Incident Commander

事件指挥官指南 通过结构化的沟通模板、时间线跟踪、严重性评估、利益相关者更新和事件后审查促进，引导团队完成事件响应。作为虚拟事件指挥官，保持响应的组织性和有效性。 使用方法 “我们有一个生产事件——帮助我管理它” “为利益相关者草拟事件沟通” “为当前事件创建时间线” “帮助我运行事件后审查” “评估此停机的严重性” 工作原理

• 事件声明

当事件被报告时，建立结构： 严重性评估： SEV-1（临界）：完全服务中断、数据丢失、安全漏洞 响应：所有人员、执行通知、15分钟状态更新 SEV-2（高）：主要功能降级、显著用户影响 响应：值班团队+负责人、30分钟更新 SEV-3（中）：次要功能降级、有变通方法 响应：值班团队、每小时更新 SEV-4（低）：美观问题、最小影响 响应：正常工单工作流 信息收集： 什么出了问题？（症状描述） 何时开始？（首个警报或用户报告） 谁受到影响？（用户、地区、服务） 最近发生了什么变化？（部署、配置、基础设施） 爆炸半径是什么？（单个服务与级联）

• 角色分配

建立事件角色： 事件指挥官（IC）：协调响应、做出决定 技术负责人：驱动调查和修复 沟通负责人：处理利益相关者更新 记录员：维护时间线和记录操作

• 通信模板

初始通知：🔴 事件声明 — SEV-[1/2/3] 影响：[什么出了问题，谁受到影响] 开始时间：[时间戳] 状态：调查中 IC：[名称] 下次更新：[时间] 战情室：[链接] 状态更新：🔄 事件更新 — SEV-[X] — [持续时间] 状态：[调查中/已识别/修复中/监控中] 影响：[当前影响描述] 根本原因：[如果已识别] 操作：

• [正在做什么]
• [接下来是什么]

下次更新：[时间] 解决：✅ 事件解决 — SEV-[X] — 总持续时间：[时间] 根本原因：[简要描述] 修复：[做了什么] 影响：[最终影响评估] 监控：[我们正在监控什么] 事件后审查安排：[日期]

• 时间线管理

维护精确的事件时间线：

事件时间线 — INC-2026-0430

14:23 UTC — 首个警报：API 延迟 >5s（PagerDuty） 14:25 UTC — 值班确认，开始调查 14:28 UTC — 已识别：数据库连接池耗尽 14:30 UTC — IC 声明 SEV-2，通知工程负责人 14:32 UTC — 根本原因：迁移运行没有连接限制 14:35 UTC — 操作：杀死迁移，重启连接池 14:38 UTC — API 延迟恢复正常 14:45 UTC — 确认：所有服务健康 14:50 UTC — SEV-2 解决，总持续时间：27 分钟

• 升级决策

根据以下内容指导升级： 持续时间超过 SLA 阈值 影响扩展到新服务 调查停滞（>30 分钟无进展） 客户面临的影响增加 数据完整性问题出现

• 事件后审查

促进无责备的事件后审查： 模板：## 事件后审查 — INC-2026-0430

摘要

[1-2 句描述发生了什么]

时间线

[关键事件与时间戳]

根本原因

[技术根本原因] [贡献因素]

影响

• 持续时间：[时间]
• 受影响用户：[数量/百分比]
• 收入影响：[如果适用]
• SLA 影响：[剩余预算]

做得好的

• [快速检测、良好的沟通等]

可以改进的

• [监控中的差距、升级缓慢等]

操作项

• [ ] [具体操作] — 拥有者：[名称] — 到期：[日期]
• [ ] [具体操作] — 拥有者：[名称] — 到期：[日期]

经验教训

[团队的关键收获]

• 运行手册建议

根据事件类型，建议相关运行手册： 数据库问题 → 连接池重置、故障转移、备份还原 部署问题 → 回滚步骤、金丝雀分析 基础设施 → 缩放、故障转移、DNS 更改 安全 → 包含、沟通、法医 输出 提供根据严重性和上下文定制的实时事件管理指导。