事故管理：流程、角色与最佳实践

有效的事故管理，是尽可能降低事故影响、缩短服务中断时间、尽快恢复正常业务运行的关键。如果没有事先演练过潜在事故的应对方案，那么真正遇到事故时，原本清晰的原则和流程很可能会在混乱中失效。

本文将先描述一起因临时、无序处置而逐步失控的事故；随后概述一套妥善的事故管理流程；最后回到同一场景，看看如果采用成熟运转的事故响应机制，结果会有何不同。

未受控的事故：事故响应为何会失控

想象一下，你是玛丽，这家公司的一名值班工程师。周四下午两点，你的寻呼器突然响起。黑盒监控显示，整个数据中心的服务已经停止。你叹了口气，放下咖啡，开始着手修复。

几分钟后，第二条告警响起：第二个数据中心也停止服务。紧接着，五个数据中心中的第三个也崩溃了。更糟的是，剩余数据中心承接的流量已经超过处理能力，开始过载。很快，整个服务彻底瘫痪，无法处理任何请求。

你盯着日志看了很久，仿佛过了几个世纪。成千上万行日志显示，最近更新的某个模块似乎出了问题，于是你决定将服务器回滚到之前的版本。可回滚之后，问题依旧存在。

你打电话给约瑟芬。她编写了这项崩溃服务的大部分代码。她提醒你，在她所在的时区，现在是凌晨三点半，但还是睡意朦胧地答应登录查看。你的同事萨布丽娜和罗宾也开始在各自的终端上检查问题。“我们随便看看。”她们告诉你。

这时，一位公司高管打电话给你的老板，怒气冲冲地质问为什么没人告知他“这项关键业务服务已经彻底崩溃”。与此同时，几位副总裁也不停催问你预计何时恢复，并反复追问：“这怎么可能发生？”

你本想表示理解，但那会耗费宝贵的精力，而你正忙着排障。这些副总裁凭借过去的工程经验，提出了一些看似有道理、实则无关紧要，却又很难当场反驳的建议，比如：“把页面大小调大！”

时间继续流逝，剩下的两个数据中心也彻底瘫痪了。

你不知道的是，睡眼惺忪的约瑟芬又给马尔科姆打了电话。马尔科姆突然想到：也许问题与 CPU 亲和性有关。他确信，只要把这个简单改动部署到生产环境，就能优化剩余服务器进程，于是他照做了。几秒钟内，服务器重启并应用了这项改动。

然后，它们又崩溃了。

事故失控的原因分析

请注意，在上面的场景中，每个人都在努力做好自己的工作。那么，事情为什么会恶化到这种地步？这起事故之所以失控，是由几个常见隐患共同导致的。

过度关注技术问题

我们通常会雇用像玛丽这样技术能力很强的人。因此，她忙于对系统进行操作层面的修改，竭尽全力解决问题，并不令人意外。

但由于眼前的技术任务过于繁重，她已经没有余力从更宏观的角度思考如何控制事故影响、协调资源和推进恢复。

沟通不畅

同样，因为玛丽已经应接不暇，她也无暇进行有效沟通。没有人清楚其他同事正在采取哪些行动。公司领导层愤怒不已，客户怨声载道，而其他本可以协助调试或解决问题的工程师，也没有被有效组织起来。

擅自行动

马尔科姆的出发点是好的，但他在没有与其他人协调的情况下修改了系统，甚至没有与正在主导排障的玛丽沟通。结果，他的改动让原本已经糟糕的局面雪上加霜。

事故管理流程的关键要素

事故管理技能和实践的目的，是将那些积极投入、急于解决问题的人的精力，引导到正确方向。一些海外技术团队的事故管理体系基于事故指挥系统，即 Incident Command System，简称 ICS。这一体系以清晰、可扩展而著称。

一个设计良好的事故管理流程，应具备以下特点。

递归式职责分离

确保事故中的每一位相关人员都清楚自己的职责，并且不越界行事，这一点至关重要。看似有些反直觉，但明确的职责划分反而能赋予个人更大的自主权，因为他们不必反复质疑同事的决定，也不必担心自己的工作被他人随意覆盖。

如果某个成员的工作量过大，该成员应向规划负责人申请增派人手。随后，他们可以将部分工作委派给其他人，这有时可能需要创建子事故。或者，角色负责人也可以将某个系统组件委派给同事负责，由该同事向上汇报关键状态。

事故处理中应将若干不同角色明确委派给具体人员。

事故指挥官

事故指挥官负责掌握事故的整体态势。他们负责组建事故响应团队，并根据需要和优先级分配职责。事实上，所有尚未明确委派的职责，都默认由事故指挥官承担。必要时，他们还应清除阻碍团队高效行动的障碍。

运维执行负责人

运维负责人负责与事故指挥官协作，使用各种运维工具应对事故。在事故处理期间，运维团队应当是唯一可以修改系统的团队。

沟通协调负责人

沟通负责人是事故响应团队对外发声的代表。其职责包括定期向事故响应团队和相关利益方发布更新，通常通过电子邮件完成；也可能包括确保事故文档准确、及时更新等工作。

规划支持负责人

规划角色通过处理较长期的问题来支持运维工作，例如提交缺陷报告、安排餐食、组织交接班，以及跟踪系统偏离正常状态的方式，以便在事故解决后将系统恢复到正常状态。

明确事故响应的指挥中心

所有相关方都需要知道如何与事故指挥官互动。在许多情况下，将事故处理成员集中到一个指定的“作战室”办公，是合适的做法。也有一些团队更倾向于在各自工位上工作，并通过电子邮件和 IRC 持续关注事故进展。

一些海外技术团队发现，IRC 在事故响应中发挥了重要作用。IRC 非常可靠，可以作为事故沟通日志使用，而这样的记录对于掌握详细的状态变化至关重要。相关团队还编写了机器人来记录事故相关的通信内容，以便事后分析；也编写了其他机器人，用于记录频道告警等事件。对于分布在不同地理位置的团队来说，IRC 也是一种便捷的协调工具。

维护实时事故状态文档

事故指挥官最重要的职责之一，是维护一份动态更新的事故文档。这份文档可以保存在 Wiki 中，但理想情况下，应支持多人同时编辑。许多团队会使用在线协作文档工具；不过，负责此类协作文档工具可靠性的团队，往往会选择另一类内部站点工具来承载事故文档。毕竟，在事故管理过程中依赖正处于故障中的软件，通常不是一个好主意。

在实际落地中，团队也可以借助 PingCode 这类智能化研发管理工具，将事故处理过程中的需求、缺陷、任务、发布、测试和复盘知识沉淀到统一的研发流程中，并通过 Wiki 记录关键经验，同时打通研发过程中使用的其他工具，让事故数据、任务状态和后续改进项能够顺畅流转。

可参见“事故状态示例文档”中的事故文档样例。这份动态文档可能并不整洁，但必须实用。使用模板可以简化文档创建过程；将最重要的信息放在文档顶部，可以提升文档的可用性。事故结束后，应保留该文档，用于事后分析；必要时，也可用于更高层面的复盘分析。

建立清晰、实时的交接机制

在工作日结束时，必须明确交接事故指挥官职责。如果需要将指挥权移交给其他地点的人员，可以通过电话或视频通话，将情况清晰、安全地交接给新的事故指挥官。

当新任事故指挥官充分了解情况后，卸任指挥官应明确完成交接，例如说：“你现在是事故指挥官了，明白吗？”只有在对方明确确认之后，才应结束通话。交接信息还应通知给参与事故处理的其他人员，确保所有人始终清楚当前由谁负责事故管理工作。

受控的事故：规范事故管理如何发挥作用

现在，让我们回到同一起事故，看看如果按照事故管理原则来处理，结果会有什么不同。

下午两点，玛丽已经喝到今天的第三杯咖啡。寻呼器刺耳的提示音让她吓了一跳，她赶紧一口喝完咖啡。问题来了：一个数据中心停止服务。她开始调查。很快，第二条告警响起：五个数据中心中的第二个也出现故障。

由于问题正在迅速扩散，玛丽知道，她需要启动现有的事故管理框架。

她一把叫住萨布丽娜：“你能负责指挥吗？”萨布丽娜点头同意。玛丽迅速向她汇报了目前掌握的情况。萨布丽娜将这些细节记录下来，并发送给预先设定好的邮件列表。

萨布丽娜意识到，自己还无法评估事故影响范围，于是请玛丽做一次影响评估。玛丽回复说：“用户目前还没有受到影响；希望我们不要再失去第三个数据中心。”萨布丽娜将玛丽的回复记录到事故日志中。

第三条告警触发时，萨布丽娜在 IRC 调试频道中看到了告警，并迅速在邮件线程中跟进更新。这个邮件线程让副总裁们能够及时了解总体状态，而不必陷入技术细节。萨布丽娜请一位外部沟通负责人开始起草用户通知。随后，她联系玛丽，询问是否应该叫醒值班开发人员，也就是约瑟芬。得到玛丽同意后，萨布丽娜将约瑟芬拉入了事故响应流程。

约瑟芬登录系统时，罗宾也主动提出帮忙。萨布丽娜提醒罗宾和约瑟芬，她们应优先处理玛丽分配的任务；如果准备采取任何其他行动，必须先告知玛丽。罗宾和约瑟芬迅速阅读事故报告，了解当前情况。

这时，玛丽已经尝试过回滚到旧版本二进制文件，但效果并不理想。她低声告诉罗宾，罗宾随即在 IRC 上更新消息，说明这次修复尝试失败了。萨布丽娜将这条更新粘贴到了实时事故管理文档中。

下午五点，萨布丽娜开始寻找接替人员，因为她和同事们即将下班。她更新了事故记录。五点四十五分，团队召开了一次简短电话会议，以便交接当前状态。下午六点，他们将工作移交给另一地办公室的同事。

第二天早上，玛丽回到岗位时发现，大西洋彼岸的同事已经接手了这个缺陷，缓解了问题，关闭了事故，并启动了事后分析。

问题解决后，她给自己煮了一杯咖啡，开始规划结构性改进，防止此类问题再次困扰团队。

何时宣布事故

与其等到问题迅速恶化数小时后才启动事故管理框架，不如尽早宣布事故；如果随后发现解决方案很简单，再结案即可。团队应明确声明事故的触发条件。

我的团队遵循以下几条基本准则。只要满足其中任意一项，就应将其视为事故：

• 是否需要第二个团队参与解决问题？
• 客户是否能够感知到此次故障？
• 经过一小时的集中分析后，问题是否仍未解决？

事故管理技能如果不经常使用，就会迅速退化。那么，工程师如何才能保持事故管理技能的熟练度，从而更好地处理更多事故呢？

幸运的是，事故管理框架也可以应用于其他需要跨时区、跨团队协作的运维变更。如果你将该框架作为变更管理流程的常规组成部分，并经常使用它，那么在真正发生事故时，团队就能更自然地遵循这一框架。

如果你的组织会进行灾难恢复测试，那么事故管理也应成为测试流程的一部分。我们也经常进行角色扮演，模拟处理已经解决的值班问题，有时这些问题是由其他地点的同事解决的。通过这种方式，团队可以进一步熟悉事故管理流程。

总结：用事故管理降低恢复成本

我们发现，提前制定事故管理策略，确保该策略能够平滑扩展，并定期执行这一策略，可以缩短平均恢复时间，也能为员工提供一种压力更小的方式来应对突发问题。任何重视可靠性的组织，都可以从采用类似策略中获益。

事故管理最佳实践

确定优先级。 先止损，恢复服务，并保留证据，以便后续查明根本原因。

做好准备。 事先与事故参与者协商，制定并记录事故管理流程。

建立信任。 给予所有事故参与者在指定角色范围内充分自主权。

保持自省。 在应对事故时，留意自己的情绪状态。如果开始感到恐慌或不堪重负，请寻求更多支持。

考虑替代方案。 定期审视各种选择，重新评估继续当前做法是否仍然合理，或者是否应在事故响应中采用其他方法。

持续练习。 经常使用这套方法，直到它成为团队的本能反应。对于需要跨团队推进任务、维护文档、安排日历、跟踪项目进展和沉淀协作记录的团队，也可以使用 Worktile 这类通用项目协作系统，让事故演练和日常变更管理更容易落到具体任务中。

轮换角色。 上次你担任了现场指挥官吗？这次换个角色。鼓励每位团队成员熟悉每一种角色。