《金融业分布式信息系统运维技术研究报告》

金融业分布式信息系统运维技术研究报告目 录一研背景 1（）金业信系统速向布式构演进 1二）融业分式息系运能力足 1三）策引高量建分布信息统运保障力 2（）金业分式信系统维技研究标 4二金融分布信息统运能力架 4（）运目标 4（）运架构划 5（）运管理障 7三金融分布信息统运技术力建设 10（）监发现 10（）应管理 18（）变管理 26（）性容量理 37（）运技术台 48（）单化架及运配套力建设 55四金融分布信息统运发展势展望 62参文献 65V一、研究背景（一）金融业信息系统加速向分布式架构演进金融业信息系统过去主要采用以IOE为代表的集中式架构，2015（二）金融业分布式信息系统运维能力不足（三）政策引导高质量建设分布式信息系统运维保障能力为加强企业IT系统稳定性提出了更高的标准和更严的要求，如国务院公布的（2022—2025年1。由此观之，政策要求各行业的运维团队培养良好的系统稳定性保障观念，做好风险管控，提升运维效能。时间机构时间机构政策名称相关政策2021年4月国务院《关键信息基础设施安全保护条例》建立信息共享机制、建立健全监测预警制度、明确网络安全事件应急处置要求。2022年1月中国人民银行《金融科技发展规划（2022—2025年）》强调高质量推进金融数字化转型。2022年1月原中国银行保险监督管理委员会《关于银行业保险业数字化转型的指导意见》提出“建立能够快速响应需求的敏捷研发运维体系”。202111原中国银行保险监督管理委员会《关于银行业保险业支持高水平科技自立自强的指导意见》坚持风险可控。统筹发展与安全，完善风险控制机制，提升科技金融风险管理能力。202110中国证监会科技监管局《证券期货业科技发展“十四五”规划》强调遵循四项原则，其中第一项为“稳字当头稳中求进”。201112原中国银行保险监督管理委员会《商业银行业务连续性监管指引》商业银行应当将业务连续性管理纳入全面风险管理体系。、（四）金融业分布式信息系统运维技术研究目标以大型银行为代表的金融机构在推进其信息系统向分布式二、金融业分布式信息系统运维能力框架（一）运维目标金融业信息系统运维的本质是服务金融业务，总体目标为“生产安全稳定”以及“服务重质高效”（如图1所示），即在保障业务连续性的同时支持业务快速创新，并提升运维效能。图1运维目标梳理（二）运维架构规划运维架构规划遵循如下重点原则。二是加强运维体系的整体设计，夯实运维服务和运维数据图2运维架构规划/资产不在本报告研究范围内。PaaSIaaS（三）运维管理保障优化运维组织管理基本组织结构金融业分布式信息系统的运维组织架构是在传统信息系统3图3运维组织建设纵向上，以业务场景为边界，围绕监控、应急等运维核心工作开展链路化运维管理，强化信息系统对业务发展的价值贡献。专项上，针对信息系统运维的关键领域建设技术团队，实现新技术的迭代和系统的持续发展。业务运维单元组织管理单体应用为运维管理粒度的运维模式无法满足高效排查处置问业务运维单元是结合金融主体业务领域划分及生产运维实2人进行主备。运维专业领域组织管理SRE（SiteReliabilityEngineer，站点可靠性工程师）是SRE、基础SRE，分别承担业务单元、技术支撑平台、基础设施领域的运维工作。SRE角色不仅仅负责信息系统面向SRE使用的运维专业领域技术与平台，需要配备专业的（TransformandLoad，抽取转换与加载完善运维制度规范，建立运维质效评价管控机制二是加强规范标准的硬控制措施，随着运维工具体系建设，完善监控、变更、应急、容灾、性能容量等相关领域的标准化，以及相应的规范标准检查自动化。三是完善业务线/应用条线的运维成熟度评估体系，通过监控发现、业务可用率、故障恢复时效等核心指标责任共担的方式，发团队的应用负责人工作评价可酌情参考应用质量评估结果和运维KPI指标。三、金融业分布式信息系统运维技术能力建设IT基础架构向多地多中心及（一）监控发现分布式架构下监控面临的挑战继续发挥作用。五是金融业传统监控体系构建于集中式信息系统架构之上，与当时的运维模式相匹配。但当核心信息系统演进到分布式架构时，监控体系自身也需要转型变革，以满足新阶段运维需求。六是受到技术状态限制，以往监控数据采集/刷新频度一般处于分钟级水平，对象颗粒度较粗，对异常的探测捕捉能力弱、响应慢，需要引入新技术栈等手段加以解决。分布式架构监控体系设计在监控体系设计上应遵循以下原则：一是平台功能支持传统架构与分布式架构下的全业务监控模式，应涵盖运维业务的各个领域，包括监、管、控、服、安全、大数据及人工智能等多方面，如图4所示。图4一站式监控功能架构分布式监控体系监控范围分布式监控体系的监控范围涵盖从业务到基础设施的各层从运维数据类型上看，至少包含日志、指标、链路、配置、事件等五类数据源。分布式监控体系重点能力建设由于分布式架构信息节点数量众多、运行数据信息量极大、复杂性较高，因此需要重点开展如下几方面能力建设。运维数据采集能力运用可观测性（Observability）理念，通过对各类系统、的记录，为进一步评估业务服务水平提供依据。业务拓扑绘制能力大数据处理及智能分析能力（节点数其次，通过数据中台等形式，集中化存储和处理全体系下的运行指标，再基于机器学习KPI异常检测模型建立阈值智能监控第三，针对告警事件做到智能地过滤、压缩、合并、丰富、去重、升级，辅以业务系统、时间、IP等维度等数据加以融合，架构开放能力集中管控能力新时期面向业务的监控体系，在实现各类运维数据充分融合（物理机/虚拟机配置规格（（单元化部署）、技术架构（技术栈、服务API接口、日志规范）等多个层面，采取标准化设计，以降低建设、整合、维护难度。监控模板化。内置精炼的必需监控模板，支持自定义配置一站式。对参数设置、算法模型、告警规则、通交互可视化。提供以业务为视角、主动发现业务故障自监控能力传输、存储、分析路径，还应提供心跳检测等对内自监控能力，及时发现自身异常情况并成功发出通知，提醒运维人员加以干预处理，以免呈现“伪健康”状态，影响用户判断决策。（二）应急管理分布式信息系统转型下应急管理面临的困难数据中心在应急管理层面所面临的困难有以下几个方面：应急的复杂度更高业务连续性要求更高/每秒的读写请求。同时，客户对金融业务的连续性要求很高，特别是对银行等金融组织，原则上要求7X24小时不间断服务。硬件设备故障概率增大越来越多的信息系统采用分布式架构来突破单机性能瓶颈，分布式信息系统在应急管理方面的优势（应急管理目标与体系建设5所示的模型。图5应急管理体系分布式架构下各系统组成部分的相互关系及作用发生了较分布式信息系统下的应急管理建设方案为应对分布式信息系统转型对应急管理造成的影响与压力，应急管理需要积极作出应对和转变。基于不同金融企业规模、投入产出比、难易度等依次提出如下建设方案。事中阶段，建设应急事中平台、标准化应急工具。（的录放、灵活组合展示和在线编辑，快速实现应急过程复盘。故障管理故障管理包括故障复盘和故障要素记录两部分主要功能。应急事中管理应急，及时有效地将应急故障消息发送至应急组织架构人员，启动应急视频会议；二是应急事中消息实时共享；三是应急复盘。应急预案管理（——应急预案场景标准化。应急预案场景按梯队划分管理，——场景管理边界清晰化。建立以业务运维单元为维度的应应急处置需要对故障事件进行诊解，或者是否可以通过决策树/排障树等智能诊断平台做出相应快速处置一键式应急处置主要使用的是应急工具。自愈管理。应急处置中，第一时间恢复生产为第一要容灾演练演练线上化管理常态化开展应急实战演练关于异地灾备恢复演练。金融机构需要定期开展灾备演练，有序开展混沌演练（三）变更管理金融业科技发展过程中变更管理变化及现状IT运维的发展，ITIL（如：ServiceDesk、HelpDesk等，或第三方开发的流程管理产品分布式信息系统转型下变更管理面临的挑战变更数量增长迅猛分布式架构的特点就决定了系统整体规模的几何倍数扩张，并导致基础环境等维护类变更数量同比增长。新应用系统上线的环境搭建数量也较传统集中模式有较大增长。互联网金融业务需求快速变化，敏捷、DevOps等软件开发实践导致应用版本上线频率显著提高。变更方案复杂度提高相对于集中式环境，分布式环境信息收集工作有所增（分布式转型引入了大量新技术、开源软件，迅速进行变更风险控制力下降由于变更数量增加和架构转变，引发了变更风险的质变。传统的专家型等变更风险评估体系面临严重压力。应用层和基础架构层尚未完全解耦前，基础环境类变金融业务发展对应用版本持续部署的强烈需求，与IT系统稳定运维之间存在着直接矛盾。业务连续性等级提升分布式架构带来更为丰富的变更管理手段变更业务影响降低（功能模块（容错性变更实施风险控制变更管理的目标与管理体系建设IT变更管理目标及管理体系建设要同时具备一定的通用性和特殊性。变更管理目标变更效率提升。体现为：智能评估、智能防御、自动化执行到智能执行（执行过程智能监控、调度、回滚）。变更风险控制在可接受范围内。变更流程按阶段可以分为：变更采集、变更通知、变更评估（方案、风险、影响）、变更测试/模拟、变更灰度实施、变更防御、变更监控、变更止血。评估效率、自动化执行率、智能防御覆盖率、智能防御效率等。分布式信息系统下的变更管理建设方案图6变更管理业务模型为应对分布式信息系统转型对变更管理造成的影响与压力，标准化变更建设。作为ITIL原有的变更管理最佳实践（中大型银行等金融企业IT规模庞大，有限的人力面对快速扩张的IT智能化变更建设。在这一变更模式下，IT系统将根据（或者也交由系统自动判断此外，还需做好以下两方面能力建设。一方面，远程变更能力建设。分布式架构的核心特点就是多地部署，同时金融企业为了提高IT系统的可用性、容灾性等，近年来都在进行同城双活、异地多活、异地灾备等数据中心建设。从IT另一方面，变更风险防控能力建设。变更最大的难点不在于变更风险防控体系变更信息收集。变更信息来源从组织层面覆盖了组织（从环IaaS风险评估。组织变更风险专家组评审，有效识别变更过程中的风险，并梳理应对措施。风险模拟。在仿真平台进行变更实施模拟，仿真环境执行防御。根据不同的变更场景类型、作用对象重要察其成败与影响。度量防控效果。通过对变更防控效果进行度量，持续拦截准确率、防御执行效率等。防控体系如图7所示：图7变更防控体系简图变更灰度/分批风险防控模式分布式架构下，计算节点、数据库节点高度自治，使得灰度/分批的变更防控模式得以实现，其防控能力得以充分发挥。由/分批策略的变更防控架构的结合，也要遵循以下几个必要条件。固定流程的执行流水线（强制风险发现/步骤可控）：——执行按照预发/灰度/生产批次进行——环境间/批次间串联变更分批执行能力（控制风险范围）：——变更的生效需要能够区分环境——线上环境按批次生效前后置防御校验（风险发现）：——前置阻断变更、后置发现问题/阻断下一批次——变更每批次的前后置需要布防基于变更灰度/分批执行的流水线如图8所示。图8变更灰度流水线基于分布式信息系统的业务软件部署部署原则。明确部署全流程中，部署流水线、文档、部署环境的对应关系及完备性要求。部署策略。明确部署策略要包含灰度策略、技术业务行部署。风险管控加强合规风险控制。验证体系后评估。部署过程的效能、中断、验证、回退等环节应可度量、可视化。软件产品灰度发布管理流程作为持续部署实践中一个最重要的软件产品发布策略之一，分布式架构的业务系统软件产品通过灰度发布的模式，有效地控制了新业务上线风险，提升了对客服务的连续性。基本原则。根据不同应用、业务系统，或产品线重要（和（即有独立的灰度应用群组风险控设计原则。灰度发布设计原则应考虑上下游的投产部/系统行的业务流/交易流的全链路灰度发布模式将是后续的发展方向。部署原则。明确并制定灰度部署全套流程的控制要求量爬坡、转正。配置原则。分布式系统的环境和程序配置信息应纳入分布式配置中心统一管理。变更管理体系建设的难点及提升方向难点1：分布式架构设计复杂，技术多样性与服务多变使得提升措施：二是利用模拟执行与灰度流水线执行等措施开展智能防御，通过智能分批监控识别变更对象、对象上下游、对象关联链路、对象关联业务等判断变更的影响，提升变更风险识别能力。难点2：金融行业对于业务连续性及产品迭代的高频需求与相对保守滞后的变更管理模式的冲突。提升措施：一是完善优化分布式架构下变更技术手段，通过灰度投产、全链路灰度投产模式的持续推广，降低产品部署风险和业务影响范围。研究并制定分布式下的变更管理新模式与流程。（四）性能容量管理分布式架构下性能容量管理的挑战与机遇IT信息系统架构愈加复杂，分布式环境受服务器资源、移动互联、数字化等新技术、新业态赋能业务发展，IT系统的稳定性带来巨大冲击。服务器的爆发式增长导致机房等基础设施资源紧张，患的矛盾。弹性伸缩：是根据业务需求和策略自动调整计算能力（容器实例数量资源混部：是在云原生架构建设过程中进行在线和离线集群效调度算法和智能化的容量计算模型等技术手段完成资源的合理利用，提升资源错峰高效利用水平，降低IT成本。资源池化：资源池化是将服务器物理资源抽象成逻辑资源，CPUI/O等硬件变成可以性能容量管理目标二是建立完整的全链路压测方案。建设压测管理平台，通过压测风险控制及配套技术手段解决测试环境压测不准确等问题。三是建设容量自愈及多级流量管控体系。提供各类流量服务检测和调拨服务，支撑网络接入层、应用接入层、应用服务层、数据服务层等多级交易流量灵活调度。性能容量管理体系建设性能容量管理体系建设闭环如图9所示。9提升资源管控水平重点业务的全链路梳理链路梳理是保障工作的基础和开始，如同对整体应用系统进该阶段工作需要从应用和系统层面入手。应用链路梳理工作一般根据前期明确的据库的情况，为后续的“流量预算”“容量评估”工作做准备；性能容量平台建设在性能容量管理平台中纳管应用性能容量和系统性能容量——应用容量评估测业务应用系统云基础设施未来的使用情况以及为满足预计的目前行业主流通过TPC-C、排队论来作为容量评估的专业手段，其中前者是作为基准方法，后者排队论更加精准（排队论是研究系统随机聚散现象和随机服务系统工作过程的理论和方法，又称随机服务系统理论，为运筹学的一个分支）。——系统容量评估cpucacheTPS，每秒数据大小计算出网络容量。建立体系化评估方法及流程——事前评估。在特殊业务时期、业务营销推广、重大项目——事中监控。加强对重点时段、重点业务的监控；建立关（——事后调优。根据生产性能容量分析结果，结合业务实际全链路压测管理全链路线上压测方案全链路压测的核心思想是借助流量打标、数据隔离等技术，复用生产软硬件资源实施压测，同时又避免了压测流量对生产业务数据的污染。常用的有两种改造方式：二是非侵入式Agent动态增强。该方案灵活度高，可复制性强，接入成本低，但是存在一定运维操作风险，如agent接入遗漏等。三是全链路风险熔断。两个系统之间服务通信将会有白黑名单开关来控制流量流入许可。全链路线上压测平台建设——搭建模式一是使用外部压力测试服务商发起压力：外购发压服务，可按照压力发起服务的发起次数及能力进行计费付费。——压测工具选择Jmeter和Gatling作为全链路压测平台的底层发压工具。——测试监控压测过程中，对系统、业务交易各项指标（例如TPS、QPS、交易成功率、失败率、错误日志查询等）的监控是定位问题和衡量压测效果的重要工具：一是系统层面的性能监控可复用生产运维的监控体系。三是压测工具监控。压测过程中，需要对压测机资源进行整实施全链路线上压测——压测实施方案制定一是压测相关方在压测前后期间的配合工作。二是压测时间窗口及具体安排。五是场景监控方案及监控指标。六是压测所需的其他文档，例如应急方案、数据清理方案等。——压测准备工作一是系统程序版本及环境就绪。二是测试环境程序测试验收及脚本测试完成。（根据前期对系四是监控系统调整就绪。五是第三方资源协调就绪，根据业务系统全链路分析，对第三方资源进行容量预估，并告知第三方进行环境资源协调准备。——压测实施过程——压测结果分析一是记录各个压测场景的实施时间。二是收集压测期间交易、系统、网络各个维度的监控数据。三是记录压测过程中发生的各类问题。容量自愈及多级流量管控容量应急自愈10图10容量自愈流程多级流量管控/调度——限流中心建设。建立统一的限流熔断治理能力平台，统——限流/调度能力覆盖。限流/调度需要做到系统组件全覆盖，包括接入层、网关层、应用层、消息、缓存、数据访问等。同时提供丰富的限流能力。——限流/调度统一规范。建立限流/调度的统一实施规范，包括全局限流策略、降级策略、熔断策略，以及实施标准等。限流/调度需要建立规范化的管理流程，包括预案的编排保鲜，演练计划实施、风险检查等。（五）运维技术平台化工具提供服务调用，从而构建全方位一体化的运维工具体系，实现运维效率和质量提升。如图11图11运维技术平台框架运维数据中台运维数据中台建设目标12图12运维数据中台功能架构运维数据体系建设方式将运维对象在运维活动中产生的属性状态信息转换为规范从“原料”到“产品”的价值转化。一是推进数据的分层体系建设，具体包含：聚合层：从运维领域完整性角度重新组织数据，建立标准化的数据连接聚合的基础，形成运维公用数据层，避免重复建设。图13运维数据资产体系框架三是重视配置管理的优化工作，研究通过更为准确、快速、完整的方法来提升配置数据的完整性和准确性，提供业务拓扑可视化展现能力，对众多关联运维系统形成有效支撑。比如工商银运维数据智能分析能力建设运维数据运营能力建设运维服务平台运维服务平台建设目标图14运维服务平台功能架构IaaSPaaS运维服务平台价值一是实现专业运维服务的封装与集成。通过运维服务平台的建设，将专业运维服务以API接口或脚本的原子能力进行集成，IaaS云等关键基础设施故障场景的快速切换能力，大幅提高生产应急效率。二是实现生产运维管理全流程自动化。面向运维管理场景，得了阶段性成绩，在应用版本交付流水线覆盖率已达95以上，投产交付实施成功率达到92以上。三是实现运维操作风险管控自动化。提升运维服务自动化能（六）单元化架构及运维配套能力建设背景一是异地场景下的访问延时问题，实现异地多活。二是单机房数据库连接限制问题，突破物理限制。四是发布变更恢复问题，支持恢复发布。容灾方面分布式架构下，系统在面临一些单机故障时，往往可以