2021/02 瑞穗银行调查报告

2021 年 2 月底日本三大银行之一的瑞穗银行系统发生大规模故障，4 千多台 ATM 无法使用，还会吞卡吞账本。前几天发了调查报告，公司大佬读了表示乐子太多，简直幺蛾子役满，要大家都读读。我就顺带记录一下。

故障详情：2 月 28 日星期天早上，瑞穗银行旗下的 8 成 ATM 共 4318 台发生故障，无法使用。于第二天下午 3 点恢复。期间有 5244 名用户被吞卡。直至 3 月 2 日有 8 成用户拿回了卡。

原因很简单，3 月底要全面上线电子账户，要做数据转移，赶上交易量大，服务器内存爆了。

不过槽点可就多了。下面总结一下。

1. 构筑系统时为了改善性能，数据库 index 做成内存常驻了，后来大概忘了。

2. 日本发行账本要交印纸税，同时还有账本的工本费，为了削减成本，要全面移到电子账户。算下来大概能省 16 亿税钱 + 1kw 工本费。电子账户 1 月下旬上线，要赶在3月底把现有数据转移。因为 4 月 1 号开始就要开始算税了。

3. 数据转移时因为大量读写 index，毫无疑问的把内存爆了。系统发现有问题想回滚，但回滚也要读写 index，于是死锁，触发了禁止交易的限制。同时期的 ATM 的访问请求自然也一起禁止。

4. 数据转移之前的测试只做了 8 万个账户，且只测了时间，没测容量。

5. 不知过去发生过什么，但是有过错误过多后解除限制就好了的，于是试着解除了限制。毫无意外又死锁。

6. 休息日运维远程工作，log 通过云服务邮件转发。但一封邮件最多只能写 15 条，又加上有延时，没能第一时间发现。

7. 故障发生前一天 27 日正式开始数据转移时内存使用率就达到了 87%，但被无视。

8. 11 点企业传讯部（Corporate communication）负责人在 SNS 上确认到 ATM 故障，想 IT 部门发函确认，11 点半得到回复表示了解。

9. 12 点企画管理部的危机管理负责人从别的部门得知吞卡故障，表示立马去公司。14 点危机管理室发文要开会。17 点成立特别对应小组。同时全公司发布出勤指示。

10. 13 点 ATM 开始大规模故障，要赶紧更新官网写通知。11 点企业传讯部（Corporate communication）负责人邮件请求更新官网，并附上了模板，没人回。12 点再发说 2 小时内必须更新依旧没人回。没办法，负责人自己写了文案，邮件请求确认，13 点 15 官网更新。

11. ATM 故障想着交给电话中心就行。1 通标准 15 分钟，当天只有 7 人在岗。

12. 公司做了 1000 多个危机备案，但没有一件是发生在休息日的。

调查报告原文：https://www.mizuho-fg.co.jp/release/20210615release_jp.html