1.为什么需要混沌工程？（译自混沌工程电子书）1.1混沌工程与故障测试的区别混沌工程是一门对分布式系统进行实验的学科，目的是建立一个在生产环境中抵抗失控情况的系统。能力和信心的概念最早是由Netflix和相关团队提出的。故障演练是阿里巴巴在混沌工程领域的产物。目标是沉淀常见的故障模式，以可控的成本在线回放，通过不断的演练和回归操作暴露问题，不断推动系统、工具、流程、人能力的不断进步。混沌工程、故障注入和故障测试在重点和工具上都有很大的重叠。混沌工程与其他方法的主要区别在于，混沌工程是一种生成新信息的实践，而故障注入是一种测试情况的??特定方法。注入诸如通信延迟和错误之类的故障是探索复杂系统可能出现的不良行为的好方法。但我们也想探索诸如流量激增、激烈竞争、拜占庭故障以及计划外或不寻常的消息组合等问题。如果一个面向消费者的网站突然因流量激增而产生更多收入，我们很难将其称为错误或失败，但我们仍然非常有兴趣探索该系统的影响。同样，故障测试会以某种预想的方式破坏系统，但如果不探索可能发生的更奇怪的场景，则可能会发生不可预测的事情。测试和实验之间可能存在重要区别。在测试中，做出断言：给定特定条件，系统将发出特定输出。测试通常是二进制的，并确定一个属性是真还是假。严格来说，这不会产生关于该系统的新知识，它只是为其已知属性分配化合价。实验会产生新知识，并且通常会提出新的探索途径。我们认为混沌工程是一种可以产生关于系统的新知识的实验形式。它不仅仅是一种测试已知属性的方法，可以通过集成测试更轻松地验证这些属性。混沌实验的示例输入：模拟整个区域或数据中心的故障。部分删除各种实例上的Kafka主题。重现生产中出现的问题。为特定百分比的事务在服务之间注入预期的访问延迟。基于函数的混淆（运行时注入）：导致抛出异常的随机函数。代码插入：在目标程序中添加指令，并允许在某些指令之前进行故障注入。时间旅行：强制系统时钟彼此不同步。在模拟I/O错误的驱动程序代码中执行例程。最大化Elasticsearch集群上的CPU内核。尝试混沌工程的机会是独一无二的，并且可能因分布式系统的架构和组织的核心业务价值而异。1.2实施混沌工程的先决条件要确定您是否准备好开始采用混沌工程，您需要回答一个问题：您的系统能否适应现实世界的事件，例如服务故障和网络延迟尖峰？如果答案是“否”，那么您还有一些工作要做。混沌工程非常适合发现生产系统中未知的弱点，但如果您确定混沌工程实验会导致系统出现严重问题，那么运行混沌工程实验就没有意义了。先修复那个弱点，然后再回到混沌工程，它会发现你不知道的其他弱点，或者它会让你发现你的系统实际上是有弹性的。混沌工程的另一个基本要素是监控系统，可用于确定系统的当前状态。1.3混沌工程原理为了具体解决分布式系统规模的不确定性，混沌工程可以看作是一种揭示系统弱点的实验。打破体内平衡越难，我们对系统的行为就越有信心。如果发现弱点，那么我们就有了改进的目标。避免问题在系统扩展后被放大。以下原则描述了应用混沌工程的理想方式，这些原则用于实施实验过程。这些原则的匹配程度可以增强我们对大规模分布式系统的信心。2、阿里巴巴在混沌工程领域的实践：故障演练混沌工程是一门新兴的技术学科，行业知识和实践积累相对较少。大多数IT团队还没有将他们对它的理解提升到一个领域概念。阿里电商领域在2010年左右开始尝试故障注入测试，最初的目标是解决微服务架构带来的强弱依赖问题。后来经过几个阶段的改进，最终演变为MonkeyKing（在线故障演练平台）。从发展轨迹来看，阿里的技术演进和Netflix的技术演进基本在一条时间线上。每个阶段解决方案的诞生都有其独特的背景和业务难点。我们也可以看到当时技术的局限和突破。.2.1围绕稳态行为建立假设目前阿里巴巴集团内部的做法偏向于故障测试，即在特定场景下进行故障注入实验，验证是否达到预期。这种检测的风险相对可控。缺点是没有通过故障注入实验探索更多场景，暴露更多潜在问题。测试结果更依赖于实施者的经验。目前的失败测试期望分为两个层次，要么过于关注系统内部细节，要么对系统的性能完全没有期望，这与混沌定义的稳态行为有很大区别工程。造成差异的根本原因仍然是组织形式的差异。2014年，Netflix团队创建了一个名为ChaosEngineer的新角色，并开始将其推广到工程社区。但是，阿里目前并没有专门的职位来实施混沌工程。项目目标、业务场景、人员结构、实施方式的差异导致对稳态行为的定义不规范。2.2多样化的现实事件阿里巴巴业务场景多样化，服务节点规模庞大，系统架构高度复杂，每天都会遇到各种各样的故障。这些故障信息是最真实的混沌工程变量。为了能够更加明智高效的描述故障，我们优先分析P1和P2的故障（P是阿里对故障级别的描述），提出一些常见的故障场景，并从IaaS层的角度进行抽取，PaaS层和SaaS层故障镜像。从故障的完整性来看，以上画像只能粗略代表已经出现的部分问题，未来可能出现的新问题还需要一种方法来保持兼容性。经过更深入的分析，我们定义了另一个维度的故障画像：任何故障都必须是硬件（如IaaS层）、软件（如PaaS或SaaS）的故障。并且有一个规律，就是硬件故障现象一定会反映在软件故障现象上。故障必须属于单机或分布式系统之一，分布式故障包括单机故障。对于单机或同机型的故障，从系统的角度来看，可能是当前进程的故障，如：FullGC，CPU飙升；进程外的故障，比如其他进程突然占用内存，导致当前系统不正常等。同时，也可能存在一类因人为失误或工艺不当造成的故障。今天我们不关注这部分。从故障注入实现的角度，我们也参考了上述画像进行了设计。之前，我们分别使用Java字节码技术和操作系统级工具来模拟进程内和进程外故障。随着Serverless、Docker等新架构、新技术的出现，故障的实现机制和接受载体也会发生一些新的变化。2.3生产环境运行实验从功能故障测试的角度来说，在非生产环境中实现故障注入是可以达到预期的，所以最早的强弱依赖测试是在日常环境中完成的。但由于系统行为会根据环境和流量模式而有所不同，为保证系统执行方式的真实性和当前部署系统的相关性，推荐的实现方式还是在生产环境（模拟环境和沙箱环境不是***sChoice）。许多同学害怕在生产环境中进行实验，因为他们担心失败的影响将无法控制。实施实验只是手段，通过实验建立对系统的信心才是我们的目标。如何减少实验的影响将在“最小化爆炸半径”部分讨论。2.4连续自动化运行实验2014年，离线环境下的强弱依赖测试用例默认在每次发布后自动执行。2015年，开始尝试线上自动化回归。不过，近两年来，人工实验的比例逐渐增加。原因并不复杂。虽然故障注入是自动化的，但是业务验证的成本还是比较高的。在业务快速发展、人员变动迅速的环境下，维护一套相对完整的在线回归用例是非常困难的。虽然也出现了流量记录技术，但由于混沌工程实验本身会打破系统现有的行为，基于出入口流量对比的参考度会下降很多。为解决测试成本问题，2017年初开始搭建线上微灰度环境，根据业务和比例过滤特征流量，用真实流量替换原有测试流量，用监控告警替换测试用例结果数据。目前已有部分业务基于微灰度+故障演练模式进行了演练验证（例如：盒马APOS容灾演练）。因为故障演练之前是作为技术组件嵌入到正常和推广过程中，所以在系统构建自动化的编排和分析上不是很产品化。锻炼视觉编排和能力开放将是我们团队未来的重点，这将在下面的规划部分进行说明。2.5最小化爆炸半径在生产中进行实验可能会引起不必要的客户投诉，但混沌工程师有责任和义务确保将这些后续影响最小化并考虑在内。彻底讨论实验协议和目标是减少用户影响的最重要手段。但从实际实施来看，***还是通过一些技术手段将影响降到最低。ChaosEngineering和FaultInjectionTest的核心区别在于：能否进一步降低故障的影响，比如微服务层面、请求层面甚至用户层面。孙悟空进化到中期，已经可以实现请求级的微服务故障注入。虽然当时演练实施的主要地点是测试环境，但初衷是为了减少注入故障带来的环境不稳定。除了故障注入，流量路由和数据隔离技术也是降低业务影响的有效手段。3.未来计划在线故障演练发展到现在已经是第三个年头了。随着阿里安全生产的大环境，业务方的诉求，研发迭代模式的改变，大家对混沌工程的接受度和理解度的提高。集团演练场未来将围绕几个目标：建立高可用的专家数据库，从结构上提高应用的容错能力（解决“稳态定义”的问题），建立故障注入实施标准，在集团内开源，并提高故障模拟能力的广度和深度（拓宽“多样化的真实世界事件”的广度）核心业务的规模覆盖（提升“生产环境跑实验”的规模）以产品和平台思路开放演练能力（探索《自动化运行实验》)》之道)4、触手可及的混沌工程MonkeyKing已提供商业产品，欢迎到阿里云官网搜索“AHAS”免费公测。地址：https://www.aliyun.com/product/ahas参考：ChaosEngineering（O'Reilly出版）【本文为专栏作者《阿里巴巴官方技术》原创稿件，转载请联系或原创作者转载】点此查看该作者更多好文
