天天看点

技术应用 | 云原生时代全面质量保障体系的探索与实践

作者:金融电子化

随着金融科技的飞速发展,证券行业也面临着新的机遇和挑战。云计算、人工智能等前沿技术的引入,为行业的创新和发展带来了更多可能性。然而,信息系统安全风险事件的发生提醒我们,随着科技应用的深入,系统稳定性和安全性的保障变得尤为重要。云原生技术的应用提升了证券行业软件交付效率,而快速迭代导致系统一直处于不稳定状态,产品交付质量很难保障。基于全面质量管理的思想,建立稳定、高可用性的系统架构,通过持续测试、持续安全保障、混沌工程体系等方法加强风险管理和业务连续性管理,确保业务系统稳定运行是解决以上问题的关键路径。

技术应用 | 云原生时代全面质量保障体系的探索与实践

中泰证券股份有限公司科技研发部 副总经理 张永启

云原生时代质量管理困难与挑战

从1986年至今证券行业经历了30多年的发展,这30年也是证券行业数字化发展的30年。2021年10月在北京金融街论坛上证监会科技监管局组织相关单位编制的《证券期货业科技发展“十四五”规划》正式发布,内容中重点强调了紧扣“推进行业数字化转型发展”与“数据让监管更加智慧”两大主题。当前无论是证券企业自身发展的需要还是监管的要求,证券行业数字化转型工作已经被提到了前所未有的高度。

随着云原生技术的快速发展,我们的系统架构及研发模式也发生了重大改变,例如基础设施从传统的小机、传统X86架构逐步转变为以容器+K8S为核心的云原生基础设施,应用架构也逐步从单体巨石应用转变为分布式微服务架构,系统运营模式也从单机房单中心发展为多地多中心的部署架构,交付模式也从传统的项目制瀑布式开发转为敏捷迭代开发。

在传统架构向云原生转型过程中面临着一系列的挑战。例如,频繁迭代带来的系统稳定性难以保障的问题;证券业务越来越丰富,测试场景越来越复杂,测试成本越来越高的问题;微服务分布式架构广泛应用,带来的系统群服务治理复杂度提升的问题;线上出现故障,问题定位难、恢复时间长的问题;混合云架构导致的开发、测试、生产环境连通性,以及发布管理问题。面对云原生转型过程中的诸多挑战,如何构建研发过程全面质量管理保障体系变得至关重要。

云原生时代的质量保障工作不再是金融科技团队某个角色的工作职责,而是需要研发、测试、运维甚至非研发体系的业务人员协同的一项跨团队协同工作,如图1所示。为此我们尝试制定了贯穿软件生命周期的“全面质量保障体系”解决方案。

技术应用 | 云原生时代全面质量保障体系的探索与实践

图1 云原生时代质量保障管理职责

全面质量保障技术体系以云原生技术为基石,贯穿整个软件生命周期。在云原生稳定性基础保障的基础上,通过全方面风险预防与发现机制,提前发现与解决系统中可能存在的风险隐患,全面提升系统对业务支持的整体质量。

其中,在云原生稳定性基础保障方面,基于CMDB管理基础设施,构建IaaS、PaaS和SaaS不同层面的可观测体系,并且通过DevOps平台与自动化运维的结合,实现快速、高效和稳定的自动化发布、故障自愈等操作。此外,规范组织内部研发流程,将流程与流水线融合,保障流程规范的落地。可以根据具体的项目和组织情况进行调整和优化,确保流水线能够满足项目和团队实际研发管理的需要。在风险防范与发现方面,全面质量管理思想贯穿整个软件生命周期,并在不同阶段通过工具、流程线与平台相融合,采用自动化的手段发现产品交付过程中的潜在风险,如图2所示。本文主要讨论软件生命周期的质量风险预防与发现,从测试管理、安全管理、混沌工程、预案管理等几个方面展开探讨。

技术应用 | 云原生时代全面质量保障体系的探索与实践

图2 全面质量保障体系解决方案

另外,为了保证解决方案的整体平稳落地,在过程中我们制定了几个原则:解决问题投入最小化,抓核心矛盾,不过度设计;优先为技术人员赋能,然后实现为研发管理服务的工作;能偷懒就偷懒,能机器干的绝对不人干,通过自动化手段降低人员成本;流程规范一定要与流水线设计相结合,不依赖书面的流程规范;工作节点尽量“左移”,能往研发侧转移的尽量“左移”,降低问题解决成本。

全面质量管理的关键方案

全面质量管理作为一套全面完整的解决方案,在传统稳定性保障的基础上,核心能力包括持续测试管理、持续安全管理与混沌工程三方面工作。

1.持续测试管理

持续测试管理是全面质量管理体系中比较核心的一部分,基于DevOps中具体项目的流水线拉通了各角色的互相配合,促进质量管理在各环节的实践落地,切实以质量为出发点,渗透全民质量意识,切实践行“人人为质量负责”,让测试和质量相关工作能扎实在一线被各工种各角色重视并为之付出劳动,如图3所示。

技术应用 | 云原生时代全面质量保障体系的探索与实践

图3 贯穿软件交付过程的持续测试

首先,在持续测试管理方面,要拉通端(需求端)到端(运营端)的流程,在DevOps平台中使我们的流程能够流动起来,从而具备更高的价值,形成需求特性提出到运营数据、用户反馈验证的实验性交付闭环,从而基于实际用户反馈调整计划和需求。

其次,我们实现了测试敏捷化,通过小环节(各阶段测试工作)前置的反馈和度量,推动大环节(各迭代)快速的交付能力,从而建立更好的质量保障。开发阶段将单元测试的能力纳入到流水线中,作为开发提测前的质量门禁;集成阶段将接口测试、UI测试的核心用例基于流水线自动化执行,性能测试支持多种压测策略的实施,基于建立的性能基线发现问题并管理跟踪;验收与发布阶段主要是做好业务验证的问题跟进以及线上运行情况的持续监控。因此,基于单元测试、集成测试、界面测试、人工探索式测试相结合的方式建立了较完善的测试体系,将重复的事情交给机器做,尽可能采用自动化测试的方法提升测试效率、降低测试时间和测试人员成本投入。在敏捷交付的过程中采用自动化回归测试的方法,在双周敏捷迭代中完成重要核心功能的接口、UI自动化回归测试,保证重要核心功能的业务服务连续性。

在持续测试敏捷化方面,重要的几点能力实践如下。

(1)精准测试。精准测试建立在业务功能点(测试用例)和业务代码相互关联的基础之上,获取功能点的覆盖率,进行测试精准覆盖、用例精准推荐、测试缺陷精准定位等。精准测试通过实时感知代码变动,实现代码变动分析,准确定位代码变动范围和变动影响范围,提供深入准确的测试决策分析依据,从而准确确定测试范围。目前我们基于Git-Diff实现了代码Gitcompare和增量代码测试用例覆盖率评估,完成支持行、分支、方法、类等不同粒度的增量覆盖率报告分析,实现精准测试的基础能力建设,极大地提升自动化回归测试的有效性,同时为人工探索式测试聚焦代码变更对业务功能的影响起到了更为精准的辅助作用。

(2)接口自动化。接口自动化包括接口的全生命周期管理与接口的自动化测试,接口管理功能对于不同的研发角色作用不同,开发人员能够利用接口管理功能进行前后端接口调用、多项目接口统一管理、接口调试和多团队协同开发;测试人员能够基于接口管理功能中登记的接口进行简单接口测试、场景化接口测试;运维人员可以基于接口管理功能中登记的接口实现业务监控。接口持续测试提倡尽可能自动化实现,手工测试负责保障质量网的密集度和有效性,自动化测试负责保障测试用例可按需被频繁且高效的执行,自动化测试用例需实现灵活跨环境被执行,自动化测试活动可随时按需开展,并能够帮助价值流快速流转,使测试不再成为研发流程中的显著阻塞环节。基于此,接口自动化与DevOps平台实现无缝对接,研发提测后支持不同测试环境的一键发布/部署,可以自动触发或者测试人员手动一键触发接口自动化的执行,并将测试结果以邮件形式自动发送给相关人员,同时支持测试报告与测试执行日志的在线查看。

(3)UI自动化。UI自动化测通过利用自动化工具模拟用户与软件界面进行交互,它通过模拟用户的点击、输入、滑动等操作,对软件的用户界面进行功能验证和页面性能分析。通过UI自动化持续测试能力建设,快速有效地反馈产品质量问题,UI自动化测试能记录故障发生的日志和截图,减少“人为”因素带来的测试漏测和结果误判,提高了测试的准确性,降低了测试成本。通过UI兼容性自动化测试实现多终端多机型测试,同时基于UI自动化的特性,精确模拟用户操作,对软件进行全面的功能验证和页面性能分析,有助于发现软件中的潜在问题,提高软件质量。

(4)性能自动化。性能自动化测试对于系统容量评估、系统稳定性测试,均具有重要作用。通过性能测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。验证软件系统是否符合用户的性能要求,同时发现软件系统存在的性能瓶颈,最后达到优化系统的目的。

(5)测试左移与右移。传统测试团队的定位主要在负责测试阶段的质量保障,云原生时代测试团队的职责将发生改变,从测试执行团队逐步过渡到测试赋能团队。持续测试的思想也强调不断促进测试往左和往右移动。测试左移是为了提升研发和测试效率与质量,测试不断向左移动,向需求、开发等环节“左移”,将自身自动化测试的能力赋能到研发侧,将自动化测试能力如接口自动化、UI自动化、性能自动化与流水线CI/CD集成。研发人员以极低的成本从DevOps平台上获得自动化测试的相关能力;测试右移是为了不断提高交付的质量和持续改进,测试不断向右移动,向运维运营等环节“右移”,及时获取线上问题和用户反馈,持续优化和改进产品。

2.持续安全管理

通过持续安全管理体系的建设,将安全工作贯穿软件交付的端到端全过程,覆盖组织级通用基础安全工程实践、安全开发过程实践、安全持续交付过程实践,安全运营过程实践。基于成熟度模型和通用安全工具,构建整体DevSecOps解决方案。

DevSecOps基于工具能力,覆盖从需求到上线的软件交付全流程,主要工具能力包括威胁建模、缺陷扫描、开源治理、风险发现和积极防御等能力,其中常用核心原子安全能力包括业务威胁建模、SAST源代码缺陷检测、SCA开源组件检测、镜像安全扫描、DAST动态应用安全测试、IAST交互式安全测试,详细如下。

(1)业务需求威胁建模。为了保证开发的安全,需要将应用威胁发现能力前置到需求分析开发测试环节,将安全工作柔和嵌入软件研发流程中去,从应用生命周期源头上实现对上线应用项目的透明安全。威胁建模通过在立项、需求、设计阶段开展安全需求的分析动作,使得安全工作随项目开始一同开展,将明确的要求下发至项目开发过程中的各类角色。威胁建模通过对业务需求设计、技术架构、业务场景及部署场景的问答分析,并以大量风险知识库做应用风险关联分析的支撑,自动化分析当前业务系统的安全需求,并且结合安全需求管理,明确安全设计规范、开发规范、测试方法。

(2)SAST源代码缺陷检测。静态应用程序安全测试(Static Application Security Testing,SAST)技术通常在编码阶段分析应用程序的源代码或二进制文件的语法、结构、过程、接口等来发现程序代码存在的安全漏洞。SAST又称白盒测试,因其检测问题类型丰富,可精准定位安全漏洞代码,比较容易被程序员接受。

(3)SCA开源组件检测。开源软件的兴起大大提升了开发者的开发速度。但是,开源软件依然有着大量的安全隐患以及许可风险,因此,在整个开发过程中,软件成分的分析就尤为重要。软件成分分析(Software Composition Analysis,SCA)是一种对二进制软件的组成部分进行识别、分析和追踪的技术。企业需要首先明确自己的软件项目中都有哪些开源组件资产,进一步确认是否还在被维护、当前版本是否存在漏洞,以及使用该组件会不会引起许可风险等问题。

(4)IAST交互式安全测试。交互式应用程序安全测试(Interactive Application Security Testing,IAST)相当于DAST和SAST结合的一种互相关联运行时安全检测技术,通过在服务端部署Agent程序,收集、监控Web应用程序运行时函数执行、数据传输,并与扫描器端进行实时交互,高效、准确地识别安全缺陷及漏洞,同时可准确确定漏洞所在的代码文件、行数、函数及参数。IAST的检测效率、精准度较高,并且能准确定位漏洞位置、漏洞信息详细度较高。但是其部署成本略高,需在被测应用进行插桩可能会对应用正常测试运行有一定影响。

(5)DAST动态应用程序安全测试。DAST(动态应用程序安全测试,Dynamic Application Security Testing)技术在测试或运行阶段分析应用程序的动态运行状态,主要是运维阶段被大家熟知的黑盒漏洞扫描技术。它模拟黑客行为对应用程序进行动态攻击,分析应用程序的反应,从而确定该Web应用是否易受攻击。

(6)RASP技术。作为一种新型Web防护手段,RASP(Runtime Application Self-Protection)将保护代码像一剂疫苗注入到应用程序中,与应用程序融为一体,使应用程序具备自我保护能力,结合应用的逻辑及上下文,对访问应用系统的每一段代码进行检测,当应用程序遭受到实际攻击和伤害时,RASP可以实时检测和阻断安全攻击,无需人工干预。RASP技术弥补了传统边界安全防护产品的先天性防护不足,可应对无处不在的应用漏洞与网络威胁,为应用程序提供全生命周期的动态安全保护,但RASP应用的运行对服务器性能有一定影响,导致应用程序性能的一部分下降。

(7)持续安全能力与研发流程结合。传统研发运营安全侧重于在测试及运营阶段,进行安全威胁排除,漏洞修复,更多的是被动式安全防御。面对云原生时代业务需要频繁调整、上线,亟需进行安全左移,在需求、研发阶段便进行安全介入,从源头处降低安全风险,实现主动式安全防御,从而构建覆盖软件应用服务全生命周期的安全体系。

过去,安全性总是由单独的安全团队在开发周期结束时(几乎是事后)添加到软件中,并由单独的质量保证(QA)团队进行测试。随着敏捷的推广和DevOps落地实践,软件开发周期缩短到几周甚至几天,传统的“添加式”安全方法造成了让人无法接受的瓶颈。DevSecOps通过将安全工具能力无缝集成到敏捷和DevOps流程和工具中去,使得安全问题处理起来更加得心应手、速度更快,且成本更低,并且不会将这些问题带入生产环境。安全工具能力与流水线集成解决方案如图4所示。

技术应用 | 云原生时代全面质量保障体系的探索与实践

图4 持续安全管理

通过将安全能力融入到流水线中,使得研发团队能够更加专注业务研发而不需要花更多的精力配合做DevSecOps落地的整改,同时可以结合流水线门禁,避免制品交付过程“带病”流转到下一个环节。

3.混沌工程

混沌工程是一个建立在分布式系统上的实验,通过主动地在生产环境系统中模拟故障,制造出系统异常,支持以可回放、持续性的故障演练验证系统稳定性,提前暴露出潜在问题并进行修复,避免实际运行过程中由于突发故障导致服务不稳定甚至服务不可用。混沌工程的实施基于“分步实施、分级提升”的推广原则,在实施的过程中,可以先基于仿真环境再过渡到生产环境,先演练关键场景再逐步全量业务场景覆盖等原则进行推进。现阶段,推进混沌工程落地的关键具体方案如下。

(1)混沌工程可观测体系的建设。混沌工程演练需要基于监控体系观察演练过程中的各个指标,并判断出系统存在的故障。监控体系的部署基于混合云的部署环境,从上到下对业务应用、基础服务、基础设施,即SaaS、PaaS、IaaS层实施监控。监控系统应用状态监控主要从Exporter、Prometheus、Alertmanager、Grafana等组件收集监控数据,此外,为了更好地监控演练过程中的应用及架构状态,也引入了链路监控和性能监控体系。通过各个Exporter数据采集器收集服务器基础资源监控指标数据、数据库集群监控指标数据、消息队列等中间件集群监控指标数据、应用服务监控指标数据等。具体包括如下。

业务应用:主要包括服务可用性监控(服务、端口是否存在,是否假死)及应用性能监控(应用处理能力,比如交易量、成功率、失败率、响应率、耗时)。

基础服务层:包括各种中间件、Docker容器、云原生平台的性能指标。

基础设施层:监控基础资源的性能情况,CPU(CPU使用率、CPU各核使用率、CPULoad负载)、内存(应用内存、整体内存等)、磁盘IO(读写速率、IOPS、平均等待延时、平均服务延时等)、网络IO(流量、包量、错包、丢包)、连接(各种状态的TCP连接数等)。

(2)混沌演练工具及演练平台能力建设。混沌工程演练平台为混沌工程实施的重要工具,混沌工程平台总体上分为6层,分别是为SRE能力、原子能力、演练能力、感知能力、计划能力和演练平台能力,具体如图5所示。

技术应用 | 云原生时代全面质量保障体系的探索与实践

图5 混沌工程演练平台能力

通过演练平台的建设,能够对多环境进行管理和演练,如虚拟机、物理机或混合云进行演练,同时能够对多服务器类型和操作系统上的应用、中间件进行演练支持。在混沌的推进过程中,往往也采用迭代按计划的方式进行推进,通过平台的演练计划能力能够根据计划按需对平台进行演练。目前,通过原子能力的丰富以及系统功能的完善,使演练平台在日志巡检、故障演练、可靠性测试和红蓝攻防等多方面能够对混沌工程实施更好地推进。

(3)应急预案管理。通过应急预案的实施,能够针对可能出现的各种突发事件或故障,制定一套预防、响应和恢复的策略和流程。同时,将应急能力沉淀到应急预案管理平台上,使组织能够迅速、有效地应对,以减少损失,恢复业务的正常运行。

通过对混沌工程不断地推进实施,对于发现和可能发现的问题做好预案管理,并保留在预案管理平台形成知识库,有利于积累规范化的演练场景及故障处理流程,赋能其他业务快速进行实验和快速应对生产故障,减少演练成本和故障处置时间。

基于混沌工程体系,对关键金融服务进行了稳定性测试,在具体的实施路线上依照从小到大、从点到面,先对服务的某个请求进行故障注入,其次是整个服务,最后再到应用整体架构。之后按照全链路流程,实施了网络、硬盘、进程破坏和业务场景等故障注入,并持续观察互联网金融服务的访问成功率、TPS等变化。通过常态化的混沌工程测试,并融入DevOps工具流水线,使得系统稳定性不断提升。

在云原生时代,全面质量保障体系的探索与实践是企业数字化转型过程中不可或缺的一部分。企业需要深化全面质量管理理念,构建稳定可靠的云原生基础设施,强化风险防范与发现机制,并推动智能化质量管理的发展,实现金融科技赋能业务高质量发展。

(此文刊发于《金融电子化》2024年3月下半月刊)