超全总结 | 阿里电商故障治理和故障演练实践

写在前面

近日,在 QCon北京2017大会上,来自阿里巴巴中间件团队的技术专家周洋(花名中亭)发表了题为《阿里电商故障治理和故障演练实践》专题演讲。在会后官方组织的评选中,本次演讲的内容得到了一致好评,中亭获选为本次大会的明星讲师。此次演讲整体上分享了从 2011 年至今,阿里巴巴电商平台遇到的诸多有代表性的故障,以及在此过程中积累的非常多的高可用保障经验和解决方案。

本次分享包括两个部分:第一部分会从分布式系统经典依赖故障出发,剖析故障成因,介绍治理方案和技术演进;第二部分从宏观视角探讨构建一套”防故障”设施的重要性,并探讨如何设计一套故障演练系统,介绍故障演练的基本原则和最佳经验。

演讲全文

大家好,今天来的人不少,可见对于故障耿耿于怀的人,不止我自己。今天分享的内容主要还是围绕故障治理有关。众所周知,故障治理本身就是一个比较大的话题,几乎涉及到运维、研发、故障运行管理的全部岗位,奇葩一点的故障还可能涉及到运营和产品经理。聊到故障的苦与泪,相信45分钟绝对连开头都没讲完。今天的分享,主要还是回归故障发生的本质,故障原因角度切入。看是否有一些方法论和通用性的手段可以沉淀出来。希望可以对大家有所帮助。


今天演讲的主要包括两个部分:第一部分会从分布式系统经典依赖故障出发,剖析故障成因,介绍治理方案和技术演进;第二部分从宏观视角探讨构建一套”防故障”设施的重要性,并探讨如何设计一套故障演练系统,介绍故障演练的基本原则和最佳经验。考虑演讲时间和内容关联度,之前报给大会提纲中的”通过灰度发布提前发现故障”的章节被隐去,有兴趣的同学可以会后交流。


首先介绍一下我自己,姓名周洋,花名中亭。2011年加入阿里,接触稳定性领域,开始做一些稳定性产品的研发,同时也会承担一些架构演进的推进工作,比如HTTPS改造,电商交易链路升配等。2015年开始搞双11大促,做为共享事业部的大促负责人,保障了双11的稳定。也获得双11老A也就是双11特种兵的称号。

共享事业部,对于大家可能比较陌生。如果我换一个说法,商品、交易、会员、优惠、评价、中间件,大家应该就都知道了,双11当天最具挑战的链条之一。右边是中间件核心作战室成员,在过了双11业务高峰后的一张合影。2016年至今,工作的重点在常态稳定性的确定性方面,今天分享主要也是围绕这部分内容。

分布式系统常见依赖故障治理及技术演进

抛一个问题,什么情况下,你会认为淘宝网挂了? 这个问题,相信关注的人很多,不过能给出确切答案的人并不多。因为这个看似简单的问题,真要回答起来好像也不是那么容易。今天的分享,试着先回答一下这个问题。



从一张“简单”的页面说起。这张页面叫做商品详情页,相信在坐的各位对这张页面不会陌生,因为对于大部分的人,这张页面是他们在淘宝完成一笔订单的第一步。而商品详情的使命就是把商品的信息没有保留的展示给大家,勾起大家的兴趣,引导大家完成购买或是收藏。从信息展示的角度来讲,商品详情页面确实是一张非常简单的页面。

我们再来看一下商品详情应用的后台架构。商品详情是阿里最早实现静态化应用之一。那些与浏览者无关信息,比如商品标题、图片信息、销售属性组合等信息均直接进入缓存,其他和用户相关的,如优惠、库存、物流、服务等动态信息则通过异步调用方式填充至静态化后的页面框架内。为了在一张页面展示足够多可供决策信息,撩起用户的购买欲望。详情后台必须去依赖非常多的服务应用,聚合足够多的信息。少则几十,多则成百。从这个角度来讲,商品详情页面又是阿里依赖最复杂的应用之一。

互联网业务的一个主要特点是,业务迭代非常快,每天有新需求,每周都有新发布,每年都有大重构,每一次变化都有可能导致状况的发生。越是贴近用户的系统,受下游服务影响越大。那么我们不仅好奇,对于详情这个阿里最复杂的应用,下游发生一些状况时,系统会变成怎样?
我们通过两个实验来观察一下。

实验一:假设后端的优惠、库存、物流发生故障,我们来观察一下商品详情页的表现。


乍一看,好像没什么问题。只是觉得页面清爽了一些。或许在这个信息过暴的时代,看着这么清新脱俗的页面,还有一点点暗爽。

在现场做了两个调查,观察大家对实验一的反映。调查1:认为详情页故障了的同学请举手。结果是现场没有人举手(也可能是现场氛围还比较冷);调查2:大家来找茬,前后两个详情页有多少处不同?结果:最后有一个妹子说出了正确的答案(大家的热情被调动起来了,因为答对的同学有《尽在双11》的书赠送)


没有对比就没有伤害,一共有6处不同。从功能角度,这铁定是一个故障页面。不过从用户体验和业务角度讲,少了这些信息也不影响商品购买,不影响核心用户体验。好像又是没故障?有点纠结,对吧? 您先纠结一会儿,我们来进行第二个实验。

实验二:当商品详情的”商品”出了问题,商品详情会怎样?


详情还是那个详情,只不过是商品详情变成了错误详情。
第一张页面:很抱歉,你查看的商品找不到了。有可能是你访问的方式不对,比如URL上面少了一些参数,也可能是后台真的出问题,对于用户还算是比较温柔的一种方式。
第二张页面:很可能就是网站真的出问题了。比较可能的原因是后台没有合理的处理超时导致前端异常。不过说实话,这个页面我也非常少的见到。如果真的出现了,那基本就是一次非常严重的事故。


通过通过上面的两个实验,相信大家应该对于我们今天要介绍的一个概念”强弱依赖”有一些模糊的感觉了。 从感性的角度来讲,就是当下游依赖服务出现问题时,当前系统会受到一些影响,让用户有感觉的是强依赖,没感觉的是弱依赖。不过这种定义不够严谨,因为总不能说没有用户访问时,就不算故障吧。所以也需要从理性角度定义一下:首先应该发生状况,其次应该是核心业务,最后是否带来损失。不影响核心业务流程,不影响系统可用性的依赖都可以叫做弱依赖,反之就是强依赖。


终于解释解释清楚强弱依赖,那么做好强弱依赖到底有什么意义?抛开依赖模型来看强弱,意义不大。严谨的依赖模型应该包括关系、流量、强弱三个组成部分。依赖关系定义依赖的方向,我依赖谁,谁依赖我。流量定义着每个应用、服务、方法调用的次数,强弱则定义着依赖的松紧程度。依赖治理就是通过科学的手段持续稳定的拿到关系、流量、强弱的数据。强弱依赖主要可以被应用到下面的场景:

  • 系统改造验收:对于分布式系统,至少应该做到运行态中不会因为我依赖的系统,后台出现故障引起当前应用出现系统级可用性的故障,比如进程挂掉,频繁GullGC,负载飙高等,合适何地都具备快速止血的能力。
  • 限流降级参考:对于弱依赖,一般都要配置限流或是自动降级策略,比起通过拍脑袋或是经验值来设定,到不如通过实际的故障测试来进行微调,比如对于下游出现超时情况,就可以通过实验得出基于线程池限流到底要填写多少数值。
  • 应用启动顺序:理想情况下,应用启动更应该做到0强依赖启动。不过有一些情况,无法做到。因此应用启动的依赖顺序也需要实时关注。特别是新IDC、机房建站时,那个蜘蛛网一样的依赖关系,最好是通过系统方式获得。
  • 故障根源定位:后台系统的故障,往往通过上一级的业务故障表现出来。故障处理讲究的是争分多秒,良好的强弱依赖,对于系统自动化诊断有非常大的助力作用。
  • 依赖容量评估:正常调用链路下系统容量需要评估,当某个弱依赖挂掉时,整体的容量是否有变化。


说完背景,终于可以聊一下强弱依赖的技术实现。强弱依赖的技术演进,整体上分了3个阶段。每个阶段的方案的诞生都有其独特的时代背景和业务难点,现在回头看来,也可以看到当时技术的局限性和突破。


熟悉淘宝技术发展史的同学都知道,2008年阿里刚刚通过一个代号为五彩石的项目,完成从巨石系统向服务化系统的改造。业务和开发开发模式上有了较大的发展,不过网状的依赖关系也带来了非常多的问题。这个纪元的主要特点是:故障频发,技术路和方法都是以结果为导向,糙一点、结果精度差一点可以忍受。

模拟依赖故障技术上有三招,改代码+发布,远程Debug+重启,登陆机器去执行一些shell命令操作。 好处是,灵活随意,可以一定程度达到效果。坏处是成本高,影响环境稳定,你测试的时候,其他人属于无法工作状态,影响效率。此外,这个阶段,因为分布式链路追踪技术还没起步,所以经常会漏掉一下服务服务。故障的粒度也比较粗,对于一些linux的命令,都是主机级别的。

阿里内部有一套日常环境,主要做上线前的集成测试。为了尽量减少对环境的影响。我们通过修改服务版本的方式,形成一个独立的测试环境。记得11年下半年,我开始做第一版的时候,我搭了淘宝12个核心应用,踩坑无数,纯体力活,也算前无古人,后无来者了。

通过这套环境跑了几次结果,发给核心的业务TL,大家很兴奋,貌似找到一条治理的路子。
不过很快暴露问题,比如环境的运维归属问题,开发机器的干扰问题,以及对于业务的了解程度和测试粒度问题。所以在很长一段时间测试的范围都局限在交易核心链路。


第二个阶段的核心就是提效,从第一个阶段的痛点入手,解决人的成本和环境的问题。这个阶段之后,基本可以摆脱手工的方式,效率上有大幅度提升。

这个阶段引入了一些测试技术,其中用的比较多的是Selenium,通过这种技术可以提前录制用户行为并转化为测试脚本的技术,并且每一个步骤都可以截图记录,方便问题复查。

在这个时期,中间件的技术有一定发展,分布式追踪技术出现,可以把用户访问的链条串联起来,排查问题的效率有了一定提升。同时所有的中间件,如nginx,消息,分布式服务调用,分布式数据库,软负载,配置中心等都做了改造,支持用户流量的标记,追踪,路由控制。基于这项技术,环境的问题有非常大的突破。

在内部,我们称为叫二套环境。它的核心原理是在基础环境之上,动态区分出一些小环境,他们分别是某个业务的子集。项目之间彼此独立,不会互相调用,只有当依赖的服务不在时,才会去访问基础环境的服务。数据库和缓存是公用的。

在这个阶段,我们不必再去修改代码的服务版本,每次发布后,代码的版本等能够自动化的保持一致,运维成本有降低,野服务干扰的情况也有所缓解,人的介入非常的少。不过还是有一些问题待解决,首先二套环境的路由策略是和用户绑定的,也就是说需要提前去做一些配置。其次,域名上也有一些限制,加了second等前缀,测试路径中URL等复用率低的问题没有完全解决。第三,测试的粒度仍然很粗,独占机器,规模化推广时机器成本,用例运行的成本还是很高。第四,功能性缺失。不被二套环境的基础设施故障没法模拟,比如数据库故障,缓存故障等。


2014年的时候,我们的思维方式有了比较大的突破。我们不再纠结于环境和外部手段的改进,而是回归到强弱依赖关注最核心的部分。那就是业务影响和系统设计。能否实现一种只与代码设计和业务相关,而与外部环境无关的方案呢?

这期间有两个关键思路或是推论:

推论1:我们要的是下游依赖出现故障现象,不必真的是下游服务提供方出现故障。只要消费方感觉下游出现故障即可。从这个思路来讲,商品详情端如果要做强弱依赖测试,只要自己玩就够了,不需要去折腾下游依赖的几十个应用。

推论2:我们之所以需要单独搭建环境,为的就是控制故障的影响范围。那么我们可以换一下思路,就是我们只影响要发生故障的请求,其他的业务流量都放过。是不是就达到目的了。本质上是一种对业务流量的筛查能力。

有了上面的思路,第一问题就是如何拦截用户的请求?拦截用户请求,让用户改造成本最低,没有什么地方比中间件更适合了。每个通用的远程调用接口,都是可以做文章的点,并且中间上层的业务系统不用做任何改造。

下一个问题就是故障规则和业务识别,我们曾考虑在用户请求的入口就打上标记,置入故障规则,不过发现对于post请求,异步js请求,定时任务等都有比较大的改造成本,有安全隐患。 所以就增加了一个服务端,直接下发故障规则到依赖插件上。故障插件通过对流量的调用拦截+业务识别唯一确定影响哪一个请求,然后通过故障规则判断是注入异常还是超时。从而达到模拟故障的效果。 因为插件可扩展的设计,所以我们默认是可以同时注入多种故障场景的。同时插件也会把影响到请求的详细信息异步上报给服务端做分析。

理论上通过上述的方案,在业务流量输入方面,我们没有任何要求。无论是人的自发测试行为,还是机器的测试行为,都没有任何限制。只不过为最大限度复用已有的测试用例积累,提高自动化程度,我们设计了一套用例注解,封装了和强弱依赖服务端的通信。利用Junit生命周期的特点完成故障规则的下发和清除。任何一个测试用例,20秒之内改造成一个强弱依赖的测试用例。在结果输出方面,会详细的展示一次强弱依赖检测的过程,以及测试用例涉及到的链路的依赖变化。到此阶段,强弱依赖真正达到了一个相对里程碑的版本,2014年开始,强弱依赖也作为双11必做的一个横向项目。

下面是强弱依赖注解和依赖系统的示例:



小结部分,重新回顾了强弱依赖的定义、意义。整个强弱依赖技术演进历史,就是对数据准确性,稳定性,成本、效率的追求和平衡。

故障演练的基本原则和最佳系统设计实践

众所周知,2017年不大太平,业界出现了很多大故障。

2017-03-01 弗吉尼亚州数据中心出现故障,亚马逊S3 服务出现了较高的错误率,直接影响到成千上万个在线服务
2017-1-31 GibLab同学线上数据库变更时,遇到突发了一个情况。因为操作失误,导致整个生产数据库被误删除,丢失6个小时的数据。
2017年 2月份国内的一家经常被测试网络连通性的友商也出现了故障,引起工信部的关注,并紧急约谈了相关公司。同时,下发紧急通知,要求BAT等各重点互联网企业吸取教训。业界一片哗然。


这时候,有一家公司显得特别淡定,那就是Netflix。 Netflix是一家服务全球的在线影片租赁提供商,他的核心业务完全架设在AWS上面。据新闻揭露,Netflix在亚马逊故障时可以很快的恢复正常(前文的新闻稿是针对早些时候AWS的故障,非2017S3故障),因为他们内部有一个”防故障”的基础设施。听起来,好像是我们需要的东西。


深入调查之后,发现防故障基础设施背后是一个猴子军团。

早在2012年,Netflix就发布了Chaos Monkey。用来在随机杀死实例,据官方数据指出,到目前累计杀死65,000个节点。他们的测试策略也比较有趣:在工作时间在生产和测试环境运行,目标测试系统的健壮性,训练后备人员,让恢复更简洁、快速、自动;Latency Monkey的作用就是让某台机器的请求或返回变慢,观察系统的表现; Chaos Gorilla,大猩猩。他的能力是搞挂一个机房,宏观验证业务容灾和恢复的能力。

Netflix发布猴子军团的原因是因为,他们很早就吃过云故障的亏,所以本能是认为云设施是不可靠的,必须在通过演练来验证软件层面的容灾。


古代有个哲学家说过”没有人曾经两次踏进同一条河流”,因为无论是这条河还是这个人都已不同。故障也是类似的,故障发生的时间地点,影响流量,与故障打交道的人都没法完全相同。从这个角度看,故障治理本身是一个伪命题,都是在解决过去某一个时刻的问题。不过从程序员视角(我习惯叫上帝视角),任何故障的原因都是可被定位的,避免相同原因重复引发故障,是每个程序员应该执着追求的目标。电商历史上遇到了非常多有代表性的故障,为了不让故障重复发生,阿里内部也打造了一套”防故障”的基础设施。


2015年5月27日,因为光纤电缆的问题,支付宝大规模宕机事故,公司内部得出一个结论:任何基础设施、生产系统、任何流程都可能出现问题,没有经过重大灾难验证的容灾设施都是耍流氓。 启动了代号为虎虎虎的生产突袭项目,用来验证异地多活的质量。
2012年,完成交易的同城双活后,就启动了同城容灾演练,也叫断网演练。验证核心系统的同城一个机房挂掉的情况下,是否还可以正常工作。
2011年,开始做强弱依赖的治理和建设,希望提前发现因为依赖问题导致的系统故障,系统的代号是EOS(出处是古希腊神话中的黎明女神,语意是能够把纷乱的依赖关系梳理清楚)

可以看到,这三大件和Netflix的猴子军团从功能上基本上是对标的。那是不是就应该没有故障,安枕无忧了呢? 答案铁定是不是。


阿里巴巴因为其多元化的业务场景和日益复杂的技术架构,会遇到各式各样的故障,故障治理的难度相比流媒体服务故障治理,难度是也增量了几个台阶。前面介绍过的强弱依赖和容灾演练只能覆盖到部分故障。如果对故障整体做初步画像,故障整体可以分为IaaS层、PaaS层、SaaS层的故障,每一层都可能有很多故障出发原因和表现。那么对于这么多种类繁杂的故障,内心一定是懵逼的。我们要如何重现进而避免这么多繁杂的故障呢?


熟悉三体的同学应该听说过”降维攻击”这个词,不妨让我们把维度降低一下,换一个视角看故障:

  • 任何故障,一定是硬件如IaaS层,软件如PaaS或SaaS的故障。 并且有个规律,硬件故障的现象,一定可以在软件故障现象上有所体现。
  • 故障一定隶属于单机或是分布式系统之一,分布式故障包含单机故障
  • 对于单机或同机型的故障,以系统为视角,故障可能是当前进程内的故障,比如:如FullGC,CPU飙高; 进程外的故障,比如其他进程突然抢占了内存,导致当前系统异常等。
  • 同时,还可能有一类故障,可能是人为失误,或流程适当导致,这部分我们今天不做重点讨论。

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


所以在内部,我们起了一个代号叫做”大圣归来”的项目,项目名叫做”故障演练”,承载的产品叫做MonkeyKing。MonkeyKing是中国美猴王的意思,看重的是孙悟空高强的本领(火眼精金、七十二变)和极具反叛的精神来,希望用一种创新的思路来保证稳定性。


我们的系统实现,也是围绕前文讨论的故障模型来设计的:

  • 在客户机器部署OS层的故障插件,用来模拟硬件层的故障和单机进程外的故障。
  • 对于应用进程内的故障,提供插拔式的故障插件,也可以用户按照我们的故障API做自己的实现。
  • 对于分布式故障,则通过服务端按照IP来控制故障的范围。
  • 对于一些因为各种原因无法触及的应用,比如数据库。我们提供了一个故障三方实现的标准,供故障服务接入。

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


在去年的双11中,故障演练的应用场景主要应用在图中的几个场景。 按照业务流量、压测流量的峰值可以划为4个象限。具体案例如下(这部分现场因为时间关系,没有展开说,为新增部分):

  • 预案有效性:过去的预案测试的时候,线上没有问题,所以就算测试结果符合预期,也有可能是有意外但是现象被掩藏了。
  • 监控报警:报警的有无、提示消息是否准确、报警实效是5分钟还是半小时、收报警的人是否转岗、手机是否欠费等,都是可以check的点。
  • 故障复现:故障的后续Action是否真的有效,完成质量如何,只有真实重现和验证,才能完成闭环。发生过的故障也应该时常拉出来练练,看是否有劣化趋势。
  • 架构容灾测试:主备切换、负载均衡,流量调度等为了容灾而存在的手段的时效和效果,容灾手段本身健壮性如何。
  • 参数调优:限流的策略调优、报警的阈值、超时值设置等。
  • 故障模型训练:有针对性的制造一些故障,给做故障定位的系统制造数据。
  • 故障突袭、联合演练:通过蓝军、红军的方式锻炼队伍,以战养兵,提升DevOps能力。


故障演练宣言:把故障以场景化的方式沉淀,以可控成本在线上模拟故障,让系统和工程师平时有更多实战机会,加速系统、工具、流程、人员的进步。

关于未来

故障演练的后续工作主要会关注在以下方向:演练常态化、故障标类化、演练智能化。用常态化的演练驱动稳定性进步,而不是大促前进行补习;丰富更多的故障场景,定义好最小故障场景和处理手段;基于架构和业务分析的智能化演练,沉淀行业故障演练解决方案。

企业级互联网架构Aliware,让您的业务能力云化:https://www.aliyun.com/aliware