民生銀行 IT運維故障管理 可視化案例
一、前言
民生銀行 IT 運維工作經(jīng)歷了多年實踐，已經(jīng)建設(shè)了CMDB、IT運維管理系統(tǒng)（流程平臺）、集中監(jiān)控系統(tǒng)、交易性能監(jiān)控系統(tǒng)、自動化運維系統(tǒng)、日志管理平臺等管理工具，并在實際工作中不斷深入的優(yōu)化，在近年還打造了運維大數(shù)據(jù)平臺，用以支撐 IT 運維管理工作。
在日常工作中，監(jiān)（各類監(jiān)控）、管（流程）、控（自動化）和CMDB系統(tǒng)均建立了映射關(guān)系，用以打通各系統(tǒng)的數(shù)據(jù)消費場景。
但實際工作中依然面臨著工具分散，依靠運維人員經(jīng)驗和頻繁切換各專業(yè)分析工具，以實現(xiàn)故障定位、影響分析等操作，運維數(shù)據(jù)消費效率存在進步空間。
二、建設(shè)思路與成果
基于上述背景，民生銀行嘗試借助架構(gòu)管理可視化工具，將配置數(shù)據(jù)（CMDB）、監(jiān)控數(shù)據(jù)（集中監(jiān)控告警、交易性能監(jiān)控）、自動化運維管理工具、IT運維管理系統(tǒng)的變更數(shù)據(jù)整合到 IT 運維架構(gòu)圖上，打造統(tǒng)一的運維數(shù)據(jù)消費場景 - IT運維架構(gòu)管理可視化平臺，行內(nèi)稱之為云圖系統(tǒng)。
在系統(tǒng)建設(shè)之初，我們先定義了四類運維數(shù)據(jù)消費場景，如下圖所示：
下面，我們先對這四個比較具備代表性的場景進行說明：
1.日常監(jiān)控
作為運維人員，每個人都需要對各自負責(zé)系統(tǒng)的運行情況了如指掌。系統(tǒng)本身的各項性能指標可以通過對數(shù)據(jù)庫、中間件、操作系統(tǒng)和網(wǎng)絡(luò)流量分析等監(jiān)控手段實時主動監(jiān)測，系統(tǒng)的交易性能情況則需要通過交易性能監(jiān)控系統(tǒng)進行實時的診斷輸出和告警。
一線值班人員需要打開不同工具的監(jiān)控窗口，實時監(jiān)測系統(tǒng)的告警和異常指標，這些窗口占用了大量的終端資源；
二線運維人員接到異常告警后，也需要打開各個監(jiān)控平臺進行故障判斷和問題定位，往往在登陸和跳轉(zhuǎn)的過程中浪費一定的時間和精力，無法有效滿足“10分鐘定位故障、10分鐘處置恢復(fù)”的“雙十”目標。
通過云圖系統(tǒng)對上述各專業(yè)監(jiān)控工具的數(shù)據(jù)實現(xiàn)高效整合，目前已經(jīng)能夠以應(yīng)用為中心，在統(tǒng)一的頁面上實現(xiàn)上述多種運行狀態(tài)數(shù)據(jù)的呈現(xiàn)，實時同步的顯示告警數(shù)據(jù)和性能數(shù)據(jù)，并與特定場景的可視化相結(jié)合，直觀高效，一目了然。
舉例：圖1是我行網(wǎng)銀互聯(lián)系統(tǒng)發(fā)往工行、農(nóng)行、中行、建行、交行、招行等14家對手行的交易量、響應(yīng)時間、響應(yīng)率和成功率一覽圖，當交易異常告警發(fā)生時，告警會實時掛載在應(yīng)用系統(tǒng)圖標上。
圖1：網(wǎng)銀互聯(lián)至對手機構(gòu)交易情況監(jiān)控
2.排障定位
在日常IT運維工作中，有時會面對一些較復(fù)雜的故障定位場景，比如大量系統(tǒng)幾乎同時涌現(xiàn)高級別告警，這些系統(tǒng)之間依托于各類網(wǎng)絡(luò)，存在著支撐和依賴關(guān)系，而每個系統(tǒng)本身也被復(fù)雜的系統(tǒng)架構(gòu)所承載。
這種情況下，如何在有限的時間內(nèi)定位故障并快速恢復(fù)業(yè)務(wù)，是運維人員面臨的低頻但高風(fēng)險的疑難問題。
對比傳統(tǒng)排障思路，運維人員需要綜合分析這些告警，確定可能的根因。
一般思路是各應(yīng)用系統(tǒng)負責(zé)人分別找數(shù)據(jù)庫、操作系統(tǒng)、中間件、網(wǎng)絡(luò)等團隊確認是否是本系統(tǒng)導(dǎo)致的。
如果不是，則需要通過事前繪制的上下游系統(tǒng)關(guān)系圖梳理可能的根因節(jié)點，再查詢相應(yīng)疑似故障根因系統(tǒng)的架構(gòu)內(nèi)是否存在故障，從而進行進一步處理。
由于相關(guān)工作既存在跨部門溝通，又需要強大的視圖化邏輯思維能力，對運維人員要求極高。
而通過云圖系統(tǒng)，我們可以先通過對應(yīng)用墻的整體查看（如圖2所示），分析各系統(tǒng)告警的分布情況，之后依照經(jīng)驗初步判斷交易關(guān)鍵節(jié)點，點擊鉆取進入應(yīng)用關(guān)系全景圖。
圖2：應(yīng)用墻展示
在圖中可以查看到基于時序的告警、性能指標曲線、近期變更記錄，從而進一步縮小需要深入判斷的故障域；再基于疑似的故障根因節(jié)點鉆取到系統(tǒng)架構(gòu)圖和網(wǎng)絡(luò)拓撲圖，同樣對架構(gòu)圖中對象的告警、變更、性能數(shù)據(jù)進行分析，進一步定位故障源頭（如圖3所示）。
圖3：應(yīng)用交互關(guān)系展示
最后，將自動化操作也集成到相應(yīng)的架構(gòu)圖中，包括一鍵巡檢等操作，縮短大腦思考和逐一登陸各系統(tǒng)消耗的寶貴時間，完成處理后再次對比相應(yīng)架構(gòu)圖中的實時監(jiān)控數(shù)據(jù)，確認故障處理效果。
排障結(jié)束后，還可借助應(yīng)用畫像功能（如下圖4所示），對故障的形成原因及解決方法進行復(fù)盤，制定預(yù)案，為可能的故障二次發(fā)生或次生風(fēng)險提供預(yù)防措施和緊急處理指導(dǎo)意見。
圖4：應(yīng)用畫像展示
3.變更影響分析
在日常的變更管理工作中，分析變更影響，進行變更過程評審是變更管理工作的重點。
就變更影響分析而言，如果CMDB數(shù)據(jù)中的關(guān)系數(shù)據(jù)不夠完善，影響范圍的確認就變得異常艱辛，需要投入更多的經(jīng)驗判斷、多方溝通以及大量思考。
依托于云圖系統(tǒng)，變更影響分析的工作得到了系統(tǒng)化改善。舉例來說，當需要對存儲系統(tǒng)進行維護時，只需要搜索該存儲設(shè)備的任意配置項屬性，便可知道哪些系統(tǒng)與該存儲存在關(guān)聯(lián)關(guān)系，同時還可以鏈接到相應(yīng)的系統(tǒng)架構(gòu)圖，從而進一步了解深層次的影響范圍（如下圖5所示）
圖5：存儲與應(yīng)用影響關(guān)系展示
4.知識共享
知識共享能夠提升人與人之間的協(xié)作和分享能力，發(fā)揮團隊成員的主動性和創(chuàng)造性。舉例來說，基于配置數(shù)據(jù)的架構(gòu)圖，結(jié)合相關(guān)的監(jiān)控信息和變更記錄，可以由專業(yè)二線人員進行場景組裝，并將其分享給ECC一線值班經(jīng)理。
值班經(jīng)理一方面可以通過更易理解的架構(gòu)圖，熟悉所需管理的各類系統(tǒng)情況，還能夠在故障定位時，更易縮小故障域根因范圍，進而向?qū)I(yè)二線傳遞信息，提升整體排障效率。
此外，日常運維中演示匯報是知識共享的場景之一，架構(gòu)圖作為IT管理領(lǐng)域存在共識的表現(xiàn)形式，本身就具備演示匯報的基礎(chǔ)能力。
不論是對新員工培訓(xùn)或與運維備份崗的日常溝通過程中，還是在向業(yè)務(wù)單位介紹IT運維日常工作，又或者是描述一些重要的系統(tǒng)建設(shè)成果。
通過該系統(tǒng)的演示模式都可以有效的提升溝通效率，使整個組織形成知識積累、統(tǒng)一認知、快速分享和實時更新的機制。
圖6：演示匯報大屏模式
三、未來展望
1.可視化AIOps
近年來AIOps的理念逐漸深入人心，Gartner也在監(jiān)管控運維架構(gòu)的基礎(chǔ)上補充了AIOps的核心節(jié)點。作為AIOps，從各類數(shù)據(jù)源匯總成為大數(shù)據(jù)庫，在這個基礎(chǔ)上進行計算、分析、融入算法、增加機器學(xué)習(xí)能力，并最終以可視化供給數(shù)據(jù)消費是已知的發(fā)展路徑。
民生銀行運維大數(shù)據(jù)平臺已經(jīng)建設(shè)完成，目前也已開展與清華大學(xué)智能運維實驗室的合作，將其機器學(xué)習(xí)和算法研究成果投入到生產(chǎn)環(huán)境進行積累和學(xué)習(xí)。
下一步云圖系統(tǒng)將對接智能運維系統(tǒng)的異常監(jiān)測分析數(shù)據(jù)，實現(xiàn)AiOps與IT運維架構(gòu)可視化故障定位的展示能力。
舉例來說，在架構(gòu)圖中呈現(xiàn)的事件信息，除了經(jīng)歷了過濾、壓縮、關(guān)聯(lián)、豐富等操作，還會補充單值標異常檢測系統(tǒng)在性能數(shù)據(jù)中挖掘的系統(tǒng)異常。
比如業(yè)務(wù)系統(tǒng)交易響應(yīng)時長原本定義在100ms生成告警事件，而在異常檢測系統(tǒng)上線后，機器學(xué)習(xí)會基于數(shù)據(jù)特征，在低峰期，即便其響應(yīng)時長只有50ms，也可以發(fā)現(xiàn)系統(tǒng)異常，從而進一步補充事件提醒，結(jié)合云圖系統(tǒng)，實現(xiàn)故障預(yù)警的可視化，進一步提高運維質(zhì)量。
圖7：Gartner監(jiān)管控運維架構(gòu)
2.自動化場景可視化
下一步，系統(tǒng)將實現(xiàn)應(yīng)用發(fā)布及災(zāi)備切換自動化的可視化能力：
應(yīng)用發(fā)布和災(zāi)備切換需要管理的各種資源關(guān)系復(fù)雜，應(yīng)用系統(tǒng)之間依存性高，自動化運維系統(tǒng)的流程管理可以清晰定義以上各種關(guān)系，有力的保障了災(zāi)備系統(tǒng)的服務(wù)質(zhì)量、提高應(yīng)對突發(fā)事件的能力。
與此同時，各部門同事及領(lǐng)導(dǎo)可以通過大屏幕，一目了然的了解流程執(zhí)行情況，使ECC成為統(tǒng)一的“作戰(zhàn)指揮中心”。
3.深入的場景化建設(shè)
基于架構(gòu)圖和各類數(shù)據(jù)的集成，架構(gòu)管理可視化工具已經(jīng)成為了最貼近運維人員的綜合情勢研判工具。
基于此，系統(tǒng)可以做進一步深化，站在運維人員不同的工作場景進行功能深化和數(shù)據(jù)封裝。
舉例而言，故障在很多情況下源于變更，在系統(tǒng)變更前需要對變更進行評審，場景化能力可以在評審前，將變更前后需要關(guān)注的系統(tǒng)架構(gòu)、應(yīng)用交易性能指標、系統(tǒng)和網(wǎng)絡(luò)層面負載指標，以及各應(yīng)用的日志新產(chǎn)生數(shù)量，均封裝在一個頁面上。
當變更日的次日清晨，應(yīng)用運維人員可以自動收到郵件通知，將上述信息進行匯總，點擊后即可打開封裝好上述數(shù)據(jù)和圖形的場景化頁面，從而對變更后的狀態(tài)一目了然，一旦出現(xiàn)問題也可以查看問題表征，并迅速定位上下游影響。
四、總結(jié)
“心靈沒有意象就永遠不能思考”，亞里士多德的這句名言，映射到IT運維管理中，架構(gòu)圖便是心靈意象的一種可視化呈現(xiàn)。
對于IT架構(gòu)圖的規(guī)范化梳理，一方面在IT治理層面保障了運維管理工作可持續(xù)的優(yōu)化；
另一方面隨著架構(gòu)可視化管理的深入，以IT架構(gòu)圖貫穿運維工作思考流的習(xí)慣正在逐漸形成。
未來，將配置數(shù)據(jù)、監(jiān)控數(shù)據(jù)、日志數(shù)據(jù)、自動化工具、流程工具，基于架構(gòu)圖進行有機整合，激發(fā)了運維人員對運維所需工具的新需求，從而形成更加高效的數(shù)據(jù)消費場景。
伴隨著工具深入使用和持續(xù)優(yōu)化，相應(yīng)的需求仍在不斷涌現(xiàn)，未來會根據(jù)進展與大家分享。
- END -
推薦閱讀 31天拿下K8s含金量最高的CKA+CKS證書！ 這些 K8S 日常故障處理集錦，運維請收藏~ 豬八戒網(wǎng) CI/CD 最佳實踐之路 從零開始搭建創(chuàng)業(yè)公司DevOps技術(shù)棧 Jenkins Pipeline 流水線部署 Kubernetes 應(yīng)用 快、狠、準！系統(tǒng)有效的排查運維類故障 Nginx 常用配置清單 最強整理！常用正則表達式速查手冊 12年資深運維老司機的成長感悟 60道常見的 Kubernetes 面試題總結(jié)
點亮，服務(wù)器三年不宕機
