一分钟精髓速览
混沌工程是在分布式系统上进行试验，在整个零碎中随机地位通过工具引发故障，从而进步零碎健壮性以及人员的响应效率，建设对系统抵挡生产环境中失控条件的能力以及信念的伎俩。尽管混沌工程曾经倒退了十余年，但对大部分公司和研发团队，它仍是一个比拟生疏的畛域。本文总结了去哪儿 2019 年至今，从零开始建设混沌工程平台的 4 个阶段，以及各阶段的落地成绩，整体建设思路和落地路线极具参考性。
作者介绍
去哪儿网高级技术总监 – 朱仕智 TakinTalks 社区特聘专家，2013 年退出去哪儿网，负责过公共业务、国内机票、基础架构等团队，善于高并发高可用高性能的零碎设计和落地，多年的技术治理教训。目前负责基础架构部门，蕴含根底平台、中间件架构、大前端、品质保障等团队，近期专一公司整体技术演进和云原生、数字化技术落地。
舒适揭示：本文约 5000 字，预计破费 8 分钟浏览。
TakinTalks 公众号后盾回复“交换”进入读者交换群；回复“1151”获取讲师课件；
回复“混沌”获取《混沌工程实际指南》。
背景
在我接手去哪儿基础架构团队之后，每次看到系统故障的新闻，比方之前 Facebook 服务器宕机、B 站去年的“713 故障”（传送门：B 站 SRE 负责人亲述 713 事变后的多活容灾建设），会十分感同身受，因为在去哪儿也陆续呈现过一些比较严重的故障。
2019 年去哪儿在 ZK 上呈现了屡次比较严重的故障，因为咱们的基础设施里所有内网的 Java 服务之间的通信，次要采纳 dubbo 的分布式服务框架，它重度依赖 ZK 组件，故障频发影响可想而知，最重大的一次故障让整个公司的业务简直停摆了 2 个小时。面对这些大范畴的重大故障，通过调研评估后，咱们决定在外部推广混沌工程来解决。
通过 3 年的实际，咱们的混沌工程也获得了很好的成果，这里也和大家分享一上来哪儿混沌工程平台从无到有、从 0 到 1 的建设实际。
一、为什么倡议做混沌工程？
1.1 混沌工程的价值
混沌工程作为软件测试和质量保证的一种办法，非常适合古代分布式系统和流程，在抵挡失控、防止不确定上，它是十分不错的技术手段。在去哪儿的实际中，我总结混沌工程的价值次要有以下三个方面：
1.2 混沌工程落地成果
混沌工程在去哪儿落地后，的确给咱们带来了不错的功效。比方，在 2019 年咱们有大量的中间件如 ZK、MQ 之类的品质和稳定性是比拟蹩脚的，通过了混沌工程一系列的保障措施之后，在过来的近三年里，咱们再没有产生过任何因为中间件可靠性导致的故障了，这对咱们来说是十分大的提高。另外，现阶段很多问题的定位工夫，曾经从几十分钟降为 3-5 分钟的程度，排查定位问题的速度也有了质的飞跃。
二、落地前须要做哪些思考和盘点？
2.1 两个值得思考的问题
如果你也恰好打算在企业外部落地混沌工程，有两个十分重要的问题我认为是值得思考的。
1、混沌工程的最佳实际是随机攻防演练吗？
2、混沌工程的落地价值如何确保？
我看到过很多同学想去实际混沌工程，更多是因为它是云原生的配套，或者因为它是一个十分新的技术。然而，当咱们在企业里去落地一项技术，咱们其实须要思考它真正的价值，确保它产出的价值可能大于投入，而且要能充沛地展现这个价值。如果只是去建设一个混沌工程平台，是没方法确保能取得价值的。所以，如果这两个问题没有失去很好的答案，我感觉不应该大规模地进行混沌工程的实际。
2.2 盘点常见故障起因
思考和盘点常见的故障起因大略都有哪些，才可能针对性地提供比拟无效的定向演练，联合去哪儿的教训，我大略把常见的故障分成了五类——机房问题、中间件问题、机器问题、利用问题、依赖问题。
咱们能够从利用架构的档次来看的这五类问题，从上往下看，它出问题的概率越来越小，然而影响却正好相同，是越来越大的。比方，机房层网络挂掉或者大规模的机器实体机被中断，这些状况呈现的概率很小，但只有呈现一个就意味着是十分大规模的影响，而且它复原时长绝对会比拟长。咱们之所以要去看这样的构造和档次，其实它跟咱们的混沌工程实际路线是有关系的。刚开始做混沌工程是要思考性价比的，即先去解决咱们认为最重要的事件。
对去哪儿来说，特地是在后面提到的 2019 年的那种状况下，咱们是优先做了机房层和中间件层，因为咱们过后的中间件和基础设施出问题的概率较高。所以这里也就是引出来一个点——咱们混沌工程的实际路线到底应该怎么去弄。
2.3 混沌工程实际线路
去哪儿的混沌工程从 2019 年 11 月开始，到 2022 年 9 月咱们始终继续在做，但每个阶段在做的点和档次是不一样的，针对不同的实际对象，咱们做了不同时长的落地，整个时间轴和要害节点大略如下图：
2019.11-2020.1 基础设施演练：比方下面提到的机房、中间件。这种基础设施的演练，适宜稳定性保障十分弱的期间，在这里出的问题影响面往往比拟大，所以做基础设施演练的收益就会比拟显著。
2020.2-2020.3 利用演练：这个阶段实际的次要对象是利用的各类过程问题。当大规模的故障曾经失去了基本保障，然而利用状态频出，此时就能够思考落地利用演练了。
2021.2-2022.9 依赖演练：次要针对零碎所有的内部依赖，如 HTTP 接口或者 RPC 接口等，即便利用自身没有问题，然而依赖的资源呈现问题时零碎也会被拖垮。此时，就须要做服务治理的问题预防。当然，如果服务治理素来没呈现过任何问题，这个可能价值就不会那么大。
2022.3-2022.4 攻防演练：后面的演练都是针对零碎的，攻防演练的对象次要是开发、品质保障或者 SRE 等人员。当混沌工程的系列工具和机制曾经绝对欠缺，然而人员在应急状况下的解决能力还是有余的时候就能够做攻防演练了。以上是去哪儿实际落地的路线，也十分举荐大家依照这种路线来做，从性价比由高往低的形式去推动。
三、各阶段的指标和成果有哪些？
3.1 阶段一：基础设施演练
3.1.1 建设指标和关键点
在做基础设施演练之前，咱们须要先剖析指标，能力提取出它对应的关键点。
去哪儿在这块的能力建设指标，是同一个机房某个业务线外面所有的服务节点全副都生效掉的时候，利用也能不受影响。对应这个指标，咱们也有几个关键点是须要特地留神的。机房聚合信息查问，不便利用革新咱们 CMDB 外面的信息要尽可能地全，而且是可能比拟不便地检索进去，这样不便利用做前置革新。即开始制订演练打算时，曾经晓得机房里部署的利用有哪些不合乎容灾特色，就能够提前告诉这些利用的负责人进行革新了。主动建设沟通群，进度周知演练是一个十分大规模、横跨多部门和团队、跨长周期的事件，所以须要无效的沟通机制。在去哪儿网，咱们依靠外部的 IM 把整个流程串起来，在开始布局时就会有专门的沟通群，真正开始执行也会有对应的进度周知，有预警时也会在群里周知复原等等，这样可能保障信息的共享是足够实时和全面的。实在关机拔电测试、网络断掉等等都能演练，然而复原起来绝对较快，为了尽可能模仿实在简单的关机场景，咱们抉择了对数千个节点做实在关机，这样能够针对外面的场景去做提效类的工作。只有实在关机，能力验证复原时长是不是真的可能达到要求。接入告警，告警事件关联推送如果公司外面曾经有告警体系，那么须要和演练的事件绑定和关联起来，确保告警信息能及时送达。
3.1.2 技术实现
整体来说，这部分的技术要求不高。比方，去哪儿过后是 openstack 虚拟机和容器并存的状态，过后就次要面向虚拟机，咱们的演练测试只需对接 openstack API；其余咱们只须要针对批量运维的工具，相似 saltstack 这种形式，就能够满足技术要求了。
这里特地说一下自研管制面，它十分要害，从制订演练打算开始，到编排和触发演练等等，都须要依靠这个管制面去把它形象好，蕴含其余各种目标和状态的演练，都是依靠它来进行的，所以它其实是一个简单的管制平台。所以在最开始设计的时候就要思考好，它可能不是简略只针对基础设施演练的平台，它须要适应各种演练策略和演练场景，还须要能相当灵便地管制，须要足够不便地去筛选出要演练的指标，这样就能疾速针对少量的利用、机器去进行实在关机的演练和复原状态的察看，而后以及后续的问题剖析和跟进。
3.1.3 演练成果
咱们在机房演练了几十次，波及到了几千个机器，大几百个利用，每次大略可能发现十几个问题——从日常设计来说，咱们感觉它是不应该呈现的。但当咱们真正去做这种机房级别的演练时，仍会发现不少会影响业务的问题，甚至会影响咱们主流程的业务。
3.2 阶段二：利用演练
3.2.1 建设指标和关键点
后面说到，咱们利用演练的能力建设指标，是对所有利用能够抉择多种策略进行故障注入。这里我认为也有 4 个关键点须要关注。线上环境利用资源会强依赖于环境状态，如果是在测试环境中去做利用演练，会发现演练进去的论断不肯定牢靠，测试环境中很多配置不能保障百分百和线上统一。牢靠的注入工具在线上环境做演练就要求注入故障的工具要十分牢靠，去哪儿过后抉择了开源的 chaosblade。（回复“混沌”，获取混沌工程工具总结比照表）丰盛的演练策略演练策略须要能涵盖公司历史上呈现过的 90% 以上的故障场景，通过这个形式至多能把应用层的问题模仿进去，这就要求有十分丰盛的策略才可能满足。失效面可控在注入故障的工具上须要做肯定的管制，比方，要注入的利用实例的规模、利用高低线等等。
3.2.2 利用演练流程
当咱们要真正对线上的利用的过程变更时，咱们须要把 agent 装载进去，再把故障策略注入进去，这两个过程中去哪儿之前也碰到了一些问题，比方，当 agent 注入时，会有刹时 CPU 升高的问题，咱们是通过把利用的实例先下线，流量先不进入这个实例，等 agent 注入实现且复原后，再把它从新挂载下来，这个点可能会在大家实际中面临到，以上解决形式能够供参考。
3.2.3 利用演练成果
下图是演练打算的成果界面图，可能看到咱们能够依照利用去演练，人工或者定时地去触发，在线上环境里抉择不同的场景、不同的演练策略、不同的利用等等。目前在去哪儿有 31 种的故障场景反对，曾经满足了公司内至多 95% 的诉求了。
3.3 阶段三：依赖演练
3.3.1 建设指标和关键点
依赖的演练不同于后面两种模式的演练，它更多是服务于服务治理，很多的服务之间都须要协同通信能力实现性能，然而这些通信的配置，比方超时、熔断或者是利用自身的代码的编写，都会造成本来冀望它是一个弱依赖，但实际上代码写进去和配置进去，它就变成了一个强依赖。通过这个依赖的演练，咱们就能够提前发现哪些是不合乎预期的，就能够提前把它修复掉。利用元数据采集故障注入时须要有元信息，比方 A- 利用要调 B 利用什么接口，咱们不可能依附人工去输出，不仅人工成本高，对人的要求也高，所以咱们须要有十分欠缺的元数据的采集，并且造成比拟无效的拓扑构造可能不便咱们去制订打算。
可视化的利用拓扑构造收集利用元数据可能造成一个比拟无效的可视化的利用拓扑构造，就能够对拓扑构造进行依赖级别的演练，在大规模演练中，咱们基本上都是从外围链路的入口开始，全链路拓扑构造大范畴笼罩的形式来进行的。辨别不同场景的同一个依赖这是下面提到的 chaosblade 中企业场景的性能。强弱关系依赖标注这部分刚开始时须要人工进行标注，能力晓得这个依赖断言进去后，强弱到底合不合理。
（去哪儿标记对象成果页面）
3.3.2 依赖演练成果
咱们大略进行了 1200 屡次的演练，波及到了 3000 多个依赖。去年五一之前，咱们对机票酒店业务的主流程进行全面笼罩演练时，共计发现了 136 个问题。
3.4 阶段四：攻防演练
3.4.1 建设指标和关键点
攻防演练是大家日常常常看到的，就是线上的随机性攻防反抗演练。须要强调的是，攻防演练并不是混沌工程中达成稳定性保障指标的无效伎俩，它服务于人工排查和处理速度的晋升。线上环境的故障排查受限于各种因素，比方，解决人员绝对扩散、解决相似故障的频率不高导致教训难积攒、故障起因品种繁多等等，都会导致当线上呈现问题时，排查处理速度较慢，攻防演练就是为了帮忙团队提前积攒教训，进步排查速度。
造就混沌文化咱们须要让公司大部分开发人员认同混沌工程的价值，开发人员必须要认同它的价值，能力比拟好地去发展攻防演练，所以外部文化的建设很重要。工夫和策略真随机如果只是提前预报，通知大家某个时候要演练，这样会对解决人做预判和解决都有影响，此时失去的处理速度和效率数据就不可信，所以工夫和注入的策略肯定要真随机。信息烦扰各类组件都有对应的异样栈，以及咱们是用测试流量或者是压测流量来做触发流量它带有的流量标识，这些信息都会在开发定位时有提醒，变相放慢了处理速度。所以这些信息须要抹除掉，还原到跟线上一样的信息，能力真正测试响应速度。
3.4.2 攻防反抗演练流程
整个攻防反抗中，我认为有两个要点，第一个是编排流程比之前的单个点演练更简单；第二个是须要依赖外部的其余基础设施，比方攻击点的布局就必须得参考历史故障，就要求要有故障的汇总平台等。
（去哪儿攻防演练故障注入过程演示）
3.4.3 攻防演练成果
在往年 4 月份集中的两次测试能够看出，咱们的整体定位速度大部分都是在 3 分钟左右，相比之前的须要几十分钟，故障排查耗时曾经升高了很多。
3.5 混沌工程平台架构
通过这些场景落地之后，目前去哪儿混沌工程的平台的系统结构大略是这样的。其中最外围的是两头的演练零碎，整个平台它自身是一个组合性、综合性的性能平台，很多事件并不是本人在这个平台外部去做的，而是应用了其余平台的能力。
1、混沌工程对小企业是否有必要？
2、混沌工程 4 个阶段的人员投入如何？
3、对于左移的做法，老师感觉意义大吗？
对于本文的更多疑难，欢送公众号后盾回复“1105”获取答案
四、总结
针对以上的分享，我总结概括为以下三个外围观点。
1、实际路线要正当：整个混沌工程的实际落地路线须要联合公司状况和诉求进行设计，千万不要随声附和，性价比高收益高的场景先反对。
2、演练老本很要害：大规模、常态化演练能力取得长期有效的稳定性保障。演练老本是确保混沌工程落地价值的要害。
3、攻防演练为提速：混沌工程的止境是随机攻防演练，但并不是性价比最高的。攻防演练的目标是加上排查速度，而不是发现问题。
理解更多去哪儿网混沌工程实际细节，欢送扫码进入「读者交换群」，和老师实时互动。
回复【1151】获取讲师课件回复【交换】进入读者交换群更多内容欢送进入「TakinTalks 稳定性社区」，观看完整版视频内容。
申明：本文由公众号「TakinTalks 稳定性社区」联结社区专家独特原创撰写，如需转载，请后盾回复“转载”取得受权。