4. 故障事件生命周期：故障发现、故障上报、故障定位、故障恢复、故障复盘

在运行时流水线中，故障事件并非孤立瞬间，而是一个完整的生命周期。SRE 团队需要将故障视为可管理、可度量的流程，而非不可控的突发事件。标准化的生命周期模型能够帮助团队在高压下保持操作一致性，并为后续的 Sandbox 准入核验提供关键输入。

故障事件生命周期通常划分为五个核心阶段：故障发现 → 故障上报 → 故障定位 → 故障恢复 → 故障复盘。每个阶段都有明确的输入、输出、责任角色和关键指标。

4.1 生命周期全景视图

下图展示了故障事件在运行时流水线中的完整流转路径，以及各阶段之间的数据传递关系。

4.2 各阶段深度解析

4.2.1 故障发现

故障发现是生命周期的起点，目标是尽可能缩短 MTTD。在运行时流水线中，故障发现依赖多层监控体系：基础设施层（CPU/内存/磁盘）、应用层（请求延迟/错误率/吞吐量）、业务层（订单成功率/用户登录率）。

• 主动发现：Prometheus + Alertmanager 规则触发、Grafana 看板异常检测、Synthetic 拨测。
• 被动发现：用户反馈、客服工单、上游服务调用超时回传。
• Sandbox 关联：Sandbox 准入核验失败本身也是一种故障发现——它发现的是“不符合安全基线的部署行为”。

4.2.2 故障上报

故障上报将原始告警转化为可追踪的事件。上报质量直接影响后续定位和恢复效率。

4.2.3 故障定位

定位阶段的目标是找到根因（Root Cause）。在云原生架构中，故障定位通常采用“分层排除法”：

1. 确认故障现象：从监控看板确认异常指标的具体数值和时间窗口。
2. 隔离范围：通过调用链追踪（Distributed Tracing）确定故障发生在哪个服务、哪个实例。
3. 假设验证：基于经验或已知问题列表提出假设，通过日志、事件、指标验证。
4. 根因确认：定位到具体代码变更、配置变更、基础设施故障或 Sandbox 准入规则误判。

定位阶段的效率通常用 MTTK（Mean Time to Know） 衡量，即从故障上报到确认根因的平均时间。

4.2.4 故障恢复

恢复阶段的核心原则是先止血，后根治。恢复操作必须可执行、可回滚、可审计。

4.2.5 故障复盘

复盘不是追责，而是系统改进。标准复盘流程包括：

• 时间线梳理：精确到秒级的事件时间轴，标注每个阶段耗时。
• 5Whys 分析：连续追问“为什么”，穿透表象找到系统性根因。
• Action Items 生成：每个 Action 必须有负责人、截止日期、验收标准。
• Sandbox 准入规则更新：如果故障本可以通过准入核验避免，则必须更新 Sandbox 规则库。

4.3 生命周期与 Sandbox 准入核验的融合

在运行时流水线中，故障事件生命周期不是孤立的流程，它与 Sandbox 准入核验形成双向数据通道：

4.4 生命周期各阶段关键指标