1 案例场景

1.1 网络故障引发生产事件

某银行在今年7月10日9：00至11：00，客服中心电话爆满，反映的问题是网上银行、手机银行等重要信息系统无法使用，经过信息科技部紧急排查发现，网上银行、手机银行等系统调用的OTP（动态验证码系统）无响应造成。

最后通过增加一台备用服务器，该问题才得以解决。

按照监管要求，重要信息系统停止服务半小时以上，属于重要事件，该事件持续达2小时，严重程度较高。事后该银行按事件的处理流程，在2月18日完成了分析，归结原因为网络问题导致的服务响应超时。解决办法为增加网络监控手段，增加备用服务器紧急补充预案。

• OTP系统是什么？

OTP（动态验证码系统），是对外提供短信验证服务，通常应用于认证、转账等重要交易中。

• 影响范围

网上银行、手机银行、企业微信、自助终端等对客服务系统。由于部分系统属于重要信息系统级别，因此该系统所引发的事件，也应该被列入到重要信息系统当中。

1.2 高管层的担忧

从原因分析的角度，属于年底交易量大，流量激增导致，属于可以解释的现象。但影响到信息系统稳定性的原因，除了网络方面，还会有哪些？主机、硬盘、内存、数据库、中间件等等，是否也会不定期的引发相关问题。

2 中小银行生产事件概述

这几年去多家银行做检查，因为各类基础设施故障、中间件故障等导致的风险事件屡见不鲜，对于这些问题，我们做了一个大概的统计分析，以某中小银行（资产1000亿以下）为例：

2019~2020年，共2447条故障，其中因为基础设施等造成的故障，1466条，占比59.9%。
其中，网络相关的故障337条，占比13.8%。
容量相关的故障441条，占比18%。
主机设备相关的故障119条，占比4.9%。

2.1 故障场景清单

2.2 有没有技术手段来规避

在系统研发的过程中，会有多轮测试用来规避生产问题出现，但无论功能测试还是非功能测试，都很难对基础资源突发问题进行预判，所以很多银行更多做法是加强监控手段，发现问题及时解决。通常将这类事件归为业务连续性的预案不充分，给出一些管理方面的建议。那么，有没有技术手段来规避相关风险和事件，给管理层增加一份的信心。

答案是肯定的，这里就要介绍一个概念：混沌工程。

3 混沌工程

3.1 混沌工程定义

混沌工程，是2010年由 NetFlix 提出的，他们建立了Chaos Monkey工具，主要用于分布式系统的故障模拟实验中，目的是建立系统抵御生产环境中失控条件的能力，提升团队信心。在国内，阿里巴巴、字节跳动、工商银行等头部的企业相继开始应用和实践。国内很多大型信息系统，所采用的分布式架构，动辄上百台服务器。很难预知小小的故障会带来哪些影响，混沌工程是一个很好的尝试。

3.2 混沌工程各类工具清单

Chaos monkey
Chaos Toolkit
Chaos Mesh
Kube-monkey
Litmus
Toxiproxy
Pumba
Byte-monkey
Chaos blade

3.3 阿里巴巴 ChaosBlade

ChaosBlade 是一款遵循混沌工程实验原理，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具，可实现底层故障的注入，特点是操作简洁、无侵入、扩展性强。

ChaosBlade 基于 Apache License v2.0 开源协议，目前有 chaosblade 和 chaosblade-exe-jvm 两个仓库。

chaosblade 包含 CLI 和使用 Golang 实现的基础资源、容器相关的混沌实验实施执行模块。chaosblade-exe-jvm 是对运行在 JVM 上的应用实施混沌实验的执行器。

3.4 ChaosBlade可以解决的问题

3.4.1 监控告警的时效性

通过对系统注入故障，验证监控指标是否准确，监控维度是否完善，告警阈值是否合理，告警是否快速，告警接收人是否正确，通知渠道是否可用等，提升监控告警的准确和时效性。

3.4.2 应急响应的及时性

通过故障突袭，随机对系统注入故障，考察相关人员对问题的应急能力，以及问题上报、处理流程是否合理，达到以战养战，锻炼人定位与解决问题的能力。

3.4.3 容错容灾的健壮性

通过模拟调用延迟、服务不可用、机器资源满载等，查看发生故障的节点或实例是否被自动隔离、下线，流量调度是否正确，预案是否有效，同时观察系统整体的 QPS 或 RT 是否受影响。在此基础上可以缓慢增加故障节点范围，验证上游服务限流降级、熔断等是否有效。最终故障节点增加到请求服务超时，估算系统容错红线，衡量系统容错能力。

通过模拟上层资源负载，验证调度系统的有效性；模拟依赖的分布式存储不可用，验证系统的容错能力；模拟调度节点不可用，测试调度任务是否自动迁移到可用节点；模拟主备节点故障，测试主备切换是否正常。

3.5 ChaosBlade的特点

3.5.1 场景丰富度高

ChaosBlade 支持的混沌实验场景不仅覆盖基础资源，如 CPU 满载、磁盘 IO 高、网络延迟等，还包括运行在 JVM 上的应用实验场景，如 Dubbo 调用超时和调用异常、指定方法延迟或抛异常以及返回特定值等，同时涉及容器相关的实验，如杀容器、杀 Pod。后续会持续的增加实验场景。

3.5.2 使用简洁，易于理解

ChaosBlade 通过 CLI 方式执行，具有友好的命令提示功能，可以简单快速的上手使用。命令的书写遵循阿里巴巴集团内多年故障测试和演练实践抽象出的故障注入模型，层次清晰，易于阅读和理解，降低了混沌工程实施的门槛。

有详细的中文文档作为参考：

中文版文档：https://chaosblade-io.gitbook.io/chaosblade-help-zh-cn/blade

目录结构清晰：

以创建 CPU 负载的混沌实验为例：

执行命令为：blade create cpu load [flags]

执行参数为：

案例参考：

3.5.3 场景扩展方便

所有的 ChaosBlade 实验执行器同样遵循上述提到的故障注入模型，使实验场景模型统一，便于开发和维护。模型本身通俗易懂，学习成本低，可以依据模型方便快捷的扩展更多的混沌实验场景。比如：支持服务器CPU满载实验的同时，也支持Docker容器、Kubernetes等满载实验。

4 网络故障场景模拟Demo

4.1 下载程序包

https://github.com/chaosblade-io/chaosblade/blob/master/README_CN.md

4.2 ChaosBlade网络故障实验

4.2.1 介绍

可以指定网卡、本地端口、远程端口、目标 IP 延迟。需要特别注意，如果不指定端口、ip 参数，而是整个网卡延迟，切记要添加 —timeout 参数或者 —exclude-port 参数，前者是指定运行时间，自动停止销毁实验，后者是指定排除掉的延迟端口，两者都是防止因延迟时间设置太长，造成机器无法连接的情况，如果真实发生此问题，重启机器即可恢复。

本地端口和远程端口之间是或的关系，即这两个端口都会发生延迟，只要指定了本地端口或者远程端口，无需指定需要排除的端口。端口与 IP 之间是与的关系，即指定的 IP:PORT 发生延迟。

网络延迟场景主要验证网络异常的情况下，系统的自我容错能力。

4.2.2 参数

• --destination-ip string 目标 IP. 支持通过子网掩码来指定一个网段的IP地址, 例如 192.168.1.0/24. 则 192.168.1.0~192.168.1.255 都生效。你也可以指定固定的 IP，如 192.168.1.1 或者 192.168.1.1/32，也可以通过都号分隔多个参数，例如 192.168.1.1，192.168.2.1。

• --exclude-port string 排除掉的端口，默认会忽略掉通信的对端端口，目的是保留通信可用。可以指定多个，使用逗号分隔或者连接符表示范围，例如 22,8000 或者 8000-8010。这个参数不能与 —local-port 或者 —remote-port 参数一起使用

• --exclude-ip string  排除受影响的 IP，支持通过子网掩码来指定一个网段的IP地址, 例如 192.168.1.0/24. 则 192.168.1.0~192.168.1.255 都生效。你也可以指定固定的 IP，如 192.168.1.1 或者 192.168.1.1/32，也可以通过都号分隔多个参数，例如 192.168.1.1，192.168.2.1。

• --interface string  网卡设备，例如 eth0 (必要参数)

• --local-port string 本地端口，一般是本机暴露服务的端口。可以指定多个，使用逗号分隔或者连接符表示范围，例如 80,8000-8080

• --offset string 延迟时间上下浮动的值, 单位是毫秒

• --remote-port string远程端口，一般是要访问的外部暴露服务的端口。可以指定多个，使用逗号分隔或者连接符表示范围，例如 80,8000-8080

• --time string延迟时间，单位是毫秒 (必要参数)

• --force强制覆盖已有的 tc 规则，请务必在明确之前的规则可覆盖的情况下使用

• --ignore-peer-port针对添加 —exclude-port 参数，报 ss 命令找不到的情况下使用，忽略排除端口

• --timeout string设定运行时长，单位是秒，通用参数

4.2.3 案例

•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  
•  

# 访问本机 8080 和 8081 端口延迟 3 秒，延迟时间上下浮动 1 秒blade create network delay --time 3000 --offset 1000 --interface eth0 --local-port 8080,8081
{"code":200,"success":true,"result":"9b4aa9fabe073624"}
# 可以在另一台相同网络内的机器通过 telnet 命令验证，即 telnet xxx.xxx.xxx.xxx 8080# 销毁实验blade destroy 9b4aa9fabe073624
# 本机访问外部 14.215.177.39 机器（ping www.baidu.com 获取到的 IP）80 端口延迟 3 秒blade create network delay --time 3000 --interface eth0 --remote-port 80 --destination-ip 14.215.177.39
# 可在本机通过 telnet 14.215.177.39 80 命令验证# 对整个网卡 eth0 做 5 秒延迟，排除 22 和 8000到8080 端口blade create network delay --time 5000 --interface eth0 --exclude-port 22,8000-8080
# 会发现 22 端口和 8000 到 8080 端口不受影响，可在另一台相同网络内的机器通过分别 telnet xxx.xxx.xxx.xxx 8080 和 telnet xxx.xxx.xxx.xxx 8081 进行测试

4.3 Demo演示

•  
•  

# eth0发往远端9080端口的数据包将延迟3秒，浮动1秒，持续120秒blade create network loss --time 3000 --offset 1000 --interface eth0 --timeout 120 --local-port 9080

5 业界的案例

5.1 工商银行

2019年3月阿里巴巴开源混沌工程，2019年9月工商银行完成“混沌工程故障演练平台”建设，在开发中心、业务研发中心对部分业务线进行试点，2020年7月，项目办制定全行推广计划。

基于 ChaosBlade 进行了二次开发，扩展了 ChaosBlade 的故障注入能力，可视化界面进行操作。

六大类一百多种测试案例，涵盖了应用层、数据库层、平台层、中间件层、路由层、缓存层等主流的应用高可用测试场景。

工行混沌工程故障演练平台，将服务器系统故障和 JVM 故障这两大类作为主要切入点，基于工行混沌工程故障演练平台高可用专家库，率先在行内快捷支付、聚合支付等一些重点业务线进行落地试点，通过注入上下游调用异常、线程池异常、磁盘 IO 夯等多种类型的故障，在各业务线的平台层、消息中间件层、应用层、数据库层、路由层均发现了一些传统测试难以发现的高可用设计等方面的问题。例如：通过对支付类交易实施混沌实验，模拟双活应用的单园区网络断连然后再恢复，发现该过程中支付链路存在一些底层故障场景下交易失败的架构设计缺陷，并在投入生产之前对支付系统架构进行了重新设计和升级。截止目前全行已对七十多各应用开展常态化故障演练测试，共实施故障演练七千余次，发现并解决了一百多个应用系统层面的高可用问题，有效避免了在生产环境触发这些问题。

6 中小银行实践混沌工程的路径建议

6.1 现状分析

6.1.1 事件分析

我们每次去一家银行来看管理方面存在哪些风险，首先是来看以往生产中出现过哪些事件和问题，对问题进行场景复现和原因排查，一是看解决问题问题分析是否到位、二是看问题解决是否彻底、三是看是否在出现同类问题。往往在事件分析方面，多数银行做的并不到位。在功能性相关的问题较多原因是归纳为为测试不到位或者是代码问题。资源类相关的问题则以业务连续性相关的应急预案完善作为整改方向。

• 同类问题反复出现；

• 造成较大生产影响；

• 监管提示或同业风险参考。

6.1.2 系统架构分析

微服务架构：这几年基于微服务的分布式核心系统逐步替代传统的单体架构系统，业务层面可以有效拓展，对应的管理与运维手段是否跟上，需要思考。

单体架构：如果依旧是单体架构，基础资源问题的出现更为致命，如何模拟和预知风险，是单体架构核心的一大课题。之前有过一些资产万亿的城商行，不仅整体架构传统，采用的技术语言和运维手段也很传统。能否在数字化浪潮下能够屹立不倒，真正发挥出“稳后台”的价值，很堪忧。

双机热备：是否健全。

系统间交互模式：ESB、数据交换平台。逐步成为银行系统间的中转站，这相当于微服务架构的消息总线和交换路由，容不得半点差错。如果没有采用混沌工程的情况下，对这种中转类系统，模拟超时、超载等情况，也是对各类系统的一种检测。

6.2 情景模拟

6.2.1 有混沌工程工具

可以在UAT或准生产环境中做测试，如果实在不满足，则把爆炸半径足够缩小，及其谨慎的在生产中进行模拟。

6.2.2 无混沌工程工具

可以尝试利用系统间的交互模式进行模拟，比如：加密平台、ESB企业消息服务总线、数据交换平台等。用延时5秒、10秒等方式做测试，看消费方是否能够有容错能力。避免因为服务方的超时，而消费方无法再次发出请求。导致需要紧急生产变更。

中小银行的IT系统建设已经达到了较大的规模，通常资产规模在1000亿左右的中小银行，系统数量多达200套，包括：核心、信贷、中间业务、票据、资金管理，同时对应提供交易系统衔接的有ESB、加密平台、数据交换平台、数据仓库等。从整体来说，银行的系统从整体角度看，与分布式系统相似，所以可以借鉴混沌工程的思维，以准生产环境为对象，对系统间接口的传输、报文通讯、文件交换等进行故障模拟，发现潜在问题。