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