最近参加了ECUG大会，其中有一个分享是pingCAP的CEO大佬刘奇分析的他们开源的在k8s平台上使用的混沌工程插件Chaos Mesh，我第一次听说混动工程这个概念，应该是在18年上半年，那时候的我还没毕业，有一天在找资料的时候，在掘金还是segmentfault上（记不清）看到一篇文章，讲的是混沌工程，点击去看了几分钟，emmmm，没看懂，里面各种各样的名词让我云里雾里。于是就离开；直到今年年初阿里巴巴开源了ChaosBlade。这个概念又一次闯进了我的世界。脑子还残存着中二少年对混沌这个词的执念，带着一丝记忆开始调研这项技术。这次我看懂了…，说白了就是给系统找茬，一会捅咕这，一会鼓捣那，反正就是折磨系统，找出系统的薄弱点，提升系统的容错能力，提高系统的健壮性。下面就来仔细说道说道这个东西。
1 什么是混沌工程？
1.1 混沌工程的起源
2008年之前，国际巨型视频网站Netflix的模式还是自建机房，自己维护，但是由于在全球有超1亿用户，所以流量特别大，有一天服务宕机，导致部分国家的不可用长达一天时间，于是他们下狠心将服务区迁移到AWS上，做了多节点分布式部署，同时增加对服务的可用性、容错性、健壮性测试，而这套测试就是混沌工程的前身。他们将这种测试方法和工具抽象剥离出来后，起名叫Chaos Monkey，寓意为上蹿下跳捣乱的猴子（看来猴子这个物种无论海内海外，都认为他们喜欢捣乱，想想大闹天宫的大圣）。
经过几年的发展，这种思想被海内外争相效仿，来提升自己公司的产品，而就在这个时候，2014年Netflix宣布新增一个职位叫混沌工程师，代表他们将混沌工程融入了公司的运维文化，这也直接瞬间激起混沌工程的热度。
2015年，Netflix与社区正式提出混沌工程原则，从此Netflix不再是一种工具，一个方法，而是真正的有了一套理论支撑
1.2 混沌工程的目的
- 提高系统架构的容错能力与健壮性
- 提高开发和运维的故障应急效率
- 提早暴露问题，降低线上故障发生率与复发率
- 提高用户使用体验
混沌工程可不是恶意找茬，而是为了优化服务而做出的检测与尝试，毕竟大佬尼采曾经说过：“打不到我的必然是我更加强大”
1.3 混沌工程的五个原则
1.3.1 建立稳定状态的假设
在做混沌工程实验的时候，首先得确定需要测试的指标已经做了高可用的工作，才能进行验证指标对业务的是否有影响。如果没有做好高可用工作，而引入混沌工程实验的话，对业务而言将会是一声灾难。
1.3.2 多样化现实世界事件
不能够凭空想像出一些事件来验证，而是引入那些真实存在的，频繁发生的，且影响重大的事件。对我们而言给这些事件做混沌实验才具有价值。如磁盘故障、网络延时、主机宕机等。
1.3.3 在生产环境运行实验
尽量在类生产环境中进行测试，生产环境的多样性是任何其它环境无法比拟的。混沌工程的价值就是保证生产上的业务连续不中断。
1.3.4 持续自动化运行实验
实施混沌工程实验一般最开始是人工手动操作，当我们对业务有足够的信心时，要把混沌实验做成持续自动化。在版本升级、不断迭代的过程中，持续不断自动化地做验证，最大程序保证业务的连续性验证。
1.3.5 最小影响范围
做混沌工程的意义就是保证生产上的业务。在我们实施混沌实验时也必须保证对线上业务影响最小。在实施实验时，从小范围开始，不断扩大范围，避开高风险时段，如选择业务量最小的时候实施实验。
2 混沌工程如何实践
2.1 实施混沌工程的步骤
有了这些原则，就可以根据业务的真实场景设计混沌工程实验。
在真实展开实验时分为两个阶段：准备阶段、执行阶段。
-
准备阶段
-
确认本次实验需要验证的目标。遵循建立稳定状态的假设、多样化现实世界事件的原则。例如：Redis的超时不会对系统影响。代码中已经对Redis超时的情况做了相关的工作，保证业务的可靠。实验只是用来测试验证。
-
选择实验范围。遵循对线上业务影响最小、尽量与生产环境相近的原则。例如先测试环境验证，生产环境选择最小量用户验证。如果求稳，可以先进行流量录制，在其他环境对流量进行重放，进行打标实现可控制的爆炸半径更大
-
确认监控指标。例如：订单成交量、应用请求响应时间、应用响应错误率，做好监控实时查看状态。
-
团队成员沟通。遵循最小化影响范围。确保团队相关成员了解实施情况，关注业务状态。准备阶段一般只是第一次实验的时候操作，一旦验证好了以后以后，后续重复执行本次工程不需要重新准备，除非对实验过程有变动。
-
-
执行阶段
-
执行实验。遵循最小化影响范围。执行过程中实时关注指标，如果有异常，随时终止实验。例如，把Redis延时调大，查看监控指标是否有异常。
-
分析结果。遵循最小化影响范围。根据收集的指标数据确认假设Redis的超时不会对系统影响。如果验证假设不成立，则需要分析代码，确认好原因，再组织下一次的混沌工程实验。
-
扩大实验范围。遵循最小化影响范围。先小范围测试，再逐步扩大测试范围。
-
自动化。遵循持续自动化运行实验。当对代码有足够的信心之后，将混沌工程实践做成自动化，让混沌工程实验能够持续保证业务的可用性，获得最大的价值。
-
2.2 在企业中落地
面对上级，表达出混沌工程的价值以及如何控制影响面，最主要的要选对故障背锅人（哈哈哈哈，开玩笑）
面对业务方，表达为啥实施实验，能给业务带来什么价值，如何修复发现的问题
2.2.1 系统评估
评估系统成熟度，了解系统，并且思考实验环境的选择以及故障注入的范围大小以及故障画像
系统成熟度：
实验环境及故障范围：
流量录制：
故障画像：
2.2.2 选择合适的混沌实验工具
选择实验工具，我们要根据以下几点进行考虑
- 场景丰富度（进程、网络、应用、容器）
- 工具类型（实验工具、开发框架、产品平台）
- 易用性
- 构建语言
- 社区状态
2.2.3 混沌工程技术演进
一个好的混沌工程绝对不是几天几个月就能建成的，一定要经过岁月的沉淀，反复的思考，稳重的提升，还记得阿里最早的混沌工程吗，当众减网线，从最早的同城容灾，断网演练到后来的公司级故障演练平台。多少个双11背后如果没有大量的故障演练支持，就没有阿里的今天。
3 技术选型
下面我们将对市面上主流的几款混沌工程的工具进行对比：
- chaos-mesh(PingCAP)
- ChaosMonkey(Netflix)
- ChaosBlade(Alibaba)
- ChaosKube
- Litmus
看着下面的图，我们也能看出来，在k8s这个平台上chaos-mesh支持的最好，而在JVM平台上阿里的ChaosBlade也不错。
Talk is cheap, Show me the code! But first, show me the demo!!!
两个工具的使用都比较简单，这里不进行演示，下面提供两者的github地址
