時下數(shù)據(jù)科學(xué)是一個熱點話題，各個行業(yè)里面也有一些比較成熟的應(yīng)用，在這個大的背景下，我們在大約一年前就開始有意識地把數(shù)據(jù)技術(shù)、數(shù)據(jù)分析、數(shù)據(jù)挖掘這些技術(shù)融合到運維領(lǐng)域的應(yīng)用。在這個過程中，我們做的時間其實不很長，比較短，目前只是做了一些相對來說較為簡單的一些事情，但取得的成果在公司內(nèi)部感覺還是比較好的。今天我就跟大家分享一下我們在應(yīng)用開發(fā)過程中的一些案例，也就是說，如何讓數(shù)據(jù)技術(shù)在運維實踐中得到充分的應(yīng)用，希望對大家的工作有一些參考價值。
分享目錄：
1.數(shù)據(jù)處理技術(shù)應(yīng)用
2.數(shù)據(jù)分析技術(shù)應(yīng)用
3.數(shù)據(jù)挖掘技術(shù)應(yīng)用
4.應(yīng)用生態(tài)建設(shè)及規(guī)劃
前言
在運維中我們會碰到各種各樣的問題，但有些問題我們經(jīng)常重復(fù)遇到，并且形成了一些提問范式，如：
- “有問題或故障發(fā)生嗎？”，這個提問轉(zhuǎn)換成數(shù)學(xué)問題就是建立“異常檢測”模型；
- 當(dāng)我們確認(rèn)有問題時，我們本能地會問“哪里出了問題”，這便是一個“根因分析”問題；
- 對于一家電商公司來說，促銷前總是要對線上系統(tǒng)進(jìn)行容量評估和擴(kuò)容，這里便有一個“預(yù)測”模型需要被建立；
- 當(dāng)我們每做完一個項目，需要對項目需要達(dá)成的目標(biāo)進(jìn)行定量的評估，這便是一個“績效分析”的問題。
目前各類數(shù)學(xué)模型的輸出在我們的具體工作中主要被用作輔助決策來使用，有兩個原因使我們還不能直接把結(jié)果自動地用于決策：一是我們對數(shù)據(jù)的使用能力還不能做到面面俱到，很多業(yè)務(wù)知識還無法用算法描述；二是算法的輸出結(jié)果一般都是有概率的，在很多需要“絕對正確”的場合只能作為參考。在實際工作中，算法和業(yè)務(wù)規(guī)則庫都會進(jìn)行建設(shè)，用來幫助運維人員更容易和正確地做出決定。
基于此，今天給大家重點介紹“數(shù)據(jù)處理技術(shù)”、“數(shù)據(jù)分析技術(shù)”、“數(shù)據(jù)挖掘技術(shù)”這三個方面在唯品會的應(yīng)用實踐，主要會講到一些應(yīng)用場景，最后談下“數(shù)據(jù)技術(shù)”在唯品會運維的生態(tài)建設(shè)和一些規(guī)劃。
1.數(shù)據(jù)處理技術(shù)應(yīng)用
對于數(shù)據(jù)處理技術(shù)來說，我們主要是需要解決以下五個方面的問題：
- 數(shù)據(jù)的準(zhǔn)確性、及時性
- 海量數(shù)據(jù)的實時計算
- 多維數(shù)據(jù)的實時監(jiān)控
- 多維數(shù)據(jù)的展示
- A/B測試實現(xiàn)方法
這里有些問題在行業(yè)里已有比較成熟的解決方案，有些可能就不是每個公司都會碰到。
數(shù)據(jù)采集
首先我們看數(shù)據(jù)采集，對唯品會來說，我們主要是兩類數(shù)據(jù)，一類是日志數(shù)據(jù)，一類是數(shù)據(jù)庫數(shù)據(jù)。
對于日志數(shù)據(jù)來說，我們有兩類采集，一類是客戶端的日志采集，一類是服務(wù)器端的日志采集。對于服務(wù)器端的日志采集，實際上是比較簡單的，一般來說就是落到本地盤之后，通過Flume傳送到公司的Kafka集群，然后大家在上面消費。對于客戶端行為的采集，分成兩種，一種是Web端的采集，一般來說就是通過異步請求在Nginx上落日志；第二個是APP端的采集，一般是通過一個接口調(diào)用的方式，把這些數(shù)據(jù)落到服務(wù)端，再由服務(wù)端把這個數(shù)據(jù)收集起來。對于數(shù)據(jù)庫的采集，實際上我們也是有兩種方法的，一種是直接在從庫上來做這種指標(biāo)的計算，還有一種就是對于復(fù)雜的應(yīng)用，我們會把DB的Binlog做一些解析，解析完了之后放到一個消息總線上，實際上就放到Kafka上，然后讓大家來進(jìn)行一個消費，每個應(yīng)用都是根據(jù)自己的特點，重構(gòu)自己的數(shù)據(jù)結(jié)構(gòu)。有些會還原數(shù)據(jù)庫，有些就直接用消息來計算指標(biāo)，具體要根據(jù)情況進(jìn)行分析。
上圖主要描述了唯品會用到的一些主要開源產(chǎn)品，基本上是這樣。
數(shù)據(jù)計算
數(shù)據(jù)計算是比較重要的一環(huán)，實際上要兼顧性能和靈活性兩個方面。對日志的處理，會有一個日志解析程序來消費Kafka的消息，“日志解析”實現(xiàn)一個實時ETL的過程，我們會根據(jù)配置（基本配置也跟ETL差不多）去生成預(yù)定義的標(biāo)準(zhǔn)格式，后續(xù)就交給Spark做聚合。“日志解析”由于日志之間沒有相關(guān)性，可以Map之后并行計算，吞吐量和資源的投入是成正比的，這樣效率就沒有什么太多的問題。
對于Spark的聚合配置，一般來說我們會把日志解析完的數(shù)據(jù)進(jìn)行定義，定義各個字段是維度或是指標(biāo)，然后會做一個全維度的聚合。這里面實際上也是有個要求的，我們要求所有的指標(biāo)在各個維度上都具有累加性，如果不具備累加性（比如百分比這種指標(biāo)），我們在Spark里是不做聚合的，只是在展現(xiàn)的時候重新計算。計算好的數(shù)據(jù)會放到一個OLAP和MOLAP的數(shù)據(jù)庫里。
還有一種情況，是通過腳本在數(shù)據(jù)庫從庫上直接進(jìn)行指標(biāo)的計算，一般用于只有時間維度的指標(biāo)計算，配置好的計算腳本，我們會用公司開源的一個產(chǎn)品Saturn來進(jìn)行一個分布式調(diào)度。Saturn這個東西還是不錯的，推薦大家去嘗試一下。對于日志的詳細(xì)查詢，我們還是放到ES里，通過全文檢索的方式來查詢。
數(shù)據(jù)展現(xiàn)
數(shù)據(jù)展現(xiàn)是最終的結(jié)果輸出，實際工作中，我們對結(jié)果數(shù)據(jù)的查詢效率要求比較嚴(yán)苛。因為這些結(jié)果數(shù)據(jù)不僅用于前端，還用于告警輸出等各個方面。對于告警的數(shù)據(jù)我們需要做到毫秒級響應(yīng)，前端界面一般要求是在3秒內(nèi)渲染完成。為了完成這個要求，我們構(gòu)建了一個ROLAP數(shù)據(jù)庫，還有一個MOLAP的數(shù)據(jù)庫，在ROLAP的數(shù)據(jù)庫里，一般只存當(dāng)天的多維數(shù)據(jù)，而在MOLAP的數(shù)據(jù)庫里，會存歷史數(shù)據(jù)。對于MOLAP數(shù)據(jù)庫的檢索，由于應(yīng)用主要是切片方面的需求，基本上都是K-value模式的一個檢索，所以它比較快。MySQL里一般是存放單維度指標(biāo)，應(yīng)該這么講，它不是多維數(shù)據(jù)。Redis緩沖里，一般會存放我們的秒級數(shù)據(jù)，還有一些配置信息。這個架構(gòu)中，最后通過Application Server進(jìn)行一個數(shù)據(jù)的整合，來滿足前端數(shù)據(jù)的一個展示要求。
- 多維分析界面案例
這是一個多維分析案例的界面，左邊是我們的分析平臺，右邊是我們的實時監(jiān)控平臺，從這上面大家能看到，我們實際提供的功能主要是對數(shù)據(jù)切片的能力，這個能力基本可以滿足我們目前所有的需求。
- A/B測試實現(xiàn)
對于數(shù)據(jù)分析來說，基于A/B測試的對比分析是一種重要的方法。因為A/B測試對比的結(jié)果容易被業(yè)務(wù)理解，如果沒有A/B測試，你說我做了一件事情，這件事情帶來了一個好的效果，還是很難經(jīng)得起挑戰(zhàn)的。在A/B測試中，它需要一些技術(shù)來支撐的，因為我們在線上同時會有很多A/B測試的案例同時在跑，你自己的A/B測試不應(yīng)該被別人干擾，在這種情況下實際上是要求各個A/B測試之間的用戶分布得具有正交性，也就是說別人的A/B測試集用戶應(yīng)該平均分布在你的A/B測試集上。
這種實現(xiàn)我們大約有兩種方法，一種是會在APP端設(shè)置開關(guān)，每個開關(guān)管理一個A/B測試的實驗。更多的A/B測試，是統(tǒng)一請求后端的A/B測試分組服務(wù)，這個服務(wù)通過算法來保證各個試驗之間相互獨立。一般來說，當(dāng)客戶端發(fā)起A/B測試場景的時候，就會向A/B測試分組服務(wù)發(fā)個請求，然后A/B分組服務(wù)會返回這個用戶是屬于A組還是B組，一般是這樣的。
2.數(shù)據(jù)分析技術(shù)應(yīng)用
這部分會簡單介紹具體的分析方法，并主要說下應(yīng)用場景和案例。總的來說，我們的運維數(shù)據(jù)分析技術(shù)主要是用于解決兩方面的問題，一方面是“績效分析”，一方面是“根因分析”。
績效分析
以前我們做了挺多的項目，這些項目一般來說WBS分解之后，我們會對項目的結(jié)果做一個簡單的跟蹤，只是說做完了，還是沒做完，一般也不會對它做一些定量的分析或者說對這個質(zhì)量有一個看法。這種情況在我們的項目中非常常見，這種項目一般來說比較小，都是靠個人技術(shù)能力就能控制住。
但在大型項目中這種做法就很困難，它會面臨更多的一個挑戰(zhàn)，尤其是跨部門合作等情況，因為大家的溝通手法不僅僅是技術(shù)的，可能還有一些管理上的，這時就需要大家用數(shù)據(jù)在各個部門之間作為一個溝通的橋梁。
- 績效分析-全站HTTPS項目案例
于是數(shù)據(jù)分析人員就已經(jīng)開始介入來進(jìn)行分析體系的設(shè)計，主要包括：分析指標(biāo)的設(shè)計和分析維度的設(shè)計，同時和研發(fā)確認(rèn)數(shù)據(jù)采集方案、A/B測試方案、統(tǒng)計口徑等。
指標(biāo)主要是根據(jù)項目中各項工作都關(guān)注什么問題來設(shè)計，而維度的設(shè)計是從當(dāng)指標(biāo)不滿意時，可以在哪些方面著手改進(jìn)來進(jìn)行。
在這個項目中可預(yù)見的是，由于證書握手的原因，TCP連接時間會變長，可能會影響用戶體驗，同時也會減少劫持從總體上提高用戶體驗，所以項目的目標(biāo)設(shè)置為轉(zhuǎn)化率至少不下降，最好能有上升。
我們實際上是做了一個HTTPS的全站項目，在項目開始之初，我們就有意識地把數(shù)據(jù)分析團(tuán)隊和技術(shù)人員整合到一起跟進(jìn)項目，取得了不錯的結(jié)果。數(shù)據(jù)分析人員在項目的初期就已經(jīng)開始介入，來進(jìn)行分析體系的設(shè)計，主要包括：分析指標(biāo)的設(shè)計和分析維度的設(shè)計，同時和研發(fā)確認(rèn)數(shù)據(jù)采集方案，A/B測試方案，統(tǒng)計口徑等。
分析人員會把這些工作做好，可他們怎么來設(shè)計這個項目的一些指標(biāo)呢？一般來說，在WBS分解之后，我們關(guān)注什么問題，就會把這個問題變換成一個主要的監(jiān)控指標(biāo)。那如何去設(shè)定這些維度呢？
改善的地方。
首先HTTPS項目，不知道大家有沒有了解，如果了解可能知道HTTPS項目，因為TCP握手時間會延長，這一點上可能會損失一部分的用戶體驗，但在防劫持等方面，又會加強整體的用戶體驗，在這種情況下，我們項目設(shè)立了一個最終的主要目標(biāo)，也就是保證轉(zhuǎn)化率，這個轉(zhuǎn)化率不能下降，最好還有一點點提升，在這個主要目標(biāo)上，我們就控制這個主要目標(biāo)，不停地灰度放量，不停地調(diào)整，這個效果是比較好的，因為在這個過程中我們發(fā)現(xiàn)了很多的問題，同時這個項目持續(xù)了大約8個月，在8個月中我們沒有發(fā)生過任何重大的故障。
這個案例是對錯誤率的分析和監(jiān)控，有一次發(fā)現(xiàn)我們的錯誤碼是HTTPS的證書認(rèn)證過不去，這種情況在某個省某個運營商大規(guī)模地發(fā)生，我們從分析的角度看這些節(jié)點IP是不是我們自己的IP，這樣我們就知道在這個地方發(fā)生了大規(guī)模的DNS劫持問題，于是就去協(xié)調(diào)當(dāng)?shù)氐倪\營商把這個事情搞定。數(shù)據(jù)分析也會發(fā)現(xiàn)一些代碼中的問題，我們做HTTPS項目，可能要對代碼進(jìn)行一些修改，比如說在整個HTML里是不能存在HTTP協(xié)議的硬編碼，但由于歷史原因，這種地方還是比較多的，開發(fā)人員很難排查完，實際上需要分析人員通過數(shù)據(jù)分析手段去查，把這些沒有改過的代碼找出來。
還有一些圖片的問題，我們發(fā)現(xiàn)一些圖片的拼接錯誤，當(dāng)然是報了404，報了404之后，我們對這個錯誤碼分析，發(fā)現(xiàn)突然多了，把報錯的URL做一個排序后發(fā)現(xiàn)一些是拼接的錯誤，還有一些是由于特殊字符引起而導(dǎo)致了無法生成正確的請求。我們對TCP的握手時長也會進(jìn)行跟蹤，在做灰度選型階段，我們在不同的入口采用了不同的技術(shù)類型，通過分析各個入口的握手時長來輔助運維人員進(jìn)行一個加速卡的選型，還有一些參數(shù)調(diào)整等工作。
- 績效分析-其它案例場景
這個項目進(jìn)行完成之后，我們總結(jié)了很多經(jīng)驗，慢慢地在其它的項目中也逐漸有意識地運用數(shù)據(jù)分析技術(shù)，把數(shù)據(jù)分析人員和技術(shù)人員有效地結(jié)合在一起。
這里面也有幾個案例，比如說CDN廠商切換時，我們要跟蹤錯誤率、響應(yīng)時間這樣的一些指標(biāo)，來決定切換是否需要回滾；促銷前的一些流量調(diào)度，我們也要分析調(diào)度策略的預(yù)期結(jié)果，比如說各個入口的流量是不是按我們的計劃把這個流量調(diào)度到位了；每次APP版本的更新，我們也需要不停地來跟蹤它的訪問連通率、網(wǎng)絡(luò)連通率等一些關(guān)鍵指標(biāo)。
根因分析
在數(shù)據(jù)的基礎(chǔ)上，我們也可以做一些原因的查找，通過數(shù)據(jù)分析進(jìn)行的原因查找有時可以直接幫我們定位到問題，在更多的時候可以有效地幫我們縮小問題的范圍。通過數(shù)據(jù)來查找原因，這其實是有一定局限性的，局限性就在于數(shù)據(jù)的維度，因為我們只能在分析的維度上來進(jìn)行查找，如果故障的原因沒有在我們已知維度上，實際上是找不出來的，但大部分時候還是能起到比較關(guān)鍵的作用。
對于直接利用多維數(shù)據(jù)進(jìn)行問題的分析，我們大約有三個步驟，第一個步驟就是要確定問題，確定問題之后，就確定了是哪個指標(biāo)有問題，第二步是做一些數(shù)據(jù)上的分析，最后找到問題之后，我們要做數(shù)據(jù)和業(yè)務(wù)上的一些驗證，主要的方法有兩種：
第一種是排序表，這個最簡單了，就是人眼看，通過排序我們可以解決70-80%的問題。第二種就有點自動化的意思了，我們叫數(shù)據(jù)探索，它有一個原理，實際上并不是所有的數(shù)據(jù)都能進(jìn)行探索，我們目前就是假設(shè)這個數(shù)據(jù)在任意切片上，在時間維度上它是屬于均勻分布的，在這種情況下我們認(rèn)為這個誤差值是符合正態(tài)分布的，就可以比較容易地做一個異常的檢測來看每個數(shù)據(jù)切片上是否有問題，當(dāng)所有的數(shù)據(jù)被探索完之后，問題的原因也基本能找到。
- 根因分析-案例
這是非實時根因分析的一些案例：
我們有一次網(wǎng)絡(luò)連通率連續(xù)三個月下降，我們分析到最后，發(fā)現(xiàn)這個APP的版本有些問題，某天之后所有新發(fā)布的APP版本連通率下降都比較大，跟研發(fā)反饋之后，他們就在SDK做了一些調(diào)整，實際上真正錯在哪，我們并不知道，我們只能知道這個版本有問題，更多地去幫助技術(shù)人員縮小這個范圍。再就是圖片錯誤率上升，剛才已經(jīng)介紹過了。
再就是實時的根因分析，剛才講的其實都是一些平時的案例，而實際上我們也做實時的系統(tǒng)，這些實時的系統(tǒng)就是希望利用多維數(shù)據(jù)，在系統(tǒng)告警候，能夠幫助大家更快定位一些問題。這里也有兩個例子：
一個就是連通率下降之后，我們會發(fā)現(xiàn)某類錯誤碼是影響的一個主要因素，有針對性地解決問題后，發(fā)現(xiàn)連通率恢復(fù)了，這樣基本上可以定位故障。
再有就是某一個應(yīng)用的錯誤率有上升，我們會看到有些省份影響比較大，具體看是一些CDN節(jié)點的故障，切換后，故障得到恢復(fù)。總體看，實時分析還是能夠比較快地幫助運維人員定位問題。
3.數(shù)據(jù)挖掘技術(shù)應(yīng)用
對于數(shù)據(jù)挖掘來說，我們目前所應(yīng)用的場景，或者說能幫我們解決的問題主要有三類：一類是預(yù)測，一類是異常檢測，異常檢測主要是用來做告警閾值自動的設(shè)置。第三類是做一些根因的分析，它的目的和剛才講的基于數(shù)據(jù)分析的根因分析是一樣的，但在實現(xiàn)上算法有些不同。
預(yù)測
我們現(xiàn)在的預(yù)測，主要是做了一些業(yè)務(wù)指標(biāo)的預(yù)測，比如像PV、UV、訂單、購物車這樣的一些業(yè)務(wù)指標(biāo)，下面我講一下訂單的預(yù)測。
這是我們的訂單預(yù)測圖。當(dāng)時做這個預(yù)測，實際是有應(yīng)用的場景，當(dāng)故障發(fā)生時，需要實時跟蹤預(yù)計的損失，以便于我們確定故障的等級，還有就是調(diào)度解決故障需要的資源量。大家可以看到，這種預(yù)估我們還是比較容易可以算出來的，在什么時候這個故障已經(jīng)好了，什么時候它的損失達(dá)到什么程度，我們的故障是不是需要升級。
這里面有一個技術(shù)點需要解決，就是說我們在故障的時候，實際值已經(jīng)掉下去了，而我們的預(yù)測算法需要前一分鐘和前幾分鐘的數(shù)據(jù)，為了不把故障的數(shù)據(jù)引入到算法中，在故障的時候，是用預(yù)測值代替真實值。具體來說，就是用上一周的數(shù)據(jù)做一些平均的加成來替換，然后再做下一次的預(yù)測。
對于預(yù)測算法，我們開始采用的是時間序列中的holt-winters算法，因為我們公司的數(shù)據(jù)周期性比較明顯，我們在時間序列上做擬合時還是比較準(zhǔn)確的，應(yīng)該來說效果還比較好。但這個算法到了一定時候，我們就碰到了一些問題，一個就是促銷和平時不太一樣，也就是說促銷的數(shù)據(jù)，我們是擬合不上的。第二個就是在告警和一些夜晚流量低峰時，這個數(shù)據(jù)波動還是比較大的，告警的準(zhǔn)確率也不是很高，我們怎么來解決這個問題呢？
先看促銷。對訂單量來說，訂單達(dá)到高峰之前，我們的PV、UV包括收藏數(shù)等業(yè)務(wù)指標(biāo)已經(jīng)開始啟動了，我們就會把這些業(yè)務(wù)指標(biāo)引入我們的分析模型，也就是我們會把PV、UV、收藏數(shù)，包括上周同期的這些數(shù)據(jù)，和上周我們要預(yù)測那個時間點的訂單數(shù)全部都引進(jìn)來，然后用一個機器學(xué)習(xí)的辦法，基本上就可以解決這個問題。在雙11促銷后觀察了一下預(yù)測的情況，現(xiàn)在促銷預(yù)測的數(shù)值還是比較準(zhǔn)的。
當(dāng)基于預(yù)測進(jìn)行告警時，碰到主要問題是夜晚低峰時數(shù)據(jù)波動較大，如果按每個時間點的指標(biāo)直接進(jìn)行告警非常容易誤報。我們采用的辦法是預(yù)估損失累計的報警方法，當(dāng)累計預(yù)估損失達(dá)到100單時就進(jìn)行告警，這樣調(diào)整后，我們從上線到現(xiàn)在基本已經(jīng)沒有了誤告。這個100單的設(shè)置，跟我們公司的制度有關(guān)，因為我們公司達(dá)到了200單、300單，那就是重大故障了，我們在100單的時候，就把這個警報給拉起來，是可以防止重大故障發(fā)生的。
根因分析
最后在數(shù)據(jù)挖掘這部分的應(yīng)用，給大家介紹一下根因分析。
我們這套算法經(jīng)過幾個案例的嘗試，基本上都能找出原因，首先就是它跟多維分析的“根因分析”不太一樣，多維分析的“根因分析”是建立在已經(jīng)計算好的多維數(shù)據(jù)基礎(chǔ)上，而這個算法實際上是從原始數(shù)據(jù)來抽樣的。比如說，像錯誤率上升的一個根因分析，我們首先會抽一些數(shù)據(jù)，把錯的和正確的日志各抽50%，對非數(shù)據(jù)列進(jìn)行預(yù)編碼。預(yù)處理之后，我們會用Spearman和Mutual Information這兩種算法來計算各個維度和結(jié)果之間的相關(guān)性程度，如果這兩種方法結(jié)果一致，則直接按相關(guān)性值大小進(jìn)行排序，然后會用One hot encoding做一個轉(zhuǎn)碼，轉(zhuǎn)碼之后放入邏輯回歸模型中，選擇L1的懲罰項，如果它的系數(shù)算出來是負(fù)值，這個負(fù)值所代表的維度就是原因所在。如果上述方法兩個結(jié)果不一致，采用random forest和adaboost的方法構(gòu)建樹模型，查看模型給出的維度重要性，這里我已經(jīng)畫得很清楚了，如果兩個模型的重要性排序一致，就走上次那個步驟，如果不同，則用該模型對數(shù)據(jù)進(jìn)行預(yù)測，選擇預(yù)測結(jié)果較高的相關(guān)性排序。
4.應(yīng)用生態(tài)建設(shè)及規(guī)劃
最后跟大家一起討論一下，如何讓數(shù)據(jù)成為運維的大腦。根據(jù)我們的經(jīng)驗，首先從組織結(jié)構(gòu)上來說，我們需要一個獨立的分析團(tuán)隊。因為在這個分析團(tuán)隊成立之前，公司的運維體系實際上也在使用數(shù)據(jù)，使用數(shù)據(jù)的方法和分析團(tuán)隊后來使用分析數(shù)據(jù)的方法也是大同小異，但因為它本身是一個自發(fā)的，沒有一些強制性的要求。在把數(shù)據(jù)分析融入到工作流程之后，我們發(fā)現(xiàn)效率會得到一個比較大的提升，同時知識的傳承，包括統(tǒng)計口徑等這些比較令人困惑的問題也都可以得到一個比較好的管理和解決。
這樣的組織架構(gòu)在我們的實踐中，感覺可以更好地幫助運維專家來解決問題。
從平臺建設(shè)上來說，應(yīng)該是說現(xiàn)在已經(jīng)開始了，著力打造的其實是兩個平臺，一個是數(shù)據(jù)分析的平臺，數(shù)據(jù)分析平臺說到底就是運維的數(shù)據(jù)倉庫，它使用現(xiàn)在大數(shù)據(jù)的一些傳統(tǒng)技術(shù)來做這件事情，第二個是統(tǒng)一信息的平臺。“統(tǒng)一信息平臺”主要考慮到在互聯(lián)網(wǎng)公司，不管是不是在野蠻成長階段，待過的人都會知道，系統(tǒng)特別多，信息也是特別分散，我們還是想把這些分散的關(guān)鍵信息看怎么收集起來，然后看能不能做一些事情。目前我們會把發(fā)布平臺的一些發(fā)布信息，還有ITIL平臺的一些事件信息、變更信息，CMDB的一些基礎(chǔ)架構(gòu)信息，再有就是各種各樣的監(jiān)控系統(tǒng)的值班表信息和告警信息（這種監(jiān)控系統(tǒng)我們有好幾十套），我們都會把它們放到信息庫里面。在信息庫建設(shè)之后，我們算法雖然可以實際有效地解決點上的問題，但還沒能很好地解決關(guān)聯(lián)性上的問題，這塊還是挺困難的。只能是說當(dāng)前是一件事情一件事情去解決，那這種復(fù)雜的關(guān)聯(lián)性我們靠什么呢？
靠的是規(guī)則庫，用業(yè)務(wù)知識補充當(dāng)前階段算法上的一些不足。也就是說在整個系統(tǒng)建設(shè)中，實際上算法庫和規(guī)則庫都是一起建設(shè)的，不會說，就用算法就不要規(guī)則了，或只有規(guī)則，算法也沒什么用，它是一體建設(shè)的，而且它們能解決的問題不一樣，算法我們是解決點上的問題，規(guī)則我們是用來解決這種關(guān)聯(lián)性的問題，尤其復(fù)雜業(yè)務(wù)關(guān)聯(lián)的問題，都靠規(guī)則來配置的。
整個這套平臺的建設(shè)它主要有兩個目標(biāo)，短期目標(biāo)就是說對告警進(jìn)行有效的一個壓制、管理、合并，第二個目標(biāo)就是想能夠解決自動故障定位的問題。目前是有一定的成效，但準(zhǔn)確率還沒有那么高，以后能做得好的時候，我們會想通過ITIL平臺來驅(qū)動自動化平臺對現(xiàn)網(wǎng)的故障進(jìn)行自動化的處理，比如說像重啟、降級，限流，磁盤空間管理，流量調(diào)度等工作。應(yīng)該是說為了自動化運維、解決故障一起努力吧！
以上就是我們對數(shù)據(jù)應(yīng)用在未來一個時期內(nèi)的定義，也是想在未來大約半年到一年能夠看到更多成果的一個實踐。今天分享就到這里，謝謝大家！
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：唯品會運維數(shù)據(jù)技術(shù)實踐的三重境界
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839324474.html
相關(guān)文章
