工作总结
2026-04-14 工作总结 运维工作总结〔实荐〕运维工作总结。
今年经手的大小故障算下来有80多个，P0级3个，P1级12个。挑三个最典型的说说，都是自己踩过的坑，有的现在想起来还觉得后背发凉。
先说第一个，那次被“常规升级”坑惨的事。
双十一前两周，按计划升级交易中间件。测试环境跑了三天，所有压测用例都过了。上线选在晚上11点，想着业务量小，出问题也好收场。结果切流量刚切到30%，监控就炸了——CPU冲到95%，线程阻塞数从几十跳到两千多。
当时第一反应不是回滚，是稳住。我让同事先把刚切的流量切回去，自己上跳板机抓现场。一开始怀疑是JVM GC问题，看了下GC日志，Full GC频率正常；又怀疑网络重传，tcpdump抓了几百个包也没看出异常。折腾了大概5分钟，脑子才转过弯来——应该看线程栈。执行top -H -p找到CPU高的线程ID，再用jstack打印出来，发现大量线程卡在同一个SQL执行上。
事后dump文件分析，新版本的数据库驱动把一条本该走索引的IN查询，改成了全表扫描。为什么测试环境没发现？因为测试环境那张表只有两万行数据，全表扫描也就几十毫秒。生产环境那张表两千三百万行，一扫描直接拖死连接池。
结果你猜怎么着？从报警到业务恢复用了19分钟，但丢了三笔订单的实时写入。后来我们立了条规矩：所有中间件升级，必须在生产灰度环境用真实流量回放跑够48小时。回放平台是自己搭的，用的tcpcopy把线上流量引到灰度机，再比对响应结果。这活儿干了三天，但之后再没出过类似问题。
第二个案例，那条“半死不活”的光纤。
某天凌晨三点，异地机房的存储链路告警，双活架构里一条链路丢包率40%。诡异的是应用日志只有零星超时，没有大面积报错。这种状态最磨人——你说它断了吧，业务还能跑；你说它好吧，那40%的丢包随时可能酿成大祸。
我先查交换机端口计数，发现CRC错误和链路震荡记录都在那条链路上。接着登录存储控制器，执行multipath -ll看所有LUN的路径状态——果然，一半路径显示“degraded”。这时候要做隔离，但得先确认故障链路不是主路径。怎么确认？看/sys/class/fc_host/host*/device/下的设备状态，再配合存储管理软件查每条路径的优先级。确认之后，用fcinfo强制把故障链路对应的端口隔离，业务流量全部切到正常链路，丢包率瞬间归零。
天亮进机房实测，发现是配线架上那个端口的光模块老化，光衰值刚好卡在接收灵敏度的临界点——热的时候勉强通，冷的时候就开始丢包。后来我们在Zabbix里加了个监控项：光功率低于-16dBm或者CRC错误率连续5分钟超过0.01%，直接发警告，不等它恶化。还写了个每天凌晨自动跑的脚本，拉取所有光模块的DOM信息，生成趋势图。现在一眼就能看出哪个模块快不行了，提前换掉。
第三个，被“经验主义”坑的那回。
某台数据库服务器报磁盘错误，执行smartctl -t short，结果显示PASSED。按我以往的经验，这种通常是文件系统问题，打算在下个维护窗口跑fsck修复一下就行。
正准备写方案，旁边一个同事多嘴问了句：“长测跑过没？”我当时觉得没必要——短测都过了，长测多浪费时间。但手贱还是敲了smartctl -t long。结果长测跑到80%的时候，直接报“不可恢复的读错误”。我后背一凉，赶紧联系硬件供应商准备换盘，同时把数据库从这台节点切走。
事后复盘，短测只检测了磁盘的元数据和部分扇区，长测才是全盘扫描。如果当时跳过这一步，等业务高峰期磁盘彻底坏掉，那就是硬切换，数据可能丢、切换时间可能长达半小时。现在我们对所有存储介质报修定了个硬规矩：必须先跑长测，截图留证，才能提更换申请。时间再紧也不行。
说实话，这一年干的活儿，八成是常规操作，真正让我长本事的就那两成“意外”。总结几点实在的：
第一，故障处理先止血，再破案。 别管根因是什么，先切流量、先隔离、先回滚。哪怕事后发现是自己操作失误，也比业务长时间中断强。
第二，复盘不能走过场。 我们现在要求每份复盘报告必须回答三个问题：怎么发现的？怎么定位的？怎么避免再发生？前两个写技术细节，第三个写改了哪些监控、补了哪些脚本、修了哪些流程。光写“加强巡检”这种废话，不如直接贴代码。
第三，文档和脚本是凌晨三点的救命稻草。 我把所有高频故障的处理步骤都写成了Checklist，每个步骤对应一个命令或一个脚本。遇到问题时按清单走，不会因为脑子糊涂而漏掉关键操作。
明年计划：把今年这几个案例的自动化预案补全，再搞个混沌工程演练平台，每个月故意制造点故障练练手。干运维的，不能等出事才想起来练。
- 为了您方便浏览更多的工作总结网内容，请访问工作总结
