4. 故障排查总览：Error Budget 消耗异常时的排查流程框架
当 Error Budget 消耗速率或剩余量触发告警阈值时，SRE 团队需要一套标准化的排查流程来快速止血、定位根因并完成复盘。本章将围绕“发现→定位→根因→恢复→复盘”五个阶段，构建完整的故障排查框架。
核心原则：Error Budget 是 SLO 的“燃料”，消耗异常意味着用户可感知的可靠性正在下降。排查流程必须优先恢复用户体验，其次才是根因分析。
4.1 五阶段排查流程总览
以下表格总结了每个阶段的核心目标、关键动作与输出物：
| 阶段 | 核心目标 | 关键动作 | 输出物 |
|---|---|---|---|
| ① 发现 | 确认 Error Budget 消耗异常，判断严重程度 | 检查 SLO 仪表盘、告警通知、燃烧速率告警 | 告警确认单、初步影响范围 |
| ② 定位 | 缩小故障范围，识别故障类型（性能/可用性/容量） | 查看服务拓扑、依赖关系、黄金信号指标 | 故障域隔离报告 |
| ③ 根因 | 确定根本原因，避免误判 | 日志分析、链路追踪、变更审计、代码审查 | 根因分析文档（RCA） |
| ④ 恢复 | 消除故障影响，恢复 SLO 合规状态 | 回滚变更、扩容、限流、降级、切流 | 恢复操作记录、SLO 恢复时间 |
| ⑤ 复盘 | 沉淀经验，改进系统与流程 | 组织复盘会议、更新 SLO 台账、优化告警 | 复盘报告、Action Items |
实战提示：在“发现”阶段，不要只依赖单一告警源。建议将 Prometheus Alertmanager、Grafana 看板、PagerDuty 通知与人工巡检结合，避免告警风暴或漏报。
4.2 发现阶段：从告警到确认
发现阶段的目标是快速确认 Error Budget 消耗是否真实异常，并评估影响等级。常见的触发源包括：
- 燃烧速率告警（Burn Rate Alert）：基于多窗口（如 1h、6h、24h）的 Error Budget 消耗速率告警，是最高效的发现手段。
- SLO 仪表盘异常：Grafana 看板上 SLO 达成率曲线出现陡降。
- 用户反馈/工单：客服或用户侧报告服务质量下降。
常见陷阱：不要忽略“慢消耗”场景。Error Budget 可能在数小时内缓慢消耗殆尽，而非瞬间爆发。建议设置多级燃烧速率告警（例如：1% / 5% / 10% 消耗速率）。
4.3 定位阶段：隔离故障域
定位阶段的核心是缩小排查范围。推荐使用“分层隔离法”：
- 服务层：检查哪个微服务或 API 的 SLI 指标（延迟、错误率、吞吐量）出现异常。
- 依赖层：查看上游依赖（数据库、缓存、消息队列）是否健康。
- 基础设施层：检查节点、网络、存储等资源是否存在瓶颈。
以下表格展示了不同故障类型的典型特征：
| 故障类型 | 典型 SLI 表现 | 常见根因 |
|---|---|---|
| 性能退化 | 延迟 P99 升高，错误率小幅上升 | 慢查询、资源争抢、代码效率问题 |
| 可用性故障 | 错误率飙升，请求失败 | 服务崩溃、网络分区、配置错误 |
| 容量不足 | 吞吐量达到上限，请求排队或超时 | 突发流量、扩容滞后、限流策略缺失 |
4.4 根因分析阶段：从现象到本质
根因分析需要结合多种可观测性数据源。推荐使用“5W1H”提问法驱动分析：
- What：什么 SLI 指标异常？错误类型是什么（HTTP 5xx、超时、业务错误）？
- When：异常从何时开始？是否与变更发布时间吻合？
- Where：影响哪个服务、哪个地域、哪个用户群体？
- Why：日志中是否有异常堆栈？链路追踪中哪个环节耗时最长？
- Who：最近谁做了变更？变更内容是什么？
- How：故障是如何传播的？是否有级联效应？
工具链推荐：日志（ELK/Loki）+ 指标（Prometheus/Thanos）+ 链路追踪（Jaeger/Tempo）三支柱联动，是根因分析的基础设施。
4.5 恢复阶段：止血与恢复
恢复阶段的目标是尽快将 Error Budget 消耗速率降至安全水平。常见的恢复操作按优先级排列：
| 优先级 | 操作 | 适用场景 | 风险 |
|---|---|---|---|
| P0 | 回滚最近变更 | 确认故障由变更引入 | 低（标准操作） |
| P1 | 扩容 / 弹性伸缩 | 容量不足或突发流量 | 低（需确保资源池充足） |
| P2 | 限流 / 降级 | 防止故障扩散，保护核心链路 | 中（可能影响非核心功能） |
| P3 | 切流至备用集群 | 单集群故障或区域性故障 | 中（需验证备用集群容量） |
恢复指标：恢复操作生效后，应持续观察 Error Budget 消耗速率是否下降，以及 SLO 达成率是否开始回升。建议设置“恢复确认窗口”（例如 15 分钟），避免过早宣布恢复。
4.6 复盘阶段：从故障到改进
复盘不是追责，而是系统改进的起点。复盘会议应围绕以下结构展开：
- 故障时间线：从发现到恢复的完整时间轴，标注关键决策点。
- 根因总结：确认根本原因，区分直接原因与间接原因。
- 影响评估：计算本次故障消耗的 Error Budget 百分比，评估对月度 SLO 的影响。
- 改进措施：针对每个根因和流程漏洞，制定可执行的 Action Items。
- SLO 台账更新：根据复盘结果，调整 SLO 目标、告警阈值或 SLI 定义。
复盘输出示例：“本次故障因数据库连接池耗尽导致，消耗 Error Budget 12%，影响月度 SLO 0.3%。改进措施：① 增加连接池监控告警；② 优化慢查询索引；③ 更新 SLO 台账，将数据库连接池健康度纳入 SLI 候选指标。”
4.7 排查流程检查清单
为帮助 SRE 团队在故障期间保持操作规范，以下是一份可打印的排查流程检查清单：
| 阶段 | 检查项 | 完成标记 |
|---|---|---|
| 发现 | 确认告警真实性，排除误报 | □ |
| 发现 | 记录故障开始时间与当前 Error Budget 消耗量 | □ |
| 定位 | 检查服务拓扑图，确认受影响的服务列表 | □ |
| 定位 | 查看黄金信号（延迟、错误率、流量、饱和度） | □ |
| 根因 | 检查最近 1 小时内的变更记录 | □ |
| 根因 | 分析错误日志与链路追踪数据 | □ |
| 恢复 | 执行回滚或扩容操作 | □ |
| 恢复 | 确认 Error Budget 消耗速率恢复正常 | □ |
| 复盘 | 组织复盘会议，记录 Action Items | □ |
| 复盘 | 更新 SLO 台账与告警规则 | □ |
重要提醒：排查流程不是死板的线性步骤。在实际故障中，定位与恢复可能并行进行。例如，在定位根因的同时，可以先执行限流操作来减缓 Error Budget 消耗速度。