工作总结
发表时间：2026-04-112026年技术主管年度工作总结。
去年系统巡检报告上写着全年累计故障时长43分钟。说真的，这个数字挂在那儿，我心里清楚有一块是抹不掉的——那次凌晨P0故障，光定位就花了11分钟，整个故障持续15分钟。复盘会上我差点把笔记本摔了，不是气别人，是气自己。我们天天喊高可用，结果一条跑批SQL就把连接池打满了。
那天晚上两点，值班电话响得跟催命似的。核心交易系统的数据库连接池告警，活跃连接数飙到上限。按老套路，我先让值班同事重启应用、扩容节点——这招以前管用。五分钟后再看，连接池又满了，像有个幽灵线程占着茅坑不拉屎。我当时汗就下来了，因为这意味着常规手段失效。
我直接登录数据库，敲了show processlist;，屏幕上刷出两百多个会话，大多数状态是“Locked”。凭经验，这不像普通的慢查询堆积。紧接着查information_schema.innodb_trx，SELECT trx_id, trx_state, trx_started, trx_mysql_thread_id FROM information_schema.innodb_trx ORDER BY trx_started; 排在第一个的事务已经跑了快二十分钟，状态还是RUNNING。根据thread_id反查processlist，找到对应的SQL：一条统计脚本，里面有个select * from order_detail where create_time between ...，没有索引，全表扫描。更致命的是，它触发了行锁升级为表锁，把后面所有写操作的请求全堵死了。
解决倒简单：kill 12345; 把那个会话干掉，然后在字段上建索引，再把跑批时间从凌晨1点挪到3点半。但问题是，我们花了11分钟才找到它。这11分钟里，我试了查慢日志、看监控、翻应用日志，甚至让同事去检查网络——全是无用功。说白了，我们没有一套故障现场的“快照工具”。出事了才临时想命令，像消防队到了火场才找水龙头。
所以那之后我干了一件事：把过去两年所有P1以上故障的处理过程，从告警到恢复，每一步敲过的命令、每个判断节点、每份日志的查看路径，全写成“故障剧本”。不是写文档，是写脚本式的清单。比如“数据库连接池告警”场景，清单是这样的：
show processlist;抓活跃会话，标记出Command不是Sleep的；SELECT trx_id, trx_started, trx_mysql_thread_id FROM information_schema.innodb_trx WHERE trx_state='RUNNING' ORDER BY trx_started LIMIT 5;找出最老的长事务；- 拿到thread_id后，
SELECT info FROM information_schema.processlist WHERE id=对应ID;看具体SQL； - 如果是非核心业务，
kill ID;立刻释放连接。
就四行，贴在值班电脑的显示器边上。后来我们把这套东西做成了内部一个小工具，告警触发时自动抓取这些快照存到日志里，不用等人去敲命令。那11分钟的定位时间，现在压缩到了3分钟以内。
但光有剧本还不够。真正让我长记性的，是那次故障之后跟开发的“打架”。那个跑批脚本是数据团队写的，我要求他们把全表扫描的SQL都加上索引，并且在提交前必须用explain检查执行计划。对方老大说：“就一条统计，你们DBA帮忙建个索引不就行了？”我没客气：“你们写的SQL连where条件字段都不建索引，下次换个条件还得找我。要么你们自己改，要么我把这条SQL拉进黑名单，跑批直接拒绝执行。”最后各退一步：我在代码审核流程里加了SQL静态检查规则，select * 和没有索引的where条件直接报错。这个规则后来写进了我们的《数据库变更工艺标准》，标准里明确写了：每条变更SQL必须附带explain结果，type字段不能出现ALL（全表扫描）或index（全索引扫描），否则一票否决。
还有设备维护那档子事。去年有台核心交换机的风扇模组报过温，我查监控曲线才发现它在警戒线上跑了三天，但告警阈值设得太高，硬是没触发。当时我就火了——阈值谁定的？翻配置记录，是两年前厂商给的一个参考值，后来机房空调改造过、机柜布局调整过，阈值从来没动过。这不是懒，这是蠢。
我拉了过去半年的温度数据，用Python算分位数。P95是41.5度，P99是44.2度。把警告线设在P95×1.2≈49.8度，严重线设在P99×1.1≈48.6度？不对，P99已经44.2度了，1.1倍是48.6度，那警告线反而比严重线还高。后来重新算：警告线用P90的1.2倍，严重线用P95的1.1倍。同时加了一条：任何设备告警阈值每季度重新校准一次，根据最近三个月的性能数据。这个活儿现在交给一个自动化脚本跑，每个月出报告，谁也不用拍脑袋。
- ⬬76范文网读者票选最佳专题:
- 技术年度工作总结 | 审计主管年度工作总结 | 采购主管年度工作总结 | 客服主管年度工作总结 | 2026年度工作总结 | 2026年度工作总结
说实话，当主管最大的坑是什么？是发现自己不再是个纯粹的工程师了。以前修好一个故障，我能兴奋半天。现在修好一个故障，我得想：这故障能不能不再发生？别的系统有没有同样的问题？团队里有没有第二个人能独立处理？比如那次P0故障之后，我让那个值班同事自己写复盘报告，然后带着他模拟了三次类似的场景。第一次我在旁边念命令，第二次他看着清单自己敲，第三次我直接去睡觉，让他一个人搞定。第二天早上我问：“昨晚演练顺利吗？”他说：“剧本上第三步的kill命令在生产环境MySQL 8.0下报语法错误，我改成了KILL CONNECTION。”我心里一块石头落地——他已经能改剧本了。
还有人问我，你就不怕系统出大事吗？怕，但怕没用。我的做法是：每年用混沌工程工具搞两次故障演练，专挑最脆弱的三个环节——去年是数据库连接池、消息队列积压、Nginx upstream健康检查。演练之前不告诉具体时间，只告诉“这周某天会搞一次”。第一次演练，消息队列积压那个场景，消费者处理速度跟不上，我们的自动化扩容策略居然没触发，因为监控采集周期是30秒，积压瞬间暴涨没来得及捕捉。后来把采集周期压到5秒，扩容阈值从80%降到60%。这些漏洞，你不自己捅一刀，永远不知道。
明年我就干三件事。第一，把故障自动定位的时间从现在的平均3分钟压到30秒以内，主要靠优化快照脚本和引入eBPF抓关键事件。第二，把“故障剧本”从目前的12个场景扩展到30个，覆盖网络抖动、磁盘坏道、内存泄漏这些低频但要命的情况。第三，让团队里每个人都能独立完成一次完整的故障恢复演练，从接到告警到写postmortem，不许中途问我。这三件事干成了，我就算没白当这个主管。
对了，那个43分钟的全年故障时长，明年我目标是30分钟以内。别跟我谈什么华丽转型，先把眼前这摊事儿干瓷实了。
- 更多精彩的工作总结，欢迎继续浏览：工作总结
