基于chaosblade的故障注入平台实践

1. 背景

当今社会互联网应用越来越广泛，用户量日益剧增。在人们对互联网服务的依赖性增大的同时，也对服务的可用性和体验感有了更高的要求。那么如何保障服务在运营过程中能一直给用户提供稳定的、不间断的、可靠可信的服务呢？

例如一个金融产品，如果出现过一次问题， 那可能带来巨 大的损失 。大家都知道金融产品的系统架构和服务逻辑是相当复杂的，至此大家都会第一时间联想到测试工程师，他们会通过单元测试、集成测试、性能测试等来验证服务的稳定性。但尽管如此，也是远远不够的，因为错误可以在任何时间以任何形式发生，尤其是对分布式系统。所以这里就需要引入混沌工程（Chaos Engineering）。

二 混沌工程介绍

混沌工程是一套通过在系统基础设施上进行实验，主动找出系统中的脆弱环节的方法学，最早由Netflix及相关团队提出。 它旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。 通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。 2012年，Netflix开源了Chaos Monkey。 今天，许多公司(包括谷歌，亚马逊，IBM，耐克等）都采用某种形式的混沌工程来提高现代架构的可靠性。

混沌工程和故障测试的区别

相同点：

• 都是基于故障注入来引入的。 

不同点：

• 混沌工程是一种生成新信息的实践，而故障测试是测试一种情况的一种特定方法。

• 故障测试会在具体的场景实施注入实验和验证预期，而混沌工程实验是围绕一个“稳态状态”通过更多场景来验证。

• 混沌工程建议是在生产环境中进行实验。

混沌工程非常适合揭露生产系统中未知的弱点，但如果确定混沌工程实验会导致系统出现严重问题，那么运行该实验就没有任何意义。

目前国内有相关使用的公司内的实践偏向于故障测试，即在一个具体场景下实施故障注入实验并验证预期是否得到满足。这种测试的风险相对可控，坏处是并没有通过故障注入实验探索更多的场景，暴露更多的潜在问题，测试结果比较依赖实施人的经验。当然这也是我们认为在混沌工程目标之路上必经的一个阶段。

故障测试预期、验证与混沌工程定义的稳态状态行为是存在差异的，差异的根本原因还是组织形态的不同。2014年，Netflix团队创建了一种新的角色，叫作混沌工程师（Chaos Enigneer），并开始向工程社区推广。而国内大部分企业目前并没有一个专门的职位来实施混沌工程，项目目标、业务场景、人员结构、实施方式的不同导致了对于稳定状态行为的定义不太标准。当然我们目前也没有Chaos Enigneer。所以基于不同的定义标准、不同的组织型态和不同的阶段，我们在混沌工程实验的引入和使用也是更偏向故障测试。

三 混沌工程原则

以下原则描述了应用混 沌工程的理想方式，这些原则来实施实验过程。 对这些原则的匹配程度能够增强我们在大规模分布式系统的信心。

围绕稳态行为构建假设

专注于系统的可测量输出结果，而非系统的内部属性。 在短时间内测量输出结果并将此作为系统稳态的代表。 整体系统的数据吞吐量、错误率、延迟百分比等皆可作为稳态行为的关键性表示指标。 通过关注实验中各系统行为模式，混沌工程能够验证系统是否正常工作——而无需尝试解析其工作原理。

多样化真实世界的事件

混沌变量应直接反映 各类现实世界事件。 我们应该考虑各类或者相关联的故障，任何可能导致稳态中断的事件皆应被视为混沌实验当中的潜在变量。 由于多元化的业务和高 复杂 的系统架构，可能会遇到非常多种类型的故障，这里已经有人优先分析P1和P2故障，按照IaaS、PaaS、SaaS层的角度绘制了故障画像，如下图

在生产环境中运行实验

从功能性的故障测试角度来看，非生产环境去实施故障注入是可以满足预期的，所以最早的强弱依赖测试就是在日常环境中完成的。 不过，因为系统行为会根据环境和流量模式有所不同，为了保证系统执行方式的真实性与当前部署系统的相关性，推荐的实施方式还是在生产环境，但是目前很多企业还是没有做到生产环境实验。

持续自动化运行实验

使用故障注入平台化代替手动实验，自动构建编排和分析。

最小化爆炸半径

混沌工程建议在线上环境进行实验，但是导致系统异常甚至异常放大的可能性是存在的。从实施角度看，最好是通过技术手段来有效的减少异常带来的影响，例如通过系统稳态指标来有效停止注入、限流、流量切换、数据隔离等方式都是减少业务影响的手段。

四 故障注入平台的构建

平台目标

1. 提供多样化、可视化操作的故障注入自动化平台

2. 作为各种演练和故障测试及验证的统一入口

3. 积累沉淀多种实验方案，建立系统上线健壮性评估基线

功能目标

1. 帮助业务发现更多未知的影响业务稳定的问题

2. 验证业务的告警有效性和完整性

3. 验证业务的故障预案是否有效

平台构建

目前业内模拟故障的工具比较多样化，支持的功能和场景也各有优劣。通过对比来看，chaosblade支持功能和场景比较丰富，同时社区也是比较活跃的。我们在充分验证了大部分注入功能后，选择了它作为底层注入的核心模块。

chaosblade 所支持的场景，可以参考文档：

https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/

整个故障注入一共分为四个阶段：

平台构建的 思路还是以四个主流程为核心来开展。 分类来看平台模块如下图所示：

目前平台的注入场景我们支持了系统层和网络层类型，主要包含了网络延迟、丢包、cpu满载、内存满载、磁盘IO满载场景。 这些场景都是 热插拔式 集成到平台，方便平台场景灵活调整和扩展。

五 演练实践

实操演练我们挑选了1个相对较稳定的业务A（业务A是一个多节点的任务调度和目标抓取的服务），对业务A的测试环境进行了实验，同时业务方很期待如此稳定的系统是否存在或者有更多的缺陷。

整个过程概览如下：

1. 定义并测量系统的“稳定状态”，精确定义指标

2. 创建假设

3. 线上流量复制持续导入测试环境

4. 模拟现实世界中可能发生的事情

5. 证明或反驳假设

6. 总 结和反馈问题优化

稳态指标

业务方任务系统在运行时，以下指标可以代表系统的稳态。

• 集群服务整体CPS

• 任务提交响应延迟

• 任务提交成功率

• 任务解析失败率

• 目标获取成功率

• 数据一致性和完整性

创建假设

假设某些节点在存在性能或者网络相关问题的时候，可能存在任务提交响应延迟，不影响稳态。

假设存在节点宕机，不影响稳态（此处不做介绍）。

线上流量导入

流量复制和测试环境导入在这里不做介绍。

模拟故障

使用系统层+网络层随机注入场景模拟。

下表格为故障注入平台中故障场景的配置。

注入功能名称

说明

Cpu注入

负载达到90%

内存注入

内存消耗达到90%

网络丢包

丢包率30%

网络延迟

增加100ms

在平台选择我们提供的系统场景故障模板和注入目标（一个注入任务中，单个机器只能注入一种场景，场景和机器随机选择）

通过选择的注入模板和目标，生成一个注入计划，如下图：

执行注入，如下 图，在注入过程中，操作者是可用随时结束和暂停注入任务的。

人为暂停指定目标，点击继续会继续注入

跟踪和观察

在整体的观察中发现了以下几个问题：

• 服务cps陡降

• 提交成功的任务，失败率大幅提升

• 用户任务提交出现不同程度延迟

• 关联服务进程异常退出

• 监控不细粒，能发现cps和失败率增加，但定位困难

发现整个服务的cps有陡降，意味着服务的处理能力下降严重。

任务执行失败数量增加，意味着任务提交了，但是服务并没有按照预期来完成。

用户提交延迟和超时增加

结束整个注入任务

注入任务结束后，业务所有指标逐步恢复了正常。

证明或反驳假设

• 假设：某些节点在存在性能或者网络相关问题的时候，可能存在任务提交响应延迟，不影响稳态。

• 证明： 存在任务提交响应延迟，间接性意味cps的下降。

• 反驳： 发现非预期的 任务执行失败增加和关联进程异常退出的问题，监控缺失和不细粒等问题。

总结和反馈

添加本次注入总结和反馈：

六 其他问题

1、任何用户都能对任何机器做注入吗？

答：不可以。 

平台目前涉及到多个维度的权限：用户在职状态，平台用户权限，用户和机器权限，平台和机器权限。

2、当因为注入导致目标机器满载或者丢包严重，sre同学无法登陆机器，平台是如何能正常中止？

答：系统在对目标机器注入时会开白名单，例如丢包或者网络中断的场景会导致其他用户无法登陆，但是我们的任务机是不受影响的。系统性能满载的注入，我们会控制满载程度，不会让机器直接满载到无法工作的情况。后面也有个性化参数配置，用户在设置方位内可调整。

3、平台是否能自 动判断停止注入？ 如果不能，人工中止忘记了注入会一直持续吗？

答：目前还无法自动判断是否需要停止注入。如果人工中止操作忘记了，用户在选择注入模板或者自己配置注入计划的时候，会有一个持续注入时间，超过这个时间，注入任务自动结束。

七 未来规划

功能规划

逐 步完善本文中提到的按照IaaS、PaaS、SaaS层的角度绘制的故障画像中的故障场景。

结合SLO、降级和流量调度，缩小爆炸半径，为线上注入实验做准备。

能主动探测绘制流量和服务调用关系拓扑。