嘉宾 | 吴冕冠
编辑 | 薛梁
混沌工程是一种提高技术架构弹性能力的复杂技术手段，旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。
工商银行在电子化和数字化方面有丰富的经验，在之前的 QCon 活动上，工商银行的吴冕冠老师分享过混沌工程的技术实践内容，介绍了金融领域 IT 架构的特点以及工行目前在应用高可用领域面临的挑战，和具体的案例，帮助大家了解混沌工程故障注入的流程，以及在开源框架上的选型策略。
混沌工程引入背景
金融领域信息系统，相对于互联网企业系统，信息系统有什么区别呢？最大的区别就是底层的技术栈和基础设施体系比互联网企业的系统更加复杂。这里的复杂不一定是体量大，而是因为金融行业的数字化普遍比互联网公司开始的要早，加之金融业对信息系统的稳定性要求较高，因此在早期多少金融机构都采用的是 IBM 主机这一套，采用 COBOL DB2 实现核心信息系统，其他管理系统可能会采用 IOE，这套体系的优点是什么呢？两个字——稳定。但最大的问题就是贵，那贵到什么程度呢，早期导致坊间有这么一种说法：全国人民给银行打工，银行给 IBM 打工。虽然这个说法不太准确，大致可以感受 IBM 的大机系统有多贵。
随着近些年云计算、分布式以及国产化的导向，目前各金融领域都在进行 IT 架构转型，将原来的烟囱式架构逐步往分布式体系转型，以工行为例，在 IT 架构转型过程中银行业务架构相对复杂，存量的一个存过可能都是上千行代码，交易链路长，对交易可靠性，幂等性要求比一般非账目类的业务系统要高。二是系统底层部署架构复杂，涉及 IBM 大机、PC 服务器、虚机、容器、物理机、国产化服务器、非标准服务器等多种类型的底层设施，随着主机下平台的推推进，很多原来运行在主机平台上的服务都需要逐步迁移至开放平台，大幅增加了平台系统的运维复杂度，导致应用运行的不确定性增加。三是由于银行业传统业务主要运行在主机平台之上，主机平台整体比较稳定，测试人员平时主要侧重业务功能的测试，在系统高可用领域测试水平有限，现在很多业务迁移至开放平台，且由行内存量没有职高可用测试人员，因此在应用高可用方面的测试相对比较薄弱，这使得工商银行急需寻找一种机制确保在 IT 架构转型的过程中所有业务可以稳定对外提供服务。
因此我们借鉴业界应用高可用保障的相关方法，采用基于混沌工程的思想，以提升工行应用系统的稳定性。混沌工程是在分布式系统上进行实验的学科，目的是建立系统对抵御生产环境中失控条件的能力和信心。通常情况下，混沌工程会采用在应用系统中随机注入一些故障，用采检验系统在部分功能出现故障的情况下，是否还能正常对外提供服务。目前相对主流混沌工程故障工具有如下几个，每个工具在各自的领域都有较为广泛的应用。那业界混沌工程实施的工具这么多，那在工行进行混沌工程故障演练平台建设的时候，就要思考是选择自研故障注入工具，还是直接引用开源的故障注入工具。如果引用开源的故障注入工具，引入哪款开源工具。考虑到工行系统的整体技术栈以及投入产出比，我们认为选择符合工行应用场景的开源故障注入工具，再更加功能的故障演练场景，进行二次开发这种策略可以产生最大的效益。通过对比分析业界主流的多款故障注入工具，发现阿里开源的 ChaosBlade 故障注入覆盖的场景最全，且提供了统一的 CLI 交互界面，学习成本相对较低，技术栈与工行分布式体系和云计算体系兼容性也较好。
那工行是如何基于混沌工程思想以及 ChaosBlade 故障注入工具提升行内各应用系统的稳定性呢？
大致路线如下：2015 年工行开始 IT 架构技术转型，转型过程中不可避免导致业架构复杂度增加，2018 年开发中心提出要加强系统稳定性，并开始关注使用混沌工程提高应用高可用能力。2019 年 3 月阿里开源混沌工程工具 ChaosBlade，同年 9 月，工商银行完成基于 ChaosBlade 的混沌工程故障演练平台建设，并在开发中心，业务研发中心对行内重点敏感业务线进行试点，由于试点效果良好，2020 年 7 月，项目办制定全行混沌工程推广计划，目前已有 100 多个应用在工行混沌工程故障演练平台开展故障演练。
平台建设初期，故障演练诉求
在平台建设初期，有一个问题一直困扰着我们，那就是要做一个什么样的平台。后来公司内部调研讨论了一下，总结出工行目前对于故障演练主要有如下几个核心诉求。
第一，屏蔽应用架构和底层部署架构的差异。由于工行目前正在进行 IT 架构转型转型，因此目前存在多种架构并存的情况、比如 IBM 大机 COBOL DB2 体系，IOE 体系，开放平台体系等。底层部署设置，可能涉及虚假、容器、物理机、国产化服务器、IBM 主机等，这么多类型的底层设施，最好能在混沌工程故障演中练平台实现统一的封装，对用户而言只要故障实施故障的内容，而不需要关注底层的差异。
第二，在开源混沌工程工具大多只提供故障注入能力，但是对于实施企业级故障演练，单凭用命令或者脚本的方式进行故障注入，无论是在效率还是可行性上来看，都是不够的。因此需要在故障注入工具的基础上提供故障编排、任务调度、演练场景配置等能力，实现企业级的平台能力。
第三，可根据不同应用架构，推荐相应的故障演练场景和示例。因为工行不同的业务场景，应用的架构特性可能会有所差异，而对于刚接触混沌工程的人员而言，可能在混沌实验实施经验方面相对缺乏，因此希望混沌工程故障演练平台可以根据架构特性，提供针对性的故障演练指导说明和 demo 样例，降低用户使用难度。总结一下就是混沌工程故障演练平台需具备通用、便捷、智能的特性。
混沌工程故障演练平台
基于通用、便捷、智能这三个理念，我们在 2019 年开发了混沌工程故障演练平台。工行的混沌工程体系总体上分为五层，分别是上层业务、平台模块、任务调度、底层能力、基础设施。最下面的是工行应用所部署的基础设施，包括容器，虚机，物理机和其他非标准服务器。最终，混沌工程故障注入介质将会安装在这些基础设施上实施各类的故障。
在基础实施层之上，基于 ChaosBlade 进行二次开发的混沌工具故障注入介质。为保障故障注入工具能力的可扩展性，实现与上层调度平台的解耦，降低调用方的使用难度，将故障注入的调用能力封装成 Rest 接口，并增加服务器系统指标收集模块，可实时收集服务器的 CPU、内存、网络等系统硬件使用情况，此外我们也开发了故障注入任务解析模块，该模块可将混沌工程故障演练管理平台下发的故障演练任务解析成多个故障注入事件，然后根据各个故障注入事件的开始和结束时间分别调用 ChaosBlade 故障注入工具实施故障注入和撤销操作。故障注入介质之上的是任务调度模块，负责平台和故障注入介质之间的交互，核心功能是实现混沌实验任务的批量下发和调度，该模块可以快速批量下发各种类型的混沌实验，支持失败重发、超时重发、高并发等机制。再往上则是混沌工程故障演练平台，主要有权限管理、介质管理、演练编排、监控、CI/CD 集成、高可用专家库等 12 个核心功能，所有底层的架构和部署差异都会在平台层统一进行封装，做到对用户透明。平台也负责所有故障演练的生命周期管理和结果分析。
最上面的就是业务场景，目前工行主要有三大应用场景，最常用的就是平时的日常故障演练，用来检测各业务系统的鲁棒性。第二个应用场景是在进行应用评级的时候，包括行业应用 DevOps 评级和工行行内重点应用评级，我们都会根据不级别应用采用相应的测评方案进行测试。第三个场景是生产问题复现和分析因为你不可能在生产环境去重现问题，有些问题也不太好重现，我们就会通过在测试环境尽量按照生产当时的情况搭建一套对等环境，然后借助故障演练平台去复现问题以及问题修复了之后的验证工作。
目前工行的混沌工程平台故障注入介质整体上支持应用，系统和容器这三个领域相关的二三十种故障注入场景，这其中大多数是 ChaosBlade 工具自带的能力，也有一些是工行自己集成进去的能力，比如模拟 IO 夯以及一些 JVM 相关的故障注入场景。
平台建成完成之后，测试人员就需要利用混沌工程故障演练平台开始实施故障演练，根据混沌工程指导原则以及工行这两年的实践，总结了工行在实施混沌工程故障演练过程中的八个步骤：分别是选定假设、设定实验范围、识别出要监控的指标、在组织内沟通到位、执行实验、分析实验结果、广大实验范围、自动化实验这八个步骤，其中执行实验的具体流程又可分为配置演练任务、任务调度框架下发故障注入介质、介质安装、故障注入任务解析、实施故障注入、恢复演练环境。
故障平台案例
下面电票业务的故障演练场为例来说明一下上述整个流程：电票就是电子商业汇票，有点类似支票的作用，主要用于商业结算。在对电票系统进行故障演练，
第一步是选定假设，明确对什么场景进行故障注入，比如在系统层面可对应用服务器、容器、数据库、WAS、操作系统、网络等进行故障注入；应用层面则可以对应用软件的线程、连接池、事务、异步、队列等场景进行故障注入、还有业务层可以通过串改业务报文、或者返回内容进行故障注入。假设本次计划对应用层和系统层进行故障注入；
第二是设定实验范围：需要对哪些节点实施故障注入，需要评估出现故障时可能会受到影响的应用范围，确保不会造成灾难性结果！因为银行业务系统一个应用一般都不只一种类型的节点，比如电票业务北向和人行的票交所相连，南向则是自身的数据库节点，电票应用内部又分为电票前置、票据服务、电票服务。所以可以在电票前置、票据服务、电票业务、数据库这四个子节点内部以及节点之间的联系共 9 处地方实施故障注入。
在初期，我们可以选择其中的一处或者几处实施故障注入，比如对主数据库设置网络不可访问，看看系统能不能自动切换到备用数据库中。然后明确要监控的指标，必须清楚地知道各监控指标的正常范围，这样可以在系统波动时第一时间发现异常。当主数据库不可访问时，交易的成功率、TPS、平均耗时这几个是必须要监控的指标，同时流量可能会突然切换到备用数据上，因此我们还需监控备用数据库的 CPU、内存、磁盘 IO、网络的变化情况。如果涉及到多个应用之间的调用，还需关注上下游应用的流量控制情况，比如限流、降级熔断等措施是否生效。监控指标明确了之后，当涉及到上下游应用时，需要协调爆炸半径内应用的相关支持人员，确保有问题时能及时发现，即时出现系统崩溃也能及时恢复。
当所有的准备工作都完成了之后，就可以登陆故障演练平台编排和实施故障演练了，在演练过程中，要对各个维度的指标进行全方位的监控。工行的混沌工程故障演练体系目前支持平台本身的目标服务器底层资源如 CPU、内存、网络、磁盘的使用情况实时监控。对于分布式服务器，也支持服务调用情况的实时监控。对于跨应用链路，也支持全链路的监控。以及业务测交易成功录，耗时等的交易实时监控。
在所有监控的指标中，其中有四个是重点关注的：
健康检查，就是你故障注入之后，应用或者平台的健康检查程序是否能在第一时间发现异常，这个是应用的第一道防线，比较理想的情况是在业务感知异常之前，应用内部已经发现并解决了相关问题。
如果应用在被故障注入之后，健康检查程序没有检测到异常，这个时候就会启动第二道防线，平台层面的健康。工行的很多业务都运行在容器上，因此当平台的容器层面感知到异常时，容器能不能自隔离和自愈也是衡量应用高可用非常重要的指标。
第三个关键指标就是能否实现优雅停机。当应用自身或者平台测感知到异常之后，能否立即不再接收新的请求，并且能够把正在处理的请求都正常处理完，然后再停止相关故障进程。
第四个指标就是业务指标，判断在注入之后是否发生交易异常。
演练结束后，需要对整个演练进行复盘，分析实验结果，一是总结分析是否达到预期的演练效果，根据实验过程中收集的监控指标，分析前面的假设是否成立，系统是否弹性，是否出现了预期之外的问题！二是针对故障演练中暴露出的问题，进行架构优化和 bug 修复。比如在电票业务实际的混沌工程故障演练过程中，发现了点票系统个别业务模块未设定进程数上限，存在隐患，个别业务超时机制没有达到预期效果，部分接口限流机制还需进一步完善，降级机制不够灵活等问题，通过对这些问题进行改进，然后再反复演练直到问题解决为止。
快捷支付故障演练
当小范围的实验中获得信心之后，就可以逐步扩大实验范围，比如增加链路应用数目。下面再举一个相对和互联网体系比较接近的例子进一步说明。
快捷支付是工行与网联进行资金清算与业务处理的平台，针对不同的业务场景，快捷支付可能需要调用后端不同应用提供的分布式服务，以调研个人金融服务为例。个金应用作为服务提供方，将个金相关业务的服务注册到注册中心，ATP 作为服务消费方，从注册中心定义个金的服务，然后再进行通信。这个场景在工行是一个双活的架构设计，就是无论哪个园区哪个环节出现故障，都不会影响整个系统的运行。首先，对双园区的某一个园区的注册中心注入网络断连的故障模拟单园区注册中心不可用。此时由于存量已经建立连接的服务可以继续通信，不受影响。新的需要到注册中心订阅服务的请求，会把流量自动切换到另外一个园区，所有整体上当园区注册中心故障对交易量、成功率几乎无影响。然后，再对服务调用方注入故障，此时应用自身健康检查会发现服务不可用，进行故障隔离，此时流量会切换到另外一个园区，由于原来分布在两个园区的流量现在都往一个园区走，可能会出发另一园区的限流机制，导致交易量会有有所下降。接着，再对一个园区的服务提供方注入故障，此时有一半的服务提供方停止对外提供服务，此时交易量会有一个比较明显的下降，等发生故障的相关节点恢复了之后，交易逐渐恢复正常。
通过以上两个例子，我想大家对于如何实施混沌工程故障演练已经有了比较清晰的认识。工行整个故障演练的实施路线整体上和 Chaos Engineering 书中所提到的是类似的，从小到大，先对服务的某个请求进行故障注入，然后再对整个服务进行故障注入，接着对容器或者虚机进行故障注入，再到应用，故障域等待。实施的环境也是先从开发环境，再到测试环境，再到生产对等环境，我们这边叫莫测环境（适应性测试）。最终的目标是在生产环境实施故障演练。目前我们还暂时没有在生产环境大规模实施故障演练，主要在测试环境和莫测环境做。
可以看到故障演练从一开始的选定假设再到设定实验范围、识别要监控的指标、组织内沟通到位，然后进行故障演练任务编排和设施。这个过程还是比较复杂的，而且很多新人一开始也不知道怎么去做。我们就开始思考能不能通过更加简便的方法，让用户可以用最少的步骤，实施相对专业的混沌工程故障演练。我们通过对用户在混沌工程故障演练平台实施的演练进行分析，发现整体上可以分为对应用层、数据库、平台层、缓存、中间件、路由层这几大领域进行故障演练，于是我们把一些共性的演练逻辑和内容进行抽象和提取，形成了演练专家库。这样用户在实施演练的时候，只需到专家库中看一下有没有自己想要的场景，然后添加计划实施故障演练的服务器，就一键生成演练任务，用户不用花费大量的精力去设计和编排什么时候注入什么故障，怎么撤销等耗费时间的事项。这大大减低了用户使用平台的门槛，同时也提升了故障演练效率。得益于专家库的逐步完善，初期在平台进行试点的应用对平台的整体体验也在逐步提升，目前全行已有一百多个应用接入混沌工程故障演练平台，在册的混沌演练测试人员两百多名，共实施了八千余次故障演练，发现并解决了两百多个应用系统层面的高可用问题，避免这些问题发生在生产环境，有效提升了应用的高可用水平。
总结与展望
总结一下工行混沌工程故障演练平台的五个价值：
- 故障演练流程标准化，之前是个应用自己去做高可用测试，测试的方法和水平都参差不齐；
- 屏蔽底层异构系统，用户不要再去更加不同的基础设施采用不同的手段去做高可用验证了；
- 提供丰富的故障注入能力，后续可能更加业务需求，还会集成其他的开源框架；
- 根据业务架构自动生成演练任务，这个主要就是高可用专家库的能力；
- 自动故障恢复，ChaosBlade 目前版本是有了，最初的版本是没有 TimeOut 字段，需要手工恢复。
开源方面，工行也是全面拥抱开源的。在混沌工程实践过程中，也积极参与开源社区建设，提交一些混沌工程产品的 bug 修复和新特性，后续也计划将一些通用故障注入能力贡献给社区。通过这两年与社区的交流以及工行在混沌工程领域的一些实践经验，我们总结了一下混沌工程对应工行在业务、平台系统、人员这三方面的价值。
在业务方面：最主要的还是上线之前验证业务的正确性和幂等性。在系统平台方面：对应用系统而言主要验证应用系统业务逻辑和运行环境的容错能力；对中间件系统而言，主要是提高中间件架构的高可用水平；对基础设施平台而言，混沌工程可提升硬件发生故障是平台的容错能力。在人员培养方面：架构师可验证系统架构容错能力；开发 & 运维则主要提高故障应急效率；测试人员可提早暴露线上问题；产品 & 设计也可提升用户体验。
那这混沌工程这么好，实施在开发和推广的时候就一路绿灯了呢？显然不是，在推广混沌工程故障演练的时候，还是遇到了一些难度，因为银行体系还是以业务为核心的，应用配合搞混沌工程，无法直接体系业务价值。有些应用觉得自己挺稳定的，为啥要弄一个混沌工程把自己的平台系统搞的不稳定，这不是没事找事么。所以不同的人对于这件事情的态度差异非常大。我们的结论是，自底向上去推，是非常困难的。你和别人说你的系统有多好，实施故障演练对他们有多大意义，通常情况下不一定有比较好的效果。然后去找了项目办，把项目办搞定了之后，项目办直接出台了一个各个应用落地实施混动工程的计划单，这个时候推广工作就进入正轨了，那具体怎么的推广措施有哪些呢，工行这边的经验是大致可以分为团队建设，平台门户推广，攻防演练这三部分去做。团队建设是核心，包括混沌工程技术团队、红蓝军团队、应用高可用测试团队都需要从各个业务团队那边去招兵买马。门户推广是提高混沌工程在行内影响力的必要手段，建议采用自顶向下，层层推进的方式，搞定核心部门，然后借住核心部门对全中心的纳管能力去推动。其次是例会月会多写材料，提升在领导面前的曝光度。
第三是完善的用户使用指引，让用户用的舒心，不要到领导面前去投诉混沌工程平台有多不好用。第三块内容是具体实施策略的制定，包括设定故障分值，推动常态化演练；根据应用等级设定故障演练标准；大型攻防，建立固定攻防日等。
两年混沌工程在工商银行落地实践的一些经验教训，首先金融领域在生产环境实施故障演练要谨慎，工行目前暂时还没有在生产上大规模实施故障演练，风险还是比较高的，主要是在测试环境和生产对等环境，业界可能叫预发环境，我们这边叫模测环境实施。构建统一的故障演练平台能事半功倍，最初各应用是自行去做高可用的，可能演练一个场景环境准备，介质安装，再混沌实验的设计开源工具的学习等，三五天才能完成整个测试，而现在基于故障演练平台，可能两三个小时就搞定所有事情了。三实施故障演练之前，要确保组织内沟通到位，如果不到位，你实施之后可能对上下游造成影响，这样就不太好。多应用间的底层故障往往难以被发现，需要重点考虑。我们之前大多数是应用内部测试，内部逻辑闭环就好了，很少人去关注不同应用集群之间的底层硬件故障可能也会导致其他应用的故障，比如我们之前就遇到搞 Ceph 故障，导致运行上上面的很多应用都报错。
接下来的一些规划：一是加强自动化故障演练编排能力，目前主要还是要测试人员手动进行故障编排。二是加强平台的故障异常自动分析能力，目前平台可以收集故障演练过程中的各项指标，最终还是依靠测试人员去判断是否达到预期效果。后续计划通过引入一下算法或者专家经验，进行自动化故障异常判断和分析。三是建立应用线上评价打分体系，这个也是工行混沌工程对外的一种业务价值输出方式。将应用的高可用能力进行量化，这样就可以相对统一去衡量应用高可用水平，让各应用清晰的看到自己的位置以及在哪里方面还有待加强。
