📚 课程目录第2章事故响应基础

2. 事故响应基础：事故等级定义（P0-P4）、事故响应流程（检测、响应、缓解、恢复、复盘）、SRE与事故响应

在平台工程架构下，统一且可量化的事故等级是高效响应的前提。等级划分需同时考虑影响范围与业务损失两个维度。下表为通用定义标准，各组织可依据自身业务特性调整阈值。

等级	定义	典型场景	响应要求
P0	核心服务完全不可用，影响所有用户或造成重大资损	数据库主库宕机、核心交易链路中断、全局认证服务失效	立即响应（<5分钟），持续作战直至恢复
P1	核心服务严重降级或大面积功能受损，影响大量用户	关键API超时率>50%、支付成功率骤降、核心页面白屏	15分钟内响应，优先恢复核心功能
P2	非核心服务不可用或核心服务局部异常，影响部分用户	非关键报表功能不可用、单机房部分实例异常、次要功能报错	1小时内响应，可在变更窗口内修复
P3	服务存在轻微异常或性能退化，无直接用户感知	后台任务延迟、日志采集丢失、非关键告警误报	下一个工作日处理，纳入常规排期
P4	咨询、建议或低优先级改进项	文档错误、UI文案不准确、非功能性优化请求	无明确SLA，按迭代计划处理

平台工程实践提示： 建议将事故等级定义直接编码进告警平台与事件管理系统。例如，P0/P1 告警自动触发电话与即时通讯群组强提醒，并锁定变更窗口；P2 告警仅发送至值班群组。避免“告警风暴”导致关键信息淹没。

标准的事故响应生命周期分为五个阶段。平台工程团队应通过自动化工具链串联各阶段，减少人为传递延迟。

阶段	核心动作	平台工程自动化支撑
检测	监控指标异常、日志关键字匹配、用户反馈工单	统一告警中心（多数据源聚合）、智能降噪、告警路由
响应	确认事故、初步定级、通知值班人员、创建事件单	自动化事件创建（绑定告警上下文）、值班表同步、IM机器人自动建群
缓解	执行止血操作：回滚、限流、降级、切流、重启	变更窗口锁定、一键回滚平台、配置中心动态降级开关、流量调度平台
恢复	修复根因、验证功能、逐步恢复全量流量	基础设施自愈流水线、灰度发布平台、数据库闪回工具
复盘	5 Whys 根因分析、时间线梳理、改进项跟踪	事件时间线自动聚合、ChatOps 聊天记录导出、改进项关联Jira/Backlog

常见误区： 许多团队在“缓解”阶段花费过多时间尝试定位根因，导致MTTR（平均修复时间）过长。正确的做法是：先止血，后验尸。例如，面对慢SQL导致的数据库负载过高，应优先执行限流或切流，而非立即分析慢查询日志。

SRE（站点可靠性工程）为事故响应提供了量化的方法论与工程实践。核心思想是将运维经验转化为可编程的软件系统。

错误预算（Error Budget）： 事故消耗错误预算。当预算接近耗尽时，应自动冻结所有非紧急变更，强制降低事故风险。
服务等级目标（SLO）： 事故响应优先级直接与 SLO 对齐。P0 事故通常意味着核心 SLO 被严重违反，需立即恢复。
减少人工操作（Toil Reduction）： 事故响应中的重复性操作（如重启、回滚、查日志）应通过自动化平台完成，SRE 专注于决策与改进。
事后复盘无指责文化（Blameless Postmortem）： 复盘聚焦于系统与流程缺陷，而非个人失误。平台工程团队应提供工具链，让复盘数据（时间线、操作记录、监控曲线）自动可查。

大型平台通常采用分层响应模型，避免所有事故都升级到核心 SRE 团队。

指标	定义	事故响应中的意义
MTTD	平均检测时间（Mean Time to Detect）	衡量监控与告警体系的有效性。平台工程应通过智能告警缩短 MTTD。
MTTR	平均修复时间（Mean Time to Resolve）	衡量响应与缓解效率。自动化回滚与限流平台是降低 MTTR 的关键。
MTBF	平均故障间隔（Mean Time Between Failures）	衡量系统稳定性。复盘改进项的有效性最终体现在 MTBF 的提升上。
Error Budget	错误预算消耗率	当消耗率过高时，触发变更冻结，从源头减少事故诱因。

  平台工程架构师视角： 事故响应不是纯流程问题，而是平台能力问题。一个成熟的平台应提供“事故响应即代码”的能力——将检测、升级、缓解、恢复的步骤编排为可执行的 Playbook，通过 ChatOps 或自动化引擎一键触发。SRE 团队的角色应从“救火队员”转变为“平台构建者”。