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