工作总结
2026-04-03按照部门主管工作总结。
接手部门管理这一年，我同时还得盯着核心模块的代码。说句实话，两头跑的日子没少熬夜，但有一件事我越来越清楚：光开会定流程没用，得亲自蹲在故障现场把锅背回来，才能让底下人服气。
一、那次七十二分钟的故障，让我把“闭环”两个字拆成了动作
二季度一个周三下午，生产环境的计量数据采集服务突然大面积超时。告警响的时候我正在改一份工艺标准的草案，放下键盘直接登录跳板机。先看了业务日志——干干净净，连个WARN都没有。这不对劲。
我习惯性地敲了ss -tnp | grep -c TIME_WAIT，正常应该有两三千个短连接在等待回收，结果只有不到两百。反过来看连接池的active线程数，飙到了配置上限的三倍。脑子里的第一反应是：连接没有被正确归还。
接下来用strace跟踪了一个随机采样的请求进程。系统调用序列里清清楚楚地显示：业务代码在close(fd)之后，又发起了一次read()操作。那个fd已经被内核回收了，读操作自然失败，但异常被吞掉了，连接池以为这个连接还活着，就一直等。 f236.COM
定位到这里花了四十分钟。后续查变更记录才发现，运维同事前一天按旧版的施工规范升级了底层库，新版本改了连接回收的时机——从“空闲超时回收”变成了“显式关闭后立即回收”。而我们代码里有个历史遗留的“假关闭”逻辑，一直没暴露问题。
这次故障持续了七十二分钟，三条产线的数据上报出现缺口。让我最上火的是，事后翻知识库发现，三个月前测试环境就出现过完全一样的现象，当时被人备注了一句“偶发，重启解决”。这简直让人无语——一个“偶发”就把根因放跑了。
从那以后我定了个死规矩：每次故障排除后，必须输出三样东西——根因定位的命令行记录、影响范围的监控截图、预防措施要细化到修改哪一条施工规范的哪一句话。到现在攒了四十七个案例，其中二十三个已经反向写进了标准文件。上个月一次连接泄露，运维照着更新后的检查清单，先用lsof统计句柄数，再用jmap dump堆比较，十五分钟就锁定了问题。对比过去平均两个小时的定位时间，这个进步是实打实的。
二、技术复盘会：不看PPT，只对着火焰图抠细节
每个月底的复盘会，我要求所有人不许做PPT。直接投屏，打开当月的慢调用链、异常日志、CPU火焰图。每个人回答三个问题：当时你的判断是什么？实际发生了什么？如果再给你一次机会，你改哪一行代码或者哪一步操作？
举个例子，核心模块里一个数据解析函数，平均耗时从0.3毫秒涨到了1.2毫秒。乍一看是数据量增长，但复盘时我们打开了火焰图，发现Pattern.compile()的调用占比异常高。再往下钻，循环体里居然每次都在重新编译同一个正则表达式。这个bug在代码审查时没人注意到，因为循环次数不大，压测跑不出来。但到了生产环境，一天几千万次调用，积少成多就把CPU干上去了。
那次复盘后，我让人整理了一张“性能优化检查表”，贴在每个人工位隔板上。我随便说几条你听听：第3条，所有正则表达式必须写成static final，违者代码审查一票否决；第7条，循环内禁止调用System.currentTimeMillis()超过1000次/秒；第12条，批量数据库操作必须分批提交，单批不超过500条。这些没有一句虚的，全是代码里真实踩过的坑。
三、质量验收：从“签字走形式”到“卡脖子”
以前的质量验收，测试报告签了字就算过了。结果现场一跑，断个网就崩溃。我接手后把验收拆成三步，每一步都有人签字背锅。
第一步，自动化回归必须全绿，且覆盖率不低于75%。第二步，故障注入测试——用tc命令模拟丢包30%，用kill -9随机杀进程，拔网线再插回去，看系统能不能按施工规范里写的“30秒内自动重建连接”。第三步最狠：我随机抽一个验收人员，让他对着验收清单逐条口述“如果这一条不通过，可能的原因是什么”。答不上来的，清单打回重写，不许上线。
这个做法得罪人，但管用。上个季度验收一个新模块，测试人员被问到“设备维护窗口内，如果写入超时怎么办”时愣住了。他回去一查代码，发现写死了两秒超时，但现场网络环境因为交换机老化，经常飘到五秒以上。这个bug如果在验收时没被逼出来，上线后就是一次夜间故障。
-
f236.coM编辑们的创作灵感库:
- 部门主管工作总结 | 足浴部门主管工作总结 | 公司部门主管工作总结 | 主管工作总结 | 部门主管工作总结 | 部门主管工作总结
四、也说说我摔过的跟头——不是所有改进都走对了
上半年我强行推行了一套“代码变更必须附带性能基准测试报告”的规定。初衷是好的，但执行了两个月后发现，单元测试环境和生产环境的硬件差距太大，测出来的数字没参考价值，反而让大家花大量时间去编报告。我后来叫停了这个规定，改成只在核心数据路径上做变更前后的AB对比，用生产流量的拷贝回放。这个弯路让我明白：流程不是越重越好，得卡在真正的风险点上。
五、接下来我打算做的三件笨事
第一，压缩故障平均发现时间。当前是七分钟左右，我的目标是三分钟以内。具体做法：增加五类关键指标的异常检测——连接池活跃率、慢查询数量、GC暂停次数、文件句柄使用率、网络重传率。告警不再是简单的阈值，而是用过去半小时的滑动窗口做动态基线。
第二，把那张“性能优化检查表”变成代码审查的强制项。我已经在GitLab的MR模板里加了一个checkbox，不勾选并附上截图证明，合并按钮就是灰的。
第三，每个月随机抽一个线上请求，从网关日志一直追到数据库的执行计划，把全链路耗时画成一张图，贴在白板上。谁路过谁看，谁看出问题请喝咖啡。这办法很土，但我试过两次，已经揪出三个隐藏的N+1查询。
这一年走过来，我最深的体会是：主管的威信不是来自你写了多少行代码，而是你带着大家把同一个坑填了多少遍，并且保证没人再掉进去。那些看起来最笨的办法——手写的检查表、逐条口述的验收问答、必须附上命令记录的故障报告——反而是最让我晚上能睡得着觉的东西。
-
更多精彩工作总结内容，请访问我们为您准备的专题：工作总结
