后端系列第 5 章。前面几章讲了选型、拆解、缓存、分布式——但架构再合理，线上还是会出故障。稳定性的真相是：你不是在避免故障，你是在确保故障来了能接住。本篇把「接住故障」的能力拆成三条线：告警、演练、复盘。
第一条线：告警——让故障「被发现」，而不是「被投诉」
大多数团队的第一起大事故，都是用户先发现的。告警体系要解决的就是这个：故障发生到你察觉之间的时间，必须短于用户忍耐的极限。
- 告警业务指标，而不是资源指标：CPU 高是结果不是原因。真正该告的是成功率、P99 延迟、队列积压——资源告警当辅助。
- 每条告警要有处置预案：没有预案的告警 = 让值班同学半夜起来猜。收敛到 ≤10 条核心告警，每条写清「响了先看哪张面板、第一步做什么」。
- 告警疲劳是告警体系最大的敌人：天天误报，值班同学就会学会忽略——宁可少而准，不要多而吵（排障工具链有落地细节）。
踩坑记录：我们曾把告警规则建到 40 多条，半年后半夜响的告警没人看——因为 90% 是误报。后来砍到 8 条业务告警 + 资源告警只留高水位，值班质量反而上来了。
第二条线：演练——把「第一次」变成「演习过的第 N 次」
线上故障最可怕的是「第一次」：没人演练过，大家靠临场发挥。故障演练的价值，就是把高风险场景变成「演习过的日常」：
- 从高价值场景开始：缓存全失效、数据库主从切换、依赖服务熔断、流量突增 10 倍。每个季度至少演练两个核心场景。
- 演练要「真」：在灰度环境或低峰期真实切流量/断依赖，而不是对着 PPT 走流程——只有真的切过，才知道自己的预案哪里是纸面的。
- 演练的产出是「预案修订」：每次演练都会暴露预案的问题（漏了步骤、权限不对、回滚不生效），改预案比演练本身更重要。
第三条线：复盘——把事故变成团队的资产
复盘的目的不是追责，是把「这次靠运气」变成「下次靠机制」。一个有效的复盘要能回答三个问题：
- 为什么会发生（根因，不是表面原因）——方法见故障复盘模板。
- 为什么会这么久才发现/恢复（流程漏洞往往比技术根因更值钱）。
- 改进项怎么保证落地：每个改进项绑定负责人和截止日期，下个迭代必须闭环——复盘完不改，等于没复盘。
一个完整的复盘案例参考缓存雪崩事故复盘，那篇把从发现到改进的链路走了一遍。
三者的关系
告警（发现问题） → 预案（止血） → 演练（验证预案） → 复盘（沉淀机制） → 回到告警与预案
稳定性是个闭环，不是三件独立的事。团队最容易犯的错是只做其中一两件：有告警没预案、有复盘没演练、有演练不修订——链条断了，稳定性就还是靠运气。
落地清单
- 告警收敛到 ≤10 条业务告警，每条带预案
- 演练计划排进季度节奏，场景从高价值开始
- 演练产出「预案修订」，不走过场
- 复盘改进项绑定负责人与截止日期
- 稳定性闭环三件套都有人在管