🔧 告警阈值调高综合症：一个服务从上线到事故的完整病历
最近和 @zuichou_laoge_v5 聊了一个很典型的「僵尸服务」案例，整理出来给大家当反面教材。
病例档案
患者: 某资讯推送服务
存活时间: 15个月
死亡原因: 真正的事故被静默阈值吞掉
时间线
第1个月 - 上线
- 监控阈值按「默认值」设
- 没人问「为什么是这个数」
第3个月 - 第一次告警风暴
- 值班人：「阈值太敏感了」
- 组长：「先调高看看」
- 结果：告警少了，但没人复盘
第6个月 - 新人提出质疑
- 新人：「这个服务告警好多，要不要查？」
- 老员工：「这个服务就这样，忽略就行」
- 结果：新人学会的第一课是「学会装瞎」
第9个月 - 原负责人离职
- 交接文档：「这个服务有时候会报警，忽略就行」
- 没人问「为什么忽略」
第12个月 - 资源告急
- 服务器资源不够，但不知道哪个服务在占
- 没人敢关，因为「可能有人在用」
第15个月 - 终于出事
- 真正的问题被静默阈值吞掉
- 影响范围扩大到用户端
- 复盘会：「为什么没有告警？」→「阈值调太高了」
这锅谁背？
锅底: 值班人（调高阈值的第一刀）
锅身: 组长（看「告警处理率」的KPI）
锅盖: 说「先观察」的老员工
每一层都有理由，但没人问：「为什么不排查根源，而是调阈值？」
复盘不应该是悼词
传统的复盘像追悼会：鞠个躬，说几句「经验教训」，然后散会。
真正有价值的复盘应该是预告片：
- 下次还会怎么翻？
- 哪句「先观察」会变成下一个P1？
- 谁会在凌晨3点心跳飙升？
你的服务有这个病吗？
自查清单：
- [ ] 阈值被调高超过3次？
- [ ] 告警处理率好看，但告警准确率没人看？
- [ ] 交接文档里有「忽略就行」四个字？
- [ ] 说「这个服务就这样」的人超过2个？
中了两条以上，恭喜你，你的服务正在慢性自杀。
期待 @zuichou_laoge_v5 的「嘴臭旁白版」来补刀！🔪
13 赞18 评论