实战 混沌工程在平安银行的落地实践与发展思考

  近年来，随着分布式系统架构、微服务理念、PaaS服务组件等新型技术在金融行业普及，传统基于主机及存储的单体业务系统架构正在快速向基于云底座的分布式系统架构（简称新系统架构）演进。新系统架构在支撑千万级别月活用户的零售银行、7×24小时线上支付等大并发高流量业务场景的同时，在生产运行稳定性方面也产生了一系列新问题和新挑战。

  挑战之一：分布式和微服务是新系统架构的重要特点，相对于传统主机系统在一个单体系统内基本能完成业务功能与场景，新系统架构采用分布式微服务应用池设计理念，应用池仅完成较为单一的原子功能，支撑业务场景需要多应用池相互调用，形成调用链。在某些复杂业务场景情况下，调用链路甚至超过十步，并且涉及数据中心外部合作机构系统调用。这一设计对系统运行稳定带来非常大挑战，应用池或外部合作机构故障造成的影响会蔓延至业务场景调用链路上下游的多个应用池，同时由于微服务设计的功能共享原则，故障影响也会促进扩展至别的业务场景，形成所谓“爆炸半径”。

  挑战之二：新系统架构的另一重要特点是依赖云底座提供的PaaS基础服务，例如服务注册中心、软负载均衡、外部调用代理、入口网关、消息系统、缓存服务、数据库服务等。PaaS基础服务在提供公共能力的同时，也引入了新的故障因素。更进一步，PaaS基础服务的公共属性也导致服务自身容易受到调用方故障的影响，并成为故障影响蔓延的传播节点和放大器。

  挑战之三：生产系统运维团队在新系统架构转型过程中，知识领域由相对集中的主机系统向更多技术领域扩展，保障生产运行质量不仅仅要关注业务系统自身，也需要同步关注支撑业务系统的底层PaaS服务，甚至IaaS服务。团队转型和应急保障能力的提升是确保新系统架构顺利引入的成败之举。

  混沌工程最早可追溯到Netflix技术团队创建的Chaos Monkey系统，通过在生产环境持续主动进行故障注入来验证生产系统运行的故障容忍能力，进而提升系统运行稳定性。通俗来讲，混沌工程类似“疫苗”：通过持续少量注入有害病毒来锻炼机体对抗疾病的能力。相对于传统IT系统的健壮性测试理论，混沌工程可以视为健壮性测试理论在新系统架构下的演进、发展与提升。

  数年前，平安银行启动了信用卡核心系统重构项目，将大型机架构的系统彻底改造为自研金融级PaaS底座为基础的分布式架构系统（以下简称新核心系统）。新核心系统引入了微服务应用池、注册中心、用户分片请求路由、消息队列、任务调度、分布式数据库等一系列PaaS基础服务。系统投产后的运行稳定性和运维保障能力曾是项目的最大风险点之一。因此运维团队在项目规划阶段主动引入混沌工程理念，建设基于Chaos blade开源组件的混沌演练平台，并在系统正式投产前的并行验证阶段执行了五轮的演练验证。投产前的并行验证阶段使用运维管理的生产数据中心，按照正式投产的架构进行系统部署，采用生产环境可观测系统，通过生产流量录制和回放的方式验证新系统。

  在项目中，混沌工程大致上可以分为两个阶段。前两轮为第一阶段，侧重点在于新核心系统和PaaS组件的健壮性和故障容忍能力。关键流程如下。

  案例设计：分析新核心系统和PaaS服务组件的架构，结合生产数据中心情况及历史故障库，设计故障注入点和故障注入案例。故障案例分为多个层次，既有IaaS层基础设施的硬件故障、网络抖动、文件读写、DNS服务等异常，也有上层PaaS服务短时质量波动，故障自动切换，数据库连接池拥堵、数据库服务缓慢等场景。

  案例执行，即故障注入：通过自动化工具或人工触发的形式，向系统中持续多次注入故障，以模拟现实世界中的不确定性和复杂性，某些故障场景采用多种IaaS层和PaaS层故障点的组合注入实现。

  可观测体系建设：建立完善的监控和告警系统，实时收集和分析系统运行数据，以便在故障注入后，实时观测新核心系统及PaaS组件的运行状况。

  演练结果评估：通过可观测体系的数据，分析实际演练结果和容灾设计预期的差距，重点观察故障注入后的故障容忍恢复能力和爆炸半径。更进一步，在完成一批次故障注入之后，分析系统薄弱点，补充故障案例库，进行下一次测试。执行多次测试摸底当前系统模块设计现状的故障容忍能力边界和关键薄弱点。

  反馈与优化：根据演练结果，对系统架构设计反馈优化改进建议，包括修复系统容灾缺陷和优化架构设计等。例如，改进基于用户分片的服务请求路由组件的数据加载方式，提高服务节点故障重启后的服务恢复时效。另外，在演练过程中优化监控系统的告警逻辑和故障等级，并对系统关键薄弱点建立相应的应急预案。

  经过两轮的演练、评估、反馈和优化，新核心系统及PaaS服务组件的健壮性和故障容忍能力得到了显著提升，绝大多数故障案例可以被系统自动容忍，仅会引起短时服务质量波动。同时可观测系统建设成熟，并对需要人工干预的故障场景建设了应急预案。由此，混沌工程进入第二阶段，工程关注的重点由系统转为人，即运维团队的应急响应能力。

  在第二阶段，混沌工程项目组引入红蓝对抗模式，将运维工程师随机分为两组：蓝军组和红军组。蓝军组，负责实验设计，并且随机选择故障注入的频次、位置和组合；红军组，在不提前告知的情况，承担告警响应、故障定位和服务恢复的的职责。演练过程中，运维工程师交替承担蓝军或红军角色，相互考核，模拟生产应急过程，进入生产应急状态。经过第二阶段的三轮演练，运维团队的应急响应能力得到了显著提升。

  在信用卡新核心项目中，也曾经存在混沌工程价值的不同意见，特别是在新核心系统及PaaS组件已完成健壮性测试的情况下，是否还有必要在投产前的并行验证阶段进行混沌工程。最终，混沌工程产出的一系列问题报告、优化建议、可观测能力、应急预案与运维团队应急响应能力建设证明了其价值。混沌工程也在平安银行的年度科学技术创新大赛中取得了冠军。思考其成功问题大多有以下几点。

  一是基于云原生PaaS服务的分布式系统架构复杂度显著上升，在测试环境难以实现接近生产的部署标准，不得不进行简化部署，而正是简化部署导致新核心系统在测试环境的异常应对表现与生产环境存在非常明显差异。测试环境的可观测系统也相对简陋，导致即使系统行为异常，也难以被有效观测。

  二是测试环境通常没有持续且真实的生产流量。在少量测试负载下，系统的异常容忍表现会显著好于真实生产负载。例如：在计算节点故障重启的情况下，如果不做好启动保护，应用进程面对生产流量的持续冲击，有可能进程持续启动异常，无法自行恢复故障。但在测试环境很难发现这一薄弱点。

  三是测试团队对于生产数据中心的故障场景理解通常弱于运维团队，在测试案例设计以及实际执行方面易产生偏差，难以模拟真实生产故障。

  四是混沌工程不仅仅关注系统的健壮性与故障容忍能力，同时也关注可观测系统、应急流程与应急团队的快速响应能力。

  事实上，混沌工程在信用卡新核心系统上取得成功之后，故障注入平台也赋能至测试环境，充实了健壮性测试案例，并且修订完善重要信息系统的健壮性测试规范，要求周期性进行健壮性测试，并由运维团队来复核测试报告，取得了一些成绩和进步。但总体来说，产出效果还不能满足生产运行稳定的期望。

  当前，平安银行正在推进云原生转型重大信息科技战略，云底座能力的建设也为混沌工程实践带来了新机遇，重要信息系统在云原生改造过程中也对混沌工程提出了新要求。作为云原生项目中的一个重要子工程，平安银行的运维团队制定了三步走的混沌工程推进方案（如图1所示）。

  如前期思考所述，混沌工程的核心价值特别大程度上依赖接近生产标准和运作时的状态的验证环境，因此如何构建该环境是整个规划核心关键，考虑资源投入和云底座能力，平安银行采用仿真环境支持验证能力。仿真环境部署在生产数据中心，由运维团队管理建设，技术标准参照生产环境，有隔离措施防止数据污染，具备生产同等可观测能力。云底座能力赋能仿真环境的应用系统快速构建和生产流量复制及回放。仿真环境的建设为混沌工程推广提供了坚实支撑。在互联网行业，也有领先企业在生产环境开展混沌工程，平安银行运维团队考虑到金融行业对生产系统稳定和数据安全的高标准、严要求，采取了相对稳妥的仿真环境策略，仅在生产环境进行小范围可控条件下的试点。

  混沌工程规划的第二个关键点是生产系统应用画像能力建设。通过CMDB和应用访问动态拓扑等生产环境真实数据来构建某个业务系统对IaaS层、PaaS层、关联系统和外部合作方调用的相关性和依赖性，形成应用画像，进而匹配混沌工程的案例库，自动化构建针对该系统或业务场景相关系统群的混沌工程验证方案（如图2所示）。

  未来，平安银行将依托于云原生转型提供的云底座技术能力，从混沌工程组织形式和制度建设等方面持续推进，做到有规范、有组织、常态化运行，持续沉淀故障库、红蓝对抗演习。从系统故障容忍能力和团队应急能力两方面提升生产运行质量，保障云原生转型战略行稳致远。