携程网瘫痪超8小时，故障原因全解析

热点

5月28日上午11时许，携程网突然陷入瘫痪，官方表示是由于携程部分服务器遭到不明攻击，而导致官方网站及APP无法正常使用。对于事故原因，社交网站和微信群中都有不同的猜测，主要包括数据库被物理删除、业务代码被删除或者安全漏洞。

物理删除是指文件存储所用到的磁存储区域被真正的擦除或清零，这样删除的文件是不可以恢复的。如果携程的数据库被物理删除，那损失不可估量。不过，携程网已经明确表示数据库被物理删除纯属谣言，所有的订单数据都保存完整。从技术角度来看，物理删除的速度非常慢，携程那么多的数据在短时间内被删除的可能性不大。所以这一猜测基本可以被否认。

另外一个猜测是业务源代码被删除。一份疑似携程的内部邮件表示：『Croller中保留了上次编译后的版本，fat到prd环境所有Windows环境编译后的源代码被删除』，如果这份邮件属实，那基本可以确认此次事故是由于业务源代码被删除引起的。同样某专业人士也赞同此观点 ，他认为携程数据库至少隔天多次备份，被删除的可能性不大。而由于代码每天都会上线并且有代码库，所以可能没有做备份。但如果只是线上代码被删除，那不太可能瘫痪这么长时间。

但为什么这次的故障持续时间能这么长？InfoQ高效运维群的智锦发表了自己的看法：

携程目前指向一个静态页面，所有动态网页都访问不了。有人问为什么从备份恢复这么慢？现在SOA架构的网站，都是由成百上千个应用子系统组成。平时真正经常发布的，可能就是不到20%的核心子系统。而且发布时都是做加法，很少完全重新部署一个应用，一旦遇到需要所有系统都需要重新部署的极端情况， 管理协调的问题，应用之间的依赖关系、还有很多平时欠下的技术债都集中爆发了，更不用说很多不常用的子系统，上线之后就没人动过，一时半会都找不到能处理的人。而且，在这样的高压之下，各种噪音和干扰很多，运维工程师的反应也没有平时灵敏。

如果是代码被删除，那也就是说某个员工可能拥有携程大部分服务器的登录和操作权限。所以有人认为携程在安全审核和权限控制方面的流程存在问题。但也有人认为再完善的流程也有可能被钻漏洞，人品比技术更重要。

如果把这次的故障比作一次地震，那这次灾难可能就是携程的『汶川地震』了。减少地震伤亡的一种有效做法是应急演练，同样，软件公司也需要灾难演练，以防不备之灾。中国移动的三少说道：

浙江移动每年的大小演练有近300次，去年核心CRM系统在白天中午11点左右做整体切换，不到5分钟就全部完成了。浙江移动内部有一个故障参考手册，运维人员可以根据手册判断故障可能会影响到的业务，并根据影响到的业务确定相应的处理方案，最后会根据处理时间评定故障等级，并汇报给相应的负责人。针对大的故障，核心思路应该是先恢复，再修复。

新浪微博的TimYang也从团队角度发表了自己的看法，他认为，出现故障后，虽然公司会有财务及形象上的损失，但是领导者这时候更多需要创造好的环境给工程师解决问题，不要急于施加时间压力或者问责，不然最有能力去解决问题的一线工程师会因为压力过大而降低效率。

截止发稿前，携程网已瘫痪超过8个小时，至今未全部恢复。接下来InfoQ将会重点跟进携程网的故障事件，敬请关注后续报道。