incident-commander

事件指挥官 Skill

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

概述

面向可用性/可靠性事件（宕机、服务降级、部署失败）的事件响应框架：严重级别划分、时间线重建和事后复盘。

这不是安全事件分诊。 对于安全事件（勒索软件、入侵、数据外泄、IOC 分析、NIST SP 800-61 取证），请转交 incident-response。两个 Skill 都使用 SEV1-SEV4 标签；本 Skill 评估运营影响（用户、收入、SLA），而 incident-response 负责划分攻击类型和取证处理。

主要功能

• 自动化严重级别划分 - 基于影响和紧急程度指标进行智能事件分诊
• 时间线重建 - 将零散的日志和事件整理为连贯的事件叙述
• 事后复盘生成 - 结合多种 RCA 框架生成结构化 PIR
• 沟通模板 - 面向利益相关方更新和升级的预置模板
• Runbook 集成 - 基于事件模式生成可执行的 Runbook

包含的 Skill

核心工具

1. 事件分类器 (incident_classifier.py)

   • 分析事件描述并输出严重级别
   • 推荐响应团队和初始行动
   • 根据严重级别生成沟通模板

2. 时间线重建器 (timeline_reconstructor.py)

   • 处理来自多个来源的带时间戳事件
   • 重建按时间顺序排列的事件时间线
   • 识别时间缺口并提供持续时间分析

3. PIR 生成器 (pir_generator.py)

   • 创建完整的事后复盘（Post-Incident Review）文档
   • 应用多种 RCA 框架（5 Whys、鱼骨图、时间线）
   • 生成可执行的后续跟进事项

事件响应框架

严重级别划分体系

SEV1 - 严重宕机

定义: 所有用户或关键业务功能的服务完全失效

特征:

• 面向客户的服务完全不可用
• 影响用户的数据丢失或损坏
• 客户数据暴露的安全漏洞
• 产生收入的系统宕机
• 造成经济赔偿的 SLA 违约

响应要求:

• 立即升级给值班工程师
• 5 分钟内指派事件指挥官
• 15 分钟内通知高管
• 15 分钟内更新公共状态页
• 建立作战室
• 必要时全员参与

沟通频率: 直至解决，每 15 分钟一次

SEV2 - 重大影响

定义: 影响部分用户或非关键功能的显著降级

特征:

• 部分服务降级（超过 25% 的用户受影响）
• 性能问题导致用户体验受挫
• 非关键功能不可用
• 内部工具影响工作效率
• 数据不一致但不影响用户体验

响应要求:

• 15 分钟内值班工程师响应
• 30 分钟内指派事件指挥官
• 30 分钟内更新状态页
• 1 小时内通知利益相关方
• 定期团队更新

沟通频率: 活跃响应期间每 30 分钟一次

SEV3 - 轻微影响

定义: 影响有限且存在替代方案

特征:

• 单个功能或组件受影响
• 受影响用户不足 25%
• 存在替代方案
• 性能下降但对用户体验影响不大
• 非紧急的监控告警

响应要求:

• 工作时间内 2 小时内响应
• 非工作时间可接受下一个工作日响应
• 通知内部团队
• 可选更新状态页

沟通频率: 仅在关键节点进行沟通

SEV4 - 低影响

定义： 影响极小、仅为外观问题或计划内维护

特征：

• 外观性缺陷
• 文档问题
• 日志或监控缺口
• 对用户无影响的性能问题
• 开发/测试环境问题

响应要求：

• 1-2 个工作日内响应
• 使用标准工单/问题跟踪
• 无需特殊升级

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

事件指挥官角色

主要职责

1. 指挥与控制

   • 负责事件响应流程
   • 就资源分配做出关键决策
   • 协调技术团队与利益相关方
   • 掌握所有响应线路的整体态势

2. 沟通枢纽

   • 定期向利益相关方提供更新
   • 管理对外沟通（状态页、客户通知）
   • 促进各响应团队之间的有效沟通
   • 使响应人员免受外部干扰

3. 流程管理

   • 确保事件跟踪与文档记录到位
   • 在保证质量的前提下推动问题解决
   • 协调团队成员之间的交接
   • 必要时规划并执行回滚策略

4. 事后领导

   • 确保开展全面的事后复盘
   • 推动落实预防措施
   • 与更广泛的组织分享经验教训

决策框架

紧急决策（SEV1/2）：

• 事件指挥官拥有全部决定权
• 偏向行动而非分析
• 记录决策以便事后审查
• 咨询相关领域专家，但不因此受阻

资源分配：

• 可调动任何必要的团队成员
• 有权升级至高级管理层
• 可批准外部资源的紧急支出
• 决定沟通渠道与时机

技术决策：

• 依靠技术负责人处理实施细节
• 对速度与风险之间的权衡做出最终决定
• 批准回滚还是向前修复的策略
• 协调测试与验证方法

沟通模板

初始事件通知（SEV1/2）

Subject: [SEV{severity}] {Service Name} - {Brief Description}

Incident Details:
- Start Time: {timestamp}
- Severity: SEV{level}
- Impact: {user impact description}
- Current Status: {investigating/mitigating/resolved}

Technical Details:
- Affected Services: {service list}
- Symptoms: {what users are experiencing}
- Initial Assessment: {suspected root cause if known}

Response Team:
- Incident Commander: {name}
- Technical Lead: {name}
- SMEs Engaged: {list}

Next Update: {timestamp}
Status Page: {link}
War Room: {bridge/chat link}

---
{Incident Commander Name}
{Contact Information}

执行摘要（SEV1）

Subject: URGENT - Customer-Impacting Outage - {Service Name}

Executive Summary:
{2-3 sentence description of customer impact and business implications}

Key Metrics:
- Time to Detection: {X minutes}
- Time to Engagement: {X minutes} 
- Estimated Customer Impact: {number/percentage}
- Current Status: {status}
- ETA to Resolution: {time or "investigating"}

Leadership Actions Required:
- [ ] Customer communication approval
- [ ] PR/Communications coordination  
- [ ] Resource allocation decisions
- [ ] External vendor engagement

Incident Commander: {name} ({contact})
Next Update: {time}

---
This is an automated alert from our incident response system.

客户沟通模板

We are currently experiencing {brief description of issue} affecting {scope of impact}. 

Our engineering team was alerted at {time} and is actively working to resolve the issue. We will provide updates every {frequency} until resolved.

What we know:
- {factual statement of impact}
- {factual statement of scope}
- {brief status of response}

What we're doing:
- {primary response action}
- {secondary response action}

Workaround (if available):
{workaround steps or "No workaround currently available"}

We apologize for the inconvenience and will share more information as it becomes available.

Next update: {time}
Status page: {link}

利益相关方管理

利益相关方分类

内部利益相关方：

• 工程负责人 - 负责技术决策与资源分配
• 产品管理 - 负责客户影响评估与功能影响分析
• 客户支持 - 负责用户沟通与支持工单管理
• 销售/客户经理 - 负责企业客户关系管理
• 高管团队 - 负责业务影响决策与对外沟通审批
• 法务/合规 - 负责监管报告与责任评估

外部利益相关方：

• 客户 - 服务可用性及影响沟通
• 合作伙伴 - API 可用性及集成影响
• 供应商 - 第三方服务依赖及支持升级
• 监管机构 - 受监管行业的合规报告
• 公众/媒体 - 面向公众服务中断的透明度

按利益相关方划分的沟通节奏

利益相关方	SEV1	SEV2	SEV3	SEV4
工程负责人	实时	30 分钟	4 小时	每日
高管团队	15 分钟	1 小时	当日结束前	每周
客户支持	实时	30 分钟	2 小时	按需
客户	15 分钟	1 小时	可选	无
合作伙伴	30 分钟	2 小时	可选	无

运行手册生成框架

动态运行手册组件

1. 检测手册

   • 监控告警定义
   • 分诊决策树
   • 升级触发点
   • 初始响应动作

2. 响应手册

   • 分步缓解流程
   • 回滚说明
   • 验证检查点
   • 沟通检查点

3. 恢复手册

   • 服务恢复流程
   • 数据一致性检查
   • 性能验证
   • 用户通知流程

运行手册模板结构

# {Service/Component} Incident Response Runbook

## Quick Reference
- **Severity Indicators:** {list of conditions for each severity level}
- **Key Contacts:** {on-call rotations and escalation paths}
- **Critical Commands:** {list of emergency commands with descriptions}

## Detection
### Monitoring Alerts
- {Alert name}: {description and thresholds}
- {Alert name}: {description and thresholds}

### Manual Detection Signs
- {Symptom}: {what to look for and where}
- {Symptom}: {what to look for and where}

## Initial Response (0-15 minutes)
1. **Assess Severity**
   - [ ] Check {primary metric}
   - [ ] Verify {secondary indicator}
   - [ ] Classify as SEV{level} based on {criteria}

2. **Establish Command**
   - [ ] Page Incident Commander if SEV1/2
   - [ ] Create incident tracking ticket
   - [ ] Join war room: {link/bridge info}

3. **Initial Investigation**
   - [ ] Check recent deployments: {deployment log location}
   - [ ] Review error logs: {log location and queries}
   - [ ] Verify dependencies: {dependency check commands}

## Mitigation Strategies
### Strategy 1: {Name}
**Use when:** {conditions}
**Steps:**
1. {detailed step with commands}
2. {detailed step with expected outcomes}
3. {validation step}

**Rollback Plan:**
1. {rollback step}
2. {verification step}

### Strategy 2: {Name}
{similar structure}

## Recovery and Validation
1. **Service Restoration**
   - [ ] {restoration step}
   - [ ] Wait for {metric} to return to normal
   - [ ] Validate end-to-end functionality

2. **Communication**
   - [ ] Update status page
   - [ ] Notify stakeholders
   - [ ] Schedule PIR

## Common Pitfalls
- **{Pitfall}:** {description and how to avoid}
- **{Pitfall}:** {description and how to avoid}

## Reference Information
→ See references/reference-information.md for details

## Usage Examples

### Example 1: Database Connection Pool Exhaustion

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

# Reconstruct timeline from logs
python scripts/timeline_reconstructor.py --input assets/sample_timeline_events.json --output timeline.md

# Generate PIR after resolution
python scripts/pir_generator.py --incident assets/sample_incident_data.json --timeline timeline.md --output pir.md

示例 2：API 速率限制事件

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

# Build timeline from multiple sources
python scripts/timeline_reconstructor.py --input assets/simple_timeline_events.json --detect-phases --gap-analysis

# Generate comprehensive PIR
python scripts/pir_generator.py --incident assets/sample_incident_pir_data.json --rca-method fishbone --action-items

最佳实践

事件响应期间

1. 保持冷静的领导力

   • 在压力下保持镇定
   • 在信息不完整时果断决策
   • 在承认不确定性的同时传达信心

2. 记录一切

   • 所有已采取的行动及其结果
   • 决策依据，尤其是有争议的决定
   • 随事件发展实时记录的时间线

3. 有效沟通

   • 使用清晰、不含行话的语言
   • 即使没有新信息，也定期提供更新
   • 主动管理利益相关方的预期

4. 技术卓越

   • 在压力下优先回滚，而非冒险修复
   • 在宣布解决前验证修复结果
   • 为次生故障和级联影响做好规划

事后复盘

1. 无责文化

   • 关注系统故障，而非个人失误
   • 鼓励如实报告问题所在
   • 庆祝学习与改进的机会

2. 行动项纪律

   • 指定明确的负责人和截止日期
   • 公开跟踪进展
   • 根据风险和投入排定优先级

3. 知识共享

   • 在组织内广泛分享 PIR
   • 根据经验教训更新运行手册
   • 针对常见故障模式开展培训

4. 持续改进

   • 寻找多次事件之间的规律
   • 投资工具与自动化
   • 定期审查并更新流程

与现有工具集成

监控与告警

• PagerDuty/Opsgenie 集成，用于升级处理
• Datadog/Grafana 用于指标和仪表盘
• ELK/Splunk 用于日志分析与关联

沟通平台

• Slack/Teams 用于战情室协调
• Zoom/Meet 用于视频会议桥接
• 状态页服务商（Statuspage.io 等）

文档系统

• Confluence/Notion 用于存储 PIR
• GitHub/GitLab 用于运行手册版本控制
• JIRA/Linear 用于行动项跟踪

变更管理

• CI/CD 流水线集成
• 部署跟踪系统
• 用于快速回滚的功能开关平台