深入解析和反思携程宕机事件【转自https://www.infoq.cn/】

宕机时间 2015 年 5 月 28 日

携程网宕机事件还在持续,截止 28 号晚上 8 点,携程首页还是指向一个静态页面,所有动态网页都访问不了。关于事故根源,网上众说纷纭。作为互联网运维老兵,尝试分析原因,谈谈我的看法。

宕机原因分析
网上有各种说法,有说是数据库数据和备份数据被物理删除的。也有说是各个节点的业务代码被删除,现在重新在部署。也有说是误操作,导致业务不可用,还有说是黑客攻击甚至是内部员工恶意破坏的。

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

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

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

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

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

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

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

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

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

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

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

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

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

原文地址:https://www.cnblogs.com/linuxcx/p/11392805.html

时间: 2024-10-06 20:32:07

深入解析和反思携程宕机事件【转自https://www.infoq.cn/】的相关文章

从谷歌宕机事件认识互联网工作原理

原文转自:http://kb.cnblogs.com/page/166210/ 英文原文:Why Google Went Offline Today and a Bit about How the Internet Works 译者注:本文中提到 CloudFlare 是一家总部位于美国旧金山的内容分发网络(CDN)服务公司,由 Project Honey Pot 项目的三位前开发人员成立于 2009 年.2011 年 10 月被华尔街日报评为最具创新精神的网络科技公司. 今天,谷歌的服务经历了

怎样最小化云宕机事件的影响?

云计算并不是天生就是不可靠的,但是如同所有的IT形式一样,必须仔细挑选和管理云服务以实现特定的可靠性和可用性目标.这些步骤可以是合同形式的.是技术形式的或者甚至可能需要重新思考你的应用程序架构.如果没有经过慎重考虑,那么你从云计算中的收益可能要少于你的预期. SLA降低了使用云厂商数据中心而产生的风险 免受云宕机事件影响的第一步就是要评估云厂商数据中心的可靠性.大部分的云厂商都拥有着很少数量的数据中心,通常情况下只有一个,而这些数据中心易于产生与企业相同类型的故障.最广为人知的云计算故障往往是那

由Redis的hGetAll函数所引发的一次服务宕机事件

昨晚通宵生产压测,终于算是将生产服务宕机的原因定位到了,心累.这篇博客,算作一个复盘和记录吧... 先来看看Redis的缓存淘汰算法思维导图: 说明:当实际占用的内存超过Redis配置的maxmemory时,Redis就会根据用户选择淘汰策略清除被选中的key. 业务场景:用户通过微信入口来访问一个页面: 测试场景:通过多线程模拟定量的并发来访问页面服务: 涉及架构:springsession+Redis集群,容器部署: 问题描述:固定并发数压测10分钟,压测开始后半小时,Redis连接数激增,

监督和审计也是关键---携程528事件启发

5月28日下午2点左右,针对携程网站无法打开的事件在朋友圈被刷屏.刚刚开始是各种调侃,其中要求对运维人员好一点的呼声最高.传播最广,然后是携程老板悬赏100万解决问题,到了晚间央视财经网.腾讯网.新浪网.地方电台等主流媒体都发表了该事件的看法,其中也有很多的负面信息.总体来说这次的事件对携程的负面影响还是比较大,也引发了很多行业专家的思考.从5月29日起行业内的一些安全专家就发布了一些深度文章,其中有几个非常有指导意义. 1.阿里智锦<深入解析和反思携程宕机事件>则认为运维应该从黑盒运维走向白

从Appstore宕机看DNS解析的重要性

3月11日,就在苹果公司高高兴兴发布完AppleWatch后不久,其网站便惨遭全球性宕机,宕机故障的持续时间长达11小时,期间App Store.iTunes Store.iCloud等苹果互联网在线服务无法访问.如此大面积.长时间的网络服务中断,堪称近年来苹果在线服务最大的一次危机事件. 根据外媒网站报道,该次大规模宕机导致全球苹果用户无法访问和购买,对苹果造成至少2500万美元的直接损失:另外,此次重大事故也影响到了苹果的股价,事件后苹果股价大幅下跌了 1.82 %, 瞬间蒸发 130 多亿

携程阿波罗(Apollo)配置中心

携程阿波罗(Apollo) https://www.cnblogs.com/xiaxiaolu/p/10025597.html 一.瞎扯点什么 1.1 阿波罗 ? 阿波罗是希腊神话中的光明之神.文艺之神,同时也是罗马神话中的太阳神:他是光明之神,从不说谎,光明磊落,在其身上找不到黑暗,也被称作真理之神.他非常聪明,通晓世事,是预言之神. 后世各种各样的项目都喜欢以阿波罗命名,比如著名的美国登月计划:阿波罗计划: 既然携程以阿波罗(Apollo)命名项目,那我们我们接下来看看,携程阿波罗能给我们程

平时人家说的宕机是什么意思?

对于我这样一个刚踏入互联网圈的新人来说,在跟圈内同事交流的时候,发现他们最近经常在讨论“宕机”这个问题.那么这个宕机到底是什么意思呢? 宕机,多指一些网站.游戏.网络应用等服务器一种区别于正常运行的状态,也叫“Down机”.“当机”或“死机”.宕机状态不仅仅是指服务器“挂掉了”.“死机了”状态,也包括服务器假死.停用.关闭等一些原因而导致出现的不能够正常运行的状态. 说到这,大家可能明白了原来宕机是和服务器有关的一种状态,通常开发和运维人员对宕机这件事最为敏感.服务器一旦宕机会给服务商或者访客造

云宕机

云计算正日益融入我们的生活,可能有时候我们都意识不到自己正在使用云服务.正因为如此云计算宕机的影响才更严重.我想,最近一个月发生的这些宕机事件给我们的启示有三点: 1.云计算不是万灵丹,我们不过是租别人的计算机而已.因此自己数据中心可能出现的问题就算是转向了云计算也依然存在. 2.云计算极大简化了用户对资源的操作,但这有好也有坏.有不知多少人为了你能正常使用操碎了心,但出了问题的时候你作为用户完全什么也做不了. 3.企业有自己的替代方案很重要.可以是另一家云服务提供商,也可以是自己后备的数据中心

如何有效预防宕机?你需要掌握这4个方法

随着应用架构的不断演进,IT 系统也变得越来越复杂,这样就容易产生各类宕机事件.就在今年,国内外就出现了多起宕机事故. 2015年1月27日,网友发现无法登陆 Facebook,页面显示「对不起,出故障了,目前正在抢修,会尽快修复」. 2015年3月11日,包括 App Store.iTunes Store.Mac App Store 以及 iBooks Store 在内的一系列苹果在线商店服务,遭遇大面积服务中断.据统计事故恢复时间长达11个小时. 2015年5月,陌陌.网易.支付宝.携程网.