工作总结
发表时间：2026-04-012026年周末值班故障处理小结[范例]。
周五晚上十一点，手机震了。我看了一眼，数据库连接数告警，阈值800，实际1176。
第一反应不是慌，是骂自己——昨天下班前才跟小张说“那个报表接口先上吧，周末流量不大”。这话现在听起来像废话。
连上VPN，查processlist，一堆Sending data状态的查询堆在那，来源IP指向刚上线的那台应用服务器。我让小张也起来看了，他在群里回了个“卧槽”，然后说“我那个接口的SQL”。我没接话，先干活。
执行kill命令清连接的时候，手有点抖。不是因为紧张，是知道这次是我自己放过去的。清理完异常连接，业务开始恢复，但接口响应还是慢。打开慢查询日志一看，order_detail表全表扫描，那张表现在有四百多万行数据。创建联合索引的时候，我在命令行里敲ALTER TABLE，盯着屏幕等了两分钟。这两分钟里，支付回调失败了三次。
索引建完，接口响应从8秒掉到120毫秒。连接数回落到200左右。整个过程12分钟。
我让小张去查那三次失败的支付回调，手动触发重试。他说好，然后补了一句“组长，那个SQL我写的时候觉得数据量不大……”我说先干活，明天再说。
挂了电话，我给运维总监发了条消息，简要说明了故障情况和处理过程，提了一句“根源在我把关不严”。他回了四个字：“周一细聊。”
周六上午十点，线上复盘会。我没让小张写检讨，也没让大家轮流发言。我直接把自己的操作记录投屏出来，从收到告警到索引建完，每一步怎么走的，当时怎么判断的，都过了一遍。然后说：“这个故障，根因是我没卡住那个SQL。但除了我，还有三个漏洞——监控阈值设高了，慢查询没有独立预警，应急预案文档里缺了‘连接数暴增’这一节。”
小张在语音里沉默了一会儿，问了一句：“那我那个接口还继续用吗？”我说用，但代码得改，分页逻辑重新写，下午四点前提交。
会后我列了个清单。第一条就是改监控阈值。之前数据库连接数告警阈值是800，但数据库最大连接数设的是1000，中间只有200的缓冲。按上周的流量峰值来看，从正常值200涨到800，最快一次只用了7分钟。这个缓冲窗口太窄了。我把阈值调到500，同时在Grafana上加了一个慢查询数量面板，每分钟超过5次就给值班群发钉钉。这个慢查询预警其实上季度就提过，当时手头在赶另一个双十一的压测项目，想着“先放一放”，结果一放就放到出了故障。
第二条是整理应急预案。我把这次用到的命令——show processlist、kill、ALTER TABLE加索引的完整语法，连带着怎么判断哪个SQL该杀、哪个索引该建的逻辑，都写进了操作手册。还加了几个坑：比如创建大表索引时建议用pt-online-schema-change而不是直接ALTER，避免锁表时间过长。写完后发群里，让每个人周末抽时间在自己的测试环境跑一遍。
第三条是重新审核本周要上线的代码。我挨个查了涉及数据库变更的提交记录，又找出3处索引缺失和2处分页逻辑可能存在的深分页问题。其中有一个是另一个同事老周写的，他看了之后说“这个确实没注意”，然后自己改完重新提测。
下午小张把改好的代码提交了，我跑了一遍压测，接口响应稳定在200毫秒以内，慢查询日志干干净净。
周日下午，我在做那个“观测清单”的模板。其实就是一张表：接口名、预期QPS、核心表、慢查询阈值、索引命中情况。以后每个上线的接口必须附带这个，否则不给合并。这不是什么新点子，就是之前一直没落到纸面上。我一边做一边想，如果这个清单三个月前就有了，周五晚上的故障大概率不会发生。
总监那条“周一细聊”的消息，我到现在还没想好怎么回。要说责任，确实在我——评审放水、监控阈值没优化、应急预案不完整，这些都不是小张的问题。但我更在意的是另一件事：为什么明知道慢查询预警该做，却一直没排上优先级？为什么明知道那个SQL有隐患，却说了“先上吧”？这些不是流程能解决的，是我自己在这类事情上不够较真。
周一早会，我打算先把观测清单推下去，然后把上周五的故障处理过程在团队里再过一遍。这次不说“反思”，就说“我当时怎么想的，哪步错了”。小张那几句“数据量不大”的话，其实我挺熟悉的——我自己当年也说过类似的话，然后捅了更大的娄子。经验这东西，有时候是护身符，有时候就是麻痹药。 dSbJ1.com
故障处置那12分钟，从监控告警到索引生效，时间精确到分钟。但真正让我觉得需要调整的，是那12分钟之外的很多东西。那些日常里觉得“差不多就行”的决定，最后都会变成某个深夜手机震动的原因。
这个周末，我补了三样东西：监控、文档、流程。但最该补的，是我自己对“差不多”这两个字的警惕。
- 需要更多的工作总结网内容，请访问至：工作总结
