9.3 事件管理

概述与动机

事件管理（Incident management）是检测、响应、解决计划外服务中断，并从中学习的一门学问。每一个非平凡的系统最终都会出问题，因此问题不在于事件是否会发生，而在于你处理得有多好。良好的事件管理能把中断的影响和持续时间控制在最小，在压力下协调人员，对受影响的人诚实沟通，并把每一次故障转化为持久的改进。它把运维就绪、清晰的角色分工、冷静的沟通和一种学习型文化结合在一起。

对于大型团队而言，事件管理正是组织复杂性真正显现威力的地方。一次严重事件可能同时涉及许多服务、若干团队、高管、客户、监管机构和公众，而且是在时间压力和信息不完整的情况下发生的。如果没有一套共享的结构，响应就会陷入混乱：重复的工作、相互冲突的决策、对利益相关者的沉默，以及把人耗尽的孤胆英雄式表现。一套定义清晰的事件流程，能让每个人都有一种已知的方式参与进来，有一个单一的真实来源，以及清晰的决策权威，这样一大群人才能在危机中协调一致地行动。

企业和政府所面临的风险很高。金融服务业对重大中断有监管报告的截止期限。医疗保健领域的事件可能影响患者安全。政府服务的故障可能导致公民无法领取福利、申报税务，或联系不上紧急服务。公众问责意味着停机是可见的、会被仔细审视的。可持续的待命（on-call）实践也是一种关怀义务：人手不足、管理不善的轮值会造成职业倦怠和人员流失，最终会让可靠性变得更差。因此，事件管理正处在运维卓越、人员福祉和制度信任三者的交汇点上。

另见： 第 9.1 章（站点可靠性工程）、第 9.2 章（可观测性与监控），以及第 1.1 章（工程文化：无责的、以学习为导向的事件文化）。

关键原则

结构胜过英雄主义。 一套明确的指挥结构能让许多人协调行动；依赖少数英雄无法扩展，还会把他们耗尽。
角色而非头衔。 在一次事件中，诸如事件指挥官（incident commander）和沟通负责人这样的清晰角色，比组织中的职级更重要。
早沟通、常沟通。 对利益相关者频繁、诚实的更新能建立信任，即便消息是坏消息；沉默则会摧毁信任。
把协调与调查分开。 负责指挥事件的人，不应同时埋头调试问题。
待命必须是可持续的。 轮值、补偿和负荷上限保护着那些守护系统的人。
默认无责。 人们会依据自己当时所知采取合理的行动；归咎于人会掩盖真正的、系统性的原因。
学习才是重点。 一次没有产生任何持久改进的事件，就是白白承受了一次痛苦。
保存组织记忆。 事后总结（postmortem）及其行动项必须是可查找、可复用的，而不是一周后就被遗忘。

建议

运行可持续的待命轮值

把待命设计得既人性化又有效。保持轮值规模足够大，使得没有人被排得太频繁；设置主值班和二线（升级）两个层级；对确认和响应时间设定清晰的预期。公平地补偿待命工作，无论是通过报酬还是调休，把它当作真正的工作来对待。跟踪每一班的告警负荷，把一个嘈杂到摧毁睡眠的轮值当作一个需要修复的缺陷（）通过减少假告警来修复，而不是把它当作常态。在能做到的地方按时区轮转（follow the sun），让人们在自己清醒的时段待命。确保每一位待命工程师都有操作手册（runbook）、访问权限和采取行动的权力，并且要有意识地在换班交接时传递上下文。

建立事件指挥体系和严重程度等级

采用一套受应急响应启发的事件指挥体系。事件指挥官（incident commander） 负责协调和决策，而不是技术层面的修复本身。他们负责分派任务、跟踪行动，并推动响应持续进行。辅助角色包括指导实际调查工作的运维或技术负责人、负责内外部更新的沟通负责人，以及记录时间线的记录员（scribe）。定义严重程度等级（例如 SEV1 代表严重、影响广泛或涉及安全的中断，一直到 SEV3 代表次要问题），并给出清晰的判定标准，因为严重程度决定了谁会被呼叫、响应速度有多快，以及组织内有多大范围会被动员起来。任何人都应该能够宣布一次事件，而且应该宁可多宣布，也不要少宣布。

在事件期间进行内部和公开沟通

设立一个单一的协调频道作为真实来源，并按固定节奏发布更新，即使更新内容只是”仍在调查中”。在内部，通过沟通负责人让领导层和受影响的团队随时了解情况，这样响应人员就不会被打断。在外部，使用状态页面，对于重大事件，还要发布对客户或公众的通知，如实说明影响和预期解决时间，不做过度承诺。对于受监管的服务和政府服务，要提前了解强制报告的义务和截止期限，并准备好相应的模板。目标是让利益相关者始终从你这里听到的信息，多于从谣言中听到的。

举行无责事后总结，并推动纠正措施落实

在任何重大事件之后，撰写一份无责事后总结：一份基于事实的时间线、影响、促成因素、做得好的地方、做得不好的地方，以及运气好的地方。“无责”意味着它关注的是系统和流程如何导致了这次故障，而不是该惩罚谁，因为心理安全感才是产生诚实叙述和真正学习的关键。每一份事后总结都应产出带有负责人和截止日期的纠正措施，并按其对未来风险的影响排定优先级。在常规的工程待办事项列表中跟踪这些措施直至完成。一份行动项从未落实的事后总结，只是一场表演。

从事件中学习，构建组织记忆

单次的事后总结是必要的，但仅靠它们并不足够。要汇总审视各次事件，找出反复出现的主题、系统性的薄弱环节，以及值得进行结构性修复的故障类别。让事后总结变得可搜索，并广泛分享，这样经验教训才能跨越团队边界传播。把学到的东西反馈到操作手册、培训、架构评审和生产就绪标准中。考虑定期进行可靠性评审，以及演练响应、在真实事件发生之前就暴露缺口的演习日（game day）或混沌工程演练。把你积累的事件记录当作一项承载着来之不易的运维知识的战略资产来对待。

权衡：优点与缺点

决策	优点	缺点
正式的事件指挥体系	响应协调、可扩展	对小型事件而言开销较大
宣布事件的门槛较低	能及早发现问题	偶尔会出现误报
公开的状态透明度	建立信任，减少谣言	暴露故障，招致审视
无责事后总结	诚实的学习、安全感	若使用不当，可能显得缺乏问责
大规模的待命轮值	可持续、倦怠更少	需要更多经过培训的人员，稀释了上下文

核心权衡在于流程开销与协调收益之间。一套重型的事件结构，在一次横跨多个团队的 SEV1 事件中极具价值，但对一次小小的波动来说就是杀鸡用牛刀，所以要根据严重程度来调整流程。透明度用短期的尴尬换取长期的信任。在中断期间坦诚沟通的组织，通常比那些保持沉默的组织保留更多的善意。“无责”有时会被误解为缺乏问责，但它所要求的问责是集体性、系统性的：团队要负责修复那些导致故障发生的条件，这比把责任推给某个个人要有效得多。

与团队讨论的问题

有多少人能够担任事件指挥官，你能说出三个不是高级管理者的名字吗？ 依赖一两个英雄来拯救每一次事件是脆弱的，而且必然会导致他们的倦怠；事件指挥官这个角色关乎协调，而不是技术职级，所以它不应该默认总落在同样那几位资深人士身上。带上花名册来参与讨论：列出每一个受过培训、能担任指挥官角色的人，以及他们上一次真正担任这个角色是什么时候。对于一个大型组织而言，一次严重事件可能在凌晨三点跨越许多团队爆发，你需要在每个时区都有一位受过培训、随时可用的指挥官，而不是一位正在睡觉的单一专家。轮换这个角色，让新的指挥官通过演习日来历练，从而让这项技能得以扩散。这个问题的答案，能告诉你的响应能力是随组织一起扩展的，还是一旦你最出色的人不在场就会崩溃。
你们知道自己强制性的停机报告截止期限吗，模板和负责人是否已经在下一次 SEV1 到来之前准备就绪？ 金融服务业对重大停机有监管报告截止期限，医疗保健领域的事件涉及患者安全，政府服务的故障会阻碍公民领取福利或联系紧急服务，因此错过一个报告窗口，会把一次技术性中断变成一个法律问题。在一次 SEV1 事件正酣之时，才发现自己只有四个小时要通知监管机构、却没有模板，是最糟糕的时机。带上真实的义务清单：哪些监管机构、哪些阈值会触发报告、截止期限是什么、谁有权提交。提前把这项工作指派给沟通负责人的角色，这样响应人员就永远不会被从修复工作中抽走去起草一份申报文件。答案应该是准备就绪的模板、一位指定的负责人，以及一个能自动触发报告倒计时的严重程度等级。
你们上一次通过演习日演练重大事件是什么时候，暴露出了什么缺口？ 演习日和混沌工程演练能在真实事件发生之前，演练响应流程并暴露缺口，而本章所描述的成熟终态，是流畅、经过充分演练的响应，而不是在压力下临场发明的响应。一个从未演练过的计划，隐藏着已经失效的假设：过时的操作手册、缺失的访问权限、一条走进死胡同的升级路径、一个没人能更新的状态页面。带上上一次演习的发现；如果从未做过演习，那么这本身就是一项发现。对于停机会受到公众审视的企业和政府系统而言，演练正是你展示专业能力的方式，而不是在公民和监管机构面前临场发挥。答案应该确定演习日的节奏，并把每一个暴露出的缺口都反馈进操作手册、访问权限审查和生产就绪标准中。
你们负荷最重的轮值实际告警量是多少，你自己愿意背这个传呼机吗？ 一个嘈杂到摧毁睡眠的轮值是一个缺陷，而不是一枚荣誉勋章；告警疲劳正是响应人员错过或迟缓确认真正紧急情况的根源，因此人性化的问题和可靠性的问题其实是同一个问题。与之相抗衡的压力在于，削减告警似乎意味着降低警惕，但实际上，泛滥的假告警对警惕性的削弱要严重得多。带上具体数字：每班的告警数量、有多少是在工作时间之外触发的、有多少是可采取行动的，以及那些真正重要的告警的确认时间。为每班设定一个明确的告警上限，把任何超出上限的轮值都当作需要通过调优或删除告警来修复的工作。对于大型组织或政府机构而言，可持续的待命既是一种关怀义务，也是一个留才的杠杆，因为承载着不可替代的系统知识的资深工程师，恰恰是那种残酷轮值最容易赶走的人，而重建那些知识的成本，远高于以人性化的方式配置轮值的成本。
上个季度的纠正措施中，有多大比例真正完成了，未完成时由谁负责？ 一份行动项从未完成的事后总结，会让同样的事件再次发生，因此区分真正的学习与表演的，不是文档写得好不好，而是修复措施是否真的上线了。这里的张力在于，纠正措施要与功能开发在同一个待办事项列表中竞争，如果没有指定的负责人、截止日期和复审节奏，它们会在每一场优先级争夺战中悄悄败下阵来。带上台账：最近几次事后总结中的每一项行动、其负责人、截止日期和状态，再加上因修复停滞而再次发生的事件数量。在常规的工程待办事项列表中跟踪这些措施，并把完成率作为一项对照基线的指标来复审，这样滞留或被放弃的行动项就会浮出水面，而不是悄悄消失。在企业和政府环境中，一次已报告的停机之后未完成的纠正措施，正是审计人员或监督机构会抓住不放的那种发现，因此完成度既是一项工程保障，也是一个可证明的问责问题。
每个人是否都感到可以安心地及早宣布事件、并在事后总结中诚实发言，还是对被归咎的恐惧拖慢了他们？ 无责文化正是产生揭示系统性原因的诚实叙述的关键，而较低的宣布门槛正是在问题还很小时就能捕获它们的关键，二者都依赖于人们不担心举手会给自己带来不利后果。与之相抗衡的担忧是，“无责”会被解读为缺乏问责，但它所要求的问责是集体性的：团队要负责修复那些导致故障发生的条件，而不是把责任推给最后一个接触过它的人。带上你能实际观察到的证据：事件被宣布的速度有多快，相比之下问题在被宣布之前又酝酿了多久；初级工程师是否曾经宣布过事件；事后总结指出的是促成条件，还是悄悄点名某个人。对于一个大型或公开的组织而言，心理安全感是脆弱的，很容易被一次以归咎为导向的复审，或一位惩罚报信者的领导所摧毁，所以要留意人们正在绕开这套流程的信号，并把诚实的及早宣布当作一种需要保护的行为，而不是一种需要管理的风险。

分行业视角

初创公司。 只有为数不多的几名工程师，也没有多余的资源，把流程压缩到一页纸：谁发现谁宣布，一人协调，一人调查，一人告知客户，其他人一律不碰生产环境。跳过你们养不起的正式严重程度分级和专职角色，但一定要写那份无责的一页纸总结，因为在你们这个规模上，一次反复出现的故障就可能拖垮你们。依靠托管的状态页面和呼叫工具，而不是自己构建协调工具。

小型企业。 你们没有专职的可靠性专家，预算也紧张，所以要购买嵌入在你们已经付费使用的监控和呼叫服务中的事件工具，而不是自己构建。把待命当作一项共同的职责来对待，设定清晰、人性化的上限，这样它就不会把仅有的一两个懂系统的人耗尽。写简短的事后总结，并真正完成修复，因为在一个小团队里，一次重复的停机会让你失去那些不容易替代的客户。

企业。 挑战在于如何在压力下协调众多团队，因此要把事件指挥体系、共享的严重程度标准和单一真实来源标准化，这样一次跨越多个服务的 SEV1 才不会四分五裂。在每个时区投入培训指挥官，把事后总结汇总成一个可搜索的组织记忆库，并以负责人和审计轨迹来治理纠正措施直至完成。把待命负荷作为一项全公司范围的指标来管理，这样就不会有任何一个轮值悄悄变得不人道。

政府。 采购规则、透明度和公众问责塑造着响应方式。提前了解你们强制性的停机报告截止期限和阈值，准备好申报模板和一位指定的、有权限的负责人，发布如实的状态更新和呼叫中心话术，这样公民就永远不会被蒙在鼓里。在整个机构内分享事后总结，把它们反馈进高峰时段的韧性规划中，把过往事件的记录当作证据，向监督机构展示故障已经产生了持久的修复。

示例

初创公司。 一家六人规模的初创公司在醒来时发现其 API 正在返回错误，所有人一下子都涌进了同一个聊天线程。被这场混乱折腾够了之后，他们写下了一页纸的事件基础流程：谁发现谁宣布事件并成为协调人，一人负责调查，一人向客户发布简明的更新，其他人一律不碰生产环境。下一次停机进行得很冷静，四十分钟内就解决了。一份简短的无责总结发现是一次迁移在没有备份步骤的情况下运行了，他们当天就把这项检查加入了部署脚本。

企业。 一家大型软件即服务（SaaS）提供商在工作时间内遭遇了部分停机。值班工程师宣布了一次 SEV1，一位事件指挥官接管协调工作，技术负责人展开调查，沟通负责人每二十分钟在公开状态页面上发布一次更新。高管们跟随一个领导层专用频道，而不是打断响应人员。服务在九十分钟内恢复。一周后的无责事后总结发现部署流水线中缺少一项保护措施，并产生了三项带有负责人的纠正措施。后续的汇总审视显示，这已是该季度第三次与部署相关的事件，这促成了一项针对更安全发布方式的结构性投资。

政府。 一家福利机构的支付系统在一个高流量的日子出现故障，导致公民无法领取补助。该机构的事件流程动员了一位指挥官、技术响应人员，以及一位负责协调公众消息发布的沟通负责人，并在规定的窗口期内满足了报告重大停机的监管要求。一个状态页面和呼叫中心话术让公民和员工都能随时了解情况。这份在全机构范围内共享的无责事后总结，把经验教训反馈进了操作手册和一次生产就绪评审，而过往事件的积累也为次年高峰时段的容量和韧性规划提供了依据。

商业论证：动机、投资回报率与总拥有成本

成熟事件管理的回报体现为每次事件影响的降低和重复事件的减少。更快、协调更好的响应能缩短停机时间，这直接节省了收入、罚款和补救成本。有纪律的事后总结和纠正措施会持续地消除整类故障，因此事件发生率会随时间下降。可持续的待命能降低资深工程师倦怠和流失所带来的巨大、往往隐性的成本，而这些工程师替换成本高昂，又承载着不可替代的系统知识。

相对于收益而言，采用这套做法的成本是有限的：事件指挥方面的培训、用于协调和状态沟通的工具、花在事后总结上的时间，以及维持人性化轮值所需的人员配置。而不采用这套做法的代价则是严重且持续的：混乱的响应会拖长停机时间，沉默会侵蚀客户和公众的信任，错过报告期限会招致监管处罚，无人完成的行动项会导致事件反复发生，待命人员也会士气低落。要向领导层论证这一点，就按持续时间和影响量化最近的事件，展示协调和完成的纠正措施本可以如何缩短这些事件或防止重演，并把可持续待命定位为留才和风险管理，而不是一种放纵。

反模式与陷阱

英雄文化。 依赖一两个人来拯救每一次事件是脆弱的，而且必然导致他们的倦怠。
没有明确的指挥官。 没有人负责协调，响应人员就会重复工作、发生冲突，并丢失时间线。
陷入沉默。 在停机期间不发布更新，会滋生谣言、恐慌和持久的不信任。
归咎游戏。 惩罚个人会把诚实逼到地下，掩盖你需要修复的系统性原因。
事后总结表演。 撰写行动项从未完成的事后总结，只会让同样的事件再次发生。
告警疲劳的待命。 嘈杂的轮值会耗尽响应人员，使他们错过或迟缓确认真正的紧急情况。
严重程度混乱。 未定义或应用不一致的严重程度等级，导致对严重事件响应不足、对次要事件响应过度。

成熟度模型

第 1 级，启动。 事件由谁发现就由谁临时处理，响应是被动的、临场发挥的。没有明确的角色、严重程度等级或事后总结。待命即便存在，也是非正式的、令人压力山大的，同样的故障反复发生，因为没有学到任何持久的东西。

第 2 级，发展。 存在基本的待命轮值和严重程度定义，一些事件会有事后总结，但各团队的做法并不一致。响应过程中角色不清晰，一个团队可能运行得井井有条，而下一个团队却陷入混乱，纠正措施的跟踪即便存在，也是随意的。

第 3 级，标准化。 一套带有清晰角色和严重程度标准的正式事件指挥体系被记录下来，并在整个组织中被一致地使用。无责事后总结是重大事件的标准做法，纠正措施带有负责人和截止日期被记录在案，待命有相应补偿，单一协调频道和状态页面的做法在全组织范围内被强制执行，而不是任由每个团队自行其是。

第 4 级，管理。 事件项目对照基线进行度量和控制。你跟踪检测时间、确认时间、解决时间、每班告警数、纠正措施完成率和重复事件率，并按节奏复审这些指标以发现退化。严重程度等级被足够一致地应用，使得数据可信；告警负荷被控制在一个明确的上限之下；事件期间和事件之后的通过或不通过决策由证据驱动，而不是直觉驱动。

第 5 级，编排。 事件管理持续改进，并在整个组织范围内实现集成。通过定期的演习日，响应变得流畅、经过充分演练；汇总分析推动能够消除整类故障的结构性投资；事后总结形成一个可搜索的组织记忆库，反馈进操作手册、培训、架构评审和容量规划中。这个体系随着自身的成长而适应，事件发生率和影响随时间呈下降趋势。

讨论思路

区分你们各个严重程度等级的标准是什么，每个人应用这些标准的方式是否一致？
随着系统的增长，你们如何在不无休止地增加人手的情况下保持待命的可持续性？
在一次正在进行的事件中，谁有权做出代价高昂的决策，比如故障切换或回滚？
在停机期间，你们对客户和公众应该保持多大程度的透明，界限又在哪里？
你们如何确保纠正措施真正得到完成，而不是在待办事项列表中被搁置？
要把你们积累的事后总结变成一个真正可复用的组织记忆库，需要付出什么？

关键要点

每个系统都会出故障；成熟度衡量的是你响应和学习的能力，而不是避免一切事件的能力。
一套带有明确角色和严重程度等级的清晰事件指挥结构，能让一大群人在压力下协调行动。
对内部和外部利益相关者及早、频繁、诚实地沟通；沉默会摧毁信任。
通过公平的轮值、补偿，以及不懈地减少嘈杂告警，来保持待命的可持续性。
开展无责事后总结，产出有明确负责人、被跟踪的纠正措施，并把它们完成。
汇总学习和可搜索的组织记忆，能把单次事件转化为持久的改进。

参考资料与延伸阅读

Betsy Beyer et al., Site Reliability Engineering (chapters on incident management and postmortems)
Betsy Beyer et al., The Site Reliability Workbook (on-call and incident response practices)
John Allspaw, Blameless PostMortems and a Just Culture (Etsy engineering)
Sidney Dekker, The Field Guide to Understanding Human Error
Charles Perrow, Normal Accidents: Living with High-Risk Technologies
U.S. Federal Emergency Management Agency, Incident Command System (ICS) reference materials
PagerDuty, Incident Response Documentation (open-sourced practices)