TSB 银行系统迁移事故：为什么一次计划了两年的系统迁移，会在上线当天让近两百万客户用不了账户？

# 商业复盘备忘录：TSB 银行系统迁移事故

> 为什么一次计划了两年的系统迁移，会在上线当天让近两百万客户用不了账户？
> 周期: 2015 - 2019 | 行业: 金融与科技
> 巅峰: 英国拥有数百万零售客户的中型银行，从大型银行集团分拆独立后，计划通过自建技术平台摆脱对原集团的系统依赖
> 终局: 2018 年数据迁移失败，约 190 万客户长时间无法正常使用账户，CEO 辞职，损失超过 3 亿英镑，并被监管处以巨额罚款

## 核心概览
把核心系统当成一个可以一次性切换的项目，而不是需要长期并行验证的工程。巅峰期英国拥有数百万零售客户的中型银行，从大型银行集团分拆独立后，计划通过自建技术平台摆脱对原集团的系统依赖；终局是 2018 年数据迁移失败，约 190 万客户长时间无法正常使用账户，CEO 辞职，损失超过 3 亿英镑，并被监管处以巨额罚款。

## 社区公投头号死因
1. [产品技术] 核心系统迁移缺少充分的并行验证 (990 票)
2. [组织管理] 回退与应急预案不足 (832 票)
3. [战略决策] 把迁移当成一次性项目 (673 票)

## 可执行教训
### 核心系统迁移要按「随时切回去」来设计
> 没有回退方案的切换，等于把全部风险压在一个日期上。

- ✅ 推荐做 (DOs):
  - 在切换前让新旧系统长时间并行运行并逐日对账
  - 准备可在数小时内执行的回退路径
- ❌ 绝不能做 (DON'Ts):
  - 不要为上线日期压缩验证
  - 不要把核心系统的控制权完全交给外部平台

## 救亡方案
### 先确保能回退，再谈切换；切换后新旧系统并行对账 — 良略编辑部
干预时点: 2018 年 4 月切换后出现大规模故障时
- 必须断腕:
  - 停止在新系统上继续叠加变更
  - 停止按原计划关闭旧系统
  - 停止把故障描述为个别客户问题
- 破局动作:
  - 立即评估并把可迁移的业务回退到旧平台
  - 让新旧系统并行运行并逐日对账后再逐步切换
  - 对全部受影响客户做账务核对与补偿
- 预期结果: 客户在故障期内快速恢复可用，账务差错被控制在小范围，公司避免数亿英镑损失与监管重罚。

## 社区见解
### 核心系统的迁移，不是「什么时候切」的问题，而是「切坏了怎么回去」的问题。 — 良略编辑部 (工程师)
银行筹备了两年的迁移，在测试环境里表现尚可，但真实业务量、产品组合与历史数据的一致性远比测试复杂。切换后大量客户无法登录、账务出现差错，而更严重的是没有一条能在当天回到旧系统的路。于是故障从几个小时的窗口变成持续数周的瘫痪，损失和监管后果远超迁移本身节省的成本。
- 如果重来一次的纠偏招式 关键系统切换的前置条件只有一个：回退方案要先被验证过。

---
来源: 良略 · https://www.lianglue.com/c/tsb-bank