最近和一些朋友做了一些線下的溝通，大家都是網際網路技術同行， 自然會談一下各自工作中遇到的一些問題。聊完後我有乙個感受，就是大家在各自業務中實施高可用過程中，踩了一些坑，然後再反過來不斷優化自己的系統，但是實際上如果我們一開始就能在運維端打下基礎，就可以避免裡面的很多問題。所以今天來簡單談談這一塊我個人的一些實戰經驗。
簡單來說，就是做好三件事：
故障發現機制系統恢復機制
線上故障覆盤機制
接下來，我們再細說這三件事如何來落地。
1. 故障發現機制
1.報警的移動化，故障出現後的第一步，自然是報警，系統不會自我修復，需要工程師來處理，所以需要通知到處理人。在24x7的時間維度下，只有報警系統通過簡訊或者語音**才能有效通知。如果你閒報警不帶勁，可以考慮換志玲jj的語音。
2.報警的實時化，這一點不必多解釋，時間就是系統的生命，所以報警的延遲必須控制在1-3分鐘的延遲內，不能再多了。
3.監控的視覺化，光靠報警簡訊，是很難第一時間定位問題的，所以這就需要做好監控的視覺化，無論是系統打點還是日誌蒐集，具體拿石投來說，我們日誌收集的elk方式或者通過系統打點，走kafka + storm全鏈路監控我們都做了，然後通過控制台清楚的定位問題，所有業務的關鍵資料，我們也有通過grafana做實時的取樣。
2. 系統的恢復機制
其實恢復機制也沒有什麼神秘的地方，就是努力做好運維的四項關鍵任務：回滾、重啟、擴容、下機器。
回滾，每次發布前，本次發布的服務必須做好回滾的準備，planb要想好，絕不能等線上故障後，才開始考慮如何回滾。一鍵回滾是家中常規**。
重啟，還是要落實到心跳或者服務監聽，通過系統指令碼做到服務自動重啟，除非無法正常重啟，再引入手工操作。
擴容/下機器，落實到映象的快速生成，有一套現成指令碼做到一鍵上線或者下線。現成的輪子已經很多，二次開發一下很快。
除此之外，平時需要做好主備切換、集群遷移、異地容災等等的演練，「平時多流汗，戰時少流血」，一直都是真理。
3. 線上故障覆盤機制
即便是做到以上提到的第1點和第2點，還是無法保證系統不會出問題，所以我們需要有一套機制來分析線上故障，通過覆盤，分析從故障發生前到發生後的應急處理過程，然後系統思考故障未來的解決方案，再逐漸落地。同時，系統在任何時候都要考慮不可用的時候，如何提供降級方案。
為什麼覆盤很重要？因為平常的功能測試也好，效能測試也罷，其實都是無法100%難覆蓋到各種情況的，而線上的真實流量能如實地反映出系統當前的狀態，能真實地評估出系統目前的短板或者瓶頸在**。
覆盤不只是運維或者開發參加，而是相關技術團隊（開發、測試、運維），拉上產品乃至運營人員，一起進行，從各個角度分析，出現線上故障很多時候都是多方面原因。珍惜每次線上故障覆盤，上一層樓看問題，下一層樓解決問題。
運維平台的建設思考
自己最近也在琢磨如何搭建出乙個完善有效的運維平台，當然這個工作不是一朝一夕就能完成，前行的道路上肯定會有各種各樣的困難和牽絆，但是自己還是能夠學以致用，把一些重複性，繁瑣性的工作都能解放出來，能夠更加關注於更高的乙個層級來看待整個系統。我把搭建運維平台的過程分成了5個階段，當然純粹是個人之見，難免有...
Redis運維篇 Redis高可用之哨兵模式
redis主從複製模式下，一旦主節點發生故障，需要人工干預進行故障轉移，故障轉移的實時性與準確性都無法保障。redis2.6版本以上提供了redis sentinel 哨兵 來自動發現和轉移故障，實現高可用 啟動多個redis例項 redis搭建主從複製 包含乙個主結點，兩個從結點，三個sentin...
網路系統建設與運維 IT基礎架構運維服務認知
什麼是it基礎架構？網路定義 it基礎架構是相對於it應用架構而言的，指的是為了各種應用系統能夠順利 可靠地執行，而提供的一系列硬體 軟體的集合體。正是因為有了這些it基礎架構的各種設施，it應用架構才能執行並提供服務。網度釋義 it基礎架構指的是客戶端裝置 伺服器 儲存 網路裝置 交換機 路由器 ...