因果关系是生活的某种基本原则。

体现在开发者的世界大抵就是：如果你不提早发现和解决问题，最后问题就会在周末/半夜来解决你。

无数个被叫醒的深夜、被工作“召回”的周末、以及因系统故障而付出的惨痛代价已让越来越来开发者和管理者意识到实施混沌工程的重要性。

说到混沌工程，并非这两年的新概念。早在十多年前 Netflix 在亚马逊云科技上发布的一款名叫 chaos monkey（混沌猴子） 的服务，混沌工程便已经诞生了。那么，为什么直到近几年，混沌工程才开始受到广泛关注呢？在《亚马逊云科技在混沌工程的探索与实践》Tech Talk 中，资深开发者布道师黄帅就这个问题进行论述，并详细介绍了实践混沌工程的难点和思路，以及如何利用合适的开发工具对混沌工程进行落地。

是时候聊聊混沌工程了

为什么是现在，而不是十年前？黄帅从我们当前面临的痛点开始聊起，并将企业和开发者当前面临的痛点归结为以下五点。

痛点 1: 系统规模增长带来的复杂性

随着系统规模的增长，其复杂性类似于心脏拓扑结构。每个节点都是一个服务，错综相连，整个软件的生命周期极度依赖治理手段和能力。企业对于系统进行观测及持续维护的难度也大大增加了。

痛点 2: 快与稳的煎熬

DevOps 、微服务、敏捷开发的广泛使用，使软件的迭代和新功能的发布越来越快速。如何快步前进过程中，保持稳健，成了企业面临的新难题。

痛点 3: 小步快跑的疑问

每次变更很小，提高发布频次，一定能够降低风险的结论值得商榷。软件版本的快速迭代通常发生在软件质量还没有收敛到比较好状态的前期，而且存在不同服务迭代节奏的差异。在这种情况下，心脏拓扑结构中哪怕很微小的增量变动都可能产生级联故障，从而对整个系统造成重大影响。

痛点 4: 稳定性测试的新难度

心脏拓扑结构的复杂依赖性，给集成测试、回归测试和浸泡测试都带来新的挑战。此外，整个新版本的发布过程也是保证系统稳定性的重要环节，因此流水线上的每一个环节都需要进行验证，给稳定性测试带来新的难度。

痛点 5: 排障追踪的困境

当系统的复杂性达到一定程度，版本更迭的速度又非常快的状态下，很多时候我们碰到生产问题，要找出背后的根因非常困难。这中间可能是因为，健康仪表盘吐出了不准确的服务状态，水平扩展明明要借助冗余性获得更好的可用性却因毒化效应完全失效，告警系统因自身的稳定性故障产生大量的误报等等。

以上五大痛点的本质都可以用故障宿命论来解释：人类设计的系统变得愈发复杂，逐渐超出了人类的认知范围。近年来，随着分布式系统、敏捷开发、云原生微服务架构等云上现代化技术的广泛应用，开发的效率和便捷性大幅提升，但是这些创新的背后隐藏的问题是传统稳定性治理手段的落后。

软件可以用新技术实现弯道超车，系统复杂性引起的故障该如何解决？复杂性科学研究者、Cynefin 认知框架的提出者戴夫·斯诺登认为——理解复杂系统的唯一方法，就是与之互动。快速迭代中，谁都无法做到所有变化背后的考量全部记录下来，系统是我们设计和构建的，但系统行为我们却无法准确预测，所以我们必须要在实际的运行环境中，通过实验探索的方式（行为预期、事件注入、系统观测和更新假设），扩展我们对系统行为的认识，这便是最好的“互动”。

亚马逊可用性保障团队灾难大师杰西·罗宾斯，因其消防员的经验于 2004 年发明了 GameDay，邀请志愿者借助“实验”与待测系统进行“互动”，探索未知的系统风险，同时也训练了工程师团队的应急响应能力。随着业界更多团队开展GameDay，亟待一种新的实践模式实现 GameDay 高效实验、自动化和流程标准化。Netflix 发明的混沌猴子工具，以及后续提出的混沌工程正是源于这个思路。

混沌工程承认人们对于系统的行为认知是有局限的，通过受控的故障注入实验，观测、记录、分析系统，找到背后的原因，改进架构或相关的代码和设计，从而真正提升整个系统架构的韧性，避免级联故障发生。

混沌工程具体能产生怎样的价值？是否能量化呢？黄帅在分享中列举了 Netflix 报告中的一个例子：“过去一年中，混沌工程提前发现了 2 次大故障和 8 次小故障，避免了整个组织大约 70 万美金的损失。混沌工程团队，总共 3 个成员，薪水支出 15 万美金/人。开展混沌工程实验，本身需要 1 万美金的成本。投资回报率是多少？高达 52.17%。”

落地混沌工程的难点和思路

混沌工程带来的价值，无疑是令人心动的。近年来，许多公司都尝试采用某种形式的混沌工程来提高现代架构的可靠性。然而，混沌工程的探索实践之路却并非一帆风顺。分享中提到，企业实践混沌工程主要面临三个方面的挑战。

首先，面临稳态分析和服务透视方面的挑战。在故障注入后，需要判定系统的稳态是否被改变。如何定义稳态？又该采用何种手段判定呢？

混沌工程的核心特征是对照观测实验。精细化流量控制后，分别设置实验组和对照组。在实验组中注入故障，通过可观测的手段比较差异，通过链路追踪的方式去判断其强弱依赖的状况。人工手动分析，稳态对照分析的效率和准确性需要依赖于自动检验算法，简单地可以采用双样本的 T 检验，复杂地就需要借助异常检测等手段。在链路追踪的过程中，需要分析它的强弱依赖，从而计算出爆炸半径。其中，很重要的可观测手段是服务透视。在亚马逊云科技上既支持已有的可观测工具，同时也支持开源架构，整套工具开发者可直接进行使用。此外，可观测性在促进我们对于系统行为认知的同时，混沌工程本身也是系统可观测性的强有力的验证手段。通过平时的实验可以去验证当有故障产生的时候，哪些告警才是真正对排障追踪真正有效，哪些告警并不能带来价值。

第二，面临爆炸半径安全管控方面的难题。混沌工程采用的方式是用很小比例可能受到影响的用户进行实验，借以提升整个系统的可靠性。这个过程需要进行安全管控，一方面，要有随时停止的能力，俗称一键关停。另一方面要合理管控实验流量的大小，流量太小，可能会产生样本误差，流量太大会影响用户。对于偏差，我们可以借助实验手段中存在已久的统计学方法，如多重检验、费舍尔方法等等。

安全管控可以采用灰度对照实验，一键关停的方式，对流量进行精细控制。通过亚马逊云科技的服务可以很细粒度的去隔离相应爆破的对象，以及进行强弱依赖识别。因为只有知道相关服务之间的依赖关系强弱才能知道爆破半径有多大。

第三，是效率方面的难题。假设有 10 个组件，采用排列组合的方式去实验会产生 360 多万个场景。这么多场景不可能通过有限的人力、时间和资源完成测试。

我们需要以史为镜，通过历史的故障进行一些类比引申和重现。首先，故障注入点不在于多，而是要使故障注入点的组合场景更接近现实的状况。其次，要去实现混沌工程标准化、模板化和互操作性，不同团队之间可以互相分享，共享一些模板，这些模板可以高效地使用起来。另外，可以使用 FMECA 服务失效模式的分析手段，从故障发生的可能性、严重性和可观测性三个角度，确定故障组合的优先级。通过这个优先级就可以很轻松地判定出哪些故障是核心故障，哪些故障是最重要的，然后把时间精力投入到重要的故障里面就可以了。在故障组合的探索方面，可以用到 STPA 分析模型。该模型认为系统的可靠性依赖数据面、控制面、人工面三个部分，三个部分交互的点，也就是最容易产生故障的点。

总结来说，企业落地混沌工程的难点和思路基本围绕稳态、安全、效率三个方面。那么，在落地过程中是否可以借助一些工具和服务呢？

用好一切可用的服务

今年 3 月，亚马逊云科技发布了一款 Amazon FIS 服务，帮助大家更简单、高效地去实践混沌工程。该服务基于亚马逊云科技内部工具 Amazon Gremlin 技术和能力的输出。

早在 2004 年，亚马逊就创立了基于工程师团队的交互式和开放式的学习与训练的“GameDay”。在 2004 年到 2021 年整整 17 年间亚马逊云科技一直实践 GameDay 的玩法。2010 年亚马逊云科技推出自研混沌工程产品 Amazon Gremlin，结合 GameDay 成为可用性保障实践内容。

在 Amazon Gremlin 内部实践并为其公司带来价值后，亚马逊云科技考虑将拥有的能力赋能给自身的客户和用户，推出了 Amazon FIS 服务。

Amazon FIS 的最大的优势体现在它的易用性。使用 Amazon FIS 不用集成和安装其他工具就可以控制管理台。同时 Amazon FIS 提供一些预设实验的模板，用这些模板可直接做故障注入，如果产生新的想法，也可以根据自己的需要进行定制和修改。

其次，Amazon FIS 非常贴近真实的场景。很多故障场景并不代表真实世界的事件，在实际场景中很多问题是多个故障的组合引发的，Amazon FIS 支持串行、并行等多种实验灵活编排，最大程度还原真实场景。

第三，也是非常重要的安全保障方面，Amazon FIS 提供了自动停止的能力。一旦混沌工程实验影响到实际用户或产生负面影响，它可以自动停止。用户也可以自行设置相应的告警，一旦触发相应的停止条件，实验将立即停止。在故障注入的过程中，可观测性非常重要，Amazon FIS 可集成 Amazon CloudWatch 的可观测能力，方便用户观察故障注入时的系统变化。此外，Amazon FIS 内置安全回滚策略，并且能够通过细粒度 IAM 实现精细权限控制，避免混沌工程这个平台成为新的攻击点。

在 Tech Talk 的最后，黄帅演示了四个借助 Amazon FIS 服务轻松打造云上混沌的实验。具体操作步骤可点击视频了解。