2021年05月19日
在講解事件、故障處理思路前，先講一個故障場景（以呼叫中心系統(tǒng)作為一例子）：
業(yè)務人員反映呼叫中心系統(tǒng)運行緩慢，部份電話在自助語言環(huán)節(jié)系統(tǒng)處理超時，話務轉人工座席，人工座席出現(xiàn)爆線情況。
運維人員開始忙活了，查資源使用情況、查服務是否正常、查日志是否報錯、查交易量還有沒有……時間不知不覺的在敲鍵盤、敲鍵盤、敲鍵盤中過去，但是原因還未定位。
經理過來了解情況：“系統(tǒng)恢復了嗎？”、“故障影響是什么？”、“交易中斷了嗎？”……
運維人員趕緊敲鍵盤，寫sql，看交易量；敲鍵盤，寫命令，看系統(tǒng)資源、情況……
最終，定位到問題原因是其中一個功能沒有控制返回數量，導致內存泄露。
針對這個故障，業(yè)務希望運維能否更快的解決故障的恢復，經理希望制定優(yōu)化呼叫中心故障處理流程，做了以下幾件事：
1、優(yōu)先故障處理過程的時間——”能通過鼠標完成的工作，不要用鍵盤“
2、提前發(fā)現(xiàn)故障，加強監(jiān)控——“技術早于業(yè)務發(fā)現(xiàn)問題，監(jiān)控不僅是報警，還要協(xié)助故障定位”
3、完善故障應急方案——“應急方案是最新的、準確的、簡單明了的”
4、長遠目標：故障自愈——”能固化的操作自動化，能機器做的讓機器做“
下面將從故障常見的處理方法開始介紹，再從故障前的準備工作（完善監(jiān)控、制定應急方案等方式）來解決經理提出的問題，并提出未來解決故障的想法。
1、常見的方法：
1）確定故障現(xiàn)象并初判問題影響
在處理故障前，運維人員首先要知道故障現(xiàn)象，故障現(xiàn)象直接決定故障應急方案的制定，這依賴于運維人員需要對應用系統(tǒng)的整體功能有一定的熟悉程度。
確認了故障現(xiàn)象后，才能指導運維人員初判斷故障影響。
2）應急恢復
運維最基本的指標就是系統(tǒng)可用性，應急恢復的時效性是系統(tǒng)可用性的關鍵指標。
有了上述故障現(xiàn)象與影響的判斷后，就可以制定故障應急操作，故障應急有很多，比如：
服務整體性能下降或異常，可以考慮重啟服務；
應用做過變更，可以考慮是否需要回切變更；
資源不足，可以考慮應急擴容；
應用性能問題，可以考慮調整應用參數、日志參數；
數據庫繁忙，可以考慮通過數據庫快照分析，優(yōu)化SQL；
應用功能設計有誤，可以考慮緊急關閉功能菜單；
還有很多……
另外，需要補充的是，在故障應急前，在有條件的情況需要保存當前系統(tǒng)場景，比如在殺進程前，可以先抓個CORE文件或數據庫快照文件。
3）快速定位故障原因
是否為偶發(fā)性、是否可重現(xiàn)
故障現(xiàn)象是否可以重現(xiàn)，對于快速解決問題很重要，能重現(xiàn)說明總會有辦法或工具幫助我們定位到問題原因，而且能重現(xiàn)的故障往往可能是服務異常、變更等工作導致的問題。
但，如果故障是偶發(fā)性的，是有極小概率出現(xiàn)的，則比較難排查，這依賴于系統(tǒng)是否有足夠的故障期間的現(xiàn)場信息來決定是否可以定位到總是原因。
是否進行過相關變更
大部份故障是由于變更導致，確定故障現(xiàn)象后，如果有應的變更，有助于從變更角度出現(xiàn)分析是否是變更引起，進而快速定位故障并準備好回切等應急方案。
是否可縮小范圍
一方面應用系統(tǒng)提倡解耦，一支交易會流經不同的應用系統(tǒng)及模塊；另一方面，故障可能由于應用、系統(tǒng)軟件、硬件、網絡等環(huán)節(jié)的問題。在排查故障原因時應該避免全面性的排查，建議先把問題范圍縮小到一定程序后再開始協(xié)調關聯(lián)團隊排查。
關聯(lián)方配合分析問題
與第（3）點避免同時各關聯(lián)團隊同時無頭緒的排查的同時，對于牽頭方在縮小范圍后需要開放的態(tài)度去請求關聯(lián)方配合定位，而對于關聯(lián)方則需要有積極配合的工作態(tài)度。
是否有足夠的日志
定位故障原因，最常用的方法就是分析應用日志，對運維人員不僅需要知道業(yè)務功能對應哪個服務進程，還要知道這個服務進程對應的哪些應用日志，并具備一些簡單的應用日志異常錯誤的判斷能力。
是否有core或dump等文件
故障期間的系統(tǒng)現(xiàn)場很重要，這個在故障應急前建議在有條件的情況下留下系統(tǒng)現(xiàn)場的文件，比如CORE\DUMP，或TRACE采集信息等，備份好一些可能被覆蓋的日志等。
上述是一般性的故障常見的方法，在重大故障或多方處理的故障出現(xiàn)時，往往小范圍的排查不利于快速解決，需要啟動緊急處理的流程，建議可以考慮以下溝通：
召集相關人員
描述故障現(xiàn)狀
說明正常應用邏輯流程
陳述變更
排查進展，展示信息
領導決策
2、完善監(jiān)控
1）從監(jiān)控可視化上完善
完善的監(jiān)控策略需要有統(tǒng)一的可視化操作界面，在制定完善的監(jiān)控策略后，故障處理人員需要能夠快速的看到相應的運行數據，比如：能夠看到一段時間的趨勢、故障期間的數據表現(xiàn)、性能分析的情況等等數據，且這些數據可以提前制定好策略直接推出分析結果給故障處理人員，這樣就大大提高了故障的處理效率，以呼叫中心系統(tǒng)為例，需要提前配置好以下實時交易數據，以便故障定位：
-交易性能數據：平均交易耗時、系統(tǒng)內部模塊交易耗時（IVR交易耗時、接口總線交易耗時）、關聯(lián)系統(tǒng)交易耗時（核心交易耗時、工單系統(tǒng)交易耗時等）
-重要交易指標數據：交易量、IVR交易量、話務量、座席通話率、核心交易筆數、工單等系統(tǒng)交易量
-交易異常情況數據：交易成功率、失敗率、錯誤碼最多交易
-按服務器分析交易數據：按server統(tǒng)計各服務交易處理筆數，交易總耗時
有了以上交易數據，并通過監(jiān)控按一定頻率統(tǒng)計，運維人員在出現(xiàn)故障時，通過鼠標即點擊即可看到故障什么時候開始，是系統(tǒng)內部有問題還是關聯(lián)系統(tǒng)有問題，最突出的交易是哪一支，各服務器交易量是否均衡等情況。
2）從監(jiān)控面上完善
監(jiān)控最基本的工作就是實現(xiàn)對負載均衡設備、網絡設備、服務器、存儲設備、安全設備、數據庫、中間件及應用軟件等IT資源的全面監(jiān)控管理。在應用軟件類的監(jiān)控工作中，不僅需要有服務進程、端口等監(jiān)控，還需要有業(yè)務、交易層的監(jiān)控。
全面性的應用監(jiān)控可以讓故障提前預警，并保存了影響應用運行環(huán)境的數據，以縮短故障處理時間。
3）從監(jiān)控告警上完善
完善的監(jiān)控策略需要有清晰的監(jiān)控告警提示，值班人員要以根據監(jiān)控告警即可作出簡單的問題定位與應急處理方案。比如類似以下的監(jiān)控短信：
22時，【理財應用系統(tǒng)】中【應用服務器LC_APPsvrA 10.2.111.111】的【前置應用模塊】出現(xiàn)【應用端口：9080】不存在，該端口作用【提供理財應用處理（負載均衡部署）】，原因可能為【SERVER1服務異常停止】，監(jiān)控系統(tǒng)己進行以下應急處理【自動執(zhí)行端口進程啟動】，該事件緊急程度【高】。
管理員可以通過短信內容看到哪個系統(tǒng)、哪個應用、哪個模塊出了什么問題，可能是什么原因，對業(yè)務有什么影響，是否需要馬上處理（比如凌晨出現(xiàn)此預警是否可以延遲到次日處理）等信息。
4)從監(jiān)控分析上完善
完善的監(jiān)控策略不僅需要有實時的數據告警，也要有匯總數據的分析告警,實時數據分析的告警的重要性不用多說，對于匯總分析的數據則能發(fā)現(xiàn)潛在風險，同時也為分析疑難雜癥提供幫忙。
5)從監(jiān)控主動性上完善
監(jiān)控不僅僅是報警，它還可以做得更多，只要我們想辦法賦予它主動解決事件的規(guī)則，它便有為管理員處理故障的能力。
3、應急方案
提前制定好故障應急方案是很有必要的，但在日常工作過程中我們的應急方案遇到一些問題：
1）應急方案缺乏持續(xù)維護，缺乏演練，信息不及時、不準確；
2）應急方案過于追求大而全，導致不利于閱讀與使用；
3）應急方案形式大于實際使用效果，方案針對性不強；
4）只關注應急方案的內容，但沒有關注運維人員對方案的理解；
針對上述常見問題，應急方案需要做到以下幾點：
1）內容精簡
很多人可能會認為故障出現(xiàn)的形式各種各樣，所以應急方案需要涉及到方方面面。但實際的故障處理過程中，我們可以發(fā)現(xiàn)其實我們的應急