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

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

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

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

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

我把这个案例分享出来不是让各位“董师傅”教我怎么做事的。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 了。但当时流量又特别大，就造成连锁反应了。

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

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

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

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

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

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

我就去办公室备份去了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-