工作总结
时间:2026-04-07 作者:工作计划之家（优秀）运维年终工作总结。
今年经手了四十多起故障，写了二十来份复盘报告，换了十二块缓存电池、七个风扇，拒掉三个初验。把这些事摊开说，不整虚的。
三月份那次核心交换机的故障，让我到现在想起来还觉得后背发凉。那天凌晨两点，告警突然涌进来——下游三个业务线大面积超时，用户侧已经开始报错了。我冲到跳板机上，ping核心网关，丢包率在5%到30%之间跳，毫无规律。第一反应是环路或者广播风暴，但查了STP拓扑，没变化。抓包看，发现大量TCP重传和乱序，但MAC表没抖动。折腾了四十分钟才定位到：一台老旧汇聚交换机的某块线卡上的光模块发射光功率掉了，导致链路CRC错误激增，交换机触发了内部的丢包保护。换上备用模块，业务恢复。
事后复盘是最折磨人的。我把前一周的所有日志翻出来，发现CRC错误计数器其实每天都有缓慢增长，从个位数涨到上百，但我们的监控只看了端口up/down和带宽利用率，根本没把这个指标纳入告警。说白了，我们每天都在巡检查，但巡的是“通不通、满不满”，没巡“好不好”。这简直令人难以置信——一个被我们忽略了一周的微小指标，差点酿成全业务瘫痪。
从那以后，我给自己定了个死规矩：每次故障处理完，不光写怎么修好的，还要列一张“如果早发现，该看什么”的清单。半年下来，这张清单已经积累了十七条。比如光模块的接收光功率低于-15dBm就要预警，CRC错误率超过1e-6就触发工单，端口缓冲区丢包计数非零就要人工复核。我们把其中十二条写进了自动化巡检脚本，每周跑一次，下半年成功预警了三起类似的链路劣化——两次是光模块老化，一次是光纤接头污染。现在的理解是，真正的稳定不是恢复快，而是让大部分故障根本长不大。
七月中旬那个数据库连接池风暴，是我今年学到最多的一课。周二下午两点半，业务高峰期，突然收到大量“获取数据库连接超时”的告警。我第一反应是数据库扛不住了，登上去看CPU、IO、慢查询，全正常。再看连接数，活动连接才到上限的六成。这就怪了——数据库没满，应用却在等连接。
当时有点懵，按常规思路走不通。我决定直接抓应用线程栈。jstack一看，发现大量线程阻塞在HikariCP的getConnection()上，连接池里的空闲连接数为0，所有连接状态都是“租用中”。谁借了不还？我查了最近一次发版记录，前一天晚上上线了一个新的批量导出功能。把开发同事叫起来，一起翻那段代码。发现他用的是try-with-resources，但catch块里直接return了，没有等finally执行。平时流量小，连接池有空闲，漏掉的连接还能被后台线程回收；高峰时段每个请求都占着连接不放，两分钟就把池子耗干了。
找到根因后，我临时把maxWait从30秒改成5秒，让超时请求快速失败，避免业务线程全部堆积。同时紧急回滚那个导出功能。当晚我跟开发坐下来，我说：“你这个写法，但凡压力大一点必炸。”他还有点不服：“我在测试环境跑了，没问题啊。”我直接把生产上的线程栈截图甩给他看，又给他演示了用JMeter压五十个并发时的连接泄漏曲线。他没话说了。最后我们一起重写了那段代码，强制要求所有连接操作必须用标准模板包裹，并且给所有Java服务统一加上了HikariCP的leakDetectionThreshold=30s，作为启动参数强制注入。这事之后，我养成了一个习惯：任何新服务上线前，必须审查它的连接池、线程池配置和异常处理逻辑，不看清楚不签字。
机房里的活儿，以前我觉得只要连通就行。上半年有一次紧急换40G光模块，结果相邻的三根光纤都没标签，型号还一样。我蹲在机柜后面，用手机打着光，一根根顺着线缆摸到对端端口，多花了二十分钟才找到要拔的那根。二十分钟在故障处理里是什么概念？够业务方投诉两轮了。从那以后，我给团队定了个硬规矩：所有新上架设备，必须按照《数据中心布线规范》来，标签用兄弟打印机打三防标签，捆扎松紧度以“能塞进一根手指”为准，每两周抽查一次。你懂的，这些破事儿平时没人管，但关键时刻能让你少掉一半头发。下半年我们处理硬件故障的平均定位时间从18分钟降到了9分钟，一半功劳归这些死板的工艺标准。
设备维护这块，我吃过一次闷亏。三季度做季度健康检查时，一台运行了四年的存储阵列，缓存电池已经过了标称寿命，但系统日志里没有任何告警，状态灯还是绿的。我手动触发了存储自带的电池自检脚本，才报出“Battery learn cycle failed”。当时吓得我冷汗都出来了——如果下次市电闪断，缓存数据无法落盘，那就是大面积数据不一致。让人深感无奈，设备的老化常常是静默的，你信它的灯你就输了。
所以我现在坚持一个原则：所有带寿命周期的部件，不能依赖设备自身的状态灯或简单告警，必须按日历时间强制轮换检查。我自己写了个小脚本，叫hw_health_check.py，每天凌晨跑一遍，通过SNMP和IPMI去读每个设备的电池寿命、风扇转速、SSD写入量、电容健康度。阈值是我自己拍脑袋定的：缓存电池超过三年直接换，SSD写入量到标称TBW的80%就预警，风扇转速偏移超过10%就人工复核。今年我们主动换了十二块缓存电池和七个风扇，全都是在“还没坏但快不行了”的时候换掉的。这种工作没流量没掌声，但避免了多少次后半夜的哭爹喊娘，只有自己知道。
质量验收这块，以前我是厂家出什么报告我就签什么字。今年我彻底变了。所有新系统上线前，必须过我亲手写的“破坏性验收用例”。上个月验收一台负载均衡，厂家工程师拍着胸脯说他们的健康检查和会话同步没问题。我把测试报告放一边，当着他的面拔掉后端一台真实服务器的网线。三秒后，负载均衡把它踢掉了，行，算你及格。然后我把网线插回去，服务器起来之后，负载均衡又过了五秒才把它加回来——这五秒里，会话表不同步，部分用户被路由到刚恢复的空节点，直接报错。厂家工程师脸都绿了。我说，这个我不签。后来他们调了参数，把健康检查间隔从5秒改成2秒，慢启动时间从10秒改成30秒，我重新测了三轮才放行。
今年经我手拒掉的初验有三回，都是因为故障转移时间超标或者日志缺失。虽然项目进度往后拖了，但上线后到现在零故障，我觉得值。
-
更多精彩的工作总结，欢迎继续浏览：工作总结
本文来源：//www.fz76.com/gongzuozongjie/190682.html