managing-incidents

事件管理

提供涵盖检测、响应、沟通和总结改进的端到端事件管理指南。强调 SRE 文化、无责复盘，以及用于实现高可靠运营的结构化流程。

何时使用此技能

在以下情况下应用此技能：

• 为团队建立事件响应流程
• 设计值班轮换和升级策略
• 为常见故障场景创建运行手册
• 在事件发生后开展无责复盘
• 实施事件沟通协议（内部和外部）
• 选择事件管理工具和平台
• 改善 MTTR 和事件频率指标

核心原则

事件管理理念

尽早并及时宣布事件： 不要等待确定无疑。宣布事件有助于协调；必要时可以降低事件级别，也能避免响应延迟。

先缓解，再查明根因： 立即停止对客户的影响（回滚、禁用功能、故障切换）。恢复稳定后，再调试并修复根因。

无责文化： 假定每个人都是出于善意。关注系统如何失效，而非谁出了错。营造心理安全感，让大家能够坦诚总结经验。

明确的指挥架构： 指定事件指挥官（IC）负责协调。IC 分派任务，但不亲自进行调试。

沟通至关重要： 通过专用频道进行内部协调，通过状态页面对外保持透明。重大事件期间，每隔 15-30 分钟向利益相关者更新进展。

严重级别分类

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

SEV0（P0）- 严重中断：

• 影响：服务完全中断、关键数据丢失、支付处理不可用
• 响应：全天候立即呼叫，所有人投入处理，通知高管
• 示例：API 完全不可用，所有客户均受影响

SEV1（P1）- 重大性能下降：

• 影响：主要功能性能下降，大量客户受到影响
• 响应：工作时间内呼叫，非工作时间升级处理，指定 IC
• 示例：错误率达到 15%，关键功能不可用

SEV2（P2）- 次要问题：

• 影响：部分功能受损、边缘场景缺陷、少量用户受影响
• 响应：通过电子邮件/Slack 发送提醒，下一个工作日响应
• 示例：UI 显示异常，非关键功能运行缓慢

SEV3（P3）- 影响较低：

• 影响：外观问题，不影响客户使用功能
• 响应：进入工单队列，纳入计划迭代
• 示例：视觉不一致、文档错误

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

事件角色

事件指挥官（IC）：

• 全面负责事件响应和协调
• 做出策略性决策（回滚还是调试、何时升级）
• 向响应人员分派任务（不亲自进行调试）
• 在确认稳定后宣布事件已解决

沟通负责人：

• 在内部和外部频道发布状态更新
• 与利益相关者（高管、产品、支持团队）协调
• 起草事件后的客户沟通内容
• 更新频率：SEV0/SEV1 每隔 15-30 分钟一次

主题专家（SME）：

• 亲自进行调试和缓解
• 执行运行手册并实施修复
• 向 IC 提供技术背景信息

记录员：

• 实时记录时间线、行动和决策
• 记录事件笔记，以便在复盘时重建经过

根据严重级别分配角色：

• SEV2/SEV3：单名响应人员
• SEV1：IC + SME（可多人）
• SEV0：IC + 沟通负责人 + SME（可多人）+ 记录员

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

值班管理

轮值模式

主值班 + 备份值班：

• 主值班：第一响应人
• 备份值班：若主值班人员在 5 分钟内未确认，则由备份人员接替
• 轮值时长：1 周（最优平衡）

日不落轮值（全天候）：

• A 团队：美国时段，B 团队：欧洲时段，C 团队：亚洲时段
• 优点：无需夜班，改善工作与生活的平衡
• 要求：多个全球团队

分级升级：

• 第 1 级：初级值班人员（常见问题，按运行手册处理）
• 第 2 级：高级值班人员（复杂故障排查）
• 第 3 级：团队负责人／架构师（关键决策）

最佳实践

• 轮值时长：每轮 1 周
• 交接仪式：召开 30 分钟会议，讨论待处理问题
• 补偿：值班津贴 + 重大事故后补休
• 工具：PagerDuty、Opsgenie 或 incident.io
• 限制：每晚最多 2-3 次告警；超出时升级处理

事故响应工作流

标准事故生命周期：

Detection → Triage → Declaration → Investigation
  ↓
Mitigation → Resolution → Monitoring → Closure
  ↓
Post-Mortem (within 48 hours)

关键决策点

何时宣布事故： 有疑问时就宣布（之后随时可以降低严重级别）

何时升级：

• 30 分钟后仍无进展
• 严重级别上升（SEV2 → SEV1）
• 需要专业技能

何时关闭：

• 问题已解决且稳定运行 30 分钟以上
• 监控显示所有指标恢复基线
• 没有客户报告问题

完整工作流详情请参阅 references/incident-workflow.md。

沟通协议

内部沟通

事故 Slack 频道：

• 格式：#incident-YYYY-MM-DD-topic-description
• 置顶内容：严重级别、IC 姓名、状态更新模板、运行手册链接

战情室： 对于需要实时语音协调的 SEV0/SEV1 事故，使用视频通话

状态更新频率：

• SEV0：每 15 分钟
• SEV1：每 30 分钟
• SEV2：每 1-2 小时更新一次，或在重要里程碑时更新

外部沟通

状态页：

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

客户邮件：

• 适用情况：影响客户的 SEV0/SEV1 事故
• 时间：1 小时内（确认收到），解决后发送（提供完整详情）
• 语气：致歉、透明、注重行动

监管通知：

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

沟通模板请参阅 examples/communication-templates.md。

运行手册和操作手册

运行手册结构

每份运行手册都应包含：

1. 触发条件： 启动此运行手册的告警条件
2. 严重级别： 预期的严重级别
3. 前置条件： 系统状态要求
4. 步骤： 带编号、可执行的命令（可直接复制粘贴）
5. 验证： 如何确认修复生效
6. 回滚： 如果步骤失败，如何撤销
7. 负责人： 负责的团队／人员
8. 最后更新： 最近一次修订的日期

最佳实践

• 可执行： 命令应可直接复制粘贴，而不只是描述
• 经过测试： 在灾难恢复演练期间运行
• 纳入版本控制： 在 Git 中跟踪变更
• 添加链接： 在告警定义中引用
• 自动化： 随时间推移，将手动步骤转为脚本

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

无责复盘

无责文化准则

假设本意良好： 每个人都根据当时可用的信息做出了最佳决策。

聚焦系统： 调查流程为何失效，而非追究是谁的责任。

心理安全： 营造鼓励坦诚的环境。

学习机会： 事故是组织知识的馈赠。

复盘流程

1. 安排复盘（48 小时内）： 趁记忆还清晰时进行

2. 前期准备： 重建时间线、收集指标和日志、起草文档

3. 会议主持：

• 梳理时间线
• 通过 5 Whys 分析找出系统性根因
• 做得好的地方／做得不好的地方
• 明确行动项的负责人和截止日期

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%
• 改进方法：整合到冲刺流程、明确负责人

持续改进循环

Incident → Post-Mortem → Action Items → Prevention
   ↑                                          ↓
   └──────────── Fewer Incidents ─────────────┘

决策框架

严重程度分类决策树

Is production completely down or critical data at risk?
├─ YES → SEV0
└─ NO  → Is major functionality degraded?
          ├─ YES → Is there a workaround?
          │        ├─ YES → SEV1
          │        └─ NO  → SEV0
          └─ NO  → Are customers impacted?
                   ├─ YES → SEV2
                   └─ NO  → SEV3

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

升级矩阵

详细的升级指南请参阅 references/escalation-matrix.md。

缓解与根因

优先缓解的情况：

• 客户影响仍在持续
• 有快速修复方案（回滚、禁用功能）

优先查明根因的情况：

• 客户影响已经得到缓解
• 修复需要仔细分析

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

应避免的反模式

• 延迟宣布： 等到确定无疑才宣布发生事件
• 跳过复盘： “小型”事件仍能带来经验
• 责备文化： 惩罚个人会阻碍系统性学习
• 忽视行动项： 复盘后不跟进只会浪费时间
• 没有明确的 IC： 多人共同领导会造成混乱
• 告警疲劳： 嘈杂、不可操作的告警会导致值班人员忽略呼叫
• 亲自排查的 IC： IC 应委派调试工作，而不是亲自处理

实施清单

阶段 1：基础（第 1 周）

• 定义严重程度等级（SEV0-SEV3）
• 选择事件管理平台
• 建立基础值班轮换
• 创建事件 Slack 频道模板

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

• 为常见事件创建首批 5 份运行手册
• 设置状态页
• 为团队开展事件响应培训
• 进行桌面演练

第 3 阶段：文化（第 4 周及以后）

• 开展首次无责复盘
• 建立复盘机制
• 实施 MTTA/MTTR 仪表板
• 在冲刺规划中跟踪行动项

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

• 自动化事件声明
• 实施运行手册自动化
• 每月开展灾难恢复演练
• 每季度审查事件趋势

与其他技能的集成

可观测性： 监控告警会触发事件 → 使用 incident-management 进行响应

灾难恢复： DR 提供恢复流程 → Incident-management 提供运维响应

安全事件响应： 流程类似，但增加了合规性与取证环节

基础设施即代码： 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 Book：《Postmortem Culture》（第 15 章）
• Gene Kim 著《The Phoenix Project》
• 《Site Reliability Engineering》（全书）

在线资源：

• Atlassian：《How to Run a Blameless Postmortem》
• PagerDuty：《Incident Response Guide》
• Google SRE：《Postmortem Culture: Learning from Failure》

标准：

• Incident Command System（ICS）——改编自 FEMA 标准，适用于技术领域
• ITIL Incident Management——传统 IT 服务管理