SRE 实战手册六故障发现与处理On-Call 与恢复业务优先对应课程「06故障发现如何建设 On-Call 机制」「07故障处理一切以恢复业务为最高优先级」。本篇直接对接我们的实验台Alertmanager → On-Call 告警台deploy/incident_console.py。一、故障全周期发现 → 处理 → 复盘课程把故障拆成三段每段都有最佳实践。这一篇讲前两段MTTI(发现时延) 故障发生 ─────────► 被发现 ─── MTTK(定位) ──► 处置 ──► 恢复 ▲ ▲ On-Call 机制 恢复业务最高优先SRE 关注的是这些时间指标MTTIMean Time To Identify平均发现时延从故障发生到被盯上屏。MTTKMean Time To Know平均定位时延从发现到搞清楚根因方向。MTTRMean Time To Repair/Restore平均恢复时延从处置到业务恢复。MTBFMean Time Between Failures两次故障间隔。注意SRE 通常追求缩短的是MTTI 和 MTTR而不是盲目追求 MTBF。故障一定会来能快速发现和快速恢复系统就是可靠的。二、06On-Call 机制让发现有保障On-Call值班不是手机 24 小时开机这么原始。课程里一套可落地的 On-Call 机制包含1. 清晰的升级链路Escalation一级一线5 分钟内响应→ 二级二线专家→ 三线研发负责人/厂商。我们实验台里alertmanager.yml的路由就体现了这点route:receiver:oncall-webhookgroup_wait:10s# 同组告警合并等待避免轰炸group_interval:30srepeat_interval:1hroutes:-match:{severity:critical}repeat_interval:5m# 严重告警 5 分钟重复提醒直到有人认领2. 告警要可行动不是可观赏告警三问每条告警上线前自问这条告警触发后我要做什么没有动作的告警 噪音它对应的用户影响是什么谁该收到它半夜被叫醒是否值得3. 减少告警疲劳我们slo_rules.yml里对结账做了燃烧速率告警而不是每次 500 都叫。原因是偶发 1 次 500 不值得半夜叫人但快速燃烧预算必须马上 Page。区分需要人现在动和明天看工单就行是 On-Call 能长期运转的前提。4. 我们的 On-Call 告警台deploy/incident_console.py是个零依赖的小服务接收 Alertmanager 的 webhook把告警落盘成寻呼记录并展示在页面上模拟真实的短信/电话链路# 访问 On-Call 告警台运行在监控节点 0001curlhttp://0001公网IP:9099/页面会列出当前活跃告警、级别、起始时间以及当前值班表——这就是 MTTI 的承接面。三、07故障处理一切以恢复业务为最高优先级这一讲是课程里态度最鲜明的一节核心一句话故障处理的第一目标永远是恢复业务而不是找到根因。很多工程师包括曾经的我一遇到故障本能是先看看为什么。这在 SRE 里是错误优先级原则 1先止血再查因能回滚就先回滚能切流量就先切能降级就先降级。恢复动作通常 5 分钟能做完定位根因可能要 2 小时——用户不关心你知不知道原因只关心现在能不能下单。原则 2建立指挥体系不要群龙无首大故障里最怕五个人同时排查、没人拍板恢复。课程强调要有一个事故指挥IC, Incident Commander角色他不一定技术最强但要负责宣布启动事故响应、拉群/拉会指派恢复执行人和信息同步人在继续定位和直接恢复之间做决策。原则 3沟通比你想的更重要对外业务、客服、用户公告、对内研发、SRE、管理层要有单一信息源避免小道消息满天飞。我们实验台把告警集中到 On-Call 台就是这个单一信息源的雏形。原则 4保护当事人故障中情绪紧绷复盘前不追责、不甩锅。这点在第 08 讲复盘时还会展开——对事不对人才能拿到真相。四、用实验台跑一次发现 → 处理等监控面起来后我们可以这样演练下一篇复盘会用到这次记录# 1) 在业务节点注入 30% 结账失败模拟故障bash/opt/sre-lab/fault.sh inject0.3# 2) 观察sre_monitor 实时错误率/燃烧速率越过 14.4× 快燃阈值curl-shttp://127.0.0.1:9090/status# burn_rate 飙到 18.5×~140×CheckoutBudgetBurnFast 告警触发并 page On-Call# 3) On-Call 告警台收到 critical 寻呼curl 127.0.0.1:9099 可见# 4) 按恢复优先原则不查根因先止血bash/opt/sre-lab/fault.sh recover# 清除故障业务立刻恢复# 5) 告警自动 resolved进入复盘环节注意第 4 步我们没去为什么 30% 失败而是先recover让预算停止燃烧。这就是 07 讲的现场落地。实现说明本实验的1h 错误率 / 燃烧速率由零依赖的sre_monitor.py计算抓取 4 节点/metrics→ 算结账错误率 → 换算燃烧速率 → 越 14.4× 即向 On-Call 台发 webhook为便于演练把评估窗口从 1h 缩到 120s。生产环境用 Prometheus Alertmanager 完全等价配置见仓库deploy/prometheus.yml、alertmanager.yml、slo_rules.yml。实测本次演练真实数据incidents.log为证健康基线结账错误率 ≈0.02%燃烧速率 ≈0.2×无告警全节点注入 30% 结账失败后约 1 分钟内1h 错误率越过 14.4× 阈值 →CheckoutBudgetBurnFast触发critical 寻呼22:38:19燃烧速率 18.5×稍早CheckoutBudgetBurnSlow先触发 warning22:38:146.4×按恢复优先执行fault.sh recover清除故障约 3 分钟窗口滚动后告警自动 resolved22:41:54 / 22:41:59全程 On-Call 告警台:9099可见两条活跃告警及其起始时间落地了 MTTI 演练。这套注入 → 发现(Page) → 恢复 → 解除 → 复盘的闭环已在本实验台完整跑通。五、小结与思考题SRE 优化 MTTI / MTTR而非盲目追求零故障。On-Call 要有升级链路、可行动告警、抗疲劳设计。故障处理最高优先级永远是恢复业务先止血再查因要有指挥角色。思考题你们上一次 P 级故障从发生到被发现的时延MTTI是多少这中间是系统叫了你还是用户投诉叫了你如果是后者On-Call 机制可能还没真正建立。下一篇故障恢复了我们进入最容易被敷衍、却最有长期价值的一步复盘与黄金三问。
