MTTR

概述 凌晨两点，你被电话吵醒。监控大屏一片红，核心交易链路 P99 延迟飙到 8 秒，上游服务开始超时熔断，客服群里用户截图已经刷屏了。你一边远程连 VPN，一边脑子里飞速转——这场景上次演练时见过吗？预案里有没有覆盖？切换步骤还记得吗？ 如果你这时候还在翻 wiki 找文档，那说明一件事：你的预案只是写了，没练过。 故障预案不是写完就完事的文档。它是一套需要反复演练、不断修正的应急肌肉记忆。就像消防队不会只在纸上画逃生路线——他们会点真火，拉真警报，让人在浓烟里跑。SRE 的故障演练也是同一个道理：不逼团队在接近真实的故障场景里做决策，到了真正出事的时候，你永远不知道谁会卡壳。 这篇文聊聊怎么把故障预案从"写给别人看的文档"变成"团队真正能执行的作战手册"，以及怎么设计演练体系让团队保持手感。 故障预案的本质：不是文档，是决策树 预案要解决什么问题 很多人把故障预案理解成一份操作手册——“如果 A 挂了，执行步骤 1-2-3”。这没错，但太浅了。真正有用的预案是一棵决策树，帮值班人员在高压环境下快速做对三件事： 判断故障等级——这事值不值得半夜叫人？叫到哪一级？ 选择止损路径——先切流量、先回滚、还是先扩容？ 确定沟通节奏——谁对外发声、多久同步一次、什么时候升级 我见过太多预案写得像产品说明书，事无巨细地列了 50 个步骤，值班同学在故障现场根本来不及看。好的预案应该短、狠、准——能在 30 秒内定位到对应的处置方案，3 分钟内开始执行止损。 预案体系的三层结构 层级 内容 目标读者 更新频率 L1 应急卡片 单服务故障的快速处置步骤（≤10 步） 值班 On-Call 每次演练后 L2 灾备预案 跨服务故障的切换方案与回滚流程 SRE 团队 每季度 L3 业务连续性预案 机房级故障的全面接管方案 SRE + 业务方 每半年 L1 应急卡片是日常用得最多的。它不是 wiki 上的长文，而是一张可以打印出来贴在工位上的卡片。格式很简单： # [服务名] 应急卡片 ## 故障特征 - 核心指标：P99 延迟 > 500ms 或 错误率 > 1% - 典型告警：service_latency_p99_critical / service_error_rate_high ## 快速止血（按优先级） 1....