PrekshaShah2509/incident-response-runbook

# 事件响应手册 一份供工程团队使用的、全面且可复刻改编的事件响应手册。它涵盖了完整的事件生命周期：在系统故障前的准备工作、检测与分类、执行响应、沟通、恢复以及事后复盘。 大多数事件响应的失败并非技术原因。它们往往是在压力下做出的决策：谁负责指挥、什么情况才算严重、谁需要知情，以及在事件关闭前必须达成什么结果。本手册提前确定了这些决策，从而让响应过程变成纯粹的执行，而非即兴发挥。 ## 目录 1. [事件生命周期](#incident-lifecycle) 2. [准备清单](#preparedness-checklist) 3. [检测与告警](#detection-and-alerting) 4. [严重性分类](#severity-classification) 5. [角色与职责](#roles-and-responsibilities) 6. [事件处理期间](#during-the-incident) 7. [沟通](#communication) 8. [解决与恢复](#resolution-and-recovery) 9. [复盘](#postmortem) 10. [事件指标](#incident-metrics) 11. [深度指南](#deep-dive-guides) 12. [模板](#templates) 13. [根据公司规模调整](#adapting-by-company-size) 14. [使用说明](#how-to-use) 15. [贡献](#contributing) 16. [许可证](#license) ## 事件生命周期 ``` Prepare -> Detect -> Declare -> Respond -> Resolve -> Learn | | | | | | runbooks alerting severity mitigate verify postmortem on-call triage and IC and comms recovery and actions ``` 每个阶段都包含一些提前决定成本远低于临时决定的决策。以下各部分为每个阶段提供了相应的检查清单。 ## 准备清单 在事件发生前所做的工作决定了事件的走向。详见 [guides/preparedness.md](guides/preparedness.md)。 ### On-Call 基础 - [ ] 定义了包含主要负责人和指定备选人员的 On-call 轮班机制 - [ ] On-call 时间表已发布并对全团队可见 - [ ] 寻呼工具已配置并进行了端到端测试 - [ ] 工作时间之外也能确实联系到每一位 On-call 工程师 - [ ] 定义了 On-call 补偿或调休政策 - [ ] 记录了轮班之间的交接流程 ### 就绪状态 - [ ] 定义了事件协调渠道并确保所有人都知晓 - [ ] 定义了事件指挥官的轮换或指定方法 - [ ] 严重性定义已记录在案，并附有具体示例 - [ ] 为每个严重级别定义了升级上报路径 - [ ] 服务归属已明确映射：每个关键服务都有指定的负责人 - [ ] 响应人员可访问生产环境诊断工具 - [ ] 紧急破窗访问流程已定义并经过审计 - [ ] 状态页面已配置并完成测试 ### 演练 - [ ] 针对过去发生过的事件，至少进行过一次桌面演练 - [ ] 定期安排故障注入演练或 Game Day - [ ] 新响应人员在主导事件前先进行跟班学习 - [ ] 为每个服务最可能出现的故障模式编写了相应的 Runbook ## 检测与告警 你无法响应你检测不到的问题。详见 [guides/detection-and-alerting.md](guides/detection-and-alerting.md)。 ### 告警质量 - [ ] 告警需与面向客户的症状挂钩，而不仅仅是内部指标 - [ ] 每个告警都必须是可操作的：它能告诉响应人员该检查什么 - [ ] 告警阈值经过调优，以减少噪音和误报 - [ ] 审查告警疲劳：修剪或修复嘈杂的告警 - [ ] 每个告警都链接到相关的 Runbook 或仪表板 - [ ] 关键路径具备合成监控或端到端监控 ### 分诊 - [ ] 首席响应人员能在几分钟内确认影响范围 - [ ] 响应人员能够看到最近的变更（部署、配置、开关） - [ ] 依赖项的健康状况是可观测的，并能进行归因分析 - [ ] 存在明确的“这算不算事件”的界定标准 ## 严重性分类 严重性由客户和业务影响决定，而不是由修复难度决定。完整矩阵详见 [guides/severity.md](guides/severity.md)。 | 级别 | 定义 | 示例 | | :--- | :--- | :--- | | SEV1 | 严重。正在发生大规模中断或数据丢失，已确认对收入或安全造成影响。 | 核心服务宕机、正在发生的数据损坏、正在进行的安全漏洞攻击。 | | SEV2 | 主要。存在严重降级但有应对方案，或部分客户完全受阻。 | 关键功能不可用、错误率升高、单一区域宕机。 | | SEV3 | 次要。影响有限或仅为表面问题，没有客户完全受阻。 | 非关键 endpoint 响应缓慢、单租户边缘情况、内部工具降级。 | - [ ] 严重性定义已记录并共享 - [ ] 每个级别编写了二到三个真实案例 - [ ] 定义了分歧处理规则：在证据表明可以降级之前，按较高级别处理 - [ ] 指定了严重性级别的决策者（通常是事件指挥官） ## 角色与职责 对于 SEV1 和 SEV2，必须在开始时明确指定这些角色。在小型团队中，一个人可以担任多个角色，但仍需大声明确说出这些角色的分配。详见 [guides/roles.md](guides/roles.md)。 - [ ] 指定 **事件指挥官 (IC)**。负责整体响应，而非具体修复。负责决策和委派。不参与 Debug。 - [ ] 指定 **运维负责人**。主导技术调查和修复。 - [ ] 指定 **沟通负责人**。负责向利益相关者和客户发布更新。 - [ ] 指定 **记录员**。记录观察到的情况、做出的决策以及对应的时间轴。 - [ ] 每个角色都清楚自己负责什么、不负责什么 - [ ] 如果 IC 需要交接，必须有备选人员可用 ## 事件处理期间 实时响应。快速参考卡详见 [checklist/quick-reference.md](checklist/quick-reference.md)。 ### 最初的 5 分钟 - [ ] 宣布发生事件并分配严重性级别 - [ ] 指定事件指挥官 - [ ] 开启专用的事件沟通渠道 - [ ] 确认范围：谁受到了影响、从什么时候开始的、最近发生了什么变更 - [ ] 开始记录时间轴 ### 稳定局势 - [ ] 首先缓解。在追究根本原因之前先恢复服务 - [ ] 考虑最快且安全的手段：回滚、feature flag、扩容、failover - [ ] 未经 IC 签字同意，避免在活跃的 SEV1 事件中进行风险大、猜测性的修复 - [ ] 将所有决策保留在事件渠道中 ### 协调 - [ ] 由一个人（即 IC）代表响应团队对外发声 - [ ] 响应人员在采取行动前需先说明他们将要做什么 - [ ] 分配并行的调查任务，而不是即兴发挥 - [ ] 记录员保持时间轴是最新的 ## 沟通 按时发布简短的更新胜过迟到的详细更新。详见 [guides/communication.md](guides/communication.md)。 | 级别 | 内部更新 | 外部更新 | | :--- | :--- | :--- | | SEV1 | 每 30 分钟 | 确认客户受到影响后立即更新，随后按固定间隔更新 | | SEV2 | 每 60 分钟 | 如果客户受到影响则更新 | | SEV3 | 解决时 | 通常无需更新 | - [ ] 开始并保持内部更新节奏，即使没有新消息 - [ ] 确定外部沟通的负责人 - [ ] 如果客户受到影响，需更新状态页面 - [ ] 根据严重性阈值通知领导层 - [ ] 将“无变化，仍在调查中”视为有效的更新 - [ ] 确保支持团队和面向客户的团队保持信息同步 ## 解决与恢复 - [ ] 确认客户影响已结束，而不仅仅是清除了告警 - [ ] 跟踪临时的缓解措施，以便进行彻底修复 - [ ] 如果数据存在风险，需验证数据完整性 - [ ] 正式结束沟通节奏 - [ ] 状态页面恢复正常 - [ ] 标记事件为已解决，并记录结束时间 - [ ] 在事件关闭前排定复盘会议 ## 复盘 对事不对人。目标是找出系统和流程本应展现出什么，而不是追究谁漏掉了它。模板见 [templates/postmortem.md](templates/postmortem.md)，详见 [guides/postmortem.md](guides/postmortem.md)。 - [ ] 在规定的窗口时间内安排复盘会议 - [ ] 根据事件记录重构时间轴 - [ ] 量化客户影响 - [ ] 将促成因素作为客观条件记录下来，而不是归咎于个人 - [ ] 记录做得好的地方，而不仅仅是失败之处 - [ ] 行动项有明确的负责人和截止日期 - [ ] 至少记录一项**监控埋点变更**行动项 - [ ] 持续跟踪行动项直至完成，而不仅仅是归档了事 ## 事件指标 跟踪趋势，而非单一数字。详见 [guides/metrics.md](guides/metrics.md)。 | 指标 | 告诉你的信息 | | :--- | :--- | | MTTD (平均检测时间) | 你发现问题的速度。较长的 MTTD 指向检测盲区。 | | MTTA (平均响应时间) | 寻呼机制和 On-call 是否在起作用。 | | MTTR (平均解决时间) | 整体响应的健康度，需作为趋势来观察。 | | 按严重程度统计的事件数 | 系统是变得越来越稳定还是越来越不稳定。 | | 复发率 | 复盘是否真正防止了重复事件的发生。 | | 产生埋点变更的事件比例 | 经验教训是否正在转化为系统的可观测性。 | ## 深度指南 | 指南 | 涵盖内容 | | :--- | :--- | | [guides/preparedness.md](guides/preparedness.md) | On-call、归属权、Game Day、事件发生前的准备。 | | [guides/detection-and-alerting.md](guides/detection-and-alerting.md) | 可操作的告警、分诊、减少噪音。 | | [guides/severity.md](guides/severity.md) | 严重性矩阵、边缘情况、分歧处理。 | | [guides/roles.md](guides/roles.md) | 深入探讨 IC、Ops、Comms、Scribe。 | | [guides/communication.md](guides/communication.md) | 内部和外部沟通、状态页面、领导层。 | | [guides/postmortem.md](guides/postmortem.md) | 无指责复盘与行动纪律。 | | [guides/metrics.md](guides/metrics.md) | 测量什么以及如何解读。 | | [guides/scaling-by-company-size.md](guides/scaling-by-company-size.md) | 从初创公司到企业平台如何调整该 Runbook。 | ## 模板 | 模板 | 用途 | | :--- | :--- | | [templates/incident-report.md](templates/incident-report.md) | 实时事件记录。 | | [templates/postmortem.md](templates/postmortem.md) | 无指责复盘。 | | [templates/status-update.md](templates/status-update.md) | 内部和外部更新的措辞。 | | [templates/severity-matrix.md](templates/severity-matrix.md) | 填写严重性定义。 | | [templates/on-call-handoff.md](templates/on-call-handoff.md) | 轮班交接。 | 实战案例位于 [examples/](examples/) 目录：包含一次处理得当的事件、一次处理糟糕的事件，以及从中得出的经验教训。 ## 根据公司规模调整 从 5 人的初创团队到企业级平台组织，其结构都是相同的。变化的是每个角色由多少人担任，以及流程的正式程度。有关初创、中型、大型和企业级团队的配置详见 [guides/scaling-by-company-size.md](guides/scaling-by-company-size.md)。 无论规模大小都不变的是： - 严重性由影响决定，绝非由修复的难度决定。 - 指定一名总指挥，他们负责决策而不是 Debug。 - 在追究根本原因之前先恢复服务。 - 即使没有新消息，也要保持更新节奏。 - 每次复盘都必须产出监控埋点变更，否则同类事件还会发生。 ## 使用说明 1. **采用：** 将此代码库 fork 到你自己的仓库中，存放在 `docs/` 或 `incidents/` 目录下。 2. **填充：** 填入严重性示例、On-call 轮班和协调渠道。 3. **选择规模：** 阅读扩展指南，并根据实际情况进行删减或规范化。 4. **演练：** 在正式投入实战前，针对过去的事件进行一次桌面演练。 5. **改进：** 在每次 SEV1 和 SEV2 事件后审查book。它是否与实际响应的需求相匹配？ ## 许可证 MIT。详见 [LICENSE](LICENSE)。随意使用、改编并发布。欢迎注明出处，但不作强制要求。 由工程主管 Preksha Shah 维护。更多工程实践与文章请访问 [preksha-shah.vercel.app](https://preksha-shah.vercel.app) 和 [LinkedIn](https://www.linkedin.com/in/preksha-shah-065552183/)。

标签：IT服务管理, 团队协作, 库, 应急响应, 文档模板, 运维, 防御加固