扫码阅读
手机扫码阅读

聊聊混沌工程

35 2024-01-31

这是鼎叔的第五十四篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

混沌工程是一门新兴学科,它不仅仅只是个技术活动,还包含如何设计能够持续协作的混沌实验。它由Neflix首先在实践中发现了混沌工程的商业价值,通过构建更有韧性的系统来抵御海量组件系统的意外失效。本文还会聊聊混沌工程的概念澄清,原则,投资回报和成熟度模型。

本文的内容参考了《混沌工程-复杂系统韧性实现之道》,作者是Casey Rosenthal,Nora Jones。

Neflix的混沌猴‍‍

Neflix的高绩效文化体现在管理层和技术人员的有趣协作,管理者不会告诉技术人员要做什么,而是确保他们了解要解决什么问题,并信任技术工程师,让他们决定工作的完成方式。

为了解决大型数据中心的实例无故消失问题,工程师尝试了各种方法,最终只有混沌猴这种方法保留下来。原理非常简单,遍历集群列表,从每个集群中随机选一个实例,在每个工作日的某个时间点将其关闭且不会发出警告。工程师只有解决了问题才能进行其他工作,不管是增加冗余,还是增加自动化容量伸缩,或是架构层面设计优化,都带来了可观的成效。

不幸的是,随机性混沌注入方法,在分布式系统上的效果都不好,故障的组合空间巨大,且并不孤立。随机方法也无法告诉我们实验的覆盖情况,应该进行多长时间才能得出结论。

替代随机搜索的方法,就是利用系统专家的领域知识来推动实验探索,利用之前实验观察形成新的假设并逐步完善。专家对故障注入进行筛选,决定哪些实验不需要进行,避免重复。专家还会决定实验的运行顺序,尽可能提高知识增加的速度。专家也需要可观测的基础设施,越丰富越好。

混沌猴后来升级为混沌金刚,使某个AWS区域关闭,验证AWS区域性故障的解决方案,大幅提升了组织内部对于故障的处理速度。后面即使发生多起停机事故,混沌金刚使用的区域故障转移机制都发挥了作用。

混沌工程由此被定义:它是分布式系统上进行实验的学科,目的是建立该系统能够承受生产环境的动荡条件的信心。不需要建立对系统的信心,就不需要混沌工程。

混沌工程通过提供可能超出“快乐路径”(即系统构建的默认路径,没有异常或错误情况)的各种条件和变化参数,来做到这一点。

如今混沌工程已经形成了强大的专业社区。

复杂系统

混沌工程这门科学要寻找系统存在弱点的证据,它们会隐藏在系统的本质复杂性中。复杂系统因为非线性导致不可预测,必然会导致不良结果。系统内的部件所发生的变化会导致系统输出发生指数级变化。输出难以模拟或建模,导致传统的探索系统安全性的方法不够充分。

复杂系统中,不同服务模块各自都有合理的设计决策和监控处理机制,但仍然会出现难以意料的崩溃。

比如场景一,少量用户的消息异常不断重试,可能导致服务降级,进而触发更大范围的重试风暴,导致服务不可用。

场景二,导入的程序库出现的内存泄漏,可能会随着服务请求数量的增加而缓慢增长,直到影响大量实例的错误率,导致局部停机。

面对复杂性,人月神话(聊聊没有35岁焦虑的《人月神话》)将其分类为偶然复杂性和本质复杂性,前者是在资源有限的项目中编写代码,必然产生各种债务-代码劣化、含糊的契约、废弃的代码路径、不清晰的变量名等。编写软件和理解软件如何失效,完全是两件不同的事情。

没有可持续的方法来解决偶然复杂性,甚至新系统会做得更加复杂。对于本质复杂性,只要添加新功能就会增加。

既然无法避免复杂性,那就接纳它,学会如何应对,而混沌工程就是最有效可行的利器。推荐两个应对复杂系统的模型。

一 动态安全模型

这模型有三个属性:经济性(投入的成本),工作量和安全性。工程师对成本和工作量有边界直觉,但是对安全性缺乏直觉。安全事故通常都是意料之外的,而工程师只会对能看到的地方进行优化。混沌工程就是培养工程师安全性直觉的,进而默默地改进行为,让系统更有韧性。

二 经济支柱模型

复杂性有四个经济支柱:状态,关系,环境,可逆性

一个研发组织控制某个支柱的程度,能反映出组织应对竞争性生产过程的复杂性的成熟度。一个汽车大厂可以控制产品状态(有限的款式),关系(上下游产业链的供货关系),环境(对外部法规的影响),但没法控制可逆性,汽车制造容易回退难。

一个应用程序的功能(状态)大多不断在增加,而无法简化。组件关系和人际关系都在复杂化。大多软件公司都没有影响环境的规模化能力。只有可逆性是软件团队可以大放异彩的支柱(即不断修改完善软件)。

而混沌工程实验能够揭示系统哪些方面违背了“可逆性”。

混沌工程的原则

混沌工程的通用解释,是“促进发现系统弱点的实验”,分为四个步骤

1 先定义“稳态”(steady state),系统行为正常时有哪些可以度量的输出

例如,在XXXX情况下,用户依然拥有良好的体验,表现在XXX数据上。

在XXX事件发生时,技术人员会得到XXX提醒。

2 建立假说,对照组和实验组都会持续这种稳态。

3 引入体现真实事件的变量。选择变量常见的误区是,工程师的选择标准经常是容易执行的,基于自身体验而不是用户体验的。有些“异常事件”在现实世界不太可能发生,这就不是好的引入变量。

4 通过在对照组和实验组之间寻找稳态差异来推翻假说

混沌工程原则提供了五项高级实践及黄金标准:建立稳态行为假说,多样化引入现实世界的事件,在生产环境实践,持续运行自动化实验,最小化爆炸半径

为了给真正关心的生产环境建立信息,高级的混沌工程都在生产环境发生,但是初始阶段先在准生产系统上实验也是有意义的。

自动化提供了规模化搜索的方法,比人手动操作,能覆盖更多的实验集;随着时间的推移能低成本地持续验证经验假设,及时发现系统的变化。

设计更安全的实验方法,将对生产环境中用户流量的负面影响降到最低,还带来加强信号检测效果的好处。

聚焦用户体验是所有高级原则的基础。

对混沌工程的常见误解

一 实验和测试是不同的

实验并不知道如何断言,而是通过假说的验证或推翻来得到新知识。源于应对复杂系统问题,所以混沌工程更多体现“未知的实验性”而非“已知的测试性”,主张验证有效性,而不是检查如何工作。

二 混沌工程并非人们误解的“搞破坏”

单纯搞破坏,很难做到减小爆炸半径,和漏洞的批判性思考。混沌工程最终的价值是修复生产环境的漏洞

三 很多人认为塔勒布的《反脆弱》理论和混沌工程在本质上是一样的。

实际上两个流派分歧很多,反脆弱缺乏软件工程学的同行评审和理论基础,给出的解决手段(如增加冗余)可能会带来更多风险。反脆弱希望给系统引入混沌,而混沌工程希望发现复杂系统的固有混沌。

四 软件接口设计不规范等问题能否通过混沌工程来发现

接口契约不匹配的协商解决,是开发过程的一部分,无需纳入混沌工程来解决,这些已知属性问题最好通过软件测试解决。混沌实验主要为不确定的自动化行为提供信心,它发现的BUG往往是多个细微逻辑错误的组合,以及时间相关性故障。

注意,被选定实验的特定服务及其依赖服务,如果存在已知的关键缺陷,要先修复后再进行实验,否则我们不能从实验中学到确定的新东西。

混沌工程的投资回报

只有事故真的发生了,才能有故事可讲。”-- John Allspaw

混沌工程是一门务实的学科,旨在为企业提供价值。但是如何证明混沌工程的回报是令人困惑的。

系统可用性指标的上升,是否应该归功于混沌工程实践呢?混沌工程触发的改进,倾向于给其他业务增加压力,比如牺牲了发布速度,那如何确定收益率呢?

Kirkpatrick模型提供了一种评估投资回报率的方法,原本用于教学培训领域,它把评估分解为四个递进的级别:反应(混沌工程示范对受训者有帮助,是否支持维持或加大该实验),学习(证明并列举团队学到了什么),转移(把知识转化为实践,发生了行为变化,提高了协作效率,提高了应急成熟度),结果(混沌工程的总成本,与商业结果价值进行比较)。每一级是否评价为积极,就展示了对应的投资回报。

混沌成熟度模型

成熟度模型横轴是采用度,纵轴是复杂性

“采用度”考虑这几个因素:接受者,参与者,采用门槛(是否有观测工具,积极讨论的共识,经得起考验的假说,一致的响应行动),采用障碍(业务的担心,合规性,从未发生过事故,难以衡量回报率)

“复杂性”,会随着实验的发展而提升,如下所示:

  • 1 Game Day,实践试水,复杂性低,但是消耗大量人力,无法在大量服务上规模化执行。

  • 2故障注入框架。工具可以让多个团队进行实验,进行更多跨功能性的学习。

  • 3 实验平台。满足更好实验的需求,在对照组和变量组进行安全对比,控制最小爆炸半径。每个实验都要被平台监控。

  • 4 平台自动化。完全自动化进行的混沌工程,包括实验的创建、优先级排序、执行和推翻/终止。平台能够“自我反省”,只自动运行哪些对实验假说有可量化期望的实验。

    平台还可以进一步进行能力升级,如控制“混沌预算”,使用组合实验变量构建实验,自动修复漏洞。

    被引入的实验变量也可以不限于基础设施层级,还可以是应用程序逻辑层的变量-比如给服务返回出乎意料的响应。

‍‍‍‍‍‍基于混沌成熟度绘制的表格,就可以看到本组织所处的位置,确定如何技术投资的路径,达到高复杂性与高参与度,让混沌工程创造最大的价值。

下一篇,我们详细介绍各大企业实践混沌工程的优秀流程,经验教训,人和组织的能力提升,从中学习到了哪些洞见。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484183&idx=1&sn=07ee33f846220e7687fe9bfaf965dd72&chksm=c24fb675f5383f638ee8f13a0c5dada5c695293cfe4ad758becc5353d4fb48c12450b7ccd1fa#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 5358
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线