在講解事件和故障處理思路之前，先說一個故障場景（以呼叫中心系統為例）：

業務人員反映呼叫中心系統運行緩慢，部分電話在自助語言環節超時，電話轉人工座席，人工座席出現線路突發情況。

運維人員忙碌，查看資源使用情況，查看服務是否正常，查看日志是否報錯，查看交易量是否還在……時間在敲打鍵盤，敲打鍵盤，在鍵盤上打字，但原因仍然沒有找到。

經理過來查看情況：“系統恢復了嗎？”、“故障有什么影響？”、“事務中斷了嗎？”……

運維人員趕緊敲鍵盤，寫sql，查看交易量；敲了鍵盤，寫了命令，看了看系統資源和情況……

最后定位，問題原因是其中一個函數沒有控制返回次數，導致內存泄漏。

針對這個故障，業務希望運維能夠更快的解決故障恢復。經理希望制定和優化呼叫中心的故障處理流程，做了以下幾件事：

1、是時候確定故障排除過程的優先級了——“用鼠標可以做什么，而不是鍵盤”

2、提前發現故障，加強監控——“技術比業務更早發現問題，監控不僅是報警，還有助于故障定位”

3、完善故障應急預案——“應急預案及時、準確、簡單明了”

4、長期目標：故障的自愈——“可以??治愈的操作自動化，機器可以做的機器”

下面將從常見的故障排除方法介紹開始，然后從故障前的準備工作（完善監控、制定應急預案等）著手解決管理者提出的問題，并提出解決故障的思路未來。

1、常用方法：

1）判斷故障現象，初步判斷問題影響

在處理故障之前，運維人員首先要了解故障現象，而故障現象直接決定了故障應急預案的制定，這取決于運維人員需要對整體有一定的熟悉程度應用系統的功能。

確認故障現象后，即可指導運維人員初步判斷故障影響。

2）緊急恢復

運維最基本的指標是系統可用性，而應急恢復的及時性是系統可用性的關鍵指標。

通過對上述故障現象和影響的判斷，可以制定故障應急操作。故障應急操作有很多，例如：

另外，需要補充的是，在故障出現之前，需要在一定條件下保存當前系統場景。例如，在殺死一個進程之前，您可以先捕獲一個 CORE 文件或一個數據庫快照文件。

3）快速定位故障原因

故障現象能否重現對于快速解決問題非常重要。可復現是指總會有方法或工具幫助我們定位問題的原因，而可復現的故障往往可能是由于服務異常、變更等工作造成的。

但是，如果故障是零星的，發生概率很小，則故障排除就比較困難，這取決于系統在故障期間是否有足夠的現場信息來確定是否可以定位始終原因。

大多數故障是由更改引起的。在確定故障現象后，如果有相應的變化，有助于從變化的角度分析是否是由變化引起的it運維技術，以便快速定位故障，制定折返等應急預案。

一方面，應用系統提倡解耦，一筆交易會流經不同的應用系統和模塊；另一方面，故障可能是由于應用程序、系統軟件、硬件、網絡等環節的問題。在排除故障原因時，應避免全面檢查。建議在協調相關團隊調查之前將問題范圍縮小到某個程序。

同時（3）點）為避免所有相關團隊同時在沒有線索的情況下同時排查，牽頭方需要有開放的態度，要求相關方在收窄后配合定位范圍，相關方需要積極配合。工作態度。

定位故障原因最常用的方法是分析應用程序日志。運維人員不僅要知道業務功能對應的是哪個服務進程，還要知道服務進程對應的是哪個應用日志，對應用日志的異常有一些簡單的判斷。能力。

故障期間的系統站點非常重要。緊急情況前，建議保留系統站點文件，如COREDUMP，或TRACE收集信息等，并備份一些可能被覆蓋的日志。

以上是一般故障的常用方法。當發生重大故障或多方故障時，小范圍排查往往不利于快速解決，需要啟動應急處理流程。建議考慮以下溝通：

2、完美監控

1）從監控可視化提升

完善的監控策略需要統一的可視化操作界面。制定完善的監控策略后，故障處理者需要能夠快速看到相應的運行數據，例如一段時間內的趨勢、故障期間的數據性能、性能分析等數據，而這些數據可以在提前將分析結果直接推送給故障處理人員，大大提高了故障處理的效率。以呼叫中心系統為例，需要提前配置以下實時交易數據，用于故障定位：

- 事務性能數據：平均事務時間、系統內部模塊事務時間（IVR事務時間、接口總線事務時間）、關聯系統事務時間（核心事務時間、工單系統事務時間等）

- 重要交易指標數據：交易量、IVR交易量、流量、座席呼叫率、核心交易數、工單等系統交易量

- 交易異常數據：交易成功率、失敗率、大部分有錯誤碼的交易

- 按服務器分析交易數據：根據每個服務處理的交易數量統計，總交易時間

有了以上交易數據，通過監控以一定的頻率統計，當發生故障時，運維人員可以通過鼠標點擊查看故障是從什么時候開始的，是系統內部有問題還是關聯系統有問題，最突出的事務是哪一個it運維技術，各個服務器的事務量是否均衡等等。

2）從監控的角度來看很完美

監控最基本的任務是實現對負載均衡設備、網絡設備、服務器、存儲設備、安全設備、數據庫、中間件和應用軟件等IT資源的全面監控和管理。在應用軟件的監控中，不僅需要對服務進程和端口的監控，還需要對業務層和事務層的監控。

全面的應用程序監控可以對故障進行早期預警，并保存影響應用程序運行環境的數據，以減少故障處理時間。

3）改進監控和報警

完善的監控策略需要有清晰的監控報警提示，值班人員可以根據監控報警做出簡單的問題定位和應急處理方案。例如，類似如下的監控消息：

22:00，在【理財應用系統】的【應用服務器10.2.111.111】中，【應用端口：9080】不存在，且端口功能【提供財務管理應用處理（負載均衡部署）】，原因可能是【服務異常停止】，監控系統進行了以下應急處理【自動執行端口進程啟動】，本次事件的緊急程度高]。

管理員可以通過短信內容看到是哪個系統、哪個應用、哪個模塊有問題，可能的原因是什么，對業務有什么影響，是否需要立即處理（例如，預警是否可以延遲到次日處理）等信息。

4)從監控分析改進

完善的監控策略不僅需要實時數據報警，還需要對匯總數據進行分析報警。不用說，實時數據分析警報的重要性在于從聚合和分析的數據中發現潛在的風險。疾病幫助。

5)通過監控主動改進

監控不僅僅是報警，它還可以做更多的事情，只要我們想辦法給它規則來主動解決事件，它就有能力為管理員處理故障。

3、應急計劃

需要提前制定故障應急預案，但是在日常工作過程中我們的應急預案遇到了一些問題：

1）應急預案缺乏持續維護，缺乏演練，信息不及時準確；

2）應急預案太大太全面，不利于閱讀和使用；

3）應急預案的形式大于實際使用效果，方案針對性不強；

4）只關注應急預案的內容，不關注運維人員對預案的理解；

針對以上常見問題，應急預案需要做到以下幾點：

1）精簡內容

很多人可能認為故障可以有多種形式，因此應急計劃需要涵蓋方方面面。但是在實際的排查過程中，我們可以發現我們的應急措施往往會復用幾個常用的步驟，所以我認為應急預案應該重點突出。如果一個應急計劃可以處理 80% 的常見故障，那么這個應急手冊應該是合格的。過分追求影響應用系統各個方面的內容，會導致解決方案的可讀性差，最終改變一個應該檢查的文檔。以下是我認為應用系統應急計劃應具備的內容：

(1）系統級：

可以知道當前應用系統在整個事務中的作用。當當前系統或上下游出現問題時，可以知道如何配合上下游分析問題，例如：上下游系統如何通信，是否有唯一的通信關鍵字等.

此外，在系統層面還涉及到一些基本的應急操作，如擴容、系統和網絡參數調整等。

(2）服務等級：

可以知道這個服務影響了哪些業務，服務中涉及的日志、程序、配置文件在哪里，如何檢查服務是否正常，如何重啟服務，如何調整應用級參數。

(3）事務級別：

能知道如何找出某個分支或某類事務有問題，無論是大規模的、局部的還是偶發的問題，都能用數據解釋事務的影響，并能定位事務錯誤信息。這里最常用的方法是使用數據庫查詢或工具。

知道如何檢查最重要的交易是否正常，以及重要定時任務的應急解決方案，如開戶、日期變更、對賬時間要求、應急措施等。

(4）輔助工具的使用：

有時，需要使用一些工具或自動化工具來輔助分析和應急響應。這時候，就需要有一個如何使用輔助工具的方法。

(5）交流計劃：

溝通計劃涉及通訊錄，包括上下游系統、第三方單位、業務部門等渠道。

(6）其他：

以上五點都完成了，相信這本應急手冊可以解決80%的故障恢復工作。

2）應急計劃是一項持續的工作

有了應急預案，很難讓運維人員不斷更新。我認為要解決這個困難，我們需要讓運維人員經常使用這本手冊。如果手冊沒有使用場景，管理人員需要為運維人員創造使用手冊的機會，例如應急演練。

3）關注運維人員對關鍵應用信息的理解

前兩點關注手冊，最后一點我覺得有必要關注使用它的人。一些運維人員認為應用運維人員沒有能力對應用系統本身的內容了解透徹，因此應用運維人員在排查過程中的狀態非常尷尬。該怎么辦。

對此，我同意應用運維人員不需要掌握應用系統的業務功能，但我認為應用運維人員對于應用系統本身需要具備以下基本能力：

（1）知道應用系統是做什么的，基礎業務是什么；

(2）了解應用架構部署，上下游系統邏輯關系；

（3）知道應用下服務的作用、端口、服務級別的緊急處理，以及如何查找和簡單定位日志等數據信息。

(4）了解應用系統的重要時間點和任務，如開、關、換天、定時任務，以及如何判斷這些任務是否正確

(5）了解最重要交易的流程；

(6）了解常見的數據庫表結構并且可以使用它們。

4、智能事件處理

處理方法如下（詳細智能涉及監控、規則引擎、配置工具、CMDB、應用配置庫等模塊協同工作）

文章轉載：twt企業IT社區