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