光大证券事件
2013年8月，光大证券在向客户演示时连接了正式数据库，导致股市震荡，被罚款5.2亿。
宁夏银行删库事件
2014年7月，宁夏银行在季末结算业务量较大的情况下，因备份系统异常导致备份存储磁盘读写处理严重延时，备份与主存储数据不一致。工程师在采取中断数据备份录像操作后，造成生产数据库损坏并宕机。造成38小时，700多定点医疗机构和定点零售药无法使用医保支付。
小插曲，2014年5月宁夏银行使用CDP软件进行了一场容灾演练，曾完成800公里的容灾切换。
携程删库事件
2015年5月，携程无法访问。官方反馈是由于运维工程师误操作，误删生产环境，而且重新部署后还是会被删除。经过十几小时努力，最终恢复成功。
小插曲，携程挂掉后，导流给了艺龙，结果艺龙也挂了。
Gitlab删库事件
2017年2月，Gitlab运维人员，在应对前一晚的DDOS攻击后，发现备库复制数据缓慢，并无法解决。最终决定删除备库，重新开始复制。但在十分疲倦的情况下，工程师误删了300G的生产数据，由于备份机制设置不合理，最终导致20多小时系统宕机，707位用户丢失数据，5,037项目丢失，受事故影响的用户基数不到1%。
我们可以看到的问题有：
1、审核和监控全部备份策略：虽然Gitlab号称有五重备份机制：常规备份24小时做一次、自动同步、LVM快照24小时做一次、Azure备份对数据库无效、S3备份。但没有一个可靠地运行或设置，而且备份失败也没有良好的预警机制。最终只能基于LVM的备份（最近6小时以前），还原了6 小时前的备份。
2、积极演练应对重大问题，保证备库是随时可用的，应急时也应该有序进行
3、数据中心之间数据传输要考虑好，本次数据传输也花费了较长时间
4、防止人肉运维，谨防开夜车，脚本工具化自动化。人总归会出错，而且总是在最不该发生的时候出错。
5、Gitlab本次事故发生后，公开透明的处理方式，值得大家借鉴和尊重。
AWS删服务器事件
2017年3月，一名S3工程师根据预先编写的playbook执行一条命令时，输入命令时输错了一个字母，结果删除了一大批本不该删除的服务器。经过4个多小时后恢复正常。
verelox.com删库事件
2017年6月，荷兰云主机厂商verelox.com，一前任管理员，恶意报复公司，删除全部用户数据，并擦出了多数服务器上面的内容。
广西移动扩容事件
2017年9月，华为工程师在进行广西移动扩容时，误将HSS设备的用户数据格式化，导致广西移动损失80万用户数据。
顺丰删库事件
2018年9月，顺丰一个高级工程误删线上库，然后跑路。导致部分服务无法使用并持续 590 分钟。
微盟删库事件
2020年2月，，导致系统6六天无法访问，市值蒸发28亿，预计赔偿金1.5亿，官方反馈是内部员工恶意行为导致，没有加到列表中。数据最后在腾讯云的帮助下得以恢复。
============================================================
注：本文主要是整理了系统Bug导致的惨痛代价，没有记录下面几种情况（设计失败，黑客攻击，病毒爆发）
*从计算机诞生以来，众多失败的软件项目，没有加到列表中