墨墨导读：大家新年好，感谢陪伴，让我们在国产数据库元年，继续携手成长进步！这份数据库年终总结你看过了吗？去选出你期待学习的内容吧，还有限量版DBA专属日历等你拿哦~
本文翻译自“ What broke the bank ”，原作者为 Chris Stokel-Walker，翻译已取得原网站授权。译者：足下
早前，英国 TSB 银行筹划了良久的迁移方案失败，13 亿客户记录出错，事后各类赔偿总计花费约 29 亿元人民币。时隔一年，这家银行终于想明白原因是缺乏严格的测试。
2018 年，英国的 TSB 银行陷入了困境。虽然这家金融机构与劳埃德银行集团（Lloyds Banking Group，两者最初于 1995 年合并）拆分已有两年时间，但 TSB 仍然与前伙伴劳埃德银行集团有着关密不可分的关系，因为她的 IT 系统是非常匆忙地从劳埃德银行集团复制而来的。更糟糕的是，TSB 每年还要支付 1 亿英镑的许可费给对方（撰写本文时按汇率计算相当于 1.27 亿美元，约 8.9 亿人民币）。
没人会愿意为“前任”付费。为了改变这种局面，2018 年 4 月 22 日晚上 6 点钟，TSB 启动了一个已经蓄谋数月的计划，要把他们 540 万用户的数十亿条数据迁移到西班牙公司 Banco Sabadell 的 IT 系统上来，后者在 2015 年 3 月以 17 亿欧元（22 亿美元）的价格收购了 TSB。
前所未有的迁移，前所未有的糟糕
Banco Sabadell 的主席 Josep Oliu 于 2017 年圣诞前两周的一次超过 1800 人的公司集会上宣布了这项计划。这次大规模集会是在巴塞罗那商业街上的一个又大又现代的会议大厅中举行的。这次迁移工作的重中之重是 Banco Sabadell 公司在 2000 年开发的 Proteo 系统的新版本，并为这次 TSB 迁移项目而专门命名为 Proteo4UK。
Banco Sabadell 的首席执行官 Jaime Guardiola Romojaro 曾对巴塞罗那的公众宣称，Proteo4UK 项目投入的人力超过 2500 人年。“在欧洲，像 Proteo4UK 这么大型的整合项目绝对是史无前例的，我们投入的技术专家已经超过了 1000 人”，他继续说，“这个项目会为我们在英国的业务带来极大助力。”。
4 月 22 日，一个平常的星期天晚上，TSB 的迁移项目 Proteo4UK 接近完工了。几乎整个周末 TSB 旧的 IT 系统都处于停服状态，客户数据不断地从旧系统向新系统迁移。到了周日晚上，新系统慢慢启用了，并对外开放入口，平滑地恢复了对外服务。
虽然在圣诞之前的公司会议上，Oliu 和 Guardiola Romojaro 都对这个项目表现得信心满满，可是 TSB 参与具体迁移工作的工程师们却非常紧张。这个项目原计划是要进行 18 个月的，但它已经延期了，而且超出了预算。毕竟，把一个公司的全部数据从一个系统迁移到另一个系统，这绝非易事。
他们所担心的事情真的发生了。
在确认数据迁移很顺利，TSB 重新对外开放了对账户的访问之后，不到 20 分钟，第一个故障投诉电话就打了进来。人们发现自己一生的积蓄忽然不冀而飞了。有些非常小额的交易却被误记成了几千元的支出。有些客户登录之后却发现，他们查看的并不是自己的银行账号，里面的信息压根就属于不相干的人。
晚上九点，TSB 的领导层向英国的金融监管机构英国金融行为监管局（Financial Conduct Authority，FCA）汇报，自己这边出了问题。而事实上在 TSB 自己汇报之前，FCA 就已经注意到了这个事件，因为好事不出门，坏事传千里，尤其是在这个有互联网有 Twitter 的时代，出了问题时人们首先想到的就是去 Twitter 上吐槽。到了晚上 11：30，FCA 终于和另一个金融监管机构 PRA（Prudential Regulation Authority）碰了头，并在零点之后成功地与 TSB 的管理者们开起了电话会议。这时候已经是 4 月 23 日，星期一的凌晨了。他们只想问一个问题：到底发生了什么？
尽管当时的局面很混乱，但现在我们对事件已经有了一个比较清晰的结论：13 亿的用户数据在迁移中被损坏了。事后银行的 IT 系统用了几个星期才恢复服务，在此期间有几百万人的日常存取钱行为受到了影响。而直到这个事件发生一年多之后，专家们才自认为找到了问题的根本原因：缺乏严格的测试。
迁移并不是想象中的那么简单
随着用户的需求和期望不断增加，银行的 IT 系统也变得越来越复杂。60 年前，我们需要自己在营业时间去到银行的某个分行或营业部，在营业员的帮助下在柜台上把钱存入银行，或者把钱从银行取出来。我们银行账户里的数字变动与我们拿在手上的真实的钱是完全对应的。银行工作人员会用笔和纸记下我们账户的变动，普通顾客是接触不到任何计算机系统的。然后当一天或一周结束时，银行工作人员再把传统的记录在卡片或纸带上的数据输入巨型计算机，做最终汇总。
到了 1967 年，世界上第一台自动提款机（automated teller machine，ATM）在伦敦北部的一家银行门前正式投入使用。它彻底地改变了银行为顾客提供服务的方式，也改变了银行的方方面面。方便成了银行服务的基本标准，这个标准也让用户与屏幕后面运行的银行系统之间的距离大大地拉近了。
“在很久以前，IT 系统只是给银行内部工作人员使用的，只需要在柜台上做些纸质工作，银行就完全可以正常运转”，ITRS 集团的首席执行官 Guy Warren 说。ITRS 集团是全世界 190 多家银行的技术供应商。“后来 ATM 出现了，再后来又有了网上银行系统，普通顾客才真的直接与银行的 IT 系统打交道了。”
ATM 还只是个开始。很快人们就可以通过电话进行转账，再也不必去现场排队了。这个功能需要把特制的卡片插入可以解密双音多频（dual-tone multifrequency，DTMF）信号的硬件中，这样当客户按下“1”时，它就可以把这个命令翻译成“取钱”，而把“2”翻译成“存钱”。
网上银行和手机银行把客户与银行核心系统之间的距离拉得更近了。尽管不同的功能会由不同的子系统来实现，但所有子系统之间都要进行交互，并且向最核心的系统发出请求，比如更新余额、记录转账等等。
据 BLMS 咨询公司的 Brian Lancaste 所说，典型的零售银行核心系统都会运行在一台大型机上。他曾经在 IBM 工作过 13 年，而在 HSBC 负责管理 IT 技术部门的时间则更长。他现在为银行提供咨询服务，并在全英国范围内推动社区（对客户服务的社区银行）的构建。他说，“那可能是你能够运行核心系统的最可靠的平台了，也是最具备可扩展性的”。把核心的用户数据库放在大型机上，再加上运行在许多服务器之上的其它不同的 IT 基础设施，就可以构建对大型机进行访问的应用接口，从而提供互联网接入了。
当用户在网上登录进自己的银行账号，看到了自己的最新信息时，很少有人会想到发生在后台的数据处理过程有多么复杂。登录信息会在多台服务器之间传递。当你做一笔交易时，系统会从后端的基础设施拷贝一份数据过来，然后就是复杂的部份了：把钱从一个账户搬到另一个账户，完成交水电费、还款等实际业务，然后再继续处理其它请求。
再设想一下，如果上面描述的过程每秒钟同时发生几十亿次，又会是怎样呢？世界银行组织在比尔和梅琳达·盖茨基金会（The Bill & Melinda Gates Foundation）的帮助下，推算出现在全世界有 69% 的成年人都有银行账户。这些成年人每个人都要还账单，有些还要还贷款，而有 Netflix 或优酷土豆账号的人就更多了。另外他们的银行账号也不属于同一家银行。
手机银行、ATM 等数不清的银行内部 IT 系统不仅要在彼此之间进行交互，它们还要与不同地域的不同银行进行交互，比如玻利维亚、危地马拉甚至巴西等。如果你把一张美国发行的信用卡插进了一台中国的 ATM 机，它仍然要能够取出钱来。钱一直是全球化的，但与钱相关的操作从来没有这么复杂过。
“使用银行 IT 系统的方式不断在增加”，ITRS 集团高管 Warren 说。而且旧的系统几乎永远都不会下线，新的系统还会不断涌现出来。
“如果你考虑的问题是用各种各样的平台来满足各种不同的用户群体，以及它们能够提供多少在线服务的时间，那么很明显，你会有大问题”，Warren 说。事实上，衡量一个好的 IT 系统的标准是“你的系统有多大能力做自我修复，在出现严重故障甚至停服时，它能够处理得怎么样”。
“双活数据中心”这个词讲的是至少要有两个数据中心来一起提供服务，保证在任何时刻都可以正常处理业务，它通过冗余来提高了可靠性。
问题复盘
TSB 的 IT 系统就不擅长自我修复，银行的技术团队在处理严重故障时也很痛苦。但导致 TSB 的 IT 系统故障的根本原因在于它的复杂性。根据事故早期 IBM 为 TSB 出具的一份报告，“新应用与微服务的高级用法相结合，再加上使用了双活数据中心，导致了生产环境的多重风险”。
对于像 HSBC 一样的全球性银行，IT 系统都是高度复杂并且内部互联的，因此会有规律地进行测试、迁移和升级等活动。“对于像 HSBC 这样的公司，这些事情是时时刻刻在发生的”，前 HSBC 的 IT 技术负责人 Lancaster 说。他觉得 HSBC 可以做为其它银行如何运营 IT 系统的典范：要有专职的员工，付出专门的时间。“就算你标记好所有的 I，划上所有的 T，最后总会发现 IT 系统还是需要相当大量的计划和测试工作”，Lancaster 说。
对于小型银行，尤其是那些没有丰富的数据迁移经验的小型银行来说，要把这事做好就更有挑战性了。
“TSB 的迁移工作就很复杂”，Lancaster 说，“我不确定他们是不是真的明白这事有多复杂，我印像很深的是他们并没有制订出非常明确的测试计划”。
故障发生几个星期之后，FCA 的首席执行官 Andrew Bailey 在回应英国议会就这个问题的问询时确认了这一点。有问题的代码当然是 TSB 问题的根源，但全球金融网络相互关联的各个系统让它的错误层出不穷并且无法逆转。各种意想不到的错误不断地从这个 IT 架构各个地方冒出来。用户不断地收到各种冒名其妙的消息，而且压根与自己的问题无关。
“对我来说，这表明他们缺乏健壮的回归测试，因为银行系统是与支付系统、短信系统等许多外部系统相关联的”，Bailey 告诉议员们，“当你提交了修复代码，又引发了各种意想不到的问题时，那我们就又回到了测试的问题上”。
回归测试可能可以有助于避免这样的灾难，它可以帮你在把有问题的代码部署到生产环境之前，在有问题的代码与外部依赖相互作用造成不可逆转的错误、造成严重破坏之前，就把问题定位出来。
其他人也表示了同意。被邀请来帮忙定位问题的 IBM 专家一点也没有掩饰对 TSB 的批评之意。他们说本应该看到“国际标准级的严格设计、测试方法、全面的运营论证、预上线试运行和就绪的运维支撑等”，而实际上他们看到的完全不一样：“IBM 并没有看到有任何证据表明这些系统经过了哪些可以达到上线标准的严格测试，以证明它们可以投入生产了”。
TSB 已经踏入了雷区，而看起来她还毫不知情。
“他们所使用的技术是有相当大复杂度的，而且这些复杂度又有着不同的表现形式”，Ryan Rubin 说。他是一个 IT 专家，之前曾在 EY 工作，现在是 Cyberian Defence 的管理总监，这是一家专门帮助大型公司管理网络风险的咨询公司。“这可能会导致宕机和各种复杂事件，正如我们所看到的那样”。
Warren 说，英国的银行一般的行业标准是要达到“四个九”的可用性，即在 99.99% 的时间里他们的服务要对用户可用。在现实中，这意味着和网上银行一样，银行的 IT 系统在一天中的每个小时都要正常对外提供服务，在一年中也最多只能有 52 分钟的离线时间。“三个九”，即 99.9% 的可能性，听起来与四个九好像没有太大区别，但那就意味着一年超过 8 小时的停服时间。“对于一家英国银行来说，四个九的标准是可以的，三个九的标准不可接受”，Warren 说，他回想起来他提供咨询服务的第一个软件项目就要求达到六个九的标准——那是一家核电站的控制系统。
每当一家公司对她的 IT 基础设施做出变更时，就会有引入故障的风险。减少变化当然有助于避免问题，但对于必要的改变来说，就要经过严格的测试，这正是 IBM 所强调的在 TSB 的故障中所缺乏的。
Shujun Li 在肯特大学教授网络安全课程，也为包括一家大型银行和许多保险公司在内的大型公司提供咨询服务。他说，每次升级和打补丁操作最后都会归结到风险管理的问题，对那些客户投资几亿的大型项目来说尤其如此。“要有流程来保证风险都得到了有效的控制”，他说，“另外你还要心里有数，万一出了问题的话，可能会付出多少金钱和名誉上的代价”。
详细的计划可以降低 TSB 所经历的这种重大事故的风险。“故障还是会发生的，但进行快速恢复和保持冗余所要付出的代价却会减少”，Rubin 说。随着网络供应商和云解决方案的发展，存储费用已经大大降低了。“所有东西都是现成的，当灾难发生时，它们可以帮助银行管理风险，并将故障影响控制到最小”。
不过，对于一些机构来说，为应对灾难的发生而要实施备份计划的成本可能太高。Warren 认为，一些银行在如何实现 IT 弹性方面做得过于保守。他解释说：“你不能靠预算来做这件事。这是一项金融服务：要么有，要么没有。他们本来就应该再多投入一些钱。”
吝啬的 IT 投入最终让人付出了惨痛的代价。TSB 声称他们在 2018 年因为事故造成的损失是 1.05 亿欧元（1.34 亿美元），与之形成对比的是 2017 年他们的利润是 1.63 亿欧元（2.06 亿美元）。迁移事故后续的总支出达到了 3.3 亿欧元（4.19 亿美元），包括补偿用户、更正虚假交易（在事故发生后的混乱情况下，虚假交易的数量急剧上升）、以及为临时聘请技术专家而要支出的费用等。对应在这次事故中中所要承担的责任，TSB 的 IT 服务供应商 Sabis 也收到了一张 1.53 亿欧元（1.94 亿美元）的账单。
要降低风险，也许最简单的办法就是尽量不要做改动。但是正如 Lancaster 所说，“每间银行，每个发展中的社区，每家公司都无时无刻不被业务驱动着，要构建出越来越多的好东西来服务客户，支撑业务”。他观察到，“为了变得更有竞争力，你就会有动力引入更多的新系统和新功能”。同时，对于各家公司，尤其是金融服务类的公司来说，他们对客户承担着责任，要保证他们的财产安全，并且在使用现有服务时要保持良好的体验。“当你承受着巨大的业务压力要引入新东西时，两难之处在于你该投入多少成本来让所有系统保持正常运行”。
根据 FCA 公布的数据，从 2017 年到 2018 年，英国金融服务业上报的技术故障发生次数增长了 187%。究其原因，最常见的故障根本原因都在于变更管理做得很失败。尤其对于银行系统来说，需要保持时刻在线，而且需要近乎实时的交易报告。客户可能担心他们的钱会不会不翼而飞，如果感受不到自己的钱的存在，他们肯定会抓狂。
在 TSB 的事故发生几个月之后，英国金融监管机构和英格兰银行一起发布了一份关于运营弹性的讨论文件。“文件的目的是提醒各家金融公司：你会不会把天平向引入新功能的一侧倾斜了太多，从而忽略了现有系统的平稳运行？”Lancaster 解释到。
文件也对监管规则提出了修改建议：公司里相关员工也应该为公司的 IT 系统所出的故障负责。“如果你对此负有责任，你可能会因此而破产，甚至可能被送进监狱。这会让许多东西都随之发生改变，包括大家对事情的重视程度，”Warren 说。“你会非常慎重地对待它，因为它事关你的家庭财产和你的人身自由。”
Rubin 说，从 TSB 的事件之后，“大家做事情时肯定会更加认真地审查。高级管理者再也不会忽视 IT 系统的建设，也不会对技术资产投入不足了。由于有着处罚和合规性要求，现在的形势已经发生了很大变化。”
不管大家从 TSB 身上学到了什么经验和教训，严重的停服事件肯定还是会发生的，这无可避免。
“我不认为故障会消失”，Warren 说，相反，人们必须接受：“你能接受多大程度的可用性？换句话说，就是多少停服时间？”
原文链接：
https://increment.com/testing/what-broke-the-bank/