携程网宕机事件持续了大半天，直到将近深夜了才恢复，历时长达11个小时，实在罕见。关于事故根源，网上也众说纷纭。作为互联网运维老兵，尝试分析原因，谈谈我的看法。
宕机原因分析
网上有各种说法，有说是数据库数据和备份数据被物理删除的。也有说是各个节点的业务代码被删除，在重新部署。也有说是误操作，导致业务不可用。还有说是黑客攻击甚至是内部员工恶意破坏的。
先说一下最早传出来的“数据库物理删除”，其实这个提法就很不专业，应该是第一个传播者，试图强调问题之严重和恢复之困难，所以用了一个普通电脑用户比较熟悉的“物理删除”的概念。
实际上，任何一个网站的数据库，都分为本地高可用备份、异地热备、磁带冷备三道防线，相应的数据库管理员、操作系统管理员、存储管理员三者的权限是分离的，磁带备份的数据甚至是保存在银行的地下金库中的。
从理论上而言，很难有一个人能把所有的备份数据都删除，更不用说这个绘声绘色的物理删除了。
第二个则是黑客攻击和内部员工破坏的说法，这个说法能满足一些围观者猎奇的心理，因此也传播的比较快，但理性分析，可能性也不大。
黑客讲究的是潜伏和隐蔽，做这种事等于是在做自杀性攻击，而内部员工也不太可能，我还是相信携程的运维人员的操守和职业素养。在刑法的威慑下，除非像“法航飞行员撞山”那种极个别案列，正常情况下不太可能出现人为恶意的可能性。
从现象上看，确实是携程的应用程序和数据库都被删除。我分析，最大的可能还是运维人员在正常的批量操作时出现了误操作。
我猜测的版本是：携程网被“乌云”曝光了一个安全漏洞，漏洞涉及到了大部分应用服务器和数据库服务器；运维人员在使用pssh这样的批量操作执行修复漏洞的脚本时，无意中写错了删除命令的对象，发生了无差别的全局删除，所有的应用服务器和数据库服务器都受到了影响。
这个段子在运维圈子中作为笑话流传了很多年，没想到居然真的有这样一天。
为什么恢复的如此缓慢？
从上午11点传出故障，到晚上8点，携程网站一直没能恢复。所以很多朋友很疑惑：“为什么网站恢复的如此缓慢？是不是数据库没有备份了？”这也是那个“数据库物理删除”的说法很流行的一个根源。
实际上这个还是普通用户，把网站的备份和恢复理解成了类似我们的笔记本的系统备份和恢复的场景，认为只有有备份在，很快就能导入和恢复应用。
实际上大型网站，远不是像把几台应用和数据库服务器那么简单。看似很久都没有变化的一个网站，后台是一个由SOA（面向服务）架构组成的庞大服务器集群。看似简单的一个页面背后由成百上千个应用子系统组成，每个子系统又包括若干台应用和数据库服务器，大家可以理解为每一个从首页跳转过去的二级域名都是一个独立的应用子系统。
这上千的个应用子系统，平时真正经常发布和变更的，可能就是不到20%的核心子系统，而且发布时都是做加法，很少完全重新部署一个应用。
在平时的运维过程中，对于常见的故障都会有应急预案，但像携程这次所有系统包括数据库都需要重新部署的极端情况，显然不可能在应急预案的范畴中。
在仓促上阵应急的情况下，技术方案的评估和选择问题，不同技术岗位之间的管理协调的问题，不同应用系统之间的耦合和依赖关系，还有很多平时欠下的技术债都集中爆发了，更不用说很多不常用的子系统，可能上线之后就没人动过，一时半会都找不到能处理的人。
更要命的是，网站的核心系统，可能会写死依赖了这个平时根本没人关注的应用，想绕开边缘应用只恢复核心业务都做不到。
更别说在这样的高压之下，各种噪音和干扰很多，运维工程师的反应也没有平时灵敏。
简单的说，就算所有代码和数据库的备份都存在，想要快速恢复业务，甚至比从0开始重新搭建一个携程更困难。即便基本恢复了，携程的工程师今天也肯定是一个不眠夜。
故障根源反思：黑盒运维之殇
携程的这次事件，不管原因是什么，都会成为IT运维历史上的一个标志性事件。相信之后所有的IT企业和技术人员，都会去认真的反思，总结经验教训。
但我相信，不同的人在不同的位置上，看到的东西可能是截然相反的，甚至可能会有不少企业的管理者受到误导，开始制定更严格的规章制度，严犯运维人员再犯事。
在此，我想表明一下我的态度：这是一个由运维引发的问题，但真正的根源其实不仅仅在运维，预防和治理更应该从整个企业的治理入手。
长久以来，在所有的企业中，运维部门的地位都是很边缘化的。企业的管理者会觉得运维部门是成本部门，只要能支撑业务就行。业务部门只负责提业务需求，开发部门只管做功能的开发，很多非功能性的问题无人重视，只能靠运维人员肩挑人扛到处救火，可以认为是运维部门靠自己的血肉之躯实现了业务部门的信息化。
在这样的场景下，不光企业的管理者不知道该如何评价运维的价值，甚至很多运维从业者都不知道自己除了到处救火外真正应该关注什么，当然也没有时间和精力去思考。
在上文的情况下，传统的运维人员实际上是所谓的“黑盒运维”，不断的去做重复性的操作，时间长了之后，只知道自己管理的服务器能正常对外服务，但是却不知道里面应用的依赖关系，哪些配置是有效配置、哪些是无效配置，只敢加配置，不敢删配置，欠的技术债越来越多。
在这样的情况下，遇到这次携程的极端案列，需要完整的重建系统时候，就很容易一筹莫展了。
对于这样的故障，我认为真正有效的根源解决做法是从黑盒运维走向白盒运维。
和Puppet这样的运维工具理念一致，运维的核心和难点其实是配置管理，运维人员只有真正的清楚所管理的系统的功能和配置，才能从根源上解决到处救火疲于奔命的情况，也才能真正的杜绝今天携程这样的事件重现，从根本上解决运维的问题。
从黑盒运维走向白盒运维，再进一步实现DevOps（开发运维衔接）和软件定义数据中心，就是所谓的运维2.0了。很显然，这个单靠运维部门自身是做不到的，需要每一个企业的管理者、业务部门、开发部门去思考。
因此，我希望今天这个事件，不要简单的让运维来背黑锅，而是让大家真正的从中得到教训和启示。
|
