混沌工程实践笔记
混沌工程简介
概念
混沌工程起始于2008年，现在混沌工程的概念与之前有了很大的区别， 经过多年的沉淀和总结，混沌工程越来越趋向如下定义，混沌工程是软件工程的一部分，旨在通过工程化的手段， 帮助软件开发获得更好的质量和稳定性，通过有计划科学的实验计划，提前对生产环境可能出现的各种问题和情况进行预演，通过对实验结果进行分析和总结，得出对软件质量和软件架构非常有帮助的结论。通过不断的迭代，使得软件质量和稳定性得到更好的保障。
混沌工程发展历史
混沌工程诞生的契机
企业服务队稳定性的迫切需求
规模的增长和系统的复杂性
快速迭代与稳定性的冲突
稳定性测试遇到的难题
排障追踪的困境
混沌工程的原则
image
image
建立一个围绕稳定状态行为的假说
要关注系统的可测量输出, 而不是系统的属性。对这些输出在短时间内的度量构成了系统稳定状态的一个代理。 整个系统的吞吐量、错误率、延迟百分点等都可能是表示稳态行为的指标。 通过在实验中的系统性行为模式上的关注, 混沌工程验证了系统是否正常工作, 而不是试图验证它是如何工作的。
通俗的来讲就是你的服务在什么的状态下（用什么样的数据说明）是正常服务的，稳定的。
这也是将来我们进行混沌试验验证的一个非常重要的参考。
多样化真实世界的事件
混沌变量反映了现实世界中的事件。 我们可以通过潜在影响或估计频率排定这些事件的优先级。考虑与硬件故障类似的事件, 如服务器宕机、软件故障 (如错误响应) 和非故障事件 (如流量激增或伸缩事件)。 任何能够破坏稳态的事件都是混沌实验中的一个潜在变量。
在生产环境中运行实验
系统的行为会依据环境和流量模式都会有所不同。 由于资源使用率变化的随时可能发生, 因此通过采集实际流量是捕获请求路径的唯一可靠方法。 为了保证系统执行方式的真实性与当前部署系统的相关性, 混沌工程强烈推荐直接采用生产环境流量进行实验。
持续自动化运行实验
手动运行实验是劳动密集型的, 最终是不可持续的。所以我们要把实验自动化并持续运行，混沌工程要在系统中构建自动化的编排和分析。 一般公司会构建自己公司专用的混沌平台， 用以解决混沌工程中处处的人工操作，解决效率低下的问题。 最终平台可以作为软件工程中必要的环节集成到公司的研发流程中去。
最小化爆炸半径
在生产中进行试验可能会造成不必要的客户投诉。虽然对一些短期负面影响必须有一个补偿, 但混沌工程师的责任和义务是确保这些后续影响最小化且被考虑到。
混沌工程是一个强大的实践, 它已经在世界上一些规模最大的业务系统上改变了软件是如何设计和工程化的。 相较于其他方法解决了速度和灵活性, 混沌工程专门处理这些分布式系统中的系统不确定性。 混沌工程的原则为我们大规模的创新和给予客户他们应得的高质量的体验提供了信心。
混沌工程实践流程
业界关于混沌工程的标准实践流程没有一个明确标准的定义。但大部分实践过混沌工程的大致流程都一致, 下图是IBM的实践流程：
总结来说，主要分为如下几个步骤:
1. 对将要进行混沌工程的软件项目进行一个彻底的了解，获得组织上的认可
对于将被实验覆盖的软件系统，我们需要有个端对端的了解，我们要知道这个软件系统的架构，软件的运行环境，软件服务的客户等等。 在了解这些基本信息之后， 我们要对此软件系统做故障注入还需要做组织上的认可和准备。
2. 创建对此软件项目专门针对性的实验假设, 实验过程可观测
通过第一步的积累， 我们需要建立一些可观测的指标，系统的运行稳健与否，需要有相关的指标数据， 通常来说，这些指标数据是由监控系统所承载的。 我们会尝试对此软件系统进行一定的假设， 比如，但个节点崩溃预期服务正常提供， 数据库崩溃服务仍然可用。 有
3. 定制设计实验
依赖假设及系统稳定态观测的方法之后， 我们可以针对性的进行实验设计。 针对不同场景，我们可以设定不同的实验内容， 整个试验可以是多种场景混合作用的一个结果， 因此，我们在设计实验的时候，可以根据既有假设，去指定对应的实验计划，证明这个假设是不成立的。 这个过程中可能需要我们的混沌平台具备场景编排的功能，以真实制造可能会出现的事件。
4. 执行实验
当实验设计完毕之后， 我们可以手动的或者在平台上自动执行编排好的混沌实验， 执行过程中，把相关的实验数据与试验结果进行详细记录。初期执行的时候通常需要相关人员在场， 后期软件系统成熟之后，也可以做一些突袭实验， 用来验证维护人员发现问题以及解决问题的能力。
5. 分析实验结果
对于每一次的实验数据，都是我们宝贵的财富， 我们结合软件系统和架构，对实验数据进行详细的分析， 总结得出实验结果得出的结论，验证之前的假设是否成立， 我们需要把这些结论文档化，并且把这些结论中需要改进的点，记录到今后的优化改进任务中去。
6. 交流改进点，并且进行改进
对于每次实验结果，我们都能得出一些结论， 我们需要对这些结论进行相应的分析和执行。
对于需要架构调整以及代码问题修复的地方，我们要及时安排任务去修复掉， 这样才能保证软件在将来遇到同样的场景，不会出现相应的问题。对于不能修复解决的，我们也要有一个可以迅速执行落地的应急预案， 这样，当这样的情况发生时， 我们可以迅速采取行动，最大可能的降低对软件服务的影响。
7. 扩大实验范围，继续进行实验迭代
经过软件的优化和修复之后， 我们会把原来的范围进行扩大，这里的范围含义比较广， 比如机器集群范围的扩大， 再比如服务依赖范围的扩大等等， 为了尽可能的验证极端情况下，我们能够正确应对突发问题的效率和可靠性， 我们需要扩大实验范围，继续迭代这个实验流程。
混沌工程的收益
未雨绸缪， 在问题发生前，提前解决可能出现的问题
提升软件质量，保障软件服务可用性
提升迭代效率， 一定程度上降低团队为稳定性所花费的额外时间。
沉淀和总结经验，为将来软件系统的设计和实施提供有益的参考
