混沌工程

简介：混沌的诞生混沌的诞生

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

混沌工程 在软件开发领域，混沌工程仍是一门相对较新的学科。本文将介绍混沌工程的历史，从最初的默默无闻，到现在所有主要行业都以某种形式采用混沌工程。在过去的三年里，问题已经从 "我们应该做混沌工程吗？"变成了 "开始做混沌工程的最佳方法是什么？"

我们这门新兴学科的历史解释了我们是如何从第一个问题过渡到刚刚提出的第二个问题的。我们不想仅仅讲述一个日期和运动的故事，以澄清事实。我们想讲述的是这门学科是如何兴起的，从而让你明白它为什么会以这样的方式兴起，以及你可以如何从这条道路中学到东西，从而从实践中获得最大收益。

故事从Netflix开始，本书作者凯西-罗森塔尔（Casey Rosenthal）和诺拉-琼斯（Nora Jones）都曾在Netflix工作，当时混沌团队定义并推广了混沌工程。¹Netflix发现了混沌工程的真正商业价值，当其他人也看到这一点时，一个围绕混沌工程的社区逐渐发展起来，并将其推广到整个技术领域。

作为代码的管理原则

从 2008 年 开始，Netflix 非常公开地表示²从数据中心向 Cloud 迁移。同年 8 月，数据中心发生了一起重大数据库损坏事件，导致 Netflix 三天内无法发送 DVD。当时流媒体视频还没有普及，DVD 的配送是他们的主要业务。

当时的想法是，数据中心将他们锁定在单点故障（如大型数据库）和垂直扩展组件的架构中。如果迁移到 Cloud，就必须水平扩展组件，从而减少单点故障。

事情并没有完全按计划进行。首先，他们花了八年时间才从数据中心完全抽身出来。与我们的利益更相关的是，在转向水平扩展云部署实践的同时，流媒体服务的正常运行时间并没有像他们预期的那样得到提升。³

要解释这一点，我们必须回顾一下，2008 年，亚马逊 Web Services（AWS）远不如现在成熟。当时的云计算还不是一种商品，也不像现在这样可以直接部署。当时的云 服务确实有很多承诺，其中之一就是 实例⁴偶尔会在没有任何警告的情况下闪烁消失。这种特殊形式的故障事件在数据中心中非常罕见，因为在数据中心中，功能强大的机器得到了很好的维护，而且人们通常对特定机器的特殊性了如指掌。而在云环境中，同样的功率是由许多在商品硬件上运行的小型机器提供的，因此不幸的是，这种情况经常发生。

构建可抵御这种形式故障事件的系统的方法众所周知。也许我们可以列出六种常见的做法，帮助系统在其中一个组件发生意外故障时自动恢复：集群中的冗余节点、通过增加节点数量和降低每个节点的相对功率来限制故障域、在不同地域部署冗余、自动扩展和自动发现服务，等等。使系统足够强大以应对实例消失的具体方法并不重要。它甚至可能会根据系统的具体情况而有所不同。重要的是，必须这样做，因为由于实例不稳定事件的高频率发生，流媒体服务正面临可用性不足的问题。在某种程度上，Netflix 只是将单点故障效应成倍放大。

Netflix 与其他软件公司不同。它积极主动地推广文化原则，这些原则来自于文化牌中概述的独特管理理念。这体现在多个实践中，对 Netflix 如何解决可用性不足问题产生了重大影响。例如

• Netflix 只聘用有相关工作经验的高级工程师。

• 他们给予所有工程师充分的自由，让他们可以做任何满足工作需要的事情，同时也让他们承担与这些决定相关的任何后果。

• 最重要的是，Netflix 信任工作的人，让他们决定如何完成工作。

• 管理层不会告诉个人贡献者（IC）该做什么，而是确保个人贡献者了解需要解决的问题。然后，个人贡献者告诉管理层他们计划如何解决这些问题，然后他们就努力去解决这些问题。 ...