前言
混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。2016年，Netflix将在生产环境开展的对系统弹性测试的经验总结为《Principles Of Chaos》，揭示了混沌工程的实施原则：建立一个围绕稳定状态行为的假说、多样化真实世界的事件、在生产环境中运行实验、持续自动化运行实验、最小化爆破半径。
酷家乐技术架构演进与混沌工程的联系
2015年开始，酷家乐整体架构开始向微服务化迈进。从早期的单体应用，经过垂直/水平拆分，再由共享能力下沉抽象出业务中台。架构的剧烈演进带来了以下三个突出问题：
- 架构的大规模变更过程导致稳定性故障频发
- 架构的复杂化导致“流程优化（code review/上线等）及稳定性盘点” 等形式的保障方式无法满足稳定性保障需求
- 需要验证服务治理、监控警报、devops等基础设施在故障出现时能有效工作，协助团队快速消灭问题
具体来说，在架构和团队膨胀到一定阶段，要想完全消除线上故障已经成为不可能的任务。当故障发生时，微服务架构能否准确进行出错重试、限流、熔断、流量控制；报警响应是否及时，提供的监控信息是否支持迅速排障；devops研发平台是否能够允许应用迅速回滚，快速上线紧急修复，等等，都成为降低业务损失的重要一环。
因此，从故障驱动的角度出发，提前挖掘当前架构、链路、系统存在的隐患，验证基础设施的完备性，限制故障影响的范围，成为需要思考的方向。混沌工程有助于达到以上三个目的，将稳定性保障方式从“流程优化（code review/上线等）及稳定性盘点” 拓展到“故障的隔离/自修复/快速响应”。
酷家乐混沌工程的实施方式
首先，基于对当前的技术架构以及团队结构的认知，在具体实施过程中需要满足以下条件：
- 从创业公司的角度，方案的实施必须契合整体架构的长期演进方向，满足低成本、高收益、可复用三个要求。在技术方案的选择上，可以通过开源和自研相结合的方式，在降低成本的同时最大限度贴合自身的架构特点。
- 从当前的运维方式，处于虚拟机部署方式向容器化过渡过程中，需要支持虚拟机、docker、k8s三种攻击模式。
- 从安全角度，线上故障注入为高危动作，需要有严格的权限控制流程。在实施前期，允许团队在线下及预发环境中验证故障注入方案的合理性。
其次，为了更真实模拟线上故障，我们对历史故障数据进行了大量分析，将相关故障场景抽象为五大类：应用类、存储类、基础设施类、中间件、业务特性。抽象的故障场景即为需要实现的故障注入能力。
再次，综合实施条件和实施能力目标，对开源方案进行筛选。目前，开源方案可以分为三类：一类，从chaosMonkey衍生、以容器化部署应用作为攻击目标，采用go语言作为技术栈，如pumba、kube-monkey，chaosblade；另一类，基于python强大运维优势的开源方案，可以较快的实现运维层面的攻击，如chaostoolkit；最后一类为侵入代码层进行攻击，如byte-monkey，在字节码层面给jvm应用注入相应故障。
经过比对，Pumba通过调用DockerAPI的方式来实现container级别的相关攻击，包含随机kill、stop、remove、pause、网络状况模拟等，是在docker部署方式下攻击方式比较丰富的一种方案。此外，阿里巴巴近期开源Chaosblade，功能强大，除了基础的CPU、disk、I/O、network外，还支持docker、dubbo、jvm的攻击，同时支持攻击后迅速回滚，是在k8s部署方式下最优方案。
开源方案极大的方便了工程的实施，但并不能解决全部的问题，如：Chaosblade对于非dubbo架构（Spring Cloud体系等）缺乏有效支持。因此，需要基于酷家乐自身的架构特性，对相关场景进行补充。在架构层面上，更好支持Spring Cloud体系；在业务层面上，通过服务治理平台提供限流、熔断、mock等功能实现业务接口层面的故障注入。
最后，为了提升故障注入工具的易用性，同时实现权限管控、大规模攻击、指令下发、历史记录、方案预演等必需功能，我们设计并实现了酷家乐混沌工程平台-Ares。Ares借助于saltstack实现攻击指令下发，以应用为维度实现权限管控，并将最小攻击目标限定在单个应用上。Ares平台架构图如下所示。
作为一个案列，下图展示了一次“应用暂停攻击”对应的监控指标变化。攻击实施后，监控看板能清晰展示数据截断。攻击发生后，我们可以进一步验证相关警报是否发出、上游业务表现是否正常、人员问题排查是否到位、相关预案是否完善等。
未来展望
混沌工程是一门实验学科，用于建立对系统抵御生产环境中失控条件的能力以及信心。从目前的落地方式上看，故障注入是其中最重要的一环，平台支持的故障注入场景的丰富性和粒度很大程度上影响实验结果。本文侧重于故障模拟部分的介绍，对应于混沌工程“多样化真实事件”原则。关于混沌工程其他原则的进一步思考，我们简单罗列如下：
- 建立一个围绕稳定状态行为的假说
我们需要在故障攻击前，确定系统稳定工作状态的指标，用于判定故障发生后系统的工作情况。 - 在生产环境中运行试验
- 持续自动化运行试验
场景设计完成后，需要有某种调度机制，自动化持续执行。 - 最小化爆破半径
故障影响范围分析，确保在生成环境执行过程中，对用户影响最小。
综上，稳定工作指标的选取、系统工作状态的判定、调度机制以及故障影响范围分析是下一步实施考量方向。
关注我们
酷家乐质量效能团队热衷于技术的成长和分享，几乎每个月都会举办技术分享活动（海星日），每半年举办一次技术专题竞赛分享（火星日），并将优秀内容写成技术文章。
我们尽可能保障分享到社区的内容，是我们用心编写、精心挑选的优质文章。如果您想更全面地阅读我们的文章，请您关注我们的微信公众号"酷家乐技术质量"。
