 作者｜中亭
编辑｜小智
2016 年，阿里巴巴开发了故障演练系统，把故障以场景化的方式沉淀到系统中，在线上主动回放故障，验证监控报警、限流降级、故障迁移、容灾策略、故障处理的有效性。本文将探讨经典的故障类型，剖析故障成因，提出处理方法，介绍故障演练系统的设计和演进，提出故障演练的原则和经验。注：本文整理自阿里技术专家中亭在 QCon 北京 2017 上的演讲，由阿里技术公众号授权转载。
写在前面
本文分享的内容重点还是围绕故障治理相关。众所周知，故障治理本身便是一个比很强的专题，几乎触及到运维、开发、故障运行管理的所有岗位，奇葩一点的故障还可能触及到运营和制品经理。聊到故障的苦与泪，相信 45 分钟绝对连开头都没讲完。今天的分享，重点还是回归故障出现的本质，故障原由方向切入。看是不是有有些办法论和通用性的手段能够沉淀出来。期盼能够对大众有所帮忙。
首要介绍一下我自己，姓名周洋，花名中亭。2011 年加入阿里接触稳定性技术行业，起始做有些稳定性制品的开发，同期亦会承担有些架构演进的推进工作，例如 HTTPS 改造，电商交易链路升配等。2015 年起始搞双 11 大促，做为共享事业部的大促负责人，保证了双 11 的稳定。亦得到双 11 老 A 亦便是双 11 特种兵的叫作号。
共享事业部针对在座各位可能比较陌生。倘若我换一个说法，商品、交易、会员、优惠、评估、中间件，大众应该就都知道了，这是双 11 当天最具挑战的链条之一。右边是中间件核心作战室成员，在过了双 11 业务高峰后的一张合影。2016 年迄今，工作的重点在常态稳定性的确定性方面，今天的分享亦是重点围绕这部分内容。
分布式系统平常依赖故障治理及技术演进
首要抛一个问题，什么状况下你会认为淘宝网挂了？ 我相信关注这个问题的人非常多，不外能给出确切答案的人并不多。由于这个看似简单的问题，真要回答起来好似亦不是那样容易。今天的分享，我先试着给大众回答一下这个问题。
让咱们从一张“简单”的页面说起。这张页面叫做商品详情页，针对大部分人来讲，这张页面是她们在淘宝完成一笔订单的第1步。而商品详情页的使命便是把商品的信息无保存的展示给大众，导致大众的兴趣，引导大众完成购买或是保藏。从信息展示的方向来讲，商品详情页确实是一张非常简单的页面。
咱们再来看一下商品详情页应用的后台架构。商品详情页是阿里最早实现静态化应用之一。哪些与浏览者无关信息，例如商品标题、照片信息、营销属性组合等信息均直接进入缓存，其他和用户关联的，如优惠、库存、物流、服务等动态信息则经过异步骤用方式填充至静态化后的页面框架内。为了在一张页面展示足够多可供决策信息，撩起用户的购买欲望，详情后台必须去依赖非常多的服务应用，聚合足够多的信息。少则几十，多则成百。从这个方向来讲，商品详情页面又是阿里依赖最繁杂的应用之一。
互联网业务的一个重点特点是，业务迭代非常快，每日有新需要，每周都有新发布，每年都有大重构，每一次变化都有可能引起情况的出现。越是贴近用户的系统，受下游服务影响越大。那样咱们不仅好奇，针对详情这个阿里最繁杂的应用，下游出现有些情况时，系统会变成怎么样？咱们经过两个实验来观察一下： 实验一：假设后端的优惠、库存、物流出现故障，咱们来观察一下商品详情页的表现。
乍一看，好似没什么问题。只是觉得页面清爽了有些。或许在这个信息过暴的时代，看着这么清新脱俗的页面，还有一点点暗爽。
在现场做了两个调查，观察大众对实验一的反映。调查 1 是请认为详情页故障了的朋友请举手。结果是现场无人举手（亦可能是现场氛围还比较冷）；调查 2 是请大众来找茬，前后两个详情页有多少处区别？这次有一个妹子说出了正确的答案（同期亦向妹子赠送了电子工业出版社出版的讲述阿里双 11 技术演进的《都在双 11》书籍）。
无对比就无损伤，一共有 6 处区别。从功能方向，这铁定是一个故障页面。不外从用户体验和业务方向讲，少了这些信息亦不影响商品购买，不影响核心用户体验。好似又是没故障？有点纠结，对吧？ 您先纠结一会儿，咱们来进行第二个实验。
实验二：当商品详情的"商品"出了问题，商品详情会怎么样？ 
详情还是那个详情，只不外是商品详情变成为了错误详情。第1张页面：很抱歉，你查看的商品找不到了。有可能是你拜访的方式不对，例如 URL 上面少了有些参数，亦可能是后台真的出问题，针对用户还算是比较温柔的一种方式。第二张页面：很可能便是网站真的出问题了。比较可能的原由是后台无恰当的处理超时引起前端反常。不外说实话，这个页面我亦非常少的见到。倘若真的显现了，那基本便是一次非常严重的事故。
经过上面的两个实验，相信大众应该针对咱们今天要介绍的一个概念"强弱依赖"有有些模糊的感觉了。 从感性的方向来讲，便是当下游依赖服务显现问题时，当前系统会受到有些影响，让用户有感觉的是强依赖，没感觉的是弱依赖。
不外这种定义不足严谨，由于总不可说无用户拜访时，就不算故障吧。因此亦需要从理性方向定义一下：首要应该出现情况，其次应该是核心业务，最后是不是带来损失。不影响核心业务流程，不影响系统可用性的依赖都能够叫做弱依赖，反之便是强依赖。
最终解释清楚什么是强弱依赖，那样做好强弱依赖治理到底有什么道理？抛开依赖模型来看强弱，道理不大。严谨的依赖模型应该包含关系、流量、强弱三个构成部分。
依赖关系定义依赖的方向，我依赖谁，谁依赖我。流量定义着每一个应用、服务、办法调用的次数，强弱则定义着依赖的松紧程度。依赖治理便是经过科学的手段连续稳定地拿到关系、流量、强弱的数据。强弱依赖重点能够被应用到下面的场景：
系统改造验收：针对分布式系统，最少应该做到运行态中不会由于我依赖的系统显现故障，而导致当前应用显现可用性的问题，例如进程挂掉，频繁 FullGC，负载飙高等，何时何地都具备快速止血的能力。
限流降级参考：针对弱依赖，通常都要配置限流或是自动降级策略，比起经过拍脑袋或是经验值来设定，倒不如经过实质的故障测试来进行微调，例如针对下游显现超时状况，就能够经过实验得出基于线程池限流到底要填写多少许值。
应用起步次序：理想状况下，应用起步更应该做到 0 强依赖起步。不外有有些状况没法做到。因此呢应用起步的依赖次序亦需要实时关注。尤其是新 IDC、机房建站时，那个蜘蛛网同样的依赖关系，最好是经过系统方式得到。
故障根源定位：后台系统的故障，常常经过上一层的业务故障表现出来。故障处理讲究的是争分多秒，良好的强弱依赖，针对系统自动化诊断有非常大的助力功效。
依赖容量评定：正常调用链路下系统容量需要评定，当某个弱依赖挂掉时，整体的容量是不是有变化。
说完背景，最终能够聊一下强弱依赖的技术实现。在阿里，强弱依赖的技术演进整体上分了 3 个周期，每一个周期的方法的诞生都有其独特的时代背景和业务难点。此刻回头看来，亦能够看到当时技术的局限性和突破。
熟练淘宝技术发展史的朋友都晓得，2008 年阿里刚才完成一个代号为五彩石的项目，完成从巨石系统向服务化系统的改造。业务和研发模式上有了很强的发展，不外网状的依赖关系亦带来了非常多的问题。这个纪元的重点特点是：故障频发，技术思路和办法都是以结果为导向，糙一点、结果精度差一点能够忍受。
模拟依赖故障技术上有三招，改代码 + 发布，远程 Debug+ 重启，登陆设备去执行有些 shell 命令操作。 好处是灵活随意，能够必定程度达到效果；坏处是成本高，影响环境稳定，你测试的时候其他人处在没法工作状态，影响效率。另外，这个周期，由于分布式链路跟踪技术还没起步，因此模拟依赖故障时，经常会漏掉有些主机或某些服务。故障的粒度亦比较粗，针对有些 Linux 的命令，都是主机级别的。
阿里内部有一套平常环境，重点做上线前的集成测试。为了尽可能减少对环境的影响。咱们经过修改服务版本的方式，形成一个独立的测试环境。记得 11 年下半年，我起始做第1版的时候，我搭了淘宝 12 个核心应用的平常环境，踩坑无数，纯体力活，亦算前无古人，后无来者了。
经过这套环境跑了几次结果，发给核心的业务 TL，大家很兴奋，貌似找到一条治理的路子。不外火速暴露了新问题，例如环境的运维归属问题，研发设备的干扰问题，以及针对业务的认识程度和测试粒度问题，因此在很长一段时间测试的范围都局限在交易核心链路。
第二个周期的核心便是提效，从第1个周期的痛点入手，处理人的成本和环境的问题。这个周期之后，基本能够摆脱手工方式，效率上有大幅度提高。
这个周期亦引入了有些测试技术，其中用的比较多的是 Selenium，经过这种技术能够提前录制用户行径并转化为测试脚本，并且每一个过程都能够截图记录，方便问题复查。
在这个时期，阿里中间件的技术有必定发展，分布式跟踪技术显现，能够把用户拜访的链条串联起来，排查问题的效率有了必定提高。同期所有的中间件，如 Nginx、信息、分布式服务调用、分布式数据库、软负载和配置中心等都做了改造，支持用户流量的标记、跟踪和路由掌控。基于以上这些技术发展，环境的问题就有非常大的突破。
在内部咱们叫作为叫二套环境。它的核心原理是在基本环境之上，动态区分出有些小环境，她们分别是某个业务的子集。项目之间彼此独立，不会互相调用，仅有当依赖的服务不在时，才会去拜访基本环境的服务。数据库和缓存是公用的。
在这个周期，咱们不必再去修改代码的服务版本，每次发布后，代码的版本等能够自动化的保持一致，运维成本有所降低，野服务干扰的状况亦有所缓解，人的介入非常的少。不外还是有有些问题亟待处理：
首要，二套环境的路由策略是和用户绑定的，亦便是说需要提前去做有些配置；其次，域名上亦有有些限制，加了 second 等前缀，测试路径中 URL 等复用率低的问题无完全处理；第三，测试的粒度仍然很粗，独霸设备，规模化推广时，设备成本和用例运行的成本还是很高；第四，故障场景缺失，只存在于基本环境的服务没法模拟的故障，如：数据库故障，缓存故障等。
2014 年的时候，咱们的思维方式有了比很强的突破。咱们再也不纠结于环境和外边手段的改进，而是回归到强弱依赖关注最核心的部分。那便是业务影响和系统设计。能否实现一种只与代码设计和业务关联，而与外边环境无关的方法呢？
这时期有两个关键思路或是推论：
推论 1：咱们要的是下游依赖显现故障现象，不必真的是下游服务供给方显现故障。只要消费方感觉下游显现故障就可。从这个思路来讲，商品详情倘若要做强弱依赖测试，只要自己玩就 OK，不需要去折腾下游依赖的几十个应用。
推论 2：咱们之因此需要单独搭建环境，为的便是掌控故障的影响范围。那样咱们能够换一下思路，便是咱们只影响要出现故障的请求，其他的业务流量都放过。是不是就能够达到目的。本质上是一种对业务流量的筛查能力。
有了上面的思路，第1问题便是怎样拦截用户的请求？拦截用户请求，让用户改导致本最低，无什么地区比中间件更适合了。每一个通用的远程调用接口，都是能够做文案的点，并且中间件之上的业务系统不消做任何改造。
下一个问题便是故障规则和业务识别，咱们曾思虑在用户请求的入口就打上标记，置入故障规则，不外发掘针对 post 请求，异步 js 请求，按时任务等都有比很强的改导致本，且有安全隐患。 因此就增多了一个服务端，直接下发故障规则到依赖插件上。
故障插件经过对流量的调用拦截 + 业务识别，独一确定影响哪一个请求，而后经过故障规则判断是注入反常还是超时，从而达到模拟故障的效果。 由于插件可扩展的设计，因此咱们默认是能够同期注入多种故障场景的，同期插件亦会把影响到请求的仔细信息异步上报给服务端做分析。
理论上经过以上的方法，在业务流量输入方面，咱们无任何需求。无论是人的自发测试行径，还是设备的测试行径，都无任何限制。只不外为最大限度复用已有的测试用例累积，加强自动化程度，咱们设计了一套用例注解，封装了和强弱依赖服务端的通信。利用 Junit 生命周期的特点，完成故障规则的下发和清除。
任何一个测试用例，20 秒之内改导致一个强弱依赖的测试用例。在结果输出方面，会仔细的展示一次强弱依赖检测的过程，以及测试用例触及到的链路的依赖变化。到此周期，强弱依赖真正达到了一个相对里程碑的版本，2014 年起始，强弱依赖亦做为双 11 必做的一个横向项目。
下面是强弱依赖注解和依赖系统的示例：
总的来讲，全部强弱依赖技术演进历史，便是对数据准确性，稳定性，成本、效率的不懈追求，并在这几者之间达成一个动态平衡。
故障演练的基本原则和最佳系统设计实践
众所周知，2017 年不大太平，业界显现了非常多大故障。
2017 年 3 月 1 日，弗吉尼亚州数据中心显现故障，亚马逊 S3 服务显现了较高的错误率，直接影响到成千上万个在线服务；2017 年 1 月 31 日， GibLab 朋友线上数据库变更时，遇到突发了一个状况。由于操作失误，引起全部生产数据库被误删除，丢失 6 个小时的数据；
2017 年 2 月份国内的一家经常被用来测试网络连通性的友商亦显现了故障，工信部快速关注，并紧急约谈了关联机构。同期下发紧急通告需求 BAT 等各重点互联网企业吸取教训，业界一片哗然。
此时候，有一家机构显出尤其淡定，那便是 Netflix。 Netflix 是一家服务全世界的在线影片租赁供给商，他的核心业务完全架设在 AWS 上面。据资讯揭露，Netflix 在亚马逊故障时能够火速的恢复正常，由于她们内部有一个"防故障"的基本设备。听起来，好似是咱们需要的东西。
 fill=%23FFFFFF%3E%3Crect x=249 y=126 width=1 height=1%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)
深入调查之后，发掘防故障基本设备背面是一个猴子军团。
早在 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 能力。
故障演练宣言：把故障以场景化的方式沉淀，以可控成本在线上模拟故障，让系统和工程师平时有更加多实战机会 ，加速系统、工具、流程、人员的进步。
关于将来：
故障演练的后续工作重点会关注在以下方向：演练常态化、故障标类化、演练智能化。用常态化的演练驱动稳定性进步，而不是大促前进行补习；丰富更加多的故障场景，定义好最小故障场景和处理手段；基于架构和业务分析的智能化演练，沉淀行业故障演练处理方法。
在 QCon 北京 2017 全世界软件大会做的分享，亦是第1次揭秘阿里故障预防的技术细节，欢迎大众转发和交流。倘若你对构建高可用行业感兴趣或有云端制品的研发经验，有做普惠技术、创造商场价值的志向，欢迎邮件 zhongting.zy@taobao.com
作者介绍
周洋，花名中亭，阿里巴巴技术专家。2011 年加入阿里巴巴中间件 & 高可用架构团队，始终从事稳定性制品开发和架构升级的关联的工作，主导了强弱依赖、灰度发布、线上故障演练等多款高可用制品的开发和建设，见证了阿里高可用制品体系从 1.0 到 3.0 的发展历程，累积了丰富的架构和稳定性经验。2015 年做为共享事业部的大促 PM，负责大促和常态稳定性的保证工作。
今日荐文
点击下方照片就可阅读
技术漫谈：为么 KPI 毁了索尼，而 OKR 却成就了谷歌？
| 
发表于 2024-8-25 13:26:17
