混沌工程在创业公司的实践

前言

混沌工程是在分布式系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。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平台架构图如下所示。

作为一个案列，下图展示了一次“应用暂停攻击”对应的监控指标变化。攻击实施后，监控看板能清晰展示数据截断。攻击发生后，我们可以进一步验证相关警报是否发出、上游业务表现是否正常、人员问题排查是否到位、相关预案是否完善等。

未来展望

混沌工程是一门实验学科，用于建立对系统抵御生产环境中失控条件的能力以及信心。从目前的落地方式上看，故障注入是其中最重要的一环，平台支持的故障注入场景的丰富性和粒度很大程度上影响实验结果。本文侧重于故障模拟部分的介绍，对应于混沌工程“多样化真实事件”原则。关于混沌工程其他原则的进一步思考，我们简单罗列如下：

• 建立一个围绕稳定状态行为的假说
  我们需要在故障攻击前，确定系统稳定工作状态的指标，用于判定故障发生后系统的工作情况。
• 在生产环境中运行试验
• 持续自动化运行试验
  场景设计完成后，需要有某种调度机制，自动化持续执行。
• 最小化爆破半径
  故障影响范围分析，确保在生成环境执行过程中，对用户影响最小。

综上，稳定工作指标的选取、系统工作状态的判定、调度机制以及故障影响范围分析是下一步实施考量方向。