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

小道消息

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

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

事实

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

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

我们可以确定的事情有：

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

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

分析

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

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

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

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

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

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

事后

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

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

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

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

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

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

多说一句

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