阿里竟然雇佣了一只大猴子...

我们“雇佣”了一只大猴子，只为“搞破坏”，不开玩笑。

一、这只猴子是用来做什么的？

从程序员的视角来看，提高系统稳定性的方法无外乎三种：

• 通过各种技术手段，例如在容器和调度、微服务、消息、软负载和配置中心等纬度提高系统和架构的健壮性；

• 提升监控的广度和深度，生产中一旦出现问题，能快速定位，给出解决方案；

• 生产就是大考，谁也不知道升学考中会出现什么样的试题，建立故障演练机制，把各类可以预见的故障提前演练出来，例如随机杀节点、延时响应，甚至中断机房；

这只猴子就是我们雇来做破坏，进行故障演练的队友。（疯起来，我们连自己都打）

二、这只猴子最早来源于哪？

Netflix的流媒体服务最初由Netflix工程师在Microsoft软件之上构建的，并位于垂直扩展的服务器机架中。然而，这一单一故障点在2008年8月受到攻击，当时一个主要的数据库损坏导致了三天的停机时间，在此期间DVD无法发送给客户。

在此之后，Netflix工程师开始将整个Netflix堆栈从单片架构迁移到分布式云架构中。

但是，这种向数百个微服务的分布式架构的重大转变带来了大量额外的复杂性。分布式系统中的这种复杂性和相互关联性创造了一些难以处理的东西，并且需要一种新的方法来防止看似随机的中断。Netflix向水平扩展软件堆栈的转变需要更可靠和容错的系统。

最重要的经验教训之一是 “避免失败的最佳方法是不断失败。”

2010年，Netflix Eng Tools团队开发出了Chaos Monkey，用来测试系统。Netflix的这个猴子军团可以在随机杀死实例，或是让某台机器的请求或返回变慢，还有就是搞挂一个机房，宏观验证业务容灾和恢复的能力。

三、阿里的这只猴子是什么来头？

1、2011年
阿里巴巴开始做强弱依赖的治理和建设，希望提前发现因为依赖问题导致的系统故障，系统的代号是EOS（出处是古希腊神话中的黎明女神，语意是能够把纷乱的依赖关系梳理清楚）

2、2012年
完成交易的同城双活后，我们就启动了同城容灾演练，也叫断网演练。验证核心系统的同城一个机房挂掉的情况下，是否还可以正常工作。

3、2015年
因为一次宕机事故，公司内部得出一个结论：任何基础设施、生产系统、任何流程都可能出现问题，没有经过重大灾难验证的容灾设施都是耍流氓。 启动了代号为虎虎虎的生产突袭项目，用来验证异地多活的质量。

3、2016年
故障演练项目立项（GOC+中间件），重新设计架构和产品流程，确定产品名为MonkeyKing，在交易和中间件链路尝试演练。MonkeyKing是中国美猴王的意思，看重的是孙悟空高强的本领（火眼精金、七十二变）和极具反叛的精神来，希望用一种创新的思路来保证稳定性。

四、阿里的这只猴子能做些什么？

阿里巴巴因为其多元化的业务场景和日益复杂的技术架构，会遇到各式各样的故障，故障治理的难度相比流媒体服务故障治理，难度是也增量了几个台阶。

前面介绍过的强弱依赖和容灾演练只能覆盖到部分故障。如果对故障整体做初步画像，故障整体可以分为IaaS层、PaaS层、SaaS层的故障，每一层都可能有很多故障出发原因和表现。

故障如此之多，让人摸不着头脑，我们试着把维度降低一下，换一个视角来看故障：

• 任何故障，一定是硬件如IaaS层，软件如PaaS或SaaS的故障， 并且有个规律，硬件故障的现象，一定可以在软件故障现象上有所体现；

• 故障一定隶属于单机或是分布式系统之一，分布式故障包含单机故障；

• 对于单机或同机型的故障，以系统为视角，故障可能是当前进程内的故障，比如：如FullGC，CPU飙高； 进程外的故障，比如其他进程突然抢占了内存，导致当前系统异常等；

• 人为误操作，或流程不当导致；

任何故障都可以套入到这个故障模型中。有了这个模型，我们就可以开始来设计模拟故障的演练系统了。

• 在客户机器部署OS层的故障插件，用来模拟硬件层的故障和单机进程外的故障。

• 对于应用进程内的故障，提供插拔式的故障插件，也可以用户按照我们的故障API做自己的实现。

• 对于分布式故障，则通过服务端按照IP来控制故障的范围。

• 对于一些因为各种原因无法触及的应用，比如数据库。我们提供了一个故障三方实现的标准，供故障服务接入。

通过上面的方式，基本上就把技术型故障的模型就cover全了。