Incident Response — 应急响应
Goal
Trigger
见 description 中的触发时机
见 ## Workflow
结构化事故处理流程,从发现到复盘全链路支持。
Workflow
- 发现告警 — 监控系统触发或用户报告
- 评估定级 — P0/P1/P2/P3,确定影响范围
- 应急处置 — 止血、回滚、降级、限流
- 根因分析 — 5 Whys、时间线重建
- 复盘改进 — 输出 RCA 报告、行动项
事故分级
| 级别 | 影响 | 响应时间 | 示例 |
|---|---|---|---|
| P0 | 全站不可用 | 5 分钟 | 数据库宕机、核心服务崩溃 |
| P1 | 核心功能受损 | 15 分钟 | 支付失败、登录异常 |
| P2 | 非核心功能受损 | 1 小时 | 搜索异常、推荐失效 |
| P3 | 体验问题 | 下个工作日 | 页面样式错误、延迟偏高 |
应急处置 Checklist
□ 确认影响范围(哪些用户、哪些功能)
□ 通知相关方(团队、用户、领导)
□ 止血措施(回滚 / 降级 / 限流 / 关闭功能)
□ 恢复服务(修复或绕过)
□ 验证恢复(监控指标、用户反馈)
□ 保留现场(日志、截图、时间线)
RCA 报告模板
# 事故复盘报告
## Goal
## Trigger
见 description 中的触发时机
见 ## Workflow
## 基本信息
- 事故时间: YYYY-MM-DD HH:MM ~ HH:MM
- 影响范围: XX 用户 / XX 功能
- 事故级别: P0/P1/P2/P3
- 处理人: XXX
## 时间线
| 时间 | 事件 |
|------|------|
| HH:MM | 告警触发 |
| HH:MM | 开始排查 |
| HH:MM | 定位原因 |
| HH:MM | 执行修复 |
| HH:MM | 服务恢复 |
## 根因分析 (5 Whys)
1. Why: 服务返回 500
2. Why: 数据库连接池耗尽
3. Why: 慢查询未优化
4. Why: 新上线的接口缺少索引
5. Why: Code Review 未检查 SQL 性能
## 行动项
| 优先级 | 行动 | 负责人 | 截止日期 |
|--------|------|--------|----------|
| P0 | 添加缺失索引 | 张三 | 今天 |
| P1 | 优化慢查询 | 李四 | 本周 |
| P2 | 增加 SQL Review | 王五 | 下周 |
Example
用户: 支付服务出现 P1 故障,支付成功率从 99.9% 降到 85%
输出:
1. 确认影响: 约 15% 支付失败,影响所有渠道
2. 止血: 回滚到上一版本 (v2.3.1)
3. 时间线: 14:00 告警 → 14:05 开始排查 → 14:15 回滚 → 14:20 恢复
4. 根因: v2.4.0 引入的超时配置错误
5. 行动项: 修复超时配置 + 增加支付集成测试