从携程宕机引发的思考.docx

墨菲定律：Anything that can go wrong will go wrong. ：凡事只要有可能出錯，那就一定會出錯。”根據“墨菲定律”：　　主要内容：一、任何事都没有表面看起来那么简单；二、所有的事都会比你预计的时间长；三、会出错的事总会出错；四、如果你担心某种情况发生，那么它就更有可能发生。一、正确认识墨菲定律认识之一：不能忽视小概率危险事件认识之二：墨菲定律是安全管理过程中的长鸣警钟对运维：墨菲定律决定了故障的不可避免性，积极地还是消极的？积极应对：必须客观的认识墨菲定律，在方案上进行考虑，针对所有可能的处理是成本极高的，必须决策，评估风险发挥警示职能，强化安全意识应急方案应急演练变被动管理为主动管理防患于未然自动化运维风险是随着认知和环境改变的，要及时调整对策比如巡检流程优化黑盒运维转向白盒运维对产品：可维护性、可监控性、可追踪性、可测量性对开发：DevOps深入解析和反思携程宕机事件作者?智锦?发布于 2015年5月28日?|?讨论分享到：微博微信FacebookTwitter有道云笔记邮件分享稍后阅读我的阅读清单携程网宕机事件还在持续，截止28号晚上8点，携程首页还是指向一个静态页面，所有动态网页都访问不了。关于事故根源，网上众说纷纭。作为互联网运维老兵，尝试分析原因，谈谈我的看法。宕机原因分析网上有各种说法，有说是数据库数据和备份数据被物理删除的。也有说是各个节点的业务代码被删除，现在重新在部署。也有说是误操作，导致业务不可用，还有说是黑客攻击甚至是内部员工恶意破坏的。先说一下最早传出来的“数据库物理删除”，其实这个提法就很不专业，应该是第一个传播者，试图强调问题之严重和恢复之困难，所以用了一个普通电脑用户比较熟悉的“物理删除”的概念。实际上，任何一个网站的数据库，都分为本地高可用备份、异地热备、磁带冷备三道防线，相应的数据库管理员、操作系统管理员、存储管理员三者的权限是分离的，磁带备份的数据甚至是保存在银行的地下金库中的。从理论上而言，很难有一个人能把所有的备份数据都删除，更不用说这个绘声绘色的物理删除了。第二个则是黑客攻击和内部员工破坏的说法，这个说法能满足一些围观者猎奇的心理，因此也传播的比较快。但理性分析，可能性也不大。黑客讲究的是潜伏和隐蔽，做这种事等于是在做自杀性攻击。而内部员工也不太可能，我还是相信携程的运维人员的操守和职业素养，在刑法的威慑下，除非像“法航飞行员撞山”那种极个别案列，正常情况下不太可能出现人为恶意的可能性。从现象上看，确实是携程的应用程序和数据库都被删除。我分析，最大的可能还是运维人员在正常的批量操作时出现了误操作。我猜测的版本是：携程网被“乌云”曝光了一个安全漏洞，漏洞涉及到了大部分应用服务器和数据库服务器；运维人员在使用pssh这样的批量操作执行修复漏洞的脚本时，无意中写错了删除命令的对象，发生了无差别的全局删除，所有的应用服务器和数据库服务器都受到了影响。这个段子在运维圈子中作为笑话流传了很多年，没想到居然真的有这样一天。为什么恢复的如此缓慢？从上午11点传出故障，到晚上8点，携程网站一直没能恢复。所以很多朋友很疑惑：“为什么网站恢复的如此缓慢？是不是数据库没有备份了？”这也是那个“数据库物理删除”的说法很流行的一个根源。实际上这个还是普通用户，把网站的备份和恢复理解成了类似我们的笔记本的系统备份和恢复的场景，认为只有有备份在，很快就能导入和恢复应用。实际上大型网站，远不是像把几台应用和数据库服务器那么简单。看似很久都没有变化的一个网站，后台是一个由SOA（面向服务）架构组成的庞大服务器集群，看似简单的一个页面背后由成百上千个应用子系统组成，每个子系统又包括若干台应用和数据库服务器，大家可以理解为每一个从首页跳转过去的二级域名都是一个独立的应用子系统。这上千的个应用子系统，平时真正经常发布和变更的，可能就是不到20%的核心子系统，而且发布时都是做加法，很少完全重新部署一个应用。在平时的运维过程中，对于常见的故障都会有应急预案。但像携程这次所有系统包括数据库都需要重新部署的极端情况，显然不可能在应急预案的范畴中。在仓促上阵应急的情况下，技术方案的评估和选择问题，不同技术岗位之间的管理协调的问题，不同应用系统之间的耦合和依赖关系，还有很多平时欠下的技术债都集中爆发了，更不用说很多不常用的子系统，可能上线之后就没人动过，一时半会都找不到能处理的人。更要命的是，网站的核心系统，可能会写死依赖了这个平时根本没人关注的应用，想绕开边缘应用只恢复核心业务都做不到。更别说在这样的高压之下，各种噪音和干扰很多，运维工程师的反应也没有平时灵敏。简单的说，就算所有代码和数据库的备份都存在，想要快速恢复业务，甚至比从0开始重新搭建一个携程更困难。携程的工程师今天肯定是一个不眠夜。乐观的