案例 | 基于开源软件向敏捷运维转型的创新与实践
现如今，全球97%的软件开发者和99%的企业都已使用开源软件，随着开源软件使用的日益广泛，以开源技术运用为核心的新技术创新体系正在逐渐形成。2021年9月，人民银行联合多部委联合发布《关于规范金融业开源技术应用与发展的意见》（以下简称《意见》），对金融行业如何合规使用开源技术提供了管理框架和具体指导。贵阳银行积极学习领会《意见》的文件精神，坚持以促进中小银行的信息科技流程规范化、标准化、实现运维自动化为原则，以解决中小银行的生产运维问题、提升运维服务能力为切入点，推进基于开源软件的运维敏捷转型。
构建敏捷运维体系对中小银行是一项极具挑战性的工程，需要站在银行发展转型的高度，从战略管理、企业文化、组织架构、业务流程、制度规范、技术工具等多方面推进敏捷运维体系建设。本文聚焦在安全、可控、合规、开放的前提下，探讨如何运用开源软件解决生产运维中的难点，并提出一套向敏捷运维转型的技术方案。
中小银行科技工作的痛点与难点
1.历史包袱重。相对于大型银行，中小银行的信息科技建设工作起步较晚、发展速度较慢、历史包袱较重，存在大量建设时规范程度低、改造难度大的老系统。在不做应用系统新建迭代的情况下，开发工作向敏态转型的阻力很大；但在运维方面，可以率先尝试敏捷转型。
2.运维自动化水平低。在日常运维方面，对系统问题仍主要依靠人工手动执行维护操作，处理周期长、效率低，难以及时有效满足频繁爆出的软件安全漏洞修复要求。在灾备切换方面，因重要信息系统的应用节点数量众多，即便技术人员熟练掌握切换流程，若遇多套系统同时需要切换场景，容易出现人为操作风险，甚至可能存在无法在要求时间范围内完成操作的情况。
3.生产问题定位能力有限，监控指标精细化程度不足。贵阳银行技术人员前期通过持续的技术积累，自主开发的运维软件已经能够覆盖操作系统、数据库、应用的基础监控，但是随着系统数量增多、基础软件种类增长，监控功能不全面、监控指标设计不灵活的短板逐渐显现。
4.主流开源软件运维管控能力弱。贵阳银行生产系统使用Redis、Kafka、RocketMQ等通用型软件的比例逐年提高，这类软件完全依赖于人工手动配置，部署环境和版本管理的规范性、一致性不足，不仅对后期运维造成困扰，也存在一定的安全隐患。
针对上述问题，贵阳银行曾尝试引入闭源商业软件。但经测试与评估，我行发现这些软件虽然提供了友好的操作界面，但是功能接口封闭，自主可控程度低，难以满足银行定制化需求；同时使用闭源商业软件资金投入成本高，且存在技术路线绑定风险。为解决以上痛点，贵阳银行坚持以问题为导向，积极探索开源软件技术，目前在敏捷运维转型方面取得了一定实践成果。
实践成果
1.落实安全合规与管控。原生开源软件是一种“术业有专攻”的软件，很可能先天缺少合规防控、安全审计等模块，并不适宜在金融行业直接投产。贵阳银行坚决贯彻执行《意见》指出的“金融机构应当把保障信息系统安全作为使用开源技术的底线，认真开展事前技术评估和安全评估，堵塞安全漏洞，切实保证技术可持续和供应链安全，提升信息系统业务连续性水平”安全可控原则，结合本行信息科技流程、IT运行环境等实际因素，因地制宜、合理合规地对开源软件进行持续适配与优化。
我行主要在以下方面开展了相关工作：一是从制度层面进行规范。例如贵阳银行在建设基于Ansible的自动化运维平台的同时，拟定了《自动化运维调度平台管理制度》，从制度层面规定了自动化运维调度平台的管理制度、用户权限、调度审批的制度与流程。二是加强开源软件准入机制。我行将安全团队纳入开源软件的准入评估中，负责对备选开源软件进行安全扫描，确认软件的安全性、完整性、漏洞修复情况；同时规定开源软件投产前需要经多轮测试验证，并通过内部专业团队的技术评审，确保安全性。三是加强使用过程的管控能力。贵阳银行在原生开源软件基础上进行定制化开发，针对性地设计了事前审核、事中监控、事后审计三个模块，分别用于事前管控批量任务的配置、工单审批；事中监控批量调度执行情况、记录执行结果、告警非预期结果；事后监督审计以及回溯批量任务的流程，强化全流程的规范化管理。四是掌握开源软件许可的相关要求。在对开源软件定制化开发前和后续使用维护过程中，我行持续学习开源软件相关许可证的条款，包括GPLV3、BSD、Apache-License许可证的法律条款，确保在技术可持续与供应链安全的前提下使用开源软件。五是引入技术服务公司支持。引入外部的技术专家支撑，弥补中小银行运维人员少、技术能力覆盖不足的短板，做好关键技术的交流与赋能。同时在专家的协助下紧密关注开源软件、社区论坛的关键事件、重大安全事件、漏洞曝光事件等，及时评估事件对行内安全的影响程度。
2.建设自动化运维调度平台。综合评估贵阳银行的运维痛点、生产环境节点规模、系统部署架构、运维人员的技术知识背景及外部服务商的支持能力，贵阳银行在三种主流的开源自动化调度工具中选择了Ansible作为基础工具。
自动化运维调度平台的成效非常明显，例如本年度爆出的著名Log4j漏洞及后续发现的Polkit缺陷，若在前期通过运维人员手动修复漏洞，即便每日加班进行变更也仅能处理数十台，全部修复至少需要一个月有余。而通过该调度平台编制剧本并测试通过后可以在一周内完成漏洞修复的测试、灰度发布及正式发布。
3.实现重要信息系统容灾快速切换。针对信息系统容灾切换的场景，我们经过审慎评估，在自动化运维调度平台上，对现有容灾切换流程中应用启停、应用状态检查、数据对比、数据库切换、存储切换的脚本进行了编排，为各个重要信息系统制定了专用的切换剧本与回滚剧本。在剧本编写过程中，考虑到灾备切换流程复杂、涉及多个组件交互，我行根据实施经验，从流程安全控制与编排灵活性出发，对原有脚本进行了拆分，保证剧本中模块的原子性，在实现快速定位问题功能的同时，也实现了模块的复用，易于后期维护。
通过调度剧本执行容灾切换，有效避免了人为操作风险，并且可多个系统并发切换，质效均得到提升。同时自动化切换解放了运维生产力，使运维人员能够将关注点从执行重复性操作转移到业务系统间的关系与容灾切换流程中，为后续进行同城双中心轮动运行打下了坚实的基础。
4.迭代基础监控与巡检平台。贵阳银行前期自研构建了Java代码与Shell脚本组合的统一监控平台。该平台虽实现了对操作系统基础环境、数据库、应用服务等方面的监控，但是监控指标灵活度不高，下钻深度不够，缺少精细化数据指标，监控巡检覆盖不足。
Zabbix监控软件对传统稳态IT架构及物理服务器的适配性较好，监控指标覆盖面广，并且提供了广泛的原型模块，用户可以根据自身需求进行定制开发，对后续扩展监控指标，实现自主创新非常有利。我行选择Zabbix监控软件实现对非数值型指标的采集，并基于JMX组件二次开发，对传统稳态架构中的中间件线程运行状态、数据源配置、服务与集群配置、JVM参数等采集，有效弥补了Prometheus监控的短板。目前该系统已应用于全行上百个中间件节点，解决中间件巡检依赖手工检查的痛点，效率明显提升。后续计划逐步推进至其他基础组件的巡检与监控，尝试完成业务系统应用程序的巡检。
5.加强主流开源中间件的运维管控。为妥善、安全地管控开源反向代理软件、消息中间件、缓存中间件、链路跟踪模块、注册中心软件等产品，贵阳银行以新核心系统项目的推进为契机，引入了金融PaaS平台产品。对比互联网公司提供的同类产品，该产品的突出优势在于设计时充分考虑了国内金融行业的特点，有效整合了存量IT资产，无需改造现有生产环境。
心得与经验
通过实践验证，用好开源软件，可以切实帮助运维团队解放生产力，实现运维工具自主可控，提升业务连续性保障能力，助推敏捷运维转型，起到事半功倍的效果。同时开源技术的运用也有助于提升运维人员视野、提高运维团队整体水平和服务质量。
但同时必须清醒地意识到开源软件存在局限性，不能“包治百病”。例如我行前期尝试引入基于Prometheus与Grafana的集中式存储与SAN交换机监控平台，但实际部署后发现监控模块与多个生产环境设备存在版本兼容性问题，并没有达到预期的性能监控效果。因此在开源软件选型与实践过程中，要做好技术路线风险控制，根据软件能力以及运维团队的实际情况选择合适的软件产品。
开源软件的灵活性、透明性和高度可定制化，在中小银行实现敏捷运维转型体现了实用性的意义，后续我行也将不断加深探索、加强应用，灵活运用开源技术构建更为科学高效的运维体系。
（栏目编辑：张丽霞）
往期精选：
（点击查看精彩内容）
新媒体中心：主任 / 邝源 编辑 / 傅甜甜 张珺 邰思琪