事件响应Skill incident-response

事件响应技能用于帮助组织设计和管理有效的事故管理流程,覆盖事件生命周期(检测、响应、恢复、学习),通过建立运行手册、值班实践和事后分析,减少平均检测时间和恢复时间,提升系统可靠性。关键词:事件管理、事故响应、DevOps、运行手册、事后分析、MTTR、值班轮换、无责文化。

DevOps 0 次安装 0 次浏览 更新于 3/11/2026

name: 事件响应 description: 用于设计事件管理流程、创建运行手册或建立值班实践。覆盖事件生命周期、通信和事后分析。 allowed-tools: 读取、全局搜索、搜索

事件响应

有效事件管理的模式和实践,从检测到事后分析。

何时使用此技能

  • 设计事件响应流程
  • 创建事件运行手册
  • 建立值班轮换
  • 运行有效的事后分析
  • 改进平均恢复时间(MTTR)

事件生命周期

┌─────────────────────────────────────────────────────────┐
│                  事件生命周期                          │
│                                                          │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐   │
│  │ 检测    │─►│ 响应    │─►│ 恢复    │─►│ 学习    │   │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘   │
│       │            │            │            │          │
│       ▼            ▼            ▼            ▼          │
│   告警监控     分类与诊断    缓解与补救   事后分析    │
│                      行动项                            │
└─────────────────────────────────────────────────────────┘

关键指标

MTTD - 平均检测时间
└── 从事件开始到检测的时间

MTTA - 平均确认时间
└── 从告警到人工确认的时间

MTTR - 平均恢复时间
└── 从检测到解决的时间

MTTF - 平均故障时间
└── 事件之间的时间(可靠性)

目标:最小化 MTTD + MTTA + MTTR

事件严重性

严重性级别

SEV 1 - 严重
├── 完全中断
├── 数据丢失或安全漏洞
├── 所有/大多数用户受影响
├── 响应:立即(24/7)
└── 示例:生产数据库宕机

SEV 2 - 高
├── 主要功能受损
├── 显著用户影响
├── 可能存在变通方法
├── 响应:紧急(工作时间+)
└── 示例:支付处理性能下降

SEV 3 - 中等
├── 部分功能受影响
├── 有限用户影响
├── 变通方法可用
├── 响应:正常优先级
└── 示例:报表生成缓慢

SEV 4 - 低
├── 次要问题
├── 最小用户影响
├── 响应:尽力而为
└── 示例:UI界面美观问题

严重性矩阵

                    用户影响
                低     中     高
范围     ├─────────────────────────────┤
广泛     │  SEV3   SEV2    SEV1       │
中等     │  SEV4   SEV3    SEV2       │
有限     │  SEV4   SEV4    SEV3       │
         └─────────────────────────────┘

事件角色

核心角色

事件指挥官(IC)
├── 端到端负责事件
├── 做决策并委派任务
├── 控制事件频道
├── 不进行调试(协调)
└── 重点:大局观、沟通

技术负责人
├── 领导技术调查
├── 协调技术响应者
├── 做技术决策
├── 向IC报告
└── 重点:根因分析、修复

通信负责人
├── 处理外部通信
├── 更新状态页面
├── 管理客户通知
├── 向IC报告
└── 重点:利益相关者更新

记录员
├── 记录时间线
├── 记录决策和行动
├── 捕获重要信息
├── 向IC报告
└── 重点:文档化

角色交接

交接协议:
1. IC: "我将IC交给[姓名]"
2. 新IC: "我接任IC。当前状态是..."
3. IC: "确认,[姓名]现在是IC"

交接时机:
- 轮班结束
- 疲劳发生时
- 需要专业知识时
- 需要升级时

事件通信

通信频道

内部:
┌─────────────────────────────────────────────────────────┐
│ #incident-YYYY-MM-DD-topic                              │
│ - 所有事件通信在这里                                   │
│ - 固定:当前状态、时间线、角色                        │
│ - 语音通话链接                                         │
└─────────────────────────────────────────────────────────┘

外部:
- 状态页面(status.example.com)
- 客户电子邮件
- 社交媒体(如需)
- 支持频道

状态更新模板

[时间] 事件更新 - [标题]

当前状态:[调查中|已识别|监控中|已解决]

影响:[用户正在经历什么]

我们知道什么:
- [关键事实]

我们正在做什么:
- [当前行动]

下次更新:[时间或"尽快了解更多信息"]

更新节奏

SEV 1: 每15-30分钟
SEV 2: 每30-60分钟
SEV 3: 每1-2小时
SEV 4: 按需

其他更新时机:
- 状态变化时
- 有重大新信息时
- 采取行动时
- 达到解决时

事件响应流程

步骤1:检测与告警

触发点:
- 自动化告警
- 用户报告
- 内部发现

第一响应者行动:
1. 确认告警
2. 评估初始影响
3. 如需则宣布事件
4. 呼叫额外响应者
5. 打开事件频道

步骤2:分类与动员

分类问题:
- 用户影响是什么?
- 有多少用户受影响?
- 有变通方法吗?
- 严重性如何?

动员:
1. 呼叫适当响应者
2. 建立角色(IC、技术负责人、通信)
3. 开始事件频道
4. 开始时间线文档

步骤3:调查与诊断

调查方法:
1. 最近有什么变化?
   └── 部署、配置、基础设施

2. 指标/日志显示什么?
   └── 错误率、延迟、追踪

3. 影响范围是什么?
   └── 哪些服务、哪些用户

4. 假设是什么?
   └── 列出、优先排序、测试

常见命令:
- "正在检查[系统]"
- "理论:[假设]"
- "发现:[发现]"
- "需要:[资源/权限]"

步骤4:缓解

缓解策略:
1. 回滚
   └── 还原近期变化

2. 故障转移
   └── 切换到备份/副本

3. 扩展
   └── 增加容量

4. 禁用
   └── 关闭受影响功能

5. 热修复
   └── 部署针对性修复

优先:先恢复服务,再分析根因

步骤5:解决与验证

解决检查清单:
□ 服务恢复
□ 指标正常化
□ 用户影响结束
□ 监控到位以防复发
□ 临时缓解措施文档化

验证:
- 检查关键SLO指标
- 测试用户流程
- 监控15-30分钟
- 与受影响团队确认

步骤6:关闭与学习

关闭:
1. 宣布事件解决
2. 最终状态更新
3. 安排事后分析
4. 指派事后分析负责人
5. 关闭事件频道(归档)

时间线:
- 事后分析文档:24-48小时内
- 事后分析会议:5个工作日内
- 行动项:跟踪至完成

值班实践

值班结构

主班:首先响应告警
副班:如果主班不可用时的备份
升级:经理/高级人员处理重大事件

轮换选项:
- 每周轮换
- 跨时区轮换(多时区)
- 分班(白天/夜晚)

非工作时间政策:
- 什么值得呼叫?
- 什么可以等待?
- 非工作时间补偿

值班责任

值班期间:
- 在SLA内响应告警
- 分类并解决或升级
- 文档化行动
- 交接给下一班

交接内容包括:
- 开放的告警/事件
- 近期事件
- 已知问题
- 计划更改

告警优化

好的告警:
- 可操作的
- 紧急的
- 影响用户的
- 有明确解决路径

告警反模式:
- "有人应该看看这个"
- 重复告警
- 不可操作信息
- 误报频繁

定期回顾:
- 哪些告警触发了?
- 哪些是可操作的?
- 哪些是噪音?
- 缺少什么?

运行手册

运行手册结构

# 运行手册:[告警名称]

## 概述
此告警的意义和重要性。

## 影响
告警触发时用户的体验。

## 调查步骤
1. 检查[指标/日志/仪表盘]
2. 查找[特定模式]
3. 验证[组件状态]

## 缓解步骤
1. 如果[条件],做[行动]
2. 如果[条件],做[行动]
3. 如果[条件],升级

## 回滚程序
如需如何撤销更改。

## 联系人
- 服务所有者:[姓名]
- 升级:[姓名/团队]

## 相关链接
- 仪表盘:[链接]
- 日志:[查询]
- 服务文档:[链接]

运行手册维护

保持运行手册最新:
- 事件后更新
- 季度回顾
- 测试程序
- 移除过时内容

运行手册位置:
- 从告警链接
- 可搜索/可发现
- 版本控制

事后分析

无责文化

无责事后分析:
- 聚焦系统,而非个人
- 假设人们理性行事
- 寻找影响因素
- 改进系统和流程

非无责:"John应该..."
无责:"系统允许..."

事后分析模板

# 事件事后分析:[标题]

日期:[日期]
持续时间:[开始-结束]
严重性:[SEV级别]
作者:[姓名]

## 摘要
一段总结发生了什么。

## 影响
- 受影响用户:[数量/百分比]
- 持续时间:[时间]
- 收入影响:[如适用]

## 时间线
[时间] - 事件
[时间] - 采取的行动
[时间] - 解决

## 根因
实际导致事件的原因。

## 影响因素
使情况恶化或更难解决的因素。

## 做得好的地方
- [积极观察]

## 可以改进的地方
- [改进领域]

## 行动项
| 行动 | 负责人 | 截止日期 | 状态 |
|--------|-------|----------|--------|
| [行动] | [姓名] | [日期] | [状态] |

## 学到的教训
组织的关键收获。

行动项类型

预防:阻止再次发生
检测:下次更快发现
缓解:发生时减少影响
文档:改进运行手册/文档

优先级:
1. 高影响、低努力
2. 安全必需
3. 减少重复劳动
4. 锦上添花

最佳实践

1. 早宣布事件
   如有疑虑,宣布

2. 先聚焦缓解
   根因分析后做

3. 频繁沟通
   沉默滋生焦虑

4. 实时文档化
   不依赖记忆

5. 练习演习
   真实事件前演练

6. 无责事后分析
   系统失败,而非人

7. 跟踪行动项
   完成承诺内容

8. 定期值班回顾
   改善值班体验

相关技能

  • slo-sli-error-budget - SLOs和告警
  • observability-patterns - 在事件中使用可观测性
  • chaos-engineering-fundamentals - 主动韧性测试