工作总结

2026-04-29 工作总结季度工作总结

2026年第一季度工作总结。

先交个底：一季度我手上七个业务系统，可用性99.97%。差那0.02%没到99.99，是因为两起故障——一个是我处理慢了，另一个是监控漏报了会儿。KPI里还有个MTTR 47分钟，比上季度快了22%，这个数字我认，但说实话，其中有两次运气成分居多。

讲一个最折腾我的事。三月份那次数据库连接池爆满，到现在想起来还觉得窝火。下午三点，支付回调接口开始超时，短信一秒钟一条。我第一反应是切到服务器上看堆栈——一千两百多个活跃连接，其中九百多个都在等连接释放。这架势，连接泄漏没跑了。但查了最近一周的应用代码提交，没人动过数据库相关的东西。怪了。

那就拉最近一小时的连接请求时序图。一看，每两分钟就有一个陡峭的尖峰，峰值是正常值的十倍。顺着来源IP反查，定位到一台新上线的定时任务服务器。连上去一看配置文件，Cron表达式写着0 */2 * * * *，每两分钟扫一次全量订单表，而且代码里只有getConnection()，没有对应的close()。开发同事是复制粘贴的，把原来一个五分钟跑一次的小任务改成了两分钟跑全量，偏偏忘了加finally里的释放。

我当时在群里贴了那段配置和线程堆栈截图，没多说话，因为气得不想说。修复很简单：改成增量扫描，只查最近五分钟的订单，加上try-with-resources，任务间隔拉到十五分钟。代码改了重新发布，十分钟后连接池水位回到正常。我又盯着跑了四十分钟，确认没有再上蹿，才撤了告警。

但是，这个故障前前后后花了多久？从收到告警到定位到那台定时任务服务器，用了18分钟。其中浪费了至少6分钟——我一开始怀疑是负载均衡把流量打偏了，跑去查了Nginx日志，发现不是。那6分钟纯属自己判断失误。后来我把这个时间线拆出来贴在了团队复盘文档里，标题就叫“今天浪费的6分钟”。

这件事之后我干了个活儿：写了一个shell脚本，扫所有定时任务的数据库连接使用方式，挂在CI流程里。现在每次代码提交，自动检查有没有未关闭的ResultSet或Statement。这事本该去年就做，一直犯懒没弄。懒一次，半夜爬起来折腾俩小时，不值当。

再说说验收那次。一月份新项目硬件部署，机房催着签字，说不然工期延误算我的。我拿过验收清单一看，UPS带载测试那栏写着“已做”，但没任何实测数据。我的习惯是，所有跟电源沾边的东西，必须亲自看负载曲线。那天晚上快十二点，我带着钳流表和红外测温仪去了机房，接入UPS管理口调历史记录——好家伙，最近一次满载测试是半年前，而且电池组里有一节内阻已经超标了。我把数据截图发群里，说“验收暂缓，电池组换完再测”。

施工方项目经理电话打过来，急了，说合同写的是抽检不是全检。我跟他说，机房的验收规范上写得很清楚，不间断电源系统带载能力必须实测，这不是抽不抽检的问题，是底线。他还在磨叽，我直接挂了电话。僵了两天，他们还是换了整组电池。三月份一次市电闪断，那台UPS硬扛了18分钟，撑到发电机起来。后来那个项目经理吃饭时私下跟我说，“当时觉得你轴，现在看是对的”。我说你别夸我，下次验收清单上再敢糊弄，我还卡你。

这事的后续是，我把所有涉及电源、制冷、网络核心设备的验收项做成了一个检查表，每个项目都有实测数据栏位和签字栏位，缺一项就不能进下一阶段。现在施工方看见这个表就头大，但也没法偷懒了。

二月份还有个教训。情人节那天晚上，大家都在过节，我一个核心报表系统突然响应慢得像蜗牛。登录上去，磁盘IO等待85%，CPU和内存倒是正常。顺着系统日志查，发现有张历史明细表被人执行了select * into，把三千万条数据导出到同一块磁盘上——那块盘同时还在写binlog和redo log。执行这个操作的是新来的数据分析师，他不知道磁盘IO会堵死。 386H.COM

杀掉会话，删掉中间表，IO立马降下来。前后花了25分钟。但问题没完。我复盘时想：为什么一个没有权限控制的操作能随便启动？为什么系统没有对大表导出做限流？为什么数据分析师的默认查询库是主库而不是从库？这三个问题，每一个都指向我自己的偷懒——之前一直想给分析团队配一个只读从库，总说“下周弄”，结果拖到出事。

二月底我把这个从库搭起来了，同时加了熔断机制：任何查询如果预计扫描行数超过五百万，或者执行时间超过十五分钟，自动阻断并推送到审批队列。注意“预计”这个词——我用了EXPLAIN估算行数，不是死等。第一周上线后误杀了一次正常的大数据导出，因为那张表的数据分布不均匀，五百万的阈值设得太死。后来改成动态阈值，根据表的总行数和平均行宽计算一个系数，误杀率才降下来。三月份这类慢查询导致的IO堵死事件降到了零。

⬬小学范文网386H.CoM当下最热:

工作第一季度总结 | 银行第一季度工作总结 | 第一季度工作小结 | 财务第一季度工作总结 | 第一季度总结 | 第一季度总结

日常的设备维护，我最烦那种死板地按厂商手册换零件。一季度我们对一批用了三年的SSD做了磨损度分析，有两块寿命已经低于15%，但按厂家推荐的更换周期，它们还有四个月才该换。我没等，直接换了。换下来的盘拆开一看，主控周围有轻微电容鼓包。这个判断依据是什么？不是感觉，是我自己写的一个脚本，每周跑一次所有盘的SMART信息，把“磨损度、重映射扇区数、CRC错误计数”三个指标做成趋势图，阈值设到20%就预警，15%强制换。这套机制一季度帮我们提前换了七块盘，有两块如果再晚两周，可能就静默损坏了。

最后说下知识库。一季度我把团队的处理记录整理了一遍，不是写长篇大论的操作手册，而是每个故障场景的“三行半”要点。比如数据库死锁的快速定位，我写的就三行：

show engine innodb status\G | grep -A 20 "LATEST DETECTED DEADLOCK"
看事务A等什么锁，事务B等什么锁
如果是个环，直接kill掉其中一个，再去代码里查多表更新的顺序

新来的同事照着做，三次能解决两次。剩下一次再往上翻文档。

二季度的事已经定好了：故障演练从每月一次改成每两周一次，不通知、不定场景。第一场我打算断一台核心交换机的上联口，看看链路聚合能不能自动切。第二场把一块SSD的smartctl返回值改成失效，看监控会不会自动派单。搞这些不为别的，就为把那0.02%的缺口补上——数据是死的，手是活的。

推荐阅读:

更多精彩的工作总结，欢迎继续浏览：工作总结