故障响应指挥官实战案例
场景描述
凌晨2点告警：支付服务P99延迟从200ms飙升到5s，错误率12%，影响下单。
效果对比
15分钟定位根因，30分钟回滚恢复，MTTR 45分钟
完整对话
支付服务告警：P99 5s（基线200ms），错误率12%，影响下单流程。最近部署了v2.3.1（含新缓存策略）。帮我执行应急响应。
好的，我来帮你。首先进行第一步：故障检测与宣告： ### 第一步：故障检测与宣告 - 告警触发或用户报告——验证是真实故障还是误报 - 使用严重等级矩阵分类（SEV1-SEV4） - 在指定频道宣告故障：严重等级、影响范围、谁来指挥 - 分配角色：故障指挥官（IC）、沟通负责人、技术负责人、记录员
第一步完成了，请继续第二步：结构化响应与协调。
### 第二步：结构化响应与协调 - IC 掌控时间线和决策——"一个人喊话，一个大脑拍板" - 技术负责人使用 runbook 和可观测性工具驱动诊断 - 记录员实时记录每个操作和发现，带时间戳 - 沟通负责人按严重等级对应的频率向干系人发送更新 - 排查假设限时 15 分钟，然后转向或升级
请给我严重等级分类矩阵的输出。
### 严重等级分类矩阵 ```markdown # 故障严重等级框架 | 等级 | 名称 | 标准 | 响应时间 | 更新频率 | 升级路径 | |------|------|------|---------|---------|---------| | SEV1 | 严重 | 全面服务中断、数据丢失风险、安全事件 | < 5 分钟 | 每 15 分钟 | 立即通知 VP Eng + CTO | | SEV2 | 重大 | >25% 用户服务降级、核心功能不可用 | < 15 分钟 | 每 30 分钟 | 15 分钟内通知工程经理 | | SEV3 | 中等 | 次要功能异常、有临时解决方案 | < 1 小时 | 每 2 小时 | 下次站会通知 Team Lead | | SEV4 | 低 | 外观问题、无用户影响、技术债触发 | 下个工作日 | 每天 | Backlog 分类 |
关键产出物
- ✓影响评估
- ✓止损决策
- ✓根因分析
- ✓修复方案
- ✓事后复盘模板
使用技巧
- 💡先明确目标和约束条件
- 💡分步骤执行，不要跳过关键环节
- 💡输出结果后进行复盘和优化