2014年7月1日，宁夏银行核心系统出现故障，故障时间长达长达37小时40分钟，影响全行业务存取款、转账支付、借记卡、网上银行、ATM和POS业务。
37小时40分钟是什么概念，《银行业重要信息系统突发事件应急管理规范(试行)》规定了3个级别的突发事件等级，业务终端超过6小时的为特别重大突发事件（Ⅰ级）、达到3小时的算重大突发事件（Ⅱ级）、达到半小时的算较大突发事件（Ⅲ级）。
直接原因
在季末结算业务量较大的情况下，因备份系统异常导致备份存储磁盘读写处理严重延时，备份与主存储数据不一致，在采取中断数据备份录像操作后，造成生产数据库损坏并宕机。
根本原因
根本原因是在于核心系统数据库版本严重老化，且2007年至今未购买核心数据库的维保服务，核心系统长期缺乏维护，事故发生后，无法获得系统供应商及时技术支持。系统恢复过程中，缺乏应急预案和准备，长时间无法实施有效处置，导致业务恢复缓慢，对银行运营产生较为严重影响。
为什么IT系统会出问题?为什么影响范围这么广？为什么没有应急预案或者应急预案没有起作用?为什么要停几个小时这么久？
一句话系统太复杂了，大型系统就更复杂了。世界上从来就没有不出错的程序。所以我们在做架构设计的时候一定要考虑系统解耦，风险隔离，尽量保证核心业务系统的正常运转，即便系统出错只影响出错的部分业务而不至于影响全行全部业务。在这个案例中应急预案为什么没起作用， 要知道出故障是备份系统，备份系统都出故障了何谈紧急预案那。为什么停这么长时间，这次故障是数据库宕机，首要问题是数据库恢复，而宁夏银行恰恰没有购买数据库维保服务，得不到数据库厂商的技术支持，这就难办了。没有数据厂商的支持解决问题谈何容易，花这么长时间也是在所难免的了。
GitLab 数据库误删事件
那么有没有使用备份系统的案例那？ 2017 年 2 月 1 日 GitLab 发生了一起生产事故，数据库被误删了。最终会丢失一小部分线上数据（6个小时的issues、comments、merge requests等，代码和wiki文档不受影响）。
一位同学在给gitlab的线上数据库做一些负载均衡的工作，在做这个工作时的时候突发了一个情况，Gitlab被DDoS攻击，数据库的使用飙高，在block完攻击者的IP后，此时已经加班到深夜了。因为遇到了种种常规脚本没能解决的问题，不得不进行大量人工操作，于是在精力不济后出现致命失误，准备从 db1 同步到 db2 时错误的删除了 db1 的数据。
在恢复的过程中，他们发现只有db1.staging的数据库可以用于恢复，而其它的5种备份机制都不可用，第一个是数据库的同步，没有同步webhook，第二个是对硬盘的快照，没有对数据库做，第三个是用pg_dump的备份，发现版本不对（用9.2的版本去dump 9.6的数据）导致没有dump出数据，第四个S3的备份，完全没有备份上，第五个是相关的备份流程是问题百出的，只有几个粗糙的人肉的脚本和糟糕的文档，也就是说，不但是是人肉的，而且还是完全不可执行的。
最终，gitlab从db1.staging上把6个小时前的数据copy回来，结果发现速度非常的慢，备份结点只有60Mbits/S，拷了很长时间
关于备份，Giblab事件中，就算所有的备份都可用，也不可避免的会有数据的丢失，理由如下：
1. 备份通常是周期性的，即便从最近的备份回复，那也有部分数据会丢失。
2. 备份的数据会有版本不兼容的问题。
3. 灾备中心的灾备数据没有一天live过。等真正灾难来临需要live的时候，你会发现各种问题让你live不起来。
所以最终的解决方案就是设计一个高可用性系统，AWS的S3就是一个高可用的号称11个9的持久性，AWS是这样定义的，如果你存了1万个对象，那么丢一个的时间是1000万年。
很不幸，亚马逊AWS服务也出了一次生产事故，2017年2月28日亚马逊S3数据中心无响应4个小时，墙外的半个互联网也跟着挂了。
2月28日晚间，亚马逊AWS服务出现了较高错误率，造成亚马逊S3在主要数据中心无响应，这是AWS历史上公共云服务出错最长且影响最大的一次。
S3 服务被近 15 万家网站使用
AWS S3 是项什么服务，为何会有如此多的企业采用？通俗讲，S3 是一项存储文件的服务，开发者可储存图片以及网页上的其他项目，保存备份，同时可在服务器和静态网站里共享文档。
简单来说，这天，工程师在调查Northern Virginia (US-EAST-1) Region 上 S3 的一个和账务系统相关的问题，想移除一个账务系统里的一个子系统下的一些少量的服务器，结果呢，有一条命令搞错了，导致了移除了大量的S3的控制系统。包括两个很重要的子系统：一个是S3的对象索引服务（Index），一个是S3的位置服务系统（Placement）。
虽然整个S3的是做过充分的故障设计的（注：AWS的七大Design Principle 之一 Design for Failure）—— 就算是最核心的组件或服务出问题了，系统也能恢复。但是，AWS 在很长很长一段时间内都没有重启过 S3 的核心服务，所以S3 的数据对象存储级数级的成长。所以，这两个核心服务在启动时要重建并校验对象索引元数据的完整性，这个过程没想到花了这么长的时候。而Placement服务系统依赖于Index 服务，所以花了更长的时间。
后续改进
1）改进运维操作工具。对于此次故障的运维工具，有下面改进：
让删除服务这个操作变慢一些（陈皓注：这样错了也可以有时间反悔，相对于一个大规模的分布式系统，这招还是很不错的，至少在系统报警时有也可以挽救）
加上一个最小资源数限制的SafeGuard（陈皓注：就是说，任何服务在运行时都应该有一个最小资源数，分布式集群控制系统会强行维护服务正常运行的最小的一个资源数）
举一反三，Review所有和其它的运维工具，保证他们也相关的检查。
2）改进恢复过程。对于恢复时间过长的问题，有如下改进：
分解现有厚重的重要服务成更小的单元（在 AWS，Service是大服务，小服务被称之为 Cell），AWS 会把这几个重要的服务重构成 Cell服务。（陈皓注：这应该就是所谓的“微服务”了吧）。这样，服务粒度变小，重启也会快一些，而且还可以减少故障面（原文：blast radius – 爆炸半径）
今年内完成对 Index 索引服务的分区计划。