北京銀行自1996年建行初期便開始了信息化方面的工作。迄今為止，銀行內(nèi)部虛機(jī)/物理機(jī)數(shù)量已達(dá)2000-3000臺，業(yè)務(wù)系統(tǒng)約為260個左右。雖然與行業(yè)內(nèi)同規(guī)模銀行的布局比較類似，但是北京銀行內(nèi)部的應(yīng)用系統(tǒng)及服務(wù)器的數(shù)量相較于其他行更多，數(shù)據(jù)庫和系統(tǒng)中間件的類型也更為復(fù)雜。

　　

　　基于以上背景，北京銀行在此前也進(jìn)行了一系列針對應(yīng)用層、系統(tǒng)層、網(wǎng)絡(luò)安全層等方面的監(jiān)控工具建設(shè)。整體來看，無論是監(jiān)控數(shù)量還是力度都是比較大的，但由于各個層面的監(jiān)控產(chǎn)品不盡相同，也難以有效聯(lián)通協(xié)作，實際監(jiān)控中依舊面臨著非常大的挑戰(zhàn)。

　　

　　

　　北京銀行從2016年開始進(jìn)行整體的運維規(guī)劃布局與實施工作，包括但不僅限于監(jiān)控工具以及其他IT軟件、系統(tǒng)均來自不同產(chǎn)商，這些軟件從界面到使用習(xí)慣均各有特點，如何將其各自效能發(fā)揮出來，成為了現(xiàn)如今北京銀行運維所面臨的最大的挑戰(zhàn)。

　　

　　以監(jiān)控工具為例，最基本的是能發(fā)現(xiàn)問題，這件工作基本都已實現(xiàn)，各類監(jiān)控產(chǎn)品推陳出新，靜態(tài)基線、動態(tài)閾值、SNMP、網(wǎng)絡(luò)旁路抓包等等。但是真的出現(xiàn)故障時，就會出現(xiàn)井噴式的報警信息。

　　

　　具體來講，我認(rèn)為可以分為三個層次：一是在整個業(yè)務(wù)流程的鏈路上，某個節(jié)點系統(tǒng)出現(xiàn)不穩(wěn)定情況，導(dǎo)致很多的業(yè)務(wù)系統(tǒng)處理時間、成功率等異常。需要明確哪個系統(tǒng)是根源；二是一個業(yè)務(wù)系統(tǒng)中，包含負(fù)載均衡、應(yīng)用、數(shù)據(jù)庫、通訊、加密甚至各層級的網(wǎng)絡(luò)安全設(shè)備。明確了業(yè)務(wù)鏈條上哪個業(yè)務(wù)系統(tǒng)是故障根因后，需要明確由于哪個設(shè)備的異常導(dǎo)致的業(yè)務(wù)系統(tǒng)異常；三是在單個設(shè)備中，往往重啟服務(wù)是最快速的解決問題方法。但是當(dāng)CPU升高、交易時間變長等異常狀態(tài)同時出現(xiàn)時，依舊需要依靠技術(shù)人員橫向分析才能判斷問題原因，但前提是監(jiān)控系統(tǒng)詳細(xì)記錄了問題出現(xiàn)的過程和現(xiàn)象，并且在服務(wù)重啟過程中故障現(xiàn)場的各類數(shù)據(jù)能夠精準(zhǔn)的保留下來。

　·北京銀行系統(tǒng)運行情況分解圖·

　　

　　我們再以最典型的“手機(jī)銀行購買理財”業(yè)務(wù)場景作為例子?？蛻舻牟僮髀贸檀笾聻椋旱卿?余額查詢-理財查詢-購買理財-查詢是否購買成功-查詢余額等多個操作，而事實上，單純“購買理財”這一個操作，系統(tǒng)會從手機(jī)銀行端發(fā)起請求至ESB統(tǒng)一平臺，然后再發(fā)送到理財系統(tǒng)，由理財系統(tǒng)發(fā)送至核心系統(tǒng)進(jìn)行響應(yīng)。

　　

　　如果某個時間點該業(yè)務(wù)場景的任一環(huán)節(jié)出現(xiàn)遲緩等問題（比如手機(jī)端進(jìn)行秒殺遲緩），在進(jìn)行問題分析處理的時候就會涉及到各個不同的層面。例如，它可能會涉及到不同客戶手機(jī)所使用的APP，以及WEB服務(wù)器、手機(jī)應(yīng)用、不同數(shù)據(jù)庫以及相關(guān)的網(wǎng)絡(luò)設(shè)備、防火墻等等。同時，這一個流程上又會涉及很多設(shè)備，每一個也都需要在自己的監(jiān)控工具上才能拿到相關(guān)的數(shù)據(jù)。

　　

　　其次，即使就單單一個數(shù)據(jù)庫而言，它也有自己的硬件服務(wù)器、盤陣、網(wǎng)絡(luò)設(shè)備，有自己獨立的一套操作系統(tǒng)，系統(tǒng)本身還會有備份以及批處理作業(yè)，以上所有的設(shè)備以及過程一旦發(fā)生變動都會對業(yè)務(wù)處理產(chǎn)生很大的影響。

　　

　　例如，北京銀行內(nèi)部曾經(jīng)出現(xiàn)過一次故障，該故障不是在使用其他系統(tǒng)期間出現(xiàn)，表現(xiàn)為整個IT系統(tǒng)突然就變得緩慢，導(dǎo)致大量交易不成功。最后經(jīng)運維人員層層篩查日志發(fā)現(xiàn)，是由于后臺程序自動的在某個點發(fā)起了一個備份作業(yè)，而且鑒于這個備份作業(yè)在后臺自動發(fā)起，非人工操作引起的，運維人員根本不知情。故障發(fā)生時，由于沒有全方位的監(jiān)控數(shù)據(jù)能夠顯現(xiàn)，問題篩查過程耗費了大量的人力、物力。

　　

　　從上面的情況中，我們可以看到，即使有了全面的監(jiān)控，但是如果數(shù)據(jù)依舊還是散落在各個監(jiān)控系統(tǒng)內(nèi)的，管理員在按照時間維度進(jìn)行橫向比對，篩查可能的問題時是非常困難的。再者，后臺批處理作業(yè)的狀態(tài)、近期的變更都有可能導(dǎo)致系統(tǒng)的不穩(wěn)定，因此有必要建立一體化的運維大數(shù)據(jù)平臺，進(jìn)行全面的業(yè)務(wù)可視化管理。

　　

　　

　　基于以上原因，北京銀行IT運維的當(dāng)務(wù)之急是進(jìn)行業(yè)務(wù)可視化平臺的建設(shè)，以此做到數(shù)據(jù)的全方位管控與利用，提升運維效率，減少故障。

　　

·可視化監(jiān)控平臺建設(shè)目標(biāo)·
 

　　

　　

　　通過可視化的監(jiān)控平臺，將覆蓋十幾個監(jiān)控系統(tǒng)的作業(yè)數(shù)據(jù)全面收集，統(tǒng)一納管，來實現(xiàn)系統(tǒng)運行狀況的實時掌握，保證生產(chǎn)系統(tǒng)穩(wěn)定運行。并在此基礎(chǔ)上，保證業(yè)務(wù)連續(xù)性，給業(yè)務(wù)人員提供穩(wěn)定的系統(tǒng)環(huán)境。

　　

　　

　　由于行內(nèi)各個監(jiān)控系統(tǒng)的使用習(xí)慣、規(guī)則等不盡相同，網(wǎng)絡(luò)之間分歧等原因，來源于不同路徑的數(shù)據(jù)往往在類型、格式上都不太一致，因此在進(jìn)行統(tǒng)一納管的時候會非常困難，更別提對他們統(tǒng)一進(jìn)行分析利用。因此，需要制定指標(biāo)數(shù)據(jù)、事件數(shù)據(jù)的相關(guān)規(guī)范，將來源于不同系統(tǒng)的指標(biāo)和事件數(shù)據(jù)進(jìn)行數(shù)據(jù)轉(zhuǎn)換，使其標(biāo)準(zhǔn)化，便于后續(xù)利用。

　　

　　

　　面對龐大的業(yè)務(wù)量，銀行內(nèi)部的數(shù)據(jù)增長呈指數(shù)級趨勢，巨大的數(shù)據(jù)如果僅僅只是被存儲起來，那么將變成累贅的包袱。而運維要想走向最終的“運營”，離不開數(shù)據(jù)的有效利用。在新的運維模式下，我們將一個生產(chǎn)事件分為三個部分，分別是“事前”、“事中”、“事后”，每一部分的數(shù)據(jù)都有其不同的角色價值。

　　

　　在“事前”，將數(shù)據(jù)分析與業(yè)務(wù)規(guī)劃結(jié)合起來，做到對流量、容量進(jìn)行預(yù)測，有的放矢。在“事中”，將數(shù)據(jù)統(tǒng)一規(guī)劃進(jìn)行分析，并快速進(jìn)行對比問題、發(fā)現(xiàn)問題并關(guān)聯(lián)問題，最終做到故障告警智能去重，降低運維噪音。在“事后”,及時做好歸納總結(jié)，智能提供參考的故障排查路徑與解決方案。

　　

　　

　　面對北京銀行每天數(shù)以億計的指標(biāo)數(shù)據(jù)、事件數(shù)據(jù)、以及非關(guān)系型數(shù)據(jù)的采集納管，需要使用大數(shù)據(jù)技術(shù)進(jìn)行相關(guān)的存儲和計算。與此同時，建設(shè)依賴于CMDB關(guān)系數(shù)據(jù)和二叉決策樹算法來判斷事件的相關(guān)性，再輔助以專家規(guī)則進(jìn)行修正。

　　

　　北京銀行通過搭建一體化的運維大數(shù)據(jù)平臺，進(jìn)行全方面的業(yè)務(wù)可視化管理能力建設(shè)，目前平臺已經(jīng)具備統(tǒng)一收集數(shù)據(jù)、數(shù)據(jù)轉(zhuǎn)換等功能，并在此基礎(chǔ)上，IT系統(tǒng)得以高效、穩(wěn)定運行。但是，在關(guān)于數(shù)據(jù)兼容性、數(shù)據(jù)質(zhì)量等方面，還有待后期建設(shè)完善。

·可視化監(jiān)控平臺建設(shè)方案·

　　

　　北京銀行業(yè)務(wù)可視化運維監(jiān)控平臺是以Kafka為基礎(chǔ)的數(shù)據(jù)交換平臺，具備數(shù)據(jù)接入、輸出的能力。數(shù)據(jù)接入來源有：服務(wù)器設(shè)備指標(biāo)數(shù)據(jù)、事件數(shù)據(jù)數(shù)據(jù)庫、中間件指標(biāo)數(shù)據(jù)、事件數(shù)據(jù)網(wǎng)絡(luò)、安全設(shè)備指標(biāo)數(shù)據(jù)、事件數(shù)據(jù)業(yè)務(wù)監(jiān)控指標(biāo)數(shù)據(jù)、事件數(shù)據(jù)關(guān)鍵業(yè)務(wù)指標(biāo)數(shù)據(jù)等不同來源，數(shù)據(jù)輸出包括可視化平臺和數(shù)據(jù)分析的平臺，由數(shù)據(jù)接入來的數(shù)據(jù)在數(shù)據(jù)輸出處進(jìn)行分析、處理后，交由數(shù)據(jù)消費環(huán)節(jié)，這部分包括有：大屏展現(xiàn)、態(tài)勢感知、關(guān)聯(lián)事務(wù)查詢、業(yè)務(wù)系統(tǒng)看板、事件根因分析等等。

　　

　　通過實際建設(shè)，北京銀行可視化監(jiān)控平臺能夠?qū)崿F(xiàn)多種功能，其中包括通過將關(guān)鍵指標(biāo)（如MQ隊列，http延時）可視化進(jìn)行業(yè)務(wù)綜合概覽。并且，可視化平臺內(nèi)設(shè)有健康度模型，運維人員能夠在后臺看到最近七天實時的系統(tǒng)健康程度，還可以通過內(nèi)置的權(quán)重模型，設(shè)定業(yè)務(wù)健康度評估，權(quán)重值允許自定義調(diào)整，同時支持添加新的指標(biāo)。與此同時，前期建設(shè)的自動化運維平臺可以和可視化關(guān)聯(lián)起來，當(dāng)系統(tǒng)出現(xiàn)故障的時候，實現(xiàn)故障自愈的相關(guān)操作。

　　

　　北京銀行期待未來的IT支撐建設(shè)能夠從“運維”走向“運營”，站在銀行布局的戰(zhàn)略角度，希望實現(xiàn)的不單是業(yè)務(wù)數(shù)據(jù)、IT資源能夠有效納管，確保IT資產(chǎn)、業(yè)務(wù)數(shù)據(jù)，能夠?qū)崿F(xiàn)“看得見，管的住”。還應(yīng)當(dāng)將統(tǒng)一收集到的有效數(shù)據(jù)進(jìn)行高效的數(shù)據(jù)分析，比如銀行卡系統(tǒng)的成交率、理財購買人員的男女比例、年齡架構(gòu)、資金來源等都能夠?qū)崿F(xiàn)數(shù)據(jù)化的分析，進(jìn)而對業(yè)務(wù)運營、決策做出一些指導(dǎo)意見。