自己亲手引发运维事故是一种怎样的体验?

知乎 2024-01-09 10:25:47
最近,小编在知乎上看到这样一个问题:

 

自己亲手引发运维事故是一种什么样的体验?

 

 

秉持着看热闹不嫌事大认真的学习态度,小编精选了几位知乎网友的悲惨经历精彩回答,分享给大家吃瓜交流

 

 
 
 
1号知乎网友:罗健
 
 
 

 

 

这是我刚入行时引发的一起事故。

 

某互联网公司,有一个实时计费系统。

 

有一天我闲着没事干,到前台转悠。

 

前台小姑娘和我说,计费系统的时间不准,慢了刚好1年。

 

我问她之前是不是也这样,她说是的,一直都比实际慢1年。

 

我估计是系统上线的时候,实施工程师把年度时间改错了。但是用了这么长时间都没有问题,说明并不影响计费系统的正常运行。

 

但是前台小姑娘可是个大美女,既然她提出来了,我想,怎么也得露两手,谁叫我是“专业”的运维工程师呢?

 

我不经思考就直接对她说:“这简单,把linux系统时间改一下就可以了。”

 

然后,在计费系统里熟练地输入了更正时间的代码,毫不犹豫地按下了回车。

 

前台小姑娘一脸微笑,但是突然,她脸色凝重了起来,指着计费屏问我:“怎么在线用户都不见了?”

 

我一看,也觉得奇怪,正常在线用户都有1000多人呢?现在怎么只有几十人了?

 

我纳闷了好长一会,然后接到了客服部的电话,客服部急迫地问我:“是不是有什么故障?投诉台有上百个电话同时打进来,说是断网了!”

 

我顿时脸色大变,眼睛瞪得老大了,意识到出大事了!

 

监控室几乎也是同一时间,也打电话过来了,问我是不是出了什么故障了,他们监控到有大范围用户断线的异常告警。

 

我吓得腿都软了,站都站不稳,脑子一片空白,冷汗从额头处瞬间冒了出来。

 

正当我不知所措的时候,已经惊动到了直属领导涛哥,因为后台监控系统一旦有告警,告警短信就会第一时间自动发到相关维护人员的手机上。

 

涛哥打电话问我怎么回事,我实话实说了,是边哭边说的。

 

涛哥也是很有领导魅力,当下叫我先保住现场,稳住用户,他和运维组的工程师们马上赶过来。

 

10多分钟后,涛哥和运维组的工程师及DBA火速抵达了现场。

 

故障的原因是时间变快了1年导致的,所以在1年内过期的账号全部被踢下线了,而且无法重新登录。

 

当时DBA写了个语句查询之后发现,这些账号多达3千多个。

 

将时间再改回去也行不通,系统时间就会颠倒错乱,数据就全乱套了,后果更严重。

 

涛哥果断做了决定,直接修改数据库,将这3千多个账号的到期时间,全部改到年底。

 

DBA赶紧写了相关语句,同时对相关的数据表进行了备份。

 

语句准备执行的时候,DBA手都抖了,涉及到的账号不是一两个,而是几千个,影响范围太大了,万一有啥差错,就吃不了兜着走。

 

语句执行的时间很长,我们的心都在颤抖,好在顺利执行了。

 

之后,我们赶紧抽查一部分账号,发现这些账号已经能正常登录了,然后赶紧通知客服部的工作人员,叫用户重新登录,借口是网络波动导致的。

 

从故障发生到恢复,用了40多分钟。

 

但是,计费金额和财务账上的已经对不上号了,后续财务部算了一下,出现了40多万元的空缺。

 

正常情况下,故障时间超过10分钟就会被定性为事故,总部将这次事故定性为1级:严重事故,人为。

 

这件事结束后,我被调离了工作岗位,公司对我进行了长达3个月的重新考核,职称从T2降级到了T3,年终奖和绩效全没了... ...

 

我的直属领导涛哥,因管理不善,被记大过处分... ...

 

 
 
2号知乎网友:知乎用户
 
 

 

曾经给公司的一个客户维护数据库,要删除一个掉测试用户,输入完 delete from users,顺手快捷键执行了……

 

最坑爹的是数据库是游戏组的老哥搭建的,用的phpstudy搞的,没有开启binlog,数据库的几十万用户,客户花了几百万推广费。那一瞬间,就感觉背后汗水流下来了。

 

--

 

结果因为有外键,没删掉!!

 

真是吓死了……

 

 
 
3号知乎网友:法外狂徒张三
 
 

 

2021年9月29号,我接到研发的请求,要给他们部门专用的服务器安装一个软件。

 

我立马用root apt install安装好了,但是我安装过程中看的有一些不认识的包怎么装上去了,装完后发现好像也没有哪里不对劲,系统能正常运行,遂交付给研发。

 

过了一会研发找到我说不对,怎么有些安装包没有了,然后我又继续安装不见的包,然后修修补补,终于把他们缺的东西补齐。

 

然后再试,还是不行……

 

继续检查,研发说glibc版本不对!得赶紧解决,这个是和客户环境一致的,我们国庆的时候release!

 

然后我就找办法降级glibc,找到晚上也没有办法,我领导也加入一起找解决方案。

 

我们把Google百度翻了个底朝天,也没看到有解决方案,一直到凌晨五点,两个人实在顶不住了,然后去睡觉。我睡的也不踏实,早上八点就起床了。

 

按照原计划,我在9月29号下班就开车回家,然后30号在家办公的,结果全被打乱了。

 

第二天继续上班后,我和领导商量要不给他们重装吧,领导去和他们商量回来,说有一些商业软件特别不好搞,不能重装,当初花了好长时间才把这套环境搭起来的!(搭建这套环境的前领导跳槽了)

 

然后我继续找解决方案!

 

找啊找,找啊找,我搭了各种环境做测试了,就是不能把glibc给降级。

 

然后毫无意外的,研发的release不能在我们的环境上搞了,还好他们还有外部环境能用,不然我不知道怎么办!

 

就这样胆战心惊的过了个国庆,国庆我也一直在查文档,当时还跟我妈说,我可能要被辞退了……

 

国庆回来后,我继续收拾这个烂摊子,然后研发捅到我大领导(vp)那里,为了这个事,专门开会几次,并制定了一系列针对他们部门的问题处理流程,以及当前问题该如何解决,然后得出结论,他们部门以后所有的安装软件需求,必须经过大领导审批,我们才可以动手,并且全力恢复这台服务器的环境,好吧,这个事我继续干!

 

当时9月份我们一个同事合同到期,因为表现原因,没有续签合同,只剩下我和领导两个人,压力特别大。

 

屋漏偏逢连夜雨,当时我们内网又被外部攻击,我领导全力处理那边的事,我一个人一边想办法解决该部门的烂摊子,一边处理其他部门提过来的case,忙得不可开交。

 

弄了一个多月后,我决定放弃,重新搭建一套环境给他们,遂向领导汇报并征得同意,用了两三天时间就把那套环境搞好了,并没有他们说得那么麻烦。

 

那段时间因为人员少,我领导动不动就是加班到八九点,我六点多七点这样下班(外企嘛),感觉特别对不起他,人少的情况下还给他添乱。

 

当时我还想着年终奖可能要变少了,结果还超出了我的预期!!!

 

当时我真的是胆战心惊,干运维这么久,第一次搞出这么大的事,差点影响到他们的release。后面我领导说到:人总是会出错的,出错不怕,就怕重复出错。跟了这样的领导真好!

 

去年我拿到字节的offer,和他提出离职,他特别震惊,说到:我们去年这么难都挺过来了,现在舒服了,为什么要走呢?是有什么不满意吗?然后我和他说了我的诉求,他很积极的和vp沟通,后面在他们的努力下,我又留了下来!

 

"自己亲手引发运维事故是一种什么样的体验?"欢迎在留言区交流(留下你的事故故事)~

 

 

整理丨dbaplus社群
来源丨网址:https://www.zhihu.com/question/21793412
*仅为提供参考和学习交流,不代表dbaplus社群立场!本文为dbaplus社群整理校对,如需转载请标明出处。dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告