3. 事故响应基础：事故的定义、事故与问题的区别、事故响应流程
3.1 事故的定义
在IT运维领域，事故（Incident）是指对IT服务的计划外中断或服务质量下降。事故的核心特征是“对用户或业务产生了实际影响”。一个服务虽然内部报错，但只要用户无感知、业务指标未下降，通常不定义为事故，而是作为告警（Alert）或事件（Event）处理。
事故判定三要素：
- 计划外：非变更窗口内的预定操作。
- 中断或降级：服务不可用、响应超时、功能异常、数据错误。
- 用户/业务影响：有真实用户反馈、收入损失、SLA违约风险。
3.2 事故与问题的区别
事故和问题是ITIL框架中的两个核心概念，经常被混淆。事故是“症状”，问题是“病因”。一次事故可能由多个问题引发，一个问题也可能导致多次事故。
| 对比维度 | 事故（Incident） | 问题（Problem） |
|---|---|---|
| 定义 | 服务的计划外中断或质量下降 | 一个或多个事故的根本原因 |
| 目标 | 尽快恢复服务，减少影响 | 定位根因，永久消除或降低复发概率 |
| 时间压力 | 极高（分钟级响应） | 中等（通常在事故恢复后启动） |
| 典型动作 | 回滚、重启、切流、降级 | 代码审查、日志分析、压测复现、架构改造 |
| 生命周期 | 从检测到恢复即结束 | 从创建到已知错误关闭，可能持续数周 |
| 关联关系 | 一个问题可能关联多个事故 | 一个事故可能由多个问题叠加导致 |
实战口诀：事故响应时“先止血，后查因”。不要在事故窗口内试图彻底解决一个复杂问题，那会延长MTTR（平均恢复时间）。先通过回滚或切流恢复服务，再创建问题单进行根因分析。
3.3 事故响应流程
标准的事故响应流程分为四个阶段：检测 → 响应 → 恢复 → 复盘。每个阶段都有明确的输入、输出和关键动作。
3.3.1 检测（Detection）
检测阶段的目标是“尽早发现，避免用户报修”。依赖监控系统、告警规则、日志平台和用户反馈渠道。
- 监控指标：延迟（Latency）、流量（Traffic）、错误（Errors）、饱和度（Saturation）——即USE/RED方法论。
- 告警分级：P0（核心服务中断）、P1（主要功能降级）、P2（非关键功能异常）、P3（咨询/通知）。
- 检测手段：主动拨测、APM（应用性能管理）、基础设施监控、日志关键字告警。
3.3.2 响应（Response）
响应阶段的核心是“确认事故、召集人员、启动流程”。响应速度直接影响MTTR。
- 事故确认：值班人员收到告警后，确认是否为真实事故，排除误报。
- 升级机制：若5分钟内无法定位或恢复，升级至二级响应团队；若涉及跨团队，升级至事故指挥官（Incident Commander）。
- 信息同步：在事故协同群（如Slack/钉钉）中建立时间线，记录每一步操作和观察。
常见误区：响应阶段不要立即开始深度排查。先做“影响评估”：影响多少用户？是否涉及资金/数据？是否需要通知管理层？评估完成后，再决定恢复策略。
3.3.3 恢复（Recovery）
恢复阶段的目标是“以最快速度消除业务影响”，而非找到根因。恢复手段按风险从低到高排列：
- 回滚：将变更回退到上一个稳定版本（最推荐，风险最低）。
- 切流：将流量切换到备用集群或可用区。
- 重启/扩容：重启进程或临时扩容资源。
- 降级：关闭非核心功能，保证核心链路可用。
- 热修复：紧急发布补丁（仅当以上手段均不可行时）。
3.3.4 复盘（Review）
复盘阶段的目标是“从事故中学习，避免重复发生”。复盘不是追责，而是改进流程和技术。
- 时间线整理：从检测到恢复的完整时间线，标注每个关键节点。
- 根因分析（RCA）：使用5Why法或因果图，找到根本原因。
- 行动项：列出改进措施，明确负责人和截止日期。
- 知识沉淀：将事故处理过程写入Runbook，更新故障定位手册。
3.4 事故响应流程中的关键角色
为了保障流程高效运转，需要明确角色分工。以下是标准的事故响应角色矩阵：
| 角色 | 职责 | 典型人员 |
|---|---|---|
| 事故指挥官（IC） | 统筹全局，决策恢复策略，对外沟通 | 资深SRE / 运维负责人 |
| 一线响应者 | 接收告警，初步排查，执行恢复操作 | 值班运维 / 初级SRE |
| 二线专家 | 深度排查，提供技术方案 | 中间件/数据库/网络专家 |
| 沟通联络员 | 同步事故进展，维护时间线，通知管理层 | 技术项目经理 / 运维BP |
| 记录员 | 记录所有操作、观察、决策，为复盘提供素材 | 轮值人员 / 实习生 |
最佳实践：在变更窗口期间，建议提前指定“变更守护者”（Change Guardian），该角色不参与变更操作，专职监控变更后的指标，一旦发现异常立即触发事故响应流程，实现“变更与响应无缝衔接”。
3.5 变更窗口与事故响应的衔接
在变更窗口内，事故响应流程需要做特殊适配：
- 变更前：准备好回滚方案、切流预案、监控看板。
- 变更中：执行变更时，事故响应团队“待命”，不参与其他工作。
- 变更后：观察期（通常15-30分钟）内，若触发P0/P1告警，直接进入事故响应流程，默认恢复手段为“回滚变更”。
变更窗口事故响应黄金法则：
- 变更后5分钟内未出现异常，视为变更成功。
- 变更后5-15分钟内出现异常，优先回滚，再排查原因。
- 变更后15分钟以上出现异常，按常规事故流程处理，不默认回滚（可能为延迟问题）。