你见过哪些离谱的运维事故?
秉持着和平交流的学习态度,小编精选了几位高赞知乎网友的精彩回答,分享给大家学习交流(勿上升、勿引战):
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天前的,所以很多新订单数据都丢失了。
也不知道有没有备份过……
所以说,运维也不是所谓的打杂一职,如果你只是相信口舌上的看看屏幕、敲敲键盘摸摸鱼,那或许是你"运气好",可以摸鱼,但是别忘了,可替代性也是同理。
-
“你见过哪些离谱的运维事故?”欢迎在留言区交流,留下你的观点~
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721