于衛(wèi)國+呂勤
摘要:金融行業(yè)為適應互聯(lián)網(wǎng)業(yè)務的挑戰(zhàn)需要建設自動化運維系統(tǒng),在傳統(tǒng)軟件上支持自動化運維系統(tǒng)需要構(gòu)建以唯一ID為基礎的日志和流水體系,進行數(shù)據(jù)信息的匯聚、關(guān)聯(lián)才能支持大數(shù)據(jù)平臺智能分析、自動應急處理。
關(guān)鍵詞:ID;雙態(tài)IT;自動運維
中圖分類號:TP391 文獻標識碼:A 文章編號:1007-9416(2017)06-0056-02
1 雙態(tài)系統(tǒng)模型
隨著互聯(lián)網(wǎng)創(chuàng)新企業(yè)給傳統(tǒng)金融業(yè)的帶來的壓力,傳統(tǒng)金融IT迫切需要改進IT整體治理體系。為幫助企業(yè)應對“互聯(lián)網(wǎng)+”轉(zhuǎn)型中遇到的挑戰(zhàn),聯(lián)想等十二家企業(yè)提出“雙態(tài)IT”方法論,使企業(yè)梳理實現(xiàn)“互聯(lián)網(wǎng)+”轉(zhuǎn)型?!半p態(tài)IT”聚焦于企業(yè)業(yè)務的穩(wěn)、敏分析,幫助企業(yè)IT 部門采用傳統(tǒng)的集中式和新興的互聯(lián)網(wǎng)分布式等信息技術(shù)架構(gòu),構(gòu)建一套穩(wěn)態(tài)、敏態(tài)和諧共存的新型IT 架構(gòu)。穩(wěn)態(tài)IT的特征是業(yè)務按照傳統(tǒng)方式經(jīng)營,戰(zhàn)略目標明確,業(yè)務流程相對成熟;敏態(tài)IT業(yè)務則采用“互聯(lián)網(wǎng)+”思維模式,業(yè)務模式本身處在不斷探索、優(yōu)化、總結(jié)的過程,需要通過不斷試錯來逐步完善。
對于布局在電子商務、金融支付類的傳統(tǒng)企業(yè)最為迫切的解決快速和高質(zhì)量的交付問題、自動運維(應急處理、資源管理、問題分析處理)、自動監(jiān)控等問題。這些企業(yè)IT治理向敏態(tài)轉(zhuǎn)型,學習敏態(tài)的開發(fā)、測試和運維一體化涉及組織架構(gòu)調(diào)整難度較大,而對現(xiàn)有系統(tǒng)優(yōu)化改造,優(yōu)化自動運維、自動監(jiān)控流程更易實現(xiàn)。
2 穩(wěn)態(tài)系統(tǒng)運維問題
金融行業(yè)傳統(tǒng)業(yè)務為穩(wěn)態(tài)業(yè)務模型,傳統(tǒng)IT為IOE架構(gòu),每個業(yè)務系統(tǒng)為單體應用,內(nèi)部調(diào)用流程固定,系統(tǒng)建設是逐步搭積木,未規(guī)劃內(nèi)部數(shù)據(jù)交互格式。按照業(yè)務發(fā)展的順序形成了由核心賬戶向外圍渠道、外圍增值業(yè)務擴展的層次架構(gòu)。
傳統(tǒng)企業(yè)IT運行中心在運維監(jiān)控主要面臨以下問題。
一是信息孤島問題。(1)不能綜合使用日志和報錯信息。運行人員以數(shù)據(jù)庫交易記錄為主要依據(jù),未自動關(guān)聯(lián)業(yè)務系統(tǒng)內(nèi)部各模塊記錄的大量日志和報錯信息。(2)不能關(guān)設備信息。系統(tǒng)管理員只分析CPU、IO、內(nèi)存、磁盤空間的靜態(tài)數(shù)據(jù);數(shù)據(jù)庫只分析自身資源使用情況,沒有與應用日志和錯誤信息關(guān)聯(lián)。(3)使用系統(tǒng)監(jiān)控信息、應用日志、數(shù)據(jù)庫記錄的運維經(jīng)驗無法與其他運行人員共享。
二是問題分析定位慢。運維以人工判斷分析為主,自動化程度低。(1)由于信息孤島,出現(xiàn)問題后錯誤信息會大量產(chǎn)生,很難判斷出根源是應用、網(wǎng)絡、系統(tǒng)。(2)運行人員分析的日志、程序報錯信息、交易流水等沒有自動關(guān)聯(lián),運行人員從數(shù)據(jù)庫中查詢符合條件的流水集合,確定其中一條記錄,選擇業(yè)務主鍵,打開日志文件,根據(jù)業(yè)務主鍵搜索主機日志中關(guān)聯(lián)記錄,根據(jù)經(jīng)驗分析日志,給出問題描述。
三是應急響應慢。故障處理、資源擴展人工操作。(1)應急處理時人工根據(jù)各類信息判斷問題原因,根據(jù)應急處理預案進行排查處理,恢復業(yè)務,處理時間較長。(2)系統(tǒng)資源只能采用硬件冗余,按照最大峰值購買和配置資源,平時浪費資源,一旦交易出現(xiàn)爆發(fā)增長無法應對。
解決傳統(tǒng)系統(tǒng)的運維關(guān)鍵在于把各類信息有效匯聚關(guān)聯(lián)。以信息流為切入點,對于每一個內(nèi)外部交易請求生成日志ID鍵,該日志ID鍵沒有業(yè)務屬性、僅用于標識該請求,并貫穿于整個交易處理環(huán)節(jié)。在應用數(shù)據(jù)庫中定義業(yè)務ID鍵,業(yè)務ID鍵與日志ID鍵關(guān)聯(lián)。以這兩類ID為基礎構(gòu)建大數(shù)據(jù)分析平臺,使數(shù)據(jù)聚合、關(guān)聯(lián),建模自動化分析,形成自動執(zhí)行指令;同時在IT基礎架構(gòu)支持軟件定義資源,配合指令執(zhí)行應急策略。
3 敏態(tài)系統(tǒng)運維
新型互聯(lián)網(wǎng)企業(yè)自動化運維有以下特點。一是用戶或業(yè)務變化率大,交易量大、瞬間產(chǎn)生巨大流量,要實時分析海量日志、報警信息、交易流。二是系統(tǒng)架構(gòu)微服務化、服務調(diào)用動態(tài)化,運維系統(tǒng)智能化發(fā)現(xiàn)問題、自動化處理問題、自動隔離問題模塊。三是軟件定義運維成為發(fā)展趨勢、運維軟件平臺PAAS化。
3.1 消除信息孤島
規(guī)范日志格式,使用統(tǒng)一的日志方法類庫;在數(shù)據(jù)輸入和輸出的關(guān)鍵點埋點,即規(guī)范數(shù)據(jù)采集位置和深度;部署統(tǒng)一的日志收集服務。建立端到端全棧監(jiān)控體系,從用戶端的各類客戶端(手機、PAD、瀏覽器)進行采樣、到應用服務器信息聚集、再到基礎架構(gòu)(中間件、數(shù)據(jù)庫、網(wǎng)絡、服務器、云平臺)監(jiān)控數(shù)據(jù)。
3.2 大數(shù)據(jù)數(shù)據(jù)分析
使用大數(shù)據(jù)技術(shù)進行數(shù)據(jù)采集、格式化、集中存儲。使用分析引擎、關(guān)鍵字解析處理數(shù)據(jù),基于經(jīng)驗沉淀建立分析模型,進行自學習、預測風險、異常預警,從而實現(xiàn)運維分析的實時化、自動化、智能化。
3.3 構(gòu)建快速自動處理機制
以自動化配置的IT基礎架構(gòu)為基礎,敏態(tài)管理采用微服務架構(gòu)、云平臺、容器技術(shù)。主機集群化、虛擬化,摒棄小型機,以低成本的PC分布式集群為基礎支持動態(tài)擴展。大量使用云平臺、容器DOCKER技術(shù),以便于服務動態(tài)擴展。以軟件定義服務、軟件定義資源為管理手段提升運維響應速度。阿里云平臺、AWS等開放云平臺都提供的接口調(diào)用,可以實現(xiàn)分鐘級別的虛擬機申請, 而DOCKER則能夠作為秒級的申請和部署。
企業(yè)通過構(gòu)建統(tǒng)一數(shù)據(jù)、大數(shù)據(jù)分析、微服務和容器等技術(shù),實現(xiàn)了以數(shù)據(jù)聚合關(guān)聯(lián)為基礎,以建模分析和智能分析為依據(jù),以自動化執(zhí)行為結(jié)果的敏態(tài)運維體系。系統(tǒng)運維由手工向智能自動化轉(zhuǎn)變,自動判斷系統(tǒng)哪些節(jié)點可能有問題,自動隔離,恢復業(yè)務。
3.4 典型應用
淘寶運維體系彈性化實現(xiàn)。(1)每個URL請求進來都會生成一個唯一TraceID,TraceID會出現(xiàn)在所有服務調(diào)用、數(shù)據(jù)庫、緩存、消息訪問的日志中。TraceID含IP地址、創(chuàng)建時間、順序數(shù)。(2)為記錄各內(nèi)部服務調(diào)用順序還設計了RcpID,用于標記服務調(diào)用嵌套關(guān)系和日志埋點的順序。這樣每條日志都含以下信息:TraceID、RcpID、開始時間、調(diào)用類型、對端IP、處理耗時、處理結(jié)果、數(shù)據(jù)傳輸量(2)每臺設備上都有代理服務,將日志采集到一個實時分析層,分析層按照格式拆分日志,發(fā)送給分布式存儲HDFS,在Hadoop大數(shù)據(jù)平臺、使用MapReduce進行關(guān)鍵字分析處理。(3)數(shù)據(jù)采集秒級集中,實時分析性能、流量、穩(wěn)定性、資源使用情況,并根據(jù)分析模型,彈性控制模塊對資源自動調(diào)度、對故障自動處理。運維監(jiān)控體系完全“彈性化”,實現(xiàn)從人工控制到秒級自動調(diào)度。endprint
4 傳統(tǒng)系統(tǒng)優(yōu)化實踐
作為國內(nèi)線下最大的第三方支付公司,銀聯(lián)商務的IT系統(tǒng)是經(jīng)過十多年的建設逐步發(fā)展起來,有傳統(tǒng)銀行卡、預付費卡系統(tǒng),也有傳統(tǒng)互聯(lián)網(wǎng)業(yè)務系統(tǒng)、以及移動互聯(lián)網(wǎng)系統(tǒng),各個系統(tǒng)交互報文有8583、XML、JSON、固定格式等。IT條線制定了分步實現(xiàn)數(shù)據(jù)關(guān)聯(lián)聚合、數(shù)據(jù)標準化問題、數(shù)據(jù)智能分析、運維自動化的計劃。
4.1 新建系統(tǒng)構(gòu)建ID規(guī)范
制訂日志ID鍵和業(yè)務ID鍵規(guī)范、應用埋點規(guī)范和日志格式規(guī)范,確保新業(yè)務系統(tǒng)或新建子系統(tǒng)內(nèi)部消除數(shù)據(jù)孤島。新建的移動支付交易系統(tǒng)使用PC Server集群,用Java開發(fā),用ZooKeeper、Dubbo、Mysql等新技術(shù)。系統(tǒng)日志使用log4j規(guī)范,以UUID為唯一索引加入各行日志中,在交易流水表中的訂單號關(guān)聯(lián)各類業(yè)務數(shù)據(jù)主鍵。使用Logstash日志管理工具,集成Elastic Search、Kibana實現(xiàn)日志的集中、快速關(guān)聯(lián)分析、監(jiān)控可視化。
4.2 原有重要關(guān)鍵系統(tǒng)優(yōu)化改造
按照非侵入性、最小變動原則先進行日志ID、日志規(guī)范的整改。由于原重要系統(tǒng)之間修改交互報文格式風險很大,無法增加唯一日志ID,這樣也無法在每一行日志中加上日志ID。銀商采用的方案是先統(tǒng)一替換日志記錄函數(shù),確保特定系統(tǒng)內(nèi)部的日志都有本地唯一日志ID;在關(guān)鍵通信節(jié)點埋點,在業(yè)務系統(tǒng)之間建立不同ID對應關(guān)系記錄,并梳理每個系統(tǒng)內(nèi)部日志ID鍵與業(yè)務ID鍵的對應關(guān)系。這樣當數(shù)據(jù)大集中后,就可以通過二次查找的方式串聯(lián)所有日志。
比如A系統(tǒng)日志ID是“設備號+終端流水”,A系統(tǒng)內(nèi)部日志都帶“設備號+終端流水”;B系統(tǒng)日志ID是“內(nèi)部系統(tǒng)流水”,B系統(tǒng)內(nèi)部日志都帶“內(nèi)部系統(tǒng)流水”。在A或B的通信層每一條從A到B的交易系統(tǒng)都增加一條日志記錄:“A設備號+終端流水”對應“B內(nèi)部系統(tǒng)流水”,這樣任何一條A的日志都可以找到對應的B日志,當日志導入大數(shù)據(jù)平臺匯聚后就可以很容易關(guān)聯(lián)了。
4.3 建立新系統(tǒng)與傳統(tǒng)系統(tǒng)的日志ID關(guān)聯(lián)
新系統(tǒng)按照日志ID鍵和業(yè)務ID鍵規(guī)范實施,但新系統(tǒng)的UUID無法通過報文傳遞給老系統(tǒng)。解決方案類似4.2,新系統(tǒng)在通信層發(fā)送和接收報文時記錄UUID和目標系統(tǒng)的日志ID對應關(guān)系,盡量不改老系統(tǒng),老系統(tǒng)只要保證內(nèi)部日志能夠有唯一日志ID即可。
4.4 建設聚合跨系統(tǒng)的交易日志和交易流水的“自助運維平臺”
首先聚合全量數(shù)據(jù),除了各個新老應用系統(tǒng)的日志和交易流水外,還有各類客戶端(手機、PAD、瀏覽器)和POS機上采樣的操作數(shù)據(jù)、行為分析數(shù)據(jù)。然后使用Hadoop、MapReduce、Hive等技術(shù)對數(shù)據(jù)實時分析性能、流量,并根據(jù)歷史問題構(gòu)建分析模型實時預警。目前平臺已投產(chǎn),初步實現(xiàn)了問題快速排查,基于大數(shù)據(jù)的智能分析還在建設中。
5 結(jié)語
敏態(tài)系統(tǒng)設計基于容器、基于微服務、云平臺、大數(shù)據(jù)等新技術(shù)可以達到快速擴展、自動部署、自動運維、智能運維,是未來新建系統(tǒng)的首選。但是很多傳統(tǒng)企業(yè)IT的管理體系還未做好準備,無法對敏態(tài)管理進行有效支持。在如何保護現(xiàn)有IT資產(chǎn)、做好原有系統(tǒng)平穩(wěn)過渡上,最好的方式是對于傳統(tǒng)核心軟件系統(tǒng)進行非侵入式改造,逐步從日志信息采集、交易日志分析等外圍的運維監(jiān)控優(yōu)化入手,提供更好運維支持,再逐步改進信息質(zhì)量的前提下提高自動化和智能化程度,使傳統(tǒng)系統(tǒng)循序漸進優(yōu)化。
目前銀商系統(tǒng)已經(jīng)有計劃的對原有系統(tǒng)進行日志規(guī)范改造、構(gòu)建大數(shù)據(jù)分析平臺,未來還需要在以下方面持續(xù)改進:(1)向全棧數(shù)據(jù)聚合改進,增加POS終端、自助設備、客戶端等數(shù)據(jù)。增加基礎架構(gòu)(中間件、數(shù)據(jù)庫、網(wǎng)絡、服務器、云平臺)監(jiān)控數(shù)據(jù)的聚集和關(guān)聯(lián),這一項工作需要設備廠商的支持。(2)基于大數(shù)據(jù)的智能分析模型還要不斷升級,要能夠自動預測和實時預警,這樣才能從手工操作向自動化、智能化改進。(3)全面推進云平臺、應用微服務化、容器化還需要逐步推進。要實現(xiàn)對資源自動調(diào)度、對故障自動處理沒有基礎設施的虛擬化、應用層容器化是無法推進的。
參考文獻
[1]鐘華.企業(yè)IT架構(gòu)轉(zhuǎn)型之路[J].機械工業(yè)出版社,2017年,P132-156.
[2]王漢明.銀行信息系統(tǒng)架構(gòu)[J].機械工業(yè)出版社,2017年,P38,P104-114.
[3]胡喜.支付寶高可用系統(tǒng)架構(gòu)的演變[J].百度文庫,2016年,P32-38.
Abstract:In order to meet the challenge of the Internet industry, the financial industry needs to build the automatic operation and maintenance software system. In the traditional financial software system, the automatic operation and maintenance system needs to construct the log and water system based on the unique ID, and the data information can be aggregated to support the large data Platform intelligent analysis, automatic emergency treatment.
Key Words:bimodel state IT; automatic operation and maintenanceendprint