上版的兩周後，差點無法挽回的慘劇

對於非工程背景，只使用Windows作業系統的人來說，使用者的操作都被限制住了，一些重要的系統檔案如果不小心使用Ctrl D刪除還會跳出小視窗提醒需要管理員權限，允許權限後依然顯示無法刪除，或許不太能理解接下來要講的事情。

Linux作業系統有個叫 rm 的指令，它的功能是刪除指定的檔案或資料夾，只要權限足夠它什麼東西都刪得掉，包含 rm 它自己或者是作業系統本身。

大約十年前，曾經發生一件至今仍會被提及的笑話。當時有一款可針對Nvidia效能優化的程式，在安裝之後會使Linux作業系統發生重大錯誤無法正常運作，直到有人發現了原因：

「rm -rf /usr/lib/nvidia-current/xorg/xorg」和「rm -rf /usr /lib/nvidia-current/xorg/xorg」，在usr後的一空白之差，直接導致了「刪除usr資料夾下的特定目標」和「刪除usr資料夾以及lib資料夾底下的特定目標」的差別，它使許多人被迫重灌作業系統，成為了工程師界講古會提到的一個笑話，以及關於「rm -rf」的工程師人生成就。

看到這相信已經可以猜到後面的發展：那個成就我也達成了(掩面)。

上版之後的第七天，也就是隔周的星期六，時間是早上9點左右，正準備出門吃早餐的時候接到電話，說是服務發生異常，不管是讀還是寫資料都會失敗，要立刻處理。當下的感覺就像是正要站起來的時候被人從背後按住肩膀，說道：「坐下，要工作了。」

和同事經過兩小時的奮鬥，總算找到原因是資料庫寫入時產生的日誌檔案把電腦硬碟磁區塞爆了，使得資料庫停止運作而且無法啟動(七天產生800GB的日誌檔案是真的想不到阿......)

當下的臨時解法是把日誌刪掉清出空間，讓資料庫可以啟動(解決問題最麻煩的從來不是最後的處理方式，而是找到問題在哪的過程)，後續再研究怎麼設定保存日誌的數量上限，或者是設定定期刪除日誌的功能。

於是我終於可以出門吃早餐...才怪，在11點左右確認資料庫啟動之後急著收拾行李出門趕車，捷運上一手拿電腦一手打鍵盤在群組內回報發生原因和後續處理方式，以及臨時編寫接下來數小時監控硬碟和服務狀態的腳本，總算是沒有延誤跟朋友們的午餐聚會。

之後的星期一，我負責的工作就是寫這次事件的檢討報告，以及為了避免發生類似情況而確認各機器(總共約40台)的硬碟使用率，並清除不需要的資料。
事實上就算不考慮空間問題，不必要的檔案也應該清除讓環境維持乾淨才是正確的做法。

每台機器的功能不同，需要一台一台登入進去確認與刪除。在另一台資料庫運作的主機上，我發現一個開發期間嘗試備份資料庫留下的資料夾。使用「rm -rf /backup」就能完成任務，不過或許是因為下午剛睡醒精神還不太好，送出的太快指令就變成「rm -rf /」，然後它就完成了。

簡單來說，我一個手誤把電腦C槽和D槽完整的清空，連檔案總管都被刪掉了。

發生的當下一陣寒意從背後一路竄上頭頂，腦中不斷想著「該怎麼辦」
「該怎麼辦」「該怎麼辦」，幸好出事的資料庫是另一台資料庫的完全複製，不至於在機器修復前完全無法提供服務，當下臨時修改所有程式的設定，讓它們改連接另一台資料庫。

一邊處理著一邊跟PM反映問題並向客戶承認錯誤，拎著背包跑到客戶公司的機器管理部門安裝一台規格完全相同的機器再進行設定，完成後再跑回公司討論如何修復，期間就是不斷地道歉道歉再道歉，除此之外什麼東西都講不出來。

討論出結果後已經接近下班時間了，和同事嘗試在測試環境模擬一次重新設定資料庫同步的做法，確認做法可行後就各自下班，晚上十點再連線處理正式環境的問題，總算是順利解決，非常感謝同事的幫忙。

「這是個寶貴的經驗，往好處想經歷過這種錯誤之後你絕對不會犯第二次。你該慶幸這是和錢沒關係的系統，如果是網銀專案，我們公司現在已經被告了。」這是事後檢討時負責技術支援的前輩所給的意見。

手上要寫的檢討報告變成兩份，第二份比起前一份更加嚴重，畢竟完全是人為疏失造成的，理論上任何主機都有可能發生。在文件定出了未來刪除資料的流程要求：
1. 刪除指令需要經過另一人確認後才能執行。
2. 固定流程，定期刪除的情況應該寫成腳本而非仰賴手動執行指令。

不過以上要求只對保持警戒的時候有用，萬一哪天執行者忘了可能造成的後果沒給他人確認，或者確認時漏看依然可能發生。基於「有沒有辦法從根本上讓特定資料夾和檔案無法刪除？」的想法，在這之後我去網路上找了機制防護的工具safe-rm，它可以透過在設定檔案裡面指定特定資料夾及檔案不可刪除。

關於這次事件的心得，首先是和同事維持和諧的關係很重要，你永遠不知道哪時會需要同事的幫助與包容；想想自己這次的經歷，未來同事犯錯也要多包容一點，事後檢討往如何避免再犯的方向引導。

另外，雖然前面前輩提到如果是網銀專案的話如何如何，但這是不可能的，因為網銀的資安要求，客戶絕對不會讓我們區區的程式開發商接觸到他們的正式環境。刪錯資料的事實也是基於我有管理員權限的前提才能成立，想避免出這種大包的根本之道，或許是拒絕參加這種案子或是不要簽這種約吧(當然這只是理想而已)。

最後，不論是何種系統，操作的時候都應該先確認自己的權限和每個操作的可能影響範圍，萬一出事能否復原、如何復原，以此界定需要謹慎處理的敏感事項。萬一忘記這些加上粗心大意，就準備體驗和我一樣的心驚肉跳的補救之旅吧。