《北京金融科技产业联盟:2023金融业分布式信息系统运维技术研究报告(71页).pdf》由会员分享,可在线阅读,更多相关《北京金融科技产业联盟:2023金融业分布式信息系统运维技术研究报告(71页).pdf(71页珍藏版)》请在三个皮匠报告上搜索。
1、金融业分布式信息系统运维技术研究报告北京金融科技产业联盟2023 年 7 月I版权声明本报告版权属于北京金融科技产业联盟,并受法律保护。转载、编摘或利用其他方式使用本白皮书文字或观点的,应注明来源。违反上述声明者,将被追究相关法律责任。II编制委员会编委会成员:王长江聂丽琴赵开山编写组成员:杨利进吴声陈鹏刘智俊宋凌杰王蕴周静吴建兰宋韬包旭利荣翔周斌峰张小翠徐行钟瑞蔡文陈凌云袁振青王文春白杨蒋维杰于永恒阚广稳谭翔韩鹏赵明明陈明刘欣吴嘉瑜蓝国平姜险峰陆碧波王月凡李铮彭晋郑焱李培范泽芳袁云飞孙玥熊彤磊林科蒋玉芳编审:黄本涛周豫齐吴声陈鹏III参编单位:北京金融科技产业联盟秘书处中国工商银行股份有限公
2、司浙江网商银行腾讯云计算(北京)有限责任公司华为技术有限公司蚂蚁科技集团股份有限公司北京百度网讯科技有限公司新华三技术有限公司杭州谐云科技有限公司IV摘要摘要金融业正处于向数字化转型发展的关键时期,而信息系统作为数字化转型的基础支撑正加速向全面分布式架构转型。分布式信息系统规模庞大,技术栈复杂,对传统运维模式提出了严峻的挑战,迫切需要构建新的运维模式。本报告在充分调研业界广泛实践探索的基础上提炼总结,研究金融业分布式信息系统运维架构规划和落地建设的体系化方法,以期更好地指导分布式信息系统运维体系的建设。本报告建立了金融业分布式信息系统运维能力框架,强化以“服务业务”为核心的运维理念,基于业务视
3、角定义生产运维的各项能力水平,给出了运维管理保障方面的优化方法,并详述了运维技术能力建设的体系化方案。一是围绕监控、应急、容灾、变更、性能容量等主要运维场景,构建运维数据驱动的自动化服务和风险管控框架。二是夯实运维服务和运维数据“两个基础平台”,形成运维互联互通能力和面向场景的服务支撑能力,全面提升运维自动化水平。三是阐述了IT架构向多地多中心及单元化演进的运维配套能力建设路线。报告最后分析了运维技术的发展趋势。关键词:关键词:金融业分布式信息系统、运维架构、运维管理保障、运维技术能力、IT基础架构V目录目录一、研究背景.1(一)金融业信息系统加速向分布式架构演进.1(二)金融业分布式信息系统
4、运维能力不足.1(三)政策引导高质量建设分布式信息系统运维保障能力.2(四)金融业分布式信息系统运维技术研究目标.4二、金融业分布式信息系统运维能力框架.4(一)运维目标.4(二)运维架构规划.5(三)运维管理保障.7三、金融业分布式信息系统运维技术能力建设.10(一)监控发现.10(二)应急管理.18(三)变更管理.26(四)性能容量管理.37(五)运维技术平台.48(六)单元化架构及运维配套能力建设.55四、金融业分布式信息系统运维发展趋势展望.62参考文献.651一、研究背景(一)金融业信息系统加速向分布式架构演进(一)金融业信息系统加速向分布式架构演进金融业信息系统过去主要采用以IOE
5、为代表的集中式架构,建立了较为规范的运维模式。随着移动互联网及大数据时代的到来,面对业务需求的快速增长以及多样化的计算场景,集中式的处理模式越来越显得捉襟见肘。另一方面,分布式计算的理论和实践逐渐走向成熟,分布式系统能快速地进行系统容量的扩缩以及系统性能的扩展,同时又因其多节点架构提升了系统的可用性以及容错性,不同节点之间可根据各自功能划分进行相互协作,整体上统一对外提供服务。分布式架构在其经济性、自主性、灵活性、扩展性层面较集中式架构有较为突出的优势。金融业正处于向数字化转型发展的关键时期,信息系统作为数字化转型的基础支撑正加速向全面分布式架构演进。以工商银行为例,从2015年开始持续推进分
6、布式架构转型,目前已构建了金融业规模最大的分布式信息系统,承载银行核心业务。(二)金融业分布式信息系统运维能力不(二)金融业分布式信息系统运维能力不足足为支持各类不同的应用场景并提供不同级别的高可用性、高性能、可扩展性、一致性等,分布式信息系统通常具有极高的复杂度。在复杂的生产环境中运行时,分布式系统往往伴随着各种无法预料的突发故障,导致系统服务响应延时、数据计算出错、不一致或丢失,甚至服务崩溃等问题,从而带来无法估量的损失和灾难。另外,随着微服务化、云原生、敏捷开发的快速普及,2快速支持迭代业务需求、高效提供全流程的模块交付变更、保证资源的合理使用,也成为了业务发展的核心诉求。因此,探索如何
7、提高分布式系统在异常情况下的稳定性,避免因为各种故障带来的风险,建设全流程的服务交付体系,完善整体业务的资源管理方案,进而为用户提供高稳定、高品质服务,成为金融业分布式信息系统运维至关重要的内容。当前金融行业的运维架构与分布式技术架构协同不足。一是既有的运维平台缺乏统一规划,新技术在运维工具中的沉淀不足。二是配置管理不适应分布式架构调用关系复杂的特性。三是监控与应急手段较难支撑分布式架构下的故障快速定位及处置。四是变更灰度及性能容量管控能力不足等。为应对上述挑战,迫切需要构建新的运维模式,具备信息系统高可靠运行保障以及赋能业务创新的高度自动化运维能力。(三)政策引导高质量建设分布式信息系统运维
8、保障能力(三)政策引导高质量建设分布式信息系统运维保障能力为加强企业IT系统风险管理,提高业务连续性管理能力,保障国家安全和人民生命、财产安全,国家对各行业的软件质量及系统稳定性提出了更高的标准和更严的要求,如国务院公布的关键信息基础设施安全保护条例指出“建立健全监测预警制度、明确网络安全事件应急处置要求”,中国人民银行印发的 金融科技发展规划(20222025年)强调高质量推进金融数字化转型,原中国银行保险监督管理委员会印发的关于银行业保险业数字化转型的指导意见 提出建立能够快速响应需求的敏捷研3发运维体系,证监会科技监管局组织编写的证券期货业科技发展“十四五”规划强调遵循的第一项原则即为“
9、稳字当头、稳中求进”等,相关政策法规列于表1。由此观之,政策要求各行业的运维团队培养良好的系统稳定性保障观念,做好风险管控,提升运维效能。表 1 国内推动信息系统运维保障的相关政策时间机构政策名称相关政策2021 年 4 月国务院关键信息基础设施安全保护条例建立信息共享机制、建立健全监测预警制度、明确网络安全事件应急处置要求。2022 年 1 月中国人民银行金融科技发展规划(20222025年)强调高质量推进金融数字化转型。2022 年 1 月原中国银行保险监督管理委员会关于银行业保险业数字化转型的指导意见提出“建立能够快速响应需求的敏捷研发运维体系”。2021 年11 月原中国银行保险监督管
10、理委员会关于银行业保险业支持高水平科技自立自强的指导意见坚持风险可控。统筹发展与安全,完善风险控制机制,提升科技金融风险管理能力。2021 年10 月中国证监会科技监管局证券期货业科技发展“十四五”规划强调遵循四项原则,其中第一项为“稳字当头、稳中求进”。2011 年12 月原中国银行保险监督管理委员会商业银行业务连续性监管指引商业银行应当将业务连续性管理纳入全面风险管理体系。4(四)金融业分布式信息系统运维技术研究目标(四)金融业分布式信息系统运维技术研究目标以大型银行为代表的金融机构在推进其信息系统向分布式架构转型的过程中,在运维方面积累了大量的经验教训,进行了广泛的探索实践,取得了一定的
11、成效,但是缺乏统一的认知和框架指导,成效参差不齐。本报告的研究目标是提炼总结业界成功实践,为金融业分布式信息系统运维架构规划和落地建设提供指导,推进金融业运维架构转型,为分布式信息系统高可靠稳定运行及赋能业务创新提供运维保障。二、金融业分布式信息系统运维能力框架(一)运维目标(一)运维目标金融业信息系统运维的本质是服务金融业务,总体目标为“生产安全稳定”以及“服务重质高效”(如图1所示),即在保障业务连续性的同时支持业务快速创新,并提升运维效能。在生产安全稳定方面,持续将风险规避在架构设计、系统分析、开发、测试、变更等活动前,需要技术能力、架构成熟度、风险意识、组织建设等稳步提升。运维目标包括
12、及时发现定位故障、快速解决故障、降低变更差错、防范容量突发风险等。在服务重质高效方面,支持应用快速交付、基础环境供应效能和运维效能提升,以及运维服务互联互通。通过运维架构目标的梳理及运维业务场景的分解,进而明确运维架构规划的主题。5图 1 运维目标梳理(二)运维架构规划(二)运维架构规划运维架构规划遵循如下重点原则。一是强化以“服务业务”为核心的运维理念,基于业务视角定义生产运维的各项能力水平。二是加强运维体系的整体设计,夯实运维服务和运维数据“两个基础”,形成运维互联互通能力和面向场景的服务支撑能力,全面提升运维自动化水平,同时重点围绕主要运维场景,构建运维数据驱动的自动化服务和风险管控框架
13、。三是明确运维规范标准和评价体系,实现研发与运维、业务与技术、运维架构与技术架构之间的协同发展。重视分布式技术架构和云原生技术栈的运维能力建设,如流量调度、资源弹性、运行状态监测、故障自愈,以及分层分级灰度等。6基于上述原则,并提炼金融业分布式信息系统运维实践,形成如图2所示的运维架构规划。图 2 运维架构规划在运维业务场景层面,提炼并规划八大主题场景,基于场景进行管控流程内聚和能力组合,形成各自独立、相互支撑的运维产品。本报告规划重点为监控、应急、演练、变更、性能容量等主题。安全管控、运营分析、资源/资产不在本报告研究范围内。在运维技术平台建设层面,以“平台化、服务化”为核心理念,提供“运维
14、服务”“运维数据”两大平台,融汇PaaS、IaaS及其他专业技术工具和数据,形成一站式运维基础支撑。实践中,也可以合并成一个平台提供服务和数据两类功能。7(三)运维管理保障1.优化运维组织管理(1)基本组织结构(三)运维管理保障1.优化运维组织管理(1)基本组织结构金融业分布式信息系统的运维组织架构是在传统信息系统运维组织结构的基础上演变形成,按照基础设施、技术支撑、业务单元三层人员体系分别对系统设备网络、通用技术支撑平台、各领域业务系统开展运维工作,建立如图3所示的具备“横、纵、专”特性的矩阵制运维组织结构,并适配一体化向研发、质量等科技体系上下游延伸。图 3 运维组织建设横向上,在层次内部
15、,集成应用实体、平台实体的单元化运维团队,一个领域由一个团队负责。纵向上,以业务场景为边界,围绕监控、应急等运维核心工8作开展链路化运维管理,强化信息系统对业务发展的价值贡献。专项上,针对信息系统运维的关键领域建设技术团队,实现新技术的迭代和系统的持续发展。(2)业务运维单元组织管理(2)业务运维单元组织管理随着业务运营监测感知需求的提高,分布式系统架构下,以单体应用为运维管理粒度的运维模式无法满足高效排查处置问题和风险管控的生产运维要求,需按照业务运维单元优化组织管理,强化端到端的面向业务视角的运维价值输出。业务运维单元是结合金融主体业务领域划分及生产运维实际,围绕端到端的一组业务场景定义的
16、用于承接版本研发、应用部署、运维分工、风险管控、应急处置等运维工作的单元。分布式系统在运维架构、制度规范、平台支撑、组织体系等方面,需基于业务运维单元构建运维能力。在金融业分布式业务单元组织构成下,通常会根据最小业务单元的维度配置相应的技术角色,每个角色通常至少配备2人进行主备。(3)运维专业领域组织管理(3)运维专业领域组织管理SRE(Site Reliability Engineer,站点可靠性工程师)是金融业务中非常特殊且有代表性的角色,根据运维对象的区别分为业务SRE、平台SRE、基础SRE,分别承担业务单元、技术支撑平台、基础设施领域的运维工作。SRE角色不仅仅负责信息系统线上的基本
17、运维工作,同时负责利用运维专业领域的技术与平台,9从性能容量、变更管控、应急定位、监控发现、资金核对、演练管理等专业领域,系统化、体系化保障信息系统在线上的系统稳定性及业务可用性,通过技术化、平台化手段不断提升信息系统线上运行时的保障水平,同时通过演练等方式,确保运维工具与流程等持续有效。面向SRE使用的运维专业领域技术与平台,需要配备专业的关键角色(通常有运维架构、运维研发、运维数据、运维算法四类角色),分别负责技术与平台的架构工作、运维技术与平台的研发工作、运维数据的开发与ETL(Extract Transform and Load,抽取转换与加载)工作、运维算法领域的算法能力训练与建模工
18、作。2.完善运维制度规范,建立运维质效评价管控机制2.完善运维制度规范,建立运维质效评价管控机制一是建立面向业务运营的“故障管理标准”。从业务运营和客户服务的视角出发,梳理并制定业务健康度和故障等级定义,基于该标准和对应的故障管理体系对运维能力、应用质量等进行标准化度量,便于指导运维核心能力建设,真实地体现业务连续性保障水平。二是加强规范标准的硬控制措施,随着运维工具体系建设,完善监控、变更、应急、容灾、性能容量等相关领域的标准化,以及相应的规范标准检查自动化。三是完善业务线/应用条线的运维成熟度评估体系,通过监控发现、业务可用率、故障恢复时效等核心指标责任共担的方式,10持续提高源头治理和共
19、同保障效果。应用质量评估结果与生产运维管控措施挂钩,通过变更频度和审批控制、加大健康巡检频度、强化变更验证等措施,控制成熟度较低的应用系统投产风险。研发团队的应用负责人工作评价可酌情参考应用质量评估结果和运维KPI指标。三、金融业分布式信息系统运维技术能力建设基于上述运维目标梳理及运维架构规划,本章的运维技术能力建设分为三部分,一是运维业务场景,聚焦监控、应急、容灾、变更、性能容量等五个主题场景,其中应急与容灾合并体现,分四个小节展开。二是运维技术平台,涵盖运维数据及运维服务两个平台内容,在第五小节详述。三是IT基础架构向多地多中心及单元化架构演进所需运维配套能力建设相关内容,在第六节详述。(
20、一)监控发现1.分布式架构下监控面临的挑战(一)监控发现1.分布式架构下监控面临的挑战一是运维关注点由原来的软硬件状态及可用性,更多地向用户体验、资源扩缩弹性、负载均衡、数据一致性及准确性等方面转变,传统“面向资源”的监控理念逐渐不能满足新发展趋势的要求。二是各专业监控系统处于独立运行状态,数据缺乏横向打通,竖井效应突出,联动机制不足,难以快速精准定位故障。三是业务系统间存在复杂的逻辑及调用关系,交易链路较以往更加多变,内部运转呈现黑盒化现象,原有监控分析手段难以11继续发挥作用。四是分布式架构下基础设施规模和复杂度急剧增加,信息节点数量翻倍、监控数据量激增,异常感知检测难度大,需引入智能算法
21、模型加以收敛,实现精准预警。五是金融业传统监控体系构建于集中式信息系统架构之上,与当时的运维模式相匹配。但当核心信息系统演进到分布式架构时,监控体系自身也需要转型变革,以满足新阶段运维需求。六是受到技术状态限制,以往监控数据采集/刷新频度一般处于分钟级水平,对象颗粒度较粗,对异常的探测捕捉能力弱、响应慢,需要引入新技术栈等手段加以解决。2.分布式架构监控体系设计2.分布式架构监控体系设计分布式架构下监控体系应以建立统一监控平台为目标,整体思路是自底向上实现对网络、存储、服务器、操作系统等基础资源,以及应用软件、业务服务的统一管理,构建以资源数据为纽带的大资源管理框架体系,打破以往分专业竖井式建
22、设模式,制定统一标准化的数据采集规范,建立全域指标体系,从业务逻辑、用户体验两个维度重新设计分析、评估、展示、告警、治理的流程与操作,使得监控系统在业务逻辑呈现上更清晰,用户使用起来更容易上手。在监控体系设计上应遵循以下原则:一是平台功能支持传统架构与分布式架构下的全业务监控模式,应涵盖运维业务的各个领域,包括监、管、控、服、安全、12大数据及人工智能等多方面,如图4所示。二是以面向业务的视角规划架构,满足不同发展阶段、不同业务的运维场景需求;以数据中台为核心,既能满足金融企业全域资源的统一管理,又能保障各技术域的数据关联;提供统一门户、统一告警、统一资源、统一监控、统一采集的集中管理能力。三
23、是架构具有灵活的可扩展性与开放性,提供二次开发能力,能快速实现与第三方系统对接;具有“热插拔”能力,以便在维护某一业务模块时不会影响其他业务模块的正常运行。图 4 一站式监控功能架构133.分布式监控体系监控范围3.分布式监控体系监控范围分布式监控体系的监控范围涵盖从业务到基础设施的各层级监控内容,通过构建多视角监控大盘形成一站式可观测的平台能力。从业务视角包含重点业务线监控、批量业务监控、账务一致性监控,大屏聚合监控等。从专业视角,包含应用/交易监控,云监控、网络监控、系统监控、设备监控、动环监控等。从运维数据类型上看,至少包含日志、指标、链路、配置、事件等五类数据源。4.分布式监控体系重点
24、能力建设4.分布式监控体系重点能力建设由于分布式架构信息节点数量众多、运行数据信息量极大、复杂性较高,因此需要重点开展如下几方面能力建设。(1)运维数据采集能力(1)运维数据采集能力运用可观测性(Observability)理念,通过对各类系统、应用、平台、业务以及用户体验的度量,以了解系统内部运行情况,进而为优化性能指引方向。可观测对象包括:日志、指标、事件等系统运行过程中产生的信息、状态以及用户使用过程中的操作表征。通过遍布各处的探针与接口,实时采集基础运行指标及日志信息。在获取CPU负载、内存使用量等技术指标的同时,还应在交易流中嵌入标签,记录交易在不同应用和系统中执行、调用、跳转等操作
25、的时空信息,用于完整描绘程序运行路径。此外,在应用侧增加切片时点交易额、交易成功率等业务度量指标14的记录,为进一步评估业务服务水平提供依据。在指标采集方式上,应尽量多样化,支持代理与无代理混合纳管方式,根据采集对象加以选择,结合主动推送与被动轮询机制,实现监控数据灵活采集、高效上送。为了扩展采集能力,还可考虑引入旁路监控、扩展伯克利包过滤器(eBPF)、移动应用锚点、巡检机器人等新技术,在采集信息的同时,尽量减小对被采集对象的影响。为了便于后续汇聚整合监控指标,应建立统一的监控指标规范,明确指标类型、格式、编码、采集周期、传输方式等。(2)业务拓扑绘制能力(2)业务拓扑绘制能力分布式系统及微
26、服务架构带来好处的同时,也增加了系统的规模和复杂性。随着应用服务粒度越来越小,应用服务数量越来越多,为了获取应用服务之间的相互依赖关系、全方位感知分布式架构业务的运行状态,需要借助业务标签信息,自动构建全链路拓扑和业务系统画像,在交易全链路拓扑关系基础上套叠基础设施拓扑信息,形成资源、状态、性能、关系等多维度全局架构和端到端交易链路体系。由于分布式架构更多地从提供高水平业务服务角度出发,业务拓扑与交易链路往往处于动态变化中,因此应综合利用嗅探扫描、网络抓包以及调取配置信息、查询知识库等手段,自动化地动态探测与描绘“业务资源”关系图,不断刷新业务服务水平与资源节点之间的关联对应关系,从而为提升业
27、务健康状况分析15与监控能力奠定基础。在业务服务水平下降时,能够根据业务拓扑和专业告警信息,构建事件因果关系图,自顶向下迅速溯源定位故障源头,为应急处置提供依据;当关键资源节点发生异常时,也可以自底向上评估业务影响范围,自动计算健康度。(3)大数据处理及智能分析能力(3)大数据处理及智能分析能力在数据处理方面,由于监控数据的时效性要求很高,依托运维数据中台的大数据处理能力,采用流计算引擎以及相关大数据存储组件,实现监控数据的高效聚合计算及存储。在智能分析方面,传统基于静态指标阈值等专家规则的分析判断方法已难以满足监控需求,需要将不同渠道上报的各专业运维数据加以整合,采取同一视角进行智能化分析。
28、首先,基于历史运维数据,按不同统计周期对各类资源指标、交易响应时间、业务成功率等维度抽取特征值,构建不同对象、不同层面的动态基线库,作为监测资源性能、评估服务水平的基准。进而,根据业务系统运行方式(节点数)、告警数量、资源容量、中断时长、安全等保评估、漏洞数量等节点信息,使用机器学习算法,训练并构建业务健康度评价模型,确定健康度层级及其关键指标和权重。在接入实时运行指标后,能够迅速捕捉异常,随着持续使用真实指标加以训练,评价模型输出的判断结果将更准确、效率更高,综合评定业务系统安全性、稳健性以及承载服务能力的水平越强,运维智能化水平越高。其次,通过数据中台等形式,集中化存储和处理全体系下的16
29、运行指标,再基于机器学习KPI异常检测模型建立阈值智能监控算法库。纵向上,对不同指标的历史数据进行挖掘分析,自动学习单个指标随时间变化的正常波动表现;横向上,自动识别和探索不同指标之间的关联关系,打破企业内部各个系统之间的数据隔阂,整合分散在各个孤岛上的数据,再配以日志语义分析,实现精准报警与趋势预测。第三,针对告警事件做到智能地过滤、压缩、合并、丰富、去重、升级,辅以业务系统、时间、IP等维度等数据加以融合,最终聚合成一种高级事件即故障,进而通知用户进行处理,减少告警噪音干扰,避免单一底层故障引发消息风暴、对监控系统正常运行产生冲击。(4)架构开放能力(4)架构开放能力由于监控系统是分布式运
30、维体系有机整体的一部分,除了实现自身功能以外,还应向体系中其他模块提供服务,例如:对运维中常见的应急、变更等操作输出数据和结论支持,满足其需求,并减少人工判断和手工操作。此外,监控系统用户还会根据工作任务变化、关注点转移等情况,不断提出新的运维需求,因此监控系统应提供便捷的二次开发能力和扩展能力,方便接入新的监控工具,从而快速达成预期功能。(5)集中管控能力(5)集中管控能力新时期面向业务的监控体系,在实现各类运维数据充分融合17的基础上,需要以全局视角审视信息系统健康度、衡量业务服务水平。因此,监控平台应提供一致的查询、分析、控制、配置等使用方法,以支持各方用户开展监控活动,这就要求至少满足
31、以下几方面:(a)设计标准化。(a)设计标准化。在基础设施资源(物理机/虚拟机配置规格)、软件资源(发布单元、容器规格)、应用架构(单元化部署)、技术架构(技术栈、服务API接口、日志规范)等多个层面,采取标准化设计,以降低建设、整合、维护难度。(b)监控模板化。(b)监控模板化。内置精炼的必需监控模板,支持自定义监控项扩展,在满足监控要求的同时,尽可能降低监控采集压力、保证监控高效性。(c)配置一站式。(c)配置一站式。对参数设置、算法模型、告警规则、通知策略等配置操作进行简化和集中管理,实现配置参数自动下发和生效,降低使用成本与操作门槛。(d)交互可视化。(d)交互可视化。提供以业务为视角
32、、主动发现业务故障并协助对业务故障进行端到端分析的可视化视图,用户可以快速获取所需信息,缩短决策时间,减轻运维团队工作压力。(6)自监控能力(6)自监控能力随着运维要求越来越高,监控系统的地位越来越重要,运维人员对其倚重程度也越来越深。监控系统自身健康优劣、能否准确高效提供服务,则必须加以考虑和重视。因此,监控系统除了满足日常对外监控需求,采取高可用架构部署,使用独立的采集、18传输、存储、分析路径,还应提供心跳检测等对内自监控能力,及时发现自身异常情况并成功发出通知,提醒运维人员加以干预处理,以免呈现“伪健康”状态,影响用户判断决策。(二)应急管理(二)应急管理为有效应对各种突发事件,快速恢
33、复对外服务,保障金融机构信息系统安全、稳定、持续运行,金融机构以第一时间恢复生产为第一要务,采取有效措施,建立层次化应急组织架构,制定应急管理制度,及时、稳妥、高效处理各类突发事件,近年来金融机构应急管理水平在不断提高。1.分布式信息系统转型下应急管理面临的困难1.分布式信息系统转型下应急管理面临的困难数据中心在应急管理层面所面临的困难有以下几个方面:(1)应急的复杂度更高(1)应急的复杂度更高分布式架构将一个单体系统拆分为多个服务,存在大量系统间复杂的调度依赖关系,一旦某个点出问题,故障定位和应急处置上都更加复杂,单纯靠人工难以处理。(2)业务连续性要求更高(2)业务连续性要求更高随着越来越
34、多新的金融服务模式和渠道出现,如手机、移动银行类服务常常会出现瞬时高并发业务负载,往往需要处理万次/每秒的读写请求。同时,客户对金融业务的连续性要求很高,特别是对银行等金融组织,原则上要求7X24小时不间断服务。(3)硬件设备故障概率增大(3)硬件设备故障概率增大越来越多的信息系统采用分布式架构来突破单机性能瓶颈,19导致硬件设备故障概率增大。一方面,随着硬件数量的增加,底层硬件和网络设备故障的概率也随之增加。另一方面,分布式架构通常包含多种异构的硬件设备,这些设备的损耗、替换速率存在差异,这种异构性也增加了硬件设备发生故障的概率。2.分布式信息系统在应急管理方面的优势2.分布式信息系统在应急
35、管理方面的优势分布式系统最大的特点是可扩展性,能适应需求变化而扩展。随着业务量需求的日益增长,并发用户请求越来越多,要处理的数据也越来越多。分布式系统因其良好的可扩展性,同时能够更便捷地通过各种应急手段(重启、隔离、切换、熔断、限流、扩容等)来增强系统整体的处理能力,并能够通过标准化应急工具执行提升应急效率,从而应对业务增长带来的计算需求。3.应急管理目标与体系建设3.应急管理目标与体系建设应急管理对于金融业信息系统稳定尤为重要。基于应急管理目标和管理过程,对应急管理相关组件进行设计并形成如图5所示的模型。图 5 应急管理体系20应急管理的目标是应对可能发生或已发生的、影响信息系统连续运行的重
36、大生产事件,能快速恢复生产系统的正常运行,降低突发事件危害。应急管理对突发事件的原因、过程及后果进行分析,集成信息系统各方面的相关资源,对突发事件进行有效预警、控制和处理。分布式架构下各系统组成部分的相互关系及作用发生了较大变化,除在系统架构设计和研发等方面的变革外,更由于系统部署模式、故障恢复机制的变化,须在应急处理等方面进行配套建设,需要研发和运维部门之间紧密协同,共同做好分布式架构下的运维。同时,科技与业务部门也需要紧密配合,一方面,可进一步发挥分布式架构的灵活可扩展、并行高效率处理的优势,另一方面,分布式架构在数据和事务一致性方面,也可能给产品和服务带来挑战,需要科技与业务部门共同处理
37、。4.分布式信息系统下的应急管理建设方案4.分布式信息系统下的应急管理建设方案为应对分布式信息系统转型对应急管理造成的影响与压力,应急管理需要积极作出应对和转变。基于不同金融企业规模、投入产出比、难易度等依次提出如下建设方案。应急管理建设方案需要围绕应急事前、事中、事后的全生命周期,提升应急管理的全流程自动化水平。事前阶段,一是建设流程编制工具,用于基于故障场景的应急流程编排和发布评审功能,便于在应急处置过程中直接调用。二是应急预案管理,将隔离、重启、限流、扩容、切换等标准应21急场景通过关联工具的服务化和脚本化,提高应急预案的切实可行程度。事中阶段,建设应急事中平台、标准化应急工具。事后阶段
38、,可利用应急事中平台或者应急执行平台,实现应急过程信息(如监控、线上交流记录、应急执行平台操作等日志)的录放、灵活组合展示和在线编辑,快速实现应急过程复盘。(1)故障管理(1)故障管理故障管理包括故障复盘和故障要素记录两部分主要功能。故障复盘功能,主要对故障发生到结束的关键时间节点进行回顾,明确故障原因、故障造成业务影响、监控情况、处置效率等信息,并分析各环节薄弱点,制定相应的后续优化措施。故障要素记录,主要将故障复盘后的内容进行详细记录,为明确事件级别、原因归类等科技管理指标提供依据,同时以故障单的形式进行跟踪,确保各项优化措施有序推进和落实。(2)应急事中管理(2)应急事中管理基于工具平台
39、实现应急过程中的信息记录、信息发布及统一管理,支持重启、参数变更、降级、切换、限流等应急处置。应急事中管理需要统一的操作执行平台,通过这个平台,可以对应急执行过程进行记录,并支持各种类型的应急处置,包括人工或者使用工具应急执行。应急事中平台,主要用于应急现场快速组织和应急过程消息实时共享,提升应急通知和组织效率。主要功能包括:一是启动22应急,及时有效地将应急故障消息发送至应急组织架构人员,启动应急视频会议;二是应急事中消息实时共享;三是应急复盘。(3)应急预案管理(3)应急预案管理金融机构应根据信息系统建设及运行情况,对应用系统各环节的次生、衍生、再生影响以及灾害性事件做出全方位分析和风险评
40、估,制定科学、操作性强的分级应急处置措施。对于分布式架构下常见的几类故障(例如服务器宕机、网络异常、磁盘故障等)要制定详细的应急预案场景,具体如下:应急预案场景标准化。应急预案场景标准化。应急预案场景按梯队划分管理,将隔离、重启、一键式切换、应急限流、熔断、降级、切流等操作纳入第一梯队,对于标准化应急场景进行脚本化和工具化,提供一键式应急能力。场景管理边界清晰化。场景管理边界清晰化。建立以业务运维单元为维度的应急预案,使业务运维单元内各场景管理边界更清晰,技术落地更有抓手,故障爆炸半径更可控。故障诊断和应急决策。故障诊断和应急决策。应急处置需要对故障事件进行诊断,并根据故障性质启动相应的应急预
41、案。故障诊断平台要和应急执行平台进行联动,将故障诊断结果推送到应急执行平台,作为应急决策的依据。故障诊断和应急决策的速度和准确度会在很大程度上影响故障恢复的时间,这主要取决于两方面:一是对实际情况是否有尽可能详细的掌握,包括监控、告警和日志信息是否完备;二是应急处置人员是否对分布式系统架构具备足够的了23解,或者是否可以通过决策树/排障树等智能诊断平台做出相应的故障诊断。同时,对于故障诊断和应急决策工具,应当有命中记录统计,并做好持续优化工作。(4)快速处置(a)一键式处置。(4)快速处置(a)一键式处置。一键式应急处置主要使用的是应急工具。建立标准化应急工具,包括同城切换工具、一梯队处理能力
42、标准化应急工具(包括重启、隔离、切换、限流、熔断、扩容等),要将以上工具纳入统一执行平台进行管理,应急的执行进展可在该平台上展现,同时监控、故障诊断平台要与应急执行平台进行联动,推荐应急处理方案,作为人工辅助判断依据,人工进入应急执行平台进行应急处理。(b)自愈管理。(b)自愈管理。应急处置中,第一时间恢复生产为第一要义。在分布式信息系统架构下,应急处置仅靠人工排查恢复并验证是不够的。故障排查定位、应急恢复操作的前后依赖项、应急恢复后的验证复杂度等,都关系着故障的影响程度、故障的影响范围、应急处置的时效性和准确性。自愈管理主要是将人工处置步骤固化成系统自动化操作,实现自动检测和自动恢复,降低影
43、响,快速恢复生产。建立立体化健康自检系统,通过流程编排工具,整合跨专业线自助式服务,如平台中间件、数据库、操作系统参数、网络防火墙、应用可用性、基础设施等,预先构建故障的检测定位步骤和相应的处置步骤,结合定时巡检方式或发生故障时的人工触发24方式,实现系统自愈,提高应急恢复的时效性和准确性。通过自愈统计形成分析报告,提供应急决策依据,提升系统稳定性。如定时巡检应用可用性时发现故障,结合数据库侧用户是否锁、中间件侧WAS是否关闭等判断故障点,若故障点定位为应用,则自动重启,验证应用恢复情况。(5)容灾演练(5)容灾演练应急演练是验证应急预案正确性、应急资源完备性及人员适应性的重要方法。金融机构通
44、常采用以演促防的策略,从而提前发现稳定性保障工作的技术、系统和组织的薄弱环节,提前着手解决问题,完善预案中可能存在的漏洞。需要关注以下几点:一是按年度安排重点应急场景应急演练计划,计划应以应急预案为基础,制定应急演练总体方案,并进行风险再评估,制定相应的保障措施;二是要选择业务影响小的时段进行,避免因演练导致服务中断;三是演练完成后,应提交应急演练报告;四是定期对信息系统应急响应相关人员进行培训。(a)演练线上化管理(a)演练线上化管理随着应急演练类型日益丰富,演练数量逐渐增多,应急与灾备管理系统已经可以实现手工登记应急演练报告、演练记录管理。在此基础上,要推动完善应急演练管理线上化,通过加强
45、应急与灾备管理系统与变更单、应急工具平台的关联,以实现自动生成演练报告的功能,并不断探索演练计划编排、覆盖率查询统计、结果复盘和持续跟进等管理功能。25(b)常态化开展应急实战演练(b)常态化开展应急实战演练关于同城切换演练。金融机构要定期开展重点应用园区隔离实战演练,综合业务交易特点等业务影响,在夜间计划性演练的基础上,扩展演练形式;同时,在业务低峰时段,以突发方式开展多应用园区隔离,检验同城双活应用系统的园区接管能力。关于异地灾备恢复演练。金融机构需要定期开展灾备演练,同时不断丰富业务连续性演练场景,优化灾备演练组织方案,持续提高灾备管理水平,提升全方位业务连续性覆盖能力。(c)有序开展混
46、沌演练。(c)有序开展混沌演练一直以来,金融行业的业务架构都相对比较复杂,交易链路长,对交易可靠性、幂等性要求高。混沌工程是在分布式系统上进行实验的学科,作为发现系统潜在风险,提升应用系统弹性的重要手段,在可控范围或环境下,通过故障注入实验,观察系统行为,发现系统弱点,并持续优化和实验,不断提高系统稳定性,对复杂分布式系统抵御突发事件树立信心。通过混沌演练,可以验证应用系统高可用能力、监控报警及应急处置能力的有效性。基于审慎原则,混沌演练一般会在测试环境引入和生产对等环境,再逐步进阶到具备真实流量的灰度环境和生产环境。混沌演练分为有损及无损两种:有损演练注入真实故障,目标是提前发现问题,减少生
47、产故障率;无损演练在不影响业务的前提下,注入日志、监控告警等模拟故障,目标是检验故障处置能力,提升运维团队战斗力。26(三)变更管理1.金融业科技发展过程中变更管理变化及现状(三)变更管理1.金融业科技发展过程中变更管理变化及现状作为系统运维的重要活动之一,变更管理紧跟IT运维的发展,不断进行自我优化与完善。得益于ITIL的引入,变更管理进一步明确了管理目标、建立了一套更为合理的标准化闭环式管理流程。目前,各金融企业通过自研或外购方式,完成了变更管理流程平台的建设(如:ServiceDesk、HelpDesk等,或第三方开发的流程管理产品)。同时伴随着多年的标准化变更、自动化变更建设,变更风险
48、控制能力有了质的提升。2.分布式信息系统转型下变更管理面临的挑战2.分布式信息系统转型下变更管理面临的挑战随着去中心化金融模式的兴起,以及如火如荼开展的国产化改造任务,我国金融行业正经历着一场IT革命。在这场革命中,变更管理也同其他IT运维领域一样,面临着各式各样的运维转型难题,较为突出的有以下几方面。(1)变更数量增长迅猛(1)变更数量增长迅猛(a)分布式架构的特点就决定了系统整体规模的几何倍数扩张,并导致基础环境等维护类变更数量同比增长。(b)新应用系统上线的环境搭建数量也较传统集中模式有较大增长。(c)分布式的弹性缩扩容机制,也产生出了新的变更类型。(d)互联网金融业务需求快速变化,敏捷
49、、DevOps等软件开发实践导致应用版本上线频率显著提高。27(2)变更方案复杂度提高(2)变更方案复杂度提高(a)相对于集中式环境,分布式环境信息收集工作有所增加。当某一变更涉及多个不同架构应用时(如:烟囱式架构、共享式架构应用等),变更方案制定复杂度将进一步凸显。(b)分布式转型引入了大量新技术、开源软件,迅速进行知识技能转型也成为了技术人员面临的一项艰巨考验。转型效果也将直接影响相关变更方案的优劣。(c)分布式转型对系统进行微服务化拆分,微服务链路长,涉及开发团队多,影响面评估复杂。(3)变更风险控制力下降(3)变更风险控制力下降(a)由于变更数量增加和架构转变,引发了变更风险的质变。传
50、统的专家型等变更风险评估体系面临严重压力。(b)应用层和基础架构层尚未完全解耦前,基础环境类变更将影响对外服务的连续性。虽然相关影响时长较短,但频率可能会有所增加。(c)金融业务发展对应用版本持续部署的强烈需求,与IT系统稳定运维之间存在着直接矛盾。(4)业务连续性等级提升(4)业务连续性等级提升金融业务互联网化后,业务部门对于变更引起的业务不可用容忍度降低,同时对故障的影响面、恢复时间都提出了更高等级要求。3.分布式架构带来更为丰富的变更管理手段3.分布式架构带来更为丰富的变更管理手段28(1)变更业务影响降低(1)变更业务影响降低由于不同的业务(功能模块)分散部署在不同的服务器,并且提供相
51、同业务功能的服务也部署在多个不同服务器或容器上,整体可靠性(容错性)较传统集中部署模式更高。为变更实施提供了更小的分批颗粒度,造成的计划性业务影响或实施异常情况下业务影响均大幅缩减。版本发布方面,基于分布式架构采取的灰度投产模式,允许少量客户的交易流量在独立的灰度环境执行,降低了由于程序质量等原因导致的全局性业务风险及影响。(2)变更实施风险控制(2)变更实施风险控制成熟的分布式产品提供了较为稳定的集中管控平台,通过该管控平台可以通过参数配置、任务下发等方式灵活实现分布式环境搭建。相关变更的实施过程也可以通过管控平台实现全流程监控,实施异常情况下,也可以快速铲除异常节点。大幅减少了人员在变更实
52、施窗口内的人工操作量,提升变更效率的同时也降低了现场实施风险。由此,部分分布式架构下的变更实现了高度全流程闭环管理模式。4.变更管理的目4.变更管理的目标与管理体系建设标与管理体系建设相较于电子商务、生产制造等行业,银行等金融企业承担着较为重要、全面的社会责任。金融系统的正常连续运作关系到国家金融稳定及人民群众的衣食住行。为此,金融业IT变更管理目标及管理体系建设要同时具备一定的通用性和特殊性。(1)变更管理目标(1)变更管理目标29分布式信息系统转型带来的变更频率和数量急剧增加,仅通过制度、管理要求的优化,已无法满足当下变更效率、变更风险管控、变更度量的需求。将变更视作为技术问题,通过新技术
53、应用,系统化、自动化、智能化的应对,不再只聚焦于人的操作流程优化与效率提升。变更管理的目标可以分为:(a)变更效率提升。(a)变更效率提升。体现为:智能评估、智能防御、自动化执行到智能执行(执行过程智能监控、调度、回滚)。(b)变更风险控制在可接受范围内。(b)变更风险控制在可接受范围内。变更流程按阶段可以分为:变更采集、变更通知、变更评估(方案、风险、影响)、变更测试/模拟、变更灰度实施、变更防御、变更监控、变更止血。(c)变更可度量。(c)变更可度量。包括但不限于:管控覆盖率、评估质量、评估效率、自动化执行率、智能防御覆盖率、智能防御效率等。(2)分布式信息系统下的变更管理建设方案(2)分
54、布式信息系统下的变更管理建设方案基于上述变更管理目标,梳理变更管理全过程业务模型如图6。主要包括:变更需求、方案、风险评估、测试与实施、评估与改进等几个阶段。30图6 变更管理业务模型为应对分布式信息系统转型对变更管理造成的影响与压力,围绕变更管理全过程,变更管理需要积极做出应对和转变。基于不同金融企业规模、投入产出比、难易度等依次提出如下建设方案。(a)标准化变更建设。(a)标准化变更建设。作为ITIL原有的变更管理最佳实践之一,标准化变更将极大程度降低变更方案风险,提高变更编排效率。在成本可控的情况下,快速实现变更管理目标。为实现该目标,一是要进行标准变更方案库建设,二是相同操作在不同环境
55、(传统环境、分布式环境等)要分别设计,三是变更方案要注意时效性。(b)自动化变更建设。(b)自动化变更建设。中大型银行等金融企业IT规模庞大,31有限的人力面对快速扩张的IT环境,必须投入一部分力量在自动化变更能力上。在建设初期可以以专业为单位进行自动化工具的开发,先实现专业内的自动化,然后逐步建立自动化工具进行平台化集中整合。(c)智能化变更建设。(c)智能化变更建设。在这一变更模式下,IT系统将根据技术人员预先设置好的参数,自动提出变更,技术人员负责可行性和必要性审核(或者也交由系统自动判断)。变更自动实施并反馈结果,异常情况下自动回退或提示人工干预。此外,还需做好以下两方面能力建设。一方
56、面,远程变更能力建设。一方面,远程变更能力建设。分布式架构的核心特点就是多地部署,同时金融企业为了提高IT系统的可用性、容灾性等,近年来都在进行同城双活、异地多活、异地灾备等数据中心建设。从IT人力资源配置合理性与冗余度考虑,远程变更能力建设势在必行。另一方面,变更风险防控能力建设。另一方面,变更风险防控能力建设。变更最大的难点不在于确保变更成功实施,而是对变更风险和影响的控制。金融机构和分布式产品开发商,均对变更风险、紧急进行了分级管理,并对不同级别的变更采取了不同的评审等管理策略。标准化变更、自动化变更在一定程度上消除方案风险和人工实施风险,但其余变更风险仍存在不可控的短板。故需要对变更实
57、施过程进行持续监控,并加强自动化、智能化应急回退等能力的建设。需要强调的是,变更智能防御水平也是智能化变更能力评判的重要因素之一。32(3)变更风险防控体系(a)变更信息收集。(3)变更风险防控体系(a)变更信息收集。变更信息来源从组织层面覆盖了组织内部、组织外部关联机构(如合作单位、网络运营商等);从环境来看,变更信息覆盖了IaaS层服务器、网络、数据库、中间件、PaaS、系统发布、系统配置、业务数据等。通过对多源信息进行标准化采集,后续可用于变更信息的订阅、应急检索、影响面分析等。(b)风险评估。(b)风险评估。组织变更风险专家组评审,有效识别变更过程中的风险,并梳理应对措施。(c)风险模
58、拟(c)风险模拟。在仿真平台进行变更实施模拟,仿真环境中的数据、流量、配置等与生产环境要尽量保持一致,最大程度上模拟变更在生产环境实施情况,提前识别潜在风险。(d)执行防御(d)执行防御。根据不同的变更场景类型、作用对象重要性,确定变更逐步生效的步长、间隔、批次,以及每个批次的具体范围。在变更动作开始前检查准入风险,在变更动作完成后观察其成败与影响。(e)度量防控效果(e)度量防控效果。通过对变更防控效果进行度量,持续提高变更防控的场景覆盖率、风险评估质量、模拟覆盖率、风险拦截准确率、防御执行效率等。防控体系如图7所示:33图 7 变更防控体系简图(4)变更灰度/分批风险防控模式(4)变更灰度
59、/分批风险防控模式原本只能靠体验应急恢复速度来解决的问题,通过一个可控范围暴露风险,再利用充分的风险识别手段,不断将未知的变更风险问题逐步收敛。由于所有的问题根因无法穷举,使得前置校验的风险覆盖率低;同时相同根因的变更故障不常复犯,使得前置规则编写的ROI(投资回报率)较低。分布式架构下,计算节点、数据库节点高度自治,使得灰度/分批的变更防控模式得以实现,其防控能力得以充分发挥。由于分批策略的引入,即使前面几个小批次出现了问题,由于范围可控,问题的严重性也可控制。变更风险防控从面向已知问题的防控,演进到了面向未知的防控,从押宝前置校验演进到了前后置共同防控。分布式架构与可灰度/分批策略的变更防
60、控架构的结合,也要遵循以下几个必要条件。(a)固定流程的执行流水线(强制风险发现/步骤可控):执行按照预发/灰度/生产批次进行环境间/批次间串联(b)变更分批执行能力(控制风险范围):变更的生效需要能够区分环境34线上环境按批次生效(c)前后置防御校验(风险发现):前置阻断变更、后置发现问题/阻断下一批次变更每批次的前后置需要布防基于变更灰度/分批执行的流水线如图8所示。图 8 变更灰度流水线(5)基于分布式信息系统的业务软件部署(5)基于分布式信息系统的业务软件部署除了分布式系统自身的软硬件变更外,基于分布式系统的业务软件产品部署也有其特殊的管理流程持续部署。分布式架构提供的持续部署由部署流
61、水线、部署策略、验证、风险应对等部分组成,用以支持分布式系统业务价值的快速交付。(a)部署原则(a)部署原则。明确部署全流程中,部署流水线、文档、部署环境的对应关系及完备性要求。(b)部署策略(b)部署策略。明确部署策略要包含灰度策略、技术业务验证策略、风险应对策略等内容,并要根据相关灰度技术规范进35行部署。(c)风险管控(c)风险管控。依据变更等级、潜在影响等进行风险评估;部署过程的可视化、可验证等非功能需求加以控制,并依据制度加强合规风险控制。(d)验证体系(d)验证体系。建立完备的验证体系,通过设置验证指标、验证要点等方式结合智能化等技术验证手段及时判断部署结果。(e)后评估(e)后评
62、估。部署过程的效能、中断、验证、回退等环节应可度量、可视化。(6)软件产品灰度发布管理流程(6)软件产品灰度发布管理流程作为持续部署实践中一个最重要的软件产品发布策略之一,分布式架构的业务系统软件产品通过灰度发布的模式,有效地控制了新业务上线风险,提升了对客服务的连续性。(a)基本原则(a)基本原则。根据不同应用、业务系统,或产品线重要程度设置灰度部署模式(物理灰度、逻辑灰度、蓝绿发布等)和策略。其中,物理灰度模式(即有独立的灰度应用群组)风险控制能力最强。该模式通过交易引流器等方式,将少量等试点交易引入灰度节点群组进行处理并验证新程序处理逻辑的正确性、客户体验情况等。(b)设(b)设计原则计
63、原则。灰度发布设计原则应考虑上下游的投产部署和灰度策略,不能对生产造成影响。灰度环境性能容量、兼容性、引流策略和参数等要评估充分。分布式架构通过业务/系统功能拆分、应用代码解耦,维护灵活性大幅提升,在此基础上进36行的业务流/交易流的全链路灰度发布模式将是后续的发展方向。(c)部署原则(c)部署原则。明确并制定灰度部署全套流程的控制要求和管理策略,具体包括:首次灰度部署、引流、验证、监控、流量爬坡、转正。(d)配置原则(d)配置原则。分布式系统的环境和程序配置信息应纳入分布式配置中心统一管理。(7)变更管理体系建设的难点及提升方向(7)变更管理体系建设的难点及提升方向分布式信息系统下的变更管理
64、体系的建设与落地,仍面临着如下难点问题。难点1:难点1:分布式架构设计复杂,技术多样性与服务多变使得运维复杂度提高。对于变更风险评估仍较大程度依赖专家体系的现状,变更方案风险评估的完整性、可控性无法得到保证。提升措施:提升措施:一是基于知识图谱进行变更影响分析,提供给专家判断与部分场景的智能决策。二是利用模拟执行与灰度流水线执行等措施开展智能防御,通过智能分批监控识别变更对象、对象上下游、对象关联链路、对象关联业务等判断变更的影响,提升变更风险识别能力。三是站在组织角度,坚持先外围应用、后核心应用的分布式改造,逐步扩大分布式技术的适用范围。加强人员技能培训,经验积累并建立分布式技术知识库。难点
65、2:难点2:金融行业对于业务连续性及产品迭代的高频需求与37相对保守滞后的变更管理模式的冲突。提升措施:提升措施:一是完善优化分布式架构下变更技术手段,通过灰度投产、全链路灰度投产模式的持续推广,降低产品部署风险和业务影响范围。研究并制定分布式下的变更管理新模式与流程。二是研究分布式架构下系统、网络等基础环境与上层应用服务的解耦方案,消除或减少底层环境变更对应用服务的影响。(四)性能容量管理1分布式架构下性能容量管理的挑战与机遇(四)性能容量管理1分布式架构下性能容量管理的挑战与机遇性能容量管理是指为优化整体运营绩效,满足当前和未来业务需求而评价、监控和调整IT服务资源性能和容量的活动,并使得
66、IT服务的成本可控。随着业务系统从集中式向分布式、微服务架构转型,对传统性能容量管理模式带来了以下几方面挑战。(1)信息系统架构愈加复杂,分布式环境受服务器资源、架构设计、网络、应用和业务场景等多条件制约,服务链路复杂,任何一个环境出现性能容量瓶颈都可能放大到整条链路,性能容量管理的复杂性显著增加。(2)移动互联、数字化等新技术、新业态赋能业务发展,新的业务形态也愈发复杂,真实业务交易的瞬息万变和部分交易的高并发大流量,随时都可能会对IT系统的稳定性带来巨大冲击。(3)服务器的爆发式增长导致机房等基础设施资源紧张,但是资源过度裁剪又会导致设备性能负载升高,存在生产性能隐38患的矛盾。另一方面,
67、分布式架构为支持资源高效利用提供了丰富的技术手段。弹性伸缩:弹性伸缩:是根据业务需求和策略自动调整计算能力(容器实例数量)的服务。根据指定的实例类型和配置策略,在业务增长时,弹性伸缩自动增加指定类型实例,保证计算能力。在业务需求下降时,弹性伸缩自动减少指定类型实例,节约成本。资源混部:资源混部:是在云原生架构建设过程中进行在线和离线集群混合部署,统一资源调度,以资源隔离和动态调整为基础,将不同属性类型的在线服务和离线计算类服务精确进行组合,利用高效调度算法和智能化的容量计算模型等技术手段完成资源的合理利用,提升资源错峰高效利用水平,降低IT成本。资源池化:资源池化:资源池化是将服务器物理资源抽
68、象成逻辑资源,让一台服务器变成几台甚至上百台相互隔离的服务器,不再受限于物理上的界限,而是让CPU、内存、磁盘、I/O等硬件变成可以动态管理的“资源池”,从而提高资源的利用率,简化系统管理,实现服务器整合。2性能容量管理目标2性能容量管理目标一是提升资源管控水平。通过建设性能容量管理平台,涵盖从业务、应用、系统、网络到基础设施的全域性能容量指标体系,实现精细化性能容量评估,解决业务与基础设施在容量评估等环节的断层现象。39二是建立完整的全链路压测方案。建设压测管理平台,通过压测风险控制及配套技术手段解决测试环境压测不准确等问题。三是建设容量自愈及多级流量管控体系。提供各类流量服务检测和调拨服务
69、,支撑网络接入层、应用接入层、应用服务层、数据服务层等多级交易流量灵活调度。3性能容量管理体系建设3性能容量管理体系建设性能容量管理体系建设闭环如图9所示。图 9 性能容量管理体系(1)提升资源管控水平(1)提升资源管控水平围绕重要业务场景做好全链路性能容量管控,结合业务量等因素,科学评估应用系统的性能容量指标及阈值,核心场景通过全链路压测,掌握实际业务支撑能力,建立体系化评估方法及流程,提升资源管控水平。(a)重点业务的全链路梳理(a)重点业务的全链路梳理链路梳理是保障工作的基础和开始,如同对整体应用系统进40行一次全面体检,从流量入口开始,按照链路轨迹,逐级分层节点,得到系统全局画像与核心
70、保障链路。该阶段工作需要从应用和系统层面入手。应用链路梳理。应用链路梳理。应用链路梳理工作一般根据前期明确的业务场景从流量入口开始,按照流量轨迹对链路上的节点按照依赖程度、可用性、可靠性进行分层区分。系统链路梳理。系统链路梳理。在保障活动中,一是评估核心链路网络情况,确认核心服务器的网卡支持带宽;二是评估核心链路存储情况,确认是否存在存储瓶颈;三是评估核心链路应用上访问数据库的情况,为后续的“流量预算”“容量评估”工作做准备;四是对于非常重要的保障需求可考虑梳理“老旧机器”,包括服务器设备、网络设备、存储设备,确保核心链路应用没有老旧设备。(b)性能容量平台建设(b)性能容量平台建设在性能容量
71、管理平台中纳管应用性能容量和系统性能容量的数据,汇聚物理设备、操作系统、中间件、数据库和应用交易的性能监控数据,建设完善业务、应用、系统、网络到基础设施的全域性能容量指标体系,实现精细化性能容量评估。应用容量评估应用容量评估根据应用业务情况和应用系统性能数据分析当前的情况、预测业务应用系统云基础设施未来的使用情况以及为满足预计的业务服务需求而需要资源,从而完成对容量评估的过程。容量评41估需要将业务量、服务等级、应用系统性能统一规划管理,建立三者之间的关系模型。容量评估需要对当前的系统做压力测试来评估当前系统的性能和容量。目前行业主流通过TPC-C、排队论来作为容量评估的专业手段,其中前者是作
72、为基准方法,后者排队论更加精准(排队论是研究系统随机聚散现象和随机服务系统工作过程的理论和方法,又称随机服务系统理论,为运筹学的一个分支)。系统容量评估系统容量评估系统容量评估主要为“资源供给”方面的容量评估,基础环境的容量决定了应用容量。结合数据中心的现状,可在网络、数据库、存储方面开展评估。数据库容量评估主要关注cpu、内存、io、cache方面的参数;存储容量重点评估每个表增加的记录数、长度等;网络容量评估主要关注系统稳定运行的整体最大TPS,每秒数据大小计算出网络容量。(c)建立体系化评估方法及流程(c)建立体系化评估方法及流程建立事前评估、事中监控、事后调优等不同阶段的全流程管控和持
73、续优化机制;通过深入挖掘主机系统、平台系统、应用容量、网络环境、设备及机房基础设施等深层次的检查要点,发现潜在的性能或容量风险隐患,并通过常态化巡检和推动整改,有效消除未来较长一段时期的风险隐患,确保系统、网络、机房容量能够满足业务需求。事前评估。事前评估。在特殊业务时期、业务营销推广、重大项目42投产前,提前做好重点业务的全链路梳理和评估,结合业务需求、全链路压测、健康检查,以及性能指标趋势分析等情况,合理预估资源需求,保障重点业务场景资源分配与业务发展相匹配。事中监控。事中监控。加强对重点时段、重点业务的监控;建立关键及敏感系统清单(重点涉及影响对外连续服务、业务和客户敏感系统、核心关键系
74、统)。通过集中监控系统和性能容量分析系统,采集系统运行指标,实时掌握系统运行情况,并结合性能容量模型进行分析优化。监控过程中,重点对超过性能容量指标阈值的情况进行分析,并按照事件管理流程或者问题管理流程进行处理。事后调优。事后调优。根据生产性能容量分析结果,结合业务实际运行情况,制定性能容量优化方案,对需优化的业务系统进行配置调优、扩容资源等实施工作。对长期因资源配置过高而利用不足的业务系统,实施资源配置缩减。做到保障业务发展的前提下对资源的充分利用。(2)全链路压测管理(2)全链路压测管理为进一步提升客户体验和系统稳定性,全链路线上压测是最贴近生产实际业务运行,测试置信度最高的测试、验收方法
75、。(a)全链路线上压测方案(a)全链路线上压测方案全链路压测的核心思想是借助流量打标、数据隔离等技术,复用生产软硬件资源实施压测,同时又避免了压测流量对生产业务数据的污染。常用的有两种改造方式:43一是侵入式代码改造。该方案确定性高,运维风险小,但是改造成本高,接入、功能升级周期都较长。二是非侵入式Agent动态增强。该方案灵活度高,可复制性强,接入成本低,但是存在一定运维操作风险,如agent接入遗漏等。改造后重点业务链路支持线上全链路影子流量压测,实现常态化活动保障压测和基线压测,系统具备的能力如下:一是全链路流量染色。通过压测平台对输出的压力请求打上标识,在系统中提取压测标识,确保完整的
76、程序上下文都持有该标识。二是全链路日志隔离。当系统向磁盘或外设输出日志时,若流量是被标记的压测流量,则将日志隔离输出,避免影响生产日志。三是全链路风险熔断。两个系统之间服务通信将会有白黑名单开关来控制流量流入许可。四是全链路数据隔离。当访问数据库时,在持久化层同样会根据压测标识进行路由访问压测数据表。数据隔离的手段有多种,比如影子库、影子表,或者影子数据,三种方案的仿真度会有一定的差异。(b(b)全链路线上压测平台建设搭建模式)全链路线上压测平台建设搭建模式一是使用外部压力测试服务商发起压力:外购发压服务,可44按照压力发起服务的发起次数及能力进行计费付费。二是在机构内搭建面向互联网的全链路压
77、测发压平台:内部搭建面向互联网的全链路压测发压平台,在自有的数据中心机房进行设备资源、网络带宽等基础设施规划改造,灵活调度使用设备、带宽资源,作为生产全链路压测的压力发起端。三是在机构内搭建面向局域网的全链路压测发压平台:在机构内搭建面向局域网的全链路压测发压平台,压测平台在内网对目标系统进行全链路压测。压测工具选择压测工具选择由于生产全链路压测一般都有较高的并发需求,且一般需要多台压测机组成发压集群进行测试,开源工具更容易进行集成和二次开发。推荐选用Jmeter和Gatling作为全链路压测平台的底层发压工具。测试监控测试监控压测过程中,对系统、业务交易各项指标(例如TPS、QPS、交易成功
78、率、失败率、错误日志查询等)的监控是定位问题和衡量压测效果的重要工具:一是系统层面的性能监控可复用生产运维的监控体系。二是完善交易性能指标的监控范围。在场景设计及测试过程中发现的,对性能容量影响较大的性能指标(如CPS、连接保持时间、交易成功TPS,交易失败TPS等),纳入生产整体监控。三是压测工具监控。压测过程中,需要对压测机资源进行整45体快速调用,并且实时汇总统计整体压测工具指标,辅助问题分析定位。四是场景化监控,可定制的监控大盘,便于快速直观地看到当前整体性能趋势。可快速定位到被测系统的所有节点监控指标数据以及问题日志定位,可以通过大盘或者统一入口进行快速信息获取,以便测试过程中对生产
79、海量服务器具体问题的快速定位。(c)实施全链路线上压测压测实施方案制定(c)实施全链路线上压测压测实施方案制定经过业务场景需求分析及场景设计后,依据业务需求形成具体测试场景细节。一般压测方案中需要包含如下内容:一是压测相关方在压测前后期间的配合工作。二是压测时间窗口及具体安排。三是压测场景和场景的压测目标描述,压测场景主要包含压测的交易种类和压测方法。目标包含:吞吐量的目标、响应时间的目标、成功率的目标、系统资源的目标等。四是压测场景的测试策略,例如:稳定阶梯发压,还是模拟秒杀类的瞬时涌入。五是场景监控方案及监控指标。六是压测所需的其他文档,例如应急方案、数据清理方案等。压测准备工作压测准备工
80、作正式压测之前,可能会有如下前置准备工作需要完成,根据整体工作安排依次完成:46一是系统程序版本及环境就绪。二是测试环境程序测试验收及脚本测试完成。三是线上系统网络、操作系统资源搭建就绪(根据前期对系统各节点的容量预估,或者全链路压测过程中的反馈数据,进行服务器数据准备)。四是监控系统调整就绪。五是第三方资源协调就绪,根据业务系统全链路分析,对第三方资源进行容量预估,并告知第三方进行环境资源协调准备。六是压力机资源协调就绪,需要提前完成发压平台建设,并基于前期测试评估的单台压力机发压的上限,准备压力机资源供测试期间调拨。压测实施过程压测实施过程压测实施过程中,需要严格按照全链路线上性能测试实施
81、方案开展;压测过程中,需要实时关注生产运行监控情况,及时记录数据,在遇到生产报警后,第一时间进行应急处理,保证生产存量业务的稳定运行;压测实施完成后,需要及时将环境进行回退处理。压测结果分析压测结果分析一是记录各个压测场景的实施时间。二是收集压测期间交易、系统、网络各个维度的监控数据。三是记录压测过程中发生的各类问题。(3)容量自愈及多级流量管控(3)容量自愈及多级流量管控47(a)容量应急自愈(a)容量应急自愈主要包括两部分:容量决策判断和容量恢复操作。基于性能容量监控、性能基线数据以及历史性能指标分析,结合历史容量故障特征值分析进行综合判断,根据分级容量异常做出自愈判断,调用容量恢复操作组
82、件实现容量自愈,如图10所示包括扩容、重启、流量阻断等。图 10 容量自愈流程(b)多级流量管控/调度(b)多级流量管控/调度48限流中心建设。限流中心建设。建立统一的限流熔断治理能力平台,统一治理对象和治理能力,建立全局管控视图。统一技术方案,适配各类技术平台。具备限流、熔断、阻断三种服务治理能力。限流/调度能力覆盖。限流/调度能力覆盖。限流/调度需要做到系统组件全覆盖,包括接入层、网关层、应用层、消息、缓存、数据访问等。同时提供丰富的限流能力。限流/调度统一规范。限流/调度统一规范。建立限流/调度的统一实施规范,包括全局限流策略、降级策略、熔断策略,以及实施标准等。规范预案管理。规范预案管
83、理。限流/调度需要建立规范化的管理流程,包括预案的编排保鲜,演练计划实施、风险检查等。(五)运维技术平台(五)运维技术平台分布式信息系统运维场景复杂,运维工具的建设存在烟囱式的情况,运维数据难以互联互通,应用运维相关操作和基础设施运维相关操作均分散在多个工作平台中,使得技术平台的标准化、操作风险管理统一管控、跨专业运维场景的编排等难以得到有效保障。因此,有必要对运维技术平台体系做整体梳理及规划,打破专业竖井。通过借鉴银行业务架构建模的理念,梳理归纳出生产运维主要场景,“抽丝剥茧”提炼出运维活动流程并构建运维领域业务架构,进而形成基于运维对象、面向运维场景的运维技术平台建设规划。主要是通过建设运
84、维数据及运维服务两个技术中台实现运维数据的互联互通及服务的共享共用,为各类运维场景49化工具提供服务调用,从而构建全方位一体化的运维工具体系,实现运维效率和质量提升。如图11所示,运维技术平台整体架构如下:运维场景化工具包含监控、应急、变更、性能容量、持续交付、容灾等。统一运维工作台封装运维服务及数据中台的服务接口,构建包含应用及基础设施运维的运维服务目录,并为上层运维场景化工具提供各类视图及“监、管、控、营”服务接口。运维服务平台覆盖各专业技术系统,运维数据中台包含数据和算法支撑。在实践中,也可以合并成一个平台提供服务和数据两类功能。图 11 运维技术平台框架1.运维数据中台(1)运维数据中
85、台建设目标1.运维数据中台(1)运维数据中台建设目标50在满足金融业分布式系统运维数字化建设背景下,按照数据组件化、服务化的思路,建设集数据、算力、算法、工具、服务于一体的运维数据中台。如图12所示,通过融合运维数据资产要素、构建数据分层布局治理体系、打造安全高效普惠用数流水线、创新研发管理新机制、驱动数据服务共享新模式,支持面向运维应用和工具多主体协同用数需求,满足大规模安全高效普惠用数创新需求,释放数据要素价值潜能,为高质量服务分布式系统运维工作提供强大的数据动力。图 12 运维数据中台功能架构(2)运维数据体系建设(2)运维数据体系建设针对专业领域产生的运维数据开展存量治理,通过标签画像
86、方式将运维对象在运维活动中产生的属性状态信息转换为规范化的数据资产,持续完善运维数据模型、元数据等数据质量规范,构建以如图13所示的贴源层、聚合层、萃取层为核心的数据分层体系,解决“数据质量不高,有数不能用”问题,快速实现数据51从“原料”到“产品”的价值转化。一是推进数据的分层体系建设,具体包含:贴源层:建设目标是把企业运维领域的全域原始数据都汇聚到运维数据中台,为聚合层、萃取层建设提供数据支撑。聚合层:从运维领域完整性角度重新组织数据,建立标准化的数据连接聚合的基础,形成运维公用数据层,避免重复建设。萃取层:建设目标是按照运维场景使用需要,通过建设通用共享指标、标签服务以提高复用与共享,建
87、设各运维系统共享服务以支撑各运维领域灵活创新需要。图 13 运维数据资产体系框架二是丰富数据纳管范围,打通元数据拓扑,监控指标,日志,以及分布式链路数据。完成CMDB,业务链路以及业务监控指标的数据模型整合,通过运维数据中台提供统一的动态数据模型给到上层业务场景。支撑上层应急定位,变更影响面分析等场景。三是重视配置管理的优化工作,研究通过更为准确、快速、完整的方法来提升配置数据的完整性和准确性,提供业务拓扑可视化展现能力,对众多关联运维系统形成有效支撑。比如工商银52行参照现实地图,基于配置拓扑及网络流数据的汇聚挖掘,构建一张包含拓扑信息、节点互访、应用高可用部署等,涵盖应用、系统、网络的数据
88、中心多层动态运维地图,为故障定位提供拓扑关系,并提升可视化能力。(3)运维数据智能分析能力建设(3)运维数据智能分析能力建设开展运维大数据分析等智能运维技术创新,规划建设智能运维平台,沉淀智能运维技术创新成果,为各专业运维场景应用研发提供智能运维引擎服务。涵盖异常检测、根因分析、关联分析、故障预测、趋势分析等算法集,实现对海量运维数据的流式计算和分析挖掘,联动历史知识库、专家规则库进行决策推导,提高复杂架构下的风险检测能力和问题排查效率。(4)运维数据运营能力建设(4)运维数据运营能力建设规划建设多层次的数据服务,通过提供数据调用、数据监控、数据分析与数据展现等多种服务,可以基于热点业务品种、
89、关键业务场景进行运维数据的深度挖潜,提取业务交易特征行为,反哺至业务部门以促进客户服务和业务运营优化。例如,工商银行基于各渠道系统的交易日志,开展客户行为特征、渠道成本分析等方面的分析挖掘,协助业务部门开展业务运营成本分析,适时调整业务产品渠道和客户服务功能的战略布局,形成技术与业务、技术与管理互相支撑的良性循环。2.运维服务平台(1)运维服务平台建设目标2.运维服务平台(1)运维服务平台建设目标53图 14 运维服务平台功能架构运维服务平台主要面向“监,管,控,营”等运维场景统一提供运维服务调用。重视运维服务平台框架建设,统一明确运维技术规范和标准。如图14所示,围绕关键运维场景梳理运维操作
90、工具、服务接口和脚本,由运维场景驱动相关服务操作接入:优先满足应急,变更,监控,容量管理等场景需求。各专业的运维工具系统需统筹考虑运维管控能力,以及对运维服务平台的接入和改造。运维服务平台向下纳管物理机设备资源对象、网络设备资源、VMware虚拟机资源对象、IaaS层资源对象、PaaS层资源对象、应用资源对象等。实现对运维通用能力进行原子化封装,主要有:命令通道、文件管理、流程编排、服务编排、任务调用、统一登录、大数据采集存储计算、统一API网关等;同时提供平台化开发能力便于各专业技术工具进行服务化封装和注册,便于持续丰富运维服务目录,进而形成对上层运维业务场景的良好支持;提54供一站式的运维
91、调度和执行能力,以及服务注册、发布和使用情况等管理功能。(2)运维服务平台价值一是实现专业运维服务的封装与集成。(2)运维服务平台价值一是实现专业运维服务的封装与集成。通过运维服务平台的建设,将专业运维服务以API接口或脚本的原子能力进行集成,提供自主研发的便捷开发者服务,通过私有化部署的软件交付模式,可以快速实现环境交付、生产应急等场景下自动化运维流程的实施落地,提升数据中心整体基础运维能力。以工商银行一键式应急切换系统为例,通过业务系统链路环节的梳理定制应急切换流程,按需调用网络域名解析、负载均衡、容器管理、数据库切换脚本等多个专业的原子能力,实现业务流量快速在同城园区或异地园区之间的漂移
92、和接管。实现了三百多个高等级应用系统、数十条核心业务全链路、覆盖网络区域和IaaS云等关键基础设施故障场景的快速切换能力,大幅提高生产应急效率。二是实现生产运维管理全流程自动化。二是实现生产运维管理全流程自动化。面向运维管理场景,将环境交付、版本发布和变更管理等核心流程纳管至运维服务平台,在规范日常运维管理活动的同时,便捷地实现了跨机构跨部门的流程自动化调度,有效提升运维的协作效率和工作质量。版本投产交付是变更复杂度最高、涉及范围最广的生产变更场景,为了及时响应业务迭代的需要,工商银行依托运维服务平台建设,践行DevOps理念,规划打通从应用版本交接、生产环境交付和应用版本投产的全流程。其版本
93、投产交付全流程自动化流水线已取55得了阶段性成绩,在应用版本交付流水线覆盖率已达95%以上,投产交付实施成功率达到92%以上。三是实现运维操作风险管控自动化。三是实现运维操作风险管控自动化。提升运维服务自动化能力,不代表可以降低运维风险控制要求。为了避免可能发生的生产运维操作风险影响,通过将原先生产变更的人工检查手段提炼并形成专家规则库,集成在运维服务平台的运维操作自动化流水线中,实现生产运维操作的事前检查和预警、事中检测和实时阻断,以及变更操作后的自动化验证,通过自动化的变更全流程风险管控手段防范操作管理类风险事件的发生。工商银行初步建立高危命令检测、明文密码检查、应用状态检查等专家规则,对
94、已注册的数百条生产变更流水线进行风险监测。(六)单元化架构及运维配套能力建设1.背景(六)单元化架构及运维配套能力建设1.背景异地多活是分布式系统的一种高可用部署架构,单元化是实现异地多活的解决方案和实现路径。通过单元化希望在分布式架构应用拆分和数据拆分的基础上解决以下问题:一是异地场景下的访问延时问题,实现异地多活。二是单机房数据库连接限制问题,突破物理限制。三是容量预估和扩容复杂问题,按单元预估和扩容。四是发布变更恢复问题,支持恢复发布。(1)容灾方面(1)容灾方面分布式架构下,系统在面临一些单机故障时,往往可以通过56快速重启等手段实现“自愈”。但在面临区域性故障时,由于应用间存在较多的
95、跨站访问,故障会随调用链延长而产生更大的爆炸半径;由于故障定位困难,主要依靠同城切换的方式应急,切换灵活性较差,系统的恢复时长难以有效控制;在异地部署模式下,大量的跨站访问会由于网络延时导致性能大幅降低,异地多活优势难以体现,也难以适应未来数据中心多地多中心发展需求。(2)容量方面(2)容量方面分布式架构下,虽然应用服务器资源可以随用户量和业务量的增长横向扩展,但数据库连接数、服务提供方的连接数会逐渐逼近上限。2.单元化架构目标2.单元化架构目标单元化架构就是按照业务链路的维度,将上下游应用的用户数据按照统一的规则和算法进行分片,并与应用处理节点一起进行逻辑上的单元划分,使业务流量按照统一的规
96、则分配到各个单元内,并尽量确保同一用户的业务处理始终收敛在同一个单元内完成。通过对单元进行层次化的设计,对应用间流量及应用到数据库的流量进行主动控制,统一对客户交易相关主要数据的分片策略,并实现单元内的亲和性部署,大幅降低不必要的跨单元访问,有效控制故障爆炸半径,提升切换的灵活性,更好地适应未来数据中心的多地多中心部署需求。通过单元的划分和单元流量的管控,可以有效控制单元内应57用节点的数量,保护数据库的连接数和服务提供方的连接数,同时还可通过单元的新增,支持系统容量进行横向的灵活扩展。3.整体架构3.整体架构图 15 单元化整体架构如图15所示,一般而言,单元化架构总体规划三种类型的单元,各
97、应用可根据所处业务链路的环节、参与角色、数据处理方式的不同,部署到不同类型的单元中。(1)接入单元(VZone)(1)接入单元(VZone)主要负责流量接入、识别用户后转发流量到分区单元或公共单元,在分区单元、公共单元故障场景下,可通过路由调整将流量转接到相应的备份单元。接入单元除客户识别功能以外,原则上不允许存在应用外的服务提供方,从而在发生故障时具有高度自限性,有效控制故障爆炸半径。(2)分区单元(RZone)(2)分区单元(RZone)按用户分组处理流量,仅在交易无法在本单元内闭环时才对外访问,生产环境每个分区单元都有预定义的同城备份单元,可在故障发生时接管其流量。分区单元部署的业务应用
98、,原则上应基于客户信息号按统一的分片算法对数据进行分片,按统一的规58则划分到分区单元,每个分区单元各自服务于一批客户,单一客户的业务处理尽量闭环在同一单元内完成。对于技术支撑节点或无状态的应用节点,可对等部署在每个分区单元内,服务于本单元内处理的业务。(3)公共单元(GZone)(3)公共单元(GZone)主要部署接入单元和分区单元所需的共享数据。同时为了从工程实施层面做好统筹管理,在保持单元化环境架构一致性的同时减少实施过程对于存量环境的影响,可以在公共单元部署代理节点,实现单元化环境和存量环境的衔接。4.监控发现(1)应用单元化可观测4.监控发现(1)应用单元化可观测单元之间因流量的调度
99、以及热点流量天然的不均衡,应用整体和单机的监控都无法有效反映单元的状态。基于丰富的应用日志、指标、链路、配置、事件等监控基础,按照逻辑部署单元进行聚合统计分析,提供相对应用整体更细粒度的单元视角,针对不同指标可以采取不同的统计策略:累计、平均、极值等,及时识别出异常应用单元,按照规则进行告警。(2)业务可观测(2)业务可观测分布式应用单元化部署后,业务同样被单元化划分,原业务整体监控无法精细化反映实际状态。基于原业务请求、成功率、业务耗时等监控指标基础,按照逻辑部署单元进行聚合统计分析,提供更细粒度的单元视角,针对不同指标可以采取不同的统计策59略:累计、平均、极值等,及时识别出异常业务单元,
100、并分析关联应用单元化监控,基于知识图谱快速完成故障分析,按照规则进行告警。(3)基础设施可观测(3)基础设施可观测基础设施中单元化相关的有:数据库、缓存、服务、消息、限流、定时任务等,提供单元化视角的聚合监控,指标按照产品覆盖原产品基础指标,可有效识别单元异常,提供更精细化的基础设施监控。对单元间的跨zone服务调用、消息等进行观测,不合理的流量除引起zone倾斜、链路耗时增加、用于架构设计、代码开发、变更等引入的异常情况进行治理。5.应急管理(1)数据库故障5.应急管理(1)数据库故障应急时自动执行主备切换,切换后主库和应用侧流量不在同一个单元可以接受,故障解决后,应在变更窗口实施主备切换,
101、恢复到主库和应用侧流量在同一单元。(2)应用侧故障(2)应用侧故障(a)流量切换与回切。应急时基于单元自动接管机制,框架侧可将流量自动切换到互备单元(基于健康检查),故障解决后,故障单元应用节点健康检查正常,流量可自动切回目标单元。(b)园区优先原则。框架侧基于园区优先规则对跨单元流量进行判断,如果上游节点触发了单元接管,下游各节点不会再60切回目标单元,而是在接管单元继续处理。(c)故障应急。如果VZone故障,应调整域名策略,快速隔离故障园区的VZone,由另一个园区接管生产流量。如果RZone故障,检查RZone自动接管是否生效(正常1到2min即可完成切换),如果未完成自动切换,需要人
102、工介入实施网络层(负载均衡设备或SLB)切换。如果GZone故障,检查GZone自动接管是否生效(正常1到2min即可完成切换),如果未完成自动切换,需要人工介入实施网络层(负载均衡设备或SLB)切换。6.变更管理6.变更管理在蓝绿发布中,应用按照zone划分为对等的蓝绿两组,每组包含所有的RZone和GZone,是一个完整的全业务逻辑架构。单元化架构是按照客户信息号进行了纵向切分,蓝绿发布中,需要对每组客户信息号对应的逻辑单元都进行堆成切分为A、B,例如:RZone01A、RZone01B,就是互为备份且共享数据库、缓存的两个单元。蓝绿发布的流量调拨可以分为以下5个阶段:一是日常状态下,A、
103、B两组分别承载单元各50%的流量,且基于流量的隔离需求,A和B之间的调用会进行隔离,不能跨单元访问。二是发布前,将“蓝”流量调配至0%,对“蓝”zone的应用进行发布部署。三是“蓝”发布完成,进行对“蓝”流量从1%进行引流验证,61有问题则流量调配为0后回滚;没有问题则逐步调配到100%。四是“蓝”引流100%后,此时“绿”流量为0%,对“绿”zone应用进行发布部署。五是“绿”发布完成,进行对“绿”流量从1%这个进行引流验证,有问题则流量调配为0后回滚;没有问题则逐步调配到50%,达到日常状态。7.性能容量管理(1)容量评估7.性能容量管理(1)容量评估系统容量评估主要为“资源供给”方面的容
104、量评估,结合基础技术架构,可在网络、数据库、存储、应用等方面开展。异地多活架构下需要结合业务容量、链路耗时、在离线混部等需求,体系化评估机房内、机房间、城市间的网络容量。单元化提供了数据库、存储、应用容量评估更精细化维度,深入挖掘每个单元的差异,发现潜在的性能或容量风险隐患,通过常态化监控推动容量弹性扩缩,在稳定生产的前提下,提高资源复用率。(2)全链路压测(2)全链路压测单元化提供给全链路压测更多可灰度空间,可以通过一个单元内的压测,控制压测过程中链路、应用、压测脚本等风险的影响范围,基于单元压测结构评估链路整体容量,再进行全部压测。压测过程中结合单元化的可观测能力,识别链路中性能和容量风险
105、的部署单元,进行容量调整。(3)容量自愈及多级流量管控(3)容量自愈及多级流量管控62基于性能容量监控并结合容量故障特征值进行综合分析判断,实现应用、单机的容量自愈,包括扩容、重启、限流等能力。单元化提供了单元间流量调拨的能力,在某个单元出现容量故障特征,而现有扩容无法及时解决时,流量调拨提供了业务无损的更高效应急自愈能力。限流中心中也需要按照单元进行精细化能力建设,提供单元机的限流策略、降级策略、熔断策略的基础上,提供单元机间的流量调拨策略,并建立规范化的预案管理、演练计划与实施等。四、金融业分布式信息系统运维发展趋势展望以大型银行为代表的金融机构在推进其信息系统向分布式架构转型的过程中,以
106、运维问题为驱动,开展了广泛的探索实践,积累了大量的经验教训,在运维架构规划及运维技术能力建设等方面取得了明显进展,初步构建了适应分布式架构的体系化运维解决方案。随着金融业数字化转型的积极推进,数字新技术不断涌现并在运维领域落地实践,推动着运维理念及方法的持续变革与演进,带来质量和效益提升。未来,金融业分布式信息系统运维将会呈现以下几个发展趋势。趋势一:知识图谱、机器学习等技术广泛应用于运维大数据分析,显著提升运维分析决策效率。趋势一:知识图谱、机器学习等技术广泛应用于运维大数据分析,显著提升运维分析决策效率。一是知识图谱结合多学科理论与方法,能够有效分析描述拓扑节点及相互联系,在分布式系统业务
107、异常下快速确定服务节点故障根因。二是基于机器学习算63法模型的智能运维技术与运维平台高度整合,建设服务化能力,并在监控应急、变更管控、性能容量等各场景发挥实效,形成数据驱动、人机协同的运维分析决策闭环。趋势二:数字人、机器人等技术广泛应用于运维例行化操作,极大减轻运维操作压力。趋势二:数字人、机器人等技术广泛应用于运维例行化操作,极大减轻运维操作压力。一是通过使用RPA(流程机器人),将重复性劳动进行自动化处理,解放大量需要人工参与的重复性人机接口交互的工作,在提高执行效率的同时避免用户操作错误。二是部署巡检类机器人,实现7X24小时无人值守巡检,替代重复、高频、高强度的低脑力劳动,将宝贵的人
108、力资源投入到更复杂和更有难度的运维工作中。趋势三:数字体验、混沌工程等技术广泛应用于运维风险管控,显著降低系统运行风险。趋势三:数字体验、混沌工程等技术广泛应用于运维风险管控,显著降低系统运行风险。一是使用元宇宙、数字孪生等数字体验技术,充分利用业务架构模型、集成多学科、多维度、多尺度、多概率的仿真过程,反映实体或者业务系统的全生命周期过程,可模拟业务运行走势,预测系统缺陷等。二是混沌工程让运维人员可以观测到系统应对混乱异常的能力,并通过主动制造故障、测试系统在各种压力下的行为,识别并修复故障问题,将指导运维人员有针对性地提升整体系统健壮性与韧性,更加游刃有余应对突发情况,建立对系统的信心。趋势四:低代码等技术广泛应用于运维工具研发,极大提升运维研发效能。趋势四:低代码等技术广泛应用于运维工具研发,极大提升运维研发效能。低代码理念所带来的组织模式变革和新开发模式,可将运维需求快速转化为产品交付,能够更好整合运维研发资源,64提高技术资产复用率,有效沉淀分享技术资产,从而实现业务研发运营一体化。65参考文献1中华人民共和国中央人民政府.关键信息基础设施安全保护条例.中华人民共和国国务院令第 745 号.2中国人民银行.金融科技发展规划(20222025).中国人民银行印发.3中国人民银行.金融业数据能力建设指引.中国人民银行印发.