这个段子想起好久以前的一条新闻。
rm -rf/ 又引发了一个血案
Marco Marsala 是一家小型主机托管公司的老板，但是他最近遇到了一个天大的麻烦——由于脚本错误，他不慎删光了所有客户的数据。更糟糕的是，由于 Bash 脚本代码中包含了一行变量未定义的“rm -rf {foo}/{bar}”，连备份也连带着被干掉了——而在通常情况下，备份网络理应和正常的生产力基础设施隔离开的。
这一错误源自 Ansible 上糟糕的代码设计，这款 Linux 实用工具被用于在多台不同服务器上自动执行脚本。
开发者解释到，实际参数应该是“rm -rf {foo}/{bar}”，foo 和 bar 是脚本中动态传递的两个变量。鉴于 Marsala 运行着 1535 个集群，其本来是能够在数小时（至数日）内恢复的。但由于未能妥善实现生产环境和备份环境的隔离，备份档也全没了。
然而由于变量处理出错，通用语法未能成功在 bash 命令中插值，所以最终指令就变成了可怕的“rm -rf /”。
“rm -rf/”意味着擦除根路径“/”下挂载的所有内容而无需询问。
不得已之下，他只能上网发帖求救，然而没人能救得了他了。当然，也许最好的建议是给律师打个电话，那样或许还不至于赔得太惨。
扒了一下，惨案太多了。。。
知乎匿名用户
链接：https://www.zhihu.com/question/29438735/answer/101838852
某通信公司，HK某运营商项目，某中间件产品，实时系统，三期割接上线。
因为一期二期已经上线，现网系统已经承载C网200w用户。
连续两晚通宵，终于成功割接，系统运行正常。
一觉醒来，下午四点，业务高峰，登录系统检查状态，运行正常，但发现系统后台目录下有11个昨晚操作留下临时文件，一共都不到1M的样子。完美主义者+强迫症患者。没经客户允许，打算直接删除。好了，事情来了。
业务操作员，应用后台home目录下，rm -rf ./*XXXX* 不知道怎么敲成了rm -rf ./* XXXX* 。多了个空格。
rm 3秒没完成，第一反应，麻蛋，不对劲，貌似这次删除时间有点长。
随即系统立即报出rm: cannot remove directory `./mdsfiles': Device or resource busy，
X，TMD，这可是生产环境啊，完了，出事了，赶紧一顿 Ctrl+C，12个^C，rm操作取消。ls查看文件，不用细看就知道明显少了好多文件。
下图就是SecureCRT记录的当时的操作日志。(16:15:08的操作是Tab，不是回车，16:15:11的操作才是真正的rm操作)
其实之前身边已经有人因为rm文件出过事故，自己也曾多次脑补过这个场景，也因为好奇使用root用户在测试镜像下搞过rm -rf /。
但第一时间还是懵了。也许是HK的空调太低，并没有惊出一身汗，只是手有点抖。
赶紧登录Web前台监控系统状态，发现监控进程自己都已经挂掉了，业务进程状态无法查询。
不行，要Hold不住。
通知身边同事，和PM汇报上升问题，看看能不能让客户上游请求系统先暂时自己缓存请求，给我们半小时时间恢复之后再下发。后来据说当时PM正在和客户开会，和客户说了我们系统出了问题，客户脸都白了，本想联系他主管，但又觉得不够，直接打了电话给主管的主管，说赶紧下发紧急告警，启动应急预案。
同时我这边Web前台查询请求状态，发现还在处理业务请求。数据库查询请求数量，发现并无明显积压。感觉主进程应该暂时还在，我们应该还可以自己Hold一会。赶紧让同事和PM说让客户先不要操作，我们自己再压一会儿。PM和正在给领导打电话的客户谎称是我们自己看错了。客户又在电话里大喊告警解除。有种电影里发射核弹的感觉，很遗憾当时没在场。如果启动应急预案，估计可以去客户官网看公告了。
凭直觉直接脚本拉起监控进程，命令敲完一半，Tab联想不出来，才发现启动脚本都已经不存在了，Fxxx。因为生产环境为双机，本来可以切换到备机，但双机管理软件因为这次上线已经冻结，现在恢复管理未必成功，如果中间出现问题无法完全启动将会更加麻烦，而且切换过程中必定存在业务中断，现在是业务高峰，所以不到万不得已，绝对不能切！
全量下载备机环境，并和主机比对，批量上传缺失文件，更新权限777。脚本拉起监控进程，启动正常。重新登录web前台，已经可以查看系统状态，发现两个主进程的确还在。
初步Hold住，赶紧联系机关R&D，逐一反馈修复之后后台目录下文件信息，确认主要文件都在，并评估部分缺失文件及本次操作影响。
目前系统状态基本正常，CPU占用率较高，原因还需定位，预计后续可能会出现报错，但应该不至于影响业务。再次和PM汇报情况。
误删文件之后，系统依旧坚挺，这应该是这次不幸中的万幸，一直被我们抱怨不靠谱的新系统，这次终于靠谱了一把，也救了我一命。也幸好内部消化，否则饭碗肯定不保了。
现在监控系统状态中，感觉应该趁加班写个脚本，以后更安全的调用rm。
2016.07.20 更新：
因为当时是业务高峰，且并没有有效定位思路，所以虽然CPU已经飙到300+%，但依旧决定进一步监控看下。当天夜里CPU使用率居高不下，但一切正常。第二天凌晨两点，爬起来监控，发现Web前台监控进程又挂了。深深呼了一口气，冷静。VPN远程登录服务器，看了下日志，有磁盘空间不足的报错。df一下，果然磁盘空间不足。du一下发现，是系统日志目录过大，后台一晚上打了几百G的日志。
拉一个下来，同时删除其余日志文件。再次手动拉起监控进程。发现日志仍在迅速增长。
看了下拉下来的日志，发现全是x个文件请求监控线程的报错，请求路径不存在。登了服务器看了下，发现文件请求目录的确不存在。下午恢复的时候，只恢复了主路径，并未恢复子路径(子路径为系统启动时自动创建，备机环境并无子路径)。mkdir手动创建目录。日志不再迅速增长，tail一下可以看到正常请求日志。感觉CPU使用率居高不下的原因肯定也是因为这个，登录Web前台，发现果然已经降到80%左右。
夜深人静，一个人偷偷摸摸擦屁股的感觉真不好。
睡觉。
第二天早上起来，VPN监控，系统状态正常，请求处理正常。七点，背着笔记本去见异地的女友。中午登录系统检查状态的时候发现，进程一切正常，CPU使用率在30%左右，的确不高，但是这低得也有点夸张啊。紧接着查询了下请求状态。妹的，从早上八点50之后就再也没有新请求过来。这他妹的少说也丢了几十万的请求了。
完了，饭碗又不保了。
正打算联系客户，客户的WhatsApp就过来了。很奇怪的是，客户语焉不详，感觉似乎是早上很快就发现了，只是一直不确定是不是他们自己请求系统的问题，所以直到下午才找到我们，这帮孙子...现在要拉上我们一起联合定位，定位个鬼，赶紧力荐客户重启。反正现在环境文件已经完全恢复，只要重启，昨天下午删除操作的一切可能的隐患都可以规避掉。
结果是重启之后果然就好了。后续定位这次的工单丢失4个小时是因为客户自己请求系统的Bug导致的，和那次误删没关系。但是两件事碰巧先后发生，真的是不得不让人紧张。
突然想到了我“岳父”的一段话：有时候，“虚惊一场”这四个字是人世间最美好的成语，比起什么兴高采烈，五彩缤纷，一帆风顺都要美好百倍。你可懂什么叫失去。这些时间来，更觉如此。愿悲伤恐惧能够过去，事外之人更懂珍惜。
终：后来在不久之后的一次和客户申请的正式升级操作过程中已将系统全部重新部署，现在已经稳定运行。我也于2016年7月结束14个月的HK项目交付工作，外人看来的“功成身退”，只有我自己知道这段日子有多难熬。
太可怕了
/2 
