如何确保团队能有效面对与处理事故?

先前我们在 软件工程师该如何值班 (on-call)? 一文谈到工程师可以如何做好轮班以应对事故，也在 软件工程师该如何做好事故检讨? 谈过事故之后如何有效做好检讨。不过在这两篇文章之前，还有一个主题是工程团队必须面对的，那就是「如何确保团队能有效面对与处理事故」。

Google 的 SRE 专书中把事故响应管理 (Incident Response Management) 拆成三个阶段，分别是准备 (Prepare)、响应 (Response) 与学习 (Learn)。把这三阶段对应到先前的主题文，软件工程师该如何值班 (on-call)? 一文在谈响应、 软件工程师该如何做好事故检讨? 一文在谈学习，在这篇文章，我们会专注来谈如何做好准备。

建立让团队能顺利应对事故的基础

事故处理不能等到真的发生事故时才采取行动，如果事前的准备做得够充足，当事故真的发生了，团队将能用从容的方式应对，也能更快速有效地解决事故。这也是为什么，推荐团队务必要先做好准备、建置能顺利应对事故的基础。

降低事故处理时的噪音

如同上方 Google 的 SRE 专书中的附图，在事故响应 (Response) 阶段的最开始是检测事故 (Detect)。理想的状况下，事故应该由系统自动检测，如果等到终端用户回报，那往往会太慢。如果要让系统能有效检测到事故，就需要做好监控相关的设置。

在实际工作中，设置监控最常见的问题，是先前在 软件工程师该如何做好监控 (monitoring)? 一文中我们有谈过的告警风暴 (alert storms)。试想，假如今天负责轮班的工程师，三不五时就收到告警说有事故，然后每次排查后都发现是虚惊一场，这类噪音不仅消耗轮班工程师的时间，还可能会让心态因此松懈 (收到告警时可能会觉得又是假告警，就不认真应对)。

因此，要让事故处理时，负责轮班的工程师能够最有效针对问题解决，其中最关键的点是要降低事故处理时的噪音。

要让告警的噪音降到最低，就意味着不该什么都设成告警。实际工作中推荐的做法可以从两个角度切入。第一个是优先针对 SLO 来设置会打扰值班人员的告警 (备注：对 SLO 不熟的读者，可以回顾 SLO 是什么? 为什么 SLO 对软件团队很重要? 一文)；至于不直接影响 SLO 的信号，则可以放在仪表板、低优先级通知，或作为排查时的辅助信息，而不是一律升级成需要即时处理的告警。第二个则是要明确设置优先级 (例如 P1、P2、P3)，并明确设定哪些是值班人员该处理的 (例如到 P4 就不该劳烦值班人员)

在每次收到假告警时，值班人员也要回过头来调整，例如把相关告警静音，或者调整发出告警的阈值，确保未来不会再出现类似的假告警。除此之外，在设置告警时，要去梳理告警之间的关系，避免类似的告警同时出现，造成过多噪音。

让缓解问题能加速的基础

除了降低告警噪音之外，团队也需要建立一些能加速排查与缓解问题的基础。这些准备平常看起来可能不紧急，但在事故真的发生时，往往会能协助团队快速止血。

其中最重要的一项准备，是为团队建立事故处理指南 (runbook)，在指南中要清楚注明针对每种告警都有对应的处理建议 (例如当 X 告警发出，建议优先查看 Y)。在指南中要清楚明定不同的分级，例如哪些事故属于 P1 要立即应对、哪些是属于 P4 事故，可以不用当下立刻处理，可以先注记即可。

团队也要确保这本指南随时更新。当值班工程师遇到某次事故是没办法跟着指南来处理时，就应该在处理完该事故后顺手更新指南，把最新信息补上去，让未来值班的人遇到相同问题时能更快缓解。

除此之外，好的软件工程实践也会对缓解问题有帮助。举例来说，在做部署时，要尽量避免一次部署大幅度的改动，而是该切成小批次的部署 (推荐回顾 如何把关好上线流程?)。当团队采用小批次部署时，如果出事故时回滚，也能够更加锁定是哪次部署，同时回滚时也能减少对其他已经部署的功能的影响。

在部署时，也推荐搭配功能旗标 (不熟的读者可以回顾 什么是功能旗标 (feature flags)? 为什么要用功能旗标? )，这样能有效做到功能隔离，这时如果功能 X 出问题，可以通过功能旗标把该功能关闭，而不影响功能 Y。这种做法能让关掉出事故功能时，决策变简单很多，因为当不会影响功能 Y，就不用再跟产品端确认，是否能接受功能 Y 也一起被关掉。

明确的分工

当事故发生时，如果有明确的分工，团队会更快进入状况，进而避免大家慌在那里不知所措，或者很多人同时有很多声音导致场面混乱。在分工上，在实际发生事故时，至少要有三个核心角色，分别是事故指挥官 (Incident Commander)、沟通负责人 (Communications Lead)，以及技术处理负责人 (Operations Lead)。

事故指挥官会掌握大局，清楚知道目前整体事故解决进度。这个角色不一定要是职级最高的人担任，而是要由能掌握全局、协调信息、分派任务并推动决策的人担任。在某些团队里，这可能是技术负责人；但在更成熟的事故管理流程中，这个角色通常会依照当下事故脉络、经验与可用性来决定。

事故指挥官会集对解决事故有帮助的人，并分派任务让团队能动起来排查问题。与此同时，如果被分派任务的人遇到困难，事故指挥官也要提供对应的协助。

沟通负责人则是会记录下目前事故解决的状态，让利益相关方能知道最新进度，并作为对外联系窗口。当有了沟通负责人，事故指挥官可以专注在控场，而不用担心向利益相关方更新进度时遗漏细节。近期在有 AI 工具的帮助下，可以直接利用 AI 来记录与更新。举例来说，在排查视频会议中，搭配 AI 生成会议逐字稿，同时每 5 - 10 分钟根据会议的逐字稿，来整理相关的记录，并将更新自动推送到相关的沟通频道中。

举例来说，假如今天在电商网站中的结账页面突然出现大量下单失败信息，事故指挥官会先快速扫过该页面的相关信息，然后迅速召集相关人员，包含负责该页面的前端、后端工程师、对应的客服负责人。接着，会迅速指派要排查的方向，例如请前端工程师去检查最近一次的部署、请后端工程师去看相关的 API 与 log，然后请客服人员根据当下的记录，起草对用户的说明文案。

在召集人员时，确保参与问题排查的人员视角足够多元。事故往往涉及整体系统，而团队中每个人仅掌握系统的部分知识，因此通常需要汇集众人知识，才能厘清系统当下的实际状况。例如如果数据库目前超载，数据库团队仅能查出查询模式被变更，但无法说明改变原因，这时就需要询问实际写查询的应用层团队。

有多元视角也能确保避免单一视角的固着 (fixation)。通常个人容易从特定角度看问题，若看的视角与解决问题所需角度不相符，很可能导致最后难以找出真正的问题。

因此，推荐平时团队应该要维护一个联系清单 (可以维护在上面提到的事故指南中)，例如当某个页面出问题，应该要拉哪些人。找人的精细度也推荐不要只是单纯分前端与后端，而是可以细到后端的 API、数据库、算法等不同角色。有了这份清单，不代表每次出事故就要拉所有人，而是可以分层级，例如第一时间一定要拉谁进来，如果过多久查不出原因，还可以再多拉谁进来。

为团队成员建立心理安全

上面谈到流程、分工，以及排查问题的思维，在这些之外，要让团队成员能够在遇到事故时，可以有效排查并解决，「为团队成员建立起足够的心理安全」也非常重要。

在《快思慢想》一书当中，诺贝尔奖得主 Daniel Kahneman 把人类的思考系统拆成两大类别，一种是更贴近自动化的快思考，另一个则是带着更多推理逻辑的慢思考。快思考能够帮助降低思考过载对脑的负担，毕竟如果连起床去刷牙这段路的每个决策点都要深思的话，人很容易就会被过多的决策淹没，导致做不了太多事。而慢思考则能帮助把事情想得更详尽完整，通过深思各种面向细节，让决策的质量更高。

在面对事故时，理论上应该要用慢思考，避免因为仓促的决策乱枪打鸟，而是能真的去找出核心。要能做到这一点，关键在于负责轮班的工程师，能否保持冷静、不慌乱。从团队的角度来看，就需要减少轮班者在处理事故时要面对的压力。

具体来说，在 Google 的 SRE 相关实践分享中也提到，团队负责人需要确保轮班成员都有足够的心理安全 (psychological safety)，这种安全感能够让轮班成员不会焦急地处理事故，因而能减少仓促的快思考。

Google 的团队分享，建立这类安全感最有效的方法，是让轮班成员清楚知道以下三点：

• 上报管道：假如轮班成员自己解决不了，可以找谁求援
• 定义明确的事故解决流程：轮班者知道各种问题该从何下手解决，就会少一点慌张焦虑
• 不指责人的事故检讨：我们在 软件工程师该如何做好事故检讨? 一文有详谈，推荐回顾

在实际工作中，上面提到的第二点，通常会需要有定期的预演，才能够强化团队成员对于应对事故的熟练度；不然即使知道流程，也很可能因为不熟悉，实际做起来仍然慌张。对此，让我们在下个段落来谈，平常可以如何通过预演，来深化团队成员对事故处理流程的理解。

阅读更多

除了上面提到的方法，如果对这个主题感兴趣，我们在 E+ 会员方案的文章中，会进一步谈如何做好事故预演。欢迎加入 E+ 会员方案阅读与交流。