现场指挥官

incident-commander
分类数据
作者Alireza Rezvani
许可MIT
评分4.70/5
使用11.7K

Incident Commander 技能

类别： 工程团队
等级： POWERFUL
作者： Claude Skills Team
版本： 1.0.0
最后更新： 2026年2月

概述

针对可用性/可靠性事件（停机、性能下降、部署失败）的事件响应框架：涵盖严重程度分级、时间线重建和事后回顾。

这并非安全事件分诊。 对于安全事件（勒索软件、入侵、数据外泄、IOC 分析、NIST SP 800-61 取证），请路由至 incident-response。两种技能均使用 SEV1-SEV4 标签；本技能侧重于评估运维影响（用户、营收、SLA），而 incident-response 则侧重于攻击类型和取证处理。

核心特性

  • 自动化严重程度分级 - 基于影响力和紧急度指标的智能事件分诊
  • 时间线重建 - 将分散的日志和事件转化为连贯的事件叙述
  • 事后回顾生成 - 结合多种 RCA 框架的结构化 PIR 报告
  • 沟通模板 - 预设的利益相关者更新和升级通知模板
  • Runbook 集成 - 根据事件模式生成可操作的 Runbook

包含的技能

核心工具

1. 事件分类器 (incident_classifier.py)
- 分析事件描述并输出严重程度等级
- 推荐响应团队和初步行动
- 根据严重程度生成沟通模板

2. 时间线重建器 (timeline_reconstructor.py)
- 处理来自多个来源的带时间戳事件
- 重建按时间顺序排列的事件时间线
- 识别时间缺口并提供时长分析

3. PIR 生成器 (pir_generator.py)
- 创建全面的事后回顾 (Post-Incident Review) 文档
- 应用多种 RCA 框架（5 Whys、鱼骨图、时间线法）
- 生成可执行的后续跟进事项

事件响应框架

严重程度分级系统

#### SEV1 - 关键停机 (Critical Outage)
定义： 影响所有用户或关键业务功能的完全服务失效

特征：

  • 面向客户的服务完全不可用

  • 影响用户的数据丢失或损坏

  • 导致客户数据泄露的安全漏洞

  • 营收系统宕机

  • 违反 SLA 并导致经济处罚

响应要求：

  • 立即升级至 On-call 工程师

  • 5 分钟内指派 Incident Commander

  • 15 分钟内通知高管

  • 15 分钟内更新公开状态页

  • 建立作战室 (War room)

  • 必要时全员投入

沟通频率： 每 15 分钟一次，直到解决

#### SEV2 - 重大影响 (Major Impact)
定义： 影响部分用户或非关键功能的显著性能下降

特征：

  • 部分服务降级（影响超过 25% 的用户）

  • 导致用户不满的性能问题

  • 非关键功能不可用

  • 影响生产力的内部工具故障

  • 不影响用户体验的数据不一致

响应要求：

  • On-call 工程师在...内响应

15 分钟
  • 30 分钟内指派事件指挥官 (Incident Commander)

  • 30 分钟内更新状态页

  • 1 小时内通知利益相关者

  • 定期向团队更新进度

沟通频率： 响应期间每 30 分钟一次

#### SEV3 - 轻微影响
定义： 影响范围有限且有替代方案

特征：

  • 仅单个功能或组件受影响

  • 受影响用户 <25%

  • 存在替代方案

  • 性能下降但未显著影响用户体验 (UX)

  • 非紧急的监控告警

响应要求：

  • 工作时间内 2 小时内响应

  • 非工作时间可在下一个工作日响应

  • 通知内部团队

  • 可选更新状态页

沟通频率： 仅在关键里程碑时更新

#### SEV4 - 低影响
定义： 影响极小、界面问题或计划内维护

特征：

  • 界面/视觉 Bug

  • 文档问题

  • 日志或监控缺失

  • 无用户影响的性能问题

  • 开发/测试环境问题

响应要求：

  • 1-2 个工作日内响应

  • 通过标准工单/问题追踪系统处理

  • 无需特殊升级流程

沟通频率： 遵循标准开发周期更新

事件指挥官 (Incident Commander) 角色

#### 主要职责

1. 指挥与控制
- 主导事件响应流程
- 做出资源分配的关键决策
- 协调技术团队与利益相关者
- 掌控所有响应环节的整体情况

2. 沟通枢纽
- 定期向利益相关者提供更新
- 管理外部沟通（状态页、客户通知）
- 促进响应团队之间的高效沟通
- 屏蔽外部干扰，确保响应人员专注

3. 流程管理
- 确保事件追踪和文档记录完整
- 在保证质量的前提下推动问题解决
- 协调团队成员之间的交接
- 计划并执行回滚策略（如需要）

4. 事后领导
- 确保开展彻底的事后回顾 (Post-incident Review)
- 推动预防措施的落地
- 在组织内部共享经验教训

#### 决策框架

紧急决策 (SEV1/2)：

  • 事件指挥官拥有最高权限

  • 行动优先于分析

  • 记录决策过程以便后续回顾

  • 咨询领域专家 (SME)，但不能被其阻塞进度

资源分配：

  • 可调动任何必要的团队成员

  • 有权向高级管理层升级汇报

  • 可批准外部资源的紧急支出

  • 决定沟通渠道和时间点

技术决策：

  • 实现细节依赖技术负责人 (Technical Lead)

  • 在速度与风险的权衡中做出最终决定

  • 决定采取回滚还是前向修复 (Fix-forward) 策略

  • 协调测试与验证方案

沟通模板

#### 初始事件通知 (SEV1/2)

code
主题: [SEV{severity}] {服务名称} - {简短描述}

事件详情:
  • 开始时间: {timestamp}

  • 严重级别: SEV{level}

  • 影响范围: {用户影响描述}

  • 当前状态: {调查中/缓解中/已解决}


技术详情:
  • 受影响服务: {服务列表}

  • 现象: {用户经历的具体问题}

  • 初步评估: {已知疑似根因}


响应团队:
  • 事件指挥官: {姓名}

  • 技术负责人: {姓名}

  • 已介入专家: {列表}


下次更新时间: {timestamp}
状态页: {链接}
作战室 (War Room): {会议/聊天链接}


---

{事故指挥官姓名}
{联系方式}
code
#### 执行摘要 (SEV1)

主题：紧急 - 影响客户的停机故障 - {服务名称}

执行摘要：
{用 2-3 句话描述对客户的影响及业务影响}

关键指标：

  • 检测耗时 (TTD)：{X 分钟}

  • 响应耗时 (TTE)：{X 分钟}

  • 预计受影响客户数：{数量/百分比}

  • 当前状态：{状态}

  • 预计恢复时间 (ETA)：{时间 或 "调查中"}

需要领导层采取的行动：

  • [ ] 客户沟通方案审批

  • [ ] 公关/传播协调

  • [ ] 资源分配决策

  • [ ] 外部供应商对接

事故指挥官：{姓名} ({联系方式})
下次更新时间：{时间}

---
此邮件由事故响应系统自动发送。

code
#### 客户沟通模板

我们目前正经历 {问题的简短描述}，影响范围为 {影响范围}。

我们的工程团队已于 {时间} 收到警报，目前正在积极修复。在问题解决前，我们将每隔 {频率} 提供一次更新。

已知情况：

  • {关于影响的事实陈述}

  • {关于范围的事实陈述}

  • {响应状态的简短陈述}

采取的措施：

  • {主要响应行动}

  • {次要响应行动}

临时解决方案（如有）：
{解决方案步骤 或 "目前暂无临时解决方案"}

对于给您带来的不便，我们深表歉意。一旦有更多信息，我们将立即分享。

下次更新时间：{时间}
状态页：{链接}

code
### 利益相关者管理


#### 利益相关者分类


内部利益相关者：
  • 工程领导层 - 技术决策与资源分配

  • 产品管理 - 客户影响评估与功能影响分析

  • 客户支持 - 用户沟通与支持工单管理

  • 销售/客户经理 - 企业级客户的关系管理

  • 执行团队 - 业务影响决策与外部沟通审批

  • 法务/合规 - 监管报告与责任评估


外部利益相关者：
  • 客户 - 服务可用性与影响沟通

  • 合作伙伴 - API 可用性与集成影响

  • 供应商 - 第三方服务依赖与支持升级

  • 监管机构 - 受监管行业的合规报告

  • 公众/媒体 - 面向公众的停机透明度


#### 不同利益相关者的沟通频率


| 利益相关者 | SEV1 | SEV2 | SEV3 | SEV4 |
|-------------|------|------|------|------|
| 工程领导层 | 实时 | 30分钟 | 4小时 | 每日 |
| 执行团队 | 15分钟 | 1小时 | 日终 | 每周 |
| 客户支持 | 实时 | 30分钟 | 2小时 | 按需 |
| 客户 | 15分钟 | 1小时 | 可选 | 无 |
| 合作伙伴 | 30分钟 | 2小时 | 可选 | 无 |


运行手册 (Runbook) 生成框架


#### 动态运行手册组件


1. 检测剧本 (Detection Playbooks)
   - 监控告警定义
   - 分诊决策树
   - 升级触发点
   - 初始响应行动


2. 响应剧本 (Response Playbooks)
   - 分步缓解流程
   - 回滚指令
   - 验证检查点
   - 沟通检查点


3. 恢复剧本 (Recovery Playbooks)
   - 服务恢复流程
   - 数据一致性检查
   - 性能验证
   - 用户通知流程


#### 运行手册模板结构
markdown

{服务/组件} 事故响应运行手册

快速参考

  • 严重程度指标： {每个严重级别对应的条件列表}
  • 关键联系人： {值班轮值表及升级路径}
code
升级路径}

  • 关键命令： {紧急命令列表及其描述}


检测


监控告警


  • {告警名称}：{描述及阈值}


  • {告警名称}：{描述及阈值}


手动检测迹象


  • {症状}：{检查内容及位置}


  • {症状}：{检查内容及位置}


初始响应 (0-15 分钟)

1. 评估严重程度
   - [ ] 检查 {主要指标}
   - [ ] 验证 {次要指标}
   - [ ] 根据 {标准} 将其分类为 SEV{级别}

2. 建立指挥体系
   - [ ] 若为 SEV1/2，通知事件指挥官 (Incident Commander)
   - [ ] 创建事件追踪工单
   - [ ] 加入作战室 (War Room)：{链接/会议信息}


3. 初步调查
   - [ ] 检查近期部署：{部署日志位置}
   - [ ] 查看错误日志：{日志位置及查询语句}
   - [ ] 验证依赖项：{依赖检查命令}


缓解策略


策略 1：{名称}

适用场景： {条件}
步骤：
1. {详细步骤及命令}
2. {详细步骤及预期结果}
3. {验证步骤}

回滚计划：
1. {回滚步骤}
2. {验证步骤}


策略 2：{名称}

{结构同上}

恢复与验证

1. 服务恢复
   - [ ] {恢复步骤}
   - [ ] 等待 {指标} 恢复正常
   - [ ] 验证端到端功能

2. 沟通通知
   - [ ] 更新状态页
   - [ ] 通知相关利益方
   - [ ] 安排事后回顾会议 (PIR)


常见陷阱


  • {陷阱}： {描述及如何避免}


  • {陷阱}： {描述及如何避免}


参考信息

→ 详情请参阅 references/reference-information.md

使用示例


示例 1：数据库连接池耗尽
bash

对事件进行分类

echo '{"description": "Users reporting 500 errors, database connections timing out", "affected_users": "80%", "business_impact": "high"}' | python scripts/incident_classifier.py

从日志重建时间线

python scripts/timeline_reconstructor.py --input assets/sample_timeline_events.json --output timeline.md

解决后生成 PIR 报告

python scripts/pir_generator.py --incident assets/sample_incident_data.json --timeline timeline.md --output pir.md
code
### 示例 2：API 限流事件
bash

从标准输入快速分类

echo "API rate limits causing customer API calls to fail" | python scripts/incident_classifier.py --format text

从多个来源构建时间线

python scripts/timeline_reconstructor.py --input assets/simple_timeline_events.json --detect-phases --gap-analysis

生成全面的 PIR 报告

python scripts/pir_generator.py --incident assets/sample_incident_pir_data.json --rca-method fishbone --action-items ```

最佳实践

事件响应期间

1. 保持冷静的领导力
- 在压力下保持沉着
- 在信息不完整的情况下果断决策
- 在承认不确定性的同时传递信心

2. 记录一切
- 记录所有采取的操作及其结果
- 记录决策依据，尤其是存在争议的决策
- 实时记录事件时间线

3. 高效沟通
- 使用清晰、无专业术语的语言
- 即使没有新进展，也要定期更新状态
- 主动管理利益方的预期

4. 技术卓越
- 在压力下，优先选择回滚而非冒险修复
- 在宣布解决前验证修复效果
- 预判二次故障和级联效应

事件结束后

1. 无责文化 (Blameless)
文化
- 关注系统失效，而非个人错误
- 鼓励诚实报告问题
- 将学习和改进视为机会

2. 待办事项执行力
- 指定明确的负责人和截止日期
- 公开跟踪进度
- 根据风险和工作量确定优先级

3. 知识共享
- 在组织内部广泛分享事后回顾 (PIR)
- 根据经验教训更新 Runbook
- 针对常见故障模式开展培训

4. 持续改进
- 分析多个事件中的共同模式
- 投入工具开发与自动化
- 定期审查并更新流程

与现有工具的集成

监控与告警

  • 集成 PagerDuty/Opsgenie 用于升级告警
  • 使用 Datadog/Grafana 进行指标监控和看板展示
  • 使用 ELK/Splunk 进行日志分析和关联

沟通平台

  • 使用 Slack/Teams 进行战时室 (War Room) 协调
  • 使用 Zoom/Meet 进行视频会议
  • 使用状态页供应商 (如 Statuspage.io 等)

文档系统

  • 使用 Confluence/Notion 存储 PIR
  • 使用 GitHub/GitLab 对 Runbook 进行版本控制
  • 使用 JIRA/Linear 跟踪待办事项

变更管理

  • 集成 CI/CD 流水线
  • 部署跟踪系统
  • 使用特性开关 (Feature Flag) 平台实现快速回滚