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

1. 背景

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

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

二 混沌工程介绍

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

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

相同点：

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

不同点：

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

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

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

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

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

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

三 混沌工程原则

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