领导，是时候开展混沌工程了 | IDCF

Gartner提到，负责DevOps的基础设施和运维(I&O)领导者，想要实现系统可靠性这一目标，必须克服对混沌工程的恐惧。混沌工程不仅能够安全地实施，而且允许组织在实践中学习，为提升系统可靠性和对系统级联依赖的理解深度，打下坚实的基础。

一、核心挑战

在现代应用的复杂环境中，I&O领导者，被可靠交付的要求所困扰，他们担心混沌工程过于危险，具有破坏性，导致他们无法对其影响做出反应。

由于交付速度的增加、平台的多样性以及分布式应用的依赖性，系统复杂性变得越来越难以厘清。

在可靠性领域，缺少全面且系统的知识体系，仍停留在专家的实践经验中。

负责DevOps的I&O领导者必须：

• 将混沌工程作为一种组织能力进行推广，视为一种常规的产品团队活动。
• 在预生产环境中，要求团队通过“测试先行”的方法安全地实践混沌工程。
• 敦促团队利用工具和实践对整个技术栈引入故障注入测试。

二、混沌理论

混沌理论起源于气象系统的数学研究。

第一篇论文，最初由爱德华·诺顿·洛伦兹 (Edward Norton Lorenz) 于 1972 年发表，他被誉为混沌理论之父。

《可预测性: 巴西蝴蝶翅膀的扇动是否会在德克萨斯州掀起龙卷风？》

通俗地可以称之为“蝴蝶效应”，在这种情况下，即使环境中的微小变动，也可能导致未来状态的剧烈变化。

混沌理论包含一个悖论，即复杂的事物可以被理解，但可以理解的事物并不总是可以预测。

就系统而言，混沌理论指出，系统初始状态的微小变化可能会导致后期发生巨大的行为差异。如下图所示。

三、推荐方式

Gartner提到，到2024年，超过50%的大型企业，将利用混沌工程实践，强化其数字化能力，以达到更高的可用性（99.999%）。

3.1 可靠性是数字业务的关键

据Gartner 2019年CIO调查发现，在2019年投资增加的领域中，排名前三的是数字化创新(22%)、收入/业务增长(22%)和卓越运营(13%)。但是，当系统频繁宕机时，上面每一个都会受到影响，从而破坏CIO的最高优先事项。

此外，Gartner 2019年的DevOps研究发现，在建立DevOps实践的最高目标中，“提高系统可靠性”排名第三，仅次于排名第二的“减少系统缺陷”。

许多提高可靠性的工作，过于关注或强调事件响应和故障恢复的过程，但这并不能阻止损害组织品牌和信任的事件发生。

I&O领导者应如何利用事件影响链和改进措施进行转变?

领导者必须引导团队在预生产中，根据稳态假说向系统有意地引入故障。这也是组织学习的催化剂。通过这种方式获取到的知识和技能，可以更好帮助我们管理和减轻系统风险(见下图)。

在预生产中利用“测试先行”的方法实践混沌工程，从中提取新知识，然后再逐步应用到生产中，提升生产的稳定性。

另外，可靠性工程的替代方案是风险管理。实践混沌工程，也相当于拥抱风险管理。

3.2 让混沌工程成为常规的团队实践

在数字业务功能发布节奏上受到的压力，往往让很多的I&O领导者感到不适，这里的原因是显而易见的。

新版本可能会带来新的生产缺陷和稳定性的问题。这会导致SLA和客户满意度下降。为了跟上当今频繁的发布周期，我们必须主动减少停机时间，而不仅仅是通过事件响应的做法。

传统发布模式中的系统可靠性曲线说明，在产品的生命周期中通常有三个阶段(见下图)。

在产品发布期间，缺陷是比较高的。随着时间的推移，当缺陷数量减少时，产品就进入使用寿命阶段，然后在一个较低的数量上稳定下来。在曲线末端时，产品会磨损，缺陷会重新出现。当我们停止维护，或者因技术负担和复杂性，降低最佳运行配置和环境时，软件也会“磨损”。

然而，当我们开始以频繁的功能增量迭代发布时，往往会出现:

• 软件测试效率和发布频率增加的同时，软件的规模、复杂性和技术债都在增长。
• 虽然版本增量要比传统发布的小，但小而频繁的更改，会增加应用非功能相关领域的潜在问题。
• 随着软件功能的丰富，用户更加依赖，从而获得更多的业务价值，同样系统可靠性也会成为影响用户满意度的关键。

下图是迭代发布模式中的可靠性曲线，表明了频繁变更对团队和产品带来的潜在影响。

为了防止这条曲线成为现实，我们应积极推广混沌工程，配合敏捷管理、DevOps和站点可靠性工程(SRE)实践，提升产品的可靠性。

在预生产阶段，我们可以将新的故障场景注入到产品的增量发布中。当混沌工程成为产品生命周期的一部分时，可以持续地带来新知识和系统的可靠性。

像许多实践一样，团队需要时间来熟悉与掌握混沌工程，所以增加GameDay(游戏日)和混沌实验计划的频率，对刚采纳混沌工程实践的团队来说是至关重要的。

I&O领导者必须把混沌工程当作常规的团队实践，而不是作为一次性的活动。

采用重用和共享的方式，来帮助I&O领导者推广混沌工程。

通常，团队的产品都会使用相似的平台和服务。这意味着已经实践过的混沌实验计划，可以被其他团队和个人复用。通过重用其他内部团队在预生产中的实施方法，可大大降低大家对混沌工程实践的恐惧。

另外，还可通过社区来更广泛地分享经验，包括失败的例子。例如：因混沌实验影响了生产系统。当然，我们必须要确保设置恰当的权限，通过共享存储库和版本控制来访问这些混沌实验计划。

3.3 在预生产中安全实施混沌工程

在预生产中利用混沌工程可以实现两个关键任务。

• 首先，允许团队以一种“非侵入式”和“测试先行”的方法，安全地掌握混沌工程实践。
• 其次，从混沌工程实践中获得的知识，可用于正常的运维和生产加固。

只有在我们增加了混沌工程实践的知识，并帮助我们从生产系统中移除足够多的故障点之后，我们才开始考虑在生产中迁移或重用这些混沌实验计划。

值得注意的是，许多组织在创建和维护“与生产相似”的测试环境方面遇到了困难。

混沌工程，就像信息技术的其他实践一样，需要花时间去学习、采纳和掌握。混沌工程可以通过业务团队、架构团队、应用开发团队、运维团队和安全团队之间的积极协作来掌握。

下图概述了创建混沌实验计划的五个简单步骤。

1）头脑风暴潜在的服务失效点

与产品负责人一起为可靠性事项排出优先级。同时邀请功能构建、功能测试或服务使用的团队成员一起参加。利用他们对系统的看法和使用系统的经验，头脑风暴出潜在的故障区域，以及整个系统和组件在压力下的行为表现。鼓励从多个角度进行思考，以获得尽可能多的内容。

2）设置稳态假设

多个团队的合作，整理和创建假设。确定系统将如何失效，影响哪些组件，如何降低用户体验，如何度量，以及团队如何恢复该服务。这些假设都是混沌实验计划的基础。

3）对系统进行实验

混沌工程中的“混沌”是系统的状态，而不是实施方式。成熟的组织甚至在生产中使用随机的故障注入。当然，只有在成功完成很多混沌实验计划，并能很好地理解系统行为之后，随着时间和经验的积累，才能达到这种成熟水平。

下图包含了一个故障注入计划的示例。

4）观测系统行为

记录系统的行为、特性(功能、可用性、性能)、SLA和服务水平指标、服务水平目标、平均检测时间(MTTD)和平均修复时间(MTTR)。

Gartner的2019软件质量工具和实践调查发现，只有36%的受访者表示，他们的组织有在度量MTTD，只有39%有在度量MTTR以评估应用交付性能。

混沌工程可以助力团队在促进组织能力和学习方面有效性的度量。例如，团队中有多少成员贡献了相关知识？创建或者记录的是否为新知识，是孤立的，还是以前未知的？

此外，用户也可以参与执行混沌实验计划。度量对下游系统的影响，即使在服务恢复之后也是如此。这里面的关键点是，实践混沌工程时，新知识和价值来自许多领域，而不仅仅是演练服务恢复的步骤。

5）分析、学习和改进

实验和观测的结果必须提供产品负责人，需要优先考虑到产品或平台的backlog中。下一步应如何？或者加固，或使简化？需要注意的是，这些学习和改进，可能会影响到其他团队的工作。
如果组织刚开始接纳混沌工程，而你的团队是第一个进行这种实践的，那么可以考虑利用混沌工程实践社区，与他人分享混沌实验计划。

3.4 推动团队打破一切

有些团队因为自身系统的复杂性，而在执行/不执行(Go/No-Go)决策时陷入困境。这就是分析瘫痪，如果经常发生，就需要加以解决。

与其没完没了的“如果/那么”对话，不如在预生产中实践混沌工程来解决这个难题，然后继续新的工作。

虽然在预生产中执行，你可能是推动者，但要意识到，这其中的价值来自于混沌实验计划的全面性，它会帮助你获得新的知识，带来决策的信心。

系统中使用的技术，往往来自不同的时间点、负责人和团队能力。

1）旧系统已经运行了几十年，仍然是运维的重心。

虽然这些系统值得信任，但很可能最初的设计和开发人员已经转移到其他团队或离开。故障注入到这些系统中，将帮助我们保留住快丢失或遗忘的知识，或意识到我们有知识缺口，需要大量的研究。混沌工程实验可以进一步识别那些遗忘的知识，帮助团队学习。

2）SaaS产品也可能成为环境的依赖项。

尽管在预生产中可能有，也可能没有，但虚拟化服务是一定有的。创建包含SaaS解决方案的混沌实验计划，看看它们如何对端到端环境产生负面影响。

3）系统安全性也是故障的注入点。

通过更改帐户密码的权限，甚至完全删除服务帐户来调查系统行为。团队可能在不了解的区域中使用了某些服务帐户；混沌实验可以将其带来的影响展现出来。我们还可以更改文件或目录的所有权，或在不正确的帐户下重新启动服务。

4）停止业务并删除数据。

虽然不太可能丢失数据库，但丢失连接并不少见。如果应用程序是通过功能标记实现数据驱动的，那么这些功能标记被完全删除，将会发生什么？在审查应用程序的行为时，还应停止常用的服务，可以考虑停止容器、虚拟机和服务(如SSH)。

5）网络也应该在混沌实验计划中。

添加一个不能存在的DNS，或者从IP表或服务注册中心中删除，禁用协议和端口，网络丢包或网络连接突增。

6）故障注入最应该到不了解的系统或依赖项。

重构或重组服务或应用时，团队可能会认为有部分技术在理解方面存在缺陷，需要混沌工程来证明，对所不了解或不知道的东西，可以建立这样一个学习计划。

3.5 工具和社区

将混沌工程嵌入到DevOps实践和工具编排中，可以促进团队和产品的增长。安全引入这种做法，积极参与内外合作，借助供应商的专业服务，或者积极参与支持开源项目的社区。

许多工具包括商业的和开源的，都可以帮助混沌工程实践。下表给出了这个领域的一些工具示例：

工具名称	开源或商用	网站地址
Byteman	开源	https://byteman.jboss.org
Chaos Monkey	开源	https://github.com/Netflix/ch...
ChaosIQ	商用	https://www.chaosiq.io
Gremlin	商用	https://www.gremlin.com
Jepsen	开源	http://jepsen.io
Mangle	开源	https://github.com/vmware/mangle
Simian Army	开源	https://github.com/Netflix/Si...
Spinnaker	开源	https://github.com/spinnaker
Verica/ChaoSlinger	开源	https://www.verica.io

推荐阅读

作者：Jim Scheibmeir, George Spafford

时间：2019 年 11 月 4 日

标题：How to Safely Begin Chaos Engineering to Improve Reliability

来源：Gartner

"How to Safely Begin Chaos Engineering to Improve Reliability", By Jim Scheibmeir, George Spafford, Manjunath Bhat. 2019 (Original)

Curry, David M. “Practical Application of Chaos Theory to Systems Engineering.” Procedia Computer Science. 2012.

“Edward Lorenz, Father of Chaos Theory and Butterfly Effect, Dies at 90.” MIT News. April 2008.

Encyclopedia Britannica editors. “Chaos Theory.” April 2019.

Ostrom, Lee T. and Wilhelmsen, Cheryl A. “Risk Assessment: Tools, Techniques, and Their Applications.” Wiley. 2012.

“Netflix Uncages Chaos Monkey Disaster Testing System.” Network World. July 2012.

来源：混沌工程实践

作者：CloudMamba/黄茂

声明：文章获得作者授权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术同伴，如原作者有其他考虑请联系小编删除，致谢。

6月每周四晚8点，【冬哥有话说】开心一“夏”。公众号留言“开心”可获取地址

• 0603 无敌哥 《IDCF人才成长地图与5P》（《端到端DevOps持续交付(5P)精品课》第1课）
• 0610 冬哥 《带你玩转创新设计思维》
• 0617 无敌哥 《敏捷项目管理到底是个啥》
• 0624 冬哥 《VUCA时代的敏捷领导力》