怎样的内部失误使携程久久不能恢复?

简介:

支付宝才因为光纤事件一度导致应用无法使用,第二天,5月28日携程又遭遇攻击,连续两天,大型互联网公司出现不同的系统事故,“互联网+”浪潮下的安全问题再次受到行业内外拷问。

根据携程官方的最新回应:经技术排查,确认此次事件是由于员工错误操作,删除了生产服务器上的执行代码导致,携程也再次保证,数据和数据库并未受到此次事件的影响,用户订单数据也完整无损,请用户放心并继续使用携程网站及App,并表示其在系统上做了改进,规范并杜绝技术人员错误删除生产服务器上代码的操作。

怎样的内部失误使携程久久不能恢复?

携程在微博上的回应内容

到底是个怎么样的内部失误呢?

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

简单的说,就算所有代码和数据库的备份都存在,想要快速恢复业务,甚至比从0开始重新搭建一个携程更困难。

多备份联合创始人胡茂华向发表文章表示:“我记得当初在1号店负责运维时,因为1号店被沃尔玛收购,作为上市企业的关联交易公司,当时沃尔玛派KPMG来做详细的审计,核心岗位和管理层都被做了访谈,并出具了详细的操作流程,我亲自参与这个过程,审计是做了,但我们作为执行人心中是非常没有底气的。在我呆过的几个大的互联网公司如腾讯、盛大和1号店,都有做数据管理流程和备份恢复服务,但是因为这些安全业务比较边缘,在整个公司关注程度很低,并没有落到实处。”

他还说到,有理由相信,所有的公司都有做数据管理和备份,不论是小微企业老板自己手动用U盘或者硬盘拷贝、还是大的互联网公司有专门的运维人员专项负责、传统的中大型企业用专业的软硬件工具,关键是99%的公司都没有做数据管理流程、备份和恢复的演练,恢复的数据到底可不可用,如何快速的恢复等操作演练。

为什么恢复时间那么长?

对于为何12小时后才恢复正常,携程解释称:类似携程这样的大型网站承载着繁多业务,其后台是一个由SOA(面向服务)架构组成的庞大服务器集群,看似简单的一个页面背后由上千个应用子系统以及上千个WebService组成,而每个应用子系统和每个WebService之间都存在着相互调用的依赖关系。

发生事件后,携程的技术人员除了需要恢复生产服务器上的执行代码以外,还需要做的是恢复并确保每个应用子系统以及每个Web Service的功能正常,同时确保应用子系统与Web Service间的调用关系得以正常执行。

这种验证性的操作需要携程的工程师及运维人员通力合作,尽快恢复生产代码并通过反复地、持续性地调试以确保应用子系统与Web Service功能的正常运行。

携程再次保证,数据和数据库并未受到此次事件的影响,用户订单数据也完整无损,请用户放心并继续使用携程网站及App。

携程官方网站及APP已于28日23:29全面恢复正常。对用户造成的不便,携程再次深表歉意。”这也是继2014年春节期间携程被爆网站存在漏洞之后,连续两年遭遇IT系统上的漏洞问题。此次事故除了导致携程的股价应声大跌外,按照携程一季度财报公布的数据,携程宕机的损失为平均每小时106.48万美元。对此这次事故的损失,大家算算吧!

虽然携程连续回应称此次事故是由于员工操作失误导致,也得到了很多人的认同。但在事件发生时,携程却说由于不明攻击所致,这样的前后说法相差甚远。

怎样的内部失误使携程久久不能恢复?

消失的微博,这是28日12:50携程的回应,如今却已删除

这让起先不明真相的笔者不得不惊呼,我们不仅要问,携程你到底有没有谱!




原文出处:科技行者
转载请与作者联系,同时请务必标明文章原始出处和原文链接及本声明。
目录
相关文章
|
机器人 vr&ar
案例19-生产事故临时解决和最终解决方案
生产事故临时解决和最终解决方案
185 0
案例19-生产事故临时解决和最终解决方案
|
监控 JavaScript 安全
从几次事故引起的对项目质量保障的思考
从几次事故引起的对项目质量保障的思考
|
NoSQL JavaScript 前端开发
P0级事故,项目组慌的一批! 上
P0级事故,项目组慌的一批! 上
|
消息中间件 NoSQL JavaScript
P0级事故,项目组慌的一批! 下
P0级事故,项目组慌的一批! 下
|
运维 监控 数据库
面对平台间业务的迁移,你该做些什么?
面对平台间业务的迁移,你该做些什么?
278 0
面对平台间业务的迁移,你该做些什么?
|
数据采集 移动开发 监控
两把利器,轻松做好十一期间服务器监控保障
由于服务器需要7×24 小时运行,十一期间,为了切实做好服务器的重点保障,电源监控,必不可少。基于成本的考虑,我们决定自己做。如何多快好省,实现一个这样的平台呢?思路是通过服务器自带的远程管理模块读取redfish接口中电源功耗信息,然后采集到时间序列数据库,再通过grafana基于时间和ip做条件筛选做展示。这里就要用到两把开源利器Grafana和Influxdb。
两把利器,轻松做好十一期间服务器监控保障
如何构建一个拖垮整个公司的备份系统
在如今“数据即资产”的时代,有备才能无患。备份就像备胎,虽然大多人都知道备胎很重要,却很少有人检查。不发生点什么,你永远不知道TA对你有多重要。
6053 0
如何构建一个拖垮整个公司的备份系统
|
人工智能 数据可视化 数据挖掘
后疫情时代,用数据支持业务恢复创造新的可能性
2020年可以说每一天都在见证历史,新冠疫情的突然造访就如同“黑天鹅”不期而至,而企业现在还不开始数字化转型就如同“灰犀牛”存在潜在风险,当下在黑天鹅和灰犀牛的夹击下,经济和市场都产生了巨大的影响。
|
弹性计算 容灾 大数据
黑科技揭秘:阿里云如何做到从业务宕机到恢复业务运行只用一分半钟时间
企业关键业务宕机会带来非常大的损失,而传统的自建容灾方案成本高昂运维复杂,因此高性能的云容灾服务正在成为企业业务持续性保障的优先选择。混合云容灾服务(HDR)-关键业务型的演示完整呈现了将本地服务器上运行的报账系统实时容灾复制到阿里云,并在出现宕机后在云上快速拉起恢复业务的全过程。
3376 0