事件指挥官技能

类别： 工程团队
层级： 强大
作者： Claude技能团队
版本： 1.0.0
最后更新： 2026年2月

概览

事件指挥官技能提供了一个全面的事件响应框架，用于从检测到解决以及事后审查阶段管理技术事件。这项技能实施了SRE和DevOps团队在大规模实践中经过验证的方法，提供了用于严重性分类、时间线重建和彻底事后分析的结构化工具。

核心特性

• 自动严重性分类 - 基于影响和紧急性指标的智能事件分类
• 时间线重建 - 将分散的日志和事件转换为连贯的事件叙述
• 事后审查生成 - 结构化的PIR，带有多个RCA框架
• 通信模板 - 预构建的模板用于利益相关者更新和升级
• 运行手册集成 - 从事件模式生成可操作的运行手册

技能包括

核心工具

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

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

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

   • 处理来自多个来源的时间戳事件
   • 重建事件时间线
   • 识别差距并提供持续时间分析

3. PIR生成器 (pir_generator.py)

   • 创建全面的事后审查文件
   • 应用多个RCA框架（5个为什么，鱼骨图，时间线）
   • 生成可操作的后续项目

事件响应框架

严重性分类系统

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）

主题：[SEV{严重性}] {服务名称} - {简短描述}

事件详情：
- 开始时间：{时间戳}
- 严重性：SEV{级别}
- 影响：{用户影响描述}
- 当前状态：{调查/缓解/已解决}

技术细节：
- 受影响服务：{服务列表}
- 症状：{用户正在经历什么}
- 初步评估：{如果已知，怀疑的根本原因}

响应团队：
- 事件指挥官：{姓名}
- 技术领导：{姓名}
- 参与的SME：{列表}

下次更新：{时间戳}
状态页面：{链接}
战情室：{桥/聊天链接}

---
{事件指挥官姓名}
{联系信息}

执行摘要（SEV1）

主题：紧急 - 客户影响中断 - {服务名称}

执行摘要：
{2-3句描述客户影响和业务影响}

关键指标：
- 检测时间：{X分钟}
- 参与时间：{X分钟} 
- 估计客户影响：{数字/百分比}
- 当前状态：{状态}
- 解决时间估计：{时间或“正在调查”}

领导行动要求：
- [ ] 客户通信批准
- [ ] PR/通信协调  
- [ ] 资源分配决策
- [ ] 外部供应商参与

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

---
这是我们事件响应系统自动发出的警报。

客户通信模板

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

我们的工程团队在{时间}被提醒，并正在积极努力解决这个问题。我们将每{频率}提供更新，直到解决。

我们知道什么：
- {影响的事实陈述}
- {范围的事实陈述}
- {响应的简短状态}

我们正在做什么：
- {主要响应行动}
- {次要响应行动}

替代方案（如果可用）：
{替代方案步骤或“目前没有可用的替代方案”}

我们为造成的不便道歉，并将在获得更多信息时分享。

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

利益相关者管理

利益相关者分类

内部利益相关者：

• 工程领导 - 技术决策和资源分配
• 产品管理 - 客户影响评估和功能影响
• 客户支持 - 用户通信和支持工单管理
• 销售/客户管理 - 企业客户客户关系管理
• 执行团队 - 业务影响决策和外部通信批准
• 法律/合规 - 监管报告和责任评估

外部利益相关者：

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

利益相关者通信节奏

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

运行手册生成框架

动态运行手册组件

1. 检测剧本

   • 监控警报定义
   • 三角决策树
   • 升级触发点
   • 初始响应行动

2. 响应剧本

   • 逐步缓解程序
   • 回滚说明
   • 验证检查点
   • 通信检查点

3. 恢复剧本

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

运行手册模板结构

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

## 快速参考
- **严重性指标：** {每个严重性级别的条件列表}
- **关键联系人：** {值班轮换和升级路径}
- **关键命令：** {紧急命令列表及描述}

## 检测
### 监控警报
- {警报名称}：{描述和阈值}
- {警报名称}：{描述和阈值}

### 手动检测迹象
- {症状}：{在哪里查找以及要查找什么}
- {症状}：{在哪里查找以及要查找什么}

## 初始响应（0-15分钟）
1. **评估严重性**
   - [ ] 检查{主要指标}
   - [ ] 验证{次要指标}
   - [ ] 根据{标准}分类为SEV{级别}

2. **建立指挥**
   - [ ] 如果SEV1/2，呼叫事件指挥官
   - [ ] 创建事件跟踪工单
   - [ ] 加入战情室：{链接/桥信息}

3. **初始调查**
   - [ ] 检查最近的部署：{部署日志位置}
   - [ ] 查看错误日志：{日志位置和查询}
   - [ ] 验证依赖项：{依赖项检查命令}

## 缓解策略
### 策略1：{名称}
**使用时：** {条件}
**步骤：**
1. {带命令的详细步骤}
2. {带预期结果的详细步骤}
3. {验证步骤}

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

### 策略2：{名称}
{类似结构}

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

2. **通信**
   - [ ] 更新状态页面
   - [ ] 通知利益相关者
   - [ ] 安排PIR

## 常见陷阱
- **{陷阱}：** {描述以及如何避免}
- **{陷阱}：** {描述以及如何避免}

## 参考信息
- **架构图：** {链接}
- **监控仪表板：** {链接}
- **相关运行手册：** {链接到依赖服务运行手册}

事后审查（PIR）框架

PIR时间线和所有权

时间线：

• 24小时： 事件指挥官完成初步PIR草稿
• 3个工作日： 所有利益相关者输入的最终PIR发布
• 1周： 分配行动项目，拥有者和截止日期
• 4周： 跟进行动项目进展

角色：

• PIR所有者： 事件指挥官（可以委托写作但拥有完成权）
• 技术贡献者： 参与响应的所有工程师
• 审查委员会： 工程领导，受影响的产品团队
• 行动项目所有者： 根据专业知识和能力分配

根本原因分析框架

1. 五个为什么方法

五个为什么技术涉及反复询问“为什么”以深入挖掘根本原因：

示例应用：

• 问题： 在高峰流量期间数据库变得无响应
• 为什么1： 为什么数据库变得无响应？→ 连接池耗尽
• 为什么2： 为什么连接池耗尽？→ 应用程序创建的连接比平常多
• 为什么3： 为什么应用程序创建了更多的连接？→ 新功能没有正确连接池
• 为什么4： 为什么功能没有正确连接池？→ 代码审查错过了这种模式
• 为什么5： 为什么代码审查错过了？→ 没有自动检查连接池模式

最佳实践：

• 至少问“为什么”三次，通常需要5次以上迭代
• 专注于流程失败，而不是个人责任
• 每个“为什么”应该指向一个可操作的系统改进
• 考虑多个根本原因路径，而不仅仅是一个线性链

2. 鱼骨（石川）图

系统分析多个潜在原因类别：

类别：

• 人员： 培训，经验，沟通，交接
• 流程： 程序，变更管理，审查流程
• 技术： 架构，工具，监控，自动化
• 环境： 基础设施，依赖项，外部因素

应用方法：

1. 在鱼骨的“头部”清楚地说明问题
2. 对于每个类别，头脑风暴潜在的促成因素
3. 对于每个因素，询问什么导致了那个因素（子因素）
4. 确定最有可能是根本原因的因素
5. 用事件的证据验证根本原因

3. 时间线分析

按时间顺序重建事件，以识别决策点和错过的机会：

时间线元素：

• 检测： 问题首次可观察是什么时候？首次检测是什么时候？
• 通知： 正确的人被告知得有多快？
• 响应： 采取了哪些行动，它们有多有效？
• 通信： 何时更新利益相关者？
• 解决： 什么最终解决了问题？

分析问题：

• 哪里有延迟，是什么原因造成的？
• 如果有完美信息，我们会做出什么不同的决定？
• 通信在哪里中断？
• 有什么自动化可以更快地检测/解决？

升级路径

技术升级

第1级： 值班工程师

• 责任： 初始响应和常见问题解决
• 升级触发器： 问题在SLA时间框架内未解决
• 时间框架： 15分钟（SEV1），30分钟（SEV2）

第2级： 高级工程师/团队领导

• 责任： 需要更深层次专业知识的复杂技术问题
• 升级触发器： 第1级请求帮助或超时发生
• 时间框架： 30分钟（SEV1），1小时（SEV2）

第3级： 工程经理/员工工程师

• 责任： 跨团队协调和架构决策
• 升级触发器： 问题跨越多个系统或团队
• 时间框架： 45分钟（SEV1），2小时（SEV2）

第4级： 工程总监/CTO

• 责任： 资源分配和业务影响决策
• 升级触发器： 延长中断或重大业务影响
• 时间框架： 1小时（SEV1），4小时（SEV2）

业务升级

客户影响评估：

• 高： 收入损失，SLA违规，客户流失风险
• 中： 用户体验降级，支持工单量
• 低： 内部工具，仅开发影响

升级矩阵：

严重性	持续时间	业务升级
SEV1	立即	工程副总裁
SEV1	30分钟	CTO + 客户成功副总裁
SEV1	1小时	CEO + 全体执行团队
SEV2	2小时	工程副总裁
SEV2	4小时	CTO
SEV3	1个工作日	工程经理

状态页面管理

更新原则

1. 透明度： 提供无猜测的事实信息
2. 及时性： 在承诺的时间框架内更新
3. 清晰度： 使用客户友好的语言，避免技术术语
4. 完整性： 包括影响范围，状态和下次更新时间

状态类别

• 运营正常： 所有系统正常运行
• 性能下降： 部分用户可能会经历缓慢
• 部分中断： 部分功能不可用
• 主要中断： 服务对大多数/所有用户不可用
• 维护中： 计划维护窗口

更新模板

{时间戳} - {状态类别}

{当前状态的简短描述}

影响：{谁受影响以及如何}
原因：{如果已知根本原因，如果不知道，则为“正在调查”}
解决：{正在做什么来解决它}

下次更新：{具体时间}

我们为可能造成的任何不便道歉。

行动项目框架

行动项目类别

1. 立即修复

   • 事件期间发现的关键错误
   • 暴露的安全漏洞
   • 数据完整性问题

2. 流程改进

   • 通信差距
   • 升级程序更新
   • 运行手册增删/更新

3. 技术债务

   • 架构改进
   • 监控增强
   • 自动化机会

4. 组织变革

   • 团队结构调整
   • 培训要求
   • 工具/平台投资

行动项目模板

**标题：** {行动的简洁描述}
**优先级：** {关键/高/中/低}
**类别：** {修复/流程/技术/组织}
**所有者：** {被分配的人}
**截止日期：** {具体日期}
**成功标准：** {我们怎么知道这已经完成}
**依赖关系：** {首先需要发生什么}
**相关PIRs：** {其他事件的链接，这个问题解决了}

**描述：**
{需要做什么以及为什么的详细描述}

**实施计划：**
1. {步骤1}
2. {步骤2}
3. {验证步骤}

**进度更新：**
- {日期}：{进度更新}
- {日期}：{进度更新}

使用示例

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

# 对事件进行分类
echo '{"description": "用户报告500错误，数据库连接超时", "affected_users": "80%", "business_impact": "high"}' | python scripts/incident_classifier.py

# 从日志重建时间线
python scripts/timeline_reconstructor.py --input assets/db_incident_events.json --output timeline.md

# 解决后生成PIR
python scripts/pir_generator.py --incident assets/db_incident_data.json --timeline timeline.md --output pir.md

示例2：API速率限制事件

# 从stdin快速分类
echo "API速率限制导致客户API调用失败" | python scripts/incident_classifier.py --format text

# 从多个来源构建时间线
python scripts/timeline_reconstructor.py --input assets/api_incident_logs.json --detect-phases --gap-analysis

# 生成全面的PIR
python scripts/pir_generator.py --incident assets/api_incident_summary.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管道集成
• 部署跟踪系统
• 功能标志平台用于快速回滚

结论

事件指挥官技能提供了一个全面的框架，用于从检测到事后审查管理事件。通过实施结构化流程，清晰的通信模板和彻底的分析工具，团队可以提高其事件响应能力并构建更具弹性的系统。

成功事件管理的关键是准备，实践和持续学习。将此框架作为起点，但根据您组织的具体需求，文化和技术环境进行调整。

记住：目标不是预防所有事件（这是不可能的），而是快速检测它们，有效响应，清晰沟通和持续学习。