SRE 系列（四）| MTTI 与 On-Call：高效故障响应之道
@[TOC](目录)
在 SRE 的体系中，SLI、SLO 和 Error Budget 已经帮我们把稳定性目标量化并落地。
但是目标定好了，日常工作依然会遇到一个关键问题：当真正的故障发生时，我们该如何尽快发现并响应？
这一讲，我们就把重点放在 MTTR（平均修复时间） 的第一个环节 —— MTTI（平均确认时间）。
因为只有尽快识别并确认故障，后续的定位、修复和验证才能真正高效。
一、MTTR 四个环节回顾
我们知道，MTTR 可以拆分为四个环节：
- MTTI：故障发现 → 响应
- MTTK：故障响应 → 定位
- MTTF：定位 → 修复
- MTTV：修复 → 验证
在 IBM 的统计中（主要针对网络设施），MTTK 占比最大。这很符合直觉：很多时候问题不在于“能不能修”，而是“到底问题出在哪”。
但在复杂的分布式系统中，情况会不太一样：
- MTTI 往往占比更高 —— 因为判断问题是否为故障、影响范围多大、要召集哪些人，都可能花费大量时间。
- 故障策略也会不同 —— 分布式系统的优先目标通常不是立即找到根因，而是先通过隔离手段快速恢复业务（限流、降级、熔断、主备切换等）。
所以，要提升整体 MTTR，就必须先从缩短 MTTI 入手。
二、MTTI：从发现故障到响应故障
MTTI 的时间跨度，就是从 故障真正发生 到 团队开始采取行动 的这段时间。
它包含两件核心工作：
- 判断问题是否为故障（以及故障等级）；
- 确定谁来响应并召集相关人员。
1. 判断是不是故障
在传统模式下，团队常常依赖用户投诉或客服反馈来触发应急响应。比如“10 分钟内有 50 个用户无法支付”，才被判定为故障。
但问题是：等到用户投诉，影响早已不可接受。
在 SRE 体系下，我们可以依托 SLO 和错误预算 来判定：
- 如果某个问题在短时间内消耗了过多错误预算，就应该立即判定为故障；
- 并且根据消耗比例，快速定级（比如消耗 20% 预算 → P2，消耗 50% → P0）。
这种方式比“等用户报案”要快得多，也更客观。
2. 谁来响应和召集？
判定为故障后，问题就变成了“谁来处理”。
这就是 SRE 中强调的 On-Call 机制：确保总有人能接收告警、快速决策并组织应急。
在 On-Call 阶段，有一点要特别注意：
👉 不是所有告警都要响应，而是要聚焦于那些真正影响稳定性的告警，也就是基于 SLO 的告警。
三、On-Call 的实践与案例
先分享两个真实案例：
案例 1：HBase 故障（跨团队协调慢）
周末 HBase 出现部分节点不可用，广告业务受到影响。
虽然 15 分钟就能修复，但光是协调各方人员上线排查，就花了 45 分钟。
案例 2：IM 产品早高峰故障（响应时段不合理）
每天早上 8:30-9:00 使用高峰时段频繁出故障，偏偏是员工通勤时间，导致响应严重滞后。
最后只能通过 错峰上下班 来保证有人随时在线值守。
这两个案例说明：
- 技术上的监控和告警固然重要；
- 但真正影响 MTTI 的，往往是 流程机制和组织协作。
四、On-Call 关键 5 步法
On-Call 流程机制，归纳为 5 步：
-
确保关键角色在线
-
不仅仅是运维或 SRE，而是核心业务的 Owner 或 Backup 都要参与 On-Call。
Google 的思路是：从依赖万能工程师，演进为由手持 SOP、经过演练的 On-Call 工程师处理大多数故障。
关键角色在线是机制保障，SOP+演练是能力保障
-
-
组织 War Room
- 严重故障时，立即组建“消防群”或电话会议，形成实时协作。
-
建立合理的呼叫方式
- 避免总是打扰同一个专家。建立轮班机制，确保公平和效率。
-
确保资源投入的升级机制
- 授权 SRE/运维直接向上级申请资源支持，必要时升级到 CTO/VP 层面。
-
与云厂商联合 On-Call
- 上云后，云服务就是系统的一部分。要与云厂商建立协作机制、联合演练和快速支撑通道。
五、总结
关键结论：
- 基于 SLO 和错误预算，可以更快、更客观地判定是否为故障，并定级响应。
- On-Call 流程机制 比单纯的技术手段更重要，高效的协作机制能显著缩短 MTTI。
- On-Call 的关键 5 步：
- 确保关键角色在线；
- 组织 War Room；
- 建立合理的呼叫方式；
- 确保资源投入的升级机制；
- 与云厂商联合 On-Call。
当 MTTI 被有效缩短时，我们不仅能减少不可用时间，更能为后续的定位、修复和验证赢得宝贵时间。