线上事故分享，一次随机杀进程脚本引发的灭霸响指事件

美食

我想分享的这个案例，并不是希望各位董师傅来指点我如何做事。事情是否妥当？这就像灭霸打响指一样，随机性极强。事情的起因是这样的：隔壁有位同事写了一个 Shell 脚本，其中有一行代码是用来杀掉指定进程的，大致逻辑是通过 ps | grep | xargs kill 来实现的。他的初衷很简单，就是要干掉符合条件的目标进程。这位同事写完脚本后，在自己的开发环境中测试了一番。他运行了一下，发现目标进程确实被成功终止了，于是满意地点点头：嗯，没问题。随后，他就把脚本部署到了线上环境，并准备执行。在正式操作之前，他还谨慎地用 ps | grep 检查了一次，确认那个即将被处理的进程依然在欢快地运行着。他嘴角微微上扬，露出一丝自信的笑容，心里想着：看我不把你解决掉！接着，他熟练地敲下了最后的命令。执行完毕后，他再次用 ps | grep 核实了一下，目标进程果然已经消失得无影无踪。哼！就这？他自言自语了一句，然后心满意足地离开了机房，直奔烧烤摊享受美食。然而，故事并没有就此结束。就在他吃得正香的时候，手机突然响了起来。他一看屏幕，顿时脸色大变——原来是老板打来的。他顾不上擦掉手上的油渍，急忙接通电话：喂……啊，老板……什么？购物车全空了？无法加购？…………肯定跟我没关系呀，我没动过购物车相关的 Pod 啊……挂断电话后，他表面上还装作若无其事，继续和我们一起吃烧烤。可没过多久，他又突然愣住了，猛地拍了一下大腿：我操！！！说完，他立刻起身拔腿就往回跑。我们都被他的反应吓了一跳，意识到事情可能闹大了，于是也顾不上吃烤串，赶紧跟着他一起赶回去。后来，经过复盘才发现，问题出在一个细节上——脚本中漏掉了用 awk 提取进程号的那一列，结果直接把 grep 匹配到的整行内容中的每一列都当成了 PID 进行了杀死操作。偏偏这个进程的启动参数里包含了很多数字，比如 --Memory 8088 --Cpu 24 --xxx 192391 等等。更巧的是，其中一个数字正好与当时某个重要的中间件容器相关联，结果就被误杀了。而当时的流量非常大，这一失误引发了一系列连锁反应，导致系统出现了严重问题。在开发机上，由于运行的进程数量有限，这种隐患基本不会暴露出来。但在线上服务器上，情况就完全不同了，成百上千的容器同时运行，偏偏这次就中招了。听完复盘后，大家都忍不住笑出了声。虽然结果令人哭笑不得，但也提醒我们，在编写脚本时一定要更加严谨，避免类似的低级错误再次发生。