携程网宕机事故深度剖析

标签: 携程网 宕机 事故 | 发表时间:2015-06-03 19:40 | 作者:sharong
出处:http://www.iteye.com
2015年5月28日上午11时许,携程旅行网官方网站突然陷入瘫痪,打开主页后点击时均显示“Service Unavailable”,经过12小时的紧急抢修后,携程网终于恢复,可正常访问。
虽然事情已经过去几天了,但通过网上的各种传言,到处都透露出携程网在网站建设中的种种不专业行为,有些传言甚至让人匪夷所思,典型的就是所有数据库数据都被物理删除,无法恢复这一条,容后表述。
下面列出一些携程网显然做的不足的方面,以资讨论。
1.运维工程师,开发工程师,测试人员等各角色的职责和权限必须定义清晰
互联网站建设的几个重要环节,基本是产品->开发->测试->运维这样一个流程。让我们根据这个流程看一下,究竟是哪个环节出问题了呢?毫无疑问是运维这部分。
出问题的可能性大致推测如下:
运维工程师不小心删除了根目录下的全部文件;
运维人员水平所限,没有搭建灾备系统;
公司管理混乱,不该具备操作权限的非运维人员也有权进入生产环境的主服务器进行操作;
外部黑客攻击网站。

根据上面的推断,基本可以发现,运维人员的水平高低,往往是决定网站能否正常运行的关键环节。而携程网显然在运维这一环节关键时刻掉链子,才造成了网站大面积宕机的惨剧。
无法想象在今天的互联网时代,一个大中型网站竟然没有灾备系统或者集群,网络拓扑结构等的配置。携程网的运维部门,必然不合格。
时至今日,在网站建设中的各个角色的定义已经相当清晰,一般来说,只有运维部门有权在生产服务器上进行发布新版等操作,如果这一点尚存疑问,携程网确实需要好好补课才行。

2.灾备系统的重要性
根据官方统计,携程网在12个小时内,网站所有功能都陷于瘫痪。说明此网站完全没有进行灾难备份。在当今一些要求比较高的应用,例如银行,金融业等,必须要求7*24小时不宕机,在这种情况下,往往至少会在生产环境发布两套系统,一旦主服务器出现异常,马上可以切换到备份服务器。另外,使用nginx的权重分配等方法也可以完成类似操作。携程网的系统架构师和运维人员显然不具备这种灾难恢复意识。

网上甚至一度盛传所有数据库数据都被物理删除,无法恢复。在实际应用中,大型网站的数据库几乎都是主从(master-slave)数据库,每隔半小时,1或2小时就会对数据库做一次备份,备份还分为冷备和热备。怎么还会出现这种问题,最多也就是丢失1至2小时的数据而已。携程网的说法实在是让人诧异不已。

3.java的安全性能相对较高,.net程序则一般运行在IIS的windows机器上,权限控制太弱
事发后,大家才获知携程网至今仍然使用的是.net进行的网站建设,那么它的全部代码理应跑在windows系统的IIS web服务器下。众所周知windows系统几乎对系统安全性不做限制,那么随便一个内部人员几乎都可以上去增删代码;而linux系统对权限的控制就严格的多。
另外,还有一说,是遭到了外部攻击造成系统瘫痪。目测时至今日,大的正规网站基本都使用了Java,php等编程语言来进行网站建设(.net基本已经被大家遗弃,不是没有理由的)。Java系统天生安全性能就较高,可以较好的抵御外部入侵。

4.系统架构的重要性
携程网瘫痪了12个小时,只有主页可以浏览,其他所有功能都陷于瘫痪。官方解释是遭到了外部攻击造成系统瘫痪。这从另一个方面说明,该网站的各个功能模块互相依赖,耦合性太强。一旦受到外部攻击,整个系统的自洽性极低,崩溃会迅速从点蔓延到面,造成整个网站瘫痪。
对大中型网站建设来说,用户系统,购物系统,订单系统,客服系统。。。甚至缓存系统,数据库集群等等,基本都是独立出来为整站提供服务。例如,客服系统受到攻击,其他系统基本不受影响。而携程网则非常诡异的全站瘫痪,实在是闻所未闻。
一种传言是有人将主服务器根目录下的所有文件都删除了。但是依我的经验,对一个大中型网站来说,通常都使用网络拓扑加服务器集群(主备或者权重)的方式来发布,删除所有服务器上的运行程序,几乎是不可能发生的事情。
从系统架构的角度来看,这是一个极其不合格的系统。一个好的系统,应该尽量降低模块间的耦合性,分散到多个服务器上发布。这样不但可以提高开发测试等工作效率,方便模块发布,也有利于系统拆分及升级扩容,显然携程网的架构师离这一要求还相去甚远。

5.公司企业文化的重要性
最后来阐述一下,公司处于稳定发展期后,企业文化对公司持续良好发展的重要影响。
根据不少使用过携程网的用户反应,此网站经常搞一些小动作,注册用户在退票时各种推诿,不能爽快的退还应付款项。感觉上是公司为了营收,经常对用户进行无理由克扣款项,肆意践踏网站自己制定的客户须知等内容,毫无企业诚信可言。

从这个现象可窥豹一斑,此公司的企业文化就是比较鸡贼,擅搞小动作。而有一种网上传闻则是,携程网的运维总监和运维部L员工的女友上床,招致该员工报复性的删除了主服务器上根目录下的全部数据,看看外界对携程网的认知和评价,马上就让人觉得这样的事情发生在携程网不足为奇了。
什么样的企业文化,培养出什么样的员工,纯粹是no zuo no die.

已有 2 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [携程网 宕机 事故] 推荐:

携程网宕机事故深度剖析

- - Linux - 操作系统 - ITeye博客
2015年5月28日上午11时许,携程旅行网官方网站突然陷入瘫痪,打开主页后点击时均显示“Service Unavailable”,经过12小时的紧急抢修后,携程网终于恢复,可正常访问. 虽然事情已经过去几天了,但通过网上的各种传言,到处都透露出携程网在网站建设中的种种不专业行为,有些传言甚至让人匪夷所思,典型的就是所有数据库数据都被物理删除,无法恢复这一条,容后表述.

微软云服务发生严重宕机事故

- lin - Solidot
由于发生了严重宕机事故,数百万微软用户整夜无法访问微软的多项在线服务. 受影响的服务包括Hotmail、Office 365和Skydrive. 微软官方博客没有透露事故原因,仅仅在最后声明他们完成了DNS配置变更广播. 微软并不是最近几天发生宕机事故的唯一一家云计算供应商,Google Docs在周三也遭遇短时间无法访问.

【另一面】携程网暴露的不止是安全漏洞

- - 网易新闻·有态度专栏
【另一面】携程网暴露的不止是安全漏洞. 60 秒读懂专题:携程网暴露的不只是安全漏洞,还有谎言、不遵循行业数据安全标准、不实在的承诺、违背银联的规定. 但尽管如此,携程网在中国无法被实质惩处. 而相似案例中的索尼公司被英国官方罚款. 导语:3月22日晚,漏洞报告平台“乌云网”在其官网上公布了一条网络安全漏洞信息,指出携程网安全支付日志可遍历下载,能导致大量用户银行卡信息泄露,包含持卡人姓名、身份证、银行卡号、卡CVV码、卡6位Bin码.

人情“事故”

- SiL - 左岸读书_blog
这是cemoon的一篇随笔,喜欢他的这种真性情. 某朋友问起一件在他看来很秘密的事情,尽力帮他打听后告之他的一天,突然接到他愤怒的电话:你干嘛说出我的秘密. 很可笑,帮忙完后都忘了这事的自己,居然被对方认为自己在意他到了需要去透露给别人的地步. 我才没在意他,我只不过无视他那些小事罢了. 然而既然未与他有什么交流、他也以上面事实证实自己对我实在没什么了解,却给我扣了个“不自知不成熟”的帽子.

关于Amazon云宕机的网贴收集

- Ryan - 酷壳 - CoolShell.cn
最近,互联网上最大的事可能是Amazon的AWS宕机了,而且好几天都没有完全恢复. 整个Internet都在讨论这个事,Internet很不高兴,后果可能很严重. 可能是因为这个事件对中国没有影响,所以中文这边相关的文章不多,大家可以参考一下和讯网的这篇《伤不起. 亚马逊史前最大宕机事件的启示》. 国外有人把所有和这个事件相关的贴子都收集了起来,都是一些相当不错的贴子和文章,尤其是一些经验教训的贴子,很受教,转给大家看看.

黑莓电邮和BBM服务出现大规模宕机

- xing - cnBeta.COM
据国外媒体报道,当地时间周五,黑莓的电子邮件服务和BBM即时通讯服务出现大规模宕机,引发用户抱怨连连,随后黑莓制造商RIM在Twitter承认了这一点. RIM通过Twitter黑莓帮助账号称,一些加拿大和拉美用户报告BBM服务出现问题,支持团队正在调查,RIM对因此带来的不便表示歉意. 无线运营商Rogers和Bell也通过Twitter承认,接到BBM存在问题的报告,但没有进一步细节需要透露.

Twitter宕机:两套数据系统同时出现故障

- - 博客园_新闻
但只有当那些神秘的数据中心停止工作时,我们才能发觉和这个世界的联系其实是在这些 0 和 1 之上. 位于美国加州中部的萨克拉门托(Sacramento)有三个身份:1850年代的淘金人口集散地、如今的加州州府和 Twitter 的数据中心. 7月 26 日上午 8 点 20 分,这个数据中心停止了工作.

电商网站的宕机案例分析

- - InfoQ cn
性能调优社区dynatrace在其 博客中分享了客户案例,电商网站在假日客流峰值期间数次崩溃,经过SQL优化和调整负载均衡算法解决了相关问题,值得读者借鉴. 按照博文的描述,该电子商务网站在圣诞节期间崩溃了七次,每次宕机的时间都超过5个小时. 这种情况让企业损失了大量的收入和名誉. 我们的一个客户就曾经遭遇到这种情况,我们在此分享下他们的经历.

2013-11-9 做的一次系统宕机诊断及总结

- - CSDN博客数据库推荐文章
        首先交代一下系统的基本情况,开发是J2EE架构,最流行的那种,部署架构是weblogic+oracle. 2013-11-11接到现场实施人员反馈在9日上午(周六)有宕机并发回了weblogic的server.log.         在 08时25分49秒和 09时28分31秒之间有四次导出,造成了最终的内存溢出.

Kubernetes 中优雅停机和零宕机部署

- - DockOne.io
【编者的话】创建、删除 Pod 是 Kubernetes 中最常见的任务之一. 本文介绍了 Pod 在响应创建、删除请求时发生的内部流程,还讨论了如何在 Pod 启动或关闭时防止断开连接,以及如何正常关闭长时间运行的任务. 在 Kubernetes 中,创建、删除 Pod 可以说是最常见的任务之一.