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