/ 中存储网

携程可能摊上大事了—崩溃原因分析之「高能技术贴」

2015-05-28 18:16:12 来源:虎嗅网

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

网站崩溃的表象

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

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

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

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

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

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

可能摊上大事了

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

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

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

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