别踩坑！ 避开这些反模式会让事故处理事倍功半

作者 | Vanessa Huerta Granda

译者 | 明知山

策划 | Tina

事故会阻碍我们实现目标，无论你的目标是什么——例如销售 Taylor Swift 音乐会的门票，让人们在假期能够准时回家，或者在全球范围内运输货物——都有可能发生事故。我在 2023 年旧金山 QCon 大会的演讲中 分享了我的见解。

幸运的是，事故并不是孤立发生的。我们可以从过去的经验中汲取教训，在未来发生事故时减轻事故的影响。

一个注重弹性文化的组织能够迅速从事故中恢复，并将这些事故转化为机会。

弹性是指具备迅速抵御或从困境中恢复的能力，比如从故障、从事故中恢复。

弹性可以帮助我们将这些事故变成机会。

事故生命周期

无论我们多么努力，都不可能做到零事故。之所以发生事故，是因为我们不断发布代码，不断做出变更，而这是一件好事。

这是系统实现目标的一部分，是事故生命周期的一部分。

事情在顺利进行（系统正常），然后发生了某些事故导致系统过载并崩溃（事故开始）。也许是因为你推出了一款炙手可热的新产品，或者开始销售有史以来最大型的音乐会的门票，导致热切的粉丝蜂拥而至。无论触发因素是什么，你现在都在努力应对一场全面的事故。

眼下的重点是恢复正常运营（事故解决），后面会有很多机会评估发生了什么（事故后活动），包括正式和非正式的事后总结。或许你的公司有正式的流程，有文档和确定的行动项，或许你的事后总结只是让一些同事在午餐或喝饮料时做一些回顾。然后，你们基于汲取到的关键教训来改进系统（应用教训），增加待命人员配备，改变请求队列的排队方式，或者在证实为系统问题时促使进行外部调查。

关键在于要认识到，“系统”不仅仅是一行行代码——它是将技术和团队结合在一起的一种社会性技术结构。每一个事故都提供了有助于改变人们处理未来事故方式的教训。我们的的大脑保持了这种成长的经历。基于事后智慧做出选择意味着系统在迭代演进。在应用了这些经验教训之后，我们最终回到了系统正常状态。

我们处理事故的方式可以引导我们走向更具弹性的基础设施和更明智的决策。事故为我们提供了一个学习的机会，我们的响应方式塑造了我们的系统以及整个团队在未来应对事故的能力。

提高系统弹性的可能性

为什么我们要关注这个问题？简单地说，公司需要为事故付出高昂的成本。这些成本可能会以多种方式体现：

• 网站故障可能导致用户无法访问和收入损失；
• 声望受损可能意味着将来的用户减少；
• 用户工作中断不仅发生在事故期间，也会延续到事故发生之后；
• 目标和计划受到影响，因为工程师无法专注于推动这些工作进展。

在事故生命周期中有三个点，我们可以将时间和精力集中在改善学习周期上，并获得一些带宽来提高系统弹性。这并不容易，因为在这个过程中你通常需要做出一些小的调整和改变。如果还没有证据表明做一件事情是有用的，CTO 通常不会直接批准花 10 万美元用于跨事故分析（这对利益相关者来说可能不是一个有市场吸引力的改进）。

专注于事故响应

我们先从事故响应本身开始。我们可以在三个主要方面做出改进：

• 协调: 记录发生事故时你所遵循的工作流程，即使只是“打电话给那个在这里工作了 10 年的人”。找出可能存在差距的地方，并讨论如何缩小这些差距。
• 协作: 如何将人们聚在一起解决问题？如何知道该打电话给谁？我曾在一家工作工作，当时我必须打开笔记本电脑，连接 V** 并打开维基页，然后找到需要的电话号码。给一个人打电话可真费劲。你如何能够更容易地让人们聚在一起？
• 沟通: 如何与利益相关者进行沟通？如何告诉客户发生了什么？他们的期望是什么？起草一些指南来管理期望，让每个人都了解响应应该是什么样子的。请记住，你的利益相关方和客户可能需要不同的信息。

这些改进都不需要完美。我们只需要找到小的改进和减轻认知负担的方法。也许你可以加入一些自动化功能来帮助解决这个问题。

反模式：MTTX

MTTX 是我用来指代发现的平均时间、恢复的平均时间、解决的平均时间等一些指标的术语。我先明确一下，这些指标数字没有任何意义。这并不是说我们不应该关心事故持续了多长时间，但这些单一的数字不应该成为我们的目标。

有一次我遇到了一个问题，我们的数据中心着火了，消防长不准我们进去。我们希望为我们的用户和工程师提供更好的体验，因为这是帮助我们取得成功的关键。我们可以做一些事情来简化事故响应，这样我们的工程师就能更好地解决问题。就像我们永远无法做到零事故一样，我们也无法完全控制从事故中恢复需要多长时间。

专注于事故分析

事故发生后，通过事故分析进行深入了解并从中学习是非常重要的。我发现基于叙述的方法有助于挖掘信息。这样，你就可以强调发生了什么以及人们从不同角度体验事故的方式。

首先，收集有关事故的数据，这个很重要。了解都有谁参与其中，他们在哪里，沟通是如何进行的——通过 Slack、Zoom 还是电话？将这些信息汇编到存储库中，并附上一个时间表，列出事故是如何发生的。记下数据中悬而未决的问题，然后决定是否需要召开会议，或者是否可以通过共享文档进行异步讨论。

你需要整个组织提供的各种视角。参与讨论的不应该只包括事故管理人员和推送错误代码的人。我发现市场营销人员、产品管理人员，尤其是客户支持人员对事故的影响也有着深刻的见解。

在开会时，请确保这是一场开放的对话——主持人说的话要少于其他人。这样，你可以了解到这次事故如何影响不同的群体。例如，你可能会了解到值班工程师缺少仪表盘的访问权限，或者客户支持收到了怎样的投诉。

最终，将主要见解和行动项提炼成适当的格式。领导可能需要简短的执行摘要，其他团队可能需要确定的行动项清单。分享这些信息，确保它们能够有效地提升组织的弹性。

我们的目标是有效地传达事故的促成因素和事故的影响，以此来推动变革。一些用于改进事故分析流程的额外的资源包括 Jeli Howie 指南 和 Etsy 的无过失事后分析促进指南。

反模式：行动项工厂

关键在于要避免常见的反模式，比如在事后分析当中只是生成行动项而不加以跟进。为特定问题创建警报或生成被遗忘在谷歌文档或待办事项列表中的修复程序，只会在整个流程中埋下不信任的种子。如果提出的修复和改进措施从未被实现，工程师和利益相关者会认为评审会议是在浪费时间。

为了抵制这种反模式，事故评审应该更广泛地评审组织的弹性，而不只是专注于行动项。很多时候，我们往往会看到要么是微小的行动项，要么是过于雄心勃勃的行动项，而我们需要找到一个平衡点——在影响范围和优先级方面都刚刚合适的“金发女孩（Goldilocks）”行动项。避开了狭隘的行动项，组织可能会发现更多增强系统弹性的机会，并确定怎样更好地分配资源。但是，如果我们想要保持对流程的信任和参与度，任何已确定的改进措施都必须得到推广。

完美的行动项是指那些可以比其他计划优先考虑，并在接下来的一两个月内完成的事情。而且，它还应该推动与事故相关的工作。

专注于跨事故分析

基于多个事后分析进行的跨事故分析对于识别系统性问题并进行有意义的改进来说至关重要。通过汇总来自个别高质量事故评审的见解，组织可以发现可能需要在整个公司范围内执行的举措或转变，如调整人员配置、供应商变更或采用新的解决方案。

这项分析应该是一项协作工作，需要结合来自工程、产品、客户支持、营销和领导的观点。不应该由任何一方单独拥有整个过程。以易于理解的方式呈现数据对于解决情境化问题并说服领导支持重大变革也至关重要。

目前，许多组织在有效进行跨事故分析方面面临困难，因为他们缺少来自事故评审的高质量数据，或者这些数据分散在多种媒介中，这给事故分析造成了阻碍。此外，大多数工程师没有接受过数据分析培训，无法用这种方式汇总见解。

如果做得好，这些见解可以清晰地描绘出事故中的痛点。我们的目标不是为了召集具体的团队，而是通过重新分配资源或更新流程来提供有用的支持。这种弹性水平使得工程师能够更好地避免未来可能发生得问题，并为创新创造了良好的环境。

通过跨事故分析获取见解的一个例子是了解事故发生在哪里。也许大多数事故发生在你的代码库的某个特定区域。你该如何更好地支持管理负责这个区域的团队？或者代码是否需要进行一些重构？

我在很多团队中都这样做过。他们能够基于事故趋势做出组织层面的决策。我们看到人们利用这些见解做出决定，例如使用特性标志，或更换供应商，甚至进行组织变更。所有这些都为工程师的成长创造了一个良好的环境。

反模式：MTTX

进行跨事故分析也存在陷入 MTTX 反模式的风险。一些高管可能会要求提供实际上不会提供实用见解的指标。工程师或分析师没有足够的理由去挑战 CTO，因此我建议在这里提供一些背景信息即可。我将这种方法叫作“意大利面酱中的蔬菜”。指标本身可能没有帮助，但你提供的上下文会让信息变得更加丰富。

反模式：不沟通见解

我想分享最后一个反模式，它与跨事故见解有关，但也适用于从评估事故中获得的任意见解。我们的工作不应该只是在完成后就将其束之高阁。

任何文档都应该能够在整个组织内阅读和分享，即使是在我们采取初始行动很久以后。我经常参加评审会议，工程师们说：“我们都知道该怎么做，我们只是不去做。”我的问题是——我们确实都知道吗？是否已经清楚传达了？

通常情况下，人们不愿意参与我们的学习，因为他们觉得这种形式与他们无关。不同的利益相关者需要掌握不同的见解。根据利益相关者调整语言和详细级别，专注于你的目标，不要纠结于不重要的细节。如果要为重新架构系统提供理由，请根据数据解释理由，然后就此结束。

还需要考虑你的格式，是否使用了见解、指标、叙述和技术细节？从最重要的见解开始。例如，“X 比例的事故与我们过时的 CI/CD 管道有关。这将影响所有的产品，并让用户难以上手。利益相关者和专家建议下个季度将重点放在重新架构上。”我们提出这个建议并不是凭空想象，而是因为数据为此提供了支撑。展示你的工作。获取到这些信息的人可以从个别事故分析追溯到跨事故见解，然后获得行动线索。

总 结

我们永远不可能做到零事故。技术在不断发展，新的挑战不断出现，我们在关注事件响应、事件分析和跨事件洞察的同时，也要注意那些反模式，这样就可以降低事故成本。我们可以更好地为处理事故做好准备，这将带来更好的用户体验。这将培育出一种工程师参与的文化，他们不仅有能力完成工作，还能够创造性地解决问题，帮助我们实现组织的目标。

查看英文原文：

https://www.infoq.com/articles/incident-lifecycle-resilience/

声明：本文为 InfoQ 翻译，未经许可禁止转载。