企業(yè)級(jí)數(shù)據(jù)中心IT運(yùn)維建設(shè)工作第一步也是最重要的一步，數(shù)據(jù)管理。很多情況下，企業(yè)考慮運(yùn)維平臺(tái)時(shí)，會(huì)側(cè)重技術(shù)框架、開發(fā)模式、軟件品牌等因素，比如大數(shù)據(jù)架構(gòu)、paas、saas、微服務(wù)，選用的軟件是商業(yè)產(chǎn)品還是開源產(chǎn)品等。但是，往往最重要的部分是在數(shù)據(jù)管理的規(guī)則上，在這套規(guī)則的框架下，我們?nèi)ミx擇具備支撐相關(guān)功能、性能的技術(shù)去實(shí)現(xiàn)。同時(shí)，我們還不得不考慮的是數(shù)據(jù)平臺(tái)的可持續(xù)性問題。可持續(xù)性方面包含了政策導(dǎo)向性、平臺(tái)可擴(kuò)展性、可移植性等。近年來由于開源技術(shù)的崛起，技術(shù)安全性的問題，導(dǎo)致很多企業(yè)犧牲歷史投資，重構(gòu)平臺(tái)的案例比比皆是。這些問題已經(jīng)是當(dāng)前企業(yè)數(shù)據(jù)管理者及架構(gòu)設(shè)計(jì)者必須面對(duì)的實(shí)際問題了。
從數(shù)據(jù)中心的業(yè)務(wù)職責(zé)上看，數(shù)據(jù)的特點(diǎn)主要有2個(gè)。第一，數(shù)據(jù)量巨大。第二，數(shù)據(jù)屬性復(fù)雜。數(shù)據(jù)量巨大不光光是簡(jiǎn)單通過搭建大數(shù)據(jù)平臺(tái)來解決。HDFS、Hadoop、ElasticSearch這些技術(shù)工具本身并不能100%的解決我們的問題。許多企業(yè)的運(yùn)維咨詢方案及架構(gòu)是簡(jiǎn)單粗暴的針對(duì)數(shù)據(jù)量的多少，來選擇數(shù)據(jù)存儲(chǔ)及計(jì)算的資源。而忽視了從數(shù)據(jù)源頭來解決問題。那么，源頭問題是在哪里？其實(shí)，數(shù)據(jù)來自于各種對(duì)象，包括設(shè)備設(shè)施、應(yīng)用。概括來說就是軟件和硬件。數(shù)據(jù)的載體又分為命令輸出、各種協(xié)議、網(wǎng)絡(luò)包、日志、接口、人工輸入、圖像、視頻、信號(hào)等。數(shù)據(jù)類型最常見的又分為資產(chǎn)數(shù)據(jù)、配置數(shù)據(jù)、告警數(shù)據(jù)、性能數(shù)據(jù)、容量數(shù)據(jù)、業(yè)務(wù)數(shù)據(jù)等等。數(shù)據(jù)的屬性是可以被靈活地多重定義的，定義的標(biāo)準(zhǔn)來自于最終的應(yīng)用場(chǎng)景，用戶需要數(shù)據(jù)被如何消費(fèi)，那么數(shù)據(jù)就可被定義為多種屬性的標(biāo)簽。這樣就解釋了數(shù)據(jù)量巨大的由來，就是因?yàn)閺母鱾€(gè)來源，各種類型，我們常常聽到的數(shù)據(jù)分析，就是需要做數(shù)據(jù)的多維度交叉分析、比對(duì)等功能。因此，這些不同的維度乘以設(shè)備/系統(tǒng)的數(shù)量這個(gè)基數(shù)，得出的結(jié)果就非常的驚人了。我們做的各式各樣的系統(tǒng)的預(yù)期結(jié)果往往達(dá)不到期望的原因也在于不是數(shù)據(jù)不足以支撐功能，就是數(shù)據(jù)太多，計(jì)算過程開銷太大，用戶體驗(yàn)不友好。
如何來解決這個(gè)問題，其實(shí)是要在數(shù)據(jù)量上做一個(gè)平衡。數(shù)據(jù)并不是越多越好，數(shù)據(jù)的收集講究的是合理、合適，同時(shí)合規(guī)。做大數(shù)據(jù)分析的朋友都聽說過數(shù)據(jù)質(zhì)量這個(gè)說法。意思就是數(shù)據(jù)質(zhì)量直接影響到最終的輸出結(jié)果質(zhì)量。一般會(huì)先對(duì)所有原始數(shù)據(jù)進(jìn)行質(zhì)量甄選，把“靠譜”的數(shù)據(jù)挑選出來，拿這些優(yōu)質(zhì)數(shù)據(jù)進(jìn)行模型訓(xùn)練。反復(fù)訓(xùn)練、強(qiáng)化訓(xùn)練得出比較可以接受的算法參數(shù)及結(jié)果。而我們的思路是直接在采集數(shù)據(jù)的時(shí)候，結(jié)合用戶的最終需求和我們的經(jīng)驗(yàn)，對(duì)數(shù)據(jù)采集時(shí)就添加各種規(guī)則。規(guī)則規(guī)定了我們針對(duì)不同應(yīng)用場(chǎng)景的對(duì)象實(shí)行顆粒度不同的采集策略。舉個(gè)例子來說，網(wǎng)絡(luò)設(shè)備，一般架構(gòu)中最常見的會(huì)有核心交換機(jī)、接入交換機(jī)這樣的用途。那針對(duì)核心交換機(jī)，我們會(huì)通過幾種不同的手段盡可能采集比較詳盡的數(shù)據(jù)，包括CPU、內(nèi)存、Sysuptime、溫度、風(fēng)扇、電源、協(xié)議狀態(tài)、丟包率、延時(shí)、所有應(yīng)用端口的流量、甚至是日志級(jí)別很低的用戶登錄消息和配置變更消息。因?yàn)椋诤诵慕粨Q機(jī)上任何一個(gè)不合規(guī)的登錄或者變更，引起的故障影響是非常巨大的。而接入交換機(jī)呢，我們只需知道設(shè)備、特定端口是通的就可以了。就這么簡(jiǎn)單。以上是從數(shù)據(jù)采集的深度上設(shè)計(jì)的策略。同樣，還要搭配時(shí)間的維度，核心交換機(jī)我們必須是7*24*365不間斷的進(jìn)行數(shù)據(jù)采集。接入交換機(jī)呢，就不需要了，5*8*5的采集時(shí)長(zhǎng)就夠了。如果不進(jìn)行采集策略的設(shè)計(jì)，我們就可以想象平臺(tái)會(huì)有多少無用的垃圾數(shù)據(jù)了。尤其，在數(shù)量上接入交換機(jī)的數(shù)量往往是核心交換機(jī)的好幾倍。那有些朋友會(huì)問，數(shù)據(jù)在處理前再進(jìn)行判斷過濾也可以吧。的確，但是這些功能也常年會(huì)消耗平臺(tái)的整體資源。逼著平臺(tái)的設(shè)計(jì)往沉重、高配的方向越行越遠(yuǎn)。除此之外，不同的數(shù)據(jù)類型，也需要通過合理的方式來采集。一般性能數(shù)據(jù)，我們看的是趨勢(shì)，對(duì)實(shí)時(shí)性的要求不是最重要的。我們需要持續(xù)的，穩(wěn)定的間隔去采集。而故障數(shù)據(jù)，則需要第一時(shí)間發(fā)現(xiàn)，因此，通過實(shí)時(shí)或者準(zhǔn)實(shí)時(shí)的發(fā)現(xiàn)。配置數(shù)據(jù)，則需要根據(jù)應(yīng)用或者業(yè)務(wù)的需要設(shè)置更新的時(shí)間。
經(jīng)過以上種種的考慮和設(shè)計(jì)，才能最有效的利用平臺(tái)的資源來處理最合適的數(shù)據(jù)。最后，再結(jié)合一個(gè)實(shí)際功能說明數(shù)據(jù)接入的重要性。根源故障分析RCA是IT運(yùn)維里的一個(gè)終極目標(biāo)功能，很多同行都在落地實(shí)現(xiàn)，但往往效果并不盡如人意。原因很大程度也是數(shù)據(jù)采集的問題。數(shù)據(jù)維度不夠多，導(dǎo)致分析出來的所謂“根源”也只是真實(shí)ROOT上衍生出來的一個(gè)節(jié)點(diǎn)而已。數(shù)據(jù)多了呢，反過來拖累了性能，導(dǎo)致分析過程超時(shí)，結(jié)果出錯(cuò)等等各式各樣的問題。
以上是對(duì)數(shù)據(jù)運(yùn)維方面的一些思考和理解，希望對(duì)各位讀者在工作中有所幫助。也希望大家有問題和想法在評(píng)論區(qū)留言。
