Shell's Home

May 29, 2015 - 1 minute read - Comments

携程本次问题分析

携程这次的事情,实在没啥好多说的了。要骂的话,早就骂过了。我们就来说说携程这次事故中,我们能确定的事情吧。

小道消息

首先我要排除一切小道消息,包括数据库被“物理”删除了,前任总监报复,运营妹子和高管好上了什么的。昨天和朋友开玩笑,物理删除要怎么做呢?你要盯着硬盘,直到他羞愧到不能淡定,自己从服务器里裸奔出来,纵身从楼上跳下去。这才叫物理删除。第二天报纸准出新闻——硬盘们,不要着急,等待反弹。。。

至于前任总监报复,运营妹子和高管好上了。我越听越像电视剧,还是国产的。这些没影子的事情就不多说了,我们来说点有用的。

事实

首先,我们要搞清楚一个问题。携程自己说的话,是没用的。

是的,无论是故障时的混乱情况导致说错话,还是出于稳定情绪角度的说辞,都没太大价值。最多用来旁证分析。我们还是要追踪当时发生的,确定无疑的事件,以这个来佐证。

我们可以确定的事情有:

  1. 携程的系统挂了近12个小时。
  2. 挂掉的是应用层,而不是数据库层。
  3. 携程下午到晚上悬赏解决问题。
  4. 恢复后,历史数据存在,当然部分出问题时的数据丢失(这是必然)。

14是大家都看的到的。2是因为没有数据库连不上时的各种应用错误提示,干脆就是网页直接失踪。这说明问题不是光缆挖断,也不是数据库(至少不能直接佐证)。能够确认的是应用确实没了。3是来自道哥的消息,我觉得应该比较靠谱(毕竟涉及钱)。

分析

好,综合123,我有个推论。携程在出问题的时候,很快就知道了是应用的问题(至少确定应用有问题)。然后试着恢复,但是无效。原因携程自己都不知道。

这是自然。如果携程不知道应用层有问题,太业余。没试着恢复,太二。恢复了有效,不像。携程知道为什么,那还发布个毛悬赏?综合起来,那就是恢复了没见效,而且携程自己都不知道原因了。

同时这个结论也隐隐的排斥高管报复说,至少携程当时不能确认是高管报复,而是作为通用性技术问题来处理的。如果是高管报复,你找外人来管个毛用啊。再黑自己一遍?

当然,这个推论有个前提。携程的悬赏不是为了转移视线的烟幕弹。不过看当时的情况,我觉得这种可能不大。

那么问题的技术细节呢?不知道。携程自己找到没找到原因?不知道。我们知道点啥?数据库备份没事。

是的,我没法确认当天数据库没事(因为我没有当天订单)。不过看事后没人吐槽,估计是没事的。

事后

携程事后说是程序员错误的删除发布的应用,这个和上文“问题出在应用层”一致。在问题原因上,携程没多大掩饰的空间。但是“程序员误删除”这个说法是真是假就不好说了。实话说,这个说辞显得像是背黑锅,推责任。但无法排除,确实可能是事实的真相。

但是这个说法无法解释的是,为什么恢复时间那么长,而且还开出了悬赏。编译整个系统,然后重新发布确实很慢。但是一来时间不会如此长。二来更关键,程序员非常清楚问题在哪,要花多久。你找个技术专家来弄这个事情也未见得快。而且就算要找,也肯定限制在所用技术系统的编译和发布专家里找,不会满世界的开悬赏。如果真的是重发布时间过长,领导层又挂出了悬赏。这无疑是在瞎指挥。

最后就是“携程在系统上做了改进,规范并杜绝技术人员错误删除生产服务器上代码的操作”。这里明显漏了一个要点”加强部署和恢复演练和自动化推进“。

一般来说,在系统设计的时候,首先考虑的是“如果不小心被删除了怎么恢复”。而不是“如何防止错误的删除”。就像我和一位同事解释的,你可以将rm替换成别的程序,但是如果对方用的是dd呢?如果是chmod呢?如果下次,操作人员执行的不是删除,而是格式化呢?或者是更改ACL权限错误。这无疑要求限制所有操作人员能做的事情。

银行里就是采取的这种思路。每个运维能做的事都被严格限死,很难越雷池一步。但是同时要注意两点。首先,银行的业务相对固定,运维要干的事非常规范。携程的运维恐怕很难做到如此规范。其次,银行是有严密的恢复机制的,恢复机制(包括演练)也是运维的固定工作之一。

考虑一下。如果没有恢复演练。那么万一因为不可知因素,携程需要再度恢复(好倒霉。。。)的时候。运维有没有删除数据的权限呢?有没有修改权限的权限呢?携程的”杜绝技术人员误删除“的手段,还要不要坚持呢?

多说一句

网络上有个哥们猜测”可能是高管报复“的时候,推测是在编译环境里做手脚。这个和我当时的观点一致(不代表我认同他说的这个事实)——要让多个系统始终编译和发布了都不能工作,最有效的后门就在编译环境里。毕竟很少有代码能够跨越多个系统,但是几乎所有项目都会使用同样的编译环境。

程序的持续更新 list.append的性能分析

comments powered by Disqus