本文主要分享《分佈式服務架構：原理、設計與實戰》相關的線上應急的目標、原則和方法。之所以分享在於近來再次回顧了以往的線上應急案例，覺得其中的內容有很大的參考價值。
一、線上應急的目標是什麼？
行動的方向在關鍵時刻一定要正確，在應急過程中不能偏離目標：
在生產環境發生故障時快速恢復服務、避免或減少故障造成的損失，避免或減少故障對客戶的影響。
二、線上應急的原則包含哪些？
- 1.應第一時間恢復系統而不是徹底解決問題，快速止損。
- 2.有明顯的資金損失時，要在第一時間升級，快速止損。
- 3.應急指揮要圍繞目標，快速啓動應急過程和快速決策止損方案。
- 4.當前應急責任人如果在短時間內不能解決問題，則必須進行升級處理。
- 5.應急過程中在不影響用戶體驗的前提下，要保留部分現場和數據。
三、線上應急的方法和流程有哪些？
線上應急一般分爲6個階段：發現問題、定位問題、解決問題、消除影響、回顧問題、避免措施。
1.發現問題
發現問題時通常通過自動化的監控和報警系統來實現。一般我們會對系統層面、應用層面和數據層面進行監控。
對系統層面的監控包括對系統的CPU利用率、系統負載、內存使用情況、網絡I/O負載、磁盤負載、I/O等待、交換區的使用、線程數及打開的文件句柄數等進行監控，一旦超出閾值，就需要報警。
對應用層面的監控包括對服務接口的響應時間、吞吐量、調用頻次、接口成功率及接口的波動率等進行監控。
對資源層的監控包括對數據庫、緩存和消息隊列的監控。我們通常會對數據庫的負載、慢SQL、連接數等進行監控；對緩存的連接數、佔用內存、吞吐量、響應時間等進行監控；以及對消息隊列的響應時間、吞吐量、負載、積壓情況等進行監控。
2.定位問題
定位問題時，首先要根據經驗來分析，如果應急團隊中有人對相應的問題有經驗，並確定能夠通過某種手段進行恢復，則應該第一時間恢復，同時保留現場，然後定位問題。
在應急人員定位過程中需要與業務負責人、技術負責人、核心技術開發人員、技術專家、架構師、運營和運維人員一起，對產生問題的原因進行快速分析。
在分析過程中要先考慮系統最近發生的變化，需要考慮如下問題:
- (1)問題系統最近是否進行了上線？
- (2)依賴的基礎平臺和資源是否進行了上線或者升級？
- (3)依賴的系統最近是否進行了上線？
- (4)運營是否在系統裏面做過運營變更？
- (5)網絡是否有波動？
- (6)最近的業務是否上量？
- (7)服務的使用方是否有促銷活動(不僅僅可能是一些商業活動還可能是其它相關)？
3.解決問題
解決問題的階段有時在應急處理中，有時在應急處理後。在理想情況下，每個系統會對各種嚴重情況設計止損和降級開關，因此在發生嚴重問題時先使用止損策略，在恢復問題後再定位和解決問題。
解決問題要以定位問題爲基礎，必須清晰地定位問題產生的根本原因，再提出解決問題的有效方案，切記在沒有明確原因之前，不要使用各種可能的方法來嘗試修復問題，這樣可能還沒有解決這個問題又引出另一個問題。
4.消除影響
在解決問題時，某個問題可能還沒解決就已恢復，無論在哪種情況下都可能需要消除問題產生的影響。
- (1)技術人員在應急過程中對系統做的臨時性改變，後證明是無效的，則要嘗試恢復到原來的狀態。
- (2)技術人員在應急過程中對系統進行的降級開關的操作，在事後需要恢復。
- (3)運營人員在應急過程中對系統做的特殊設置如某些流量路由的開關，需要恢復。
- (4)對使用方或者用戶造成的問題，儘量採取補償的策略進行恢復，在極端情況下需要一一覈實。
- (5)對外由專門的客服團隊整理話術統一對外宣佈發生故障的原因並安撫用戶，話術儘量貼近客觀事實，並從用戶的角度出發。
5.回顧問題
消除問題後，需要應急團隊與相關方回顧事故產生的原因、應急過程的合理性，對梳理出來的問題提出整改措施，主要聚焦於如下幾個問題:
- (1)類似的問題還有哪些沒有想到？
- (2)做了哪些事情，這個事故就不會發生？
- (3)做了哪些事情，這個事故即使發生了，也不會產生損失？
- (4)做了哪些事情，這個事故即使發生了，也不會產生這麼大的損失？
當然，回顧事故的目的是不再犯類似的錯誤，而不是單單懲罰當事人，就沒有然後了。
6.避免措施
根據回顧問題時提出的改進方案和避免措施，我們必須以正式的項目管理方式進行統一管理。如果有項目經理的角色，則將避免措施和改進措施一併交給項目經理去跟進；如果沒有，則請建立一個改進措施和避免措施的跟進方案和機制，否則，久而久之，問題就被忽略了。
四、我在實踐中是如何應用上述目標、原則和方法的？
過往寫的一些文章可供讀者朋友們參考：
- 1.基於報告之覆盤
- 2.Gateway Timeout 504問題覆盤
- 3.ssh問題之覆盤
- 4.數據庫被刪之反思
- 5.服務器安全策略之思考與實踐
- 6.Linux設備上沒有空間之覆盤
- 7.項目依賴管理混亂問題之解決
- 8.分佈式配置中心之思考
- 9.WebService安全機制的思考與實踐
- 10.SQL優化之博客案例
回顧職業生涯，除以上文章列舉的案例外，還有更多，例如以下三個：
- 1.在創業公司的時候，爲什麼Tomcat上的應用服務總是宕機(那個時候我沒有弄清楚真正的原因是什麼，採用一個臨時的辦法，寫shell腳本，每分鐘檢測，如果宕機，立即重啓，以此確保服務的正常運行)？
- 2.在教育Saas公司的時候，爲什麼MongoDB會導致整個系統崩塌(後面我們團隊以此覆盤以後，我明白了爲什麼以及後續將如何避免這樣的問題，其實這已經不是一個小小的中間件問題，上升到整個業務流程的管理)？
- 3.在M2公司的時候，爲什麼報告不能實時生成反而將其改爲定時生成(經過當初的多次試驗，我弄清楚了爲什麼，這既有技術層面的實現原因，也有業務層面的數據處理問題)？
同樣無論你的職責是研發工程師還是架構師、技術經理、項目經理之類的，都需要敬畏以下法則和定律:
- 1.海恩法則。
- 2.墨菲定律。
1.海恩法則
海恩法則的定義爲:
每一起嚴重事故的背後，必然有29次輕微事故和300起未遂先兆及1000起事故隱患。
該法則強調如下兩點：
- (1)事故的發生是量的積累的結果。
- (2)再好的技術、再完美的規章，在實際操作層面也無法取代自身的素質和責任心。
2.墨菲定律
如果有兩種或兩種以上方式去做某件事情，而選擇其中一種方式將導致災難，則必定有人會做出這種選擇。
墨菲定律強調以下四點:
- (1)任何事情都沒有表面看起來那麼簡單。
- (2)所有事情的發展都會比你預計的時間長。
- (3)會出錯的事總會出錯。
- (4)如果你擔心某種情況發生，那麼它更有可能發生。
本文分享到此結束，希望能夠對大家有所幫助！！！