過年期間新聞不少。除了動物園老虎吃人這樣荒唐的事情之外，it圈里也出現了gitlab.com刪庫這樣的重大運維安全事故。
事故的起因是gitlab的運維在處理線上故障的過程中，可能是有點疲憊了，本想刪掉一個從庫，重新從主庫復制一遍，結果眼睛一花在主庫上敲了“rm -rf / ”。雖然兩秒鐘后他就意識到不對了，但是悔之晚矣。
刪庫這樣的事故其實很常見，我當年也干過這樣的蠢事。俗話說得好，常在河邊走，哪能不濕鞋。只要是靠人來做手動的操作，那么遲早會出現問題的，畢竟人總有犯錯誤的時候。就像小時候考試，我每次都檢查好幾遍，但總是很難拿到100分。
那么怎么解決這樣的問題呢？有幾種思路。一種是加強管理，從流程上杜絕犯錯誤的可能性。譬如在線上執(zhí)行任何操作的時候，都必須由兩個人來完成，一個人敲命令，另一個在邊上看著負責檢查。這樣犯錯誤的可能性就大大降低了。但這樣做不好的地方是成本增加了，原來一個人能干的活現在得幾個人才能完成。本來IT強調的是自動化，靠堆人肉來干活有點開倒車的意思。并且是人就會犯錯誤，幾個人一起犯錯誤的情況也很常見，特別是大家互相比較信任的時候。
另一種思路就是備份。依靠備份的恢復來解決之前犯錯誤的問題。這聽著是挺靠譜，但問題在于備份的實時性如何保證。比較好的辦法是每天做全量備份，當天的修改用日志的方式做增量備份。這樣想恢復到哪個時間點都問題不大，只是還要解決恢復速度的問題。
我覺得最好的思路還是從根本上減少犯錯誤的可能性，那就是減少人的操作，盡量用機器自動化的方式去解決問題。這就是基礎設施即代碼，也就是把原來手工的操作都通過腳本來進行，以代碼的形式維護起來。把對生產環(huán)境的任何操作，都看作一次發(fā)布的過程。這樣從代碼上就知道你做的是什么操作。相反，如果依靠在線上敲命令來做運維的話，沒人知道你下一步會敲出什么荒唐的命令來，比如rm -rf / 。
基礎設施即代碼聽起來不錯，但也需要團隊投入很大的精力在這上面，得先把這樣的基礎設施建立起來。有一些工具可以幫助團隊實現這一點，比如chef，puppet這樣的自動化配置管理工具。
我自己也很缺乏這方面的經驗，有機會逐步改進吧。
