3. 事故响应体系：事故分级标准、响应流程与 RTO/RPO 定义
事故响应体系是平台工程中保障服务连续性的核心防线。一个成熟的事故响应体系需要明确三个关键要素：事故分级标准（P0-P4）、标准化响应流程（检测、响应、恢复、复盘）以及可量化的恢复目标（RTO 与 RPO）。本章将逐一拆解这些要素，并给出可落地的工程实践指南。
3.1 事故分级标准（P0-P4）
事故分级是响应流程的起点。通过统一的严重性等级（Severity Level），团队可以快速判断响应优先级、资源投入和升级路径。以下是平台工程中通用的 P0-P4 分级标准：
| 等级 | 定义 | 典型场景 | 响应要求 |
|---|---|---|---|
| P0 | 核心服务完全不可用，影响所有用户或关键业务流程中断 | 数据库主库宕机、核心 API 网关 5xx 错误率 100%、支付链路中断 | 立即响应（< 5 分钟），全员投入，持续通报 |
| P1 | 核心服务严重降级，影响大量用户或关键功能不可用 | 搜索服务延迟 > 10 秒、登录模块大面积失败、核心报表延迟超过 1 小时 | 15 分钟内响应，组建专项小组，每 30 分钟同步进展 |
| P2 | 非核心服务不可用或核心服务部分功能降级，影响有限用户 | 后台管理页面加载缓慢、非关键通知推送延迟、单个可用区部分实例异常 | 1 小时内响应，工作时间优先处理，可安排值班人员跟进 |
| P3 | 服务正常运行，但存在潜在风险或用户体验轻微受损 | 日志告警阈值误报、非关键配置错误、文档链接失效 | 24 小时内评估，纳入迭代计划，无需紧急响应 |
| P4 | 咨询、建议或低优先级改进项 | 功能优化建议、非功能性需求、技术债务记录 | 无明确 SLA，按 backlog 优先级处理 |
incident-response-policy.md，并与告警系统（如 PagerDuty、Opsgenie）的 escalation policy 绑定。P0/P1 事故必须自动触发电话或短信通知，P2 以下可仅通过即时通讯工具通知。
3.2 事故响应流程：检测、响应、恢复、复盘
标准化的事故响应流程将无序的应急操作转化为可重复、可度量的工程活动。完整的流程包含四个阶段：检测（Detect）、响应（Respond）、恢复（Recover）、复盘（Review）。
3.2.1 检测（Detect）
检测阶段的目标是尽早发现异常。依赖的工具有：
- 指标监控：Prometheus + Grafana 对黄金信号（延迟、流量、错误、饱和度）设置动态阈值。
- 日志告警：ELK/Loki 对 ERROR 级别日志进行聚合告警。
- 端到端拨测：Synthetic monitoring 模拟用户请求，发现区域性故障。
- 用户反馈通道：内部工单系统或外部状态页（Status Page）收集异常报告。
3.2.2 响应（Respond）
响应阶段的核心是止血（Stop the Bleeding）。关键动作包括：
- 确认事故等级：根据 P0-P4 标准快速定级，必要时升级。
- 组建响应群：在即时通讯工具（如 Slack、钉钉）中创建专用事故频道，邀请相关 SRE、开发、运维人员。
- 初步诊断：查看仪表盘、日志、链路追踪，定位故障范围。
- 执行回滚或降级：如果怀疑是变更导致，优先回滚；如果无法回滚，考虑功能降级或流量切换。
3.2.3 恢复（Recover）
恢复阶段的目标是将服务恢复到正常状态。常见恢复手段：
- 扩容：快速增加实例数应对突发流量。
- 切流：将流量从故障可用区切换到健康可用区。
- 数据修复：从备份恢复数据或执行补偿事务。
- 重启/重建：重启异常进程或重建故障节点。
恢复完成后，需要在状态页更新为“已解决”，并通知所有干系人。
3.2.4 复盘（Review）
复盘阶段的目标是从事故中学习，避免同类问题再次发生。标准复盘流程：
- 时间线整理：从告警触发到恢复的完整时间线，标注关键决策点。
- 5 Whys 分析：逐层追问根本原因，直到找到可修复的工程缺陷。
- 行动项跟踪：每个根本原因对应一个可量化的行动项（Action Item），指定负责人和截止日期。
- 复盘报告：输出公开的复盘文档（Postmortem），不追责、只改进。
3.3 RTO 与 RPO 定义
RTO（Recovery Time Objective，恢复时间目标）和 RPO（Recovery Point Objective，恢复点目标）是衡量事故恢复能力的两个核心指标。它们直接决定了平台架构设计和灾备策略。
3.3.1 RTO（恢复时间目标）
RTO 是指从事故开始到服务恢复所允许的最大时间间隔。它决定了团队对恢复速度的要求：
- P0 服务：RTO 通常为 < 5 分钟，需要全自动故障转移（如多活架构）。
- P1 服务：RTO 通常为 15-30 分钟，需要半自动切换或快速人工介入。
- P2 服务：RTO 通常为 1-4 小时，允许值班人员手动恢复。
- P3/P4 服务：RTO 通常为 24 小时以上，按正常迭代节奏修复。
3.3.2 RPO（恢复点目标）
RPO 是指事故发生时允许丢失的最大数据量（以时间衡量）。它决定了数据备份和复制的策略：
- RPO = 0：零数据丢失，需要同步复制（如数据库强同步、跨可用区同步写）。
- RPO = 5 分钟：允许丢失 5 分钟数据，使用异步复制或定期快照。
- RPO = 1 小时：允许丢失 1 小时数据，每小时全量备份即可。
3.3.3 RTO 与 RPO 的权衡
| 指标 | 低值（严格） | 高值（宽松） | 成本影响 |
|---|---|---|---|
| RTO | 秒级恢复（多活、热备） | 小时级恢复（冷备、手动恢复） | 低 RTO 需要更多冗余资源和自动化投入 |
| RPO | 零数据丢失（同步复制） | 小时级数据丢失（每日备份） | 低 RPO 需要更高带宽、更复杂的复制机制 |
3.4 事故响应体系与平台工程的集成
在平台工程实践中，事故响应体系不是孤立存在的，它需要与工具链深度集成：
- 告警与分级联动：监控系统（如 Prometheus）根据阈值自动生成告警，并携带事故等级标签，直接触发 PagerDuty 的 escalation policy。
- 自动化响应：对于已知的 P0 场景（如数据库主库宕机），平台应提供一键切换或自动故障转移的 Runbook，通过 ChatOps 触发。
- 复盘数据闭环：复盘产生的行动项自动录入 Jira/Linear，并与事故 ID 关联，形成可追溯的改进链路。
- RTO/RPO 验证：定期进行混沌工程实验（如 Chaos Mesh、Gremlin），验证实际恢复时间是否满足 RTO 目标，数据恢复是否满足 RPO 目标。
通过将事故分级、响应流程和 RTO/RPO 定义固化到平台工具链中，团队可以从被动救火转向主动韧性管理，真正实现“系统自愈、流程可测、改进可追”。