不小心敲了 rm -rf / 后反应是怎样的？ 第1页

生产环境的话，这会破坏掉Kubernetes的pod，K8监控发现pod挂掉后会自动起一个新的，所以什么都不会发生。

至于在本地机子上跑rm -rf / tmp， 在没有root的情况下是执行不起来的。

所以段子只是段子而已。

这个问题，我一定要强答，今天中午的时候本来是想rm -rf /.xxx文件的，谁知道多打了个空格 rm -rf / .xxx了，然后就看见mac一直开始跑，删根目录下的所有东西。我写的代码呀，这些年收集的各种jar包资源，PDF文档，自己写的东西，全没了。用软件恢复也没恢复出来，假期写的一个项目眼看就要上线了，直接丢了。没有备份，以后写代码再也不敢不备份了。

某通信公司，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汇报情况，但PM已经气得不接我电话了...

误删文件之后，系统依旧坚挺，这应该是这次不幸中的万幸，一直被我们抱怨不靠谱的新系统，这次终于靠谱了一把，也救了我一命。也幸好内部消化，否则饭碗肯定不保了。

现在监控系统状态中，感觉应该趁加班写个脚本，以后更安全的调用rm。

2016.07.20 更新：
因为当时是业务高峰，且并没有有效定位思路，所以虽然CPU已经飙到300+%，但依旧决定进一步监控看下。当天夜里CPU使用率居高不下，但一切正常。第二天凌晨两点，爬起来监控，发现Web前台监控进程又挂了。深深呼了一口气，冷静。VPN远程登录服务器，看了下日志，有磁盘空间不足的报错。df一下，果然磁盘空间不足。du一下发现，是系统日志目录过大，后台一晚上打了几百G的日志。
拉一个下来，同时删除其余日志文件。再次手动拉起监控进程，系统监控页面恢复，日志仍在迅速增长。

看了下拉下来的日志，发现全是x个文件请求监控线程的报错，报请求路径不存在。登上服务器看了下，发现文件请求目录的确不存在。下午恢复的时候，只恢复了主路径，并未恢复子路径(因为子路径是系统启动时自动创建的，备机环境并无子路径)。mkdir手动创建目录。ll日志不再迅速增长，tail一下可以看到正常请求日志。感觉CPU使用率居高不下的原因肯定也是因为这个，登录Web前台，发现果然已经降到80%左右。

夜深人静，一个人偷偷摸摸擦屁股的感觉真不好。

睡觉。

第二天早上起来，VPN监控，系统状态正常，请求处理正常。七点，背着笔记本去见异地的女友。中午登录系统检查状态的时候发现，进程一切正常，CPU使用率在30%左右，的确不高，但是这低得也有点夸张啊。紧接着查询了下请求状态。妹的，从早上8点50之后就再也没有新请求过来。这他妹的少说也丢了几十万条的请求了。完了，饭碗又不保了。
正打算联系客户，客户的WhatsApp就过来了。很奇怪的是，客户语焉不详，感觉似乎是早上很快就发现了，只是一直不确定是不是他们自己请求系统(客户自己开发，和我们同时上线)的问题，所以直到下午才找到我们，这帮孙子...现在要拉上我们一起联合定位，定位个鬼，赶紧力荐客户重启。反正现在环境文件已经完全恢复，只要重启，昨天下午删除操作的一切可能的隐患都可以规避掉。

结果是重启之后果然就好了。后续定位这次的工单丢失4个小时是因为客户自己请求系统的Bug导致的，和那次误删没关系。但是两件事碰巧先后发生，真的是不得不让人紧张。
突然想到了我“岳父”的一段话：有时候，“虚惊一场”这四个字是人世间最美好的成语，比起什么兴高采烈，五彩缤纷，一帆风顺都要美好百倍。你可懂什么叫失去。这些时间来，更觉如此。愿悲伤恐惧能够过去，事外之人更懂珍惜。

终：后来在不久之后的一次和客户申请的正式升级操作过程中已将系统全部重新部署，现在已经稳定运行。我也于2016年7月结束14个月的HK项目交付工作，外人看来的“功成身退”，只有我自己知道这段日子有多难熬。

2017.02.03更新

不知道是不是因为这两天的gitlab rm -rf事故让大家对这个问题产生了兴趣，但两天500+的点赞量着实让我有点受宠若惊。
其实这次经历很大一部分原因在于我自己的手残，而且处理的方式也并无什么值得借鉴之处，所以这么高的点赞量让我更加惭愧。

于心有愧，所以我觉得应该和大家分享自己的一些思考...

1.工作的时候尽量保持清醒，进行高危操作的时候一定要保持清醒

2.建议每次执行rm操作前，核对一遍之后再敲回车(虽然这个动作可能已经成为很多程序员神经回路的一部分)。如有必要，可对rm命令设置alias，设置别名为mv到指定目录，crontab定时清理

3.做好用户权限控制，root不公开，使用低权限业务用户进行日常操作。需要高权限使用密码sudo (当时使用的就是业务用户，操作的是应用后台根目录，误删文件的数量，用途和影响至少都大致了解，风险可控)

4.操作窗口之外，不要乱动生产，我现在觉得最好登都不要登

rm -rf *

桃花过后，寸草不生。