說起磁盤報警，相信大家都是一副不屑的眼神，這種事情，還需要專門寫一篇文章？哥們你是閒的慌吧。大家不屑的原因是：磁盤報警沒什麼了不起，只要服務進入穩定狀態，各種磁盤報警都經歷一次，查漏補缺，以後磁盤報警就很少了，偶爾半夜來幾條，也無傷大雅，搞運維嘛，還能沒報警呀。那麼這種思路違反了一個原則：同樣的錯誤不能犯兩次！並且處理問題太過被動，讓問題挨個半夜找上門來，也太辛苦了。所以，我和團隊的同學提出一個問題，磁盤報警，能否通過一種機制，徹底消除呢，即使無法消除，是否也可以做到，一個季度最多一次磁盤報警？這個問題的背後，是我們做事情的價值觀：一次性的投入，持續徹底的解決某一類問題，我們願意爲這種工作做足夠多的投入。
具體到磁盤報警上，一個季度最多一次磁盤報警，不論什麼原因！那麼我們就要分析，有哪些可能會導致磁盤報警呢？我先簡單列舉一些，後續慢慢完善補充
- 服務相關的
- log：業務日誌將磁盤打滿
- data：業務數據將磁盤打滿
- bin：進程coredump文件將磁盤打滿
- conf：業務配置文件的歷史版本將磁盤打滿
- 運維繫統相關的
- 部署系統：在磁盤上做歷史部署包的備份
- 傳輸系統：在磁盤上做傳輸時的冗餘副本
- 備份系統：在磁盤上做打包
- 基礎架構相關的
- 各類agent：類似於服務相關的，bin/conf/data/log都可能導致問題
- 操作系統相關的
- /var/log/下的系統日誌
- /tmp下的臨時文件
- 刪除的文件還被引用導致空間未釋放
- 人員操作相關的
- 拷貝日誌到臨時目錄處理完畢後未刪除
可能還會有其他的一些原因導致的磁盤異常，需要不斷的更新完善，但是當大家把磁盤打滿的原因從服務日誌擴展到多個方面且逐漸形成磁盤清理標準化策略，並通過Puppet工具推送到全部機器上的時候，磁盤報警數量就可以得到有效的控制，這個時候，相信，沒有人會說，磁盤清理這種事情不值一提。
其實，走到這裏，問題還遠遠沒有結束，具備BAT自動化運維能力的公司畢竟少數，很多公司事實上還處於小米加步槍的階段，那麼即使有了一個足夠好的磁盤清理插件，距離沒有磁盤報警，還有很多的路要走，比如下面的問題：
- 如何確保磁盤清理腳本能夠100%覆蓋所有機器而不會有任何遺漏
- 如果確保磁盤清理腳本的更新版本能夠100%覆蓋所有機器而不會有任何遺漏
- 如果確保新擴容的機器能夠立即部署了磁盤清理腳本
- 磁盤清理腳本在單機上以何種方式定期運行，誰來保證這種定期運行機制的有效性
- 如何確保磁盤腳本不會做壞事，比方說將線上需要的東西給刪除掉了
- 如何確保磁盤清理腳本在清理文件的時候不會產生瞬時的大IO導致業務受損
- 如果例行的機制確實沒有攔截到報警，報警發生後是否可以通過自動化的方式進行處理
- 如何避免磁盤清理腳本因IO問題而卡死導致機器上出現無數個類似的進程
- 腳本依賴的命令在刪除文件場景下有沒有最佳實踐避免踩坑的行爲（資源問題爲主）
爲了解決上面的問題，可能需要建立puppet來進行機器狀態的維持，對監控系統新增異常自動回調的能力，需要統一的機器管理系統，等等之類的基礎架構建設和完善工作。因此，再次回顧我們的目標：一個季度至多一次磁盤報警，想要達成這個目標，可能遠飛我們想象的那麼簡單。相信，在基礎架構的逐步完善，人員意識的逐步提升，Aiops的不斷介入，今後的運維工作會越來越好！