依靠大型机主导的金融服务数字化转型

本篇是大型机现代化五部曲系列的第三部分。

既然前文已说明大型机现代化并不仅限于金融行业，我们不妨直面核心议题：全球最严峻的现代化挑战正集中于银行业。

在互联网与云计算尚未普及时，在智能手机与移动应用还未问世前，银行机构就已在通过大型电子结算网关处理支付业务，并将大型机系统作为核心数据记录载体。

金融服务企业被视作现代经济支柱，因其掌管并驱动着全球金融体系的核心命脉。而维系这些金融机构高效运转的心脏，正是 IBM大型机。

若银行能成功将其大型机应用与数据资产提升至现代云化标准，实现灵活敏捷、支持创新的客户服务模式，则将收获最大红利；反之则可能面临最大损失。

从2008年"大而不能倒"的金融危机，到如今疫情后高利率导致部分大型存款银行过度暴露风险乃至破产，我们都亲身经历了这些全球经济动荡。

虽然银行倒闭通常源于管理决策与政策失误，但将部分责任归咎于滞后的现代化举措也合情合理。高管们难道不能通过更精准的数据分析识别风险吗？为何迟迟无法推出新的移动应用？是否曾遭遇黑客攻击导致客户无法访问？

众所周知，推迟大型机应用现代化会带来机会成本，但业界普遍认为更改当前支撑业务运营的系统存在风险。

社区银行和地区性银行可能缺乏技术资源，而大型机构则背负着沉重技术债务、面临高重力数据迁移难题，或受困于商业模式论证。

各类银行机构很可能都已遭遇过一次或多次现代化或迁移项目的失败。随着计划搁浅，企业的 IT 负责人往往感到力不从心。

现代化转型不应要求对大型机代码进行全盘重写，也无需开展费时费力的直接迁移。相反，团队应根据企业最核心的诉求，有针对性地推进现代化进程。

以下是几家银行的成功案例，它们不仅重启了现代化进程，更在高度分布式软件架构和当今严苛客户体验要求的背景下，显著提升了大型机系统的价值。

许多银行对处理现有大型机代码中的技术债务心存顾虑，这些代码可能采用 COBOL 等分布式系统出现前的语言编写。由于原系统设计者通常已离职，而业务中断又不可行，IT 决策者往往只能通过中间层修补来延迟转型。

Atruvia AG 是全球领先的银行服务技术供应商之一，依托分布在四个数据中心的八套 IBM z15 系统，为 800 多家银行处理近 1000 亿笔年度交易。

他们并未选择推倒重来，而是决定实施原地重构，在大型机原有 COBOL 程序旁并行开发 Java 版 RESTful 服务。通过逐步将 85% 核心银行业务交易替换为现代 Java 代码，他们不仅为银行客户开发了新功能，更将大型机工作负载性能提升了三倍。

多数银行都制定了包含灾难恢复冗余机制的数据保护计划，例如在数据中心保留生产大型机的主副本，并设置每隔数月批量更新的异地辅助备份或虚拟磁带解决方案。

随着交易量和应用端点持续增加，数据规模不断膨胀，通过传统备份技术进行复制不仅成本高昂、耗时日增，数据重构过程也极其缓慢，可能造成灾难恢复的停机空窗期。现代银行体系亟需建立更及时的备份与恢复机制，以保障计算环境安全（包括应对勒索软件威胁）。

澳大利亚排名前五的银行 ANZ 希望提升系统能力，以实现更及时的大型机备份和更快速的灾难恢复性能，从而确保为超过 850 万客户提供持续稳定的服务。

他们构建了跨站点弹性容量，通过镜像 IBM zSystems 服务器并利用 HyperSwap 功能，可在无需停机的情况下实现多目标存储切换——当任一服务器执行备份或恢复流程时，其他相同配置的服务器可立即接管生产负载。

得益于更高的系统可用性，ANZ IT 管理层得以高枕无忧；更重要的是，他们现已建立现代化的灾难恢复架构，该架构可通过认证以确保客户业务的连续性。

银行的各项关键业务决策几乎都依赖高级分析技术，这些决策关乎客户满意度、财务表现、基础设施投资与风险管理。

在大型机上对海量数据集执行复杂分析查询会大量消耗计算资源，运行耗时可能长达数小时甚至数天。若将数据转移至他处（例如云数据仓库），传输延迟可能更为严重，导致数据滞后并影响决策质量。

土耳其第二大银行 Garanti BBVA 部署了 IBM Db2 Analytics Accelerator for z/OS，在提升查询负载处理速度的同时降低了大型机 CPU 消耗。

通过将分析负载与大型机生产环境的运维顾虑及成本分离开来，Garanti 现可每晚运行超过 300 个分析批处理任务，而一份过去需要两天生成的合规报告现在仅需一分钟即可完成。

银行的核心竞争力在于向客户提供创新应用与服务的能力，因此敏捷的开发测试团队正在持续优化软件功能。我们往往习惯性地将这些创新归结为智能手机应用的前端改进，或是通过 API 驱动与云服务的集成。

但请注意：几乎所有新功能最终都会与大型机产生交互。何不让大型机团队以核心成员身份加入DevOps变革，使其参与其中？

丹麦银行决定让近 1000 名内部大型机开发人员参与全企业范围的DevOps转型，采用IBM Application Delivery Foundation for z/OS（ADFz）作为功能开发、调试、测试与发布管理的统一平台。

即使是现有的 COBOL与PL/1 代码也能纳入CI/CD管理流水线，开发者可在集成开发环境中直观地进行编辑修改，彻底告别绿屏时代。如今该行推出新服务的上市时间比以往缩短了一半。

阅读丹麦银行案例研究 https://www.ibm.com/cn-zh/case-studies/danske_bank_as

即便是新近涌现的“云原生”金融科技公司，也应当慎重思考：自身的创新技术如何与不断变化的混合计算环境中的合作方进行交互。

移动应用上的一笔交易，最终仍会触及全球支付网络、监管机构及其他银行——而每个环节的请求实现，背后都离不开各自的大型机计算与存储资源。

大型机应用现代化征程从无单一路径，因为每家银行的架构皆具独特性，且存在多种可行的改造方案。

IT 决策者需找准切入点，选择最契合业务需求及大型机所处独特应用架构的用例。

了解更多信息，请参阅本系列其他文章：

• 第 1 部分：《大型机应用程序现代化改造：超越银行业范畴》
• 第 2 部分：《通过协作（而非迁移）实现云上大型机应用程序现代化》
• 第 4 部分：《大型机与云？开源让一切变得简单》