線上服務應急與技術攻關方法論

海恩法則和墨菲定律

海恩法則指出：

每一塊兒嚴重事故的背後，必然有29次輕微事故和300起未遂先兆以及1000起事故隱患。

海恩法則強調兩點：

（1）事故的發生是量的積累的結果；

（2）再好的技術，再完美的規章，在實際操做層面，也沒法取代人自身的素質和責任心。

根據海恩法則，一塊兒重大事故發生以後，咱們要在處理事故和解決問題的同事，還要及時的對同類問題的「事故徵兆」和「事故苗頭」進行排查並處理，以防止相似問題的再次發生，將問題在萌芽狀態就將其解決掉，這能夠做爲互聯網企業線上應急的指導思想。

墨菲定律指出：

若是有兩種或者兩種以上方式去作某件事情，而選擇其中一種方式將致使災難，則一定有人會作出這種選擇。

默認定律強調一下幾點：

（1）任何事情都沒有表面看起來那麼簡單

（2）全部事情的發展都會比你預計的時間長

（3）會出錯的事情總會出錯

（4）若是你擔憂某種狀況會發生，那麼它更有可能發生

墨菲定律其實是個心理學效應，若是你擔憂某種狀況會發生，那麼它更發生的可能性很大，長此以往就必定會發生。

墨菲定律給到咱們技術人的警示：

對生產環境發生的任何怪異現象和問題都不要輕視，對其背後產生的緣由必定要徹查。

海恩法則給到咱們技術人的警示：

任何生產環境的嚴重故障，背後都有不少次小問題的積累，積累到必定量級以後會致使質變，進而發生更嚴重的故障。

因此，咱們須要對線上服務，產生的任何問題徵兆，不論問題大小，都要刨根問底，對任何問題都要持懷疑態度，問問本身"爲何會發生？發生的緣由是什麼？如何排查和解決？怎麼快速恢復服務？如何避免？"等等。不能由於問題的現象不明顯而忽略。

線上應急的目標、原則、方法

一、應急目標

行動的方向在關鍵時間正確把握，在應急過程當中不能偏離目標。

生產環境發生故障，要快速優先想辦法恢復服務，避免或減小因故障形成的損失，下降對用戶的影響。

二、應急原則

對應應急原則總結以下：

（1）第一時間恢復系統而不是完全查找緣由解決問題，快速止損。

（2）有明顯的資金損失時，要在第一時間升級，快速止損。該條用在金融領域尤其關鍵。

（3）當前應急負責人若短期內沒法解決問題，必須升級處理。

（4）應急過程當中在不影響用戶體驗前提下，要保留部分現場和數據。便於恢復後定位分析問題緣由。

三、應急方法和流程

線上應急必須有組織、有計劃的進行。

線上應急主要分爲六個階段：

應急要有整體目標：儘快恢復問題，消除影響。無論應急的那個階段，首要問題都是優先恢復系統問題，恢復問題不要求立馬定位問題，也不必定有完美的解決方案。

通常經過經驗判斷，啓動線上的問題預處理方案等，達到快讀恢復問題的目標。同時，要注意保留部分現場，便於過後定位解決並覆盤問題。

一、發現問題

一般針對系統層面來講的，問題的發現必定是藉助於系統的告警、自動化監控等機制來實現的，不能由用戶、業務方來告訴通知你的系統出現問題了，若是這樣，你的系統出現問題已經持續了一段時間了。

監控層面，一般都是對系統層面、應用層面、資源層面進行監控。

對系統層面的監控包括：系統的CPU利用率、系統負載、內存是會用狀況、網絡IO負載、磁盤負載、I/O等待、交換區的使用、線程數及打開的文件句柄數等進行監控，一旦超出閾值，就及時告警。

對應用層面的監控包括對服務接口的響應時間、吞吐量、調用頻次、接口成功率即接口的波動率進行監控。

對資源層面的監控包括對數據庫、緩存和消息隊列的監控。咱們一般會對數據庫負載、慢SQL、鏈接數等進行監控；對緩存的鏈接數、佔用內存、吞吐量、響應時間等進行監控；對消息隊列的響應時間、吞吐量、負載、積壓狀況進行監控。

二、定位問題

首先要根據經驗來分析 ，應急團隊中有人對相應問題有經驗，並肯定可以經過某種手段來進行恢復，則應第一時間快速恢復，同時保留現場，而後定位問題。

應急人員定位過程當中可能須要與業務負責人、技術負責人、技術人員、運營和運維一塊兒，對產生問題的緣由進行快速分析。

須要考慮以下問題：

（1）問題系統最近是否進行了上線操做？

（2）依賴的基礎平臺和資源是否進行了上線或者升級？

（3）依賴的系統最近是否進行了上線？

（4）運營是否在系統裏面作過運營變動？

（5）網絡是否有波動，聯繫運維人員協助排查？

（6）最近的業務訪問量是否正常，是否有異常流量？

（7）服務的適用房是否有促銷活動？

三、解決問題

解決問題的階段有時在應急處理中，有時在應急處理後。理想狀況下，出現問題系統啓動應急預案，每一個系統會對各類問題設計止損、兜底、降級開關等策略。所以，發生嚴重問題先使用啓用這些預案來恢復問題，以後再定位和解決問題。

解決問題固然要以定位問題爲基礎，必須清楚的明確分析出問題的根本緣由，再提出解決問題的有效方案，切記沒有明確緣由以前，不要使用各類可能方法來嘗試修復問題，這樣可能尚未解決當前問題，可能會引出了另一個問題。

四、消除影響

解決問題時，某個問題可能尚未被解決就已恢復，不管在那種狀況下都須要消除問題產生的影響。

五、覆盤問題

消除問題後，須要應急團隊與相關方回顧事故產生的緣由、應急過程的合理性，對樹立處理啊的問題提出整改措施，主要聚焦一下幾個問題：

（1）相似的問題還有哪些沒有想到？

（2）作了哪些事情，這個事故就不會發生了？

（3）作了哪些事情，這個事故即便發生了也不會產生損失？

（4）作了哪些事情，這個事故即便法神過來，也不會產生這麼大的損失？

固然，回顧事故目的再也不犯相似的錯誤，而不是懲罰當事人。

六、避免措施

根據回顧問題提出的改進方案和避免措施，咱們必須以正式的項目管理方式進行統一管理，若是有項目經理的角色，則將避免措施和改進措施一併交給項目經理去跟進；若是沒有，則請創建一個改進措施和避免措施的跟進方案和機制，不然，長此以往，問題就被忽略了。

技術攻關方法論

技術攻關流程圖：

技術攻關的目標是解決問題。

從問題發生的環境和背景入手，優先考慮上述圖中的提到的幾個問題：

一、最近是否有變動、升級或上線操做？

優先考慮這一條，特別是上線完成後收到系統告警，用戶反饋的相關問題及時關注，若是因上線致使出現的問題，要第一時間回滾處理，避免擴大影響。

同時，創建健全上線流程和上線評審機制，每次上線都須要有快速回滾方案。

二、以前是否有遇到過相似的問題？

根據歷史經驗判斷系統是否曾出現過相同或相似的問題，若是有解決相似的問題經驗，能夠參考快速的應用歷史經驗解決問題。

要求每次故障後覆盤並總結故障緣由，並給出問題解決方案，積累到經驗庫。

三、是否有相關領域的專家？

遇到了更深層次的問題，好比遭遇DDOS攻擊、性能扛不住、網絡故障、使用的中間件頻繁告警等。相似問題先求助相關領域專家，他們積累了更加豐富的經驗，或能更深刻了解緣由並快速解決問題。

以上流程仍然沒法解決問題，就須要本身想辦法作技術攻關了。

對於任何問題的分析，須要從如下幾個方面入手來分析：

簡稱：5W

When：何時出現的問題？

What：什麼出現了問題？

Who：誰在什麼時間裏發現了問題？問題影響了誰？

Where：哪裏出現了問題？

Why：爲何出現了問題？

根據以上的分析，幫助你理清思路，初步對系統作判斷，而後從這個系統的日誌、數據、工具，並結合代碼定位分析問題緣由。

這裏也就體現了系統中日誌的重要性，好的日誌能協助快速而準確的定位問題。

能夠想辦法「最小化復現」線上問題，最小化復現是問題產生時所依賴的組件最小化集合，容易搭建，減小了使用組件的範圍，有助於迅速定位問題緣由。

若是能在一個可控的環境或者仿真環境上重現問題，或者經過遠程調試的手段也能協助定位問題。

定位到問題緣由後，要給出解決方案。

評估解決方案對線上的影響，權衡利弊，選擇最佳方案，並給出選擇的緣由。

將問題解決方案報備給上級進行評審，評審經過後再實施。方案須要在開發環境和QA環境進行驗證，不只僅要驗證方案所解決的問題，同時，還要避免對現有功能有所影響，所以可能還須要進一步迴歸驗證。

經過這樣一系列技術攻關流程，能夠保障技術攻關過程當中獲得完整、正確且高效的問題解決之道。

參考：分佈式服務架構、原理、設計與實戰

歡迎關注個人公衆號，掃二維碼關注得到更多精彩文章，與你一同成長~