系統壞了，不要慌，參考如下措施

處理這類事情特別能體現一個人的綜合能力。因為它會涉及到抗壓能力、對外的溝通能力，以及排查問題所需的技術能力等等多個方面。如果你還沒機會成為核心開發，其實很少會有這樣充滿壓力的經歷。因為在這個情況下處理事情其實是很慌的，畢竟所有使用系統的人以及他們的老板、你的上級、你的老板等等無數雙眼睛都在盯著這件事情。

我還記得有一年雙11，我作為“首席問題處理官”正在緊急處理服務器扛不住壓力的問題，老板默默走到我身后問到“什么問題啊?什么時候好?”。你腦補一下這畫面，想象一下看看。

只要你接下去還會繼續從事程序員這個職業，我想這樣的場景你總歸會有機會遇到的。因為一個著名的定律——墨菲定律。墨菲定律：凡是可能出錯的事就一定會出錯。如果沒有一個清晰的應對思路，那么一旦發生線上問題就會像熱鍋上的螞蟻一樣，急得團團轉，像無頭蒼蠅一樣到處亂撞(試)。

所以，我這次就想分享一些我多年作為“首席問題處理官”所總結下來的經驗。這可是承載了我N多汗水和腦細胞的經驗～

在日常的項目開發迭代過程中我們遇到一個bug，大家的處理過程幾乎是一樣的：定位bug -> 解決bug。可能少部分人在解決bug之后會有一個思考、復盤，看看是否有類似bug的地方，一并處理掉。

這個“定位 -> 解決 -> 復盤”的過程也同樣適用于線上問題的處理。但是必然不僅僅如此。俗話說，解決一個問題最難的地方不是解決的過程，而是定位的過程。所以，針對線上問題我們等不起定位問題所花費的時間，因此要將「恢復」系統正常使用放在最首要的位置。所以，這個過程就變成了：“恢復 -> 定位 -> 解決 -> 復盤”。

這里多說一句，有一部分人的觀點認為，將恢復系統作為首要目標，應當包括犧牲保留現場的動作，因為這個動作可能也需要耗費數分鐘才行。我對這個觀點持反對意見。理由是，解決問題的時長的確是一個很重要的指標，但是問題既然已經發生，如果由于沒有保留現場導致后續沒有排查到根源，導致下次該問題再次出現，到時候場面將會更加難看。所以我對這事的觀點是，保留現場最重要。因此，這個過程又變成了：“保留現場 -> 恢復 -> 定位 -> 解決 -> 復盤”。

當然了，保留現場也不是說非得面面俱到，花很多時間。用最快的方式保留你當下所能想到的所有相關線索的地方即可。如果事后還是由于線索不足導致未能排查到根本原因，那只能說經驗不足，考慮一下以后需要多保留哪些現場數據才行。好了，確定了這5個步驟，那么具體每個步驟可以做些什么呢?我來一個個說。

保留現場最最最重要的一件事是保存異常程序的dump文件。有了它，你就可以擺脫盲人摸象式的分析問題，可以快速定位問題的發源地。

我用了三個“最”來強調它的重要性。如果你還沒掌握它，那么后面我提到的東西都先放一放，先去掌握它。

另外，如果系統的監控體系并不完備的話，還需要將問題發生時，操作系統、各第三方組件自帶的監控數據快速地通過截圖保存下來。

保存監控數據的時候要特別留意一下網絡相關的數據。如果發現網絡相關的數據有異常，那么再把當下的網絡連接情況通過 命令保存下來。因為相對來說，網絡出現問題的概率遠遠大于硬件，不管是程序導致的還是其他原因。規模越大的系統，越是如此。

恢復系統訪問有很多方法。首先不得不提到一個適用于80%情況的神技了——重啟。沒錯，根據多年的經驗來看這招的確在大多數情況下很有效。也正因為屢試不爽，所以很多人習慣性地會在第一時間去重啟，導致現場忘記保存并受到破壞。重啟也分兩種，強制重啟和自然重啟。當然優先考慮自然重啟，這樣能避免產生一些意料之外的臟數據。但是如果是系統出現資源耗用異常的話，就不要傻傻地等自然重啟了，只能強制重啟(kill掉進程)。

第二種常見的方法是「回滾」。當然它的前提條件是你判斷下來問題的出現是由于最近一次發布。否則盲目的回滾不但起不到作用，還會越弄越亂，特別在分布式系統中。因為在分布式系統中，一旦上下游耦合的地方出現對接不上，輕則報錯，重則出現大量的異常數據，夠你后續折騰好久的。

第三種方法是「降級」。暫停出問題的模塊，停止服務。當然，這個動作需要和業務方做好溝通，是否單獨降級某個模塊會導致業務不完整之類的問題。

第四種方法是「限流」或者「擴容」。如果你發現是系統扛不住突增的流量，如果有條件的話可以快速擴容幾臺機器和程序。如果沒法擴容的話可以選擇限流，將一定百分比的請求直接拒絕服務。畢竟所有無法提供服務和部分無法提供服務相比，肯定還是后者劃算。

還有一些比較小眾的方法是「切到備機」、「故障隔離」等，這里就不展開了。它們對環境、條件的要求更多一些。有時候可能系統并未恢復到完全正常的狀態，比如，讀取數據是OK了，但是某些操作寫入數據到時候還是有問題。在這樣的情況下，不要著急定位問題，還是先盡最大努力恢復到最大程度的可用狀態再進行下一步的動作，畢竟用戶第一嘛。

關于定位問題，如果有dump文件的話最方便了，通過dump文件分析工具來分析dump文件就可以快速定位到出問題的代碼行，特別是程序阻塞、內存溢出、cpu100%之類明顯是程序本身的問題。

不同的語言有不同的dump分析工具，可以自行網上搜一下教程。最終目的就是定位到異常點的堆棧信息，有了它就相當于直接把問題代碼出現在哪里都給定位到了。

如果說分析dump文件是跳過抽絲剝繭的步驟，直擊要害的話。通過監控數據、日志層層分析是個慢活。但是如果缺失dump文件或者從dump文件從未能分析出問題的情況下，也只能選擇后者。

我們在看日志、監控數據的時候一定要有關聯起來看的意識，而不能僅僅在單個維度上看。因為有時候你在單個維度上看到的數據像是正常的，但是你關聯起來看就不一定了。比如，tcp連接數降低了一半，但是內存反而漲了100%，為什么?這里面可能就藏著故障的線索。

定位到了問題，解決起來就很簡單了。該改代碼的改代碼，該改配置的改配置文件。這里就不多說了，畢竟情況太多，大家遇到的可能都不太一樣。

大家都知道復盤的好處，但是真正做復盤的人真不多。如果你不知道從何下手來做復盤的話，不妨從以下幾個問題入手。

1.這次故障原因是什么?

2.是否有更快的方式在當時來恢復業務?

3.如何避免再出類似故障?

4.當前系統中是否還有類似的潛在風險?

如果你能回答這些問題，我覺得這個復盤就很到位了，剩下的就是執行。

當然了，不管如何優秀的處理故障，最理想的還是不要發生故障。所以我們需要在前期做更多的準備。

我們很多人了解自己負責的程序只有通過coding這一種途徑。除非該程序是個單體應用，否則這樣的方式是遠遠不夠的。

我建議你按照以下清單去了解你的程序：

1.程序包含有哪些模塊，對應使用者是哪些?哪些是核心模塊，哪些是可以“棄車保帥”的?

2.多個模塊/系統間如何流轉的?(盡量畫一個流程圖，加深記憶)

3.依賴了哪些中間件，誰負責維護他們?

4.依賴了哪些其他的程序，強依賴還是弱依賴，誰負責維護他們?

5.依賴的存儲、消息隊列背后又依賴了哪些存儲，存儲運維負責人是誰?

6.線上的程序部署在什么環境。你是否有條件獨立進行部署并調優?

大多數的故障不是突然發生，而是有一個逐漸積累的過程，直到爆發。所以監控的價值不僅僅是看看數據那么簡單，對于異常識別特別有幫助。

一般監控分兩個維度，系統維度和業務維度。監控指標分為三層，「環境指標」、「程序指標」、「業務指標」。具體怎么做我在之前的文章《分布式系統關注點——360°的全方位監控》有具體說明，這里就不贅述了。

如果是分布式系統，還可以搭建一個請求鏈路跟蹤系統。有很多成熟的現成解決方案，CAT、SkyWalking、Zipkin、Pinpoint等等。

多說一句，我們在做監控預警的時候，除了設置閾值還要關注一下波動率。比如，某項資源日常使用率20%，除了設置超過80%的閾值進行預警之外，在它產生波動幅度100%(使用率40%)以上的時候也需要預警，提前讓人關注。否則一旦以一個較快的速度增長到80%之后，留給你在故障爆發前消滅它的機會就非常渺茫了。

另外，針對常見的故障預設幾套故障響應方案，以及進行定期的故障演練(一般上了一定規模的公司或者處于擴張期的公司才會考慮)可以讓團隊面對線上故障的時候更加地游刃有余。

假如你不幸成為了線上故障的解決者，如果上級不在旁邊的話，需要定時向上級匯報問題處理情況，以便TA了解問題的嚴重程度、修復進度并作出決策。

反正就算你不上報，遲早也會被催。與其被動的被催，不如主動上報。

原文來自： https://www.linuxprobe.com/system-down-process.html