最近和一些朋友做了一些線下的溝通，大家都是網際網路技術同行， 自然會談一下各自工作中遇到的一些問題。聊完後我有一個感受，就是大家在各自業務中實施高可用過程中，踩了一些坑，然後再反過來不斷優化自己的系統，但是實際上如果我們一開始就能在運維端打下基礎，就可以避免裡面的很多問題。所以今天來簡單談談這一塊我個人的一些實戰經驗。
簡單來說，就是做好三件事：
故障發現機制
系統恢復機制
線上故障覆盤機制
接下來，我們再細說這三件事如何來落地。
1. 故障發現機制
1. 報警的移動化，故障出現後的第一步，自然是報警，系統不會自我修復，需要工程師來處理，所以需要通知到處理人。在24x7的時間維度下，只有報警系統通過簡訊或者語音電話才能有效通知。如果你閒報警不帶勁，可以考慮換志玲JJ的語音。
2. 報警的實時化， 這一點不必多解釋，時間就是系統的生命，所以報警的延遲必須控制在1-3分鐘的延遲內，不能再多了。
3. 監控的視覺化，光靠報警簡訊，是很難第一時間定位問題的，所以這就需要做好監控的視覺化，無論是系統打點還是日誌蒐集，具體拿石投來說，我們日誌收集的ELK方式或者通過系統打點，走kafka + Storm全鏈路監控我們都做了，然後通過控制檯清楚的定位問題，所有業務的關鍵資料，我們也有通過grafana做實時的取樣。
2. 系統的恢復機制
其實恢復機制也沒有什麼神祕的地方，就是努力做好運維的四項關鍵任務：回滾、重啟、擴容、下機器。
回滾，每次釋出前，本次釋出的服務必須做好回滾的準備，PlanB要想好，絕不能等線上故障後，才開始考慮如何回滾。一鍵回滾是家中常規武器。
重啟，還是要落實到心跳或者服務監聽，通過系統指令碼做到服務自動重啟，除非無法正常重啟，再引入手工操作。
擴容/下機器，落實到映象的快速生成，有一套現成指令碼做到一鍵上線或者下線。現成的輪子已經很多，二次開發一下很快。
除此之外，平時需要做好主備切換、叢集遷移、異地容災等等的演練，“平時多流汗，戰時少流血”，一直都是真理。
3. 線上故障覆盤機制
即便是做到以上提到的第1點和第2點，還是無法保證系統不會出問題，所以我們需要有一套機制來分析線上故障，通過覆盤，分析從故障發生前到發生後的應急處理過程，然後系統思考故障未來的解決方案，再逐漸落地。同時，系統在任何時候都要考慮不可用的時候，如何提供降級方案。
為什麼覆盤很重要？因為平常的功能測試也好，效能測試也罷，其實都是無法100%難覆蓋到各種情況的，而線上的真實流量能如實地反映出系統當前的狀態，能真實地評估出系統目前的短板或者瓶頸在哪裡。
覆盤不只是運維或者開發參加，而是相關技術團隊（開發、測試、運維），拉上產品乃至運營人員，一起進行，從各個角度分析，出現線上故障很多時候都是多方面原因。珍惜每次線上故障覆盤，上一層樓看問題，下一層樓解決問題。
掃描二維碼或手動搜尋微信公眾號【架構棧】： ForestNotes
歡迎轉載，帶上以下二維碼即可