中小银行基于开源软件向敏捷运维转型的创新与实践

字数 4977阅读 1211评论 0赞 8

内容摘要：

中小银行向敏捷运维转型需解决历史包袱、自动化、生产问题定位、开源软件管控等难点。某城商行通过安全合规、自动化运维、容灾快速切换、金融PaaS平台等实践，取得一定成果。开源技术可提高运维团队整体水平和服务质量，但需控制技术路线风险，选择合适软件产品。

当前摘要为AI生成

现如今，全球97%的软件开发者和99%的企业都已使用开源软件，随着开源软件使用的日益广泛，以开源技术运用为核心的新的技术创新体系正在逐渐形成。2021年9月，人民银行联合多部委联合发布《关于规范金融业开源技术应用与发展的意见》（以下简称《意见》），对金融行业如何合规使用开源技术提供了管理框架和具体指导。某城商行积极学习领会《意见》的文件精神，坚持以促进中小银行的信息科技流程规范化、标准化、实现运维自动化为原则，以解决中小银行的生产运维问题、提升运维服务能力为切入点，推进基于开源软件的运维敏捷转型。

构建敏捷运维体系对中小银行是一项极具挑战性的工程，需要站在银行发展转型的高度，从战略管理、企业文化、组织架构、业务流程、制度规范、技术工具等多方面推进敏捷运维体系建设。本文聚焦在安全、可控、合规、开放的前提下，探讨如何运用开源软件解决生产运维中的难点，并提出一套向敏捷运维转型的技术方案。

# 一、中小银行科技工作的痛点与难点
（一）历史包袱重。相对于大型银行，中小银行的信息科技建设工作起步较晚、发展速度较慢、历史包袱较重，存在大量建设时规范程度低、改造难度大的老系统。在不做应用系统新建迭代的情况下，开发工作向敏态转型的阻力很大；但在运维方面，可以率先尝试敏捷转型。

（二）运维自动化水平低。在日常运维方面，对系统问题仍主要依靠人工手动执行维护操作，处理周期长、效率低，难以及时有效应满足频繁爆出的软件安全漏洞修复要求。在灾备切换方面，因重要信息系统的应用节点数量众多，即便技术人员熟练掌握切换流程，若遇多套系统同时需要切换的场景时仍然容易出现人为操作风险，甚至可能存在无法在要求时间范围内完成操作的情况。

（三）生产问题定位能力有限，监控指标精细化程度不足。某城商行技术人员前期通过持续的技术积累，自主开发的运维软件已经能够覆盖操作系统、数据库、应用的基础监控，但是随着系统数量增多、基础软件种类增长，监控功能不全面、监控指标设计不灵活的短板逐渐显现。

（四）主流开源软件运维管控能力弱。某城商行生产系统使用Redis、Kafka、RocketMQ等通用型软件的比例逐年提高，这类软件完全依赖于人工手动配置，部署环境和版本管理的规范性、一致性不足，不仅对后期运维造成困扰，也存在一定的安全隐患。

针对上述问题，某城商行曾尝试引入闭源商业软件。但经测试与评估，我行发现这些软件虽然提供了友好的操作界面，但是功能接口封闭，自主可控程度低，难以满足银行定制化需求；同时使用闭源商业软件资金投入成本高，且存在技术路线绑定风险。为解决以上痛点，某城商行坚持以问题为导向，积极探索开源软件技术，目前在敏捷运维转型方面取得了一定实践成果。

# 二、实践成果

## （一）落实安全合规与管控
原生开源软件是一种“术业有专攻”的软件，很可能先天缺少合规防控、安全审计等模块，并不适宜在金融行业直接投产。某城商行坚决贯彻执行《意见》指出的“金融机构应当把保障信息系统安全作为使用开源技术的底线，认真开展事前技术评估和安全评估，堵塞安全漏洞，切实保证技术可持续和供应链安全，提升信息系统业务连续性水平”安全可控原则，结合本行信息科技流程、IT运行环境等实际因素，因地制宜、合理合规地对开源软件进行持续适配与优化。

我行主要在以下方面开展了相关工作：

一是从制度层面进行规范。例如某城商行在建设基于Ansible的自动化运维平台的同时，拟定了《自动化运维调度平台管理制度》，从制度层面规定了自动化运维调度平台的管理制度、用户权限、调度审批的制度与流程。

二是加强开源软件准入机制。我行将安全团队纳入开源软件的准入评估中，负责对备选开源软件进行安全扫描，确认软件的安全性、完整性、漏洞修复情况；同时规定开源软件投产前需要经多轮测试验证，并通过内部专业团队的技术评审，确保安全性。

三是加强使用过程的管控能力。某城商行在原生开源软件基础上进行定制化开发，针对性地设计了事前审核、事中监控、事后审计三个模块，分别用于事前管控批量任务的配置、工单审批；事中监控批量调度执行情况、记录执行结果、告警非预期结果；事后监督审计以及回溯批量任务的流程，强化全流程的规范化管理。

四是掌握开源软件许可的相关要求。在对开源软件定制化开发前和后续使用维护过程中，我行持续学习开源软件相关许可证的条款，包括GPL V3、BSD、Apache-License许可证的法律条款，确保在技术可持续与供应链安全的前提下使用开源软件。

五是引入技术服务公司支持。引入外部的技术专家支撑，弥补中小银行运维人员少、技术能力覆盖不足的短板，做好关键技术的交流与赋能。同时在专家的协助下紧密关注开源软件、社区论坛等的关键事件、重大安全事件、漏洞曝光事件等，及时评估事件对行内安全的影响程度。

## （二）建设自动化运维调度平台
综合评估某城商行的运维痛点、生产环境节点规模、系统部署架构、运维人员的技术知识背景以及外部服务商的支持能力，某城商行在三种主流的开源自动化调度工具中选择了Ansible作为基础工具（选型对比见表1）。最终选中Ansible的重要原因是行内信息系统Linux占据绝大多数，aix小型机已逐渐下移淘汰，windows系统一般也不再作为业务系统使用，且ansible基于python语言开发，易于运维人员掌握。

![表1.主流开源自动化调度工具对比](/home/attachment/202310/29/1234113_169856226756031.png)

Ansible在linux系统之上运行不需要额外安装python依赖包（linux已默认安装），内置模块也提供了丰富的运维模块，包括但不限于用户管理、服务管理、文件系统、网络配置；而在aix小型机上运行，即使安装了python依赖包，能够调用的内置模块也很有限，仅能做到设备、文件系统、软件包的管理功能。对于windows系统，ansible的运行依赖于Powershell与.Net依赖包，只有在Windows Server 2012以上才能流畅运行 。

在定制Ansible的“剧本”（即Ansible的Playbook模块，定义了批量任务的执行过程）过程中我们意识到，定制一个剧本的本质是将运维过程与经验转化成一行行的代码脚本，而对于如何控制好剧本在生产环境的风险，则是运维团队面临的新挑战。

对此某城商行组织运维人员学习了Ansible相关剧本的开发方法，积极由传统运维向敏捷运维转型，并要求运维人员按照应用开发上线的流程对剧本的设计、开发、变更、上线流程进行管理。

自动化运维调度平台的成效非常明显，例如本年度爆出的著名Log4j漏洞以及后续发现的Polkit缺陷，若在前期通过运维人员手动修复漏洞，即便每日加班进行变更也仅能处理数十台，全部修复至少需要一个月有余。而通过该调度平台编制剧本并测试通过后可以在一周内完成漏洞修复的测试、灰度发布及正式发布。

## （三）实现重要信息系统容灾快速切换
针对信息系统容灾切换的场景，我们经过审慎评估，在自动化运维调度平台上，对现有容灾切换流程中应用启停、应用状态检查、数据对比、数据库切换、存储切换的脚本进行了编排，为各个重要信息系统制定了专用的切换剧本与回滚剧本。在剧本编写过程中，考虑到灾备切换流程复杂、涉及多个组件交互，我行根据实施经验，从流程安全控制与编排灵活性出发，对原有脚本进行了拆分，保证剧本中模块的原子性，在实现快速定位问题功能的同时，也实现了模块的复用，易于后期维护。

通过调度剧本执行容灾切换，有效避免了人为操 作风险，并且可多个系统并发切换，质效均得到提升。同时自动化切换解放了运维生产力，使运维人员能够将关注点从执行重复性操作转移到业务系统间的关系与容灾切换流程中来，为后续进行同城双中心轮动运行打下了坚实的基础。

## （四）迭代基础监控与巡检平台
某城商行前期自研构建了java代码与shell脚本组合的统一监控平台。该平台虽实现了对操作系统基础环境、数据库、应用服务等方面的监控，但是监控指标灵活度不高，下钻深度不够，缺少精细化数据指标，监控巡检覆盖不足。

Prometheus监控软件对云原生环境的软件指标支持较好，选择其对操作系统软件性能监控也取得了良好的效果。Prometheus以KEY-VALUE与时序数据库实现精细化指标地采集，这样的技术特征支持快速变数字的录入，恰到好处地弥补了某城商行前期自行开发的Shell脚本监控对linux操作系统底层性能数据采集不够精细与深入的缺点。同时结合开源的Grafana图形化软件，可对Prometheus的监控数据进行分析与可视化展现，能够有效协助运维人员快速定位系统故障：例如我行在实际应用中，曾通过TCP协议的segment retrans参数地实时监控，及时发现了负载均衡设备与应用系统之间TCP重传的问题，结合历史性能数据记录，快速定位故障开始时间，缩短了问题排查周期，减少了故障影响程度。这对精准定位系统异常、解决生产故障有着非常积极的作用，同时也体现了开源软件的技术能力在构建敏捷运维体系中的价值。

Zabbix监控软件对传统稳态IT架构以及物理服务器的适配性较好，监控指标覆盖面广，并且提供了广泛的原型模块，用户可以根据自身需求进行定制开发，对后续扩展监控指标，实现自主创新非常有利。我行选择Zabbix监控软件实现对非数值型指标的采集，并基于JMX组件二次开发，对传统稳态架构中的中间件线程运行状态、数据源配置、服务与集群配置、JVM参数等采集，有效弥补了Prometheus监控的短板。现该系统已应用于全行上百个中间件节点，解决中间件巡检依赖手工检查的痛点，效率明显提升。后续计划逐步推进至其他基础组件的巡检与监控，尝试完成业务系统应用程序的巡检。

## （五）加强主流开源中间件的运维管控
为妥善、安全地管控开源反向代理软件、消息中间件、缓存中间件、链路跟踪模块、注册中心软件等产品，某城商行以新核心系统项目地推进为契机，引入了金融PaaS平台产品。对比互联网公司提供的同类产品，该产品的突出优势在于设计时充分考虑了国内金融行业的特点，有效整合了存量IT资产，无需改造现有生产环境。

该平台通过统一门户界面对Redis、Kafka、RocketMQ等软件统一管理，实现了页面交互式资源申请，并通过预先定制的软件版本与集群参数完成部署，有效替代了运维手工集群部署，规避了人工误操作风险、软件配置不统一、版本难以控制的问题。实现了提升交付效率，降低运维复杂度，增强安全管控的目标。

# 三、心得与经验
通过实践验证，用好开源软件，可以切实帮助运维团队解放生产力，实现运维工具自主可控，提升业务连续性保障能力，助推敏捷运维转型，起到事半功倍的效果。同时开源技术的运用也有助于提升运维人员视野、提高运维团队整体水平和服务质量。

但同时必须清醒地意识到开源软件存在局限性，不能“包治百病”。例如我行前期尝试引入基于Prometheus与Grafana的集中式存储与SAN交换机监控平台，但实际部署后发现监控模块与多个生产环境设备存在版本兼容性问题，并没有达到预期的性能监控效果。因此在开源软件选型与实践过程中，要做好技术路线风险控制，根据软件能力以及运维团队的实际情况选择合适的软件产品。

开源软件的灵活性、透明性和高度可定制化，在中小银行实现敏捷运维转型体现了实用性的意义，后续我行也将不断加深探索、加强应用，灵活运用开源技术构建更为科学高效的运维体系。

# 四、参考文献
1. 《关于规范金融业开源技术应用与发展的意见》，中国人民银行等多部委
2. 《关于银行业保险业数字化转型的指导意见》，中国银行保险监督管理委员会
3. 《商业银行业务连续性监管指引》，中国银行保险监督管理委员会
4. 《Ansible Automation Platform E-book》，Redhat公司
5. 《Zabbix产品技术手册》，Zabbix中国开源社区
6. 《Prometheus技术文档》，Prometheus技术社区

敏捷运维 Prometheus 集中式存储 Ansible 开源软件

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

中小银行基于开源软件向敏捷运维转型的创新与实践

添加新评论0 条评论

文章目录收起目录

作者其他文章

相关文章

相关问题

相关资料