上个月系统崩了两次。发现第一次是个问周三凌晨，订单服务突然大面积超时，题填套机查了四十分钟才定位到——某个新上线的补批查询接口没加索引，数据量一上来直接把连接池打满了。漏洞第二次隔了不到一周，建立同一个模块，发现换了个字段，个问又是题填套机一条慢SQL拖垮了整个服务。

两次故障，补批根因不同，漏洞但暴露的建立是同一个问题：代码合并进来之前，没人认真看过它的发现数据库操作。Code Review 走过场，个问评审的题填套机人盯着业务逻辑对不对，SQL 性能压根不在检查清单里。

这就是我说的"发现一个问题"。问题本身不复杂，甚至有点低级。但它能连续发生两次，说明不是某个人粗心，是流程上有洞。

补漏洞，别只补眼前那个

第一次故障之后，我们的做法是加上索引，发个热修复。这当然对，但只做到这一步，等于什么都没做。第二次故障就是证据。

真正要补的漏洞至少有三层。最表层是那条具体的SQL，加索引、改写法，当天就能搞定。中间层是Review环节——我们把慢查询检查加进了合并请求的模板里，要求每个涉及数据库操作的PR必须附上EXPLAIN结果。这事听起来有点繁琐，但执行两周后大家就习惯了，跟写单元测试一样，一开始嫌麻烦，后来发现能省掉半夜被叫醒的麻烦。

最底层是人的意识问题。说白了，很多开发写SQL的时候不是不会优化，是没想过数据量会涨。测试环境几千条数据跑得飞快，生产环境几百万条直接趴窝。这个认知差不是靠一次故障复盘就能解决的。我们的办法是在测试环境定期同步生产数据的脱敏样本，让问题在测试阶段就暴露出来。这比任何培训都管用——你亲眼看到查询跑了八秒，下次自然会去想索引的事。

机制不是挂在墙上的文档

补完漏洞就得想一件事：怎么保证同类问题不再冒出来？靠人自觉是靠不住的，我自己写代码的时候也经常偷懒。得靠机制。

但机制这东西，最怕搞成形式主义。之前公司推过一阵"故障复盘制度"，要求每次出事都写复盘报告，结果大家花两个小时编一份PPT，真正该改的东西一个没动。所以这次我们换了个思路——不写报告，改流程。

具体做了三件事。一是把数据库操作的检查项直接嵌入CI流水线，慢查询阈值超了自动打回，不靠人盯。二是在监控层面加了连接池水位告警，超过70%就提前通知，不等它爆。三是每两周拿十五分钟开个短会，不讲理论，只过一遍这两周线上出现的慢查询和告警记录，谁写的谁讲，讲清楚怎么改的。

这套机制跑了快一个月，慢查询数量降了大概七成。但我觉得更重要的变化是——现在开发提交代码之前会自己先跑一遍EXPLAIN，不是因为制度要求，是因为上次会上被点名讲故障原因，脸上挂不住。

机制最终要起的作用，不是惩罚谁，也不是走流程，是让正确的做法变成默认动作。当"检查索引"跟"写完之后编译一下"一样自然的时候，这套机制才算真正立住了。

回头看，从一次半夜的故障电话，到一套跑得起来的流程，中间隔的不是什么高深的技术方案。就是愿不愿意多想一步——修完这个bug之后，下一个同类bug怎么才能不出现。这个问题想清楚了，机制自然就有了。