Gitlab：一场“删库”血案引发的反思

过年期间，一条Gitlab误删数据的新闻占领了各大科技网站的头条。一切令人惊叹感慨，一切又让人似曾相似。回首2016年，网络重大异常事件其实并不罕见。

<< 2016.03
全球三分之二网站服务器用的开源加密工具OpenSSL爆出“水牢漏洞”。
<<  2016.04
土耳其因数据库漏洞，近5000万公民信息遭泄露。
<< 2016.09
雅虎曝史上最大规模信息泄露，5亿用户资料被窃。
<< 2016.10
Dyn DNS遭到了大规模DDoS攻击，美国大半互联网下线。
<< 2016.11
德国电信路由设备的维护界面暴露，90万家庭断网。
<< 2016.12
黑客伪造用户证书攻击俄罗斯央行，3100万美元不翼而飞。

2017年1月，“Gitlab误删库事件”再掀血案，再次挑动起业界对信息安全和重大风险的敏感神经。

【事件回顾】

Gitlab对整个事件的回顾和处理进行实时更新，让我们可以清晰地看到整个事件的发生过程：Gitlab的一位系统管理员在给线上数据库做负载均衡工作时，遭受了DDoS攻击。在阻止了攻击之后，运维人员发现了数据库不同步的问题，便开始修复，在修复过程中，错误地在生产环境上执行了数据库目录删除命令，导致300GB数据被删除，Gitlab被迫下线。在恢复的过程中，他们发现只有db1.staging的数据库可以用于恢复，而其它的5种备份机制都不可用。db1.staging
是6小时前的数据，而且传输速率有限，导致恢复进程缓慢，Gitlab 最终丢掉了差不多6个小时的数据。

面对这样的异常事件，技术上的分析不是我们想讨论的，真正值得探讨的是：在风险无处不在的金融市场，我们该如何对重大异常进行反思，从而做到更好地预防和处理异常和故障。

【如何反思异常】

不管是传统的工业领域，还是IT行业，异常的预防和处理都是一项重要课题。当异常和故障发生时，如何及时追究问题发生的原因，妥善解决和处理异常，并总结原因预防故障再次发生，体现出一家公司服务意识、技术能力和市场竞争力。

在Gitlab故障回顾的blog中提到要写“Ask 5 Whys”，其实在分析和反思故障的过程中，很多IT企业会用“Ask 5 Whys”，例如亚马逊。5Why分析法是由丰田创始人丰田佐吉提出的，就是对一个问题点连续以5个“为什么”来自问，以追究其根本原因，在实际运用中问题并不限于5个。这一方法在丰田汽车公司被广泛应用，是一项必须的培训内容。丰田汽车的大野耐一曾举了一个找出停机原因的经典案例：

＞＞问题一：为什么机器停了？
答案一：因为机器超载，保险丝烧断了。
＞＞问题二：为什么机器会超载？
答案二：因为轴承的润滑不足。
＞＞问题三：为什么轴承会润滑不足？
答案三：因为润滑泵失灵了。
＞＞问题四：为什么润滑泵会失灵？
答案四：因为它的轮轴耗损了。
＞＞问题五：为什么润滑泵的轮轴会耗损？
答案五：因为杂质跑到里面去了。

经过连续五次不停地问“为什么”，才找到问题的真正原因和解决的方法，在润滑泵上加装滤网。如果员工没有以这种追根究底的精神来发掘问题，他们很可能只是换根保险丝草草了事，真正的问题还是没有解决。5why法的关键所在：鼓励解决问题的人要努力避开主观或自负的假设和逻辑陷阱，从结果着手，沿着因果关系链条，顺藤摸瓜，直至找出原有问题的根本原因。

当我们的IT系统发生异常时，需要问自己：为什么会发生？为什么没有发现？为什么没有从系统上预防事故？每个层面连续5次或N次的询问，得出最终结论。只有以上三个层面的问题都探寻出来，才能发现根本问题，并寻求解决。例如Gitlab事件，需要问很多问题：为什么会出现数据库不同步？为什么会丢失数据？为什么轻易在生产环境上执行删除命令？为什么运维过程如此混乱？为什么备份机制都失效？为什么备份失效平时未检查？只有把这些问题一个个搞清楚，一个个进行5why分析，才能把问题和隐患一个个解决。

【优化异常处理流程】

当异常发生后，需要一套完备的流程来处理异常，保证快速反馈问题，及时跟进技术人员，确定行动计划，拿出解决方案，落实回访与总结。

在Gitlab事件中技术人员对异常的处理有些杂乱无章，当受到DDoS攻击后，出现数据库使用飙高这一异常，在解决攻击后引发了另一项异常（数据无法同步），在处理数据同步异常时又出现误删数据库，最后在数据恢复过程中发现集中备份机制都失效，可以说是在处理一个异常的过程中反而引发了更多的异常，最终备份机制这一解决方案也失效。虽然这不完全是流程上的问题，但可以看到处理流程的混乱引发了更多的问题。一套完备的流程会更有利于问题的解决。

异常的类型和性质并非千篇一律，需要根据异常发生的情况不断对处理流程进行优化，以更好地应对不同类型的问题。

【自我审视和树立风险意识】

在Gitlab事件中，有两个致命的问题引发最大的关注，一是运维人员删除数据库的命令错误的敲在了生产环境上，另一个是恢复数据时5种备份机制全部失效。大家奇怪的是，运维人员在处理问题时，没有任何限制就可以在生产环境上执行删除目录这样高危的操作，然后5种备份机制全部失效在平时为何没有发现。这两个问题暴露出Gitlab的很多问题，而有些问题是可以防患于未然的，我们在平时的工作中需要经常自我审视，审视产品质量，审视流程和规则，审视自身能力，审视风险隐患。

有些问题可以靠技术预防，有些问题可以靠流程和规则预防，例如误删数据库的运维人员，可以用自动化运维、智能运维来代替“人肉运维”，避免低级错误；可以通过规范的流程和规则来避免误删数据这样的失误；通过平时的测试和演练来检查备份方案是否有效。很多问题是可以在平时预防的。

金融市场的风险无处不在，有经济客观存在的风险，也有主观失误的风险（例如乌龙指），为金融市场服务的技术也会存在风险，我们要在平时的工作中树立风险意识，经常审视自我发现问题，开发更高质量的产品，不要因产品和技术的不到位影响市场的稳定和企业的发展，避免出现像Gitlab误删数据这样的“技术乌龙指”。

【敢于直面故障和异常】

当异常发生时，我们需要以积极的心态去面对，勇于承担责任，而不是掩盖和逃避，有些企业在异常发生后遮遮掩掩推脱责任，反而失去用户的信任。我们应该直面问题，拥抱客户拥抱监管，用心解决问题，对客户负责，对社会负责。
 
任何程序都会有Bug，任何系统都会有异常，Gitlab只是一个缩影，提醒我们需要时刻注意风险，积极总结和反思，预防那些可以避免的异常，妥善处理已经发生的异常，让产品更好地服务客户。