業務人員反映呼叫中心系統執行緩慢，部份**在自助語言環節系統處理超時，話務轉人工座席，人工座席出現爆線情況。
運維人員開始忙活了，查資源使用情況、查服務是否正常、查日誌是否報錯、查交易量還有沒有……時間不知不覺的在敲鍵盤、敲鍵盤、敲鍵盤中過去，但是原因還未定位。
經理過來了解情況：「系統恢復了嗎？」、「故障影響是什麼？」、「交易中斷了嗎？」……
運維人員趕緊敲鍵盤，寫 sql，看交易量；敲鍵盤，寫命令，看系統資源、情況……
最終，定位到問題原因是其中乙個功能沒有控制返回數量，導致記憶體洩露。
針對這個故障，業務希望運維能否更快的解決故障的恢復，經理希望制定優化呼叫中心故障處理流程，做了以下幾件事：
提前發現故障，加強監控：「技術早於業務發現問題，監控不僅是報警，還要協助故障定位」
完善故障應急方案：「應急方案是最新的、準確的、簡單明瞭的」
長遠目標：故障自癒：「能固化的操作自動化，能機器做的讓機器做」
下面將從故障常見的處理方法開始介紹，再從故障前的準備工作（完善監控、制定應急方案等方式）來解決經理提出的問題，並提出未來解決故障的想法。
一、常見的方法
1、確定故障現象並初判問題影響
在處理故障前，運維人員首先要知道故障現象，故障現象直接決定故障應急方案的制定，這依賴於運維人員需要對應用系統的整體功能有一定的熟悉程度。
確認了故障現象後，才能指導運維人員初判斷故障影響。
2、應急恢復
運維最基本的指標就是系統可用性，應急恢復的時效性是系統可用性的關鍵指標。
有了上述故障現象與影響的判斷後，就可以制定故障應急操作，故障應急有很多，比如：
另外，需要補充的是，在故障應急前，在有條件的情況需要儲存當前系統場景，比如在殺程序前，可以先抓個core檔案或資料庫快照檔案。
3、快速定位故障原因
1）是否為偶發性、是否可重現
故障現象是否可以重現，對於快速解決問題很重要，能重現說明總會有辦法或工具幫助我們定位到問題原因，而且能重現的故障往往可能是服務異常、變更等工作導致的問題。
但如果故障是偶發性的，是有極小概率出現的，則比較難排查，這依賴於系統是否有足夠的故障期間的現場資訊來決定是否可以定位到總是原因。
是否進行過相關變更。
大部份故障是由於變更導致，確定故障現象後，如果有應的變更，有助於從變更角度出現分析是否是變更引起，進而快速定位故障並準備好回切等應急方案。
2）是否進行過相關變更
大部份故障是由於變更導致，確定故障現象後，如果有應的變更，有助於從變更角度出現分析是否是變更引起，進而快速定位故障並準備好回切等應急方案。
3）是否可縮小範圍
一方面應用系統提倡解耦，一支交易會流經不同的應用系統及模組；另一方面，故障可能由於應用、系統軟體、硬體、網路等環節的問題。在排查故障原因時應該避免全面性的排查，建議先把問題範圍縮小到一定程式後再開始協調關聯團隊排查。
關聯方配合分析問題
與第（3）點避免同時各關聯團隊同時無頭緒的排查的同時，對於牽頭方在縮小範圍後需要開放的態度去請求關聯方配合定位，而對於關聯方則需要有積極配合的工作態度。
4）是否有足夠的日誌
定位故障原因，最常用的方法就是分析應用日誌，對運維人員不僅需要知道業務功能對應哪個服務程序，還要知道這個服務程序對應的哪些應用日誌，並具備一些簡單的應用日誌異常錯誤的判斷能力。
5）是否有core或dump等檔案
故障期間的系統現場很重要，這個在故障應急前建議在有條件的情況下留下系統現場的檔案，比如 core\dump，或trace採集資訊等，備份好一些可能被覆蓋的日誌等。
上述是一般性的故障常見的方法，在重大故障或多方處理的故障出現時，往往小範圍的排查不利於快速解決，需要啟動緊急處理的流程，建議可以考慮以下溝通：
二、完善監控
1、從監控視覺化上完善
完善的監控策略需要有統一的視覺化操作介面，在制定完善的監控策略後，故障處理人員需要能夠快速的看到相應的執行資料，比如：能夠看到一段時間的趨勢、故障期間的資料表現、效能分析的情況等等資料，且這些資料可以提前制定好策略直接推出分析結果給故障處理人員，這樣就大大提高了故障的處理效率，以呼叫中心系統為例，需要提前配置好以下實時交易資料，以便故障定位：
有了以上交易資料，並通過監控按一定頻率統計，運維人員在出現故障時，通過滑鼠即點選即可看到故障什麼時候開始，是系統內部有問題還是關聯系統有問題，最突出的交易是哪一支，各伺服器交易量是否均衡等情況。
2、從監控面上完善
監控最基本的工作就是實現對負載均衡裝置、網路裝置、伺服器、儲存裝置、安全裝置、資料庫、中介軟體及應用軟體等it資源的全面監控管理。在應用軟體類的監控工作中，不僅需要有服務程序、埠等監控，還需要有業務、交易層的監控。
全面性的應用監控可以讓故障提前預警，並儲存了影響應用執行環境的資料，以縮短故障處理時間。
3、從監控告警上完善
完善的監控策略需要有清晰的監控告警提示，值班人員要以根據監控告警即可作出簡單的問題定位與應急處理方案。比如類似以下的監控簡訊：
管理員可以通過簡訊內容看到哪個系統、哪個應用、哪個模組出了什麼問題，可能是什麼原因，對業務有什麼影響，是否需要馬上處理（比如凌晨出現此預警是否可以延遲到次日處理）等資訊。
4、從監控分析上完善
完善的監控策略不僅需要有實時的資料告警，也要有彙總資料的分析告警,實時資料分析的告警的重要性不用多說，對於彙總分析的資料則能發現潛在風險，同時也為分析疑難雜症提供幫忙。
5、從監控主動性上完善
監控不僅僅是報警，它還可以做得更多，只要我們想辦法賦予它主動解決事件的規則，它便有為管理員處理故障的能力。
三、應急方案
提前制定好故障應急方案是很有必要的，但在日常工作過程中我們的應急方案遇到一些問題：
針對上述常見問題，應急方案需要做到以下幾點：
1、內容精簡
很多人可能會認為故障出現的形式各種各樣，所以應急方案需要涉及到方方面面。但實際的故障處理過程中，我們可以發現其實我們的應急措施往往重複使用幾個常用的步驟，所以我認為應急方案要有重點，如果乙個應急方案可以應對平時故障處理80%的場景，那這個應急手冊應該是合格的。過於追求影響應用系統方方面面的內容，會導致這個方案可讀性變差，最終變更乙個應付檢查的文件。以下是我覺得應用系統應急方案應該有的內容：
1）系統級
能知道當前應用系統在整個交易中的角色，當前系統出現問題或上下游出現問題時，可以知道如何配合上下游分析問題，比如：上下游系統如何通訊，通訊是否有唯一的關鍵字等。
另外，系統級裡還涉及一些基本應急操作，比如擴容、系統及網路引數調整等。
2）服務級
能知道這個服務影響什麼業務，服務涉及的日誌、程式、配置檔案在**，如何檢查服務是否正常，如何重啟服務，如何調整應用級引數等。
3）交易級
能知道如何查到某支或某類交易出現了問題，是大面積、區域性，還是偶發性問題，能用資料說明交易影響的情況，能定位到交易報錯的資訊。這裡最常用的方法就是資料庫查詢或工具的使用。
知道最重要的交易如何檢查是否正常，重要的定時任務的應急處理方案，比如開業、換日、對賬的時間要求及應急措施。
4）輔助工具的使用
有時候，需要借助一些工具或自動化工具輔助分析並應急，這時需要有輔助工具如何使用的方法。
5）溝通方案
溝通方案涉及通訊錄，包括上下游系統、第三方單位、業務部門等渠道。
6）其它
上述5點內容如何都完備，相信這個應急手冊己可以解決80%的故障恢復工作。
2、應急方案是一項持續的工作
有了應急方案，如何讓運維人員持續去更新是難點。我認為要解決這個難點，需要先讓運維人員經常使用這個手冊。如果乙個手冊沒有場景可以用，那就需要管理者為運維人員創造機會去使用這個手冊，比如應急演練。
3、關注運維人員對應用關鍵資訊的認識
前兩點關注了手冊，最後一點我覺得有必要關注使用這個手冊的人。有些運維人員認為應用運維人員沒有能力去把應用系統本身的內容了解得很透徹，所以應用運維人員在故障處理過程中的地位很尷尬，運維人員掌握操作權，但卻不知道應該操作什麼。
對此，我認同應用運維人員不需要掌握應用系統的業務功能，但我覺得就對應用系統本身來講應用運維人員需要具備以下最基本的能力：
四、智慧型化事件處理
處理方法如下圖（詳細的智慧型化涉及監控、規則引擎、配置工具、cmdb、應用配置庫等模組協同工作）。
近期熱文推薦：
1.1,000+ 道 j**a面試題及答案整理(2022最新版)
2.勁爆！j**a 協程要來了。。。
3.spring boot 2.x 教程，太全了！
4.20w 程式設計師紅包封面，快快領取。。。
覺得不錯，別忘了隨手點讚+**哦！
服務端解決故障的處理思路
簡單記錄一下解決伺服器故障的思路，以便今後迅速定位問題。1 出錯一般來說是兩種情況 1 邏輯出錯了 2 傳入引數出錯了 2 在上述情況都正確的情況下，那麼業務邏輯可能是正常執行了。這時錯誤可能就是其他原因 1 出錯的 在別的地方 2 rpc呼叫超時 3 盡可能搞清楚問題的前因後果，不要一下子就扎到伺...
熊掌號 據說這篇文章能解決80 的收錄疑惑
資料收錄的誤區在 最近我們可愛的客服反饋經常收到這樣的問題 資料到底有沒有被收錄，去 能看到？為什麼我的熊掌號收錄成功了，但是在熊掌號首頁沒有展現呢？熊掌號頁面收錄成功了，但是為什麼顯示的是百家號內容呢？鑑於問題關注度比較高，菁菁今天在這裡回覆一下大家的問題，歡迎大家分享給身邊存有同類問題的朋友們 ...
解決網頁瀏覽故障的一般思路
無法瀏覽網頁是上網最常見的故障之一，其具體原因比較複雜，解決的方法也不盡相同。結合工作經驗，我想就解決這個問題的思路談點個人看法 我的習慣思路是 先軟再硬後系統，先簡單後複雜，折半查詢縮小故障範圍。具體有以下幾個主要步驟 第一步 排除偶然的 不可預見性故障 不管三七二十一，先冷啟動電腦及數據機，排除...