SRE 系列（五）| MTTK/MTTF/MTTV：故障应急机制的三板斧
目录
- 一、一次应急操作导致的故障蔓延
- 二、如何建立有效的故障应急响应机制
- 1. Google 的故障指挥体系
- 2. On-Call 流程机制
- 三、总结
在上一篇里，我们聊了 MTTR 的第一个环节 —— MTTI（平均确认时间），重点放在如何通过 On-Call 机制 快速发现并响应故障。
今天我们继续深入 MTTR 的另外三个环节：
- MTTK（平均定位时间）
- MTTF（平均修复时间）
- MTTV（平均验证时间）
这三个阶段对应的就是：诊断 → 修复 → 确认。
但在展开之前，要先强调一句：在故障处理中，所有手段和行动，唯一目标就是尽快恢复业务，没有第二个。
听上去很朴素，但真正执行时往往很难做到，很多团队都在这里“翻车”。我先用一个亲身经历的案例，帮你体会一下。
一、一次应急操作导致的故障蔓延
双十一前夕，我们策划过一场预热活动，玩法是秒杀，瞬时并发量极大。团队自认为准备充分，但一到时间点，系统就出现了 下单失败。
我们第一时间启用限流，但问题仍然严重，请求阻塞在价格计算的 SQL 语句上。DBA 当时压力很大，觉得“扩容最快”，于是直接上线了新的 Slave 节点，却遗漏了数据一致性校验。结果请求压力缓解了，但引入了更严重的问题：价格计算出错，用户多付了钱。
最终，我们只能紧急取消活动，用退费和补偿券来收尾，整个活动彻底失败。
复盘下来，暴露了三个典型问题：
- 缺少故障隔离手段：限流、降级、熔断等策略不完善，业务恢复只能依赖改代码 → 浪费时间。
- 缺少角色与流程机制：DBA 独自决策，缺乏协同和反馈机制，反而放大了故障。
- 缺少演练：既没演练过限流降级等应急手段，也没有演练故障协作流程。
二、如何建立有效的故障应急响应机制
建立应急响应机制是避免上面问题的关键，我们可以依赖 War Room 机制。这是我们应急响应中的核心环节，它指的是在故障发生时，迅速将相关人员召集起来，快速响应并协作解决问题。
但仅仅有 War Room 并不够，真正有效的应急响应还需要有明确的角色分工和沟通机制。
1. Google 的故障指挥体系
Google 参考了美国消防员的应急指挥体系，建立了类似的角色分工：
- Incident Commander (IC)：故障指挥官，负责协调和组织整个故障处理工作。
- Communication Lead (CL)：沟通负责人，负责信息收集、传达和对外通报。
- Operations Lead (OL)：运维指挥，负责具体的故障排查和业务恢复。
这些角色形成了紧密的协作机制，确保故障响应高效有序。
其实还有一类角色，虽然不在指挥体系内，但是也非常重要：
Incident Responders，简称 IR。就是所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的，比如具体执行的 SRE、网络和系统运维、业务开发、平台开发、网络或系统运维、DBA，甚至是 QA 等
2. On-Call 流程机制
在我们的实践中，On-Call 流程机制被总结为“关键 5 步法”：
- 确保关键角色在线：不仅仅是 SRE 和运维人员，还包括核心业务的 Owner 或 Backup。
- 组织 War Room：一旦确认故障，立即组建应急小组，实时同步信息并进行高效协作。
- 建立合理的呼叫方式：避免同一个人长期值守，确保 On-Call 轮班机制的合理性。
- 确保资源投入的升级机制：SRE 或运维可以直接要求上级协调资源，以确保处理速度。
- 与云厂商联合 On-Call：云服务供应商也应纳入应急响应机制，确保跨组织协作顺畅。
三、总结
故障处理过程中，效率的关键在于三个因素：
- 技术层面：故障隔离手段是否完备。
- 流程机制：指挥体系是否明确，角色分工是否清晰。
- 演练与反馈：应急流程是否经过演练，沟通反馈是否及时。
通过加强技术手段、优化流程机制，并定期进行故障演练，我们能显著提高故障处理效率，确保在故障发生时能够快速恢复业务，减少损失。