w3b3/incident-response

# 事件响应 ## 01 // 基础 **事件响应真正的作用是什么** 在复杂的分布式系统中，事件是不可避免的。一个团队工程质量的衡量标准不是事件是否发生——而是事件发生时他们的响应速度和响应质量。 1. **事件是正常的。响应失败不是。** — 高绩效团队的事件比低绩效团队更多——因为他们的监控更好，定义事件更早。目标不是零事件。目标是快速发现、快速缓解，以及学习如何防止再次发生。 2. **在事件发生前定义"事件"** — 没有统一的定义，团队会在每个事件的前10分钟争论它是否算是一个事件。事件是指任何影响客户、违反SLO、或需要多个人协调才能解决的非计划事件。 3. **无责文化是必须的** — 当工程师害怕被责备时，他们会延迟升级、隐瞒信息，并撰写经过粉饰的事后分析。责备产生的是合规表演。无责文化产生的是诚实的时间线和系统性修复，从而防止再次发生。 ## 02 // 严重程度分级 **严重程度由客户影响决定，而不是系统状态** 一个CPU跑满的数据库不是事件——如果用户不受影响的话。结账时2%的失败率影响500个付费客户，这就是SEV1。唯一重要的是客户影响。为每个级别附加具体标准和响应SLA——模糊的阈值会导致延迟升级。 | 级别 | 定义 | 响应 | |-------|-----------|----------| | **SEV1** | 影响收入、全面停机或数据丢失 | 全员行动。5分钟内确认，15分钟内分配IC。 | | **SEV2** | 降级但可用——重大客户影响 | 15分钟内确认。SLO快速燃烧。可能存在变通方案。 | | **SEV3** |轻微影响——有变通方案，SLO未受影响 | 1小时内确认。工作时间响应即可。 | | **SEV4** | 无客户影响——内部或 cosmetic | 正常迭代流程。不需要值班通知。 | ## 03 // 角色与指挥 **一群人一起调试不是事件响应** 每个事件在发生前就需要明确指定的角色。当角色是现场临时指定的，协调会崩溃，沟通会停止，最资深的工程师最终会一个人做所有事情。 1. **IC——事件指挥官——协调，不修复** — IC负责整体响应：分配任务、推动沟通、做出范围决策，确保合适的人在现场。IC绝不能陷入技术细节。每个事件一个IC——没有例外。 2. **TL——技术负责人——调查，向上汇报给IC** — TL深入根因，协调SME，执行缓解方案。他们定期向IC汇报状态。当IC和TL是同一个人时，两个角色都会退化——IC会陷入问题中，协调停止。 3. **CL——沟通负责人——负责状态页和利益相关者** — CL处理所有外部和执行层沟通：状态页更新、客户邮件、利益相关者简报。这个角色让IC和TL在他们需要全心专注于缓解时摆脱沟通负担。 4. **OB——观察者进入只读频道** — 每个在活跃事件频道中但不贡献额外人员都会增加噪音并减慢决策。执行官、利益相关者和好奇的工程师在一个单独的只读频道中观察，定期获取IC更新。保持工作频道的小规模。 ## 04 // 沟通 **在客户发推之前更新状态页** 事件期间的沉默会导致客户提交工单、执行官升级、客服队列爆满——所有这些都在最糟糕的时刻增加了负担。沟通不是修复后的礼貌。它是一个积极的缓解工具。 1. **SEV1/SEV2发生15分钟内更新状态页** — 即使信息只是"我们正在调查影响结账的问题"。看到状态页更新的客户会停止提交工单。看不到任何东西的客户会认为你不知情，从而升级到销售、执行官和社交媒体。 2. **有节奏的内部更新——不要临时起意** — IC在SEV1期间每15-30分钟发布结构化更新：当前状态、采取的最后行动、下一步行动、预计时间（如果已知）。节奏防止了管理问题的洪流冲淡技术工作。 3. **预先编写客户消息模板** — 事件期间是从零开始写作的最糟糕时机。维护以下模板："调查中"、"原因已确定，正在修复"、"缓解措施已到位，监控中"和"已解决"。填入空白——不要在压力下起草新内容。 4. **对不同的受众提供适当的详细程度** — 工程频道获取技术细节。状态页获取面向用户的影响。执行频道只获取业务影响和预计时间。发送给执行者的技术细节浪费他们的时间；发送给工程师的模糊影响浪费所有人的时间。 ## 05 // 分诊与缓解 **先恢复服务。理解原因稍后进行。** 活跃事件期间的优先级是让客户回到可用状态——不是找到根因。理解发生在事后。你不完全理解的回滚比你在设计修复方案而用户正受影响时要好得多。 1. **先缓解，后理解** — 根因分析是事件后的活动。事件期间唯一的问题是：什么行动能最快恢复服务？理解导致故障的原因是在客户解封之后，绝不是在事件期间。 2. **回滚是默认的恢复操作** — 如果上一次部署与事件相关，立即回滚——在调查之前。特性开关、蓝绿部署和金丝雀发布的存在就是为了让回滚快速且廉价。在每个事件时间线内维护部署时间线。 3. **每个主要功能都有熔断开关** — 在几秒内禁用昂贵或故障功能的特性开关是一级事件工具。当支付提供商故障时，你需要无需部署就能禁用它。熔断开关必须在事件外测试——如果在事件中发现坏了就毫无用处。 4. **在升级前为调查设时限** — 如果值班人员在30分钟内没有向缓解取得进展，他们就要升级——而不是继续独自调试。时限强制升级路径是真实的、经过测试的且众所周知的。一个工程师阻塞SEV1是组织失败，不是个人失败。 ## 06 // 运行手册与剧本 **每个告警都是一个问题。运行手册是答案。** 没有运行手册的告警会让值班工程师进入事件时没有地图。运行手册不需要很长——它只需要存在、准确，并且从告警直接链接，这样在凌晨3点能在10秒内找到。 1. **每个告警都链接到运行手册——没有例外** — 运行手册必须包含：这个告警意味着什么、前3个要检查的东西、回滚或熔断程序、升级联系人、已知的误报条件。它不需要全面。它只需要存在且正确。 2. **像维护代码一样维护运行手册** — 落后18个月的运行手册比没有更糟糕——它会以虚假的信心将值班人员引向错误的方向。当系统变更时，运行手册会过时。在每次使用它们的事件后审查它们，其他情况下每季度审查。 3. **游戏日让运行手册真实** — 计划的混沌练习——在受控环境中注入故障——在真实事件之前暴露运行手册缺口、破损的升级路径和未记录的依赖。游戏日在为付费客户运行生产SaaS后不是可选的。 **每个运行手册必须包含：** 这个告警意味着什么 · 前3个检查 · 回滚/熔断 · 升级联系人 · 误报标准 · 相关告警 ## 07 // 事后分析 **事件在缓解时结束。工作在之后开始。** 不产生行动项的事后分析是文档剧场。将个人命名为根因的事后分析适得其反。目标是系统性理解以防止再次发生——以及整个组织都能使用的学习成果。 1. **设计上无责** — 人永远不是根因。系统、流程、工具和条件才是。当工程师害怕在事后分析中作为事件原因出现时，他们会写粉饰的时间线。无责文化是获得防止再次发生所需的诚实叙述的唯一方式。 2. **重建完整时间线** — 时间线从第一个可观察的异常到完全解决。它由日志、部署记录、告警时间戳和聊天记录构建——不是记忆。时间线的缺口是可见性的缺口。每个缺口都是后续行动项。 3. **每个行动项都有负责人和截止日期** — 没有负责人和日期的事后分析是一份良好愿望清单。每个促成因素都要映射到具体的补救措施：运行手册更新、监控缺口关闭、熔断开关添加、流程变更。没有负责人和截止日期意味着不会发生。 4. **在组织内部分享事后分析** — 一个团队事件的所学通常与运行类似系统的其他三个团队直接相关。事后分析应该被索引、可搜索、全公司可访问。锁定在一个团队内的部落知识会阻止组织学习。 ## 08 // 值班健康 **可持续的值班是工程需求，不是文化选择** 需要英雄主义才能维持的轮值最终会失败。告警疲劳、倦怠和人员流动是值班不可持续的直接影响值班辛苦是产品缺陷——它属于迭代待办列表，不属于"我们稍后处理"列表。 1. **跟踪MTTD、MTTR和每个工程师每周的告警次数** — 平均检测时间和平均解决时间是事件响应项目的KPI。每个工程师每周的告警次数是值班健康的代理指标。不跟踪它们，改进就看不见，退化也注意不到。每季度向工程组织公布。 2. **值班轮值必须是可持续的——不是英雄主义** — 任何在工作时间外每周被呼叫超过2-3次的工程师都在积累会因疲劳而累积的债务。轮值必须足够大以分配负载。经常在凌晨3点呼叫的值班是系统设计问题，需要工程解决，而不是耐力。 3. **每个轮班边界都有结构化交接** — 每次值班交接涵盖：活跃事件及其状态、最近可能引发问题的部署、下一班已知的风险、以及任何当前被抑制或处于噪音状态的告警。口头或跳过的交接是保证下次出问题时的冷启动缺口。 4. **值班是直接反馈到产品的循环** — 凌晨3点被呼叫处理不稳定集成的工程师拥有任何QA流程都无法复制的关于产品质量的真实情况。值班观察直接进入迭代规划。减少辛苦是产品需求——它提高可靠性、降低成本并留住工程师。 ## 心理模型 *Daniel Brasileiro · [incident-response.w-b.dev](https://incident-response.w-b.dev)*

标签：Rust程序, SaaS, SLO, SRE, 严重级别, 事后复盘, 偏差过滤, 分布式系统, 可靠性工程, 后端开发, 响应大小分析, 团队协作, 工程实践, 库, 应急响应, 故障处理, 无责文化, 服务等级目标, 生产系统, 监控告警, 稳定性, 系统可用性, 运维