工作总结
发表时间：2026-04-18〔参考〕运维一线工作梳理与经验交流。
又到年底翻运维日志的时候了。这一年的记录本比去年厚了一倍，不是因为故障变多了，而是每个问题后面我都多写了“为什么”和“怎么堵”。下面拣几个实打实的片段说一说。
一、两次Full GC引发的连锁反应
年初那次故障，现在想起来还是觉得窝火。凌晨两点监控弹窗，核心交易系统CPU飙到100%，服务假死。登录上去看GC日志，发现每秒钟Full GC一次，每次停顿8.3秒。当时第一反应是堆太小，调了-Xmx参数重启，半小时恢复。
两周后同样的事又来了，只不过换了另一个批处理接口。那次我真是火了——同一个坑踩两次。坐下来跟开发一起翻代码，才发现问题不是堆大小，而是一个定时任务每次从数据库拉200万条记录往内存里塞，触发了G1回收器的Humongous Allocation。
后来我们定了三条死规矩：
- 所有批量查询必须分页，单次不超过5000条
- 上线前用生产流量副本做全量压测，GC停顿超过1秒就打回
- 发布系统里加了“一键回滚”脚本，原来回滚要8分钟，因为要手动重启、清缓存、验证，现在用预置的Docker镜像快照，90秒内切完
下半年同类故障再没出现过。说实话，技术上的调整不难，难的是让开发改掉“本地能跑就行”的思维。
二、机房那个局部热点
六月中旬，机房一台存储设备反复报温度过高。空调出风口22度，设备进风口34度。我拿红外热成像仪扫了一圈，发现是三个月前扩容时，施工人员把三台高功耗计算节点紧挨着存储塞进去，满载时局部温度飙到46度。
翻出当时的验收报告，上面“设备间距”“热分布测试”都打了勾，但实际上没人做负载状态下的实测。我重新做了验收卡：
- 满载跑4小时，每半小时记录一次进风口温度，温差不能超过5度
- 用一把30厘米的钢尺复核相邻设备间距，拍照留底
- 所有电源线、光纤预留50厘米余量，两端贴带日期的标签
那个周末我带着两个同事，把12个机柜86台设备全按新标准过了一遍。验收时省五分钟，以后可能要花五小时来填坑，这账我算明白了。
三、光纤弯折的教训
三季度做政务云扩容，施工队布光纤跳线时，有几根直接跨过理线槽弯折，弯曲半径不到2厘米。施工队长说“能通就行”。我拿衰耗仪测给他看：合规布线的衰耗0.3dB，弯折那几根1.8dB。短距离确实不影响业务，但光模块寿命至少减半。
后来我在每个工位放了一个半径4厘米的塑料标尺，要求每根光纤走完必须卡一下。验收标准从“通断测试”升级到“衰耗值≤0.5dB+通断”。
四、容器排障的一次卡壳 [迷你句子网 JZ139.COm]
还有个事值得记一笔。十月份上线一个新服务，用的K8s部署。业务反馈偶尔超时，但监控上看CPU、内存都正常。我登进Pod查日志，发现每次超时前后都有“Connection refused”错误。折腾了两个小时，最后发现是服务启动时依赖另一个StatefulSet的headless service，但那个StatefulSet重建后Pod IP变了，而调用方代码里硬编码了旧IP。
这件事让我意识到，容器化之后不能光盯着资源指标，服务发现和DNS解析的监控也得补上。后来我在监控系统里加了headless service的端点变更告警，并且推动所有内部调用必须走service name，不允许写IP。
五、那个雨后的电话
说个暖心的。十一月初做完一次数据库大版本升级，从PostgreSQL 11升到13。准备了两周的方案，凌晨零点开始，预演了三遍。升级完成后，我在监控前盯了半小时，指标平稳。早上七点多，客户那边技术对接人打电话过来，说“昨天的批处理窗口提前了40分钟跑完，业务部门让我谢谢你”。
干运维的，系统稳的时候没人觉得你有存在感。但就这一句话，那些半夜调参数、写预案、反复测试的功夫，全值了。
六、还有哪些没做好的
不藏着掖着，这一年也有明显短板。自动化巡检还停留在脚本拼凑阶段，没有做成平台，每周至少花8小时手动登录各环境看日志和磁盘。另外，虽然年初就开始学K8s，但遇到复杂的网络策略问题还是得翻半天文档，缺乏快速定位的肌肉记忆。
明年我打算把这两个坑填上：一季度把巡检平台搭起来，至少覆盖90%的日常检查项；二季度考个CKA，逼自己系统学一遍。
这一年最大的体会：运维不是比谁救火快，而是比谁能让火少着几次。每一次复盘文档、每一版验收标准、每一个标尺，都是在给未来的自己省时间。继续干。
- 推荐阅读: 〔参考〕运维一线工作梳理与经验交流 2026年一线教师年度工作思考 【优秀】变电运维工作总结 【全面】网络运维工作年度总结 2026年图像分割技术一线工作盘点 【全面】运维总监年度工作总结
- 更多精彩的工作总结，欢迎继续浏览：工作总结
