IT運(yùn)維平臺算法背后的兩大“神助攻”
智能運(yùn)維(AIops)是目前 IT 運(yùn)維領(lǐng)域最火熱的詞匯，全稱是 Algorithmic IT operations platforms，正規(guī)翻譯是『基于算法的 IT 運(yùn)維平臺』，直觀可見算法是智能運(yùn)維的核心要素之一。
本文主要談算法對運(yùn)維的作用，涉及異常檢測和歸因分析兩方面，圍繞運(yùn)維系統(tǒng)Kale 中 skyline、Oculus 模塊、Opprentice 系統(tǒng)、Granger causality（格蘭杰因果關(guān)系）、FastDTW 算法等細(xì)節(jié)展開。
一、異常檢測
異常檢測，是運(yùn)維工程師們最先可能接觸的地方了。畢竟監(jiān)控告警是所有運(yùn)維工作的基礎(chǔ)。設(shè)定告警閾值是一項(xiàng)耗時(shí)耗力的工作，需要運(yùn)維人員在充分了解業(yè)務(wù)的前提下才能進(jìn)行，還得考慮業(yè)務(wù)是不是平穩(wěn)發(fā)展?fàn)顟B(tài)，否則一兩周改動(dòng)一次，運(yùn)維工程師絕對是要發(fā)瘋的。
如果能將這部分工作交給算法來解決，無疑是推翻一座大山。這件事情，機(jī)器學(xué)習(xí)當(dāng)然可以做到。但是不用機(jī)器學(xué)習(xí)，基于數(shù)學(xué)統(tǒng)計(jì)的算法，同樣可以，而且效果也不差。
異常檢測之Skyline異常檢測模塊
2013年，Etsy 開源了一個(gè)內(nèi)部的運(yùn)維系統(tǒng)，叫 Kale。其中的 skyline 部分，就是做異常檢測的模塊， 它提供了 9 種異常檢測算法 ：
first_hour_average、
simple_stddev_from_moving_average、
stddev_from_moving_average、
mean_subtraction_cumulation、
least_squares
histogram_bins、
grubbs、
median_absolute_deviation、
Kolmogorov-Smirnov_test
簡要的概括來說，這9種算法分為兩類：
從正態(tài)分布入手：假設(shè)數(shù)據(jù)服從高斯分布，可以通過標(biāo)準(zhǔn)差來確定絕大多數(shù)數(shù)據(jù)點(diǎn)的區(qū)間；或者根據(jù)分布的直方圖，落在過少直方里的數(shù)據(jù)就是異常；或者根據(jù)箱體圖分析來避免造成長尾影響。
從樣本校驗(yàn)入手：采用 Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor 等非參數(shù)校驗(yàn)方法。
這些都是統(tǒng)計(jì)學(xué)上的算法，而不是機(jī)器學(xué)習(xí)的事情。當(dāng)然，Etsy 這個(gè) Skyline 項(xiàng)目并不是異常檢測的全部。
首先，這里只考慮了一個(gè)指標(biāo)自己的狀態(tài)，從縱向的時(shí)序角度做異常檢測。而沒有考慮業(yè)務(wù)的復(fù)雜性導(dǎo)致的橫向異常。其次，提供了這么多種算法，到底一個(gè)指標(biāo)在哪種算法下判斷的更準(zhǔn)？這又是一個(gè)很難判斷的事情。
問題一： 實(shí)現(xiàn)上的抉擇。同樣的樣本校驗(yàn)算法，可以用來對比一個(gè)指標(biāo)的當(dāng)前和歷史情況，也可以用來對比多個(gè)指標(biāo)里哪個(gè)跟別的指標(biāo)不一樣。
問題二： Skyline 其實(shí)自己采用了一種特別樸實(shí)和簡單的辦法來做補(bǔ)充——9 個(gè)算法每人一票，投票達(dá)到閾值就算數(shù)。至于這個(gè)閾值，一般算 6 或者 7 這樣，即占到大多數(shù)即可。
異常檢測之Opprentice系統(tǒng)
作為對比，面對相同的問題，百度 SRE 的智能運(yùn)維是怎么處理的。在去年的 APMcon 上，百度工程師描述 Opprentice 系統(tǒng)的主要思想時(shí)，用了這么一張圖：
Opprentice 系統(tǒng)的主體流程為：
KPI 數(shù)據(jù)經(jīng)過各式 detector 計(jì)算得到每個(gè)點(diǎn)的諸多 feature；
通過專門的交互工具，由運(yùn)維人員標(biāo)記 KPI 數(shù)據(jù)的異常時(shí)間段；
采用隨機(jī)森林算法做異常分類。
其中 detector 有14種異常檢測算法，如下圖：
我們可以看到其中很多算法在 Etsy 的 Skyline 里同樣存在。不過，為避免給這么多算法調(diào)配參數(shù)，直接采用的辦法是：每個(gè)參數(shù)的取值范圍均等分一下——反正隨機(jī)森林不要求什么特征工程。如，用 holt-winters 做為一類 detector。holt-winters 有α，β，γ 三個(gè)參數(shù)，取值范圍都是 [0, 1]。那么它就采樣為 (0.2, 0.4, 0.6, 0.8)，也就是 4 ** 3 = 64 個(gè)可能。那么每個(gè)點(diǎn)就此得到 64 個(gè)特征值。
異常檢測之
Opprentice 系統(tǒng)與 Skyline 很相似
Opprentice 系統(tǒng)整個(gè)流程跟 skyline 的思想相似之處在于先通過不同的統(tǒng)計(jì)學(xué)上的算法來嘗試發(fā)現(xiàn)異常，然后通過一個(gè)多數(shù)同意的方式/算法來確定最終的判定結(jié)果。
只不過這里百度采用了一個(gè)隨機(jī)森林的算法，來更靠譜一點(diǎn)的投票。而 Etsy 呢？在 skyline 開源幾個(gè)月后，他們內(nèi)部又實(shí)現(xiàn)了新版本，叫 Thyme。利用了小波分解、傅里葉變換、Mann-whitney 檢測等等技術(shù)。
另外，社區(qū)在 Skyline 上同樣做了后續(xù)更新，Earthgecko 利用 Tsfresh 模塊來提取時(shí)序數(shù)據(jù)的特征值，以此做多時(shí)序之間的異常檢測。我們可以看到，后續(xù)發(fā)展的兩種 Skyline，依然都沒有使用機(jī)器學(xué)習(xí)，而是進(jìn)一步深度挖掘和調(diào)整時(shí)序相關(guān)的統(tǒng)計(jì)學(xué)算法。
開源社區(qū)除了 Etsy，還有諸多巨頭也開源過各式其他的時(shí)序異常檢測算法庫，大多是在 2015 年開始的。列舉如下：
Yahoo! 在去年開源的 egads 庫。(Java)
Twitter 在去年開源的 anomalydetection 庫。(R)
Netflix 在 2015 年開源的 Surus 庫。(Pig，基于PCA)
其中 Twitter 這個(gè)庫還被 port 到 Python 社區(qū)，有興趣的讀者也可以試試。
二、歸因分析
歸因分析是運(yùn)維工作的下一大塊內(nèi)容，就是收到報(bào)警以后的排障。對于簡單故障，應(yīng)對方案一般也很簡單，采用 service restart engineering~ 但是在大規(guī)模 IT 環(huán)境下，通常一個(gè)故障會(huì)觸發(fā)或?qū)е麓竺娣e的告警發(fā)生。如果能從大面積的告警中，找到最緊迫最要緊的那個(gè)，肯定能大大的縮短故障恢復(fù)時(shí)間(MTTR)。
這個(gè)故障定位的需求，通常被歸類為根因分析（RCA，Root Cause Analysis）。當(dāng)然，RCA 可不止故障定位一個(gè)用途，性能優(yōu)化的過程通常也是 RCA 的一種。
歸因分析之 Oculus 模塊
和異常檢測一樣，做 RCA 同樣是可以統(tǒng)計(jì)學(xué)和機(jī)器學(xué)習(xí)方法并行的~我們還是從統(tǒng)計(jì)學(xué)的角度開始。依然是 Etsy 的 kale 系統(tǒng)，其中除了做異常檢測的 skyline 以外，還有另外一部分，叫 Oculus。而且在 Etsy 重構(gòu) kale 2.0 的時(shí)候，Oculus 被認(rèn)為是1.0 最成功的部分，完整保留下來了。
Oculus 的思路，用一句話描述，就是：如果一個(gè)監(jiān)控指標(biāo)的時(shí)間趨勢圖走勢，跟另一個(gè)監(jiān)控指標(biāo)的趨勢圖長得比較像，那它們很可能是被同一個(gè)根因影響的。那么，如果整體 IT 環(huán)境內(nèi)的時(shí)間同步是可靠的，且監(jiān)控指標(biāo)的顆粒度比較細(xì)的情況下，我們就可能近似的推斷：跟一個(gè)告警比較像的最早的那個(gè)監(jiān)控指標(biāo)，應(yīng)該就是需要重點(diǎn)關(guān)注的根因了。
Oculus 截圖如下：
這部分使用的 計(jì)算方式有兩種：
歐式距離，就是不同時(shí)序數(shù)據(jù)，在相同時(shí)刻做對比。假如0分0秒，a和b相差1000，0分5秒，也相差1000，依次類推。
FastDTW，則加了一層偏移量，0分0秒的a和0分5秒的b相差1000，0分5秒的a和0分10秒的b也相差1000，依次類推。當(dāng)然，算法在這個(gè)簡單假設(shè)背后，是有很多降低計(jì)算復(fù)雜度的具體實(shí)現(xiàn)的，這里就不談了。
唯一可惜的是 Etsy 當(dāng)初實(shí)現(xiàn) Oculus 是基于 ES 的 0.20 版本，后來該版本一直沒有更新。現(xiàn)在停留在這么老版本的 ES 用戶應(yīng)該很少了。除了 Oculus，還有很多其他產(chǎn)品，采用不同的統(tǒng)計(jì)學(xué)原理，達(dá)到類似的效果。
歸因分析之 Granger causality
Granger causality（格蘭杰因果關(guān)系）是一種算法，簡單來說它通過比較“已知上一時(shí)刻所有信息，這一時(shí)刻 X 的概率分布情況”和“已知上一時(shí)刻除 Y 以外的所有信息，這一時(shí)刻 X 的概率分布情況”，來判斷 Y 對 X 是否存在因果關(guān)系。
可能有了解過一點(diǎn)機(jī)器學(xué)習(xí)信息的讀者會(huì)很詫異了：不是說機(jī)器只能反應(yīng)相關(guān)性，不能反應(yīng)因果性的么？需要說明一下，這里的因果，是統(tǒng)計(jì)學(xué)意義上的因果，不是我們通常哲學(xué)意義上的因果。
統(tǒng)計(jì)學(xué)上的因果定義是：『在宇宙中所有其他事件的發(fā)生情況固定不變的條件下，如果一個(gè)事件 A 的發(fā)生與不發(fā)生對于另一個(gè)事件 B 的發(fā)生的概率有影響，并且這兩個(gè)事件在時(shí)間上有先后順序（A 前 B 后），那么我們便可以說 A 是 B 的原因。』
歸因分析之皮爾遜系數(shù)
另一個(gè)常用的算法是皮爾遜系數(shù)。下圖是某 ITOM 軟件的實(shí)現(xiàn)：
我們可以看到，其主要元素和采用 FastDTW 算法的 Oculus 類似：correlation 表示相關(guān)性的評分、lead/lag 表示不同時(shí)序數(shù)據(jù)在時(shí)間軸上的偏移量。
皮爾遜系數(shù)在 R 語言里可以特別簡單的做到。比如我們拿到同時(shí)間段的訪問量和服務(wù)器 CPU 使用率：
然后運(yùn)行如下命令：
acc_count<-scale(acc$acc_count,center=T,scale=T)
cpu<-scale(acc$cpuload5,center=T,scale=T)
cor.test(acc_count,cpu)
可以看到如下結(jié)果輸出：
對應(yīng)的可視化圖形如下：
這就說明網(wǎng)站數(shù)據(jù)訪問量和 CPU 存在弱相關(guān)，同時(shí)從散點(diǎn)圖上看兩者為非線性關(guān)系。因此訪問量上升不一定會(huì)真正影響 CPU 消耗。
其實(shí) R 語言不太適合嵌入到現(xiàn)有的運(yùn)維系統(tǒng)中。那這時(shí)候使用 Elasticsearch 的工程師就有福了。ES 在大家常用的 metric aggregation、bucket aggregation、pipeline aggregation 之外，還提供了一種 matrix aggregation，目前唯一支持的 matrix_stats 就是采用了皮爾遜系數(shù)的計(jì)算，接口文檔見：
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html
唯一需要注意的就是，要求計(jì)算相關(guān)性的兩個(gè)字段必須同時(shí)存在于一個(gè) event 里。所以沒法直接從現(xiàn)成的 ES 數(shù)據(jù)中請求不同的 date_histogram，然后計(jì)算，需要自己手動(dòng)整理一遍，轉(zhuǎn)儲回 ES 再計(jì)算。
饒琛琳，目前就職日志易，有十年運(yùn)維工作經(jīng)驗(yàn)。在微博擔(dān)任系統(tǒng)架構(gòu)師期間，負(fù)責(zé)帶領(lǐng)11人的SRE團(tuán)隊(duì)。著有《網(wǎng)站運(yùn)維技術(shù)與實(shí)踐》、《ELKstack權(quán)威指南》，合譯有《Puppet 3 Cookbook》、《Learning Puppet 4》。在眾多技術(shù)大會(huì)上分享過自動(dòng)化運(yùn)維與數(shù)據(jù)分析相關(guān)主題。
才旦朋15124873806： 哪些運(yùn)維平臺比較適合國內(nèi)的企業(yè)?
嘉蔭縣蝸桿： ______ 云吶IT交互服務(wù)臺,針對解決企業(yè)信息互聯(lián)互通問題,幫助企業(yè)智能化管理企業(yè)內(nèi)外業(yè)務(wù),功能非常全面,故應(yīng)該不僅限于國內(nèi)企業(yè).
才旦朋15124873806： 數(shù)字簽名在電子商務(wù)領(lǐng)域的應(yīng)用 -
嘉蔭縣蝸桿： ______ 隨著電腦的普及應(yīng)用和互聯(lián)網(wǎng)的快速發(fā)展,電子商務(wù)已經(jīng)逐漸成為人們進(jìn)行商務(wù)活動(dòng)的新模式;電子商務(wù)在提高商務(wù)效率、降低商務(wù)交易成本的同時(shí),本身安全性也隨之而至,成為制約其進(jìn)一步發(fā)...
才旦朋15124873806： ITSM對于IT運(yùn)維管理有哪些作用呢? -
嘉蔭縣蝸桿： ______ IT運(yùn)維是指IT設(shè)備的運(yùn)行維護(hù).保證設(shè)備正常運(yùn)行,并且注意還有運(yùn)行的概念,比如客戶需要?jiǎng)?chuàng)建一個(gè)虛擬機(jī),你幫客戶創(chuàng)建了,這也是運(yùn)行.他和運(yùn)營也就是沒有把錢引進(jìn)去而已.總的來說,IT運(yùn)維是指用技術(shù)等手段保證業(yè)務(wù)正常運(yùn)轉(zhuǎn).
才旦朋15124873806： 運(yùn)維工作中最重要的是什么? -
嘉蔭縣蝸桿： ______ 1、安全,公司的運(yùn)維首先應(yīng)當(dāng)將安全放在第一位.安全漏洞,信息泄露這些都會(huì)關(guān)系到公司的未來發(fā)展甚至是生死存亡,發(fā)生在互聯(lián)網(wǎng)公司的信息泄露事件不在少數(shù),都給這些公司造成很大的負(fù)面影響,要想挽回這些影響資金上的付出是很大...
才旦朋15124873806： 如何提高IT運(yùn)維人員工作效率 -
嘉蔭縣蝸桿： ______ 用一些IT運(yùn)維管理軟件,比如流程管理軟件,監(jiān)控軟件.每發(fā)生一個(gè)事件就創(chuàng)建一個(gè)工單,創(chuàng)建工單后就開始計(jì)時(shí),運(yùn)維人員必須在規(guī)定事件內(nèi)完成,如果沒能完成,就會(huì)在后續(xù)的統(tǒng)計(jì)分析中顯示出來,影響當(dāng)月或者當(dāng)年度的績效考核.當(dāng)然,這需要一個(gè)統(tǒng)一的服務(wù)臺進(jìn)行調(diào)度,對每個(gè)工程師的特長,還有是否有空閑都清楚.云雀運(yùn)維就是這樣的,通過這個(gè)平臺可以監(jiān)控大部分的設(shè)備節(jié)點(diǎn),當(dāng)發(fā)生故障的時(shí)候,會(huì)自動(dòng)的向工程師的手機(jī)發(fā)短信和微信,工程師只有接收并創(chuàng)建工單后才能停止,創(chuàng)建工單后就會(huì)顯示時(shí)間,所以工程師必須盡力解決,這樣就大大提高了工作效率.
才旦朋15124873806： linux運(yùn)維工程師到底是做什么的 -
嘉蔭縣蝸桿： ______ 大把運(yùn)維工種,幾天都說不完,下面簡單介紹下 1)IT運(yùn)維IT運(yùn)維是IT管理的核心和重點(diǎn)部分,也是內(nèi)容最多、最繁雜的部分,常見的IT運(yùn)維:硬件化的蟻巡運(yùn)維平臺,軟件形態(tài)的的HP Operations Orchestration、IBM tivoli等還有開源的軟件Nagios...
才旦朋15124873806： IT管理員常用的管理,運(yùn)維工具有哪些 -
嘉蔭縣蝸桿： ______ ITSM V3.0(運(yùn)維管理平臺) ECC V8.8(綜合系統(tǒng)管理) NNM V3.7(拓?fù)渫?
才旦朋15124873806： 如何有效減少運(yùn)維工作量 -
嘉蔭縣蝸桿： ______ A.近幾年很流行云桌面,云計(jì)算類的企業(yè)辦公軟件,個(gè)人推薦虛擬化,這種呢,一般在服務(wù)器端安裝應(yīng)用,集中在服務(wù)器管理應(yīng)用程序,按需分配應(yīng)用資源,統(tǒng)一升級維護(hù).這樣子就可以大大降低IT運(yùn)維成本和人力,減輕工作量.市場上很多相關(guān)的軟件,比如云舒3C,微軟,思杰等.B.將全部應(yīng)用資源部署在服務(wù)器上,通過應(yīng)用虛擬化軟件直接發(fā)布給每一個(gè)用戶就可以了.
才旦朋15124873806： 搶占式SPF中,新到達(dá)的進(jìn)程所需要的服務(wù)時(shí)間與正在執(zhí)行的進(jìn)程的還...
嘉蔭縣蝸桿： ______ 這個(gè)其實(shí)就是說的有效監(jiān)控、監(jiān)管你的IT設(shè)備資源,IT應(yīng)用的問題.下面的只重點(diǎn)說一下個(gè)人對服務(wù)器與服務(wù)器應(yīng)用進(jìn)行有效監(jiān)管,其實(shí),下面這個(gè)軟件對網(wǎng)絡(luò)設(shè)備、機(jī)房環(huán)境等IT運(yùn)維同樣有效,只是有其它的模塊里.我今天想說的是,你們服務(wù)...
本文主要談算法對運(yùn)維的作用，涉及異常檢測和歸因分析兩方面，圍繞運(yùn)維系統(tǒng)Kale 中 skyline、Oculus 模塊、Opprentice 系統(tǒng)、Granger causality（格蘭杰因果關(guān)系）、FastDTW 算法等細(xì)節(jié)展開。
一、異常檢測
異常檢測，是運(yùn)維工程師們最先可能接觸的地方了。畢竟監(jiān)控告警是所有運(yùn)維工作的基礎(chǔ)。設(shè)定告警閾值是一項(xiàng)耗時(shí)耗力的工作，需要運(yùn)維人員在充分了解業(yè)務(wù)的前提下才能進(jìn)行，還得考慮業(yè)務(wù)是不是平穩(wěn)發(fā)展?fàn)顟B(tài)，否則一兩周改動(dòng)一次，運(yùn)維工程師絕對是要發(fā)瘋的。
如果能將這部分工作交給算法來解決，無疑是推翻一座大山。這件事情，機(jī)器學(xué)習(xí)當(dāng)然可以做到。但是不用機(jī)器學(xué)習(xí)，基于數(shù)學(xué)統(tǒng)計(jì)的算法，同樣可以，而且效果也不差。
異常檢測之Skyline異常檢測模塊
2013年，Etsy 開源了一個(gè)內(nèi)部的運(yùn)維系統(tǒng)，叫 Kale。其中的 skyline 部分，就是做異常檢測的模塊， 它提供了 9 種異常檢測算法 ：
first_hour_average、
simple_stddev_from_moving_average、
stddev_from_moving_average、
mean_subtraction_cumulation、
least_squares
histogram_bins、
grubbs、
median_absolute_deviation、
Kolmogorov-Smirnov_test
簡要的概括來說，這9種算法分為兩類：
從正態(tài)分布入手：假設(shè)數(shù)據(jù)服從高斯分布，可以通過標(biāo)準(zhǔn)差來確定絕大多數(shù)數(shù)據(jù)點(diǎn)的區(qū)間；或者根據(jù)分布的直方圖，落在過少直方里的數(shù)據(jù)就是異常；或者根據(jù)箱體圖分析來避免造成長尾影響。
從樣本校驗(yàn)入手：采用 Kolmogorov-Smirnov、Shapiro-Wilk、Lilliefor 等非參數(shù)校驗(yàn)方法。
這些都是統(tǒng)計(jì)學(xué)上的算法，而不是機(jī)器學(xué)習(xí)的事情。當(dāng)然，Etsy 這個(gè) Skyline 項(xiàng)目并不是異常檢測的全部。
首先，這里只考慮了一個(gè)指標(biāo)自己的狀態(tài)，從縱向的時(shí)序角度做異常檢測。而沒有考慮業(yè)務(wù)的復(fù)雜性導(dǎo)致的橫向異常。其次，提供了這么多種算法，到底一個(gè)指標(biāo)在哪種算法下判斷的更準(zhǔn)？這又是一個(gè)很難判斷的事情。
問題一： 實(shí)現(xiàn)上的抉擇。同樣的樣本校驗(yàn)算法，可以用來對比一個(gè)指標(biāo)的當(dāng)前和歷史情況，也可以用來對比多個(gè)指標(biāo)里哪個(gè)跟別的指標(biāo)不一樣。
問題二： Skyline 其實(shí)自己采用了一種特別樸實(shí)和簡單的辦法來做補(bǔ)充——9 個(gè)算法每人一票，投票達(dá)到閾值就算數(shù)。至于這個(gè)閾值，一般算 6 或者 7 這樣，即占到大多數(shù)即可。
異常檢測之Opprentice系統(tǒng)
作為對比，面對相同的問題，百度 SRE 的智能運(yùn)維是怎么處理的。在去年的 APMcon 上，百度工程師描述 Opprentice 系統(tǒng)的主要思想時(shí)，用了這么一張圖：
Opprentice 系統(tǒng)的主體流程為：
KPI 數(shù)據(jù)經(jīng)過各式 detector 計(jì)算得到每個(gè)點(diǎn)的諸多 feature；
通過專門的交互工具，由運(yùn)維人員標(biāo)記 KPI 數(shù)據(jù)的異常時(shí)間段；
采用隨機(jī)森林算法做異常分類。
其中 detector 有14種異常檢測算法，如下圖：
我們可以看到其中很多算法在 Etsy 的 Skyline 里同樣存在。不過，為避免給這么多算法調(diào)配參數(shù)，直接采用的辦法是：每個(gè)參數(shù)的取值范圍均等分一下——反正隨機(jī)森林不要求什么特征工程。如，用 holt-winters 做為一類 detector。holt-winters 有α，β，γ 三個(gè)參數(shù)，取值范圍都是 [0, 1]。那么它就采樣為 (0.2, 0.4, 0.6, 0.8)，也就是 4 ** 3 = 64 個(gè)可能。那么每個(gè)點(diǎn)就此得到 64 個(gè)特征值。
異常檢測之
Opprentice 系統(tǒng)與 Skyline 很相似
Opprentice 系統(tǒng)整個(gè)流程跟 skyline 的思想相似之處在于先通過不同的統(tǒng)計(jì)學(xué)上的算法來嘗試發(fā)現(xiàn)異常，然后通過一個(gè)多數(shù)同意的方式/算法來確定最終的判定結(jié)果。
只不過這里百度采用了一個(gè)隨機(jī)森林的算法，來更靠譜一點(diǎn)的投票。而 Etsy 呢？在 skyline 開源幾個(gè)月后，他們內(nèi)部又實(shí)現(xiàn)了新版本，叫 Thyme。利用了小波分解、傅里葉變換、Mann-whitney 檢測等等技術(shù)。
另外，社區(qū)在 Skyline 上同樣做了后續(xù)更新，Earthgecko 利用 Tsfresh 模塊來提取時(shí)序數(shù)據(jù)的特征值，以此做多時(shí)序之間的異常檢測。我們可以看到，后續(xù)發(fā)展的兩種 Skyline，依然都沒有使用機(jī)器學(xué)習(xí)，而是進(jìn)一步深度挖掘和調(diào)整時(shí)序相關(guān)的統(tǒng)計(jì)學(xué)算法。
開源社區(qū)除了 Etsy，還有諸多巨頭也開源過各式其他的時(shí)序異常檢測算法庫，大多是在 2015 年開始的。列舉如下：
Yahoo! 在去年開源的 egads 庫。(Java)
Twitter 在去年開源的 anomalydetection 庫。(R)
Netflix 在 2015 年開源的 Surus 庫。(Pig，基于PCA)
其中 Twitter 這個(gè)庫還被 port 到 Python 社區(qū)，有興趣的讀者也可以試試。
二、歸因分析
歸因分析是運(yùn)維工作的下一大塊內(nèi)容，就是收到報(bào)警以后的排障。對于簡單故障，應(yīng)對方案一般也很簡單，采用 service restart engineering~ 但是在大規(guī)模 IT 環(huán)境下，通常一個(gè)故障會(huì)觸發(fā)或?qū)е麓竺娣e的告警發(fā)生。如果能從大面積的告警中，找到最緊迫最要緊的那個(gè)，肯定能大大的縮短故障恢復(fù)時(shí)間(MTTR)。
這個(gè)故障定位的需求，通常被歸類為根因分析（RCA，Root Cause Analysis）。當(dāng)然，RCA 可不止故障定位一個(gè)用途，性能優(yōu)化的過程通常也是 RCA 的一種。
歸因分析之 Oculus 模塊
和異常檢測一樣，做 RCA 同樣是可以統(tǒng)計(jì)學(xué)和機(jī)器學(xué)習(xí)方法并行的~我們還是從統(tǒng)計(jì)學(xué)的角度開始。依然是 Etsy 的 kale 系統(tǒng)，其中除了做異常檢測的 skyline 以外，還有另外一部分，叫 Oculus。而且在 Etsy 重構(gòu) kale 2.0 的時(shí)候，Oculus 被認(rèn)為是1.0 最成功的部分，完整保留下來了。
Oculus 的思路，用一句話描述，就是：如果一個(gè)監(jiān)控指標(biāo)的時(shí)間趨勢圖走勢，跟另一個(gè)監(jiān)控指標(biāo)的趨勢圖長得比較像，那它們很可能是被同一個(gè)根因影響的。那么，如果整體 IT 環(huán)境內(nèi)的時(shí)間同步是可靠的，且監(jiān)控指標(biāo)的顆粒度比較細(xì)的情況下，我們就可能近似的推斷：跟一個(gè)告警比較像的最早的那個(gè)監(jiān)控指標(biāo)，應(yīng)該就是需要重點(diǎn)關(guān)注的根因了。
Oculus 截圖如下：
這部分使用的 計(jì)算方式有兩種：
歐式距離，就是不同時(shí)序數(shù)據(jù)，在相同時(shí)刻做對比。假如0分0秒，a和b相差1000，0分5秒，也相差1000，依次類推。
FastDTW，則加了一層偏移量，0分0秒的a和0分5秒的b相差1000，0分5秒的a和0分10秒的b也相差1000，依次類推。當(dāng)然，算法在這個(gè)簡單假設(shè)背后，是有很多降低計(jì)算復(fù)雜度的具體實(shí)現(xiàn)的，這里就不談了。
唯一可惜的是 Etsy 當(dāng)初實(shí)現(xiàn) Oculus 是基于 ES 的 0.20 版本，后來該版本一直沒有更新。現(xiàn)在停留在這么老版本的 ES 用戶應(yīng)該很少了。除了 Oculus，還有很多其他產(chǎn)品，采用不同的統(tǒng)計(jì)學(xué)原理，達(dá)到類似的效果。
歸因分析之 Granger causality
Granger causality（格蘭杰因果關(guān)系）是一種算法，簡單來說它通過比較“已知上一時(shí)刻所有信息，這一時(shí)刻 X 的概率分布情況”和“已知上一時(shí)刻除 Y 以外的所有信息，這一時(shí)刻 X 的概率分布情況”，來判斷 Y 對 X 是否存在因果關(guān)系。
可能有了解過一點(diǎn)機(jī)器學(xué)習(xí)信息的讀者會(huì)很詫異了：不是說機(jī)器只能反應(yīng)相關(guān)性，不能反應(yīng)因果性的么？需要說明一下，這里的因果，是統(tǒng)計(jì)學(xué)意義上的因果，不是我們通常哲學(xué)意義上的因果。
統(tǒng)計(jì)學(xué)上的因果定義是：『在宇宙中所有其他事件的發(fā)生情況固定不變的條件下，如果一個(gè)事件 A 的發(fā)生與不發(fā)生對于另一個(gè)事件 B 的發(fā)生的概率有影響，并且這兩個(gè)事件在時(shí)間上有先后順序（A 前 B 后），那么我們便可以說 A 是 B 的原因。』
歸因分析之皮爾遜系數(shù)
另一個(gè)常用的算法是皮爾遜系數(shù)。下圖是某 ITOM 軟件的實(shí)現(xiàn)：
我們可以看到，其主要元素和采用 FastDTW 算法的 Oculus 類似：correlation 表示相關(guān)性的評分、lead/lag 表示不同時(shí)序數(shù)據(jù)在時(shí)間軸上的偏移量。
皮爾遜系數(shù)在 R 語言里可以特別簡單的做到。比如我們拿到同時(shí)間段的訪問量和服務(wù)器 CPU 使用率：
然后運(yùn)行如下命令：
acc_count<-scale(acc$acc_count,center=T,scale=T)
cpu<-scale(acc$cpuload5,center=T,scale=T)
cor.test(acc_count,cpu)
可以看到如下結(jié)果輸出：
對應(yīng)的可視化圖形如下：
這就說明網(wǎng)站數(shù)據(jù)訪問量和 CPU 存在弱相關(guān)，同時(shí)從散點(diǎn)圖上看兩者為非線性關(guān)系。因此訪問量上升不一定會(huì)真正影響 CPU 消耗。
其實(shí) R 語言不太適合嵌入到現(xiàn)有的運(yùn)維系統(tǒng)中。那這時(shí)候使用 Elasticsearch 的工程師就有福了。ES 在大家常用的 metric aggregation、bucket aggregation、pipeline aggregation 之外，還提供了一種 matrix aggregation，目前唯一支持的 matrix_stats 就是采用了皮爾遜系數(shù)的計(jì)算，接口文檔見：
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-matrix-stats-aggregation.html
唯一需要注意的就是，要求計(jì)算相關(guān)性的兩個(gè)字段必須同時(shí)存在于一個(gè) event 里。所以沒法直接從現(xiàn)成的 ES 數(shù)據(jù)中請求不同的 date_histogram，然后計(jì)算，需要自己手動(dòng)整理一遍，轉(zhuǎn)儲回 ES 再計(jì)算。
饒琛琳，目前就職日志易，有十年運(yùn)維工作經(jīng)驗(yàn)。在微博擔(dān)任系統(tǒng)架構(gòu)師期間，負(fù)責(zé)帶領(lǐng)11人的SRE團(tuán)隊(duì)。著有《網(wǎng)站運(yùn)維技術(shù)與實(shí)踐》、《ELKstack權(quán)威指南》，合譯有《Puppet 3 Cookbook》、《Learning Puppet 4》。在眾多技術(shù)大會(huì)上分享過自動(dòng)化運(yùn)維與數(shù)據(jù)分析相關(guān)主題。
IT運(yùn)維平臺算法背后的兩大“神助攻”
智能運(yùn)維(AIops)是目前 IT 運(yùn)維領(lǐng)域最火熱的詞匯,全稱是 Algorithmic IT operations platforms,正規(guī)翻譯是『基于算法的 IT 運(yùn)維平臺』,直觀可見算法是智能運(yùn)維的核心要素之一。本文主要談算法對運(yùn)維的作用,涉及異常檢測和歸因分析兩方面,圍繞運(yùn)維系統(tǒng)Kale 中 skyline、Oculus 模塊、Opprentice 系統(tǒng)、Granger causality(格...
相關(guān)評說：
嘉蔭縣蝸桿： ______ 云吶IT交互服務(wù)臺,針對解決企業(yè)信息互聯(lián)互通問題,幫助企業(yè)智能化管理企業(yè)內(nèi)外業(yè)務(wù),功能非常全面,故應(yīng)該不僅限于國內(nèi)企業(yè).
嘉蔭縣蝸桿： ______ 隨著電腦的普及應(yīng)用和互聯(lián)網(wǎng)的快速發(fā)展,電子商務(wù)已經(jīng)逐漸成為人們進(jìn)行商務(wù)活動(dòng)的新模式;電子商務(wù)在提高商務(wù)效率、降低商務(wù)交易成本的同時(shí),本身安全性也隨之而至,成為制約其進(jìn)一步發(fā)...
嘉蔭縣蝸桿： ______ IT運(yùn)維是指IT設(shè)備的運(yùn)行維護(hù).保證設(shè)備正常運(yùn)行,并且注意還有運(yùn)行的概念,比如客戶需要?jiǎng)?chuàng)建一個(gè)虛擬機(jī),你幫客戶創(chuàng)建了,這也是運(yùn)行.他和運(yùn)營也就是沒有把錢引進(jìn)去而已.總的來說,IT運(yùn)維是指用技術(shù)等手段保證業(yè)務(wù)正常運(yùn)轉(zhuǎn).
嘉蔭縣蝸桿： ______ 1、安全,公司的運(yùn)維首先應(yīng)當(dāng)將安全放在第一位.安全漏洞,信息泄露這些都會(huì)關(guān)系到公司的未來發(fā)展甚至是生死存亡,發(fā)生在互聯(lián)網(wǎng)公司的信息泄露事件不在少數(shù),都給這些公司造成很大的負(fù)面影響,要想挽回這些影響資金上的付出是很大...
嘉蔭縣蝸桿： ______ 用一些IT運(yùn)維管理軟件,比如流程管理軟件,監(jiān)控軟件.每發(fā)生一個(gè)事件就創(chuàng)建一個(gè)工單,創(chuàng)建工單后就開始計(jì)時(shí),運(yùn)維人員必須在規(guī)定事件內(nèi)完成,如果沒能完成,就會(huì)在后續(xù)的統(tǒng)計(jì)分析中顯示出來,影響當(dāng)月或者當(dāng)年度的績效考核.當(dāng)然,這需要一個(gè)統(tǒng)一的服務(wù)臺進(jìn)行調(diào)度,對每個(gè)工程師的特長,還有是否有空閑都清楚.云雀運(yùn)維就是這樣的,通過這個(gè)平臺可以監(jiān)控大部分的設(shè)備節(jié)點(diǎn),當(dāng)發(fā)生故障的時(shí)候,會(huì)自動(dòng)的向工程師的手機(jī)發(fā)短信和微信,工程師只有接收并創(chuàng)建工單后才能停止,創(chuàng)建工單后就會(huì)顯示時(shí)間,所以工程師必須盡力解決,這樣就大大提高了工作效率.
嘉蔭縣蝸桿： ______ 大把運(yùn)維工種,幾天都說不完,下面簡單介紹下 1)IT運(yùn)維IT運(yùn)維是IT管理的核心和重點(diǎn)部分,也是內(nèi)容最多、最繁雜的部分,常見的IT運(yùn)維:硬件化的蟻巡運(yùn)維平臺,軟件形態(tài)的的HP Operations Orchestration、IBM tivoli等還有開源的軟件Nagios...
嘉蔭縣蝸桿： ______ ITSM V3.0(運(yùn)維管理平臺) ECC V8.8(綜合系統(tǒng)管理) NNM V3.7(拓?fù)渫?
嘉蔭縣蝸桿： ______ A.近幾年很流行云桌面,云計(jì)算類的企業(yè)辦公軟件,個(gè)人推薦虛擬化,這種呢,一般在服務(wù)器端安裝應(yīng)用,集中在服務(wù)器管理應(yīng)用程序,按需分配應(yīng)用資源,統(tǒng)一升級維護(hù).這樣子就可以大大降低IT運(yùn)維成本和人力,減輕工作量.市場上很多相關(guān)的軟件,比如云舒3C,微軟,思杰等.B.將全部應(yīng)用資源部署在服務(wù)器上,通過應(yīng)用虛擬化軟件直接發(fā)布給每一個(gè)用戶就可以了.
嘉蔭縣蝸桿： ______ 這個(gè)其實(shí)就是說的有效監(jiān)控、監(jiān)管你的IT設(shè)備資源,IT應(yīng)用的問題.下面的只重點(diǎn)說一下個(gè)人對服務(wù)器與服務(wù)器應(yīng)用進(jìn)行有效監(jiān)管,其實(shí),下面這個(gè)軟件對網(wǎng)絡(luò)設(shè)備、機(jī)房環(huán)境等IT運(yùn)維同樣有效,只是有其它的模塊里.我今天想說的是,你們服務(wù)...
