那 么，携程连续数小时瘫痪原因究竟为何？又是什么原因使事故持续时间如此之长？业内专家对携程此次事件有什么观点阐述？携程包括行业对该类事件又该进行何种 反思？如果这样的黑锅注定运维来背，那解决运维问题的核心和难点又是什么？数据管理又面临怎样的困难和挑战？InfoQ将持续从运维等角度针对事件相关做 深度分析报道。

事故原因猜测

猜测一 数据库被物理删除

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

事实上这个猜测实在不算专业，应该是第一个传播者试图强调问题之严重和恢复之困难，所以用了一个普通电脑用户比较熟悉的“物理删除”的概念。实际上，任何一个网站的数据库，都分为本地高可用备份、异地热备、磁带冷备三道防线，相应的数据库管理员、操作系统管理员、存储管理员三者的权限是分离的，磁带备份的数据甚至是保存在银行的地下金库中的。从理论上而言，很难有一个人能把所有的备份数据都删除，更不用说这个绘声绘色的物理删除了。所以即使没有官方辟谣，这一猜测也基本可以被否认。

猜测二 业务代码被删除

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

猜测三 黑客攻击/内部员工破坏

这个说法能满足一些围观者猎奇的心理，因此也传播的比较快。但理性分析，可能性也不大。黑客讲究的是潜伏和隐蔽，做这种事等于是在做自杀性攻击。而内部员工也不太可能，我还是相信携程的运维人员的操守和职业素养，在刑法的威慑下，除非像“法航飞行员撞山”那种极个别案例，正常情况下不太可能出现人为恶意的可能性。

从现象上看，确实是携程的应用程序和数据库都被删除。最大的可能还是运维人员在正常的批量操作时出现了误操作。我猜测的版本是：携程网被“乌云”曝光了一个安全漏洞，漏洞涉及到了大部分应用服务器和数据库服务器；运维人员在使用pssh这样的批量操作执行修复漏洞的脚本时，无意中写错了删除命令的对象，发生了无差别的全局删除，所有的应用服务器和数据库服务器都受到了影响。这个段子在运维圈子中作为笑话流传了很多年，没想到居然真的有这样一天。

恢复缓慢原因

持续数小时未恢复成功使得大家对是不是数据库没有备份产生怀疑。这也是那个“数据库物理删除”的说法很流行的一个根源。实际上这个还是普通用户，把网站的备份和恢复理解成了类似我们的笔记本的系统备份和恢复的场景，认为只有有备份在，很快就能导入和恢复应用。

实际上大型网站，远不是像把几台应用和数据库服务器那么简单。看似很久都没有变化的一个网站，后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由成百上千个应用子系统组成，每个子系统又包括若干台应用和数据库服务器，大家可以理解为每一个从首页跳转过去的二级域名都是一个独立的应用子系统。这上千的个应用子系统，平时真正经常发布和变更的，可能就是不到20%的核心子系统，而且发布时都是做加法，很少完全重新部署一个应用。

在平时的运维过程中，对于常见的故障都会有应急预案。但像携程这次所有系统包括数据库都需要重新部署的极端情况，显然不可能在应急预案的范畴中。在仓促上阵应急的情况下，技术方案的评估和选择问题，不同技术岗位之间的管理协调的问题，不同应用系统之间的耦合和依赖关系，还有很多平时欠下的技术债都集中爆发了，更不用说很多不常用的子系统，可能上线之后就没人动过，一时半会都找不到能处理的人。更要命的是，网站的核心系统，可能会写死依赖了这个平时根本没人关注的应用，想绕开边缘应用只恢复核心业务都做不到。更别说在这样的高压之下，各种噪音和干扰很多，运维工程师的反应也没有平时灵敏。

简单的说，就算所有代码和数据库的备份都存在，想要快速恢复业务，甚至比从0开始重新搭建一个携程更困难。携程的工程师今天肯定是一个不眠夜。乐观的估计，要是能在24小时之内恢复核心业务，就已经非常厉害了。

专家观点解读

InfoQ高效运维群的智锦针对故障为何持续如此长时间发表了自己的看法：

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

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

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

中国移动王晓征：

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

新浪微博TimYang从团队角度出发发表观点：

出现故障后，虽然公司会有财务及形象上的损失，但是领导者这时候更多需要创造好的环境给工程师来解决问题，切记不要急于施加时间压力或者问责，不然最有能力去解决问题的一线工程师可能会因为压力过大而降低效率。

故障根源反思

运维：预防和治理更应该从企业入手

携程的这次事件，不管原因是什么，都会成为IT运维历史上的一个标志性事件。相信之后所有的IT企业和技术人员，都会去认真的反思，总结经验教训。但我相信，不同的人在不同的位置上，看到的东西可能是截然相反的，甚至可能会有不少企业的管理者受到误导，开始制定更严格的规章制度，严犯运维人员再犯事。在此，我想表明一下我的态度：这是一个由运维引发的问题，但真正的根源其实不仅仅在运维，预防和治理更应该从整个企业的治理入手。

长久以来，在所有的企业中，运维部门的地位都是很边缘化的。企业的管理者会觉得运维部门是成本部门，只要能支撑业务就行。业务部门只负责提业务需求，开发部门只管做功能的开发，很多非功能性的问题无人重视，只能靠运维人员肩挑人扛到处救火，可以认为是运维部门靠自己的血肉之躯实现了业务部门的信息化。在这样的场景下，不光企业的管理者不知道该如何评价运维的价值，甚至很多运维从业者都不知道自己除了到处救火外真正应该关注什么，当然也没有时间和精力去思考。

在上文的情况下，传统的运维人员实际上是所谓的“黑盒运维”，不断的去做重复性的操作，时间长了之后，只知道自己管理的服务器能正常对外服务，但是却不知道里面应用的依赖关系，哪些配置是有效配置、哪些是无效配置，只敢加配置，不敢删配置，欠的技术债越来越多。在这样的情况下，遇到这次携程的极端案例，需要完整的重建系统时候，就很容易一筹莫展了。

对于这样的故障，我认为真正有效的根源解决做法是从黑盒运维走向白盒运维。和Puppet这样的运维工具理念一致，运维的核心和难点其实是配置管理，运维人员只有真正的清楚所管理的系统的功能和配置，才能从根源上解决到处救火疲于奔命的情况，也才能真正的杜绝今天携程这样的事件重现，从根本上解决运维的问题。

从黑盒运维走向白盒运维，再进一步实现DevOps（开发运维衔接）和软件定义数据中心，就是所谓的运维2.0了。很显然，这个单靠运维部门自身是做不到的，需要每一个企业的管理者、业务部门、开发部门去思考。因此，我希望今天这个事件，不要简单的让运维来背黑锅，而是让大家真正的从中得到教训和启示。

数据管理：核心不变

数据备份保护

数据备份是数据保护的最后一道防线。数据备份的核心价值是通过有效的数据备份手段，降低数据丢失风险，提升数据安全保障。数据备份的关键是有效性。数据管理规划中，如何更有效地进行数据备份保护是重点。数据备份不是目的，可恢复才是关键。有效的数据备份需要进行合理的规划，包括合理的备份窗口、备份的可恢复性、跨站点或远距离备份容灾等。如果需要更安全的保护，那么道理很简单，那就是做更多的冗余，多样的介质冗余，多地的冗余；同时定期进行数据恢复演练与验证。

如何保障用户数据高可用与业务联系

数据的高可用性与一致性，是业务连续性的基础。为了提升数据高可用性，诞生了很多我们耳熟能详的技术：RAID、镜像、复制、双活高可用、分布式技术，等等。这些技术诞生的背后，很多都是基于当时的用户对数据高可用与业务连续性的需求。对于业务连续性要求很高的用户来说，如金融、医院等用户，构建一套能够确保数据高可用的系统非常关键。因此，在设计重要业务系统的数据管理架构时，数据高可用与业务连续性的规划也是必不可少的一部份。

如何节省用户数据存储与管理成本

有效的数据管理，不仅仅是为了提升数据安全性与业务连续性，同时也是为了降低数据存储与管理的总成本。关于数据存储的成本，我们通常想到的是存储容量成本，如每TB多少钱。实际上，数据存储与管理的成本远远不止这些，还涉及容量成本、IO成本、安全成本、电力成本、运维成本等。然而大多数公司只注重容量成本，却忽略了其他成本，例如安全成本。当数据量小，IO压力不大时，这些成本支出还可以接受；但数据量大、IO需求也大时，安全、电力、运维成本也将大幅增加，总体成本的支出将可能难以承受。