浅谈Cobol – 金融的骨灰级语言

曾经，一位65岁的程序员 Wayne Linksman 在自己的 LinkedIn 主页写了这么一句：“Long Live Cobol”。因为这门骨灰级的编程语言，他现在还有一份稳定的工作。如果查看这位大叔的简历，他在美国银行、Fidelity、FIS InvestOne 都工作过。他的职业生涯，一路都是多亏了这门1959年诞生的计算机语言——Cobol。

然而，这门骨灰级的语言，最近几年又被“诈尸”一样地给“诈”出来。而这一“诈”，能直接让人出一身冷汗。

几年前，IBM 和路透发布了两份报告。报告中的数据，可以解释冷汗的原因。

• 2400亿行代码：截至 2022 年 12 月，全球有 2400 亿行 Cobol 代码仍在运行中，而且每天会继续增加 50 亿行。
• 银行系统的依赖：全球有 43% 的银行系统是用 Cobol 编写的。
• 线下交易的基础：80% 的线下银行交易是基于 Cobol 语言。
• ATM 交易的支撑：大家用 ATM 刷卡的那一刻，95% 是 Cobol 在运行。

这个语言的根深蒂固超乎了大部分人的想象。全球大部分金融系统（银行、基金、企业等）都基于该语言。就连失业系统也是如此。美国在疫情期间，突然有两千多万人申请失业救济金，结果系统崩溃了。

懂 Cobol 的人越来越少，这是又一个系统性风险

如果说一种语言能运用而且维护这么多年，从某种意义上来说，的确是一门值得尊敬的语言。但是，这又衍生出另外一个问题，那就是精通这门语言的人会越来越少。想一想一开头提到的那位 Wayne Linksman 在 65 岁的高龄还不能退休，大概就能体会到这个人才市场的紧缺。

另一方面，几乎没有学校会主动教授 Cobol。马斯克都用 Python 来写火箭了，试问还有多少人会去学、去教一门骨灰级语言。不是说没有，只能说少之又少。

如果一个东西坏了，世界上只有少数人知道怎么修。而这个东西，刚好是全球金融系统的底层代码。

这事情的危险程度，已经到了计算机巨头 IBM 和 Linux 都看不下去了。两家机构走到一起，推出了三个项目。一个是全球 Cobol 程序员论坛，便于大家互助甚至招聘职位。一个是 Cobol 的技术论坛，大家基于技术层面讨论并提供经验分享。最后一个是 IBM 的开源培训课程，全免费，可以在 IBM 培训平台上获取。

这么一波操作，还真的是召集了全球 1500 位 Cobol 程序员的回应。但是仔细思考一下，这还是一个治标不治本的问题。就好像全球的传真机（如果还有人知道传真机是什么东西）坏了，于是我们召集会修传真机的人。

这种在业内叫做技术负债（Technical Debt）。对一套老系统不断地打补丁，直到要培训专业的人来维护补丁。放眼全球，大部分金融系统都是如此。我接触过的国内银行，无论是 Kondor 或是 Opics，都是永恒打补丁状态。就算是银行的自建系统，出于经验和人才储备，也是摸着石头过河的创建与维护过程。做过这项工作的人才能懂其中的痛苦。

加拿大政府的前首席技术官 Alex Benay 曾经说过，这种技术负债就是问题的滚雪球。不断地回避和推后，直到有一天（比如新冠疫情），才能把警钟敲响。可到了那个时候，很多人连警钟的按钮在哪里都不知道。

有一家专门研究反洗钱技术的公司 Hummingbird Regtech，他们的联合 CEO Matthew Van Buskirk 说：“我接触过那么多银行机构，无论是我的客户，还是政府机构，我还没见过一家真的把 Cobol 运用得很好的机构。大部分都是在旧代码上不断地修补，甚至到了一种比较恐怖的状态，就是没有一家银行能清楚地说出自己究竟有多少个客户。”

他提到一家银行，大概有 10 个核心系统，大部分是基于历史的并购。这些系统彼此没有互通。一个用户，比如叫张三，他可能重复出现在四个核心系统上。唯一破解的方法，只能是手动一个一个查。

还有另外一家银行，用的 Cobol 系统只能识别大写字母。如果用这个系统运行报告，然后有人一不小心输入一行有大小写的代码，系统会跑出一份 1000 多页的乱码。无格式，无分段。唯一的方法还是人手去一行一行地找，然后修改。

在那些人力成本很高的市场，非常不幸的事实是，真的有人在做这项工作。

Matthew 说：“如果你问我什么时候我们得认认真真地去正视这些问题。我的回答是：十年前！”

有什么可以代替 Cobol？

不是没有，而是太多。一多，就带来机会成本的讨论。

苹果的 iOS 用的是 Swift，电脑芯片用的是 Rust。Python 的高灵活度则被用来做大量的人工智能和机器学习。但如果你问游戏和手机 App 的阵营，大部分又是 Java 和 C++。

在金融领域的新语言也是很丰富的。比如 JP Morgan 的一位交易员就写了一种叫 Concurnas 的语言，主要是为了在建模和自动化交易过程中减少多语言切换的不便。这位程序员 Jason Tatton 为了能让更多人一起维护，从一开始就决定了开源，为了把 Java、C++ 还有 Python 的灵活度全部都调用起来。

Julia 的诞生故事，也是 2009 年的时候，几位程序员把 C、Matlab、Java、Ruby、Python、Perl 和 R 的精华与糟粕做了取舍之后，创出来的一门新语言。

要选一门灵活度高，开源，还要能在未来 30 年都能持续运行的金融底层语言，真不是一件容易的事情。2014 年的时候，FINOS（Fintech Open Source Foundation）就开始了这项工作。他们最终的目的是把开源软件在金融体系中运用开来。非开源的封闭系统和语言，将来绝对很难成为主流。

除了语言的开源性，高频数据的处理方式也是另外一个值得思考的领域。在不久的某一天，现有的系统绝对处理不了日渐高频和海量数据。很多人以为这只是一个运营的问题，但很少人会意识这其实是一个合规甚至是监管的问题。

为什么这么说？ 因为在一些国家的监管已经开始要求金融机构对数据留痕的要求。只要他们算法碰过的数据，都要有迹可循。如果对于数据的二次加工和转换，也需要有能力去进行解析。这么做的其中一个主要的原因，是为了避免算法太过聪明，自动把社会的弱势群体，或是收入能力不高的用户，甚至是单亲妈妈等，给自动排除掉。

回到主题，要把Cobol代替掉，绝对不是一件简单的事情。这难度就好像要解决雾霾和全球气候变化一样，要从非常底层的工作开始。然而，很多人在自己的岗位上只是那么几年的时间，是无法去持续维护一个这么大的项目。再加上金融机构的内部人事变化，人员管理，内部政治，外部监管的变化等。

也许，真的是得等到下一个比新冠疫情更加严重的来袭，才能把这个警钟再次敲醒。