还记得10月份全银系统的大规模故障在日本的银行界引起的不小的骚动吧。这次故障影响了包括三菱UFJ银行和埼玉银行在内的10家银行，持续了两天。
截至12月1日数据显示，最初公布的受影响交易的数量从506万件增至566万件。补偿方面，到11月17日为止已确认有8000余件赔偿对象，赔偿金额会超800万日元。随着调查的深入，影响的数量和金额可能会进一步增加。
全银系统故障说明会
12月1日，全国银行资金结算网络（全银网）和NTT Data在东京大手町的银行会馆召开记者会，就10月10日至11日全银系统连续两天的故障进行了说明。
这已经是他们第四次就此事召开会见，前三次主要是说明故障的可能原因，但一直没有确定。此次的特别之处在于，这是全银系统的主要供应商NTT Data的相关人员首次与全银网一同出席。
在全银系统故障中，究竟发生了什么？
全银系统是几乎所有国内金融机构都在使用的处理日常转账和实时付款的系统。此次故障发生在10日上午8点35分左右，在全银网和NTT Data于10月7日至9日进行的中继全银系统和金融机构之间连接的中继计算机（RC）更新之后。
本次更新是将旧的RC17系列的14家金融机构迁移到新的RC23系列，结果在RC的“国内兑换制度运营费加算/chk处理”程序上出现错误，9家机构的RC挂掉了，当日上午9时43分左右，又1家机构的RC出现故障，导致10家机构无法进行“电信汇兑业务”。该问题持续两天直至11日，导致截至当日共有约566万笔交易未完成。
为什么会发生这次的故障呢？
关于这个问题，两家公司都宣布，用于生成索引表（用于在电信汇兑业务中确认金融机构消息内容）的程序耗尽了内存空间，导致索引表中的全部数据被删除。据公布，索引表中整体数据的2%遭到破损是造成这次障害的直接原因。损坏的索引表被加载到磁盘区域并扩展到本番的共享内存里。10日，本番环境的RC上的“国内兑换制度运营费加算/chk处理”的程序访问共享内存里的损坏的索引表，无法获取正常值而异常终了。
用于检查消息内容的索引表据称由四种类型组成：“金融机构名称表”、“正读金融机构名称索引表”、“简读金融机构名称索引表” 、“金融机构代码索引表”。这是因为电文中收款人等信息有很多种类型，而使用这四种类型的索引表能够准确、快速地完成该过程。
在本次RC更新中，RC17中使用的32位Linux操作系统更改为RC23系列中的64位操作系统。为了解决操作系统版本变更带来的不兼容问题，上述四类索引表中，仅对金融机构名称表进行了扩容，其他三类索引表的大小保持不变。创建索引表的程序本身也没有改变。
NTT Data表示，本来应该根据四类索引表的整体大小，来考虑是否扩张创建索引表的程序的工作区域的，详细设计中也考虑到了这一点。然而，在处理不兼容性时的影响调查过程中，只是意识到了金融机构名称表，并且由于金融机构名称表大小的扩展也在创建索引表的程序的正常领域范围内，制造担当认为没有必要扩大程序的工作区域。
实际情况是，四类索引表的总大小（包括三类没有扩容的索引表）超出了工作区，导致索引表损坏。即使在后续的测试过程中也没有检知到索引表损坏的风险，导致在本番环境中RC的运行异常结束。
此外，据称，他们并没有准备一个完全承担本次 RC 更新相关风险的恢复计划，虽然中继计算机在东京和大阪各有一台，互为备份，但由于同时将这两台切换到新型号的RC23系列，导致两台都发生了软件故障，无法履行备份的角色。他们计划的方针是采取替代措施。
因此，12日，因为修改程序涉及范围很广会影响恢复时间，所以作为替代解决方案，在RC的“国内兑换制度运营费加算/chk处理”程序的输入字段中统一输入“0日元”，通过此措施没有发生错误，结果解决了问题。截至12月1日，RC仍在用此替代解决方案运行。
今后的对策
出现故障后需要立即采取一系列对策。尽管NTT Data认为“工作领域的保障错误”并非“简单问题”，但表格和索引整体容量的计算错误更多地被可以看作是疏忽大意。这也成为问题的焦点，因为这一错误绕过了所有先前的审查和测试。
NTT Data 分析原因并确定以下问题：
(1) 设计/制造流程问题；(2) 测试流程问题；(3) 恢复流程问题。
在调查处理操作系统版本变更导致的不兼容性的影响时，本应扩展创建索引表的程序的工作区，却被错误地判断为没有必要，为了防止这种情况再次发生，公司决定改变流程，在修改程序时始终包括参与详细设计的人员一起进行判断。
另外，基于本次教训，他们认为在新的基盘环境中为了确认表的有效性，需要对新旧表进行比较和确认。此外，未来还将使用相当于实际交易的数据进行疏通测试。
还一个相当关键的问题是，在恢复计划中，NTT Data和全银联之间并未达成一致的优先级排定。
作为防止再次发生的措施，对于“恢复业务的优先级”和“切换到备份计划的时机”进行认识统一，并制定了障害发生时的的恢复指南，并考虑到东京和大阪的全银系统同时发生故障的风险最大的情况进行有效性评估和训练。
基于上述情况，在接下来的六年里，将进行四次从RC17到RC23的替代工作。全银联理事长辻松雄表示，尽管此次事件不会影响到2024年1月的更改实施和迁移到第八代全银系统的计划，但明年1月原计划进行迁移的三家金融机构中，有一家推迟了迁移工作，而对于其余两家，迁移工作将采用暂时解决方案版本。
尽管总体计划未发生变化，但目前所有涉及第八代系统核心开发的工作都已暂停，优先进行故障应对。
在明年的第二季度以后，他们将努力实现RC23的替代工作的正常进行，同时在明年10月的替代工作中，将再次面临类似于本次发生的问题，因此他们正在推进全面的解决方案，以应对可能出现的问题。
还有为弥补业务连续性计划（BCP）的不足，全银联计划设立首席信息官（CIO）负责信息管理。为防止同时发生故障，他们打算在位于日本国内的东京和大阪两个中心，采取RC23替代方案时的错时替代，而非同时进行。虽然明年1月的时机无法达成，但一旦准备就绪，他们将迅速采取行动。
尽管发生故障，全银联仍坚持进行RC替代计划和第8代系统计划，其中一个原因是系统维护期限。先前引入RC17的金融机构在6年后，维护期限逐渐到来，难以大幅推迟迁移时机。
另外，第8代系统牵涉到“开放适应”和“API网关设置”等关键主题。对开放系统的过渡考虑到目前核心系统中心大型主机的产品提供和维护期限的结束，将在2030年后进行。而API网关在未来有必要废除RC，届时银行间的连接将从API经由直接连接进行。无论如何，在未来10年中，全银系统将经历重大变革，因此他们不得不在应对故障的同时推进这些计划。
ITgo技术者之家，持续关注在日IT人关心的各种资讯，打造在日技术者的专属社区。欢迎留言交流互动。
ITgo
