名称：事件管理描述：使用SRE原则、严重性分类、值班管理、无责文化和通信协议，指导从检测到事后分析的事件响应。适用于设置事件处理流程、设计升级政策或进行事后分析。

事件管理

提供端到端的事件管理指导，覆盖检测、响应、通信和学习。强调SRE文化、无责事后分析和结构化流程，适用于高可靠性运营。

何时使用此技能

在以下情况应用此技能：

为团队设置事件响应流程
设计值班轮换和升级政策
创建常见故障场景的运行手册
在事件后进行无责事后分析
实施事件通信协议（内部和外部）
选择事件管理工具和平台
改进平均修复时间（MTTR）和事件频率指标

核心原则

事件管理哲学

及早并频繁声明： 不要等待确定性。声明事件能促进协调，可以降级（如果需要），并防止响应延迟。

先缓解，后根因： 立即停止客户影响（回滚、禁用功能、故障转移）。稳定性恢复后，再调试和修复根因。

无责文化： 假设良好意图。关注系统如何失败，而非谁失败。为诚实学习创造心理安全环境。

清晰指挥结构： 指定事件指挥官（IC）负责协调。IC委派任务，但不进行手动调试。

通信至关重要： 内部通过专用渠道协调，外部通过状态页透明。关键事件期间，每15-30分钟更新利益相关者。

严重性分类

标准严重性级别及响应时间：

SEV0（P0）- 关键中断：

影响：服务完全中断、关键数据丢失、支付处理停机
响应：立即24/7通知、全员参与、执行层通知
示例：API完全下线，影响全部客户

SEV1（P1）- 重大降级：

影响：主要功能降级、影响显著客户子集
响应：工作时间通知，非工作时间升级，指定IC
示例：15%错误率，关键功能不可用

SEV2（P2）- 次要问题：

影响：次要功能受损、边缘情况错误、小用户子集
响应：电子邮件/Slack警报，下一个工作日响应
示例：UI小故障，非关键功能缓慢

SEV3（P3）- 低影响：

影响：外观问题，不影响客户功能
响应：工单队列，计划冲刺
示例：视觉不一致，文档错误

有关详细严重性决策框架和交互式分类器，请参阅references/severity-classification.md。

事件角色

事件指挥官（IC）：

负责整体事件响应和协调
做出战略决策（回滚 vs. 调试，何时升级）
委派任务给响应者（不进行手动调试）
稳定性确认后，宣布事件解决

通信负责人：

发布状态更新到内部和外部渠道
与利益相关者协调（执行层、产品、支持）
草拟事后客户通信
频率：SEV0/SEV1每15-30分钟

主题专家（SMEs）：

手动调试和缓解
执行运行手册并实施修复
向IC提供技术背景

记录员：

实时记录时间线、行动、决策
记录事件笔记用于事后分析重建

基于严重性分配角色：

SEV2/SEV3：单响应者
SEV1：IC + SME(s)
SEV0：IC + 通信负责人 + SME(s) + 记录员

有关详细角色职责，请参阅references/incident-roles.md。

值班管理

轮换模式

主+备：

主：第一响应者
备：主响应者5分钟内未确认时的备份
轮换时长：1周（最佳平衡）

跟随太阳（24/7）：

团队A：美国时间，团队B：欧洲时间，团队C：亚洲时间
优势：无夜班，改善工作生活平衡
要求：多个全球团队

分层升级：

层级1：初级值班（常见问题，运行手册驱动）
层级2：高级值班（复杂故障排除）
层级3：团队领导/架构师（关键决策）

最佳实践

轮换时长：每次轮换1周
交接仪式：30分钟电话讨论活跃问题
补偿：值班津贴 + 重大事件后休假
工具：PagerDuty、Opsgenie 或 incident.io
限制：每晚最多2-3次通知；超过则升级

事件响应工作流

标准事件生命周期：

检测 → 分类 → 声明 → 调查
  ↓
缓解 → 解决 → 监控 → 关闭
  ↓
事后分析（48小时内）

关键决策点

何时声明： 有疑问时，声明（可以随时降级严重性）

何时升级：

30分钟后无进展
严重性增加（SEV2 → SEV1）
需要专业专长

何时关闭：

问题解决并稳定30+分钟
监控显示所有指标回到基线
无客户报告问题

有关完整工作流细节，请参阅references/incident-workflow.md。

通信协议

内部通信

事件Slack频道：

格式：#incident-YYYY-MM-DD-主题描述
固定：严重性、IC名称、状态更新模板、运行手册链接

战室： 需要实时语音协调的SEV0/SEV1视频通话

状态更新频率：

SEV0：每15分钟
SEV1：每30分钟
SEV2：每1-2小时或在主要里程碑

外部通信

状态页：

工具：Statuspage.io、Instatus、自定义
阶段：调查中 → 已识别 → 监控中 → 已解决
透明度：公开承认问题，尽可能提供预计时间（ETA）

客户电子邮件：

何时：影响客户的SEV0/SEV1
时机：1小时内（确认），解决后（完整详情）
语气：道歉、透明、行动导向

法规通知：

数据泄露：GDPR要求72小时内通知
金融服务：立即通知监管机构
医疗保健：HIPAA违规通知规则

有关通信模板，请参阅examples/communication-templates.md。

运行手册和剧本

运行手册结构

每个运行手册应包括：

触发： 激活此运行手册的警报条件
严重性： 预期严重性级别
先决条件： 系统状态要求
步骤： 编号、可执行的命令（可复制粘贴）
验证： 如何确认修复生效
回滚： 步骤失败时如何撤销
所有者： 负责的团队/人员
最后更新： 上次修订日期

最佳实践

可执行： 命令可复制粘贴，不仅仅是描述
测试： 在灾难恢复演练中运行
版本控制： 在Git中跟踪更改
链接： 从警报定义引用
自动化： 随时间将手动步骤转为脚本

有关运行手册模板，请参阅examples/runbooks/目录。

无责事后分析

无责文化信条

假设良好意图： 每个人基于可用信息做出了最佳决策。

关注系统： 调查流程如何失败，而非谁失败。

心理安全： 创造诚实受奖励的环境。

学习机会： 事件是组织知识的礼物。

事后分析流程

1. 安排回顾（48小时内）： 记忆新鲜时

2. 准备工作： 重建时间线、收集指标/日志、草拟文档

3. 会议促进：

时间线走查
5个为什么分析以识别系统性根因
什么做得好/什么出错
定义行动项，分配所有者和截止日期

4. 事后分析文档：

部分：摘要、时间线、根因、影响、什么做得好/出错、行动项
分发：工程、产品、支持、领导层
存储：存档到可搜索知识库

5. 后续跟进： 在冲刺规划中跟踪行动项

有关详细促进指南和模板，请参阅references/blameless-postmortems.md和examples/postmortem-template.md。

警报设计原则

仅可操作警报：

每个警报需要人类行动
包括图表、运行手册链接、近期更改
去重相关警报
基于服务所有权路由到适当团队

防止警报疲劳：

每季度审计警报：移除不可操作警报
增加噪音指标的阈值
使用异常检测代替静态阈值
限制：每晚最多2-3次通知

工具选择

事件管理平台

PagerDuty：

最适合：成熟企业，复杂升级政策
成本：$19-41/用户/月
何时：团队规模10+，预算$500+/月

Opsgenie：

最适合：Atlassian生态系统用户，灵活路由
成本：$9-29/用户/月
何时：使用Atlassian产品，预算$200-500/月

incident.io：

最适合：现代团队，AI驱动响应，Slack原生
何时：团队规模5-50，Slack中心文化

有关详细工具比较，请参阅references/tool-comparison.md。

状态页解决方案

Statuspage.io： 最受信任，易于设置（$29-399/月） Instatus： 预算友好，现代设计（$19-99/月）

指标和持续改进

关键事件指标

平均确认时间（MTTA）：

目标：SEV1 < 5分钟
改进：更好的值班覆盖

平均修复时间（MTTR）：

目标：SEV1 < 1小时
改进：运行手册、自动化

平均故障间隔时间（MTBF）：

目标：关键服务 > 30天
改进：根因修复

事件频率：

跟踪：每月SEV0、SEV1、SEV2计数
目标：下降趋势

行动项完成率：

目标：> 90%
改进：冲刺集成、所有权清晰

持续改进循环

事件 → 事后分析 → 行动项 → 预防
   ↑                                          ↓
   └──────────── 减少事件 ─────────────┘

决策框架

严重性分类决策树

生产是否完全中断或关键数据面临风险？
├─ 是 → SEV0
└─ 否  → 主要功能是否降级？
          ├─ 是 → 是否有变通方法？
          │        ├─ 是 → SEV1
          │        └─ 否  → SEV0
          └─ 否  → 客户是否受影响？
                   ├─ 是 → SEV2
                   └─ 否  → SEV3

使用交互式分类器：python scripts/classify-severity.py

升级矩阵

有关详细升级指导，请参阅references/escalation-matrix.md。

缓解 vs. 根因

优先缓解当：

客户影响持续进行
有快速修复可用（回滚、禁用功能）

优先根因当：

客户影响已缓解
修复需要仔细分析

默认： 先缓解（99%的情况）

需避免的反模式

延迟声明： 在声明前等待确定性
跳过事后分析： "小"事件仍提供学习
责备文化： 惩罚个人阻碍系统性学习
忽略行动项： 事后分析无后续是浪费时间
无清晰IC： 多人领导导致混乱
警报疲劳： 噪音、不可操作警报导致值班忽略通知
手动调试IC： IC应委派调试，而非亲自进行

实施清单

阶段1：基础（第1周）

[ ] 定义严重性级别（SEV0-SEV3）
[ ] 选择事件管理平台
[ ] 设置基本值班轮换
[ ] 创建事件Slack频道模板

阶段2：流程（第2-3周）

[ ] 创建前5个常见事件运行手册
[ ] 设置状态页
[ ] 培训团队事件响应
[ ] 进行桌面演练

阶段3：文化（第4周+）

[ ] 进行首次无责事后分析
[ ] 建立事后分析频率
[ ] 实施MTTA/MTTR仪表板
[ ] 在冲刺规划中跟踪行动项

阶段4：优化（第3-6月）

[ ] 自动化事件声明
[ ] 实施运行手册自动化
[ ] 每月灾难恢复演练
[ ] 每季度事件趋势回顾

与其他技能集成

可观察性： 监控警报触发事件 → 使用事件管理进行响应

灾难恢复： DR提供恢复程序 → 事件管理提供操作响应

安全事件响应： 类似流程，添加合规/取证

基础设施即代码（IaC）： IaC通过自动重建实现快速恢复

性能工程： 性能事件触发响应 → 性能团队缓解后调查

示例和模板

运行手册模板：

examples/runbooks/database-failover.md
examples/runbooks/cache-invalidation.md
examples/runbooks/ddos-mitigation.md

事后分析模板：

examples/postmortem-template.md - 完整的无责事后分析结构

通信模板：

examples/communication-templates.md - 状态更新、客户电子邮件

值班交接：

examples/oncall-handoff-template.md - 每周交接格式

集成脚本：

examples/integrations/pagerduty-slack.py
examples/integrations/statuspage-auto-update.py
examples/integrations/postmortem-generator.py

脚本

交互式严重性分类器：

python scripts/classify-severity.py

通过提问基于影响和紧急性确定适当严重性级别。

进一步阅读

书籍：

Google SRE书：《事后分析文化》（第15章）
《凤凰项目》由Gene Kim
《网站可靠性工程》（全书）

在线资源：

Atlassian：《如何运行无责事后分析》
PagerDuty：《事件响应指南》
Google SRE：《事后分析文化：从失败中学习》

标准：

事件指挥系统（ICS） - FEMA标准适用于技术
ITIL事件管理 - 传统IT服务管理

名称：事件管理 描述：使用SRE原则、严重性分类、值班管理、无责文化和通信协议，指导从检测到事后分析的事件响应。适用于设置事件处理流程、设计升级政策或进行事后分析。

事件管理

何时使用此技能

核心原则

事件管理哲学

严重性分类

事件角色

值班管理

轮换模式

最佳实践

事件响应工作流

关键决策点

通信协议

内部通信

外部通信

运行手册和剧本

运行手册结构

最佳实践

无责事后分析

无责文化信条

事后分析流程

警报设计原则

工具选择

事件管理平台

状态页解决方案

指标和持续改进

关键事件指标

持续改进循环

决策框架

严重性分类决策树

升级矩阵

缓解 vs. 根因

需避免的反模式

实施清单

阶段1：基础（第1周）

阶段2：流程（第2-3周）

阶段3：文化（第4周+）

阶段4：优化（第3-6月）

与其他技能集成

示例和模板

脚本

进一步阅读

名称：事件管理描述：使用SRE原则、严重性分类、值班管理、无责文化和通信协议，指导从检测到事后分析的事件响应。适用于设置事件处理流程、设计升级政策或进行事后分析。