混沌工程

第 10 章 人文混沌

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

安迪-弗莱纳

我面临着一个困扰我很久的问题。我怎样才能把我所知道的混沌工程学应用到人类系统中呢？当我第一次了解到混沌工程学这一新兴领域时，如果说我被它深深地吸引住了，那也太轻描淡写了。有目的地在系统中注入故障，以帮助你更好地理解你的系统？我立刻就被吸引住了。作为 一个 "新观点 "安全书呆子和系统思想家，我可以支持一种承认我们每天使用的系统本质上不安全的模式。我最初的假设是，如果混沌工程实践是针对分布式网络系统而设计的，那么它们也可以应用于我们日常交互的其他分布式系统--这些系统就在我们身边，构成了我们的日常生活。

如果我们不仅能将混沌工程学应用于我们熟知和喜爱的复杂分布式技术系统，还能将其应用于被称为组织的复杂分布式系统，那会怎样呢？一个组织就是一个巨大的系统，为什么不能适用同样的规则呢？在本章中，我将列举三个真实案例，介绍如何在我领导的平台运营团队以及SportsEngine更广泛的产品开发组织中将混沌工程学原理付诸实践。

系统中的人类

在组织中，系统的基本单位或行为者是人。真正棘手的问题在于这些参与者之间的互动。我们经常会遇到这样的问题："如何才能创造出让人能够有效操作的软件来实现目标？请注意，人既是问题的核心，也是解决方案的核心。他们既是产生需求的原因，也是解决需求的方案。

为社会技术系统注入 "社会 "元素

作为 技术专家，我们致力于为人类问题提供技术解决方案。技术对我们的生活产生了巨大的影响。我们所做的一切都离不开它。从单体到微服务 "的故事比比皆是，其中许多历程都是围绕着解决非常现实的组织扩展问题展开的。但是，改变我们使用的技术并不能神奇地创造出我们想要的文化。我们总是忽视我们每天都在其中穿梭的社会技术系统的社会层面。显然，改进技术系统的最有效方法就是绘制技术系统的地图。加里-克莱因（Gary Klein ）在他的《洞察他人所未洞察》一书中谈到了我们如何获得这些洞察力。他指出，故事是组织内的 "锚"，而这些故事是我们解读细节的方式。我们通过架构审查、系统设计和文档等多种方式来实现这一点，在更高层次上，我们还通过事件审查等回顾性活动来实现这一点。我们不断尝试调整我们对系统功能的心智模型。但我们是如何在系统的社会方面做到这一点的呢？您上次绘制事件响应升级流程图是什么时候？该流程图是否包括二级人员休假时该怎么办？是否包括当你没有收到某人正在处理某个问题的确认时该怎么办？是否包括如何确定某件事是否属于事件？很好，你已经绘制了所有这些内容，那么你是否尝试过监控这些系统的运行呢？记住，要注意 "想象中的工作 "与 "已完成的工作 "之间的差距。我们说要做的和实际要做的是完全不同的。这种差距的影响可以用 "暗债 "来描述 ，"暗债 "是 SNAFUcatchers 的 STELLA 报告中首次使用的术语。¹

我们可以把一个系统的组成部分或参与者看作是为处理某种能力而设计的；而当这种能力耗尽时会发生什么，可能是极其不确定的。在系统的技术层面，这可能表现为连锁故障等巨大的涟漪。而在系统的人的方面，我们通常会认为这是职业倦怠或丢三落四的表现。但是，如果没有亲眼目睹，就很难推理出倦怠的工程师或失职的经理所造成的影响。

组织是一个系统的系统

对我来说，组织的迷人之处在于它无处不在的系统。其中一些制度是成文的--例如，你可能有一项休假策略，允许你每年休假x天。或者你有一个为期一周的轮班制度，由六个人轮流值班。但还有一些制度根本没有写下来，它们只是众所周知的部落知识，比如只能通过 ...