携程数据库事件网上有各种说法。有说是数据库数据和备份数据被物理删除的。也有说是各个节点的业务代码被删除 现在重新在部署。也有说是误操作，导致业务不可用。尽管众说纷芸，做为一个技术人员，我们还是需要透过现象看本质。

网站崩溃的表象

我们先观察一下ctrip这次问题的表现。从我观察视角来看，在下午2点左右，携程PC版的首页上的酒店、机票这两个最核心的应用还是无法使用的，而且个人用户也是无法登录的，同时携程手机端的酒店、机票无法使用，以及个人订单是无法查询的。

而网上的新闻报道上午11点服务就不可用了：携程方面称，今天上午11时09分，携程的部分服务器遭到不明***，导致官方网站及APP暂时无法正常使用，目前正在紧急恢复。从携程内部人士处获悉，此次不明***是携程未拦截成功的第一次数据库***，目前技术部正在抢救。

数据库整体被***的可能性极大

从这些信息来判断，应该不是业务流程上线中出BUG，或者上线流程过程有些误操作。为什么这么讲，我们要进行粗略分析。对于用户的角度来讲，好像携程的首页是只有一个，好像携程只有首页这么一个，各个业务的入口是统一的，但是从程序以及项目管理的角度来看，单单只是从携程的首页来看，至少有14以上个业务部门以及项目，而且这些项目之间关联耦合度不大，平时上线肯定也是独立上线的，如果一个项目挂了，短暂不可用又很快恢复了，那还可以理解，毕竟谁上线没有回滚过。但是大面积绝大部分业务都不可用，必然不是正常的上线流程中出问题。基本上我们可以判断，携程内部系统肯定是受到大规模的***，大部分的业务节点受到严重的***或者数据库受到严重的***，至于是内部员工或者是***那就不好说了。

我们再来分析下是不是业务节点受***，从表象来看，业务节点或者负载均衡应该是被***了，不然不会点击酒店和机票搜索都会跳出Http/1.1 Service Unavailable，而应该会出现搜索迟迟不出结果，但是网页大部分的界面还是可以展现的。如果仅仅是业务节点受***，比如：所有的业务节点上的部署的代码、程序被删除了，或者是关机了，受到这种***恢复的手法还是可以非常迅猛的，毕竟机器还在，携程做为一个十几年的老牌公司，上线部署流程应该是建设的比较完善的，可以在比较短的时间内进行恢复。

我们再看是不是某个数据库挂了，从前面我们也讲到，携程的业务多，项目多，这些项目与业务线是不太可能使用同一台数据库的物理机的，携程的数据库机器数量肯定是比较庞大的，而且我相信携程的数据库肯定是做好高可用的，同时日常备份是定期进行的。如果只是个别数据库挂了，恢复起来的时间是非常快的。但是从这次***的事件来看，数据库整体被***的可能性非常大。

可能摊上大事了

如果这是一次******，那***对携程内部的系统了解程度那是相当的深，而且***、潜伏的时间非常长。如果这是一次非常恶意的***，而且***对携程苦大仇深，想一击致命的话，数据库就会是核心***目标。业务节点丢点程序代码不会紧，最多就像人走在大街上衣服被抢光了而已，虽然丢人，但是还是可以很快再搞几件衣服回来穿上就是了，要是数据库被删除，而且不仅仅是逻辑删除，而且是物理删除，同时把所有备份也进行非常彻底的物理删除的话，那基本上心脏中qiang，没得救了，不过好在这种情况出现的可能性不大。如果***把数据库所在的主、从机器上的数据全部进行逻辑删除，同时运行类似于dd的命令进行数据覆盖，那么主、从机器上的数据是没法救的。

从网上的新闻来看，上午11点09服务就不可用了，我们做一个最坏情况的猜测：***应该是***了大部分的数据，同时估计也备份到存储上的数据也给删除了。所以到现在，携程的服务还没有恢复。

那么现在的问题关键点来了：携程是用什么方式进行数据库的备份的（如果没有日常备份，那整个携程就可悲剧了）。如果采用内部私有云存储的方式进行备份，那么此事还有的救。虽然***有可能把这些数据从云存储的应用端删除，但是服务端这些数据可能还存在。数据是否可以恢复要取决于私有云存储的架构。携程从公开的报道来看，内部私有云用的是openstack，那么很有可能是使用swift的存储，除非***也是非常熟悉swift的架构，把swift上的三个备份的机器找到，进行物理删除。否则，数据还是有可能恢复的。如果到备份到存储一体机，我相信数据还是有可能找的回来的。简而言之：如果有正常的备份，我相信数据还是可以恢复，如果没有做数据库日志的实时备份的话，最多丢个一备份周期的数据（一般是一天）。

上面讲的都是针对性的***，但是最坏的情况是：***掌握了携程大部分机器的root权限,同时进行无差别的毁灭性的***的话（业务节点、数据库节点、存储节点），那后果反正我是不敢想了。