嘉宾|吴冕皇冠

编辑|梁雪

混沌工程是一种提高技术架构灵活性的复杂技术手段，旨在将故障扼杀在萌芽阶段，即在故障导致中断之前识别故障。通过主动制造故障，测试系统在各种压力下的行为，识别和修复故障问题，避免严重后果。

工行在电子化、数字化方面有着丰富的经验。在之前的QCon活动中，工行关先生分享了混沌工程的技术实践，介绍了金融领域IT架构的特点、工行在高可用领域应用面临的挑战以及具体案例，帮助大家了解混沌工程中故障注入的过程以及开源框架下的选择策略。

混沌工程介绍背景

财务信息系统和互联网企业系统有什么区别？最大的区别是底层的技术栈和基础设施系统比互联网公司复杂。这里的复杂程度不一定大，但由于金融行业的数字化一般比互联网公司起步早，金融行业对信息系统的稳定性要求更高，所以在早期，有多少金融机构采用了IBM大型机，用COBOL+DB2实现核心信息系统，其他管理系统可能采用IOE。这个系统有什么优点？两个字-稳定。但最大的问题是贵。贵到什么程度？早期市场上有一种说法，全国人民都为银行工作，银行为IBM工作。虽然这个说法不准确，但是你可以大致感受到IBM的大型机系统有多贵。

随着近年来云计算、分布式、本地化的定位，各个金融领域都在进行IT架构转型，逐渐从原来的烟囱式架构向分布式架构转型。以工行为例，在IT架构转型过程中，银行业务架构相对复杂，存量可能是几千行代码，交易环节长，对交易可靠性和幂等性的要求比一般非会计业务系统更高。二是系统底层部署架构复杂，涉及IBM大型机、PC服务器、虚拟机、容器、物理机、国产服务器、非标服务器等各类底层设施。随着主机下平台的推广，很多原本运行在主机平台上的服务需要逐步迁移到开放平台，大大增加了平台系统的运维复杂度，导致应用运行的不确定性增加。三是传统银行业务主要在主机平台上运行，整体相对稳定。测试人员通常专注于业务功能的测试，但系统高可用性领域的测试水平有限。现在很多业务迁移到开放平台，职业高中没有可用的测试人员，所以应用高可用性的测试相对薄弱，这使得工行在IT架构转型过程中，迫切需要找到一种机制，确保所有业务都能稳定地对外提供服务。

因此，我们借鉴行业内应用高可用保障的相关方法，采用基于混沌工程的思想，提高工行应用系统的稳定性。混沌工程是一门在分布式系统上进行实验的学科，旨在建立系统抵抗生产环境中失控条件的能力和信心。通常混沌工程会在应用系统中随机注入一些故障，测试系统在某些功能失效时是否还能正常提供服务。目前比较主流的混沌工程故障工具有几种，每一种都在自己的领域广泛应用。行业内实现混沌工程的工具太多了，所以工行在搭建混沌工程故障演练平台时，需要考虑是选择自研故障注入工具，还是直接参考开源故障注入工具。如果参考一个开源的故障注入工具，会引入哪个开源工具？考虑到工行系统整体的技术栈和投入产出比，我们认为选择一款符合工行应用场景的开源故障注入工具，在功能更多的故障演练场景中进行二次开发，能够带来最大的收益。通过对比分析行业内几种主流的故障注入工具，发现来自阿里开源的ChaosBlade故障注入覆盖了最完整的场景，提供了统一的CLI界面，学习成本相对较低。技术栈与工行分布式系统、云计算系统的兼容性也不错。

基于混沌工程和ChaosBlade故障注入工具，工行如何提高应用系统的稳定性？

总的路线是这样的:2015年，工行开始IT架构技术转型，不可避免地导致行业架构的复杂度增加。2018年，开发中心提出加强系统的稳定性，开始重视利用混沌工程提高应用的高可用性。2019年3月，阿里开启混沌工程工具ChaosBlade。同年9月，工行完成了基于ChaosBlade的混沌工程故障演练平台建设，并在发展中心和业务R&D中心试点关键敏感业务线。由于试点效果良好，2020年7月，项目办制定了全行混沌工程推进方案。目前，工行混沌工程故障演练平台已使用100余个应用程序开展故障演练。

在平台建设初期，对故障演练的需求

在平台建设初期，有一个问题一直困扰着我们，那就是做什么样的平台。后来经过内部调查讨论，得出工行对故障演练有以下核心需求。

快速支付是工行与网络之间进行资金结算和业务处理的平台。对于不同的业务场景，快速支付可能需要调用不同后端应用提供的分布式服务，以个人金融服务为例。个人基金作为服务提供者，应向注册中心注册个人基金相关业务的服务，ATP作为服务消费者，从注册中心定义个人基金服务，然后进行沟通。这个场景是工行内部的一个主动架构设计，也就是不管校区哪个部分出现故障，都不会影响整个系统的运行。首先在双校区某校区的注册中心注入网络断开的故障模拟，单校区注册中心不可用。此时，由于股票而建立连接的服务可以继续通信而不受影响。需要在注册中心订阅服务的新请求会自动将流量切换到另一个校区，整个校区注册中心的故障对交易量和成功率影响不大。然后，故障被注入服务调用方。此时应用自我健康检查会发现服务不可用，会进行故障隔离。此时，交通将切换到另一个公园。由于原本分布在两个园区的流量现在都往一个园区去，可能会从另一个园区的限流机制入手，导致交易量减少。然后，故障被注入公园中的服务提供商。这时，一半的服务提供者停止向外界提供服务。此时，交易量将大幅下降。故障的相关节点恢复后，事务会逐渐恢复正常。

通过以上两个例子，我想大家对如何实施混沌工程故障演练有了清晰的认识。总的来说，工行全故障演练的实施路线与混沌工程中提到的类似。从小到大，对一个服务请求执行故障注入，然后对整个服务执行故障注入，然后对容器或虚拟机执行故障注入，然后对应用程序和故障域等待执行故障注入。实现环境也是从开发环境，再到测试环境，再到生产对等环境。我们这边叫不可预测环境。最终目标是在生产环境中实施故障演练。目前，我们还没有在生产环境中大规模实施故障演练，主要是在测试环境和不可预测的环境中。

可以看出，故障演练从一开始选择假设开始，然后设置实验范围，确定要监控的指标，在组织内部进行到位的沟通，然后为故障演练安排任务和设施。这个过程相当复杂，很多新人一开始都不知道怎么做。我们开始思考是否可以用更简单的方法，让用户用最少的步骤实现一个相对专业的混沌工程故障演练。通过分析用户在混沌工程故障实践平台上的实践，发现整个系统可以分为应用层、数据库层、平台层、缓存层、中间件层和路由层，因此我们抽象提取了一些常见的实践逻辑和内容，形成了实践专家库。这样，用户在实现演练时，只需要去专家库看看有没有自己想要的场景，然后添加一个计划实现故障演练的服务器，一键生成演练任务。用户不需要花费大量精力来设计和安排耗时的事项，例如何时注入任何故障以及如何取消故障。这大大降低了用户使用平台的门槛，同时提高了故障演练的效率。得益于专家库的逐步完善，初期在平台上试点应用的整体体验逐步提升。目前已有100多个应用接入混沌工程故障演练平台，200多名注册的混沌演练测试人员实施了8000多次故障演练，在应用系统层面发现并解决了200多个高可用问题，避免了这些问题在生产环境中发生，有效提升了应用的高可用水平。

总结与展望

总结工行混沌工程故障演练平台的五大价值:

故障演练流程标准化，在做高可用性测试应用之前，测试方法和水平参差不齐；

屏蔽底层异构系统，用户不应该去不同的基础设施，用不同的手段做高可用性验证；

提供丰富的故障注入能力，未来可能会有更多的业务需求，并集成其他开源框架；

根据业务架构自动生成演练任务，主要是高可用专家库的能力；

自动故障恢复在当前版本的ChaosBlade中可用，但初始版本中没有超时字段，需要手动恢复。

在开源方面，工行也全面拥抱开源。在混沌工程实践过程中，我们也积极参与开源社区的建设，提交了一些混沌工程产品的bug修复和新特性，并计划在未来为社区贡献一些通用的故障注入能力。通过近两年与社会各界的交流以及工行在混沌工程领域的实践经验，我们总结了混沌工程对工行在业务、平台体系、人员等方面的价值。

在商业中:最重要的是在上线前验证商业的正确性和幂等性。系统平台方面:对于应用系统，主要验证应用系统业务逻辑和运行环境的容错能力；对于中间件系统，主要是提高中间件架构的高可用性水平；对于基础设施平台，混沌工程可以提高硬件故障的容错性。在人才培养方面:架构师可以验证系统架构的容错性；开发运维主要提高故障应急效率；测试人员可以提早暴露在线问题；产品和设计也可以提升用户体验。

所以这个乱七八糟的项目就这么好，等它开发推广了，就一路绿灯。显然不是，推广混沌工程故障演练还是有一定难度的，因为银行系统还是以业务为中心，混沌工程的应用不能直接系统化业务价值。有些应用觉得挺稳定的，为什么要搞一个混乱的项目，让你的平台系统不稳定？它不是要去找麻烦吗？因此，不同的人对这件事的态度有很大的不同。我们的结论是，从下往上推是非常困难的。你告诉别人你的系统有多好，对他们来说实施故障训练有多有意义。通常不一定有好结果。然后我去了项目办，项目办完成后，项目办直接下发了实施各种应用的混合项目的方案。这时，推广工作走上了正轨。具体有哪些推广措施？工行在这里的经验大致可以分为三个部分:团队建设、平台门户推广、攻防演练。团队建设是核心，包括混沌工程团队、红蓝军团团队和应用高可用测试团队，都需要从各个业务团队中招募。门户推广是提升混沌工程在行业影响力的必要手段。建议采用自上而下、层层推进的方式，先固定核心部门，再利用核心部门的能力管理整个中心。其次，在例会、月会上多写材料，增强在领导面前的曝光度。

三是完善用户指南，让用户用起来舒服，不要抱怨混乱的工程平台有多糟糕。第三个内容是制定具体的实施策略，包括设置故障分值，推进常态化演练；根据应用级别设置故障演练标准；大型攻防，建立固定攻防天数等。

工行近两年实施混沌工程的一些经验教训，首先，金融部门在生产环境中实施故障演练要谨慎。目前工行还没有在生产中大规模实施故障演练，风险还是比较高的，主要是测试环境和生产点对点环境，在行业内可以称之为预测试环境，在我们这边可以称之为模型测试环境的实施。搭建统一的故障演练平台，可以事半功倍。最初，每个应用程序本身都是高度可用的。可以演练场景环境准备、媒体安装、混沌实验设计、开源工具研究等。，而整个测试可以在三五天内完成。现在，基于故障演练平台，一切都可以在两三个小时内完成。3.在实施故障演练之前，确保组织内部的沟通到位。如果不到位，你实施后可能会影响上下游，不太好。多个应用程序之间的潜在故障通常很难发现，需要考虑。我们大多数人习惯于应用内部测试，内部逻辑闭环就可以了。很少有人关注不同应用集群之间的底层硬件故障，这也可能导致其他应用的故障。比如我们之前遇到的Ceph故障，导致上面很多应用在运行中报错。

以下计划:第一，加强自动故障演练能力。目前，测试人员主要需要手动安排故障。二是加强平台故障异常自动分析能力。目前，平台可以收集故障演练过程中的各种指标，最终依靠测试人员判断是否达到预期效果。在后续计划中，将通过引入一些算法或专家经验进行自动故障异常判断和分析。三是建立在线评价评分系统，这也是工行混沌工程的一种业务价值输出方式。量化应用的高可用性，让应用的高可用性可以相对统一地衡量，让每个应用都可以清楚地看到自己的位置和需要加强的地方。

关:在工行软件开发中心云计算实验室工作，目前主要负责工行混沌工程、云原生、反应式架构、AlOps等领域新技术的研究和落地。

活动建议:

今年5月29日至5月31日，QCon全球软件开发大会将在北京召开。本次大会邀请了150多位在各个领域都有着深厚耕耘和丰硕成果的技术专家，围绕热门技术系统分享他们的实用技术，设置了人工智能驱动的商业实践、AIOps最佳实践、云原生技术应用、大数据实时计算与分析、大规模服务治理、数据库与存储技术等29个专题。

单击一个可以少看到一个bug