工作总结
发表时间：2026-04-12【全面】运维总监年度工作总结。
今年跟去年比，有一个变化我自己都觉得意外——去年半夜被叫醒，我先骂两句娘再爬起来；今年被叫醒，第一反应是“哪个环节又没按规范走”。说白了，不是脾气好了，是团队把该堵的漏洞堵得差不多了，剩下的才是真意外。
一、从“救火队长”到“查火种的人”，中间踩了多少坑
去年上半年，我们生产环境平均每月4起P3级以上故障。最典型的一次，某业务系统凌晨2点大面积超时，我带着两个兄弟查了三个多小时，最后发现是半年前一个同事为了赶进度，在Nginx配置里写死了上游IP。后来那台机器退役了，健康检查根本没覆盖到。那天早上六点解决问题后，我一个人在工位上坐了十分钟，心里特别窝囊——不是技术多难，是我们明明有变更规范，但执行全靠自觉。
今年我干了一件让团队一开始很不爽的事：所有变更必须带“回退预案”和“影响半径评估”，缺一项就不给上。有个老员工直接找我：“一个小补丁至于吗？这要花半小时填单子。”我说至于。你懂的，运维这行，小改动捅大篓子的例子还少吗？我把去年的故障复盘数据贴出来：6起故障里4起是变更引起的，其中3起只需要一个简单的回退步骤就能在5分钟内搞定，但因为没人提前想这一步，硬是拖了半小时以上。
具体怎么推的？我弄了个变更管理看板，每次变更前强制填三个字段：回退操作命令（必须是具体命令，不准写“回滚”两个字）、影响范围（精确到哪个接口、哪个数据表）、验证方法（怎么确认改好了）。开始有人敷衍，写“重启服务”。我直接退单，附上我写的标准模板。前两周退了11次单，团队里有人私下说“这总监事儿真多”。我没吭声，第三周开始，退单率降到2次。两个月后，新人第一次提变更单，老员工主动拦住：“你回退方案写清楚没？别给总监添堵。”
但说实话，这中间也有反复。9月份有一次，我们一个核心服务做扩容，变更单填得漂漂亮亮，回退方案写的是“停止新实例，恢复负载均衡配置”。结果真出问题时，发现回退脚本里漏了一条iptables规则，导致流量切不回去。那一次我们用了25分钟才恢复，比预期多了15分钟。复盘时我第一个检讨：预案验证机制有漏洞——只审核了文档，没审核脚本的可执行性。后来加了一条硬杠杠：所有回退脚本必须在预发布环境跑通一遍，截图附在变更单里。这玩意儿说起来简单，干起来全是坑，但总比半夜炸了再现写强。
二、团队能力不是培训出来的，是被故障逼出来的
去年我花了很多精力搞培训，讲内核参数调优、讲TCP拥塞控制，底下记得挺认真，回头遇到真实故障照样抓瞎。今年我换了个路子：每个人轮流当“值班架构师”，一周内所有变更和故障排查的第一责任人不是我，是他。我的角色从“拍板的人”变成“最后一道防线”。说实话，刚开始那一两个月，我比自己干还累——得忍着不插嘴，得看着他走弯路，得在他实在搞不定的时候才伸手。
有个场景印象特别深。今年6月，数据库连接池突然飙升，值班的是入职刚一年的小张。他按照我们沉淀的故障排查SOP，先看监控、再看慢查询、最后锁定了某个业务SQL。但他不敢确认，跑过来问我“能不能重启应用”。我没给答案，反问他三个问题：重启能解决根因吗？会不会引发雪崩？业务方能不能接受这个窗口？他愣了几秒，自己回去查连接状态，最后定位到一个定时任务批量更新没有加索引。那天晚上他主动加班把索引加上，第二天还写了个文档发给全团队。那次之后，他像换了个人，主动把数据库设计规范翻了两遍，还提出了三个改进点。
但我也有判断失误的时候。8月份一次演练，我模拟了Redis集群主节点宕机，值班的是另一个同事。他按照SOP切了从节点，业务恢复用了4分钟，指标达标。我当时觉得没问题，就让他下班了。结果第二天早上真实故障发生了，同样的场景，他用了15分钟才恢复。后来我复盘发现，演练时我漏了一个关键变量——演练是在白天低峰期做的，真实故障发生在凌晨批量任务高峰期，从节点扛不住写入压力，他又要临时扩容。这件事让我很惭愧：我设计的演练场景太“干净”了，没有把真实负载考虑进去。从那以后，所有演练必须在生产流量的镜像环境里做，并且要压上峰值数据。
三、工艺标准和施工规范，是磨出来的，不是写出来的
去年我们虽然有各种文档，但执行起来打折扣。比如服务器初始化标准写的是“关闭不必要的端口”，但有人只关了常见的21、22、23，留了一堆像111、2049这样的端口敞着。今年我把所有操作提炼成“工艺卡片”——每个动作必须有对应的脚本或命令，不允许手工敲。谁再手工改配置，我就让他把键盘吃了。这话我说过，也真的退回过两次单。
拿设备维护来说，以前硬盘更换靠人工记序列号，出过一次换错盘的事故——把A机器的盘拔了插到B机器上，数据全乱套。今年我们上了带外管理系统，换盘之前必须扫码录入，系统自动比对槽位和序列号，不匹配直接报错。这套流程跑通后，硬件故障平均修复时间从2小时降到40分钟。有兄弟开玩笑说“现在换硬盘跟换乐高似的”，我说乐高插错了还能拔，你插错了数据就没了，别开玩笑。
故障排除这块，我强制要求每起故障都要输出“五分钟快报”和“两周复盘”。快报只写三样：现象、根因、临时方案，发到团队群里@所有人。复盘必须动代码或配置，不允许写“加强责任心”这种废话。今年我们累计复盘了17起故障，其中12起都输出了永久性修复——要么改了代码，要么加了监控，要么优化了架构。剩下的5起因业务逻辑太复杂，也至少把监控告警补上了。举个例子，有一次发现某个服务的日志量突然暴增，排查下来是一个循环里打了debug日志。复盘后，我们把所有日志级别在配置中心做了动态开关，并且给每个服务设置了日志量阈值告警。
四、跨部门扯皮这事，真是让人深感无奈
今年最让我头疼的不是技术问题，而是跨部门协调。有一次存储设备扩容，我们按标准流程提前三天提了变更申请，邮件也发了、周会也同步了。结果网络组那边没看到，扩容过程中出现路由环路，业务抖动了一刻钟。事后复盘，网络组的理由是“没看到你们在群里@我”。这简直令人难以置信——我们有正式的变更系统、有邮件通知、有周会同步，结果还是靠群里@才有用。
后来我牵头搞了一个“变更握手”机制：所有依赖其他团队的变更，必须得到对方书面确认（钉钉回复“确认”就算），截图附在变更单里。这个办法土是土了点，但管用。今年第四季度，跨团队变更导致的故障降到了零。不过我也知道，这不是因为大家配合度高了，而是我把“不确认就不给上”这条写进了变更系统的强制校验里。说白了，制度不如工具，工具不如自动化。
还有一次，开发团队非要在一个周四下午上线一个紧急功能，说“客户等着要”。我看了变更内容，涉及数据库表结构变更，回退方案不清晰。我直接拒了。开发经理跑到我工位前拍了桌子：“你们运维就是拖后腿的！”我没跟他吵，拿出我们上半年的故障统计表，指给他看：“上两次你们说的‘紧急变更’，一次把订单表锁了十分钟，一次把索引删错了，都是周四下午。这周四我可以放你过，但下次故障复盘会上，你敢不敢当着老板的面说‘是我要求强上的’？”他愣了一下，回去重新排期到周六凌晨。后来他私下跟我说，那天我说话挺冲，但理不亏。
五、几个实实在在的数字和还没填的坑
团队现在6个人，管着200多台服务器、40多个微服务。今年做成的几件事，我列一下：
- 部署频率：从每周一次提到每天三次（别笑，我们这种传统行业出身的，能到这一步已经脱了层皮）。代价是回滚率从2%升到了5%，但每次回滚都在5分钟内完成，业务影响控制在分钟级。
- 监控覆盖率：从70%提到95%，漏报率下降了八成。具体怎么做的？我把所有服务的健康检查、业务指标、资源指标拆成了三张清单，每个服务一条条打勾。
- 文档：从散落在各个Wiki的碎片变成了统一的结构化知识库。每个服务必须有：架构图、依赖关系、常见故障处理、变更历史。
但我心里清楚，还有很多坑没填。比如配置中心还在用老掉牙的SVN，每次改配置要提交代码、走CI、重启服务，效率低得要命。比如全链路追踪只覆盖了核心链路，边缘服务出问题还是要靠猜。比如灾备切换演练一年只敢做一次——因为上次做的时候，切换脚本里有个路径写的是绝对路径，换到备环境就找不到文件了，差点真的切不过去。这些明年必须啃，而且我已经把优先级排好了：一季度上新的配置中心，二季度扩全链路追踪，三季度再做两次灾备演练。
- 我们精彩推荐工作总结专题，静候访问专题：工作总结
