公司新成立了一个稳定性团队，20年的重要目标之一就是开展混沌工程。为了后续更好的开展工作，记录关于“混沌工程”相关的知识以及工程实践。
内容来源：《混沌工程：Netflix系统稳定性之道》摘录以及个人思考总结。。。。。。
概要
定义：主动发现系统中脆弱点的一整套方法论。
目的：如何让系统在不确定性中获益？
接受“系统越复杂，越脆弱”的事实，让系统在每一次失败中获益，然后不断进化。
在实践中，用一系列的实验来真实的验证系统在各类故障场景下的表现，通过频繁大量的实验，使得系统本身的“反脆弱性”持续增强，让组织建立对系统抵御生产环境中失控条件的能力以及信心。
初衷：通过实验性的方法，让人们建立复杂分布式系统能够在生产中抵御事件能力的信息。
出现：最早由Netflix的技术团队提出，现已经演变成计算机科学的一门新兴学科，即“混沌工程”。
现状：目前业内的认知和实践积累较少，但它实际上是一种提高技术架构弹性能力的复杂技术手段。
挑战：服务规模不断增长，服务间依赖带来的不确定性指数级增长。软件可用性面临两大挑战：
1）自身复杂度激增；
2）开发者引入复杂性的同时对风险的低估和忽视；
方法：通过一系列可控实验和执行实验原则，揭示出系统中随时发生的各类事件是如何逐步导致系统整体不可用的。
书籍：《混沌工程：Netflix系统稳定性之道》
工具
Chaos Dingo：支持在Azure相关服务上进行实验。
Chaos-http-proxy：向http注入故障的代理服务工具。
Tugbot：可在基于docker的生产环境中进行测试的框架。
Chaos Lambda：办公期间可随机关闭AWS ASG节点的工具。
Blockade：基于docker，可测试网络故障和网络分区的工具。
Pumba：基于docker的混沌工程测试工具以及网络模拟工具。
Simoorg：LinkedIn开发的故障注入工具，以扩展，很多关键组件可插拔。
Chaos Lemur：测试高可用性系统弹性的工具，可本地部署，允许随机关闭BOSH虚拟机。
Monkey-Ops：Go语言实现，可在OpenShift V3.X上部署并在其中生成混沌工程实验。可随机停止OpenShift组件。
ChaosBlade：阿里开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具，是内部MonkeyKing对外开源的项目，结合了阿里各业务的最佳创意和实践。
背景
由很多微服务组成的分布式系统中，永远难以全面掌握什么事件会导致系统局部不可用，甚至全面崩溃。主要因素：
1）系统架构演进：服务集群→分布式→微服务→容器化（K8S&docker）→上云；
2）版本迭代增速：CICD、敏捷、devops、ABtest；
3）用户需求变更：复杂化、多样化、快速化、小众化；
对系统的要求：扩展性、稳定性、弹性能力、容错灾备能力；
软件系统现状：系统复杂性提高、问题定位成本高；
要解决的问题：生产环境下的分布式系统在面对失控条件时依然具备较强的“可观测性”和故障恢复能力；
主要验证方式：故障注入；
开展“混沌工程”的意义
开发者的能力和认知水平有边界，不可能所有的细节都可以预估到，系统很脆弱，各种潜在不可预期的突发事件在所难免。
我们需要在异常触发之前，尽可能地去筛选出会导致出现有异常问题的、容易造成故障的、系统中明显裂痕的环节，这也是混沌工程所肩负的意义。
能让复杂系统中根深蒂固的混乱和不稳定性浮出水面，让我们更全面了解系统中固有的现象，然后进行及时修复、加固和防患于未然，才能打造更具弹性的软件工程系统。
思考
1、设计良好的系统，需要考虑哪些因素？
可靠性、安全性、可扩展性、可定制化、可伸缩性、可维护性、用户体验等。
2、混沌工程解决什么问题？
生产环境下，分布式系统在面对失控条件时是否具备较强的“可观测性”和故障恢复能力。
3、开展混沌工程要考虑的维度有哪些？
1）建立稳定状态的假设（清晰可衡量的指标）
2）用多样的生产事件做验证（多样性降低误差）
3）在生产环境做验证（真实场景）
4）自动化开展实验（持续运行）
5）控制最小化爆炸半径（影响范围）
4、Netflix开展混沌工程总结的三点经验
1）建立面向失败设计和拥抱失败的技术文化（技术文化）
思想上，引入混沌工程的核心是通过引入一些风险去暴露已有的不易发现的问题，而不是创造问题。这样有助于问题的发现和处理，降低潜在故障带来的影响。
2）定义一个清晰可度量的目标（定义目标）
前期：对历史故障的复现率以及解决率，确保故障改进的有效性；
中期：监控发现率，验证故障发现能力的全面性和监控的完备程度；
后期：故障的“发现-定位-恢复”市场这种综合性指标；
3）在控制风险的前提下不断提升混沌工程效率（技术推广）
先从简单的场景开始尝试，逐渐增加组织对系统的信心（要明白准备工作比落地执行更重要）。
混沌工程是一种实践思想，方法论，本身不绑定任何工具或者技术。不过在进行推广和实施时，考虑到真实性、容错性、开发成本、运维效率等因素，建议复用成熟的开源组件或者商业化工具。