生产事故响应手册

使用方式

事故发生时，先控制影响，再定位根因。本手册适用于 P0/P1 级生产事故，也可用于重大变更失败和安全事件。按“发现 → 分级 → 组织 → 止血 → 恢复 → 复盘”执行。

提前指定 incident commander（IC）、沟通负责人和记录人；不要让一个人同时做所有事。

检查清单

1. 发现与确认

• 确认告警真实，排除监控误报。
• 确认影响面：用户、核心链路、收入、数据。
• 记录首次发现时间和当前状态。
• 拉起事故频道，邀请相关服务 owner。
• 指定 IC、沟通人和记录人。

2. 分级与通知

• P0：核心业务不可用或数据丢失风险。
• P1：核心功能严重降级或大面积影响。
• P2：部分用户/功能受影响，有绕行方案。
• P3：轻微影响，可常规处理。
• 按级别通知业务、管理层和客户支持。

3. 止血

• 优先回滚最近变更。
• 切流、扩容、降级、限流、熔断。
• 冻结相关发布和配置变更。
• 不可逆操作（删库、格式化、强制重启）二次确认。
• 记录每个动作的时间和结果。

4. 定位

• 从指标、日志、trace、事件和变更记录交叉验证。
• 按依赖链从入口向下游排查。
• 区分“症状”和“根因”，避免过早下结论。
• 保留现场，必要时抓包、保存日志和堆栈。
• 不确定时先做可逆的缓解，不要赌。

5. 恢复

• 核心指标回到基线，错误率和延迟可接受。
• 数据一致性校验完成。
• 积压消息、队列和任务逐步消化。
• 解除限流/降级，观察是否反弹。
• 通知相关方恢复状态和后续安排。

6. 沟通

• 统一频道，固定更新时间。
• 对外信息由沟通人发布，工程同学专注处理。
• 不猜测根因，不承诺未验证的恢复时间。
• 状态页/客户通知使用模板。
• 事故结束后发布简明总结。

7. 复盘

• 24–72 小时内完成无责复盘。
• 时间线精确到分钟，包含关键决策。
• 根因分析到可行动的层面。
• 改进项有 owner、截止时间和验收标准。
• 更新 runbook、监控、告警和演练计划。

常见误区

• 事故一开始就追根因，影响面持续扩大。
• 没有 IC，多人同时操作互相覆盖。
• 沟通信息不一致，客户支持无法对外答复。
• 只回滚应用，忽略数据库迁移和配置变更。
• 恢复后立即解散，没有观察反弹。
• 复盘变成追责，真正风险被隐藏。

相关条目

• sre-oncall-checklist、k8s-production-checklist
• observability-roadmap、linux-performance-triage
• prometheus、alertmanager、grafana、loki
• kubectl、journalctl、tcpdump、ss
• promql-cheatsheet、migration-readiness-checklist