9月底的時候，我們團隊負責的兩個系統在幾周內連續發生了兩次線上的生產故障，雖然最後並沒有發生嚴重的損失，但是領導免不了要提一些更高的要求，圍繞 保持安全穩定，避免故障再次發生 這個目標需要梳理種種可能的優化措施，也藉此機會來梳理下我對於如何做好運維管理工作的一些看法，歡迎各位同行批評指正。

本文中所說的運維是指應用系統的運維工作，與傳統的Linux運維、資料庫運維不同，應用系統運維更多的是從一個線上的業務系統能否安全穩定執行的角度來思考，包括系統日常的執行狀況是不是正常、遇到線上生產故障能不能快速恢復、對於突發事件有沒有對應的處置手段等等，總的目的只有一個，就是要想盡辦法保障不管在什麼情況下，都有措施或手段能夠快速的恢復業務的執行。當然具體到不同業務系統，可以根據業務時效性要求和重要性要求劃分不同的保障等級，本文略過不表。

應用系統運維與面向單個產品的運維相比，有以下兩個特點：

• 運維物件較多且可能比較複雜。既有基礎的作業系統、資料庫，也有自主開發的應用程式，可能還會涉及很多的開源軟體如Kafka、Zookeeper、Redis、MongoDB等等。
• 運維過程中打交道的人也比較多。作業系統管理員、資料庫管理員、各種監控工具管理員、專案開發人員、業務部門人員等等。

這兩個特點決定了應用系統運維管理人員沒有辦法精通所有的領域，如何實現運維的目標更多的要靠管理手段而不是技術能力，管理手段也大體上分為三個層次：

• 儘早發現問題的手段。
• 快速恢復業務的手段。
• 緊急處置故障的手段。

我認為這三個層次的重要性依次降低，如果我們做好了前面的功課，可能會降低後面事情發生的概率，下面依次展開說一下每個層次的具體手段。

儘早發現問題的手段

• 監控。這個的重要性自不必說，全面的監控指標和靈敏的閾值能夠讓我們收到很多告警簡訊，但最重要的是我們要能發現哪一條才是會影響業務的。
• 日常巡檢。巡檢儘量做成自動化的方式，但是巡檢報告的解讀必須運維管理人員親自操刀，儘量做到對每一個異常項都刨根問底。巡檢即包括作業系統的檢查，例如磁碟空間、檔案控制代碼等，也包括資料庫的檢查，例如AWR報告、慢查詢等，還應該包括業務系統的檢查，包括營業日曆是否正確、系統線上人數有沒有破新高等等。
• 值班制度。不管是不是現場，我覺得堅持值班制度非常有必要，通過值班安排落實了職責，避免三個和尚沒水喝的尷尬情況。

快速恢復業務的手段

• 流量隔離。這個手段我覺得是最好的恢復業務的手段，但是所需要的投入往往非常大，首先需要應用是叢集部署，這樣才能支援流量的排程和隔離，其次還要給運維人員提供隔離的工具或手段，如果運維人員在開發階段能夠提出這個要求，後續運維過程中可以節省不少人力。
• 重啟應用。這個的前提是要確保你的應用程式是對狀態不敏感或者支援優雅重啟的，這個辦法往往能解決80%的生產問題。
• 重啟作業系統。如果重啟應用還不能解決問題，那麼就重啟作業系統好了。
• 主備切換。對於主備模式部署的應用，這往往是最後考慮的一個手段，而且一般還不敢嘗試，特別是在有資料同步的場景下。

在執行快速恢復業務手段之前，我們都應該牢記把故障裝置的現場資訊收集記錄下來，為開發人員排查、再現問題提供重要的現場資料。

緊急處置故障的手段

如果前兩個部分的手段都不能幫助解決生產問題，到這個層次需要有提前的準備才行，例如日常的備份、異地的備份等等，如果日常的備份也沒有，那還有一個終極的辦法，那就是 拉開發來上緊急版本啊 。