基于統(tǒng)一管控的基礎(chǔ)平臺(tái)性能提升研究

湯劍 胡洪新

摘要：描述信息化基礎(chǔ)平臺(tái)性能下降的原因，提出使用資源及應(yīng)用狀態(tài)集中監(jiān)控、事件處理狀態(tài)跟蹤、安全漏洞更新統(tǒng)一管理等方法來(lái)提升平臺(tái)性能

關(guān)健詞：統(tǒng)一管控;事件跟蹤;數(shù)據(jù)中心;安全

中圖分類(lèi)號(hào)：TP393 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2019）31-0269-02

信息化是實(shí)現(xiàn)業(yè)務(wù)高效運(yùn)行的重要手段，細(xì)化到具體業(yè)務(wù)就對(duì)應(yīng)著一個(gè)個(gè)信息化的應(yīng)用，信息化基礎(chǔ)平臺(tái)的計(jì)算性能及系統(tǒng)運(yùn)行穩(wěn)定性直接影響到應(yīng)用的可用性，應(yīng)用的是否可用決定業(yè)務(wù)的可持續(xù)性，保障信息化基礎(chǔ)平臺(tái)的性能是線上業(yè)務(wù)流暢運(yùn)行的基礎(chǔ)必要條件。

1問(wèn)題現(xiàn)狀

實(shí)際使用中經(jīng)常因缺少高效的問(wèn)題修復(fù)與安全保障支持，基礎(chǔ)平臺(tái)常發(fā)生整體性能下降的現(xiàn)象，常見(jiàn)的主要原因包括：

1.1應(yīng)用的全面可用性監(jiān)控信息不完整，故障發(fā)生的歷史情況無(wú)法跟蹤

隨著信息化的不斷推進(jìn)，每年建設(shè)的應(yīng)用數(shù)量在逐年增加，應(yīng)用的使用頻率直接和業(yè)務(wù)期直接相關(guān)，有些應(yīng)用使用量、使用面較廣，每天都有很多人在訪問(wèn)使用，有些應(yīng)用使用的頻率較低，一年中只有在業(yè)務(wù)期的時(shí)候使用，應(yīng)用的質(zhì)量直接由設(shè)計(jì)應(yīng)用的工程技術(shù)人員的水平?jīng)Q定，雖然應(yīng)用在上線前已經(jīng)做了很多測(cè)試工作，但這并不能保證應(yīng)用運(yùn)行時(shí)完全穩(wěn)定可靠，一些設(shè)計(jì)較差的應(yīng)用在遇到一些意外故障時(shí)，可能會(huì)大量消耗計(jì)算資源，較小范圍影響可能涉及相關(guān)應(yīng)用故障，若數(shù)據(jù)層面的讀寫(xiě)鎖故障可能會(huì)影響數(shù)據(jù)庫(kù)系統(tǒng)，進(jìn)行影響整個(gè)平臺(tái)的性能下降。缺乏全面的監(jiān)控信息與故障歷史記錄會(huì)降低問(wèn)題處理效率，例如一個(gè)關(guān)聯(lián)多個(gè)應(yīng)用的接口故障了，首先的現(xiàn)象是某一應(yīng)用不可用，排除問(wèn)題并不能快速定位到故障源頭，導(dǎo)致相關(guān)應(yīng)用相續(xù)出現(xiàn)故障，偶發(fā)性還會(huì)引起平臺(tái)整體性能下降，若不能及時(shí)找到問(wèn)題源并修復(fù)，給使用者的體驗(yàn)是應(yīng)用反應(yīng)慢、基礎(chǔ)平臺(tái)性能的不行。

1.2故障事件修復(fù)響應(yīng)不及時(shí)，故障問(wèn)題修復(fù)處理的歷史情況缺乏關(guān)聯(lián)性記錄

故障的修復(fù)時(shí)間直接影響到用戶(hù)的使用體驗(yàn)，若每次都是現(xiàn)場(chǎng)發(fā)揮臨陣出招去修復(fù)問(wèn)題，一半以上的情況會(huì)耽誤修復(fù)的最佳時(shí)間，同時(shí)發(fā)生了多個(gè)問(wèn)題丟個(gè)現(xiàn)場(chǎng)工程師，現(xiàn)場(chǎng)人員一般是按照問(wèn)題的順序一個(gè)個(gè)的處理，但現(xiàn)在業(yè)務(wù)系統(tǒng)之間都有相互關(guān)聯(lián)性，有時(shí)出現(xiàn)故障的應(yīng)用并非問(wèn)題源頭，該問(wèn)題可能是由其他應(yīng)用故障后關(guān)聯(lián)引起的，這時(shí)非常需要借助歷史問(wèn)題處理情況作為有效參考，通過(guò)借鑒歷史問(wèn)題處理情況可以有效協(xié)助問(wèn)題源定位，縮短事件處理的時(shí)間。再有事件處理任務(wù)被分配到具體人員后，經(jīng)過(guò)分析后發(fā)現(xiàn)需要多方協(xié)同處理，在協(xié)同處理過(guò)程中常會(huì)出現(xiàn)溝通內(nèi)容有偏差及問(wèn)題響應(yīng)不及時(shí)，因工程人員同時(shí)負(fù)責(zé)的工作任務(wù)一般較多，時(shí)間久了難免會(huì)出現(xiàn)信息記錄模糊或任務(wù)遺忘的情況，不能及時(shí)有效跟蹤、隔離、修復(fù)故障可能引起連鎖反應(yīng)，進(jìn)行影響應(yīng)用的用戶(hù)使用體驗(yàn)及意外降低整體平臺(tái)性能。

1.3漏洞問(wèn)題或安全問(wèn)題的響應(yīng)及安全防護(hù)調(diào)整變更效率低

信息化系統(tǒng)一般是應(yīng)用軟件，與應(yīng)用軟件相關(guān)聯(lián)的包括中間件、操作系統(tǒng)、數(shù)據(jù)庫(kù)等，這一系列軟件中的任意一個(gè)被曝出現(xiàn)漏洞問(wèn)題都會(huì)影響整體的運(yùn)行穩(wěn)定性與安全性，最基礎(chǔ)的方法是發(fā)現(xiàn)一個(gè)，對(duì)比資產(chǎn)清單逐個(gè)修復(fù)，操作是人工實(shí)施的為主，人工操作難免會(huì)出現(xiàn)遺漏，隨著計(jì)算資源與應(yīng)用的資源的不斷擴(kuò)大，修復(fù)的工作量在越來(lái)越大，出現(xiàn)遺漏的量一定會(huì)隨之增加，沒(méi)有有效的事件處理記錄及處理復(fù)查審核，很難保證每次的漏洞修復(fù)已經(jīng)全面完成了，加強(qiáng)人工處理復(fù)查則工作量大、效率低。

2改進(jìn)方法

經(jīng)過(guò)分析以上問(wèn)題同時(shí)兼顧安全管理的需求，設(shè)計(jì)使用統(tǒng)一管理平臺(tái)的概念來(lái)改善問(wèn)題，主要包括資源及應(yīng)用信息全面監(jiān)控、問(wèn)題修復(fù)全流程跟蹤、漏洞安全問(wèn)題批量處理。

2.1資源及應(yīng)用統(tǒng)一監(jiān)測(cè)管理

資源狀態(tài)監(jiān)測(cè)主要包括基礎(chǔ)存儲(chǔ)設(shè)施、計(jì)算設(shè)備、網(wǎng)絡(luò)設(shè)備等資源的狀態(tài)監(jiān)控，這些資源的狀態(tài)直接決定信息化基礎(chǔ)平臺(tái)的工作狀態(tài)。存儲(chǔ)設(shè)施一般來(lái)自不同廠商，提供的接口以SNMP協(xié)議為主，監(jiān)控主要采集設(shè)備報(bào)警狀態(tài)、設(shè)備性能狀態(tài)、磁盤(pán)占用比例等，采集報(bào)警狀態(tài)用于及時(shí)獲取磁盤(pán)故障、控制器故障等信息，并及時(shí)向廠商報(bào)修，避免了問(wèn)題進(jìn)一步擴(kuò)大及減少人工巡檢工作量，采集設(shè)備性能狀態(tài)用于資源動(dòng)態(tài)調(diào)整參考，基礎(chǔ)平臺(tái)一般同時(shí)有多套不同品牌的存儲(chǔ)設(shè)備，每套存儲(chǔ)上存儲(chǔ)著不同批次的應(yīng)用，隨著應(yīng)用業(yè)務(wù)期的來(lái)臨部分應(yīng)用的業(yè)務(wù)量有上升，關(guān)聯(lián)存儲(chǔ)設(shè)備的讀寫(xiě)數(shù)據(jù)量也會(huì)隨之增加，當(dāng)讀寫(xiě)量到達(dá)一定程度存儲(chǔ)性能會(huì)下降，參照采集的存儲(chǔ)集性能狀態(tài)信息，及時(shí)將應(yīng)用業(yè)務(wù)或虛機(jī)遷移到負(fù)載較輕的虛機(jī)，進(jìn)而提升平臺(tái)服務(wù)性能。網(wǎng)絡(luò)設(shè)備的監(jiān)控采集使用SNMP協(xié)議，主要采集設(shè)備的性能狀態(tài)及流量信息，采集的數(shù)據(jù)用于監(jiān)控網(wǎng)絡(luò)的整體健康狀態(tài)及異常流量發(fā)現(xiàn)，通過(guò)發(fā)現(xiàn)網(wǎng)絡(luò)設(shè)備負(fù)載及流量的異常變化，及時(shí)做好異常應(yīng)急處理準(zhǔn)備，較多情況是網(wǎng)絡(luò)或應(yīng)用被攻擊了。計(jì)算資源方面主要采集計(jì)算設(shè)備的CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)使用量及報(bào)警信息，通過(guò)收集報(bào)警信息及時(shí)在計(jì)算設(shè)備發(fā)生故障的第一時(shí)間進(jìn)行報(bào)修，計(jì)算資源一般包括多個(gè)不同架構(gòu)技術(shù)的軟硬件設(shè)備，通過(guò)統(tǒng)一的信息收集與分析可以及時(shí)發(fā)現(xiàn)那個(gè)計(jì)算資源的計(jì)算負(fù)載量比較大、哪個(gè)計(jì)算資源的網(wǎng)絡(luò)流量比較大、哪個(gè)計(jì)算資源長(zhǎng)期工作在高負(fù)荷狀態(tài)下，通過(guò)這些信息的定期匯總與歷史數(shù)據(jù)分析，及時(shí)在維護(hù)期內(nèi)進(jìn)行應(yīng)用資源配置調(diào)整，進(jìn)行提升整體平臺(tái)的性能負(fù)載狀態(tài)。

應(yīng)用的統(tǒng)一監(jiān)控管理分成主機(jī)狀態(tài)信息監(jiān)控及應(yīng)用狀態(tài)信息監(jiān)控二部分，主機(jī)狀態(tài)信息的監(jiān)控使用SNMP及客戶(hù)端信息采集相結(jié)合的方式，SNMP協(xié)議提供的主機(jī)監(jiān)控項(xiàng)一般包括CPU、內(nèi)存、磁盤(pán)空余空間、網(wǎng)絡(luò)流量等標(biāo)準(zhǔn)信息的收集，有些情況下需要依據(jù)主機(jī)部署的應(yīng)用監(jiān)控應(yīng)用對(duì)應(yīng)的端口狀態(tài)、關(guān)鍵文件變動(dòng)、目錄內(nèi)容的變化等，使用SNMP協(xié)議一般無(wú)法完成該功能，需要使用對(duì)應(yīng)的客戶(hù)端軟件來(lái)完成信息收集與傳送，通過(guò)以上信息的收集實(shí)現(xiàn)主機(jī)性能的監(jiān)測(cè)與及時(shí)調(diào)整。應(yīng)用狀態(tài)信息的監(jiān)控一般采集用無(wú)客戶(hù)端模式，在管理平臺(tái)上使用HTTP監(jiān)測(cè)或TCP監(jiān)測(cè)插件來(lái)監(jiān)控應(yīng)用服務(wù)狀態(tài)是否可用，在管理平臺(tái)對(duì)監(jiān)控的應(yīng)用依據(jù)業(yè)務(wù)邏輯進(jìn)行關(guān)聯(lián)性配置與描述，當(dāng)應(yīng)用問(wèn)題發(fā)生時(shí)依據(jù)業(yè)務(wù)關(guān)聯(lián)性描述應(yīng)用狀態(tài)能較精確的發(fā)現(xiàn)問(wèn)題的源頭，進(jìn)而保障了整體平臺(tái)性能提升。

2.2事件處理全面跟蹤

依據(jù)基礎(chǔ)的計(jì)算資源池、主機(jī)資源、應(yīng)用信息、網(wǎng)絡(luò)IP資源建立基礎(chǔ)資源庫(kù)，依據(jù)常用事件處理規(guī)則建立事件庫(kù)，事件庫(kù)包括事件標(biāo)識(shí)號(hào)、事件發(fā)生時(shí)間、報(bào)警人、狀態(tài)描述、故障應(yīng)用、事件受理人、關(guān)聯(lián)應(yīng)用、關(guān)系資源、處理過(guò)程描述、處理完成時(shí)間，依據(jù)基礎(chǔ)資源庫(kù)、事件庫(kù)按照事件的處理流程及處理過(guò)程生成事件處理流程庫(kù)，通過(guò)事件處理流程庫(kù)留存問(wèn)題處理過(guò)程中所有工程技術(shù)信息，便于后期工程人員參考，同時(shí)通過(guò)事件跟蹤機(jī)制協(xié)助工程人員進(jìn)行進(jìn)度控制，所有事件的處理效率得到提升，從側(cè)面提升了平臺(tái)的性能。

2.3安全漏洞問(wèn)題批量響應(yīng)

漏洞問(wèn)題是網(wǎng)絡(luò)安全重點(diǎn)關(guān)注的問(wèn)題，一些操作系統(tǒng)、應(yīng)用的安全漏洞常會(huì)導(dǎo)致特權(quán)泄漏及信息被盜問(wèn)題，考慮到一些漏洞問(wèn)題的緊迫性，通過(guò)防護(hù)與打補(bǔ)丁同行的模式來(lái)保障安全，實(shí)現(xiàn)方式是在主機(jī)部署IPS及軟補(bǔ)丁防護(hù)客戶(hù)端，在控制中心配置定期進(jìn)行系統(tǒng)及應(yīng)用漏洞檢測(cè)并自動(dòng)啟用漏洞防護(hù)軟補(bǔ)丁策略，遇緊急情況通過(guò)平臺(tái)發(fā)起實(shí)時(shí)檢測(cè)與策略下發(fā)，主機(jī)層面通過(guò)前期部署的監(jiān)控客戶(hù)端實(shí)現(xiàn)遠(yuǎn)程補(bǔ)丁更新，通過(guò)防與補(bǔ)共進(jìn)的方式有效避免安全問(wèn)題擴(kuò)散，為平臺(tái)性能的提升做好安全保障。

3總結(jié)

通過(guò)資源及應(yīng)用狀態(tài)監(jiān)控、事件處理狀態(tài)跟蹤、安全漏洞更新的統(tǒng)一管理，平臺(tái)的性能有所改善、應(yīng)用的使用體驗(yàn)得到了提升。在大部分主要功能完成部署及使用磨合一段時(shí)間后，相對(duì)于前期基礎(chǔ)平臺(tái)及應(yīng)用軟件的故障時(shí)間縮短了靠近一半，主要借助于應(yīng)用故障的及時(shí)預(yù)警，通過(guò)事件處理的全面跟蹤管理及廣泛應(yīng)用狀態(tài)監(jiān)控，事件處理的效率得到了提升，事件問(wèn)題源頭的誤判率減少了很多，在安全漏洞方面，部署統(tǒng)一的IPS及軟補(bǔ)丁防護(hù)系統(tǒng)后，安全漏洞的處理效率得到了明顯提升，因漏洞引發(fā)的安全事件大量減少，安全的及時(shí)有效保障、業(yè)務(wù)應(yīng)用的快速修復(fù)協(xié)同避免計(jì)算資源的額外浪費(fèi)及性能下降，助力平臺(tái)整體性能的提升。

在實(shí)際實(shí)施及使用過(guò)程中發(fā)現(xiàn)還有很多問(wèn)題，如應(yīng)用資源的監(jiān)控細(xì)化程度還不夠，有時(shí)應(yīng)用服務(wù)未掛起但應(yīng)用已不工作，應(yīng)用狀態(tài)監(jiān)控的有效性及顆粒度還需繼續(xù)細(xì)化，事件處理的跟蹤信息及流程還不夠完善，需要繼續(xù)完善事件要素、改善信息記錄流程等，這些都是經(jīng)后需要繼續(xù)改進(jìn)與研究的方向。