Netflix正在搞的混沌工程到底是什么？终于有人讲明白了
导读：与任何新概念一样，混沌工程时常被误解。本文会探讨混沌工程是什么以及不是什么。
作者：Casey Rosenthal, Nora Jones
来源：大数据DT（ID：hzdashuju）
在Netflix的混沌工程实践之初，大家实际上并不明确这门学科究竟是什么。关于如何让服务更可靠存在着许多误解。比如那时经常听到这样一些口号——拔掉电缆、在生产环境搞破坏或在生产环境进行测试。另外，也几乎不存在混沌工程实际工具的例子。
Netflix成立混沌工程团队就是要创建一门有意义的学科。该学科能够借助工具主动提高可靠性。我们花了几个月的时间研究韧性工程和其他学科，并提出混沌工程的定义和蓝图以造福他人。
混沌工程的定义已经以宣言的形式上线，称为“混沌工程原则”。
https://principlesofchaos.org
01 混沌工程是什么
混沌工程原则定义了混沌工程学科，以便大家了解何时该进行、该如何进行以及该如何做好混沌工程。如今，混沌工程的通用定义是“促进发现系统弱点的实验”。混沌工程原则的网站概述了如下实验步骤：
- 首先定义“稳态”（steady state，稳定状态），以表示系统正常行为的某些可测量的输出。
- 建立如下假说—对照组和实验组都将持续这种稳态。
- 引入反映真实事件的变量，例如崩溃的服务器、发生故障的硬盘驱动器、断开的网络连接等。
- 试图通过在对照组和实验组之间寻找稳态差异来推翻这一假说。
该实验构成了混沌工程的基本原则，并为实验的实施提供了很大的自由度。
1. 实验与测试
在Netflix，我们发现首先必须要做出的澄清是，混沌工程是一种实验而非测试。可以说，“质量保证”涵盖了两者，但该词在软件行业通常具有负面含义。
最初，Netflix的某些团队会问混沌工程团队：“难道你们就不能编写一堆集成测试来发现同样的问题吗？”从理论上讲，这种观点是务实的。但实际上，不可能从集成测试中获得理想的结果。
严格来说，测试不会创造新知识。测试要求编写测试的工程师知道要验证的系统的特定属性。复杂系统对于这种类型的分析是不透明的。对于复杂系统中各个部件所有的潜在相互作用所带来的所有潜在副作用，人类根本就无法理解。这使我们得出了测试的下述关键特性。
测试会根据现有知识做出一个断言，然后执行测试，并给出该断言的结果（通常为真或假）。测试是关于系统已知属性的声明。
另一方面，实验创造了新知识。实验提出了一个假说，只要假说不被推翻，对该假说的信心就会增强。而如果假说被推翻了，那就会学到一些新东西。这就能启动一个调查，以弄清楚假说为什么是错的。
在复杂系统中所发生的事情的原因通常都不会是显而易见的。实验可以建立信心，也可以让我们学到系统的新属性。这是对未知的探索。
因为测试需要有人提前提出断言，所以仅凭测试是无法取得通过实验而收获的洞察的。实验引入了一种发现新属性的正规方法。而当发现了系统的新属性后，完全可以将其转换为测试。
实验还有助于将有关系统的新设想编码为新的假说，从而创建类似“回归实验”的实践，以便随着时间的推移而对系统做进一步探索。
由于混沌工程诞生于应对复杂系统问题，因此该学科必须体现实验性而非测试性。
2. 验证与清查
在运维管理和物流规划领域，验证（verification）和清查（validation）的定义是不同的。而混沌工程更偏重于验证。
- 验证
复杂系统的验证是在系统边界分析输出的过程。比如房主可以通过测试水槽（系统边界）中的污染物，来验证水（输出）的质量，而无须了解管道或市政供水系统（系统部件）的功能。
- 清查
复杂系统的清查是分析系统的各个部件并建立反映部件之间的相互作用的思维模型的过程。房主可以通过检查所有管道和基础设施（系统部件）来清查水质。这些管道和基础设施会采集、清洁和输送水（功能部件的思维模型），并将水输送到居民区中的千家万户。
这两种做法都是有用的，并且都可以建立对系统输出的信心。作为软件工程师，我们经常会偏向于强迫自己去深入研究代码，并验证代码是否反映了我们关于代码应如何工作的思维模型。与这种偏好相反，混沌工程极力主张进行验证而不是清查。混沌工程所关心的是某事是否有效，而不是如何工作。
请注意，在上面有关管道的隐喻中，虽然可以清查用于提供清洁饮用水的所有组件，但由于某些未曾想到的原因，最终水龙头里流出来的仍是被污染的水。在复杂系统中总是存在不可预测的交互。但是，如果验证水龙头流出的水是干净的，那么就不必操心水是如何来的。
在大多数业务案例中，比起考虑系统的实现是否符合我们的思维模型，系统的输出要重要得多。混沌工程更关心业务和输出，而不是正在互动的各个部件的实现或思维模型。
02 混沌工程不是什么
有两个概念经常和混沌工程混淆——在生产环境中搞破坏和反脆弱。
1. 在生产环境中搞破坏
在博客文章或会议演讲中，人们时常会将混沌工程描述为“在生产环境中搞破坏”。对于能从混沌工程中获益良多的大型企业以及其他复杂系统的运营者来说，尽管这句话听起来很酷，但对他们并没有吸引力。
有关混沌工程的一个更好的说法是：修复生产环境中的漏洞。 “搞破坏”很容易，但完成下述事情很难：减小爆炸半径，对安全性进行批判性思考，确定漏洞是否值得修复，决定是否应该进行实验，等等。
“搞破坏”可以用无数的方式来完成，且花费的时间也很少。但更大的问题是，在不知道系统部件已被破坏的情况下，该如何推测出哪些部件已经被破坏？
“修复生产环境中的漏洞”能更好地体现混沌工程的价值，因为整个混沌工程实践的重点是主动提高复杂系统的可用性和安全性。现在已经有很多对事故做出应急反应的学科和工具，比如告警工具、事故响应管理、可观测性工具、灾难恢复计划等。其目的是当事故发生后能缩短检测时间和修复时间。
有人可能会说，SRE（Site Reliability Engineering，网站可靠性工程）是一门兼具被动性和主动性的学科，可以通过从过去的事故中获得知识，并将知识进行社交化来防止将来发生类似的事故。而混沌工程是软件行业中唯一专注于主动提高复杂系统安全性的学科。
2. 反脆弱
熟悉纳西姆·塔勒布（Nassim Taleb）所提出的反脆弱性概念的人，经常会认为混沌工程本质上是反脆弱的软件版。塔勒布认为，诸如“低剂量毒物兴奋效应”之类的词，已不足以表达复杂系统的适应能力。因此他发明了“反脆弱”一词，指系统当受到随机压力时能变得更强的特性。
混沌工程和反脆弱之间一个重要的关键区别是混沌工程能教育系统维护人员，让他们认识到混沌为系统所固有，从而使他们成为一支更具韧性的团队。而相比之下，反脆弱却给系统加入混沌，并希望系统在响应混沌时能变得更强大，而不是屈服于混沌。
作为框架，反脆弱的观点与学术界所研究的韧性工程、人因学和安全系统都不一致。例如对于提高系统健壮性而言，反脆弱建议的第一步是寻找并消除弱点。这项建议看似直观，但韧性工程告诉我们，对于安全性而言，寻找做对的地方要比寻找做错的地方提供的信息要多得多。
反脆弱的下一步是添加冗余。这似乎也很直观，但是添加冗余既可以缓解故障，也可以导致故障。在有关韧性工程的文献中有众多冗余所导致的安全性故障案例。
这两种思想流派之间还存在许多其他分歧。韧性工程是一个有着数十年历史，并正不断发展的研究领域。而反脆弱则游离于学术界之外，且缺乏同行评审。因为两者都是要应对混沌和复杂系统，所以很容易就产生两者可以融合在一起的感觉。
但反脆弱实际上并不具备混沌工程所拥有的经验主义和理论基础。由此，两者在根本追求上就已分道扬镳。
关于作者：Casey Rosenthal，Verica公司的首席执行官兼联合创始人。他曾是Netflix公司混沌工程团队的工程经理，在使用分布式系统、人工智能以及将新颖的算法和学术界知识转化为能落地的模型方面拥有丰富的经验。
Nora Jones，Jeli公司的首席执行官兼联合创始人。她是一位敬业且充满自驱力的技术领导者和软件工程师，对分布式系统中人与软件的协同工作充满热情。她在2017年AWS re:Invent大会的主题演讲中为混沌工程运动的发起做出了贡献。
本文摘编自《混沌工程：复杂系统韧性实现之道》，经出版方授权发布。
延伸阅读《混沌工程：复杂系统韧性实现之道》
转载请联系微信：DoctorData
推荐语：混沌工程开创者撰写，通过谷歌、微软等行业专家的真实故事，系统阐释混沌工程的核心实践，提供实践建议。