9月底的時候，我們團隊負責的兩個系統在幾周内連續發生了兩次線上的生産故障，雖然最後并沒有發生嚴重的損失，但是上司免不了要提一些更高的要求，圍繞
保持安全穩定，避免故障再次發生
這個目标需要梳理種種可能的優化措施，也借此機會來梳理下我對于如何做好運維管理工作的一些看法，歡迎各位同行批評指正。
本文中所說的運維是指應用系統的運維工作，與傳統的Linux運維、資料庫運維不同，應用系統運維更多的是從一個線上的業務系統能否安全穩定運作的角度來思考，包括系統日常的運作狀況是不是正常、遇到線上生産故障能不能快速恢複、對于突發事件有沒有對應的處置手段等等，總的目的隻有一個，就是要想盡辦法保障不管在什麼情況下，都有措施或手段能夠快速的恢複業務的運作。當然具體到不同業務系統，可以根據業務時效性要求和重要性要求劃分不同的保障等級，本文略過不表。
應用系統運維與面向單個産品的運維相比，有以下兩個特點：
- 運維對象較多且可能比較複雜。既有基礎的作業系統、資料庫，也有自主開發的應用程式，可能還會涉及很多的開源軟體如Kafka、Zookeeper、Redis、MongoDB等等。
- 運維過程中打交道的人也比較多。作業系統管理者、資料庫管理者、各種監控工具管理者、項目開發人員、業務部門人員等等。
這兩個特點決定了應用系統運維管理人員沒有辦法精通所有的領域，如何實作運維的目标更多的要靠管理手段而不是技術能力，管理手段也大體上分為三個層次：
- 盡早發現問題的手段。
- 快速恢複業務的手段。
- 緊急處置故障的手段。
我認為這三個層次的重要性依次降低，如果我們做好了前面的功課，可能會降低後面事情發生的機率，下面依次展開說一下每個層次的具體手段。
盡早發現問題的手段
- 監控。這個的重要性自不必說，全面的監控名額和靈敏的門檻值能夠讓我們收到很多告警短信，但最重要的是我們要能發現哪一條才是會影響業務的。
- 日常巡檢。巡檢盡量做成自動化的方式，但是巡檢報告的解讀必須運維管理人員親自操刀，盡量做到對每一個異常項都刨根問底。巡檢即包括作業系統的檢查，例如磁盤空間、檔案句柄等，也包括資料庫的檢查，例如AWR報告、慢查詢等，還應該包括業務系統的檢查，包括營業月曆是否正确、系統線上人數有沒有破新高等等。
- 值班制度。不管是不是現場，我覺得堅持值班制度非常有必要，通過值班安排落實了職責，避免三個和尚沒水喝的尴尬情況。
快速恢複業務的手段
- 流量隔離。這個手段我覺得是最好的恢複業務的手段，但是所需要的投入往往非常大，首先需要應用是叢集部署，這樣才能支援流量的排程和隔離，其次還要給運維人員提供隔離的工具或手段，如果運維人員在開發階段能夠提出這個要求，後續運維過程中可以節省不少人力。
- 重新開機應用。這個的前提是要確定你的應用程式是對狀态不敏感或者支援優雅重新開機的，這個辦法往往能解決80%的生産問題。
- 重新開機作業系統。如果重新開機應用還不能解決問題，那麼就重新開機作業系統好了。
- 主備切換。對于主備模式部署的應用，這往往是最後考慮的一個手段，而且一般還不敢嘗試，特别是在有資料同步的場景下。
在執行快速恢複業務手段之前，我們都應該牢記把故障裝置的現場資訊收集記錄下來，為開發人員排查、再現問題提供重要的現場資料。
緊急處置故障的手段
如果前兩個部分的手段都不能幫助解決生産問題，到這個層次需要有提前的準備才行，例如日常的備份、異地的備份等等，如果日常的備份也沒有，那還有一個終極的辦法，那就是
拉開發來上緊急版本啊
。