携程瘫痪事件反思:历史会记住的

2024-04-23 08:48

本文主要是介绍携程瘫痪事件反思:历史会记住的,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

携程网宕机事件持续了大半天,直到将近深夜了才恢复,历时长达11个小时,实在罕见。关于事故根源,网上也众说纷纭。作为互联网运维老兵,尝试分析原因,谈谈我的看法。

宕机原因分析

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

先说一下最早传出来的“数据库物理删除”,其实这个提法就很不专业,应该是第一个传播者,试图强调问题之严重和恢复之困难,所以用了一个普通电脑用户比较熟悉的“物理删除”的概念。

实际上,任何一个网站的数据库,都分为本地高可用备份、异地热备、磁带冷备三道防线,相应的数据库管理员、操作系统管理员、存储管理员三者的权限是分离的,磁带备份的数据甚至是保存在银行的地下金库中的。

从理论上而言,很难有一个人能把所有的备份数据都删除,更不用说这个绘声绘色的物理删除了。

第二个则是黑客攻击和内部员工破坏的说法,这个说法能满足一些围观者猎奇的心理,因此也传播的比较快,但理性分析,可能性也不大。

黑客讲究的是潜伏和隐蔽,做这种事等于是在做自杀性攻击,而内部员工也不太可能,我还是相信携程的运维人员的操守和职业素养。在刑法的威慑下,除非像“法航飞行员撞山”那种极个别案列,正常情况下不太可能出现人为恶意的可能性。

从现象上看,确实是携程的应用程序和数据库都被删除。我分析,最大的可能还是运维人员在正常的批量操作时出现了误操作。

我猜测的版本是:携程网被“乌云”曝光了一个安全漏洞,漏洞涉及到了大部分应用服务器和数据库服务器;运维人员在使用pssh这样的批量操作执行修复漏洞的脚本时,无意中写错了删除命令的对象,发生了无差别的全局删除,所有的应用服务器和数据库服务器都受到了影响。

这个段子在运维圈子中作为笑话流传了很多年,没想到居然真的有这样一天。

为什么恢复的如此缓慢?

从上午11点传出故障,到晚上8点,携程网站一直没能恢复。所以很多朋友很疑惑:“为什么网站恢复的如此缓慢?是不是数据库没有备份了?”这也是那个“数据库物理删除”的说法很流行的一个根源。

实际上这个还是普通用户,把网站的备份和恢复理解成了类似我们的笔记本的系统备份和恢复的场景,认为只有有备份在,很快就能导入和恢复应用。

实际上大型网站,远不是像把几台应用和数据库服务器那么简单。看似很久都没有变化的一个网站,后台是一个由SOA(面向服务)架构组成的庞大服务器集群。看似简单的一个页面背后由成百上千个应用子系统组成,每个子系统又包括若干台应用和数据库服务器,大家可以理解为每一个从首页跳转过去的二级域名都是一个独立的应用子系统。

这上千的个应用子系统,平时真正经常发布和变更的,可能就是不到20%的核心子系统,而且发布时都是做加法,很少完全重新部署一个应用。

在平时的运维过程中,对于常见的故障都会有应急预案,但像携程这次所有系统包括数据库都需要重新部署的极端情况,显然不可能在应急预案的范畴中。

在仓促上阵应急的情况下,技术方案的评估和选择问题,不同技术岗位之间的管理协调的问题,不同应用系统之间的耦合和依赖关系,还有很多平时欠下的技术债都集中爆发了,更不用说很多不常用的子系统,可能上线之后就没人动过,一时半会都找不到能处理的人。

更要命的是,网站的核心系统,可能会写死依赖了这个平时根本没人关注的应用,想绕开边缘应用只恢复核心业务都做不到。

更别说在这样的高压之下,各种噪音和干扰很多,运维工程师的反应也没有平时灵敏。

简单的说,就算所有代码和数据库的备份都存在,想要快速恢复业务,甚至比从0开始重新搭建一个携程更困难。即便基本恢复了,携程的工程师今天也肯定是一个不眠夜。

故障根源反思:黑盒运维之殇

携程的这次事件,不管原因是什么,都会成为IT运维历史上的一个标志性事件。相信之后所有的IT企业和技术人员,都会去认真的反思,总结经验教训。

但我相信,不同的人在不同的位置上,看到的东西可能是截然相反的,甚至可能会有不少企业的管理者受到误导,开始制定更严格的规章制度,严犯运维人员再犯事。

在此,我想表明一下我的态度:这是一个由运维引发的问题,但真正的根源其实不仅仅在运维,预防和治理更应该从整个企业的治理入手。

长久以来,在所有的企业中,运维部门的地位都是很边缘化的。企业的管理者会觉得运维部门是成本部门,只要能支撑业务就行。业务部门只负责提业务需求,开发部门只管做功能的开发,很多非功能性的问题无人重视,只能靠运维人员肩挑人扛到处救火,可以认为是运维部门靠自己的血肉之躯实现了业务部门的信息化。

在这样的场景下,不光企业的管理者不知道该如何评价运维的价值,甚至很多运维从业者都不知道自己除了到处救火外真正应该关注什么,当然也没有时间和精力去思考。

在上文的情况下,传统的运维人员实际上是所谓的“黑盒运维”,不断的去做重复性的操作,时间长了之后,只知道自己管理的服务器能正常对外服务,但是却不知道里面应用的依赖关系,哪些配置是有效配置、哪些是无效配置,只敢加配置,不敢删配置,欠的技术债越来越多。

在这样的情况下,遇到这次携程的极端案列,需要完整的重建系统时候,就很容易一筹莫展了。

对于这样的故障,我认为真正有效的根源解决做法是从黑盒运维走向白盒运维。

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

从黑盒运维走向白盒运维,再进一步实现DevOps(开发运维衔接)和软件定义数据中心,就是所谓的运维2.0了。很显然,这个单靠运维部门自身是做不到的,需要每一个企业的管理者、业务部门、开发部门去思考。

因此,我希望今天这个事件,不要简单的让运维来背黑锅,而是让大家真正的从中得到教训和启示。

这篇关于携程瘫痪事件反思:历史会记住的的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/928328

相关文章

禁止平板,iPad长按弹出默认菜单事件

通过监控按下抬起时间差来禁止弹出事件,把以下代码写在要禁止的页面的页面加载事件里面即可     var date;document.addEventListener('touchstart', event => {date = new Date().getTime();});document.addEventListener('touchend', event => {if (new

查看提交历史 —— Git 学习笔记 11

查看提交历史 查看提交历史 不带任何选项的git log-p选项--stat 选项--pretty=oneline选项--pretty=format选项git log常用选项列表参考资料 在提交了若干更新,又或者克隆了某个项目之后,你也许想回顾下提交历史。 完成这个任务最简单而又有效的 工具是 git log 命令。 接下来的例子会用一个用于演示的 simplegit

FreeRTOS内部机制学习03(事件组内部机制)

文章目录 事件组使用的场景事件组的核心以及Set事件API做的事情事件组的特殊之处事件组为什么不关闭中断xEventGroupSetBitsFromISR内部是怎么做的? 事件组使用的场景 学校组织秋游,组长在等待: 张三:我到了 李四:我到了 王五:我到了 组长说:好,大家都到齐了,出发! 秋游回来第二天就要提交一篇心得报告,组长在焦急等待:张三、李四、王五谁先写好就交谁的

【经验交流】修复系统事件查看器启动不能时出现的4201错误

方法1,取得『%SystemRoot%\LogFiles』文件夹和『%SystemRoot%\System32\wbem』文件夹的权限(包括这两个文件夹的所有子文件夹的权限),简单点说,就是使你当前的帐户拥有这两个文件夹以及它们的子文件夹的绝对控制权限。这是最简单的方法,不少老外说,这样一弄,倒是解决了问题。不过对我的系统,没用; 方法2,以不带网络的安全模式启动,运行命令行,输入“ne

从希腊神话到好莱坞大片,人工智能的七大历史时期值得铭记

本文选自historyextra,机器之心编译出品,参与成员:Angulia、小樱、柒柒、孟婷 你可能听过「技术奇点」,即本世纪某个阶段将出现超级智能,那时,技术将会以人类难以想象的速度飞速发展。同样,黑洞也是一个奇点,在其上任何物理定律都不适用;因此,技术奇点也是超越未来理解范围的一点。 然而,在我们到达那个奇点之前(假设我们能到达),还存在另一个极大的不连续问题,我将它称之

BT天堂网站挂马事件后续:“大灰狼”远控木马分析及幕后真凶调查

9月初安全团队披露bt天堂网站挂马事件,该网站被利用IE神洞CVE-2014-6332挂马,如果用户没有打补丁或开启安全软件防护,电脑会自动下载执行大灰狼远控木马程序。 鉴于bt天堂电影下载网站访问量巨大,此次挂马事件受害者甚众,安全团队专门针对该木马进行严密监控,并对其幕后真凶进行了深入调查。 一、“大灰狼”的伪装 以下是10月30日一天内大灰狼远控的木马样本截图,可以看到该木马变种数量不

可选择的反思指令微调

论文:https://arxiv.org/pdf/2402.10110代码:GitHub - tianyi-lab/Reflection_Tuning: [ACL'24] Selective Reflection-Tuning: Student-Selected Data Recycling for LLM Instruction-Tuning机构:马里兰大学, Adobe Research领

react笔记 8-19 事件对象、获取dom元素、双向绑定

1、事件对象event 通过事件的event对象获取它的dom元素 run=(event)=>{event.target.style="background:yellowgreen" //event的父级为他本身event.target.getAttribute("aid") //这样便获取到了它的自定义属性aid}render() {return (<div><h2>{

react笔记 8-18 事件 方法 定义方法 获取/改变数据 传值

1、定义方法并绑定 class News extends React.Component {constructor(props) {super(props)this.state = {msg:'home组件'}}run(){alert("我是一个run") //方法写在类中}render() {return (<div><h2>{this.state.msg}</h2><button onCli

【Qt】定时器事件

定时器事件 在之前学习QTimer中实现了定时器的功能,而在QTimer背后是QTimerEvent定时器事件进行支撑的。在QObject中提供了一个timeEvent这个函数。 startTimer启动定时器killTimer关闭定时器 Qt 中在进⾏窗⼝程序的处理过程中,经常要周期性的执⾏某些操作,或者制作⼀些动画效果,使⽤定 时器就可以实现。所谓定时器就是在间隔⼀定时间后,去执⾏某⼀