做混沌工程是什么样的体验？阿里：有点刺激

混沌未分天地乱，茫茫渺渺无人见。

因为对未知的好奇，盘古劈开了天地，身化做了天地。再后来，人类不满足于眼前的狭小世界，渴望天地之外，无人得见的另一番天地。

是以未知探寻未知，遍观未知，方知无知。

混沌工程，便因未知而生。

这一通过有意识地注入故障，从而发现系统的未知弱点的实验手段，现在还很年轻，在行业内的认知和实践累积也比较少，很多 IT 团队对它的理解还没有上升到一个领域的概念。但阿里很敢，率先付出了长久的关注与实践。

今天我就跟大家聊聊阿里的混沌工程。

其实，早在 2011 年，阿里电商就开始尝试通过故障注入技术去解决微服务的依赖问题，从注入实现、实验效率、业务影响等多个方面进行演进。2016 年开始，我们尝试在线上复现一些重大故障并验证措施是否有效。此时，阿里内部还称之为”故障演练”。

直到 2016 年去参加旧金山的 QCon 大会，我们发现很多人在讨论混沌工程，他们想要解决的问题与我们想要的不谋而合，于是，阿里开始关注这个技术领域。

越来越多的企业选择基于云原生技术构建系统架构，希望可以构建容错性好、易于管理和便于观察的松耦合系统。但我们需要意识到的是，在围绕新技术、新理念来升级系统架构和组织模式的同时，一定会遇到一些超出预期的不确定问题。

如何减小不确定性问题对系统稳态的影响，保持系统状态的一致性，是我们实施混沌工程的主要契机。

再说说我自己吧。

2011 年，我加入了阿里巴巴高可用架构团队，此后长期参与稳定性产品研发和集团架构演进工作，主导了强弱依赖、灰度环境、故障演练、智能对账等多款高可用产品的研发和建设，见证了阿里高可用产品体系从 1.0 到 3.0 的发展历程，积累了丰富的架构和稳定性经验。

2015 年，作为共享事业部的双 11 负责人，我负责大促和常态稳定性的保障工作。

一晃 8 年过去了，现在，我在阿里负责高可用技术的云化输出和技术演进工作，是阿里云产品 AHAS（应用高可用）的技术负责人。

如果你要问我，在推进混沌工程的过程中是否有一些比较刺激的经历，那我会说，还真有。

刚刚推进混沌工程的时候，我们优先选择的是在生产环境复现历史发生的故障，验证故障措施改进的有效性。之前的故障措施的验收往往是在线下环境验证或走一个流程。那次实验，我们选择了一个非常严重的故障做验收。虽然我们做了比较充分的评估，但是真正在生产环境实施的时候，还是比较紧张。

会是成功还是失败？答案是，成功。

最终故障注入后，相关系统完成了容灾切换，业务曲线几乎无影响。

成功是一针兴奋剂，增强了大家对系统稳定性的信心，我们都受到了鼓舞。

为什么阿里要选择混沌工程啊？

也许你会疑惑，既然现在已经有了故障注入和故障测试，比如单元测试和集成测试，那么，为什么阿里还要选择混沌工程？

我认为，它们虽有一定的重叠性，但混沌工程是发现新信息的实践。

单元测试和集成测试的核心目标是检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。

故障注入和故障测试的定义是通过引入故障，让程序走入一些不常经过的路径，是一种提高程序覆盖率的手段。

混沌工程虽然也使用短期的度量结果代表系统状态，但一般来讲度量结果都是一个监控的指标，而非具体的接口返回值。混沌工程是一个围绕稳态进行验证和探索的过程，每次实验可能都会产生新的数据。

如果把系统架构比作一个房子，实施混沌工程就类似对房子进行验房的过程。通过模拟有损和无损的的场景来观察房子质量，目标是暴露结构性风险，不会去关注每个细节。

看起来有点意思，对吧？

那你想不想知道，混沌工程是不是与你有关？

如果你是一名系统架构师、测试人员、SRE 人员，那你需要关注混沌工程。

那么，企业如何确定自己是否适合混沌工程？满足一下部分特征的企业，都适合实施混沌工程：

• 对于资损或 SLA 有极高要求的行业（金融、电商、医疗、游戏、公共等）

• 有较大的系统改造（比如：系统重构、微服务化、容器化、迁云）

• 业务发展快，稳定性积淀少

• 人员流动快，或 SRE 团队规模较小

对于使用混沌工程的团队，我建议：

• 要先从文化上让团队认可实施混沌工程的必要性和方法论。

• 重点关注实验方案的评估，明确定义系统稳态和终止条件。

• 尝试通过一些简单的场景开始尝试，增加大家对系统和过程的信心。

• 与其他团队进行合作，通过混沌工程配合其他稳定性手段，达成整体目标（如：监控发现率、故障改进覆盖率、系统自愈有效性等）。

下面我要说的很重要。

在使用混沌工程之前，我们需要准备三点：

1. 思想上要准备好。要意识到系统故障是可以通过周期性的引入一些实验变量来提前暴露和解决的。不论是否实施混沌工程，系统的隐患或 Bug 都客观存在。

2. 系统稳态和实验方案的仔细评估。对于实验方案进行推演，如果已经可以预想到一些问题，那么修正后再进行新的实验。

3. 提升系统的可观测性。对于系统稳态，要有配套的监控或观测工具，否则会影响混沌工程的实施效果。

你知道的，实践出真知。

作为第一批吃螃蟹的，我们也做了将近十年了，阿里在故障模拟、爆炸半径的控制、产品化方面出了一些成绩。业务方基本可以做到很低成本使用我们的产品，DevOps 同学基本已经可以实现自助演练。

从 2016 年到现在，看到大家对领域的认可度逐年变高，演练覆盖的应用规模和发现问题的数量已经翻了几倍，帮助业务方识别了很多潜在故障和改进点，很多高速发展的领域，比如新零售，也是通过实施混沌工程来快速的落地和改进稳定性，我还挺高兴的。

虽然混沌工程在行业内没有一个比较广的认知，但除去 Netflix 和阿里之外，国内外也有不少公司在做这个。

比如，国外有 Gremlin、ChaosIQ 这样专门实施 Resilience as a Service 的商业公司。像一些中、大型公司也都有实施混沌工程团队，比如 Linkedin、Uber、Google 等等。

国内的公司，据我所知，百度、华为、美团、京东、猫眼电影等，应该都有一些实施经验。

目前开源社区的工具主要关注在故障注入层面。商业化产品一般也是基于产品 + 专家服务的模式。

下面，我推荐一些好用的工具吧。

开源工具：

kube-monkey、PowerfulSeal、ChaosIQ，提供了一些容器层面的故障注入能力。详细可以看：https://github.com/dastergon/awesome-chaos-engineering

近期阿里会开源一款混沌工程测试工具 ChaosBlade，提供基础资源、应用服务、容器等多维度的故障模拟能力。

商业化工具：

Gremlin 提供一款商用的故障注入平台，部分功能免费，目前在公测中。

阿里云 - 应用高可用服务（AHAS）：AHAS 供了基于混沌工程原则的完整的实现，除了提供常见的故障注入能力，默认也打通了一些常见的云服务，提升系统的可观测性和自动化能力。目前免费公测中（支持非阿里云机器公网使用）。

随着企业云化，一定会有越来越多的公司开始关注和实施混沌工程。我希望可以有更多的公司分享思考和实践，并结合领域场景产出一些最佳的实践。

居安思危，思则有备，有备无患。这是《左传·襄公十一年》说的。

此前，有人认为，混沌工程是一种在故障发生之前发现故障的技术，但也是一种心态。

我觉得这句话还是有道理的。混沌工程是一种验证系统对非预期情况防御有效性的实验思想，任何依照”混沌工程原则”进行的探索，都是有效实践。

系统架构可能会很复杂，比如采用了微服务、Docker、K8s，甚至函数计算类似的技术，需要实验项目也涉及很多门类。为了更有效地实施混沌工程，就需要借助一些场景丰富、操作简便、模型标准的工具或技术了。

混沌工程技术会随着其他技术发展而演进，混沌工程会与融入到每个领域的最佳实践中。

今年开始，我开始在一些场合将自己称呼为” 混沌工程布道师”。

布道师，听起来好像有点“忽悠”。

不过，你知道皮埃罗·斯加鲁菲（PieroScaruffi）吗？这位全球人工智能及认知科学专家，被誉为永远站在时代前面的硅谷精神布道者，我很敬佩他。推动技术传播，推动技术落地，推动行业变革，这就是布道者的意义之所在。

在阿里内部，其实并没有设置一个专门的布道师的岗位。作为技术 Leader 或架构师，完成既定的业务目标是最核心，也是最本分的任务，除此之外，他们还活跃在外界，扮演着产品宣导者和技术推广人的角色。

让更多的人知道他们的团队在做什么，从而发现更多可能。

我希望，能通过这种手段给自己一定的责任和压力，持续性地去关注和推进领域的发展，让更多的人了解并加入这个领域。

愿为星星之火，这是我的选择。

周洋是 QCon 北京 2019“混沌工程”专题的出品人，同时也是专题演讲嘉宾，他将在大会上与大家就云原生架构下的混沌工程实践做分享。

2019 年 5 月 6-8 日，QCon 北京 2019 还将聚焦 Java 生态系统、高可用架构、运维最佳实践等经典方向，人工智能、机器学习、前端前沿技术等前沿领域，26+ 热门专题，近 200 名技术大咖全明星豪华阵容，QCon 十周年精心策划品质呈现。

点击  「 阅读原文 」或识别二维码了解详情，8 折购票优惠仅剩最后 2 天，欲购从速，别给自己后悔的机会！有任何问题欢迎联系票务小姐姐 Ring：电话 010-53935761，微信 qcon-0410

点个在看少个 bug