事故响应

事故时优先止血，其次定位，最后复盘。
复盘对事不对人。

1. 严重级别（参考）

级别	示例	响应期望
P0	资金错误、全站不可用、数据可能损坏	立即响应，成立临时指挥
P1	核心路径严重受损	快速响应，限定升级时间
P2	局部功能异常，有绕行	计划内修复
P3	体验问题、低风险缺陷	排期处理

项目可调整定义，但须事先约定。

2. 响应步骤

发现

• 监控、用户反馈、值班巡检
• 先记录：时间、影响范围、现象、是否仍在恶化

止血（先于完美根因）

可选动作：

• 回滚 / 关特性开关 / 切备通道
• 限流 / 熔断 / 降级文案
• 隔离故障实例

沟通

对内：

• 现状、影响、动作、下一次同步时间

对外（按约定）：

• 不沉默；暂无根因也可以同步「正在处理、影响范围、临时建议」
• 避免过早下定论

恢复与验证

• 主路径验证
• 数据/账务核对（如涉及）
• 观察期后再降级值班强度

3. 复盘（无指责）

复盘输出必须是改动项，不是人格评价。

建议结构：

1. 时间线（事实）
2. 影响
3. 根因（系统/流程/设计，可多层）
4. 已做处置
5. 改进项：负责人、到期日
6. 哪些告警该有却没有 / 哪些噪声该降

禁止：

• 复盘变批斗
• 只改当事人、不改系统

4. 告警治理

• 告警要有可执行含义（谁、做什么）
• 分级与抑制，避免「静音后漏真故障」
• 平均值可能骗人；关注分位与关键分群

5. 与发布的关系

许多事故发生在变更窗口。
发布清单见 发布与部署；日常质量见 代码与评审规范。

更多真实场景侧写，可阅读专栏中的 事故 标签文章（经验向，不替代本流程）。