阿里混沌工程平台实践
作者:阿里巴巴|银桑
背景
混沌工程是近几年比较火的一个概念,通过主动制造故障,测试系统在各种压力下的行为,识别并修复故障问题,避免造成严重的后果。包括业内的大公司的 netflix,facebook,amazon 等还是集团内部很多的团队都在做混沌工程相关的一些工作,但是目前还没有一个很好的实践心得来说明混沌工程到底该如何来实施,monkeyking 平台一直在做故障演练的工作,并且也引入了混沌工程,在这里说一下实践心得,同时希望通过开放和开源的态度来吸引用户参与到其中,形成混沌工程文化,来更好的保障系统和业务的稳定性。
混沌工程是什么
简单的说混沌工程就是像演习一样,通过有目的的搞破坏,找出系统可能存在的弱点,从而验证在真实复杂的环境下,系统,人员应对各种突发问题的能力是否符合预期,提升系统的免疫能力.这里不详细的介绍混沌工程, 主要是想讲述一下基于混沌工程的理念该怎么来实施以及 monkeyking 是如何落地的。
混沌工程的前提
单纯的故障注入(现在 mk 的功能)只是混沌工程的一小部分,如果要实施混沌工程的话,你还需要判断一下到底自己的系统是不是适合做混沌过程,否则盲目的执行故障注入并不会带来什么实质性的效果,甚至可能会引发未知的问题,影响到真实的业务,一张图很生动的展示了做混沌工程前需要做哪些思考.
如果系统存在已知的 bug 未修复,那么是不适合做混沌工程的,这也是混沌工程和系统测试的一个区别,混沌工程考验的是你系统应对真实依赖环境发生问题时候的反应,而不是由于自身代码 bug 所导致的问题,因此在做混沌工程前,请务必保证自己的应用是经过严格的测试,并且问题都已修复。
我只是来执行这次演练,我不是很清楚这个演练到底会影响系统的哪些方面或者业务。
如果无法回答这两个问题,那么可能就不适合做演练,因为混沌工程的实施不是盲目的,不是试探性的,混沌工程是有目的性的,是可控的!
混沌工程的步骤
基于混沌工程的基本原则,我们将混沌工程的实施步骤分成以下几个,如图:
1. 稳态假设
稳态假设是混沌工程里面的一个基本概念,就是你需要清楚的知道系统的健康状态并且在实施混沌过程当中,可能出现的情况以及如何应对.要做好稳态假设,以下几步是必不可少的。
监控指标
定义一个系统的稳态,监控是非常重要的,在什么指标下系统是正常的,如果实施了混沌工程哪些指标是会有变化的,以及指标在什么样的浮动是符合预期的.在做混沌工程前你无法保证系统处于一个稳定可监控的状态,那么演练是毫无意义的,这个也是我们在答疑时候经常遇到的问题,很多同学在系统没稳定的情况下进行演练,结果发生了各种问题。
预警通知
因为混沌工程都是真实的环境中演练,所以你有必要配置好演练的通知人员,执行的业务范围,可能会影响的业务方等,我们希望演练通知到的人员是越多越好的,这样更能起到协同的作用.
混沌工程的人员应该熟悉自己的系统
在我们很多的系统测试中,会邀请一些完全不懂系统底层的人员来进行测试,这样能发现一些问题,但是混沌工程不一样,无论是开发还是测试,都应该对系统非常的熟悉了解,知道该怎么来处理突发的状况。
2. 真实事件模拟
故障注入的模型选择很大程度上决定了一次演练是否是有意义,故障注入的场景可以是多种多样,但是对故障注入有几个基本的要求。
就是必须是真实发生的事件,真实发生可以从两个方面去理解:1.故障注入的情况必须是系统真实可能碰到的事件,比如像网络,CPU 等,如果你一个系统不依赖 database,那么去演练 database 是毫无意义的 2.故障注入是真实的,不是 mock 出来,像网络,CPU 这种,就是真的去 burn cpu,delay network,而不是通过某一层的 mock 来做。
故障演练的环境必须是生产环境或者等同于生产环境,如果在测试环境中演练,那样几乎没什么意义,我们在答疑中也经常会遇到这样的问题,要是我在生产环境当中,万一真的造成问题了怎么办?如果在演练场景的时候,有这样的问题,说明你的稳态假设没有做好,系统还不可以进行故障演练,虽然故障演练是注入了故障,但是最终目的不是为了去引发线上的问题,而是为了验证就算发生了故障,你的系统也可以很好的应对,如果真的造成了问题,说明你的系统还存在缺陷需要完善,另外控制好最小化爆炸半径也是非常重要的。
3. 影响检测
影响检测在混沌工程里面被称作控制好最小化爆炸半径,意思就是混沌工程的影响范围必须得到控制,是细粒度的,逐渐扩大。谁都不希望因为一次演练导致了系统大半个瘫痪,因此在演练当中我们需要时刻关注在稳态假设中配置好的系统指标,如果影响范围超出了预期,立刻终止演练,并且修复问题,如果影响范围没有达到预期,也需要考虑下是不是场景选择合理,演练的范围太小,或者其他的问题。
4. 演练的恢复
当演练结束之后,应该需要及时的恢复演练,并且观察相应的系统监控指标是否符合预期。
混沌工程的落地
monkeyking 这边主要从三个方面来落地混沌工程。
1. 平台建设
通过对混沌工程加上前期用户对老平台 mk 的宝贵建议,我们重新打磨了一下 monkeyking 平台,同时也提供了云上的故障注入平台 ahas-chaos,在设计新版的 monkeyking 时候,我们遵循了以下的几个规则
演练的流程是可以编排的,核心步骤是和混沌工程的理念相契合的,可编排的流程一方面让用户灵活定义自己的演练计划,另一方面平台通过对每个步骤的严格管控,也能够保证演练的安全和稳定性.
演练除了要支持按步操作外,还必须是可以自动化运行的,因为故障演练应该是一个常态化的工作,所以也是需要能够做持续集成的。
平台必须是开放的,1.虽然 mk 提供了很多的故障能力,但还是无法满足需求,因此我们提供小程序来扩展平台的基础能力,在演练的各个流程当中都可以定制自己的小程序,不仅限于执行阶段 2.很多业务方都有自己的演练平台需要,因此 mk 也需要提供 api 来供业务方搭建自己的演练平台.
基于以上几点,流程可以分为四个步骤.
下面详细的介绍一下四个步骤是怎么来做的.
准备阶段
准备阶段就对应了混沌工程的一些稳态假设,可以在这里做一些故障演练前的准备工作,比如环境,流量的准备,监控指标的一些配置等,保证在故障注入前系统是达到了指定的要求.
执行阶段
故障注入的的要求就是场景尽可能全,影响范围尽可能可控,对于底层的故障注入我们进行了重新的抽象和设计,所有的故障场景都是可配置化的,对于故障场景的参数以及故障注入的目标都会做好严格的控制,包括权限控制等,一方面避免用户参数输入错误导致演练失败,另一方面防止故障演练的范围,比如机器范围过大等,下图是 monkeyking 的小程序配置界面,小程序的参数,支持阶段,依赖操作都是可以配置完成的。
检查阶段
当故障注入之后,会进入检查阶段,用户可以配置需要检查的系统项以及其他指标等,如果不符合预期,那么就会终止演练,并且自动执行恢复操作。
恢复阶段
执行故障注入的恢复,默认情况下故障恢复不需要用户自己选择,当用户选择了故障注入的场景以后,我们会自动生成对应的故障恢复的节点,同时优化了恢复的体验,之前如果是 java 类的故障注入,当挂载了 agent 之后,需要用户重启应用来恢复,现在演练结束之后,将会自动卸载 agent.
2. 开放开源
开放和开源从两方面考虑:
开放是 monkeyking 希望做一个底层的平台,只是定义混沌工程的基本流程和提供故障注入的能力,业务方在上层灵活编排自己的演练计划,定制自己的演练平台,并且将有价值的心得和产出沉淀到 monkeyking 平台上,实现业务和平台的双赢.
开源是通过抽象出一个混沌工程的底层注入模型,使得故障注入变得更加便捷,安全,同时借助开源社区的力量,丰富底层的故障注入能力,应用到平台上面.
开放
monkeyking 的开放主要在两个点:
对外提供了 openApi,方便业务方根据自己的需要基于 mk 搭建自己的演练平台,同时为了避免搭建平台而搭建平台,没有很好的实践混沌工程,对于流程编排,故障注入,故障恢复这些都做了一些基本的限定,像盒马就基于 mk 的 api 搭建了自己的故障演练平台,并且在线下门店成功使用起来.
monkeyking 提供了一些故障注入场景,但是这些也不一定满足需求,因此我们提供了小程序的扩展机制,用户可以将手动的操作转换成自动的能力,并且不限于流程环节,可以是准备,也可以是故障注入等,这样也会自动化的演练提供了可能.
开源
混沌工程的思想就是如果你觉得系统某个点有问题,那么就去破坏验证它,但是如果缺乏对应的故障注入能力就不行了,因此基于 monkeyking 这么多年的能力沉淀加上混沌工程的实验原理,我们抽象出了一款混沌工程工具:ChaosBlade
ChaosBlade 是一款遵循混沌工程实验原理,提供丰富故障场景实现,帮助分布式系统提升容错性和可恢复性的混沌工程工具,可实现底层故障的注入,特点是操作简洁、无侵入、扩展性强,它为 mk 提供了底层的故障注入能力,两者的关系可以用下图来描述:
3. 文化传播
要实施好混沌工程,有一个好的工具平台只是必要条件之一,文化的传播也是必不可少,我们会定期的推出一些混沌工程的分享和活动,同时也希望联合集团混沌工程团队们(可能很多团队已经在做混沌工程的一些东西了,比如故障演练等)来一起推广和建设混沌工程,因为通过混沌工程我们可以:
可以更好的理解系统对于复杂环境的应对能力,增强信心.
实施一次演练往往会涉及到多个团队的合作,通过常态化的演练,也可以增强各个团队之间的协同合作.
总结
混沌工程的好处如此之多,希望有越来越多的人可以参与到其中的建设当中,让我们的系统变得更加的稳定,让我们的人员可以更好的应对突发情况,更好的保障业务,借用一句话:
我热爱与家人和朋友在一起的生活。我不想花费无数个夜晚和周末来修复严重故障,混沌工程让我们对我们的系统能够更好地应对生产环境中的恶劣条件充满了信心。
版权声明: 本文为 InfoQ 作者【心远】的原创文章。
原文链接:【http://xie.infoq.cn/article/7a949e5e6a02734cce1830c5c】。未经作者许可,禁止转载。
评论