在相当长一段时间内,互联网金融占据了大众的注意力,吸引了足够多的眼球。的确,互联网金融使得金融业务通过与互联网技术的结合拥有了更大的发展空间。但是,想要了解金融领域业务与新技术结合的全貌,就离不开对传统金融的探究。
InfoQ 特别策划“科技创新为传统金融带来哪些变革新契机?”选题,以深度访谈、案例展示、评论分析等多种形式,揭示传统金融行业采用哪些科技创新手段实现业务发展和变革,让更多的人了解到传统金融科技创新的真正实力,如实展现金融科技创新发展全貌。
为此,我们采访到了工行银行测试部高级经理 - 李雁南,就工行在性能测试方面所遇到的问题,以及采用了哪些解决方案为主线索,来了解工行在架构转型和构建性能监控体系的上的收获。
性能测试体系的遗留问题
从事长时间的性能测试工作,肯定会有印象深刻的大事件可以分享出来。对此,李雁南说,感触较多的是 IT 架构转型对于性能测试既有的工作模式和方法的改变。过去两年间,工行也在持续有序的推动内部 IT 架构转型,变化主要体现在以下三个方面:
- 分布式架构的应用开始出现,部分传统的竖井式应用向着分布式迁移;
- 软件产品的种类更加丰富和多元化,大量开源产品和技术被应用;
- 应用系统对于性能容量的要求越来越高。
牵一发而动全身,上述变化也给性能测试工作本身带来了非常大的挑战,具体可以分为三点:
- 在性能测试案例设计过程中,非常重要的一项工作是针对应用架构预估的性能瓶颈设计测试场景和案例,这就对测试人员的技术水平和经验有很高的要求。而面对分布式架构这个全新的领域,需要慢慢的去积累经验,从理论基础到技术方法都需要重新学习和实践。
- 新的架构和软件产品的使用,迫使我们要更多的关注架构和软件本身的性能容量,原有性能测试工作的范围扩大了,测试方法和工具也需要不断改变。
- 测试与生产的资源差异越来越大,测试环境资源有限,尤其针对分布式架构问题时,我们只能利用较小的测试集群规模去评估投产后表现,对于性能容量的评估难度逐渐加大。
工行的测试系统架构从传统到互联网 + 的演变过程
其实对于这个问题,可以引用之前两位工行领导所发表的文章里的话来解释。谷澍行长 2017 年在《金融电子化》刊物上发表了专题文章,详细解释了工行架构转型的目标和路线,概括来说就是工行科技系统正在积极推动架构转型,但不是盲目转型,而是遵循“优化存量、管好增量”的既定方针,打造传统集中式和分布式有机融合的 IT 系统。
数据中心(北京)毛卫东总经理发表过题为《银行业软件测试的思考及工行实践》的文章中清晰阐述了工行一体化、标准化和自动化的软件测试战略,将测试中心打造成一个能为银行业金融机构抵御风险、提高业务风控能力、强化业务流程的关键部门。从这两位的话语中足见工行对于架构转型的重视程度。
不仅是工行,国内传统金融机构在 IT 方面基本上都存在一些问题,家家有本难念的经,各家的问题各不相同,比较共性的问题还是 IT 系统架构转型的压力。国内金融机构普遍都有着比较长的 IT 建设历史,系统内部存在大量传统架构的应用,这些应用很多都面临着架构转型的挑战。如何在保证系统稳定的前提下,通过架构优化提升对于业务创新的支撑能力,这不仅仅是技术上需要考虑的问题,也是业务部门一直在关注的问题,既需要宏观的视野与魄力,也需要微观的针对每一个技术方案的严谨的推敲论证,其中的难度可想而知。
性能测试的步骤如何跟上性能测试的需求?
记得有一次,李雁南在演讲中提到,性能测试的步骤跟不上性能测试的需求,那么对于这一点,工行有什么样的解决方法?是否借助外力来解决这个事情?
李雁南说,性能测试活动跟不上性能测试需求的增长,主要有以下两个原因:1、现有的性能测试成本偏高;2、性能测试需求过多。工行测试团队针对性的做了一些优化:
- 优化性能测试流程:从需求完整性、测试合理性、验收标准性三个方面对性能测试流程进行了优化。总而言之,面对性能测试需求增长的压力,测试团队不会去减少需求,而是要增加需求,覆盖所有的测试项目。通过构建性能测试流程管理平台和监控体系,来对需求进行准确的评估,更加合理的制定测试方案,更加智能的去发现和定位问题,通过对日常功能测试的监控给出性能评估结论。
- 建设平台监控体系:平台监控体系建成之后,软件性能监控覆盖面更大,指标更加丰富,结果更加标准化,评估过程更加自动化,从而降低了性能测试工作的成本。测试人员的精力可以从日常的测试执行中释放出来,投入到测试设计和监控模型优化这种高回报的工作中。
- 重视对架构的性能测试:工行测试团队的工作重心更加偏重对架构的性能容量评估,因为一个好的架构肯定会为应用提供更强大的性能容量支撑,从一开始就去搞清楚架构能够支撑多大的压力、性能瓶颈在哪儿、通过优化和扩容能够获得多少提升,搞清楚这些问题会节约很多以后性能测试的工作量。
互联网环境下的新技术
在互联网环境的冲击下,我们很想知道,工行采纳了时下互联网科技里的哪些先进技术,同时,还有哪些技术方面需要不断精进的?
李雁南说,工行在分布式架构、云计算、大数据和区块链等技术领域都有深入的研究和成功的实践。技术的进步是永不停息的,新技术会催生出新的需求,并产生新的问题,而解决这些问题的技术里,没有最好的技术,只有最合适的技术。正如工行最近在规划的关于架构目标蓝图,目的就是在技术选择上提供尽可能详细的指导意见。
关于测试监控的创新
经过多年的发展,工行在 IT 技术上,尤其是从测试监控 1.0 到测试监控 X.0 这一块,也有了一些创新点,以及较为成功的案例。
有别于生产监控,测试监控的首要目标是发现应用版本中的性能问题,测试团队主要利用根因分析模型,将测试人员分析问题的过程经常遇到的固化的问题导入模型中集中处理,而这个模型来源是根据过往生产性能问题和典型测试问题的分析和总结。除此之外,面对巨量的监控数据,我们也在尝试利用数据分析的方法,对指标增长趋势等指标进行分析,预判问题的发生。最近一段时间,我们就发现了几个连接不释放、数据清理策略不合理的问题,这些问题采用传统的性能测试方法是很难被发现的,但是通过这种简单的趋势分析模型,很容易就会被找到。
关于趋势分析模型,这里李雁南老师也做了分析,根据测试工作的经验,性能指标值的持续增长必然会在未来引发性能问题,参考了一个简单的一次线性拟合模型,对监控系统采集的操作系统的资源使用率、网络连接数、数据库的表数据量、语句执行时间、语句的 cost、session 数量等指标进行了分析,找出那些在过去至少 3 个采样周期中出现数值持续增长的对象,并对拟合度大于 90% 的对象进行深入分析。这个简单的模型帮助测试团队发现了很多潜在的性能隐患,比如没有释放连接、数据清理策略不合理、语句执行计划效率差等,查找问题的命中率非常高。
悬而未决的问题
到目前为止,很多传统金融企业都有很多遗留问题没有解决,那么工行还有哪些现存的问题亟待解决的呢?
“坦率的说,目前还有很多问题没有解决。”李雁南回答说。
对于监控数据的分析处理,目前工行测试团队做的还比较简单。监控数据绝大部分都是结构化的数据,适合做数据分析和挖掘。目前,团队也计划着借助一些大数据的技术和方法,来处理这些巨量的监控数据。
2016 年,工行 POC 了一款 APM 产品,帮助团队从业务交易流程上将各个监控节点串联起来,解决了监控数据孤岛的问题,也弥补了工行整个中间件监控的短板。目前这款 APM 产品正在大力推广阶段。
寄语
对于传统金融系统的未来,无需多言,肯定是会向着更加智能化的道路上前进。IT 技术日新月异,变化超出想象。以后的 IT 系统的发展会直接决定金融机构的发展,IT 人员的价值也会获得更大的体现。
感谢 **薛梁 ** 对本文的策划和审校。
评论