线上出故障时，最怕的不是故障本身，而是"无流程、无角色、无节奏"的混乱。一套清晰的应急流程能让团队在压力下保持有序：先止损、再定位、后复盘。
应急响应的核心目标
- 止损优先：故障第一时间不是查根因，而是把影响面控制住（回滚/降级/限流），恢复业务是最高优先级。
- 同步信息：让所有干系人（值班、研发、Leader、客服/公关）在同一个信息通道上，避免重复排查与恐慌。
- 有序定位：止损完成后，再按照日志、监控、链路、DB 等证据链逐步收敛根因。
- 复盘闭环：故障结束后必须复盘，产出可执行的改进项，避免同类问题再次发生。
发现与定级
故障来源一般有三类：监控告警（主动发现）、用户反馈/客服工单（被动发现）、巡检/容量报告（提前预警）。
收到故障信息后，先做两件事：确认影响面（哪些接口/功能/用户受影响）和故障定级。
| 级别 | 定义 | 响应要求 | 举例 |
|---|---|---|---|
| P0 | 核心业务完全不可用，或造成资金/数据损失 | 立即响应，全员投入 | 支付全挂、订单库不可写 |
| P1 | 核心业务部分受损，有严重降级 | 15 分钟内响应 | 下单延迟、核心接口超时 |
| P2 | 非核心功能受损，有替代方案 | 当天修复 | 营销活动页 404 |
| P3 | 轻微瑕疵，不影响使用 | 排期修复 | 文案错误、样式问题 |
应急止损
定级后马上进入止损，不要等根因确认。止损手段按影响从小到大排列：
- 快速回滚：最近一次发布/配置变更导致时，立即回滚到上一稳定版本，并暂停继续发布。
- 功能降级：关闭非核心功能（缓存、推荐、风控等），把资源让给核心链路。
- 限流 / 熔断 / 隔离：对流量入口限流，对依赖服务熔断，必要时把故障实例从流量摘除。
止损完成后业务恢复，应急流程转入定位阶段；若止损无效，继续尝试其他止损手段或升级事件。
定位根因与恢复
止损之后有喘息空间，开始系统化定位。推荐按"证据链"排查，而不是瞎猜：
- 先看监控大盘：CPU/内存/磁盘/网络、QPS/RT/错误率，确认是资源问题还是业务问题。
- 再看日志：应用错误日志、GC 日志、慢查询日志，找出报错模式和堆栈。
- 链路追踪：跨服务调用时用 Trace 定位瓶颈点或异常节点。
- 数据库：慢 SQL、锁等待、连接池耗尽、主从延迟。
- 发布/变更记录：比对最近一次变更时间点与故障开始时间是否吻合。
定位到根因后修复问题，修复后先灰度验证再全量恢复，避免二次故障。
事后复盘与闭环
业务恢复不代表结束，复盘让故障变成团队资产：
- 梳理时间线：什么时候告警、什么时候响应、每步操作耗时，找出可压缩的环节。
- 定位根因：区分直接原因与深层原因（用 5 Whys 追问"为什么"）。
- 明确责任：复盘不是为了追责，而是分清系统设计与流程上的缺口。
- 产出改进项：每条改进项必须有 owner 和 deadline，跟进到闭环（监控补全、演练、代码修复、文档沉淀）。
角色与职责
| 角色 | 职责 |
|---|---|
| 值班 On-call | 第一时间响应、确认故障、按流程处置 |
| 应急指挥 | 统筹全局、决策止损手段、对外同步信息 |
| 研发/运维 | 定位根因、实施修复 |
| 消息同步者 | 在 IM 群/战报中同步状态，避免被反复询问 |
关键原则
- 信息要同步，而不是堆积在个人脑中：故障群里持续更新进展，恢复后整理成简报。
- 避免单人单点：哪怕只有一个人在排查，也要有人旁观确认操作，防止误操作扩大故障。
- 操作留痕：所有变更操作记录到群里或工单，便于复盘时还原时间线。
- 复盘不追责：流程问题大于个人问题，只有放下追责文化，真实根因才会浮出水面。