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