如何防止誤刪根目錄
一、悲劇回顧
執行了一個清理日誌的腳本，大致的邏輯是：
...
cd ${log_path}
rm -rf *
...
看上去沒有任何問題，進入到日誌目錄，然後把日誌都刪除。但是，當目錄不存在時，悲劇就發生了。
二、大夥建議
【命令替換】
點贊數最多的朋友“39度的風”建議：
生產環境把rm -rf 命令替換爲mv，再寫個定時shell定期清理，以模擬“回收站”功能。
【收攏權限】
這個方案建議的人數最多：
帳號權限的分離，線上分配work帳號，只能夠刪除/home/work/logs/目錄，無法刪除根目錄。
【使用&&】
有部分朋友建議，使用&&將
cd ${log_path}
rm -rf *
合併成一個語句
cd ${log_path} && rm -rf *
當前半句執行失敗的時候，後半句不再執行。
【不使用cd】
對於
cd ${log_path}
rm -rf *
直接改爲
rm -rf ${log_path}
而不是cd到目錄下再執行。
這個方案個人感覺對於這個case可行，但不太通用，總有需要cd的場景吧。
【判斷目錄是否存在】
制定編碼規範，對目錄進行操作之前，要先判斷目錄是否存在。
確實，可是靠人的自覺來保證規範的執行，總感覺有些不太靠譜。
【單元測試】
和制定編碼規範類似，自測貌似比較難測出來，根據經驗：rd往往以自己編寫代碼的思路和邏輯編寫自測用例，來證明自己代碼的正確性。
【使用Python，避免使用shell】
這…
貌似不太通用，技術討論的第一大前提“不要有語言之爭”（技術討論的第二大前提“不要討論哪個編輯器好用”）。
三、其他悲劇
除了部分朋友反饋也刪除過根目錄，還有朋友提到：
（1）刪除過es數據
（2）刪除過生產數據庫
（3）刪除過home目錄
（4）誤格式化過硬盤
還有朋友提到了攜程之前的線上事故，我們都放下吃瓜看笑話的心態，別人還能夠在十幾個小時故障恢復，我們問自己一句，“假如我們線上20臺服務器全被幹掉了”，我們能在十幾個小時恢復麼？
後續和大家聊聊故障的快速恢復。
轉自：架構師之路