TICA 2019 工行金融业务稳定性验收实践

阿里QA导读：作为经济核心，金融业务对高质量的要求和挑战非常大，业务稳定、安全又是重中之重。工行软件开发中心杨卓俊老师为我们介绍，如何守护工行金融业务的稳定性。

我是来自工商银行软件开发中心的杨卓俊，非常开心有机会来到现场跟大家分享一下工商银行在金融业务稳定性验收的实践。我团队负责工行和中心内部的安全、性能、功能性测试的相关工具研发及相关的质量守护。

我从四个方面进行演讲：1.金融业务特性；2.测试方案设计；3.测试平台建设；4.未来展望。
[h1]1 金融业务特性千里之堤溃于蚁穴[/h1]

第一块是金融业务特性。我在这里写了“千里之堤溃于蚁穴”，前一段时间支付宝有20分钟的抖动，大家会发现网上有什么言论？有一些段子说花呗是不是不用还了？这是大家可以觉得有意思的，大家网上纷纷议论是不是你的哪些方面技术上有挖掘，有的吃瓜群众也会说我花呗不用还，大家有一系列的探讨。但是大家有没有想过中国整个银行业，如果说有一天工商银行无法取钱了，大家会是一种什么反应？所以金融业务有其必然性，银行业在整个稳定性包括相关业务严谨性上的要求更高，大家知道工行就是一个大象，随着我们现在互联网金融包括在座可能有支付宝、蚂蚁金服同事，互联网金融不断发展，传统的银行除了社会稳定、监管履职和信誉保障之外，我们还要在人工智能、区块链等方面不断深化。但往往船越大，调头越难，所以我们质量的要求更高。
[h1]2 测试方案设计线上集市防堵策略如何构建？[/h1]

我们怎么做这件事情？天将降大任于斯人也，我们怎么做方案设计？我们还是做稳定性测试，就是要通过系统加载给予一定的业务压力，让系统持续一段时间（一般有7×24小时），检测系统是否能够稳定的一种测试方法，其实蕴含的内容非常多，简单来讲有三点：

上线前，我知道很多互联网公司同事会做大量线上测试，但是银行业内部更重要的是内部的线下测试，线下测试能否把大部分的代码行为问题全部解决掉？
我们也会做相对应的线上测试，我的线上的机器、平台的容量、各方面的东西能否支撑整个业务的发展？
会不会有一些异常？大家知道云原生是非常火爆的概念，基础设施不像以前IBM大型机那么稳定，我们现在底层用的机器是虚拟机，可能底层还有一些IaaS。这些不稳定因素对系统会造成什么影响？我们的系统能否对这些问题进行容错？这是我们需要考虑的问题。

我行对整个稳定性测试做了一定的测试方法，比如说线下会做性能测试、容量测试、混沌注入，比如网络出现丢包或者相关的情况，是否使系统保持正常？这些链路完成、保障的情况下，我们会做生产的业务演练，比如说双11高峰流量演练、波动流量演练和线上混沌注入，最终达到业务稳定性测试的多场景和业务行为的测试。

谈到稳定性测试，我们会讲到混沌相关的前提，即我们的可靠。其实我们对稳定性在可靠性上做了拆分，大家对可靠性的理解，我们自己会分为三层：

一是系统层，即容器和操作系统、网络、磁盘、数据库、中间件等和应用代码不发生关系的组件，这些组件意味着你的应用在上面跑着，但这些组件一旦出现问题，上面跑起来就比较麻烦。我们要考虑的是系统层的东西能否在它出现问题的时候，我们在我们的应用编码高可用方面进行架构的思考和设计，以支撑99.99999%的要求？
第二层是我们的应用层，大家做编程有知道有线程连接、队列、交互等等，这些东西是否能做到完美的互通，不会说我在手机上说工商银行我要取一百元，不会说业务繁忙不给取。
第三层是业务处理，因为账务包括你的钱对大家非常敏感，所以业务一致性在所有的环节不可容错，金融业务就不能容错我有一百万你就要还我一百万，你不能给我一万，当然你给我一千万，我很开心。

[h1]3 测试平台建设罗马不是一天建成的[/h1]

我们如何支撑上面所说的三点内容？我们构建了整个平的建设，当然罗马不是一天建成的。这是我们整个稳定性的测试体系，因为我们团队除了稳定性和性能方面，我们还做了一些相关的安全上的问。大家也知道现在互联网的安全是随着我们互联网、区块链包括人工智能、云平台的发展，它的安全变得非常重要。这一块不是我们的重点，我今天主要对稳定性测试的体系，给大家做一个介绍。如果大家对安全感兴趣，也可以私下跟我交流。

针对我们的稳定性，其实大家可以看到解决一项问题，我们首先要发现的是我们的难点在哪里、我们的目标是哪里。稳定性这件事情最大的问题是对于普通的测试人员来说，它的技术难度有点高，分布的问题比较广。比如任何一个很小角落的问题，都会产生系统性的风险。第三点是问题影响范围非常大、影响面非常大，如果一旦出现系统层的问题，意味着你在一整套系统上发生了问题，就没办法进行服务。我们会在整个设计、编码、测试和生产运行阶段都进行相对应的工作，来保证第一步，就是在设计阶段整个架构的OK，在编码阶段会进行静态扫描、白盒检查来确保案例的完备。在测试阶段，会做代码级包括全流程、全场景、全链路的测试，包括压测、混沌，在生产上会进行监控。左边一行是支撑我们整个体系的工具，右边也有一些相对应的管理体系，比如要进行评审、回顾和问题的反思，来进行整个工作。

我们2015年开始建了体系，首先完成了数据库的监控平台，对所有的数据库层的Mysql趋势进行分析，去挖掘到这个Mysql刚开始可能就这么慢，但是什么时候慢到一定程度，可能会对我的系统服务造成一定影响。2016年我们做了端到端的全端的性能监控，了解用户侧体会到的感觉是怎样的，就是大家通过手机银行做一些交费或者支付交易的时候，这个速度是否够快？是否给大家造成体验上的不好？2017年开始我们搭建性能测试云平台来支撑整体的全链路压测工作，2018年建立性能诊断，包括今年也在做混沌平台，未来可能和AI都有关系。

这是我们整个数据库性能监控平台的工具，它主要是对数据库性能监控视图的采集，去动态分析整个数据库的Mysql的情况，它能够把包括数据库端的很多问题挖掘出来。这一套不仅是应用在测试环境，可能整个生产的环境都会使用，对我们整个线上和线下的Mysql进行统一的分析和解决相关的问题。

这一块是我们整个架构的部署。我们会统一有一个集中的中心，对线上和线下的性能的Sql进行分析，进行线上线下的比对，以解决线下相对应的数据和环境的差别和产生的影响，能够更准确地分析Mysql在线上的表现。

这一块是我们的前端性监控工具，我们通过在客户端搭建agent，去回收相对应的前端的请求级的数据，不仅能获取到更接近用户真实体验的新的数据，而且也能够更加精准定位性能的瓶颈，实现具体到请求级的性能分析，其实我们也用了大数据相关的技术做一些数据清洗，最终获得相对应的性能指标。

这一块是我们的筋斗云性能测试云平台，其实它使用了容器化的技术，来实现性能测试压力的动态生成，来支撑筋斗云开展一定的测试，用Master16节点使整个性能测试压力和流量无限提供，因为它是通过分布式的架构可以进行弹性伸缩。

我们的平台有一些特点，比如说它不需要像以前传统的性能测试的时候安装介质，我直接在线上的平台就可以进行测试；第二支持脚本的自动生成，大家可能只要配置一些个性化的数据流，它就能自动帮大家生成一些测试所用的脚本，支持测试结果的自主查验，支持百万级压力一键发起和生产流量模拟复制。比如说双11中，大家会发现一般都是一下子上去了，然后又下来，这些流量特点对你的模拟有比较高的要求。

这是我们的性能诊断平台。其实我们除了在行业常用的JAVA和Oracle等传统数据库，其JAVA最大的问题是很多时候的问题隐藏比较深，没有办法通过短时间的问题，比如说有一些问题是小概率的内存泄露，可能它需要8-10个小时才能解决。所以性能的监控比较重要，这是使用了angnt的技术实现服务端的监控。

这是我们混沌测试平台。现在业界做可靠性测试也做的比较多，比如我们发现特别多的是以前早几年支付宝的网络被挖断了，怎么办？或者说我们的服务器的磁盘出现了一些异常，甚至我以前遇到的问题是有一次我们到线下进行问题排查，会发现我也快捷支付的应用系统说跑着跑着系统速度急剧下降，基本上跌到0，我们觉得很奇怪，信号正常、代码没有改，怎么会发现这样的问题。我们通过一系列的琢磨，发现数据库跑着就出现等待的事件，进一步分析就发现是硬件服务器的电压不稳，跑久了电压一波动，服务器性能就产生影响。所以一系列的奇怪的异常，我们要通过线下或者线上的异常模拟或异常的红蓝攻防去验证这些方面。一方面是保证我们的系统能够支撑这些能力，另一方面是开发人员需要有这些能力，在很快的时间内定位问题并把它解决，以达到所谓的6个9的要求。

这一块是用了一些混沌相对应的介质，通过angnt和自建码技术和开源，厂商包括阿里也提供了一些方法，来实现整个工作的开展。当然我们做这些事情的时候，因为范围比较广，所以我们也会封装易用性更高的平台，方便我们的测试团队去使用。
[h1]4 未来展望 AI?[/h1]

最后畅想一下未来。之前讲的很多东西在我们实践过程中，就会发现现在在测试领域，其实我年初包括年终都会听一些大会，大家都说狼来了，大家发现测试领域的效能是否能跟上研发的节奏？提出了一些灵活的探讨，甚至有一些领域也会问我们这个领域0测试行不行？所以这些东西对我们来说是一个过程。在未来，大家也会担心AI是否会替代测试人员的工作？其实我个人认为不是的。其实AI可方便我们的工作，但是我们还有很多事情要做，比如说我们在做一些AI的时候，我们最近也在思考我们在做一些稳定性测试的时候，我们现在还依赖于我们生成一些脚本，我们能否通过线上的流量自动获取我们需要测试的请求，这些请求又能通过我们人工智能的算法自动进行膨胀，达到我们的业务场景的自动生成，能够更广阔地覆盖相对应的面？另外是我们一些的分析和监控的经验，这些个人的经验中，比如我举到的电压不稳或者内存等其他的问题，我们能否通过人工智能的方式自动发现问题，因为人的能力是有限的，甚至有一些问题是程序报了控制异常，日志写的特别不好，没有告诉你哪一行是控制异常，所以最后非常痛苦，最后发现奇葩的是有一个数据库的结构返回一个级的时候，当其他一个地方出现问题的时候，两边交叉出现一个控制异常，而且两边都判空。所以是否可以通过人工智能机器学习的方式，能够帮助大家解决，并且进行线上线下的分析。还有测试桌面支撑向数据计算支撑，就是我们的工作能否可量化、能够覆盖多少，这些覆盖情况是否合理，能否保障线上的安全，这些东西是否有数据的度量？我们自己的主要思考是这样的。

今天讲的比较快，因为我们团队除了稳定性这一块，可能还在安全、可靠性上都有研究，时间有限，后面还有很多精彩的演讲，所以可能讲的快一些。如果大家线下有什么想要交流的，也可以私下跟我做交流。

谢谢大家！

关注「阿里巴巴技术质量」阅读更多