如何更快处理故障 - 论心理模型重叠的重要性

今天偶尔刷到一篇文章，标题是《What Makes Difficult Incidents So Difficult?》，为何复杂事件如此难以处理？作者是 Hamed Silatani，文中提到一个“心理模型重叠”的说法，感觉还挺有意思，在这里分享给大家。

下面是原文的翻译 👇👇👇

我在这里谨慎地使用了“困难事件”这个词——因为，当然，这会引发一个问题：什么使得一个事件容易或困难？对于这篇文章，我们姑且认为一个困难的事件通常涉及多个团队、所有权不明确以及没有明显的解释。

当对话停滞不前时

如果你曾经担任过支持人员，你可能见过这样的事件聊天：

• 工程师 1：“网络团队有人在线吗？无法将 ClientData 服务连接到其数据库。”
• 网络工程师：“我需要源 IP 地址、目标 IP 地址和端口号。”
• 工程师 1：“我们只有服务和依赖名称在配置中。我不知道 IP 地址。”

现在我们只能等待——对话拖延，宝贵的时间被浪费了。

当交流顺畅时

比较一下这个版本：

• 工程师 1：“网络团队有人在线吗？ClientData 服务在 HOSTXXX 无法连接到其 DB 在 192.168.x.x:1521。同时在 netstat 中看到 SYN_SENT。”
• 网络工程师：“谢谢。SYN_SENT 通常指向防火墙问题。”

这次交流进行得很快，更快地接近了解决方案。

关键在于心理模型

不同之处在于？应用程序工程师对网络有一些了解，而网络工程师对应用程序也有足够的了解来进行有意义的交流。他们的心理模型有所重叠——而这重叠是关键。

但随着我们引入更多的抽象来使代码更易于部署和运行，这种共享的理解变得越来越罕见。你以为不必知道这些复杂抽象是如何工作的……直到你陷入一个故障中。

当我们对同一件事有不同的理解时会发生什么？

实际上有一个术语来形容这种情况：“基本共识破裂”（Fundamental common ground breakdown）。

这就是当处理同一事件的人对已经说过的话做出相互矛盾的假设时会发生的情况——这通常会导致延误或全面的灾难。

个人例子

我在一家金融交易公司的新工作中，注意到负载均衡器上有高内存使用率和不断增加的连接数。我建议进行滚动重启以避免麻烦。平台工程师同意了，我们开始了重启。

但结果是…导致了全面的服务中断。

原来，负载均衡器需要一段时间来标记实例为“在线”。我假设“滚动重启”意味着实例之间的快速、安全的切换。他们没有解释清楚。砰。服务中断。

这是一个心理模型不匹配——并且给我们带来了损失。

如何故意构建重叠

扩展你的知识范围——即使只是稍微扩展一下——也可以预防事故或帮助更快地解决事故。比如应用程序开发人员理解数据库。数据库工程师理解网络和操作系统。

我们可以找机会构建这种重叠… 或者我们可以故意构建它。

跨团队轮换工程师或进行事故演练是构建这些共享模型的好方法。虽然我们不能确保完全相同的思维模型，但可以促进团队成员之间思维模型的重叠。

译者注：

在 SRE、可观测性领域，如何通过平台产品来抬升各个团队的心理模型重叠度？本质就是要把经验和知识沉淀到平台产品中，让大家基于一个高 level 的共识来沟通、做故障定位/发现。

Facebook 曾撰文讲解他们内部一个系统叫 SLICK，本质就是把各个服务的 SLI 数据沉淀到一个地方，大家都能看到。这样就避免了各个团队之间的沟通成本。我们创业做的一站式智能观测平台 Flashcat 里也做了类似的事情，叫做「灭火图」，帮助企业构建全局稳定性视图，有故障了一目了然看到哪些服务受影响，哪些模块是故障原因。如果您需要乙方协助您构建整套监控、可观测性体系，欢迎联系我们交流产品和思路（免费哒） 👇

https://flashcat.cloud/contact/