深刻解析和反思携程宕机事件

本文做者智锦，资深运维从业者，自动化运维和云计算倡导者，曾做为支付宝运维团队创始人，管理过上万台服务器，后做为建行特聘互联网技术专家，主导了建设银行总行数据中心私有云计算平台建设。智锦目前是杭州云霁科技有限公司创始人，作运维领域的创业，致力于开发全中国最好的数据中心操做系统。

······················································································

携程网宕机事件还在持续，截止28号晚上8点，携程首页仍是指向一个静态页面，全部动态网页都访问不了。关于事故根源，网上众说纷纭。做为互联网运维老兵，尝试分析缘由，谈谈个人见解

1、 宕机缘由分析

网上有各类说法，有说是数据库数据和备份数据被物理删除的。也有说是各个节点的业务代码被删除 如今从新在部署。也有说是误操做，致使业务不可用，还有说是黑客攻击甚至是内部员工恶意破坏的。

先说一下最先传出来的“数据库物理删除”，其实这个提法就很不专业，应该是第一个传播者，试图强调问题之严重和恢复之困难，因此用了一个普通电脑用户比较熟悉的“物理删除”的概念。实际上，任何一个网站的数据库，都分为本地高可用备份、异地热备、磁带冷备三道防线，相应的数据库管理员、操做系统管理员、存储管理员三者的权限是分离的，磁带备份的数据甚至是保存在银行的地下金库中的。从理论上而言，很难有一我的能把全部的备份数据都删除，更不用说这个绘声绘色的物理删除了。

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

从现象上看，确实是携程的应用程序和数据库都被删除。我分析，最大的可能仍是运维人员在正常的批量操做时出现了误操做。我猜想的版本是：携程网被“乌云”曝光了一个安全漏洞，漏洞涉及到了大部分应用服务器和数据库服务器；运维人员在使用pssh这样的批量操做执行修复漏洞的脚本时，无心中写错了删除命令的对象，发生了无差异的全局删除，全部的应用服务器和数据库服务器都受到了影响。

这个段子在运维圈子中做为笑话流传了不少年，没想到竟然真的有这样一天。

二 、为何恢复的如此缓慢？

从上午11点传出故障，到晚上8点，携程网站一直没能恢复。因此不少朋友很疑惑：“为何网站恢复的如此缓慢？是否是数据库没有备份了？”这也是那个“数据库物理删除”的说法很流行的一个根源。实际上这个仍是普通用户，把网站的备份和恢复理解成了相似咱们的笔记本的系统备份和恢复的场景，认为只有有备份在，很快就能导入和恢复应用。

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

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

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

天下运维是一家。携程的同行加油，尽快度过难关！

三 、故障根源反思：黑盒运维之殇。

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

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

在上文的状况下，传统的运维人员其实是所谓的“黑盒运维”，不断的去作重复性的操做，时间长了以后，只知道本身管理的服务器能正常对外服务，可是殊不知道里面应用的依赖关系，哪些配置是有效配置、哪些是无效配置，只敢加配置，不敢删配置，欠的技术债愈来愈多。在这样的状况下，遇到此次携程的极端案列，须要完整的重建系统时候，就很容易束手无策了。

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

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

 

转自：http://mp.weixin.qq.com/s?__biz=MzA4MDYwMDQ5Mg==&mid=207052274&idx=1&sn=db02845f87053c0c5402e610a0f3b1e7