當(dāng)前位置:首頁 > 公眾號精選 > 架構(gòu)師社區(qū)
[導(dǎo)讀]本文根據(jù)胖亞鵬老師在〖deeplus直播第222期〗線上分享演講內(nèi)容整理而成。 胖亞鵬 光大銀行科技部系統(tǒng)架構(gòu)師 光大銀行科技部系統(tǒng)架構(gòu)師、技術(shù)專家,具有十余年監(jiān)控系統(tǒng)建設(shè)的項目實施經(jīng)驗。目前主要負責(zé)光大銀行統(tǒng)一監(jiān)控管理平臺的總體架構(gòu)規(guī)劃和欄目內(nèi)部研發(fā)


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


本文根據(jù)胖亞鵬老師在〖deeplus直播第222期〗線上分享演講內(nèi)容整理而成。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路

胖亞鵬

光大銀行科技部系統(tǒng)架構(gòu)師


  • 光大銀行科技部系統(tǒng)架構(gòu)師、技術(shù)專家,具有十余年監(jiān)控系統(tǒng)建設(shè)的項目實施經(jīng)驗。目前主要負責(zé)光大銀行統(tǒng)一監(jiān)控管理平臺的總體架構(gòu)規(guī)劃和欄目內(nèi)部研發(fā)管理等工作。

  • 對監(jiān)控系統(tǒng)的管理模型優(yōu)化、監(jiān)控服務(wù)化的實現(xiàn)以及分布式監(jiān)控等領(lǐng)域有較深入的研究和理解。對于將AI技術(shù)運用到監(jiān)控領(lǐng)域有濃厚興趣。


大家好,我今天分享的主題是光大銀行統(tǒng)一監(jiān)控平臺建設(shè)實踐。


光大銀行統(tǒng)一監(jiān)控平臺,定位是服務(wù)全行科技條線的IT監(jiān)控系統(tǒng),是運維之眼。該平臺體系比較龐大,今天主要介紹偏向于監(jiān)控管理和報警管理的相關(guān)功能。這部分功能是我行根據(jù)多年的經(jīng)驗自主研發(fā)實現(xiàn)的,里面蘊含著監(jiān)控管理方面的理念和思路,希望此次分享能給大家?guī)硪恍﹨⒖己蛦l(fā)。


一、監(jiān)控系統(tǒng)發(fā)展現(xiàn)狀分析


1、發(fā)展背景


金融科技是一個炙手可熱的話題,通過互聯(lián)網(wǎng)、大數(shù)據(jù)、云計算、人工智能、區(qū)塊連等新技術(shù)的應(yīng)用,支持和引領(lǐng)著業(yè)務(wù)的快速發(fā)展。


這個過程中,對銀行科技運維和運營都帶來了很大的挑戰(zhàn),主要表現(xiàn)在:


  • 業(yè)務(wù)對服務(wù)的穩(wěn)定性、可靠性要求越來越高;

  • 業(yè)務(wù)對IT支撐能力的依賴性越來越強;

  • IT架構(gòu)本身的復(fù)雜度越來越高。


為了提升整體的IT運營和運維能力,銀行業(yè)的數(shù)據(jù)中心較早引入了ITIL管理理念,建立流程管理的模式,形成運維管理工作的流程化和標(biāo)準(zhǔn)化模式。


隨著云計算、大數(shù)據(jù)和人工智能的發(fā)展,在原有的ITIL的基礎(chǔ)上引入了DevOps和AIOps理念的相關(guān)技術(shù),逐步轉(zhuǎn)向為數(shù)據(jù)和業(yè)務(wù)價值驅(qū)動,向著IT運營和數(shù)字化運營的目標(biāo)轉(zhuǎn)型。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


從我們光大銀行的角度,科技部運維中心提出了BCDT的理念,作為運維相關(guān)工作的總體指導(dǎo)思想和理念。從監(jiān)控系統(tǒng)建設(shè)的角度,主要的內(nèi)容就是:


  • 底線思維:不漏報、不誤報、全覆蓋,監(jiān)控系統(tǒng)自身高可用,安全可靠;

  • 閉環(huán)思維:監(jiān)控能力建設(shè)要向開發(fā)、測試前移,監(jiān)控策略的部署、故障處置、定位和后分析,要形成閉環(huán)持續(xù)優(yōu)化;

  • 發(fā)展思維: 是研究和引入新的監(jiān)控手段和管理方法,適應(yīng)和滿足新的管理要求;

  • 技術(shù)思維:強調(diào)技術(shù)是核心驅(qū)動力,通過技術(shù)帶動監(jiān)控能力的提升。


2、建設(shè)歷程


光大銀行監(jiān)控體系經(jīng)過了多年的建設(shè),歷經(jīng)了幾個主要階段,通過分析可以看到主要的趨勢是朝著集中化、平臺化和數(shù)字化的發(fā)展方向。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


1)2005年開始配置獨立的監(jiān)控工具。


2)2011年開始進入平臺化建設(shè),報警統(tǒng)一。


3)2014年開始全面監(jiān)控,實現(xiàn)應(yīng)用交易監(jiān)控,搭建了大數(shù)據(jù)平臺的框架。


4)2018年新一代的監(jiān)控管理平臺上線運行,這是我行自主研發(fā)的平臺,在報警管理、標(biāo)準(zhǔn)化和自動化能力上的提升明顯。


5)2019年科技運營數(shù)據(jù)平臺投產(chǎn),這個系統(tǒng)通過產(chǎn)學(xué)研合作的方式落地 AI分析處理能力,監(jiān)控系統(tǒng)向著數(shù)字化轉(zhuǎn)型。


3、思考總結(jié)


在我行監(jiān)控管理系統(tǒng)持續(xù)演進的過程中,我們也在思考和總結(jié),哪些是不變的,哪些是頻繁變化的。


相對穩(wěn)定不變的內(nèi)容包括:


  • 平臺職能目標(biāo):保障IT系統(tǒng)穩(wěn)定運行,不變。運維中心對監(jiān)控系統(tǒng)設(shè)定的主動發(fā)現(xiàn)率這個KPI指標(biāo),一直沒有變;

  • 報警管理的目標(biāo):事前預(yù)警、事中發(fā)現(xiàn)和定位、事后分析,這個工作方法沒有變。

  • 監(jiān)控管理的模型: 監(jiān)控管理作為業(yè)務(wù)去分析,它包含的監(jiān)控對象、監(jiān)控指標(biāo)、監(jiān)控策略,這個管理模型沒有變。


變化的內(nèi)容就比較多了,比如:


  • 監(jiān)控對象更復(fù)雜;

  • 監(jiān)控技術(shù)和工具日新月異;

  • 監(jiān)控范圍涵蓋指標(biāo)、日志、Tracing等;

  • 更加認(rèn)識到數(shù)據(jù)的價值;

  • 引入很多智能算法;

  • 運維和開發(fā)更加緊密合作等等。

  

我們回顧和總結(jié)這個變化,對我們監(jiān)控系統(tǒng)建設(shè)有很強的指導(dǎo)作用。不變的點更多是管理相關(guān)的能力和要求,這在市場上沒有完全滿足我們要求的產(chǎn)品,于是我們選擇了自主進行研發(fā),最終形成了監(jiān)控管理平臺。


而對于更多變化的內(nèi)容,我們的策略是快速引入專業(yè)領(lǐng)域的監(jiān)控工具納入到我行監(jiān)控體系中使用,對接到管理平臺進行統(tǒng)一管理。發(fā)展趨勢中,大數(shù)據(jù)平臺的作用和價值凸顯,我們也以此作為監(jiān)控乃至IT運營的轉(zhuǎn)型的方向,基于開源的產(chǎn)品重點建設(shè)和優(yōu)化。


二、光大銀行監(jiān)控體系總體介紹


1、總體架構(gòu)


在重點介紹監(jiān)控管理平臺之前,有必要讓大家對光大銀行監(jiān)控體系的總體架構(gòu)和功能有個了解。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


光大銀行監(jiān)控系統(tǒng)的定位是面向全行科技部門的IT監(jiān)控系統(tǒng)。從功能層面分為3層,分別是監(jiān)控工具層、平臺層和統(tǒng)一展示層。


1)監(jiān)控工具層,包含各類開源或者商業(yè)的專業(yè)領(lǐng)域的監(jiān)控工具,他們實現(xiàn)對各類監(jiān)控工具的實時的數(shù)據(jù)采集。常見的比如Zabbix、Nagios、Prometheus、BPC、Tivoli等等,都定位在監(jiān)控工具層。監(jiān)控工具會把報警數(shù)據(jù)、性能數(shù)據(jù)、日志數(shù)據(jù),上送到平臺層。


2)平臺層,包含兩大部分功能:一是由監(jiān)控報警處理、監(jiān)控標(biāo)準(zhǔn)化和自服務(wù)等功能模塊組成的管理平臺;二是基于大數(shù)據(jù)架構(gòu)的科技運營數(shù)據(jù)平臺,包括大數(shù)據(jù)處理、存儲、AI分析以及數(shù)據(jù)服務(wù)接口等子系統(tǒng)。在平臺層,還實現(xiàn)了和行內(nèi)其他運維系統(tǒng)的對接。


3)統(tǒng)一展示層,根據(jù)不同用戶的角色和場景,提供PC、大屏和手機端展示。


總的來說,平臺層的建設(shè)思路是開源+自研,是整個體系的核心;工具層的建設(shè)思路是專業(yè)+敏捷+統(tǒng)一管理。


通過多年的建設(shè),監(jiān)控系統(tǒng)的指標(biāo)覆蓋從底層的機房設(shè)施到最上層的應(yīng)用交易,實現(xiàn)了指標(biāo)全覆蓋。借助多種監(jiān)控工具的部署,對監(jiān)控指標(biāo)的實現(xiàn),一般都具備多種監(jiān)控手段。


我們內(nèi)部有個原則:對于關(guān)鍵指標(biāo),要有兩種的工具能夠覆蓋。這樣做有兩個好處:一是能夠確保監(jiān)控策略有冗余,二是確保當(dāng)我們識別出一個新的指標(biāo)要納入監(jiān)控時,我們一定有工具能快速實現(xiàn)監(jiān)控部署。 


2、交易監(jiān)控


交易監(jiān)控,一直是所有監(jiān)控系統(tǒng)建設(shè)的重點功能。我們通過多種手段,實現(xiàn)端到端的交易全方位監(jiān)控:


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


1)采用了網(wǎng)絡(luò)旁路抓包、流水表鏡像和交易日志分析等多種方式監(jiān)控交易成功率、響應(yīng)率、響應(yīng)時間等指標(biāo),實現(xiàn)了對應(yīng)用無侵入的、實時的監(jiān)控。


2)TCP網(wǎng)絡(luò)層監(jiān)控,通過旁路方式對應(yīng)用的全鏈路“通訊對進行監(jiān)控和分析,能夠快速發(fā)現(xiàn)網(wǎng)絡(luò)的異常,也能從網(wǎng)絡(luò)層面對應(yīng)用故障進行協(xié)助定位和分析。


3)模擬監(jiān)控,從互聯(lián)網(wǎng)以及內(nèi)網(wǎng)探點模擬訪問應(yīng)用系統(tǒng),主動獲取可用性和性能數(shù)據(jù),并接入到監(jiān)控平臺進行集中處理和分析。


4)通過網(wǎng)絡(luò)抓包和日志Api的方式進行端到端追蹤系統(tǒng)應(yīng)用間和應(yīng)用系統(tǒng)內(nèi)部的交易路徑。這個功能目前在部分新架構(gòu)下的應(yīng)用系統(tǒng)已經(jīng)實現(xiàn),更多傳統(tǒng)的應(yīng)用系統(tǒng)正在改造過程中。


3、大數(shù)據(jù)和智能化


大數(shù)據(jù)和智能算法,是我們現(xiàn)在的工作重心。2019年我們的科技運營數(shù)據(jù)平臺完成上線投產(chǎn),這個平臺綜合運用了多種算法,實現(xiàn)了指標(biāo)異常檢測、多維檢測、批處理異常檢測等多種功能。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


對銀行業(yè)最重要的就是聯(lián)機交易和批量執(zhí)行,智能監(jiān)控為傳統(tǒng)監(jiān)控提供了重要的補充手段:


一個場景是交易監(jiān)控,綜合節(jié)假日、促銷等各種因素實現(xiàn)動態(tài)的異常交易檢測和告警,可以細化到每一只交易單獨進行監(jiān)控,相比于傳統(tǒng)的固定閾值監(jiān)控能提前3-5分鐘進行提示。  


第二個場景,是對批量任務(wù)時長的智能分析,相比于傳統(tǒng)的固定批量執(zhí)行時長的監(jiān)控,智能分析的結(jié)果能夠做到提前預(yù)警,為夜間故障處置贏得了時間。


在數(shù)據(jù)展示方面,我們建設(shè)了統(tǒng)一視圖系統(tǒng)。支持移動端、大屏端、PC端實時數(shù)據(jù)展示。根據(jù)業(yè)務(wù)場景,定制了日常運維視圖、 應(yīng)急保障視圖、和重保運營視圖。


按照用戶角色的使用需求,對各類視圖進行分類,如一線偏重于故障發(fā)現(xiàn)、和按照預(yù)案處置以及事后的驗證;二線偏重于故障的解決以及趨勢分析和隱患排查。


4、技術(shù)棧


對于監(jiān)控系統(tǒng)的建設(shè),我們的原則是以開源為主,自主可控。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


在數(shù)據(jù)采集層面,我們使用了zabbix、nagios、prometheus 等常見的開源軟件。另外也有國產(chǎn)的網(wǎng)絡(luò)流量采集和分析的產(chǎn)品。對于存量的國外商業(yè)套件,我們已經(jīng)制定了替換的計劃,預(yù)計會逐步下線。


需要特別提到的是,我們正在實施部署的統(tǒng)一采控Agent子系統(tǒng),采用自研方式建設(shè),目標(biāo)是能夠成為一個采集腳本編寫和管理的基礎(chǔ)平臺,提供通用的Agent驅(qū)動能力,獨立實現(xiàn)服務(wù)器上所有數(shù)據(jù)的實時采集,成為大數(shù)據(jù)平臺最穩(wěn)定可靠的數(shù)據(jù)來源。


在數(shù)據(jù)處理、數(shù)據(jù)存儲、前端展示以及開發(fā)部署各個層面,也就是平臺層的產(chǎn)品則基本都是開源的產(chǎn)品和技術(shù)。


上面是對我行監(jiān)控系統(tǒng)整體的功能和架構(gòu)進行了簡要介紹。


三、監(jiān)控管理平臺建設(shè)實踐分享


前面介紹了光大銀行總體監(jiān)控體系,在本章節(jié)我來介紹一下監(jiān)控體系中的監(jiān)控管理子系統(tǒng)。


1、管理平臺功能架構(gòu)


這是監(jiān)控管理平臺的總體功能架構(gòu)圖:


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


主要是兩大部分,第一個是左半部分,從下到上包括報警采集、預(yù)處理和處理,構(gòu)成了報警處理引擎子系統(tǒng),其中還包括了報警通知和維護期管理的功能。 


第二是右半部分從上到下,監(jiān)控標(biāo)準(zhǔn)化管理子系統(tǒng),包含監(jiān)控對象、策略、指標(biāo)和規(guī)則等標(biāo)準(zhǔn)化管理功能,以及監(jiān)控配置自動化、監(jiān)控評價等功能。


通俗的說,左面部分解決的是報警來了怎么處理的問題, 右面部分解決的是報警如何配置,怎么產(chǎn)生的問題。


2、監(jiān)控報警引擎


下面分別介紹一下報警處理引擎和監(jiān)控標(biāo)準(zhǔn)化管理兩大部分功能。報警處理引擎,是光大銀行自主研發(fā)實現(xiàn)的核心組件,所以這個部分是本次分享的重點內(nèi)容。


首先,我們先來分析報警管理的技術(shù)和業(yè)務(wù)特點:


  • 在事件采集層,數(shù)據(jù)源豐富、報文格式多種多樣,并且期望的采集延遲在毫秒級;

  • 在報警處理層,特點包括報警量大、可能存在報警風(fēng)暴、報警之間相關(guān)性高、處理邏輯復(fù)雜,要考慮擴展性并且還要合理繼承原有的規(guī)則,處理延遲要求在秒級完成;

  • 在展示和處置層,要求的是展現(xiàn)形式多種多樣,前端頁面能夠高頻刷新或主動的接收服務(wù)器推送的報警,保證時效性。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


基于上述報警管理的特點,我們制定了報警處理引擎的選型和開發(fā)的目標(biāo):


1)事件采集和處理要解耦,這樣能夠保證采集器的采集時效性。


2)事件處理集中化,規(guī)則、外部對象資源都要加載,通過集中處理可以更加充分的利用資源,一次加載重復(fù)使用。


3)事件處理分布式,處理集中之后就要有分布式處理可水平擴展的能力。


4)分布式內(nèi)存數(shù)據(jù)庫,針對報警反復(fù)讀寫數(shù)據(jù)庫的情況,這是從性能角度考慮。


5)對SQL的支持好,數(shù)據(jù)庫的訪問就能非常靈活和簡潔,監(jiān)控報警規(guī)則就更容易實現(xiàn)。


6)去商業(yè)化,自主構(gòu)建?;陂_源軟件構(gòu)建,能夠最大程度滿足管理要求。


上述幾點是我們最初選擇報警處理引擎的一些考量或者是目標(biāo)。這和我們之前用的產(chǎn)品也有一定關(guān)系,我們之前采用的是IBM Omnibus產(chǎn)品,到現(xiàn)在也有很多金融機構(gòu)在使用該產(chǎn)品,它是一個基于內(nèi)存的支持SQL的報警處理引擎,它的最大問題就是單節(jié)點、單進程運行,所以對于大數(shù)據(jù)量的處理存在瓶頸。


所以我們開發(fā)的新報警引擎一方面要解決處理能力的瓶頸,另一方面要能夠完全兼容原平臺的處理邏輯和規(guī)則。這是我們在技術(shù)選型前的另外一個約束。

    

在產(chǎn)品選型的過程中,我們主要考慮的是兩部分,一是數(shù)據(jù)庫,二是分布式開發(fā)的框架。


在數(shù)據(jù)庫選型中,我們選擇了Apache Ignite作為分布式數(shù)據(jù)庫。和其他數(shù)據(jù)庫的對比,比如Oracle、MySQL、Eedis、Geode、ES,主要考量幾個特征是內(nèi)存關(guān)系數(shù)據(jù)庫、支持SQL、支持持久化等。


第二個選型,是分布式開發(fā)框架,因為框架主要用于引擎內(nèi)各個組件的高性能交互,所以我們選擇了Dubbo框架,相對更輕量和小巧。


關(guān)于 Apache Ignite,是基于Java語言開發(fā)的,可以用作一個分布式的緩存,也是一個分布式內(nèi)存數(shù)據(jù)庫,可以作為關(guān)系數(shù)據(jù)庫使用。它的數(shù)據(jù)儲存在堆外內(nèi)存的,不受GC影響,性能更好。作為內(nèi)存數(shù)據(jù)庫,它還能將數(shù)據(jù)持久化到磁盤,保證數(shù)據(jù)不丟失。另外一些特點比如支持事務(wù)、可配置為CP或者AP使用,支持SQL函數(shù)擴展以及內(nèi)置消息訂閱發(fā)布模型。


作為報警引擎來講,我們更加關(guān)注分布式緩存、分布式數(shù)據(jù)庫、和持久化。


下面是報警處理引擎的功能架構(gòu)圖,包括接入層、處理層、APP管理層、數(shù)據(jù)管理層和接口層。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


其中的重點是處理層,分為兩大類的處理功能,下層是報警流處理,上層是報警的批處理。這些處理功能模塊是動態(tài)加載和可擴展的,是在App管理層采用應(yīng)用商店的模式,進行發(fā)布和編排的App。在我們的報警引擎中,將每個處理功能都作為一個App來管理。通過這樣的靈活管理和部署的架構(gòu),滿足報警處理的各種需求。

    

光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路



從技術(shù)產(chǎn)品框架的視角看,最下層是自主開發(fā)的事件采集器 使用了spring boot + akka。應(yīng)用層采用Dubbo的分布式處理集群,集群內(nèi)運行多個事件處理節(jié)點,事件處理節(jié)點使用的技術(shù)包括:ANTLR 語法分析、java 動態(tài)編譯tools 以及Java RMI。使用zookeeper作為服務(wù)發(fā)布和訂閱的管理,ignite是報警存儲庫。最上層是報警視圖的前后端服務(wù)。


一個事件處理節(jié)點內(nèi)部的邏輯架構(gòu)和數(shù)據(jù)的流向圖如下:


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


主要內(nèi)容包括:


1)數(shù)據(jù)處理流程是報警從采集器來,送到流處理模塊后通過ignite客戶端節(jié)點入庫。批處理模塊負責(zé)把報警取出來進行二次分析,增刪改的動作還會送到流處理模塊進行處理后入庫。


2)在ignite庫中分為實時庫和歷史庫,保存所有的報警信息。引擎通過報警跟蹤的模塊,把所有的報警變化記錄同步到kafka,供第三方消費。批處理分配模塊則實現(xiàn)了批任務(wù)的分布式處理調(diào)度的工作。


3)控制臺提供用戶交互接口,管理流處理和批處理中運行的處理功能App。節(jié)點間管理信息的同步則通過RMI通訊模塊完成。


報警處理功能,是處理引擎的核心功能。什么是處理功能?比如一個報警發(fā)生了,要不要進維護期,那這就是一個報警處理功能。那維護期的判斷,一定是在報警通知之前執(zhí)行。那這就是功能間的編排。


我們的報警處理引擎,是以應(yīng)用商店App的模式對報警處理功能進行封裝和管理編排,定義了多種App類型,支持處理功能的定制開發(fā)。也就是說報警功能可以不斷的擴充的。


App的類型,包括:


  • 最普通的流App和批量App;

  • 廣播型的App本質(zhì)是為分布式批量;

  • 訂閱型批量是和上述類型App組合使用的,用于數(shù)據(jù)的匯總和再處理;

  • Restful App 可以動態(tài)的生成訪問App內(nèi)部數(shù)據(jù)的接口,可以對App運行情況進行監(jiān)控。


在我行報警處理引擎正在運行的處理功能,包括一些基本的處理功能,比如報警豐富、報警壓縮 、恢復(fù)關(guān)聯(lián)、自動升降級、維護期等。在智能化報警方面,主要的處理功能用于報警的根因和影響分析,實現(xiàn)了根因升級和受影響報警的自動降級,場景包括如服務(wù)器宕機、應(yīng)用服務(wù)擁堵、DWDM中斷等異常場景。我們正在做的優(yōu)化工作,包括基于算法的報警和基于cmdb規(guī)則的排障樹等功能。 


總結(jié)一下報警處理引擎的特性:


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


特性包括:分布式處理、高可用;完全兼容之前IBM omnibus的處理規(guī)則,可以平滑過渡;支持App熱部署熱插拔;App可編排、調(diào)度和協(xié)作;擴展性強,支持自定義App開發(fā)和部署以及SQL函數(shù)擴展;高并發(fā)、高性能;支持告警鏈路追蹤和處理性能統(tǒng)計;支持全備+增量的備份方式;支持多數(shù)據(jù)中心主備模式部署。


3、監(jiān)控標(biāo)準(zhǔn)化


前面講了監(jiān)控管理平臺的報警引擎,下面要再來分享標(biāo)準(zhǔn)化管理的內(nèi)容。


在前面介紹監(jiān)控系統(tǒng)演進過程時我們講到過,監(jiān)控管理的模型到目前為止還是依然適用的:


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


其中涉及監(jiān)控對象、監(jiān)控工具、監(jiān)控策略、監(jiān)控指標(biāo) ,比較核心的幾個概念和關(guān)系:


  • 監(jiān)控指標(biāo)是針對每一類對象要監(jiān)控什么,是對象的一組動態(tài)屬性,比如CPU使用率就是一個指標(biāo);

  • 監(jiān)控策略是如何進行度量指標(biāo),比如 CPU使用率大于80%,持續(xù)3分鐘,報一個警告; 

  • 關(guān)系是:監(jiān)控對象關(guān)聯(lián)了監(jiān)控指標(biāo),監(jiān)控策略實現(xiàn)了監(jiān)控指標(biāo),并且在特定的監(jiān)控工具上運行,完成對監(jiān)控對象的監(jiān)控;

  • 監(jiān)控標(biāo)準(zhǔn),就是哪些對象用哪些策略覆蓋哪些指標(biāo)。把這些規(guī)則匯總和發(fā)布出來,就是我們企業(yè)級的監(jiān)控標(biāo)準(zhǔn)。


在實際運行中,監(jiān)控對象、指標(biāo)、策略和工具自身的內(nèi)容,都在發(fā)生變化,比如我們引入了交易量動態(tài)基線的監(jiān)控,實際上就是用一種新的工具和策略,去檢查我們原有的監(jiān)控對象和指標(biāo)。


在我行監(jiān)控系統(tǒng)實現(xiàn)時的一些要點總結(jié)如下:


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


1)在監(jiān)控對象管理的方面,支持對象全覆蓋、對象類別和屬性擴充、對象關(guān)聯(lián)關(guān)系管理。錄入對象時,物理的屬性是系統(tǒng)自動發(fā)現(xiàn)和采集;管理屬性優(yōu)先是從外部的cmdb進行同步。支持批量導(dǎo)入。這部分的管理功能可以套用cmdb的管理。


2)指標(biāo)方面,需要支持虛擬指標(biāo)和工具指標(biāo)的定義和關(guān)聯(lián)。


3)策略方面,要支持通用的公式編輯器,利用指標(biāo)生成策略。對于一些單向支持的工具,支持策略從工具進行抽取。


4、監(jiān)控自動化和自服務(wù)


前面標(biāo)準(zhǔn)化模型的內(nèi)容都準(zhǔn)備好之后,就具備了監(jiān)控自動化和自服務(wù)部署策略的前提。


自動化分為兩個層次:


  • 自動化,就是監(jiān)控的實施人員進行的自動化部署;

  • 自服務(wù),這個是面向?qū)I(yè)團隊運維人員的操作。自服務(wù)是自動化的更高階的階段,需要系統(tǒng)提供面向業(yè)務(wù)場景的、更加易用的交互界面。


實現(xiàn)過程中的技術(shù)要點,就是通過監(jiān)控工具驅(qū)動程序的開發(fā),實現(xiàn)平臺對底層監(jiān)控工具的變更操作,而且能夠屏蔽工具的差異性,快速接入各類工具。根據(jù)工具接口的完備度,有全驅(qū)動和半驅(qū)動之分,全驅(qū)動就是所有的操作都能在平臺層完成,半驅(qū)動就是常見的標(biāo)準(zhǔn)化策略部署,在平臺完成,一些特殊策略部署還需要到工具手工完成。 


正是有了驅(qū)動能力的不同,所以對于半驅(qū)動來說,我們還需要一個策略采集器,確保管理平臺有完整的工具策略。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


對于監(jiān)控自服務(wù)管理的執(zhí)行,那我們有一個原則:專業(yè)團隊的管理員的自助式的配置,是在監(jiān)控標(biāo)準(zhǔn)下的自服務(wù)。


典型場景是操作人員錄入設(shè)備信息,自動發(fā)現(xiàn)或者同步資源的信息,然后補充必要的對象信息,預(yù)覽自動匹配到的監(jiān)控策略,進行確認(rèn)后,下發(fā)生效。


在這個流程中,策略的匹配和綁定是基于監(jiān)控規(guī)則的,監(jiān)控規(guī)則是企業(yè)級定義和發(fā)布的監(jiān)控標(biāo)準(zhǔn),所以大家在進行自服務(wù)的時候,還是要以規(guī)則為準(zhǔn)。 


對于個性化策略的部署,技術(shù)上是可以支持的。目前在我們的實際使用中是要走ITSM流程審批過后,由監(jiān)控管理員去執(zhí)行非標(biāo)策略或個性化策略部署的。而且這種非標(biāo)的策略部署過后,我們是有評價機制來跟蹤的。


5、監(jiān)控評價


監(jiān)控評價模塊,用于事后量化評價每個應(yīng)用系統(tǒng)的監(jiān)控情況。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


評價主要是3個指標(biāo),監(jiān)控覆蓋率、監(jiān)控標(biāo)準(zhǔn)化率、超額布控率,這三個指標(biāo)在設(shè)計的時候,從管理上要求是逐級升高的:


1)監(jiān)控覆蓋率,是說需要有監(jiān)控,這是最基本的要求。計算公式是基于監(jiān)控指標(biāo)進行的。


2)監(jiān)控標(biāo)準(zhǔn)化率,是說除了有監(jiān)控,還應(yīng)該按照行里的標(biāo)準(zhǔn)策略進行監(jiān)控,比如標(biāo)準(zhǔn)的閾值是90%,如果某個服務(wù)器需要改為80%的閾值,那這就是不遵從標(biāo)準(zhǔn)了。所以監(jiān)控標(biāo)準(zhǔn)化率指標(biāo)是基于監(jiān)控策略進行計算的。


3)超額布控率,就是說前面的標(biāo)準(zhǔn)動作都做完了,如果管理員責(zé)任心強,又提了額外的監(jiān)控策略,那就是超額布控率,也是基于指標(biāo)計算的。


通過這樣三個指標(biāo),可以對我們的應(yīng)用系統(tǒng)的監(jiān)控完備度進行一個量化的評價和排名。有了這個排名后,那我們的管理機制就能夠發(fā)揮作用了。


監(jiān)控評價的目標(biāo)是以評促改?;谠u價的結(jié)果,我們或者進一步去完善監(jiān)控標(biāo)準(zhǔn),或者對于一些非標(biāo)的特例就要促進相應(yīng)的應(yīng)用系統(tǒng)進行整改,進一步符合監(jiān)控的規(guī)范。這樣一個持續(xù)改進的閉環(huán)就形成了。


6、監(jiān)控自動化和自服務(wù)


管理平臺還有一個比較重要的功能,維護期管理。這和報警管理以及標(biāo)準(zhǔn)化管理都有一些關(guān)系。這個是個常用的功能,技術(shù)上并不復(fù)雜,但也非常容易出問題。它直接影響了報警的有效性,管理的不好很容易出現(xiàn)漏報警或者誤報警。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


關(guān)于維護期使用,我們在多年的監(jiān)控運行中,吃了一些虧得到一些教訓(xùn),這會促進我們不斷優(yōu)化相關(guān)的功能。以下經(jīng)驗和大家分享:


1)維護期最多設(shè)置30天,單次超過24小時,就要進行二次確認(rèn),避免出現(xiàn)誤操作。


2)非周期的維護期內(nèi)發(fā)生的高級別報警,也要通知到管理員,避免把維護期報警和故障報警進行混淆。


3)出維護期前,管理員要去檢查維護期內(nèi)報警的狀態(tài),避免出現(xiàn)誤報警。


4)出維護期后,如果報警還沒有恢復(fù),那就要重新進入處置流程,避免遺漏報警。


此外,我們還定期導(dǎo)出報表,進行維護期的重檢,確認(rèn)維護期的有效性。


7、監(jiān)控管理的整體評價


作為監(jiān)控管理平臺,如何對我們整個監(jiān)控體系的運行效果進行評價,最直接的指標(biāo),是發(fā)現(xiàn)率和有效率。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


目前運維中心設(shè)定的KPI指標(biāo)是監(jiān)控發(fā)現(xiàn)率,就是監(jiān)控系統(tǒng)發(fā)現(xiàn)的故障占總體故障的百分比。我們的監(jiān)控主動發(fā)現(xiàn)率基本能保持在98%以上,對于監(jiān)控未主動發(fā)現(xiàn)的故障,有相當(dāng)大比例會引起業(yè)務(wù)影響,這也從側(cè)面也證明了監(jiān)控的重要性。


前面講的偏向于工具功能以及技術(shù)實現(xiàn),在這我還想強調(diào)一下體系的作用,體系包括人員的參與和管理流程:


1)人員各司其職很重要,一線人員、二線人員、專家、運維質(zhì)量管理人員、監(jiān)控管理的人員還有監(jiān)控系統(tǒng)建設(shè)的人員,都參與到系統(tǒng)運行中,而且通過二線應(yīng)用管理人員,開發(fā)項目組的人員也間接參與到整個監(jiān)控體系運轉(zhuǎn)中,盡職盡責(zé)。


2)我們做了很多基礎(chǔ)的管理工作和數(shù)據(jù)分析工作,通過監(jiān)控報表、事件報表,每天、每周、每月、每年的事件會,對報警相關(guān)的事件進行分析,持續(xù)的反饋和優(yōu)化監(jiān)控標(biāo)準(zhǔn)、補充策略。過去10年間,運維中心的領(lǐng)導(dǎo)能夠親身參與到這些工作中。堅持,所以才能讓我們的監(jiān)控系統(tǒng)持續(xù)優(yōu)化。


對于有效率指標(biāo),從真實有效的角度去度量,那我行監(jiān)控系統(tǒng)誤報很少,都能如實反應(yīng)生產(chǎn)的情況。如果站在一個更高的要求去理解這個指標(biāo),有效率表示的是事件的數(shù)量和報警的比值,提升有效率能夠減少無效報警的干擾,提升故障處置的效率。我們目前正在做的優(yōu)化是基于規(guī)則和場景,按照報警的根因和業(yè)務(wù)影響的分析,這兩個視角進行報警的合并和關(guān)聯(lián),減少孤立報警的數(shù)量,提升報警的有效率。


四、未來發(fā)展方向展望


最后我們對監(jiān)控系統(tǒng)的未來發(fā)展,做個展望??傮w的方向,我們認(rèn)為是向數(shù)字化運營的轉(zhuǎn)變。


光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路


目標(biāo)是提升對數(shù)字化運行態(tài)的洞察力和智能分析能力。這里面有4個方面:


1)數(shù)字化的思維的建立和數(shù)字化的監(jiān)控轉(zhuǎn)型。


2)基于這些大數(shù)據(jù),進一步豐富完善算法,推廣智能算法的應(yīng)用場景。


3)監(jiān)控管理和服務(wù)的融合,在強化監(jiān)控標(biāo)準(zhǔn)化管理的基礎(chǔ)上,還要更加快速的納管新的技術(shù)工具,提升自服務(wù)的應(yīng)用范圍和場景。


4)監(jiān)控云和云監(jiān)控。監(jiān)控云是以云原生方式構(gòu)建監(jiān)控系統(tǒng),提升彈性和敏捷的能力,加強工具整合;云監(jiān)控則是提升容器、k8s、分布式應(yīng)用的監(jiān)控能力,通過監(jiān)控API的部署和使用,把運維和開發(fā)部門進行打通,提升云應(yīng)用自身的主動監(jiān)控能力。


>>>>

Q&A


Q1:咱們有用到規(guī)則引擎嗎?


A:用到了Spring SpEL,正在研究Drools。


Q2:請問Ignite持久化到RDMS有使用嗎?


A:沒有使用Ignite自身的機制持久化到RDMS,我們做了IDUC模塊將所有告警的變更操作都同步到了RDMS,這個比Ignite本身持久化到RDMS更細致。


Q3:請問實時流事件處理是基于Ignite嗎?


A:不是,Ignite只是用來做存儲,實時流處理是我們自己開發(fā)的模塊。


Q4:請問咱們Ignite可以支持多大的告警量?


A:支持千萬級的實時告警量,支持億級的歷史告警量。


Q5: 監(jiān)控的指標(biāo)會有相應(yīng)的區(qū)分嗎?比如根據(jù)采集的手段:遠程或者本地?


A:指標(biāo)是一個抽象概念,跟具體的實現(xiàn)解耦。指標(biāo)只包含名稱、單位、數(shù)據(jù)類型等關(guān)鍵屬性。


Q6:您好,想了解這里介紹的各個功能,是基本都已經(jīng)實現(xiàn)的還是規(guī)劃為主呢?


A:大部分已經(jīng)實現(xiàn)。有一些功能還在推廣過程中,如監(jiān)控自服務(wù)和監(jiān)控評價功能,還在持續(xù)提升工具的覆蓋范圍。


Q7:請問現(xiàn)在智能化監(jiān)控落地的場景能講一下嗎?


A:交易基線分析、批量運行時長分析、交易異常點定位。


Q8:請問目前光大銀行的自動化運維達到什么程度了呢?


A:和監(jiān)控相關(guān)的自動化主要是監(jiān)控策略自動部署,以及報警產(chǎn)生后推送到自動化運維平臺和運維工具箱進行自動匹配。


Q9:請問表鏡像用的是什么技術(shù)和工具?


A:使用Oracle Golden Gate實現(xiàn)Oracle數(shù)據(jù)庫之間以及Oracle數(shù)據(jù)庫到Kafka的實時數(shù)據(jù)同步。


Q10:可以談一談監(jiān)控和CMDB,流程平臺的關(guān)聯(lián)關(guān)系嗎?


A:監(jiān)控對象的全集來自CMDB,目前是每天自動同步;和流程平臺,目前已經(jīng)實現(xiàn)了變更流程的維護期自動設(shè)置,還有報警轉(zhuǎn)事件工單流程。


Q11:請問目前每天數(shù)據(jù)量有多少?


A:存量活動告警2萬以內(nèi),歷史告警新增記錄數(shù)每天10w+。


Q12:晚上批處理監(jiān)控有沒有比較好的方法呢?特別是關(guān)鍵路徑上的批處理時間的監(jiān)控


A:我們是根據(jù)批量運行的歷史數(shù)據(jù)計算批量運行時長的基線,再根據(jù)基線進行報警。


Q13:TCP鏈路追蹤是指在網(wǎng)卡層進行分布式鏈路采集嗎?


A:我行的TCP鏈路監(jiān)控是通過網(wǎng)絡(luò)交換機旁路抓包的方式對TCP報文進行分析和監(jiān)控。


Q14:這個監(jiān)控平臺都是自己開發(fā)的嗎?沒有引入一些開源的監(jiān)控工具嗎?


A:基于開源工具進行自主開發(fā)的,具體的開源工具正文有介紹。


Q15:想了解下在存儲方面如何做統(tǒng)一監(jiān)控呢?


A:統(tǒng)一監(jiān)控平臺通過接收存儲設(shè)備推送的trap報警實現(xiàn)故障監(jiān)控。獨立運行的存儲管理平臺實現(xiàn)存儲設(shè)備及SAN交換機的性能監(jiān)控。


Q16:請問做自研的監(jiān)控平臺,從哪方面入手更好?比如先做好數(shù)據(jù)采集?用哪些開源技術(shù)棧比較好?


A:需要看具體的需求和資源投入了,最好還是做好提前規(guī)劃設(shè)計。最大化利用開源工具的能力,比如Prometheus、Zabbix。


Q17:請問監(jiān)控數(shù)據(jù)在問題故障根因定位等方面是如何使用,在哪些方面或環(huán)節(jié)必須基于監(jiān)控數(shù)據(jù)?


A:根因定位一般需要告警數(shù)據(jù)和配置數(shù)據(jù)兩類數(shù)據(jù),告警數(shù)據(jù)指告警記錄本身,配置數(shù)據(jù)指描述對象的資源數(shù)據(jù)、描述業(yè)務(wù)的業(yè)務(wù)數(shù)據(jù)等等元描述數(shù)據(jù)。


Q18:請問應(yīng)用的監(jiān)控數(shù)據(jù)采集是通過什么方式?


A:應(yīng)用監(jiān)控數(shù)據(jù)采集方式主要包括:本地代理實時采集;外部服務(wù)探測;旁路網(wǎng)絡(luò)抓包;數(shù)據(jù)庫流水表同步鏡像等方式。


Q19:請問自動發(fā)現(xiàn)引擎用的是Zabbix還是自研呢?


A:服務(wù)器相關(guān)的自動發(fā)現(xiàn)是基于Zabbix的,網(wǎng)絡(luò)設(shè)備發(fā)現(xiàn)和配置采集是自研的。


Q20:請問帶外硬件設(shè)備的監(jiān)控,和帶內(nèi)系統(tǒng)監(jiān)控,關(guān)聯(lián)關(guān)系建立方面,有相關(guān)經(jīng)驗可以分享嗎?謝謝。


A:cmdb實現(xiàn)虛擬化OS和物理設(shè)備的收集匯總和關(guān)聯(lián)關(guān)系的建立。監(jiān)控同步cmdb的數(shù)據(jù)獲取相關(guān)的關(guān)系。


Q21:咱們機器學(xué)習(xí)算法也是在分布式內(nèi)存庫內(nèi)做嗎?


A:不是,是在我們的大數(shù)據(jù)平臺做的。


Q22:請教一下,告警收斂怎么實現(xiàn)?


A:在報警處理層面,通過預(yù)置場景,比如服務(wù)器宕機、交易繁忙等關(guān)聯(lián)規(guī)則,實現(xiàn)報警關(guān)聯(lián)和抑制。在通知層面,對于報警狀態(tài)未發(fā)生變化的情況,不會重復(fù)發(fā)送報警,且會對通知短信進行壓縮處理。


Q23:咱們有服務(wù)撥測相關(guān)的監(jiān)控功能嗎?可以介紹一下嗎?


A:我們采購了互聯(lián)網(wǎng)廠商的服務(wù),從全國各運營商對我行外網(wǎng)應(yīng)用進行撥測,包括App和Web服務(wù),監(jiān)控數(shù)據(jù)實時同步到行內(nèi)監(jiān)控系統(tǒng)。在內(nèi)網(wǎng)建設(shè)了私有化的撥測平臺和探點,通過錄制腳本和定期回放的方式監(jiān)控重點應(yīng)用。


Q24:告警關(guān)聯(lián)是如何實現(xiàn)的?可否舉個例子呢?


A:空間上,通過告警對象的關(guān)聯(lián)關(guān)系,比如同一個應(yīng)用系統(tǒng)下,如果數(shù)據(jù)庫發(fā)生告警,那么依賴他的所有中間件、應(yīng)用都會產(chǎn)生告警;時間上,通過時間窗,比如某個告警發(fā)生的前后幾分鐘之內(nèi)的所有告警。規(guī)則引擎會根據(jù)上述條件對報警進行實時分析,同時在這兩個維度有關(guān)聯(lián)的,才會進行告警的關(guān)聯(lián)。


Q25:請問告警風(fēng)暴和根因分析這塊兒,可以分享一下嗎?


A:目前采用了分布式內(nèi)存數(shù)據(jù)庫和分布式并發(fā)處理,完全可以應(yīng)付告警風(fēng)暴;根因分析是根據(jù)預(yù)置場景規(guī)則進行報警的關(guān)聯(lián)和壓制。


Q26:請問老師可以分享一下指標(biāo)的標(biāo)準(zhǔn)化體系建設(shè)嗎?


A:監(jiān)控指標(biāo)體系最初建立是多年監(jiān)控系統(tǒng)運行經(jīng)驗的積累?,F(xiàn)階段由監(jiān)控團隊負責(zé)監(jiān)控指標(biāo)的維護和管理,定期由專業(yè)團隊和各領(lǐng)域?qū)<疫M行重檢。


特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長按關(guān)注一下:

光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路

長按訂閱更多精彩▼

光大銀行監(jiān)控平臺實踐,含詳細工具及架構(gòu)選型思路

如有收獲,點個在看,誠摯感謝

免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關(guān)機構(gòu)授權(quán)發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權(quán)益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關(guān)鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術(shù)解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關(guān)鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術(shù)公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認(rèn)證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關(guān)鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務(wù)能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務(wù)中斷的風(fēng)險,如企業(yè)系統(tǒng)復(fù)雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務(wù)連續(xù)性,提升韌性,成...

關(guān)鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關(guān)鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關(guān)鍵字: 華為 12nm EDA 半導(dǎo)體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務(wù)董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權(quán)最終是由生態(tài)的繁榮決定的。

關(guān)鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應(yīng)對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務(wù)引領(lǐng)增長 以科技創(chuàng)新為引領(lǐng),提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關(guān)鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術(shù)學(xué)會聯(lián)合牽頭組建的NVI技術(shù)創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術(shù)創(chuàng)新聯(lián)...

關(guān)鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(shù)(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關(guān)鍵字: BSP 信息技術(shù)
關(guān)閉
關(guān)閉