所以，在灾难来临的时候，你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作，但也会导致数据丢失，而且可能长期不用的备份系统很难恢复(比如应用、工具、数据的版本不兼容等问题)。
我之前写过一篇《分布式系统的事务处理》，你还记得下面这张图吗?看看 Data Loss 那一行的，在Backups, Master/Slave 和 Master/Master的架构下，都是会丢的。
所以说，如果你要让你的备份系统随时都可以用，那么你就要让它随时都Live着，而随时都Live着的多结点系统，基本上就是一个分布式的高可用的系统。因为，数据丢失的原因有很多种，比如掉电、磁盘损坏、中病毒等等，而那些流程、规则、人肉检查、权限系统、checklist等等都只是让人不要误操作，都不管用，这个时候，你不得不用更好的技术去设计出一个高可用的系统!别无它法。(重要的事，得再说一篇)
另外，你可以参看我的另一篇《关于高可用系统》，这篇文章中以MySQL为例，数据库的replication也只能达到 两个9。
AWS 的 S3 的的高可用是4个加11个9的持久性(所谓11个9的持久性durability，AWS是这样定义的，如果你存了1万个对象，那么丢一个的时间是1000万年)，这意味着，不仅仅只是硬盘坏，机器掉电，整个机房挂了，其保证可以承受有两个设施的数据丢失，数据还是可用的。试想，如果你把数据的可用性通过技术做到了这个份上，那么，你还怕被人误删一个结点上的数据吗?
非技术方面
故障反思
一般说来，故障都需要反思，在Amazon，S2以上的故障都需要写COE(Correction of Errors)，其中一节就是需要Ask 5 Whys，我发现在Gitlab的故障回顾的blog中第一段中也有说要在今天写个Ask 5 Whys。关于Ask 5 Whys，其实并不是亚马逊的玩法，这还是算一个业内常用的玩法，也就是说不断的为自己为为什么，直到找到问题的概本原因，这会逼着所有的当事人去学习和深究很多东西。在Wikipedia上有相关的词条 5 Whys，其中罗列了14条规则：
你需要找到正确的团队来完成这个故障反思。 使用纸或白板而不是电脑。 写下整个问题的过程，确保每个人都能看懂。 区别原因和症状。 特别注意因果关系。 说明Root Cause以及相关的证据。 5个为什么的答案需要是精确的。 寻找问题根源的频，而不是直接跳到结论。 要基础客观的事实、数据和知识。 评估过程而不是人。 千万不要把“人为失误”或是“工作不注意”当成问题的根源。 培养信任和真诚的气氛和文化。 不断的问“为什么”直到问题的根源被找到。这样可以保证同一个坑不会掉进去两次。 当你给出“为什么”的答案时，你应该从用户的角度来回答。
工程师文化
上述的这些观点，其实，我在我的以住的博客中都讲过很多遍了，你可以参看《什么是工程师文化?》以及《开发团队的效率》。其实，说白了就是这么一个事——如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。
这个道理很简单，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些流程、规则、人肉检查、权限系统、checklist等等统统都不管用，这个时候，你觉得应该怎么做呢?是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统!别无它法。(重要的事得说三遍)
事件公开
很多公司基本上都是这样的套路，首先是极力掩盖，如果掩盖不了了就开始撒谎，撒不了谎了，就“文过饰非”、“避重就轻”、“转移视线”。然而，面对危机的最佳方法就是——“多一些真诚，少一些套路”，所谓的“多一些真诚”的最佳实践就是——“透明公开所有的信息”，Gitlab此次的这个事给大家树立了非常好的榜样。AWS也会把自己所有的故障和细节都批露出来。
事情本来就做错了，而公开所有的细节，会让大众少很多猜测的空间，有利于抵制流言和黑公关，同时，还会赢得大众的理解和支持。看看Gitlab这次还去YouTube上直播整个修复过程，是件很了不起的事，大家可以到他们的blog上看看，对于这样的透明和公开，一片好评。