故障应急规范

故障应急规范

故障分级、应急响应、事后复盘（Postmortem）

---

故障分级

分级标准

[Requirement] 故障按影响范围和严重程度分为 P0-P3 四级：

级别	名称	判定标准	响应时间
P0	致命	核心功能完全不可用，影响大面积用户，或造成数据丢失/安全事故	立即（5 分钟内）
P1	严重	核心功能部分不可用，或非核心功能完全不可用，影响较多用户	15 分钟内
P2	一般	非核心功能异常，有临时规避方案，影响少量用户	1 小时内
P3	轻微	不影响功能使用的 UI/体验问题，或极少数用户遇到	4 小时内

分级示例

场景	级别
全站无法访问	P0
支付/下单功能不可用	P0
用户无法登录	P0
搜索功能不可用	P1
订单详情加载缓慢（>5s）	P1
消息推送延迟	P2
个人头像上传失败	P2
页面文案错别字	P3
按钮颜色显示异常	P3

影响面评估

[Standard] 故障定级需综合评估以下维度：

维度	评估项
影响用户数	受影响用户占比
影响功能	核心功能 vs 非核心功能
影响时长	已持续时间 + 预计恢复时间
数据影响	是否有数据丢失/损坏
安全影响	是否涉及数据泄露/安全漏洞
业务损失	直接经济损失、品牌影响

---

应急响应

响应流程

[Requirement] P0/P1 故障必须按以下流程响应：

发现故障 → 1.定级通告 → 2.组建应急小组 → 3.止损恢复 → 4.根因分析 → 5.故障解除 → 6.复盘

时间线要求

阶段	时间要求	责任人
发现告警	自动通知	监控系统
确认定级	5 分钟内	值班工程师
通告全员	10 分钟内	值班工程师
止损（回滚/降级）	30 分钟内	应急小组
恢复服务	P0 ≤ 1 小时，P1 ≤ 2 小时	应急小组
根因初步分析	恢复后 2 小时内	应急小组
复盘报告	3 个工作日内	故障负责人

止损优先

[Requirement] 应急响应的首要目标是恢复服务，而非定位根因。按以下优先级止损：

1. 回滚：回滚到上一稳定版本（最快）
2. 降级：关闭非核心功能，保障核心功能可用
3. 扩容：增加实例应对流量突增
4. 限流：对非核心接口限流
5. 切换：切换到备用集群/可用区

[Caution] 禁止在未止损的情况下花费大量时间定位根因，导致故障影响面扩大。

应急小组

[Standard] P0/P1 故障必须组建应急小组，角色分工明确：

角色	职责
指挥（IC）	统一决策，协调资源，对外沟通
技术负责人	技术方案、止损操作
运维	基础设施、部署操作
沟通负责人	对内通告、对外公告
记录员	记录时间线、操作日志

操作纪律

[Standard] 应急期间必须遵守：

• 所有变更操作必须经指挥同意，禁止多人同时操作
• 重大操作（回滚、重启、删数据）必须双人确认
• 所有操作必须记录，事后可追溯
• 禁止在生产环境直接执行未经验证的修复

---

沟通机制

对内沟通

[Requirement] P0/P1 故障必须在专属应急群实时同步进展，同步频率：

阶段	同步频率	内容
故障发生	立即	故障现象、影响范围、定级
止损过程	每 15 分钟	当前进展、下一步计划
恢复后	立即	恢复时间、初步原因、后续安排

[Standard] 使用固定模板通告，信息清晰：

【故障通告】
级别：P0
时间：2024-01-15 14:23
现象：用户无法登录，返回 500
影响：全量用户
当前状态：已回滚到上一版本，验证中
预计恢复：14:40
负责人：张三

对外沟通

[Standard] P0 故障需向用户公告，公告渠道：

渠道	适用场景
App 弹窗/公告	大面积影响
官网状态页	所有 P0/P1 故障
短信/邮件通知	影响付费用户
客服话术	统一口径

[Caution] 对外公告必须经指挥和产品负责人审核，措辞准确，不夸大不隐瞒。

沟通禁忌

• ❌ 故障期间在公开渠道讨论技术细节
• ❌ 多人对外发布不一致的信息
• ❌ 承诺无法兑现的恢复时间
• ❌ 互相指责、推卸责任

---

事后复盘

复盘原则

[Requirement] 所有 P0/P1 故障必须在 3 个工作日内完成复盘（Postmortem），P2 故障选择性复盘。

[Standard] 复盘遵循 Blameless（无指责） 原则，聚焦于改进系统和流程，而非追究个人责任。

复盘报告结构

[Requirement] 复盘报告必须包含以下内容：

1. 故障概述
   - 故障级别、发生时间、恢复时间、影响范围
2. 故障时间线
   - 精确到分钟的关键事件时间线
3. 根因分析
   - 直接原因、根本原因（5 Whys）
4. 止损过程
   - 采取了哪些措施、效果如何
5. 改进措施
   - 短期措施（1 周内）、中期措施（1 月内）、长期措施（3 月内）
6. 经验教训
   - 本次故障的经验总结

5 Whys 根因分析

[Standard] 使用 5 Whys 方法挖掘根本原因，避免只解决表面问题。

示例：

问题：服务响应超时
Why 1：数据库查询慢
Why 2：慢 SQL 没有索引
Why 3：新上线的查询功能没有走索引
Why 4：Code Review 时没有关注 SQL 性能
Why 5：没有 SQL 性能检查的自动化门禁
根本原因：缺少 SQL 性能自动化检查机制
改进措施：在 CI 中加入 SQL 执行计划检查

复盘会议

[Standard] P0 故障必须召开复盘会议，参会人员：故障应急小组成员、相关模块研发、技术负责人。

[Caution] 复盘会议禁止人身攻击，讨论焦点是”系统如何改进”而非”谁犯了错”。

---

改进跟踪

改进项管理

[Requirement] 复盘产出的改进措施必须转化为可跟踪的任务项（Jira/Issue），明确责任人和完成时间。

改进项	责任人	优先级	计划完成	状态
CI 加入 SQL 性能检查	张三	高	2024-02-01	进行中
增加慢查询告警	李四	中	2024-02-15	待开始
优化索引	王五	高	2024-01-25	已完成

跟踪机制

[Standard] 改进项跟踪要求：

• 每周回顾改进项进展，未按期完成需说明原因
• 改进项完成后必须验证效果（如：告警是否生效）
• 改进项关闭需经技术负责人确认
• 复盘报告和改进项归档保存，便于后续查阅

复盘文化

[Suggestion] 定期组织”故障复盘分享会”，将典型故障的经验教训在团队内分享，避免同类问题重复发生。

反模式

• ❌ 复盘报告只写”操作失误”，不深入分析系统原因。
• ❌ 改进项只列不做，无人跟踪。
• ❌ 复盘变成批斗会，打击团队士气。
• ❌ 同类故障反复发生，说明改进措施未落地。