银行合并的系统事故 (Mizuho Systems)：三家银行合并成一家巨头的第一天，为什么系统就先出事了？

# 商业复盘备忘录：银行合并的系统事故 (Mizuho Systems)

> 三家银行合并成一家巨头的第一天，为什么系统就先出事了？
> 周期: 2002 | 行业: 金融与科技
> 巅峰: 由三家大型银行合并组建的金融集团，合并时资产规模位居全球前列，客户数量与服务网点极为庞大
> 终局: 合并当天的系统整合出现严重故障，大量账户交易出错，监管机构下达业务改善命令，高层承担责任辞职，合并红利被事故抵消

## 核心概览
合并的成败不在签约那天，而在两套系统的第一笔交易能不能对上。巅峰期由三家大型银行合并组建的金融集团，合并时资产规模位居全球前列，客户数量与服务网点极为庞大；终局是合并当天的系统整合出现严重故障，大量账户交易出错，监管机构下达业务改善命令，高层承担责任辞职，合并红利被事故抵消。

## 社区公投头号死因
1. [产品技术] 跨机构系统整合低估复杂度 (1,075 票)
2. [战略决策] 合并时间表不可调整 (903 票)
3. [组织管理] 缺少极端情形的演练 (731 票)

## 可执行教训
### 系统整合的日期应该由技术就绪度决定，而不是由对外公告决定
> 把回滚与并行运行能力作为切换的前提条件。

- ✅ 推荐做 (DOs):
  - 在切换前完成大规模演练与回滚预案
  - 让技术就绪度拥有推迟对外日期的权力
- ❌ 绝不能做 (DON'Ts):
  - 不要让合并宣布日期绑架技术方案
  - 不要在未演练的场景下切换核心系统

## 救亡方案
### 先做大规模演练与回滚预案，再决定是否切换 — 良略编辑部
干预时点: 2002 年初合并日期临近、整合测试明显不足时
- 必须断腕:
  - 停止为配合对外日期压缩测试
  - 停止在没有回滚方案时切换核心系统
  - 停止把对账差异留到生产环境解决
- 破局动作:
  - 完成跨机构对账规则的逐项比对
  - 做大规模并发与异常场景演练
  - 保留可快速回滚的并行运行能力
- 预期结果: 切换过程受控，出现异常时可快速回滚，客户资金不受影响。

## 社区见解
### 这类事故里最讽刺的一点是：银行的技术团队其实提前知道风险，但日期已经对外公布了。 — 良略编辑部 (工程师)
合并的技术难点在于「对账」：三家银行对同一笔交易的处理方式、时间戳、费用计算可能有细微差别，这些差别在系统里会放大成重复扣款或漏记。要解决它，需要时间做逐项比对与演练；而合并日期是董事会对外宣布过的，往回推的时间必须留给市场与客户沟通，于是留给技术的时间被压到最少。切换当天出问题时，第一个小时决定了后面几周的工作量——客户的钱出了错，就必须一笔一笔查。事故之后，监管机构的处分与高层辞职说明了一件事：在金融业，系统切换失败会被视为治理失败。
- 如果重来一次的纠偏招式 在核心系统上，「按时上线」不是勇敢，而是把风险转嫁给了客户。

---
来源: 良略 · https://www.lianglue.com/c/mizuho-systems