先把时间线摆出来，这比任何总结都有说服力。
- 19:12 某个上游依赖开始返回超时，我们的一个核心流程失败率从 0.2% 涨到 68%。
- 19:47 客服群里出现第一条用户反馈：提交没反应。
- 19:52 值班同事看到反馈，开始查。
- 20:20 定位到上游超时，开始降级。
- 20:35 降级生效，恢复正常。
从故障发生到有人知道，隔了 35 分钟。这 35 分钟里影响了大约一万两千次操作。
事后复盘时，老板问了一个很直接的问题：我们不是有监控吗？
为什么监控没响
我们确实有监控，而且看板做得挺好看。但那天它一声没吭，原因有三个，每一个都很典型。
第一，监控的层次不对。我们监控的是资源和进程：CPU、内存、磁盘、实例存活、接口的响应时间。故障期间这些指标全部正常——服务活着，接口也在 200 毫秒内返回，只不过返回的是失败结果。系统很健康地在失败。
第二，有一条相关告警，但被静音了。失败率告警三个月前配过，因为阈值设得太敏感，一天要响十几次，值班的人不堪其扰，把它静音了，然后忘了。这是最讽刺的一点：告警存在，但被我们自己关掉了。
第三，即使响了，也没人知道该干什么。那条告警的内容只有一句「失败率超过阈值」，没有说是哪个环节、影响什么业务、该找谁。收到的人第一反应也是先去问别人。
我们改了什么
把监控分成三层，重点做最上面一层
资源层（机器状态）、应用层（接口耗时、错误率、线程池、连接池）、业务层（成功提交数、支付成功率、核心链路完成率）。
以前我们 90% 的精力在前两层，现在反过来。业务层指标是唯一能反映「用户是不是真的能用」的东西。那次事故里，如果有一个「每分钟成功提交数」的曲线，19:13 就能看出来它掉到了地板上。
用同比，不用固定阈值
固定阈值在业务有波动的系统里几乎没法用：白天设的阈值到了凌晨全是误报，凌晨能用的阈值白天又不敏感。
我们改成跟上周同一时刻比、跟一小时前比。核心指标下跌超过 40% 就告警。这个改动让误报量断崖式下降。
治理告警疲劳
我做了一次统计，那一周我们一共收到 400 多条告警，其中真正需要动手处理的只有 20 条左右。也就是说 95% 是噪音。在这种比例下，任何人都会开始无视告警，这是人性问题，不是态度问题。
治理的做法是给每条告警定级并且问一句：收到它之后有明确的动作吗？
- 有明确动作、且必须立刻做的 → 保留为告警，允许半夜叫人。
- 需要关注但不用立刻处理的 → 降级成日报或者看板。
- 说不出动作的 → 直接删掉。
删掉的那批占了将近一半。删的时候有人担心万一以后需要呢，我的回答是：一条从来没人处理的告警，和不存在没有区别，但它会稀释所有其他告警的可信度。
每条告警带处置说明
现在我们的告警内容有固定格式：什么指标、当前值和参照值、影响哪个业务、可能的原因列表、一个处置文档的链接。新人值班第一次收到告警也能按文档走完前三步。
还有一条更重要的
复盘时我们争论了很久：那 28 分钟的定位时间（19:52 到 20:20）能不能缩短。后来我意识到问题问错了。
正确的问题是：为什么必须先定位才能恢复？
如果我们一开始就有一个降级开关，值班同事在 19:52 看到失败率飙升时，可以先关掉这个非核心依赖、让主流程走兜底逻辑，然后再慢慢查原因。恢复和定位本来就该解耦。
现在我们对每个外部依赖都要求有降级预案，并且每季度真的演练一次——在测试环境把依赖切断，看降级开关是不是真的有效。第一次演练时我们发现有三个开关是坏的，配了但代码里根本没读。
这个发现本身，就值回了演练的成本。