共计 5405 个字符，预计需要花费 14 分钟才能阅读完成。
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 时代的麻利领导力》