【作者】彭華盛，騰訊TVP，10年+的金融領域運維工作，期間負責參與運維組織、流程、工具建設，包括重大業(yè)務系統(tǒng)與數(shù)據(jù)中心工程性項目實施，標準化工作流程構建，平臺工具體系的規(guī)劃與研發(fā)、數(shù)字化轉型研究與實施相關等，對金融領域的運維有較全面理解，更多信息可見其個人公眾號“運維之路”。
TBF（無故障時長）和TTR（故障修復時長）是業(yè)務連續(xù)性管理兩個重要指標，故障處置管理的目標就是為了最大限度的增加TBF和縮短TTR。在具體管理中，我們通常會根據(jù)故障應急處置時間軸擴展以下指標：MTBF（無故障時長）、MTTI（平均故障發(fā)現(xiàn)時長）、MTTK（故障定位時長）、MTTF（平均故障處理時長）、MTTR(平均故障響應時長)，MTTF(平均故障恢復時長)的思路，從故障發(fā)生時間、發(fā)現(xiàn)時間、響應時間、嘗試處置時間、診斷時間、生效應急處置開始時間、故障恢復時間等梳理應急處置的關鍵節(jié)點。通常，MTTI=發(fā)現(xiàn)時間-發(fā)生時間；MTTR=響應時間-發(fā)現(xiàn)時間；MTTK=定位時間-發(fā)現(xiàn)時間；MTTF=恢復時間-定位時間。
面對不斷復雜的生產(chǎn)環(huán)境，要增加TBF和縮短TTR的目標，需要圍繞“故障發(fā)現(xiàn)、故障響應、故障定位、故障恢復”四個關鍵環(huán)節(jié)，在人員技能、協(xié)同機制、工具平臺、數(shù)字化感知等方面進行統(tǒng)籌建設。
一、故障發(fā)現(xiàn)
故障發(fā)現(xiàn)指生產(chǎn)故障或潛在風險被監(jiān)控等機器或運維人員發(fā)現(xiàn)的過程，重點關注發(fā)現(xiàn)及時性。從故障發(fā)現(xiàn)角度看，主要包括監(jiān)控發(fā)現(xiàn)、協(xié)同發(fā)現(xiàn)、數(shù)據(jù)運營三個方式。良好運維組織的故障發(fā)現(xiàn)應該大部分來自監(jiān)控等自動化手段，甚至對一些確定性很強的故障進行自愈行為。其次，當前故障處置過程是一個多角色協(xié)同的場景，構建在線協(xié)同網(wǎng)絡有助于提升協(xié)同效率，基于協(xié)同網(wǎng)絡建立高效的信息傳遞是當前提升故障發(fā)現(xiàn)能力的重要手段。另外，隨著系統(tǒng)復雜性不斷提高，運維組織也在推動數(shù)據(jù)運營分析工作，主動的基于數(shù)據(jù)運營推動故障發(fā)現(xiàn)將是一個有力補充。
1.監(jiān)控發(fā)現(xiàn)
從人機協(xié)同角度看運維管理，監(jiān)控相當于給運維團隊分配了成千上萬上機器人，這些機器人駐扎在硬件、平臺軟件等對象中，7*24不間斷的采集指標數(shù)據(jù)，并將指標的異常情況實時推送出來。監(jiān)控已經(jīng)是發(fā)現(xiàn)潛在風險或異常的源頭，推動監(jiān)控發(fā)現(xiàn)的覆蓋面、準確率、告警觸達能力的提升，是縮短故障發(fā)現(xiàn)時長的關鍵舉措。以下從被動監(jiān)控、上帝視角、主動撥測三個角度分析如何提升監(jiān)控發(fā)現(xiàn)能力。
1）被動監(jiān)控
此處強調(diào)“被動”監(jiān)控是為了區(qū)別主動監(jiān)控，指代傳統(tǒng)在基礎設施、硬件資源、平臺軟件、應用可用性、客戶體驗多個層級的監(jiān)控管理，以及統(tǒng)一的監(jiān)控告警管理。這類監(jiān)控方案通常是針對已知異常環(huán)節(jié)，采集指標數(shù)據(jù)，配置監(jiān)控策略，以及觸發(fā)策略后將監(jiān)控告警統(tǒng)一推送到統(tǒng)一告警系統(tǒng)。
對于源端監(jiān)控端強調(diào)“不漏報、少誤報”，實施上關注平臺能力建設與工具運營兩點：監(jiān)控平臺方面采用樂高式組合提升能力，比如缺性能監(jiān)控補充APM、NPM，提升監(jiān)控覆蓋面；工具運營方面采用數(shù)據(jù)與機制運營推動，監(jiān)控策略需要運維人員在工作過程中，結合企業(yè)系統(tǒng)的實際特點，在平臺通用監(jiān)控策略上持續(xù)的豐富針對性策略，運維組織需要建立事件或任務觸發(fā)機制，比如事件復盤對監(jiān)控發(fā)現(xiàn)能力的分析，并通過主動的監(jiān)控評審、監(jiān)控告警數(shù)據(jù)分析等運營工作發(fā)現(xiàn)哪些系統(tǒng)監(jiān)控監(jiān)控的覆蓋面與誤報情況。
2）上帝視角
傳統(tǒng)被動性的監(jiān)控管理是針對已知異常，進行補丁式的增強監(jiān)控的方式持續(xù)完善的過程。但運維面臨三個困難，一是隨著架構復雜性越來越高，運維組織面臨越來越多的的未知的故障；二是數(shù)據(jù)量與風險觸發(fā)因素增強后，單維指標監(jiān)控監(jiān)控能力不足，而多維指標讓人配置又面臨無法窮舉的問題；三是運維對于故障發(fā)現(xiàn)已經(jīng)在可用性故障基礎上，增加了功能邏輯、數(shù)據(jù)類故障的發(fā)現(xiàn)要求，對于日志、鏈路的監(jiān)控發(fā)現(xiàn)能力要求越來越高。
提出上帝視角是運維組織需要借助算法、海量數(shù)據(jù)、平臺能力，構建一個全數(shù)字化監(jiān)控感知的能力。這種感知能力需要盡量減少運維打補丁式的增加細化的指標策略，利用算法能力加深感知監(jiān)控深度，利用海量數(shù)據(jù)加大感知監(jiān)控廣度，利用平臺加快感知監(jiān)控的速度與窮舉的能力。當然，當前這種上帝視角對監(jiān)控發(fā)現(xiàn)的準確率、覆蓋面仍需要一個提升的過程，應該作為傳統(tǒng)監(jiān)控的一個補充手段，而非替代。
3）主動撥測
主動撥測監(jiān)控是采用模擬用戶訪問終端、域名、頁面URL、功能、API等，從客戶視角監(jiān)測功能可用性、感知用戶端體驗、檢測網(wǎng)絡鏈路質(zhì)量，系統(tǒng)事務可用性，領先一步發(fā)現(xiàn)問題，提升客戶體驗。在企業(yè)推動以客戶體驗為中心的數(shù)字化轉型中，撥測是監(jiān)控發(fā)現(xiàn)的一種有力補充。借助機器不間斷、自動化執(zhí)行，提前設計好撥測執(zhí)行的腳本步驟，可幫助運維執(zhí)行更細粒度的功能操作，主動獲取應用運行的性能體驗指標，更準確地了解客戶訪問業(yè)務功能級的體驗，以及應用層及網(wǎng)絡層性能。同時，站在故障處置角度看撥測，當發(fā)生異常時將執(zhí)行過程進行截圖留痕，還可以輔助快速定位問題。
在撥測的解決方案中，通常包括公有云或私有化撥測方案，前者是通過撥測運營商提供部署在世界或全國各地的撥測源進行測試，用戶不需要管理撥測終端，只要根據(jù)SLA明確的時效性、次數(shù)等付費，就可以獲得撥測結果。私有化部署的撥測方案則運維組織管理撥測涉及的服務器、終端設備等環(huán)境。運維組織可以根據(jù)政策、風險、成本等維度考慮選擇不同的解決方案。
2.協(xié)同反饋
雖然我們希望故障盡量由機器自動化發(fā)現(xiàn)，但是隨著基礎架構、應用邏輯、業(yè)務邏輯越來越復雜，系統(tǒng)一個小模塊異常都可能導致系統(tǒng)自身甚至關聯(lián)系統(tǒng)的業(yè)務連續(xù)性故障，建立一個在線的協(xié)同網(wǎng)絡，提升協(xié)同節(jié)點中業(yè)務、客戶、同業(yè)、開發(fā)、測試等團隊的反饋的效率，仍然是故障發(fā)現(xiàn)的有力手段。
1）業(yè)務、客戶、同業(yè)反饋
理想情況下，應盡量減少由業(yè)務與客戶側反饋的故障發(fā)現(xiàn)占比。但是現(xiàn)實中仍有部分故障，當前監(jiān)控或運營分析比較難實時發(fā)現(xiàn)，比如功能邏輯性、數(shù)據(jù)準確性等類別，這些故障雖然不會帶來全局性的可用性故障，但是站在以客戶為中心角度，此類故障對個別或部分客戶屬于可用性故障，尤其是對公重要客戶或權益類交易故障。針對這類故障，運維要提前建立一個高效的信息反饋的渠道，基于用戶旅程梳理并建立全線上化的問題反饋是一個好的選擇，比如：將問題反饋整合在業(yè)務系統(tǒng)中，系統(tǒng)可以獲得快速獲知用戶反饋問題的熱點信息，并通知運維處理；建立全線上化的服務臺、一線、二線的問題處理流程，問題反饋的業(yè)務人員可以在線獲知問題處理進度，機器可以根據(jù)問題反饋時長進行線上督辦。另外，在企業(yè)內(nèi)部建立必要的信息系統(tǒng)即時通訊溝通群，方便公司內(nèi)業(yè)務人員的即時反饋，安排相應的問題服務崗位正在被很多運維組織接受。
同業(yè)反饋是針對同類業(yè)務事故的一個比較好的方法。比如，銀行里涉及人行結算中心、銀聯(lián)、第三方支付、通信運營商等；券商里涉及的交易所、銀行、通信運營商、重點廠商等，通常事故會有一定的共性，如能建立實時的故障信息互通互聯(lián)的渠道，將有助于故障發(fā)現(xiàn)、定位、恢復決策與執(zhí)行。參考前面提到的企業(yè)內(nèi)容信息系統(tǒng)問題反饋的即時通訊群，提前建立行業(yè)間的即時通訊溝通群也很有必要，在預案中提前確定關注、咨詢的溝通預案步驟與責任人是一個有效的方法。
2）開發(fā)或測試發(fā)現(xiàn)
開發(fā)或測試發(fā)現(xiàn)的故障是一個邊界比較難界定，但又不可忽視的故障發(fā)現(xiàn)方式。邊界難界定，有一些客觀原因，比如很多系統(tǒng)或變更是帶缺陷上線，這些缺陷本身在生產(chǎn)運行中會觸發(fā)故障條件；很多線上的問題，如果是業(yè)務反饋，可能會先到達開發(fā)人員，由于故障通常在組織內(nèi)會被用于質(zhì)量考核，部分開發(fā)人員可能延遲問題的反饋。不可忽視，前面已經(jīng)提到開發(fā)與測試反饋的故障，由于個體的重視程度或主觀因素，可能導致故障處置的及時性。
這里暫不探討故障涉及的考核方式，但是建議在流程中建立線上化的問題反饋閉環(huán)，比如在變更環(huán)節(jié)，制定緊急變更類型，這類變更與一般需求變更區(qū)別，緊急變更的變更ID由線上化的運維問題單分配，緊急變更支持更高優(yōu)先級的上線支持。再比如建立線上存量缺陷的管理，包括缺陷觸發(fā)條件、缺陷影響、缺陷計劃修復時間，將部分中高風險的缺陷轉為生產(chǎn)問題管理，并定期對線上存量缺陷問題進行復盤管理。
3.數(shù)據(jù)運營
數(shù)據(jù)運營強調(diào)主動的運行分析。主動是當前運維組織轉型的一個重點方向，對應的是當前被動響應服務請求、需求工單、監(jiān)控告警、生產(chǎn)故障的工作模式。數(shù)智萬物的運維世界為主動分析提供了數(shù)據(jù)原材料與平臺賦能支持。
1）常規(guī)巡檢
本節(jié)的巡檢針對常規(guī)的例行巡檢，在監(jiān)控不斷完善的今天，經(jīng)常會引發(fā)“是否還需要巡檢”或“巡檢是否可以被監(jiān)控替代”的話題。監(jiān)控能代替巡檢，主要思路是因為覆蓋面與機器執(zhí)行力更強角度出發(fā)，由于監(jiān)控覆蓋面越來越廣，且很多巡檢的指標數(shù)據(jù)也來源于監(jiān)控系統(tǒng)，且監(jiān)控執(zhí)行力更好、實時性更強，認為監(jiān)控將代替巡檢。認為巡檢仍是一個必要手段的主要思路是監(jiān)控的覆蓋面與可靠性角度出發(fā)，覆蓋面是指仍有一些重要的點監(jiān)控無法發(fā)現(xiàn)，引入專家經(jīng)驗進行巡檢可以發(fā)現(xiàn)一些疑難雜癥。我的觀點是，要區(qū)分運維組織的職能，對于一些以設備或服務可用性為保障的組織，隨著監(jiān)控與自動化巡檢手段的覆蓋，巡檢將慢慢被機器代替。但如果是需要對業(yè)務層進行保障的團隊，巡檢仍將與監(jiān)控等自動化手段并存，是一個重要手段，一方面是因為監(jiān)控對于業(yè)務層的問題發(fā)現(xiàn)覆蓋面有待提升，另一方面由于業(yè)務層的保障要求運維人員要持續(xù)深入的學習系統(tǒng)，巡檢是運維人員保持必要的學習力、關注度一個手段，尤其像證券行業(yè)這種重點保障開盤、銀行業(yè)的批次清算等時點。
總體來說，巡檢的常規(guī)操作性工作是一個被自動化替代的過程，巡檢內(nèi)容則需要運維專家不斷深入，巡檢的管理機制則需要不斷的固化為巡檢規(guī)則、任務、報告、數(shù)據(jù)感知等解決方案。從技術角度看巡檢，在巡場上可以分為定時巡檢與基于事件驅動的臨時巡檢，實現(xiàn)上通常需要數(shù)據(jù)采集與執(zhí)行的代理（或復用現(xiàn)在的自動化能力），巡檢策略規(guī)則，巡檢任務，巡檢報告、值班管理幾塊內(nèi)容。
2）深度巡檢/分析
深度巡檢/分析，我更傾于命名為深度巡檢，因為巡檢意味著例行工作任務，對于運維數(shù)據(jù)例行的深度分析將是主動運營工作一個轉變。一個潛在問題的觸發(fā)，通常觸發(fā)三種策略：診斷誤報并取消，潛在風險掛起，發(fā)起故障響應流程。與常規(guī)巡檢針對線上問題的即時反饋并發(fā)起故障響應流程，深度巡檢主要是針對潛在風險的發(fā)現(xiàn)或預測。深度巡檢通常從分析牽頭方看，通?？赡馨▋深?，一類是由運維組織內(nèi)專家發(fā)起的主動性的運行分析；另一類是通常商務合同要求供應商定時執(zhí)行的深度巡檢。
深度巡檢分析的主題應該關注影響業(yè)務連續(xù)性的風險點，比如應用及數(shù)據(jù)庫等平臺軟件性能容量、容災/應用架構高可用、應用邏輯缺陷、數(shù)據(jù)質(zhì)量、高可用有效性、應急方案、技術保障方案、數(shù)據(jù)備份、數(shù)據(jù)丟失、監(jiān)控發(fā)現(xiàn)及時性等。在實施上，要區(qū)別于常規(guī)巡檢，更加深入分析。同時，深度巡檢最好是一項聯(lián)合運維組織硬件及系統(tǒng)軟件運維人員、第三方軟硬件廠商、應用系統(tǒng)維護人員等人員協(xié)同進行的深度分析工作，要建立線上化的協(xié)同機制，確保各環(huán)節(jié)的銜接緊密與落實。
3）運行感知
此處指的運行感知與監(jiān)控與巡檢有一些區(qū)別，監(jiān)控與巡檢都是根據(jù)已經(jīng)制定的策略或任務發(fā)現(xiàn)問題并觸發(fā)故障流程，是針對一個個細分點的分析，運行感知是一個面的分析。運行感知是從運維專家視角，感知運維對象的運行狀況，需要從感知面與感知策略制定感知方案。在感知面上，要廣泛使用運行數(shù)據(jù)，將影響運維對象運行的數(shù)據(jù)指標化，比如基礎設施層的網(wǎng)絡鏈路延時、丟包率等，平臺軟件層的響應時間、資源負載等，應用系統(tǒng)層的端口監(jiān)聽、JVM內(nèi)存利率等，業(yè)務及體驗層的交易成功率、頁面加載錯誤率等，也就是說只要與運行對象相關的關鍵運行狀況的數(shù)據(jù)都要指標化。在感知策略上，要善用基線的策略，比如偏離度，制定同比、環(huán)比、首筆出現(xiàn)等，或引入一些AIOps的算法獲得更加有效的基線。
在實現(xiàn)上，運行感知不僅僅獨立存在的實時運行看板，還應該與當前主干的運維流程結合在一起，才能不斷的加深感知面與感知策略的深度。比如，將運行感知與巡檢的定時任務結合在一起，要求每天都分析感知數(shù)據(jù)；將運行感知的異常數(shù)據(jù)推送到監(jiān)控告警系統(tǒng)，融入到監(jiān)控處理的流程中；將運行感知融入到故障診斷的環(huán)節(jié)，作為問題診斷、影響分析的一個工具。隨著運行數(shù)據(jù)分析能力的提升，運行感知在故障發(fā)現(xiàn)環(huán)節(jié)中將起到越來越重要的角色。
二、故障響應
故障響應指故障發(fā)現(xiàn)后機器或運維人員介入應急處理的過程。相比故障發(fā)現(xiàn)、定位、恢復，故障響應環(huán)節(jié)對協(xié)同的順暢要求更高，通?？梢試@應急協(xié)同、告警觸達、影響分析3方面進行建設。其中對故障影響初步判斷是一個難點，考驗運維人員的故障識別能力，不僅要求有基本的應急技能，還要對系統(tǒng)有深刻的理解。另外，在故障響應過程中，系統(tǒng)故障受理人，關聯(lián)上下游系統(tǒng)運維人員，值班經(jīng)理等各個角色的作用都尤其重要，需要不斷的練習、實戰(zhàn)來提升協(xié)同順暢性。
1.應急協(xié)同
在降低故障處置過程中TTR時間過程中，故障響應是最容易被忽視，但又可以占用最長時間的環(huán)節(jié)。很多運維組織會制定“故障先報告后處理的”要求，其中一個考慮因素就是要加快故障的響應速度，以免延誤戰(zhàn)機。應急協(xié)同的管理是故障響應的關鍵舉措，以下從ECC管理、信息在線、服務臺三點對應急協(xié)同進行介紹。
1）ECC管理
ECC又叫總控中心，或監(jiān)控指揮中心，是成熟運維組織對運行監(jiān)控、現(xiàn)場值班、聯(lián)絡調(diào)度、事件處置等職責的日常工作場所。從人看，ECC主包括：值班經(jīng)理、流程經(jīng)理、一線運維、二三線條線專家、服務臺（也可以將服務臺歸到一線運維）等崗位。從ECC形態(tài)看，ECC通常是一個獨立的房間，里面有值班與應急需要的設備。在對于單個主數(shù)據(jù)中心的運維組織中，ECC里面值班的人員包括所有運維團隊的值班人員，是公司最核心的應急處置場所，做好ECC管理是加快應急協(xié)同的最重要措施。
從故障響應看，ECC定位應急指揮中心的角色，需要制定一些工作機制。比如制定一線值班的工作職責，處理監(jiān)控事件、應急響應與處置、問題咨詢的解答、變更工單處理等，明確的工作職責有助于值班人員專注最重要的工作，提升故障響應的及時性。再比如落實好應急環(huán)境準備，里面要有運行情況的大屏，一線運維需要的辦公終端，二線現(xiàn)場支持時需要的終端，用于應急使用的日志、運行數(shù)據(jù)、監(jiān)控報警的工具系統(tǒng)，用于對故障臨時決策討論的房間，以及一些聯(lián)絡的通訊設備，故障定級、分析、聯(lián)絡人員的文檔。
2）信息在線
由于信息的復雜性越來越高，一個業(yè)務關聯(lián)的設備與系統(tǒng)越來越多，應急管理是一個多團隊協(xié)同的工作，充分保持故障過程中的信息在線是一個重要舉措。從故障響應角度看信息在線，又可以分解為協(xié)同在線、數(shù)據(jù)在線、工具在線。
協(xié)同在線指故障處置過程的線上化，比如故障處置過程中涉及監(jiān)控報警或工單轉化故障、故障通報、故障升級、故障定位、故障恢復、應急集結等環(huán)節(jié)線上化。從故障響應角度看協(xié)同在線，重點關注面的轉化故障、故障通報、應急集結、故障升級幾個步驟。其中故障集結是對故障關聯(lián)人員的即時觸達，或要求相關人員到達ECC現(xiàn)場參與應急，可以借助全自動化手段或半自動的手段。要做好以上協(xié)同在線，需要提前做好協(xié)同機制，并進行演練，減少實際故障過程中的溝通成本。
數(shù)據(jù)在線指將故障處置過程需要的數(shù)據(jù)在線化，讓參與故障響應的人員可以方便的獲取數(shù)據(jù)，提升并發(fā)處理故障的能力。數(shù)據(jù)在線關注要提前準備哪些數(shù)據(jù)，數(shù)據(jù)如何讓參與處理故障的專家方便看，如何方便專家獲得數(shù)據(jù)，如何獲得故障進度。在數(shù)據(jù)方面，關注與故障涉及對象的故障數(shù)據(jù)，比如運行對象負載、性能、關鍵運行指標、服務狀態(tài)與數(shù)據(jù)、近期變更、監(jiān)控告警、上游系統(tǒng)狀況等。要讓專家方便看數(shù)據(jù)，要提前將相關數(shù)據(jù)以服務化方式提供給運維以外的團隊，或進行桌面演練與混沌工程工作。要方便獲取數(shù)據(jù)，則需要建立線上化的運維數(shù)據(jù)服務門戶，一站式開放數(shù)據(jù)。要即時獲知故障處理進度，則要讓故障進度及時通告，并線上化觸達關聯(lián)人員。
工具在線與數(shù)據(jù)在線類似，只是數(shù)據(jù)關注提前落地好關鍵指標的數(shù)據(jù)，工具則關注提供一個更靈活的功能集合，比如日志查詢工具、數(shù)據(jù)庫查詢工具等。
3）服務臺
ITIL對服務臺定位是連接用戶和IT部門的唯一信息交換平臺，它起雙向信息反饋作用，并且與多個服務管理流程密切相關，為用戶提供與問題、變更、服務級別、發(fā)布、配置、IT服務持續(xù)等管理流程的接口?；诖?，IT服務臺承擔了故障發(fā)現(xiàn)、故障響應、故障解釋等工作，方便用戶方便快速地獲得故障處理進度，讓運維應急專家專注應急響應，減少溝通解釋的工作。
在不同行業(yè)中，IT服務臺的能力起到的作用不同，比如一些大型制造業(yè)，服務臺一天可能會受理成千上萬的服務工單，這些企業(yè)的服務在故障響應過程中起來極為關鍵的作用。要更好的支持服務臺能力的提升，服務臺應該提供快速響應IT部門內(nèi)部呼叫涉及的渠道工具、在線的工單分派、工單級別升級等工具，讓服務臺工單處理全在線。比如一個涉及故障的工單的過程：請求登記、故障匹配（知識庫或經(jīng)驗）、故障分派、跟蹤狀態(tài)與反饋故障處理狀況、故障與應急方案解釋、故障解決、客戶或業(yè)務溝通。要提升故障響應效率，服務臺是一個很關鍵的角色，需要通過提升線上化與自動化能力為服務臺賦能。
2.告警觸達
對于告警觸達，強調(diào)“統(tǒng)一、高響應”。統(tǒng)一指全公司的監(jiān)控的監(jiān)控告警需要實時匯總于一個告警系統(tǒng)，由這個告警系統(tǒng)進行告警的整合、收斂、豐富、升級、觸達處理人或機器。高響應則需要推動告警觸達人或機器后，針對告警能得到快速的應急動作，要實現(xiàn)高響應需要即時知道哪些告警處理發(fā)生后沒有響應，或響應了但是長時間未關閉，對這類告警實時進行再次觸達或升級，并定期對低響應的運維對象（人、系統(tǒng)、機器等）進行排名公示。
1）統(tǒng)一告警
下面這個統(tǒng)一告警歸納圖是我?guī)啄昵罢恚F(xiàn)在看起來仍然是一個比較完整的產(chǎn)品功能圖。站在故障響應角度看統(tǒng)一告警，需要關注是否所有監(jiān)控告警都進行了集中，是否從告警風暴角度對告警進行收斂，是否從告警定位角度看對告警進行豐富關聯(lián)，監(jiān)控告警是否與故障處置線上化系統(tǒng)線上化打通等。具體的內(nèi)容在監(jiān)控專項的文章中有提及，本節(jié)不作過多的介紹。
2）告警描述
從我的個人經(jīng)歷看，告警描述是一個很重要的環(huán)節(jié)，尤其是對于ECC值班的工作。但遺憾的事，好像對于告警描述，大家關注得不太夠。我引用一段之前寫過的內(nèi)容：
完善的監(jiān)控策略需要有清晰的監(jiān)控告警提示，值班人員要以根據(jù)監(jiān)控告警即可作出簡單的問題定位與應急處理方案。比如類似以下的監(jiān)控短信：22時，【理財應用系統(tǒng)】中【應用服務器LC_APPsvrA 10.2.111.111】的【前置應用模塊】出現(xiàn)【應用端口：9080】不存在，該端口作用【提供理財應用處理（負載均衡部署）】，原因可能為【SERVER1服務異常停止】，監(jiān)控系統(tǒng)己進行以下應急處理【自動執(zhí)行端口進程啟動】，該事件緊急程度【高】。管理員可以通過短信內(nèi)容看到哪個系統(tǒng)、哪個應用、哪個模塊出了什么問題，可能是什么原因，對業(yè)務有什么影響，是否需要馬上處理（比如凌晨出現(xiàn)此預警是否可以延遲到次日處理）等信息。
3）告警升級
告警已經(jīng)成為最為關鍵的故障發(fā)現(xiàn)渠道，提升故障響應需要提升監(jiān)控告警的升級機制。要升級，要先分級，運維組織可能根據(jù)實際情況對級別進行劃分，我建議告警的分級應該結合應急響應機制進行分級，如果組織的精細化程度還沒那么高不要分太多級，比如分為三級：一級對應高響應的告警，二級是對客戶或業(yè)務有影響的告警，三級是潛在風險但未對客戶產(chǎn)生影響。制定了告警分級，下一步是將告警響應線上化，系統(tǒng)可以針對告警響應的時長，進行升級。對于高風險的告警，升級可以通過觸達方式的升級，比如先用短信通知，不及時用電話通知，或通過大屏的色彩，或觸達處理人上司與值班經(jīng)理，或按級別推送到團隊的IM群中進行公示。對于低風險級別的告警，長時間不響應的低級別告警，可以升級為高風險級別的事件，并根據(jù)高風險級別告警進行告警觸達。
3.影響分析
在故障處理過程中，運維人員很容易鉆進故障定位與恢復環(huán)節(jié)，但要加強故障響應的協(xié)同效率，讓應急協(xié)同中的決策者、值班經(jīng)理、上下游系統(tǒng)運維、開發(fā)、測試、業(yè)務、服務臺共同參與到應急中，對故障現(xiàn)象與影響面的描述必不可少。同時在處理故障前，故障現(xiàn)象直接決定故障應急方案的制定，這依賴于運維人員需要對應用系統(tǒng)的整體功能有一定的熟悉程度，清晰的故障影響面描述，有助于資源的準確調(diào)配。
1）關鍵指標
遺憾的是故障影響面有時很難判斷，尤其是在應急的那個爭分奪秒的時刻，要準確判斷故障影響面需要具備對應用架構、業(yè)務功能等有綜合能力的專家。針對短時間很難快速判斷影響面的問題，提前做好準確性工作是一個比較好的方向。比如提前對影響業(yè)務系統(tǒng)、平臺軟件、基礎設施等層面的運維對象進行分析，對影響這些對象的關鍵KPI指標進行提前定義。所謂的關鍵指標，是指衡量系統(tǒng)運行情況的可量化的數(shù)據(jù)，比如性能管理中常提到的交易量、成功率、延時等指標數(shù)據(jù)。這類指標數(shù)字不要求很多，但要求指標能能反映故障產(chǎn)生的影響面，可參考故障定級、業(yè)務影響程度、上下游依賴等角度去定義指標。制定了關鍵指標后，接下來要解決的是讓關鍵指標在線、可觀察，要讓應急協(xié)同的參與人都能快速的獲知關鍵指標的實時運行的數(shù)字。關鍵指標能夠讓運維專家，尤其是故障協(xié)調(diào)的決策層快速判斷故障級別，并針對級別進行資源的調(diào)配。
2）具體影響
關鍵指標的獲知可以更加準確的調(diào)配應急資源，判斷是否啟動應急集結的響應機制，具體影響面的分析則通常需要故障處理現(xiàn)場的臨時分析決策。在故障響應環(huán)節(jié)賦能具體影響的分析，通常需要提前提升運維專家技能，讓運維專家加深對系統(tǒng)的理解，比如：系統(tǒng)架構、上下游關系、應用服務、應用日志、關鍵數(shù)據(jù)庫表、關鍵參數(shù)配置、主要的業(yè)務流程等信息。為專家提供方便的工具也是提升影響分析的賦能手段，比如：日志、感知等工具。另外，建立在線的協(xié)同機制，讓應急協(xié)同的各方在線將各環(huán)節(jié)（上下游系統(tǒng)、開發(fā)代碼排查、測試復現(xiàn)、業(yè)務分析等）的分析信息同步出來也是提升具體影響的方法。
三、故障定位
故障定位指診斷故障直接原因或根因，故障定位有助于故障恢復動作更加有效。故障定位通常是整個故障過程中耗時最長的環(huán)節(jié)，故障定位的目的強調(diào)快速恢復的基礎上，而非尋找問題根因，后者由問題管理負責。通常大部分可用性故障，要借助運維專家經(jīng)驗的假設判斷或已知預案的執(zhí)行得到解決，但仍有部分故障，尤其是性能、應用邏輯、數(shù)據(jù)故障需要多方協(xié)同與工具支持。故障定位的方法通常包括專家經(jīng)驗驅動的假設嘗試、測試復現(xiàn)、預案啟動、代碼分析四種，這個過程涉及對日志、鏈路、監(jiān)控、數(shù)據(jù)感知、知識管理五類工具。隨著系統(tǒng)復雜性不斷提升，依靠專家經(jīng)驗驅動的假設嘗試準確率會下降，如何將數(shù)字化手段結合專家經(jīng)驗，融入到協(xié)同機制中，這考驗故障定位場景的設計水平。
1.定位方法：
1）專家經(jīng)驗驅動的假設嘗試
2）已知預案啟動
3）測試復現(xiàn)
4）代碼分析
2.定位工具：
1）日志
2）鏈路
3）監(jiān)控
4）數(shù)據(jù)感知
5）知識管理
四、故障恢復
故障恢復指恢復業(yè)務連續(xù)性的應急操作，很多故障是在不斷嘗試驗證解決恢復的動作，所以故障恢復環(huán)節(jié)與故障定位環(huán)節(jié)有一定的交疊，或在這兩個環(huán)節(jié)之間不斷試錯的循環(huán)，即故障恢復操作可能和故障診斷是同時，也可能是診斷之后或診斷之前。在故障恢復中我們通常采用已知預案下的恢復三把斧：“重啟、回切、切換”、自動或手動觸發(fā)系統(tǒng)架構高可用策略、臨時決斷的恢復動作，以及恢復后的信息傳遞。
1.已知預案下的恢復三把斧
（重啟，回切，切換）
2.啟用架構高可用策略
（隔離，限流，降級，熔斷）
3.臨時決斷恢復
（發(fā)布、調(diào)參、修數(shù)）
4.恢復后信息傳遞
（驗證、信息通報）
