银行升级引发的账户混乱 (RBS Outage)：一次被形容为「常规」的软件升级，为什么让几百万人的账户余额乱了？

# ビジネス失敗の回顧メモ：银行升级引发的账户混乱 (RBS Outage)

> 一次被形容为「常规」的软件升级，为什么让几百万人的账户余额乱了？
> 期間: 2012 | 業界: 金融・FinTech
> ピーク: 英国大型银行集团，旗下拥有多个零售银行品牌，客户数量以千万计，是本国个人与企业账户的主要提供者之一
> 終局: 一次批处理软件升级引发账户余额错乱与服务中断，数百万客户受影响，赔偿与罚款金额巨大，银行的技术治理被监管机构严厉批评

## 概要
在金融系统里，没有小改动——只有小改动带来的大后果。巅峰期英国大型银行集团，旗下拥有多个零售银行品牌，客户数量以千万计，是本国个人与企业账户的主要提供者之一；终局是一次批处理软件升级引发账户余额错乱与服务中断，数百万客户受影响，赔偿与罚款金额巨大，银行的技术治理被监管机构严厉批评。

## コミュニティ投票の主要死因
1. [プロダクト技術] 变更管理缺少充分的回归测试 (1,407 票)
2. [戦略意思決定] 多个品牌共用一套核心批处理 (1,182 票)
3. [組織マネジメント] 长期压缩技术投入 (957 票)

## 実行可能な教訓
### 关键系统的变更，必须假设它会失败并准备好回滚
> 把回滚演练与变更窗口限制写成硬规则。

- ✅ 推奨 (DOs):
  - 对核心变更做回归测试与回滚演练
  - 避免多个品牌共用同一批处理单点
- ❌ 禁止 (DON'Ts):
  - 不要用削减技术投入来改善当期报表
  - 不要在业务高峰期执行高风险变更

## 再生プラン
### 先建立变更演练与回滚纪律，再谈技术成本优化 — 良略编辑部
介入時点: 2012 年批处理升级引发全集团服务中断时
- 断つべきもの:
  - 停止在缺少回滚方案时执行核心变更
  - 停止让多个品牌共用同一批处理单点
  - 停止以削减技术投入改善当期报表
- 打開策:
  - 对核心变更强制做回归测试与回滚演练
  - 按品牌或业务线隔离关键批处理
  - 建立可快速回滚的发布机制
- 期待される成果: 变更管理具备演练与回滚能力，单点故障影响范围被有效隔离。

## コミュニティの知見
### 这次事故最有警示意义的细节是：升级本身没写错，是它在真实数据上的表现和测试环境不一样。 — 良略编辑部 (工程师)
核心账务系统有一个特点——它的逻辑跨越多年，测试环境很难完整复现生产环境的历史数据与状态。这次变更在执行时按计划启动，但在批处理窗口里遇到了测试中不曾出现的分支，导致整个夜间流程失败；而失败之后，积压的交易需要按顺序重放，处理时间被成倍拉长。更严重的是影响面：多个零售品牌共用同一套批处理体系，一次故障让整个集团的客户同时受影响。事故之后，银行支付了赔偿与罚款，而这些数字比事先做好冗余与演练所需的投入大得多。
- やり直せるなら打つべき一手 在核心系统上省下的钱，通常都会以事故赔偿的形式加倍还回去。

---
出典: 良略 · https://www.lianglue.com/c/rbs-outage