你见过哪些离大谱的运维事故?

知乎 2025-03-16 10:20:00
最近,小编在知乎上看到这样一个问题:
 
 
 

你见过哪些离谱的运维事故?

 
 

 

秉持着和平交流的学习态度,小编精选了几位高赞知乎网友的精彩回答,分享给大家学习交流(勿上升、勿引战):

 
 
 

1号知乎网友:机制小风风

 
 

 

刚开始接触 k8s 的时候,那时候入职的一家小公司,之前负责 k8s 离职了,当时,我连 k8s 是啥都不知道。

 

这家公司比较激进,所有东西都上 k8s,包括数据库,gitlab 等等,存储用的 nfs 走的 pv&pvc。然后骚操作来了。

 

所有的持久化用的同一个 pv 和 pvc,然后通过子目录的方式区分不同的服务,用的时候还挺好用的。

 

某天,为了下线某个服务,准备把这个服务对应的 pv&pvc 删掉。执行了好久,感觉不对劲,然后就取消了。后来发现,虽然删除的是子目录的 pv&pvc,但是 k8s 会清空整个目录,然后公司的代码全没了。此前也没做过备份,幸好一个月前,因为迁移还是啥备份过一次,代码一下回滚到一个月以前了。

 

这是唯一的一次,造成线上数据丢失的故障。也够离谱的,离谱的用法,离谱的逻辑。

 

 
 

2号知乎网友:罗然

 
 

 

我把这个案例分享出来不是让各位“董师傅”教我怎么做事的。o 不 ok?

 

灭霸的响指!

 

你们见过随机杀进程的脚本吗?而且还贼难发现的那种。

 

起因是隔壁一个哥们写了一个 shell 脚本,但里面有一行代码是杀掉指定进程大概是 ps | grep | xargs kill 这个样子的。

 

本意是 kill 符合条件的进程。

 

这哥们写完还在他自己的开发容器里面测试了一下,嗯,没有问题,进程被杀掉了。

 

然后就发上线了。到线上机器执行脚本。

 

执行之前,ps | grep 了一下,确认了一下,那个待宰的进程还撒欢地跑着。

 

“看我不弄死你”哥们嘴角轻蔑一提,

 

熟练地默默敲下了

 

  •  
  •  
> chmod +x script> ./script

最后,哥们还用 ps| grep 确认了一下,那个进程大抵是凉了,透透的。

 

“哼!就这?”

 

哥们干完活就愉快的吃烧烤去了。

 

话说,这哥烧烤吃到正欢的时候,突然这哥电话响了,定睛一看 +2 老板打来的,也顾不上手上的油了,赶紧划拉手机。

 

“歪歪歪……唉,老板,是我……啊?没有呀……购物车全空了?也无法加购?哦…………那肯定跟我没关系呀,我没动购物车的 pod 呀,唉…………唉唉好好“

 

挂了电话之后,这哥继续跟我们愉快地吃烧烤,又是吃到正爽,突然这哥像是被雷给劈了,大腿一拍。

 

“哎呀,我c!!!”。

 

说完拔腿就往回跑。我们一脸懵逼,但感觉应该是粗了大事,我们也都顾不上吃了,赶紧也跟着这哥往回跑。

 

事后听复盘分享,简直笑尿。

 

因为,漏了一个 awk 把进程号那一列提取,而把符合条件的那一行的每一列都当做 pid 给 kill 了一下。好死不死,这个进程的执行参数里面就有--Memory 8088 --Cpu 24 --xxx 192391 等各种数字。又特么偏偏这么巧,有一个数字刚好跟当时某重要中间件容器有关,结果直接给 kill 了。但当时流量又特别大,就造成连锁反应了。

 

他自己的开发机上面总共就没跑几个进程,所以脚本大概率没有问题,但服务器上可跑了一大堆容器的,偏偏就中奖了。

 

 
 

3号知乎网友:陈永楚

 
 

 

之前公司搞基础平台服务,运维挺多的。

 

当时公司内部有台dell的服务器,上面有4个主机。什么原因不记得了,这4台主机都要格式化重新安装操作系统。

 

当时公司前一天刚刚入职了一位运维,这个事情其他的运维本来不让这位新来的运维干的,但是这位刚入职的可能觉得这个事情很简单,也想表现一下,非要他来干。

 

干之前跟这群运维反复交代,其中的第三台服务器上有我们的代码仓库,动手之前跟我打声招呼,我确认后再动手。主要是想再做一次备份,以防万一。

 

老运维答复说先搞其他的机器,这台机器最后操作,操作之前跟我确认。

 

我就去办公室备份去了。

 

过了会儿,发现这台服务器连接中断了,连不上。

 

赶紧跑到机房一看,这位刚入职的哥们正在关机3号主机准备格式化重装系统了。问了一下其他运维,其他运维说拦都拦不住,让他先搞其他的也不听。

 

再次跟这群运维说先搞其他的机器,这台最后搞,搞之前跟我确认。

 

回办公室一段时间后发现SSH再次中断,跑到机房一看,这位刚入职的运维已经在格式化3号主机了。

 

其实这次事故倒是没有引起多大的事故,数据都有备份。

 

但是这位刚入职的运维的操作让我实在无法理解:操作之前备份数据保证回滚正常不是一个运维的基本常识嘛,虽然这次备份没让他做(按理说他也应该自己备份一下,毕竟别人是靠不住的),但是几次三番让他确认完全当耳旁风。

 

留下他就是个定时炸弹,迟早要出事。让他们运维领导通知他走人了。

 

 

 
 

4号知乎网友:天上白玉京

 
 

 

某证券公司,有一段时间一到开市高峰期,就有很对服务超时,查看pod和node节点的资源使用率都不高,但是load负载稍微高点,理论上也不会引发超时现象,而且服务上线前也都进行过压测,没到峰值就出现超时确实很诡异。

 

因为当时node节点一般都是虚拟机,偶然想到是不是vmware的exsi宿主机出问题了,就找管虚拟化的同事问了一下,一查果然是到高峰期,exsi主机的cpu使用率都100%了。原来他们团队当时要维护exsi主机的bios版本,将虚拟机都迁移了一遍,导致分布的不均衡,有三台机器很闲,其他9台都很满,后来做了平衡之后就没事了。

 

 
 

5号知乎网友:张子浩

 
 

 

我说一个,整个公司用的office2007都是一个安装源装的。

 

有一天一个同事说开Excel时蓝屏了,我正要去看一下,然后整个公司同事都说自己文档都无法打开,打开就报错。

 

然后挨个给大家临时换wps。换到蓝屏那一台,我一看先重启吧,结果重启完,所有电脑都好了,又都正常了,至今没明白。

 

 
 

6号知乎网友:黑帽子阿姨

 
 

 

早些年,有一家电商公司在618大促期间发生了一起严重的数据库事故。

 

他们的一个资深DBA在促销高峰期需要给主数据库扩容。正常情况下这种操作应该在低峰期进行,而且还得先在测试环境验证。但是由于时间紧,主管压力大,就让他直接在生产环境操作。

 

结果他在执行扩容命令时,不小心把一个删除测试数据的脚本放到了生产环境。更离谱的是,他还带着root权限执行了这个脚本。一瞬间,整个主数据库的核心交易数据就被清空了。

 

后果是什么?整个网站瘫痪了将近4个小时,据说造成了几百万的直接损失(不知真假)。最惨的是,他们的备份策略也出了问题,最近的可用备份是3天前的,所以很多新订单数据都丢失了。

 

也不知道有没有备份过……

 

所以说,运维也不是所谓的打杂一职,如果你只是相信口舌上的看看屏幕、敲敲键盘摸摸鱼,那或许是你"运气好",可以摸鱼,但是别忘了,可替代性也是同理。

 

-

 

“你见过哪些离谱的运维事故?”欢迎在留言区交流,留下你的观点~

 

 

整理丨dbaplus社群
来源丨知乎:https://www.zhihu.com/question/653030041
*仅为提供参考和学习交流,不代表dbaplus社群立场!dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告