2、事件回顾

整个事件的回顾 Gitlab.com 在第一时间就放到了 Google Doc 上，事后，又发了一篇Blog来说明这个事，在这里，我简单的回顾一下这个事件的过程。

首先，一个叫YP的同学在给 gitlab 的线上数据库做一些负载均衡的工作，在做这个工作时的时候突发了一个情况，Gitlab 被 DDoS 攻击，数据库的使用飙高。

在 block 完攻击者的IP后，发现有个 staging 的数据库(db2.staging)已经落后生产库 4GB 的数据，于是YP同学在 Fix 这个 staging 库的同步问题的时候，发现 db2.staging 有各种问题都和主库无法同步。

在这个时候，YP同学已经工作的很晚了，在尝试过多个方法后，发现 db2.staging 都hang在那里，无法同步，于是他想把 db2.staging 的数据库删除了，这样全新启动一个新的复制，结果呢，删除数据库的命令错误的敲在了生产环境上（db1.cluster），结果导致整个生产数据库被误删除。

陈皓注：这个失败基本上就是 “工作时间过长” + “在多数终端窗口中切换“，于是迷失掉了

在恢复的过程中，他们发现只有 db1.staging 的数据库可以用于恢复，而其它的5种备份机制都不可用:

·         第一个是数据库的同步，没有同步 webhook；

·         第二个是对硬盘的快照，没有对数据库做；

·         第三个是用 pg_dump 的备份，发现版本不对（用9.2的版本去 dump 9.6 的数据）导致没有 dump 出数据；

·         第四个S3的备份，完全没有备份上；

·         第五个是相关的备份流程是问题百出的，只有几个粗糙的人肉的脚本和糟糕的文档，也就是说，不但是是人肉的，而且还是完全不可执行的。

陈皓注：就算是这些备份机制都 work，其实也有问题，因为这些备份大多数基本上都是24小时干一次，所以，要从这些备份恢复也一定是是要丢数据的了，只有第一个数据库同步才会实时一些。

最终，gitlab从db1.staging 上把6个小时前的数据 copy 回来，结果发现速度非常的慢，备份结点只有 60Mbits/S，拷了很长时间。

陈皓注：为什么不把 db1.staging 给直接变成生产机？因为那台机器的性能很差

数据现在恢复了，不过，因为恢复的数据是6小时前的，所以，有如下的数据丢失掉了：

·         粗略估计，有4613 的项目， 74 forks,  和 350 imports 丢失了；但是，因为Git仓库还在，所以，可以从Git仓库反向推导数据库中的数据，但是，项目中的 issues 等就完全丢失了。

·         大约有 ±4979 提交记录丢失了（陈皓注：估计也可以用git仓库中反向恢复）。

·         可能有 707  用户丢失了，这个数据来自Kibana的日志。

·         在1月31日17:20 后的 Webhooks 丢失了。

因为 Gitlab 把整个事件的细节公开了出来，所以，也得到了很多外部的帮助，2nd Quadrant 的 CTO – Simon Riggs 在他的 blog 上也发布文章 Dataloss at Gitlab 给了一些非常不错的建议：

·         关于 PostgreSQL 9.6 的数据同步 hang 住的问题，可能有一些Bug，正在fix中。

·         PostgreSQL 有 4GB 的同步滞后是正常的，这不是什么问题。

·         正常的停止从结点，会让主结点自动释放 WALSender 的链接数，所以，不应该重新配置主结点的 max_wal_senders 参数。但是，停止从结点时，主结点的复数连接数不会很快的被释放，而新启动的从结点又会消耗更多的链接数。他认为，Gitlab 配置的32个链接数太高了，通常来说，2到4个就足够了。

·         另外，之前 gitlab 配置的 max_connections=8000 太高了，现在降到2000个是合理的。

·         pg_basebackup 会先在主结点上建一个 checkpoint，然后再开始同步，这个过程大约需要4分钟。

·         手动的删除数据库目录是非常危险的操作，这个事应该交给程序来做。推荐使用刚 release 的 repmgr。

·         恢复备份也是非常重要的，所以，也应该用相应的程序来做。推荐使用 barman （其支持S3）。

·         测试备份和恢复是一个很重要的过程。

看这个样子，估计也有一定的原因是—— Gitlab 的同学对 PostgreSQL 不是很熟悉。

随后，Gitlab 在其网站上也开了一系列的 issues，其 issues 列表在这里 Write post-mortem （这个列表可能还会在不断更新中）

·         infrastructure#1094 – Update PS1 across all hosts to more clearly differentiate between hosts and environments

·         infrastructure#1095 – Prometheus monitoring for backups

·         infrastructure#1096 – Set PostgreSQL’s max_connections to a sane value

·         infrastructure#1097 – Investigate Point in time recovery & continuous archiving for PostgreSQL

·         infrastructure#1098 – Hourly LVM snapshots of the production databases

·         infrastructure#1099 – Azure disk snapshots of production databases

·         infrastructure#1100 – Move staging to the ARM environment

·         infrastructure#1101 – Recover production replica(s)

·         infrastructure#1102 – Automated testing of recovering PostgreSQL database backups

·         infrastructure#1103 – Improve PostgreSQL replication documentation/runbooks

·         infrastructure#1104 – Kick out SSH users inactive for N minutes

·         infrastructure#1105 – Investigate pgbarman for creating PostgreSQL backups

从上面的这个列表中，我们可以看到一些改进措施了。挺好的，不过我觉得还不是很够。

3、相关思考

因为类似这样的事，我以前也干过（误删除过数据库，在多个终端窗口中迷失掉

了自己所操作的机器……），而且我在 Amazon 里也见过一次，在阿里内至少见过四次以上（在阿里人肉运维的误操作的事故是我见过最多的），但是我无法在这里公开分享。

在这里，我只想从非技术和技术两个方面分享一下我的经验和认识。

3.1、技术方面1）关于人肉运维

一直以来，我都觉得直接到生产线上敲命令是一种非常不好的习惯。我认为，一

个公司的运维能力的强弱和你上线上环境敲命令是有关的，你越是喜欢上线敲

命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。

理由如下：

·         其一，如果说对代码的改动都是一次发布的话，那么，对生产环境的任何改动（包括硬件、操作系统、网络、软件配置……），也都算是一次发布。那么这样的发布就应该走发布系统和发布流程，要被很好的测试、上线和回滚计划。

关键是，走发布过程是可以被记录、追踪和回溯的，而在线上敲命令是完全无法追踪的。没人知道你敲了什么命令。

·         其二，真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。你敲了什么命令没人知道，但是你写个工具做变更线上系统，这个工具干了什么事，看看工具的源码就知道了。

另外、有人说，以后不要用 rm 了，要用 mv，还有人说，以后干这样的事时，一个人干，另一个人在旁边看，还有人说，要有一个 checklist 的强制流程做线上的变更，还有人说要增加一个权限系统。

我觉得，这些虽然可以 work，但是依然不好，理由如下：

·         其一，如果要解决一个事情需要加更多的人来做的事，那这事就做成劳动密集型了。今天我们的科技就是在努力消除人力成本，而不是在增加人力成本。而做为一个技术人员，解决问题的最好方式是努力使用技术手段，而不是使用更多的人肉手段。

人类区别于动物的差别就是会发明和使用现代化的工具，而不是使用更多的人力。另外，这不仅仅因为是，人都是会有这样或那样的问题（疲惫、情绪化、急燥、冲动……），而机器是单一无脑不知疲惫的，更是因为，机器干活的效率和速度是比人肉高出N多倍的。

·         其二，增加一个权限系统或是别的一个 watch dog 的系统完全是在开倒车，权限系统中的权限谁来维护和审批？不仅仅是因为多出来的系统需要多出来的维护，关键是这个事就没有把问题解决在 root 上。

除了为社会解决就业问题，别无好处，故障依然会发生，有权限的人一样会误操作。对于Gitlab这个问题，正如 2nd Quadrant 的 CTO 建议的那样，你需要的是一个自动化的备份和恢复的工具，而不是一个权限系统。

·         其三，像使用 mv 而不是 rm，搞一个 checklist 和一个更重的流程，更糟糕。这里的逻辑很简单，因为:

§  这些规则需要人去学习和记忆，本质上来说，你本来就不相信人，所以你搞出了一些规则和流程，而这些规则和流程的执行，又依赖于人，换汤不换药，

§  另外，写在纸面上的东西都是不可执行的，可以执行的就是只有程序，所以，为什么不把 checklist 和流程写成代码呢？（你可能会说程序也会犯错，是的，程序的错误是 consistent，而人的错误是 inconsistent）

最关键的是，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，

掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些想流程、规则、人肉检查、权限系统、checklist 等等统统都不管用了。

这个时候，你觉得应该怎么做呢？

是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统！别无它法。

2）关于备份

一个系统是需要做数据备份的，但是，你会发现，Gitlab这个事中，就算所有的备份都可用，也不可避免地会有数据的丢失，或是也会有很多问题。理由如下：

·         备份通常来说都是周期性的，所以，如果你的数据丢失了，从你最近的备份恢复数据里，从备份时间到故障时间的数据都丢失了。

·         备份的数据会有版本不兼容的问题。比如，在你上次备份数据到故障期间，你对数据的scheme做了一次改动，或是你对数据做了一些调整，那么，你备份的数据就会和你线上的程序出现不兼容的情况。

·         有一些公司或是银行有灾备的数据中心，但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候，你就会发现，各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴 宁夏银行7月系统瘫痪最新解析》

所以，在灾难来临的时候，你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作，但也会导致数据丢失，而且可能长期不用的备份系统很难恢复（比如应用、工具、数据的版本不兼容等问题）。

我之前写过一篇《分布式系统的事务处理》，你还记得下面这张图吗？看看 Data Loss 那一行的，在 Backups，Master/Slave 和 Master/Master 的架构下，都是会丢的。

所以说，如果你要让你的备份系统随时都可以用，那么你就要让它随时都 Live 着，而随时都 Live 着的多结点系统，基本上就是一个分布式的高可用的系统。

因为，数据丢失的原因有很多种，比如掉电、磁盘损坏、中病毒等等，而那些流程、规则、人肉检查、权限系统、checklist 等等都只是让人不要误操作，都不管用。

这个时候，你不得不用更好的技术去设计出一个高可用的系统！别无它法。（重要的事，得再说一遍）

AWS 的 S3 的的高可用是4个加11个9的持久性（所谓11个9的持久性 durability，AWS 是这样定义的，如果你存了1万个对象，那么丢一个的时间是1000万年），这意味着，不仅仅只是硬盘坏，机器掉电，整个机房挂了，其保证可以承受有两个设施的数据丢失，数据还是可用的。

试想，如果你把数据的可用性通过技术做到了这个份上，那么，你还怕被人误删一个结点上的数据吗？

3.2、非技术方面1）故障反思

一般说来，故障都需要反思，在 Amazon，S2以上的故障都需要写 COE（Correction of Errors），其中一节就是需要 Ask 5 Whys，我发现在Gitlab的故障回顾的 blog 中第一段中也有说要在今天写个 Ask 5 Whys。

关于Ask 5 Whys，其实并不是亚马逊的玩法，这还是算一个业内常用的玩法，也就是说不断的问自己为什么，直到找到问题的概本原因，这会逼着所有的当事人去学习和深究很多东西。

在 Wikipedia 上有相关的词条 5 Whys，其中罗列了14条规则：

1.    你需要找到正确的团队来完成这个故障反思。

2.    使用纸或白板而不是电脑。

3.    写下整个问题的过程，确保每个人都能看懂。

4.    区别原因和症状。

5.    特别注意因果关系。

6.    说明Root Cause以及相关的证据。

7.    5个为什么的答案需要是精确的。

8.    寻找问题根源的频，而不是直接跳到结论。

9.    要基础客观的事实、数据和知识。

10. 评估过程而不是人。

11. 千万不要把“人为失误”或是“工作不注意”当成问题的根源。

12. 培养信任和真诚的气氛和文化。

13. 不断的问“为什么”直到问题的根源被找到。这样可以保证同一个坑不会掉进去两次。

14. 当你给出“为什么”的答案时，你应该从用户的角度来回答。

2）工程师文化

上述的这些观点，其实，我在我的以住的博客中都讲过很多遍了，你可以参看《什么是工程师文化？》以及《开发团队的效率》。

其实，说白了就是这么一个事 —— 如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。

这个道理很简单，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些流程、规则、人肉检查、权限系统、checklist 等等统统都不管用，这个时候，你觉得应该怎么做呢？

是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统！别无它法。（重要的事得说三遍）

3）事件公开

很多公司基本上都是这样的套路，首先是极力掩盖，如果掩盖不了了就开始撒谎，

撒不了谎了，就“文过饰非”、“避重就轻”、“转移视线”。

然而，面对危机的最佳方法就是——“多一些真诚，少一些套路”，所谓的“多一些真诚”的最佳实践就是——“透明公开所有的信息”，Gitlab 此次的这个事给大家树立了非常好的榜样。AWS 也会把自己所有的故障和细节都批露出来。（陈皓原创）

2、事件回顾

整个事件的回顾 Gitlab.com 在第一时间就放到了 Google Doc 上，事后，又发了一篇Blog来说明这个事，在这里，我简单的回顾一下这个事件的过程。

首先，一个叫YP的同学在给 gitlab 的线上数据库做一些负载均衡的工作，在做这个工作时的时候突发了一个情况，Gitlab 被 DDoS 攻击，数据库的使用飙高。

在 block 完攻击者的IP后，发现有个 staging 的数据库(db2.staging)已经落后生产库 4GB 的数据，于是YP同学在 Fix 这个 staging 库的同步问题的时候，发现 db2.staging 有各种问题都和主库无法同步。

在这个时候，YP同学已经工作的很晚了，在尝试过多个方法后，发现 db2.staging 都hang在那里，无法同步，于是他想把 db2.staging 的数据库删除了，这样全新启动一个新的复制，结果呢，删除数据库的命令错误的敲在了生产环境上（db1.cluster），结果导致整个生产数据库被误删除。

陈皓注：这个失败基本上就是 “工作时间过长” + “在多数终端窗口中切换“，于是迷失掉了

在恢复的过程中，他们发现只有 db1.staging 的数据库可以用于恢复，而其它的5种备份机制都不可用:

·         第一个是数据库的同步，没有同步 webhook；

·         第二个是对硬盘的快照，没有对数据库做；

·         第三个是用 pg_dump 的备份，发现版本不对（用9.2的版本去 dump 9.6 的数据）导致没有 dump 出数据；

·         第四个S3的备份，完全没有备份上；

·         第五个是相关的备份流程是问题百出的，只有几个粗糙的人肉的脚本和糟糕的文档，也就是说，不但是是人肉的，而且还是完全不可执行的。

陈皓注：就算是这些备份机制都 work，其实也有问题，因为这些备份大多数基本上都是24小时干一次，所以，要从这些备份恢复也一定是是要丢数据的了，只有第一个数据库同步才会实时一些。

最终，gitlab从db1.staging 上把6个小时前的数据 copy 回来，结果发现速度非常的慢，备份结点只有 60Mbits/S，拷了很长时间。

陈皓注：为什么不把 db1.staging 给直接变成生产机？因为那台机器的性能很差

数据现在恢复了，不过，因为恢复的数据是6小时前的，所以，有如下的数据丢失掉了：

·         粗略估计，有4613 的项目， 74 forks,  和 350 imports 丢失了；但是，因为Git仓库还在，所以，可以从Git仓库反向推导数据库中的数据，但是，项目中的 issues 等就完全丢失了。

·         大约有 ±4979 提交记录丢失了（陈皓注：估计也可以用git仓库中反向恢复）。

·         可能有 707  用户丢失了，这个数据来自Kibana的日志。

·         在1月31日17:20 后的 Webhooks 丢失了。

因为 Gitlab 把整个事件的细节公开了出来，所以，也得到了很多外部的帮助，2nd Quadrant 的 CTO – Simon Riggs 在他的 blog 上也发布文章 Dataloss at Gitlab 给了一些非常不错的建议：

·         关于 PostgreSQL 9.6 的数据同步 hang 住的问题，可能有一些Bug，正在fix中。

·         PostgreSQL 有 4GB 的同步滞后是正常的，这不是什么问题。

·         正常的停止从结点，会让主结点自动释放 WALSender 的链接数，所以，不应该重新配置主结点的 max_wal_senders 参数。但是，停止从结点时，主结点的复数连接数不会很快的被释放，而新启动的从结点又会消耗更多的链接数。他认为，Gitlab 配置的32个链接数太高了，通常来说，2到4个就足够了。

·         另外，之前 gitlab 配置的 max_connections=8000 太高了，现在降到2000个是合理的。

·         pg_basebackup 会先在主结点上建一个 checkpoint，然后再开始同步，这个过程大约需要4分钟。

·         手动的删除数据库目录是非常危险的操作，这个事应该交给程序来做。推荐使用刚 release 的 repmgr。

·         恢复备份也是非常重要的，所以，也应该用相应的程序来做。推荐使用 barman （其支持S3）。

·         测试备份和恢复是一个很重要的过程。

看这个样子，估计也有一定的原因是—— Gitlab 的同学对 PostgreSQL 不是很熟悉。

随后，Gitlab 在其网站上也开了一系列的 issues，其 issues 列表在这里 Write post-mortem （这个列表可能还会在不断更新中）

·         infrastructure#1094 – Update PS1 across all hosts to more clearly differentiate between hosts and environments

·         infrastructure#1095 – Prometheus monitoring for backups

·         infrastructure#1096 – Set PostgreSQL’s max_connections to a sane value

·         infrastructure#1097 – Investigate Point in time recovery & continuous archiving for PostgreSQL

·         infrastructure#1098 – Hourly LVM snapshots of the production databases

·         infrastructure#1099 – Azure disk snapshots of production databases

·         infrastructure#1100 – Move staging to the ARM environment

·         infrastructure#1101 – Recover production replica(s)

·         infrastructure#1102 – Automated testing of recovering PostgreSQL database backups

·         infrastructure#1103 – Improve PostgreSQL replication documentation/runbooks

·         infrastructure#1104 – Kick out SSH users inactive for N minutes

·         infrastructure#1105 – Investigate pgbarman for creating PostgreSQL backups

从上面的这个列表中，我们可以看到一些改进措施了。挺好的，不过我觉得还不是很够。

3、相关思考

因为类似这样的事，我以前也干过（误删除过数据库，在多个终端窗口中迷失掉

了自己所操作的机器……），而且我在 Amazon 里也见过一次，在阿里内至少见过四次以上（在阿里人肉运维的误操作的事故是我见过最多的），但是我无法在这里公开分享。

在这里，我只想从非技术和技术两个方面分享一下我的经验和认识。

3.1、技术方面1）关于人肉运维

一直以来，我都觉得直接到生产线上敲命令是一种非常不好的习惯。我认为，一

个公司的运维能力的强弱和你上线上环境敲命令是有关的，你越是喜欢上线敲

命令你的运维能力就越弱，越是通过自动化来处理问题，你的运维能力就越强。

理由如下：

·         其一，如果说对代码的改动都是一次发布的话，那么，对生产环境的任何改动（包括硬件、操作系统、网络、软件配置……），也都算是一次发布。那么这样的发布就应该走发布系统和发布流程，要被很好的测试、上线和回滚计划。

关键是，走发布过程是可以被记录、追踪和回溯的，而在线上敲命令是完全无法追踪的。没人知道你敲了什么命令。

·         其二，真正良性的运维能力是——人管代码，代码管机器，而不是人管机器。你敲了什么命令没人知道，但是你写个工具做变更线上系统，这个工具干了什么事，看看工具的源码就知道了。

另外、有人说，以后不要用 rm 了，要用 mv，还有人说，以后干这样的事时，一个人干，另一个人在旁边看，还有人说，要有一个 checklist 的强制流程做线上的变更，还有人说要增加一个权限系统。

我觉得，这些虽然可以 work，但是依然不好，理由如下：

·         其一，如果要解决一个事情需要加更多的人来做的事，那这事就做成劳动密集型了。今天我们的科技就是在努力消除人力成本，而不是在增加人力成本。而做为一个技术人员，解决问题的最好方式是努力使用技术手段，而不是使用更多的人肉手段。

人类区别于动物的差别就是会发明和使用现代化的工具，而不是使用更多的人力。另外，这不仅仅因为是，人都是会有这样或那样的问题（疲惫、情绪化、急燥、冲动……），而机器是单一无脑不知疲惫的，更是因为，机器干活的效率和速度是比人肉高出N多倍的。

·         其二，增加一个权限系统或是别的一个 watch dog 的系统完全是在开倒车，权限系统中的权限谁来维护和审批？不仅仅是因为多出来的系统需要多出来的维护，关键是这个事就没有把问题解决在 root 上。

除了为社会解决就业问题，别无好处，故障依然会发生，有权限的人一样会误操作。对于Gitlab这个问题，正如 2nd Quadrant 的 CTO 建议的那样，你需要的是一个自动化的备份和恢复的工具，而不是一个权限系统。

·         其三，像使用 mv 而不是 rm，搞一个 checklist 和一个更重的流程，更糟糕。这里的逻辑很简单，因为:

§  这些规则需要人去学习和记忆，本质上来说，你本来就不相信人，所以你搞出了一些规则和流程，而这些规则和流程的执行，又依赖于人，换汤不换药，

§  另外，写在纸面上的东西都是不可执行的，可以执行的就是只有程序，所以，为什么不把 checklist 和流程写成代码呢？（你可能会说程序也会犯错，是的，程序的错误是 consistent，而人的错误是 inconsistent）

最关键的是，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，

掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些想流程、规则、人肉检查、权限系统、checklist 等等统统都不管用了。

这个时候，你觉得应该怎么做呢？

是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统！别无它法。

2）关于备份

一个系统是需要做数据备份的，但是，你会发现，Gitlab这个事中，就算所有的备份都可用，也不可避免地会有数据的丢失，或是也会有很多问题。理由如下：

·         备份通常来说都是周期性的，所以，如果你的数据丢失了，从你最近的备份恢复数据里，从备份时间到故障时间的数据都丢失了。

·         备份的数据会有版本不兼容的问题。比如，在你上次备份数据到故障期间，你对数据的scheme做了一次改动，或是你对数据做了一些调整，那么，你备份的数据就会和你线上的程序出现不兼容的情况。

·         有一些公司或是银行有灾备的数据中心，但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候，你就会发现，各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴 宁夏银行7月系统瘫痪最新解析》

所以，在灾难来临的时候，你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作，但也会导致数据丢失，而且可能长期不用的备份系统很难恢复（比如应用、工具、数据的版本不兼容等问题）。

我之前写过一篇《分布式系统的事务处理》，你还记得下面这张图吗？看看 Data Loss 那一行的，在 Backups，Master/Slave 和 Master/Master 的架构下，都是会丢的。

所以说，如果你要让你的备份系统随时都可以用，那么你就要让它随时都 Live 着，而随时都 Live 着的多结点系统，基本上就是一个分布式的高可用的系统。

因为，数据丢失的原因有很多种，比如掉电、磁盘损坏、中病毒等等，而那些流程、规则、人肉检查、权限系统、checklist 等等都只是让人不要误操作，都不管用。

这个时候，你不得不用更好的技术去设计出一个高可用的系统！别无它法。（重要的事，得再说一遍）

AWS 的 S3 的的高可用是4个加11个9的持久性（所谓11个9的持久性 durability，AWS 是这样定义的，如果你存了1万个对象，那么丢一个的时间是1000万年），这意味着，不仅仅只是硬盘坏，机器掉电，整个机房挂了，其保证可以承受有两个设施的数据丢失，数据还是可用的。

试想，如果你把数据的可用性通过技术做到了这个份上，那么，你还怕被人误删一个结点上的数据吗？

3.2、非技术方面1）故障反思

一般说来，故障都需要反思，在 Amazon，S2以上的故障都需要写 COE（Correction of Errors），其中一节就是需要 Ask 5 Whys，我发现在Gitlab的故障回顾的 blog 中第一段中也有说要在今天写个 Ask 5 Whys。

关于Ask 5 Whys，其实并不是亚马逊的玩法，这还是算一个业内常用的玩法，也就是说不断的问自己为什么，直到找到问题的概本原因，这会逼着所有的当事人去学习和深究很多东西。

在 Wikipedia 上有相关的词条 5 Whys，其中罗列了14条规则：

1.    你需要找到正确的团队来完成这个故障反思。

2.    使用纸或白板而不是电脑。

3.    写下整个问题的过程，确保每个人都能看懂。

4.    区别原因和症状。

5.    特别注意因果关系。

6.    说明Root Cause以及相关的证据。

7.    5个为什么的答案需要是精确的。

8.    寻找问题根源的频，而不是直接跳到结论。

9.    要基础客观的事实、数据和知识。

10. 评估过程而不是人。

11. 千万不要把“人为失误”或是“工作不注意”当成问题的根源。

12. 培养信任和真诚的气氛和文化。

13. 不断的问“为什么”直到问题的根源被找到。这样可以保证同一个坑不会掉进去两次。

14. 当你给出“为什么”的答案时，你应该从用户的角度来回答。

2）工程师文化

上述的这些观点，其实，我在我的以住的博客中都讲过很多遍了，你可以参看《什么是工程师文化？》以及《开发团队的效率》。

其实，说白了就是这么一个事 —— 如果你是一个技术公司，你就会更多的相信技术而不是管理。相信技术会用技术来解决问题，相信管理，那就只会有制度、流程和价值观来解决问题。

这个道理很简单，数据丢失有各种各样的情况，不单单只是人员的误操作，比如，掉电、磁盘损坏、中病毒等等，在这些情况下，你设计的那些流程、规则、人肉检查、权限系统、checklist 等等统统都不管用，这个时候，你觉得应该怎么做呢？

是的，你会发现，你不得不用更好的技术去设计出一个高可用的系统！别无它法。（重要的事得说三遍）

3）事件公开

很多公司基本上都是这样的套路，首先是极力掩盖，如果掩盖不了了就开始撒谎，

撒不了谎了，就“文过饰非”、“避重就轻”、“转移视线”。

然而，面对危机的最佳方法就是——“多一些真诚，少一些套路”，所谓的“多一些真诚”的最佳实践就是——“透明公开所有的信息”，Gitlab 此次的这个事给大家树立了非常好的榜样。AWS 也会把自己所有的故障和细节都批露出来。（陈皓原创）