3.4 混沌工程和故障演练
混沌工程是近年来新出现的概念，主要用于稳定性方面的研究，英文全称为chaos engineering，由网飞公司最先提出。因为最开始混沌工程称作chaos monkey，形容就像有一只猴子在系统中捣乱一样，以至于到现在每次提到混沌工程都会用一只捣乱的猴子来比喻。但是稳定性测试不是网飞独创的，在混沌工程之前，就已经有很多关于稳定性的研究了。随着测试系统的业务逻辑越来越复杂，交付团队也在不断地通过细化测试、增加发布环节及各种流程管控保障系统的稳定性，但是仍然会出现各式各样的故障。混沌工程就是本着提早暴露系统脆弱环节的理念，以提高系统的稳定性为目的而出现的。
3.4.1 从故障制造到混沌工程
系统稳定性是当前任何系统都会面临的首要任务，一个不稳定的系统没有任何一个用户愿意使用。这里说到系统稳定性，就不得不提一下SLA（Service Level Agreement，服务等级协定）。在SLA中常用几个9来衡量提供服务的稳定性，9越多就代表团队提供的服务稳定性越高，故障时间越短。
下面举例说明。如果某团队提供的服务满足4个9，那么一年发生故障的时间可以通过以下方式计算。
365天×24小时/天×0.0001 = 0.876小时=52.56分钟
当前很多公司的服务要求满足5个9的要求，这时故障时间的计算方式如下。
365天×24小时/天×0.00001=0.0876小时=5.256分钟
如此苛刻的条件促使团队不断寻求提高系统稳定性的方法，以满足系统稳定性的要求。
为了保证系统的稳定性，测试工程师可谓殚精竭虑，除常规的测试以外，还会通过在测试过程中人为设置一些故障，验证系统的一些可靠性保障机制是否有效。
虽然当时的测试方法没有现在这么自动化、智能化，但是同样会进行故障模拟测试，例如，要验证测试A服务的多活部署是否有效，测试工程师会进入机房，把一台服务器的网线拔掉，验证服务是否可以继续对外提供服务。
如果需要模拟CPU高负载情况下系统服务的响应，就要登录服务器并编写C语言中的死循环，从而让CPU满载。为了产生大量的磁盘I/O，就要通过dd命令完成虚拟文件系统的镜像文件创建等破坏性的操作，但是这些操作在现在来看还不能算真正的稳定性测试，只能算故障后服务验证。为什么这么说呢？
因为当用死循环占用服务器的CPU资源时，测试工程师已经知道问题就是CPU资源被占用，也就是说，测试工程师使用特定的方法验证了系统在可能发生类似故障时的反应。
而混沌工程通过多元化的业务场景建立基于场景的故障，这是一种提高技术架构弹性能力的技术手段，终极目标就是在用户感知到之前将所有故障都消灭。通过主动制造故障，收集系统在各种压力下的行为，识别并修复故障问题，降低技术风险，避免造成严重后果。混沌工程是在分布式系统上进行实验的学科，目的是提高系统抵御生产环境中失控条件的能力。
下面是几个关于混沌工程的输入示例。
模拟云服务机房故障无法访问。
模拟某地数据中心故障无法访问。
生产Redis数据丢失。
某类服务响应超时。
强制系统节点间的时间不同步。
在驱动程序中执行模拟I/O错误的程序。
让某个Elasticsearch集群中CPU超负荷。
混沌工程是一门学科，提供了基本的理论指导。而故障演练是混沌工程的具体实践，通过向目标系统注入真实可能发生的故障来考量系统的稳定性。
3.4.2 故障演练的实施要点
混沌工程为稳定性验证实验提供了可实践的指导。如果要将混沌工程落地实践，首先要有一个快速、方便的故障注入工具，然后结合混沌工程的理论进行故障演练，从而提高系统的稳定性。
1．选好混沌工程的工具
“工欲善其事，必先利其器”，选取一个好的混沌工程工具可以让测试工程师事半功倍。用于混沌工程的开源工具有很多，站在团队的角度，要选取平台化工具，作为故障演练的统一入口，需要提供方便、易用的交互方式，以自动完成故障注入。提供多样化、可视化的故障注入自动化平台，作为各种演练和故障测试及验证的统一入口。
故障注入平台能够帮助业务人员发现更多影响业务稳定性的未知问题，验证警告的有效性和完整性，以及业务的故障预案是否有效。这里推荐使用阿里巴巴的开源平台ChaosBlade。ChaosBlade内置的场景非常多，不仅能模拟CPU满载、磁盘I/O过高等简单故障，还能模拟Dubbo调用超时、关闭容器、关闭pod等，从而方便制造更多的实验场景。ChaosBlade不仅方便、易用，还支持自行扩展场景。
2．建立稳定性指标
既然故障演练是混沌工程的实践，那么所有的演练都要站在混沌工程“建立一个围绕稳定状态行为的假说”的基础之上开始设计。因此，要在开始设计前先定义好故障演练过程中需要监控的指标，这些指标可以正确地反映系统的健康情况，并在出现问题时直接通过指标表现出来，同时明确对应的指标可能造成的结果，帮助触发监控预警，以便快速解决问题。
3．定好故障类型
故障演练中触发的故障并非随意选取的，而是通过总结系统历史上出现的问题，以及类似系统出现过的问题得出的。比较常用的故障有外部依赖超时访问，Kafka超时，Kafka不可用，数据可不可用，CPU满载，网络中断，服务器宕机，磁盘没空间等。
4．流程准备
除上述相关准备以外，在开始故障演练前，还要检查流程准备工作是否已经做好。例如，故障决策链是否清晰明确？各种故障是否都有明确的排查和解决方案？每种方案是否都切实可行？
5．开始演练
开始演练前，通知所有干系人，包括相关业务的开发工程师、业务工程师及基础设施工程师。通知内容包含参与故障演练的服务、故障演练的开始时间、故障演练的结束时间、故障演练对应服务所在的集群环境。同时，建立统一协调的工作组即时聊天群。通过故障注入工具将问题注入系统，观察故障排查和解决的全过程。重点记录的信息如下：
故障是否按照预期修复或者降低影响；
业务指标的变化；
稳定性指标的变化；
如果要降级处理，对应降级方案是否生效。
在故障演练过程中，如果超出控制或者原定计划的故障影响范围，要立即终止故障演练，快速恢复系统，同时清理全部故障演练对系统的影响和痕迹。因为故障演练是在真实环境中进行的，除被测业务之外，很多真实用户也在使用该系统，不能为了完成故障演练而引起真实故障。
6．结束总结
故障演练重点中的重点是恢复故障演练环节，故障演练都是在真实环境中完成的，因此一定要记住恢复全部环境，关闭故障注入工具，恢复降级处理的服务，以保证服务可以恢复到故障演练之前的正常状态。然后再对整个过程做总结，并针对发现的问题制订整改计划。
混沌工程并非混沌初开的意思，而是指将系统搅乱，通过制造问题提高系统的稳定性。混沌工程方兴未艾，但已在很多大型互联网公司落地实践了。很多大型互联网公司开源了自己的混沌工程工具，也公开了自己的故障演练方案，但是故障演练是一项需要详细计划并且由包含测试工程师、开发工程师、运维工程师等角色的推进小组完成的工作，某一个角色“单打独斗”是无法完成的。
3.5 小结
持续测试不仅包含功能测试，还包含非功能测试。这里非功能测试重点保障了可靠性、可用性、可移植性、性能效率等质量特性。绝大部分测试技术是针对制品交付过程的，如全链路压测、混沌工程等覆盖了测试右移中很多很好的实践。这些都是不断促进质量改进、提高质量效能的有效办法。
