為了支撐業(yè)務(wù)的高速發(fā)展，京東物流在智能運(yùn)維體系的落地和構(gòu)建方案上一直迭代優(yōu)化、持續(xù)演進(jìn)。從構(gòu)建基于系統(tǒng)指標(biāo)的實(shí)時(shí)大規(guī)模智能監(jiān)控平臺到融合多個(gè)部門多個(gè)監(jiān)控平臺的統(tǒng)一監(jiān)控平臺實(shí)踐，再到基于 APM 的智能運(yùn)維體系落地。通過實(shí)時(shí)告警、實(shí)時(shí)預(yù)警、故障智能處理以及全方位的應(yīng)用維度數(shù)據(jù)分析，大大縮短了研發(fā)人員定位問題的效率，有力保障了大促期間各系統(tǒng)的平穩(wěn)運(yùn)行。 我們在構(gòu)建這套運(yùn)維體系的時(shí)候大體上分為以下三個(gè)階段：
下面我會從以下幾個(gè)方面來介紹今天的內(nèi)容：
智能運(yùn)維的發(fā)展 關(guān)于智能運(yùn)維的發(fā)展，我們將發(fā)展過程分為以上七個(gè)階段。前三個(gè)階段從手工運(yùn)維發(fā)展到面向業(yè)務(wù)服務(wù)的主動管理。第四個(gè)階段是服務(wù)驅(qū)動，該階段建立了統(tǒng)一的 CMDB 系統(tǒng)，這時(shí)候我們需要服務(wù)的流程化來支撐整個(gè)運(yùn)維體系，比如一些工單系統(tǒng)等等。 運(yùn)維發(fā)展的第五階段是自動化和平臺化，該階段將運(yùn)維工具、流程集成為統(tǒng)一的運(yùn)維平臺，提供資產(chǎn)管理、監(jiān)控告警、故障處理等運(yùn)維服務(wù)，此時(shí)已經(jīng)構(gòu)建了初步的平臺化的運(yùn)維體系。目前多數(shù)企業(yè)還是處在自動化和平臺化的階段。 下一階段是數(shù)據(jù)化。監(jiān)控平臺、運(yùn)維平臺將持續(xù)產(chǎn)生大量的數(shù)據(jù)，這一階段我們運(yùn)維平臺的主要任務(wù)就是結(jié)合大數(shù)據(jù)分析的工具和技術(shù)，挖掘數(shù)據(jù)價(jià)值。統(tǒng)計(jì)數(shù)據(jù)和結(jié)論反過來又可以作為實(shí)際運(yùn)營決策的重要參考。 最后一個(gè)階段是智能運(yùn)維領(lǐng)域的趨勢——AIOps。將 AI 技術(shù)應(yīng)用于運(yùn)維領(lǐng)域，在異常檢測、根因分析、故障預(yù)測、智能故障處理、智能運(yùn)維機(jī)器人等方面已經(jīng)取得了階段性進(jìn)展。但目前實(shí)現(xiàn) AIOps 真正落地的不多，各企業(yè)目前只是在 AIOps 的某幾個(gè)點(diǎn)上去發(fā)力和探索。因此，AIOps 之路任重道遠(yuǎn)，需要學(xué)術(shù)界和運(yùn)維界兩方面一起努力。 面臨的挑戰(zhàn) 現(xiàn)在我們遇到的挑戰(zhàn)主要有：
拓?fù)?/h3>以前大家可能面對的是一個(gè)應(yīng)用只操作一個(gè)數(shù)據(jù)庫這種傳統(tǒng)的應(yīng)用架構(gòu)，而現(xiàn)在幾乎所有的應(yīng)用都已經(jīng)加入了微服務(wù)架構(gòu)的行列，應(yīng)用之間的調(diào)用情況就變得很復(fù)雜，在定位系統(tǒng)問題的時(shí)候就非常被動，這也是我們面臨的一個(gè)問題。  APMAPM 是近幾年才興起。據(jù) Gartner 統(tǒng)計(jì)，APM 是整個(gè) ITOM，甚至 ITSM 領(lǐng)域里增長最快的一個(gè)領(lǐng)域，有很廣闊的市場前景，目前全球 APM 市場規(guī)模大大約為 60 億美元，預(yù)計(jì)在 5 年內(nèi)可以達(dá)到 90 億美元。目前國內(nèi)外的 APM 廠商已經(jīng)比較多，正處于群雄逐鹿的階段。  運(yùn)維人員的角色變化由傳統(tǒng)運(yùn)維向智能運(yùn)維的轉(zhuǎn)型，除了產(chǎn)品、技術(shù)架構(gòu)的升級之外還需要運(yùn)維團(tuán)隊(duì)由背鍋、救火式的被動運(yùn)維向主動發(fā)現(xiàn)、處理、規(guī)避問題的主動運(yùn)維轉(zhuǎn)變來驅(qū)動。 以上說到的諸多挑戰(zhàn)和新技術(shù)的發(fā)展倒逼運(yùn)維人員主動尋求變化，不能像以前一樣，一提到運(yùn)維就是背鍋俠或者救火隊(duì)員。要改變這種被動運(yùn)維的方式，首先就要轉(zhuǎn)變思想：運(yùn)維也可以主動?？梢詮哪男┓矫嬷鲃幽?？
 智能運(yùn)維體系建設(shè)方法論 那么到底要如何實(shí)現(xiàn)智能運(yùn)維的落地呢？ 我覺得第一點(diǎn)，就是統(tǒng)一規(guī)劃，避免重復(fù)建設(shè)。很多公司發(fā)展到一定的規(guī)模之后，由于前期運(yùn)維體系的發(fā)展規(guī)劃不足，可能每個(gè)部門都有自己的一套運(yùn)維或者監(jiān)控平臺，平臺繁多就容易形成數(shù)據(jù)孤島，導(dǎo)致數(shù)據(jù)串不起來，無法做全面的數(shù)據(jù)分析工作。 上面這張圖是京東物流的運(yùn)維體系規(guī)劃。最下層是資源層，包括物理資源、虛擬資源、應(yīng)用、中間件以及數(shù)據(jù)庫。上層是平臺層。在平臺層，我們建立了維護(hù)基礎(chǔ)數(shù)據(jù)的 CMDB 系統(tǒng)，在 ITSM 管理方面，集成了事件管理、問題管理、值班管理等運(yùn)維流程化管理模塊。在 CMDB 系統(tǒng)基礎(chǔ)上我們建設(shè)了大規(guī)模資源監(jiān)控平臺、網(wǎng)絡(luò)監(jiān)控平臺以及多個(gè)運(yùn)維平臺。京東物流在全國 550 個(gè)大型倉庫中還運(yùn)營著幾百個(gè)庫房的集群，針對庫房運(yùn)維管理我們建設(shè)了庫房運(yùn)維和數(shù)據(jù)庫運(yùn)維平臺。通過 DevOps 平臺將 CMDB、監(jiān)控、運(yùn)維等多個(gè)平臺數(shù)據(jù)關(guān)聯(lián)起來，形成閉環(huán)，從而建立基礎(chǔ)的運(yùn)維體系。 再往上，是數(shù)據(jù)化層。在這一層，我們期望通過對監(jiān)控和運(yùn)維平臺產(chǎn)生的大量數(shù)據(jù)進(jìn)行分析，做趨勢性的預(yù)測和智能分析，提供一些比較有價(jià)值的統(tǒng)計(jì)報(bào)表，來指導(dǎo)業(yè)務(wù)運(yùn)營和決策。 最上層是 AIOps 層，我們是從三個(gè)方面去實(shí)現(xiàn)的：發(fā)現(xiàn)問題，解決問題，規(guī)避問題?；?AIOps，我們可以在異常檢測、根因分析、故障預(yù)測、智能故障處理、智能運(yùn)維機(jī)器人等方面繼續(xù)發(fā)力探索。在解決問題方面，可以借助 KPI 聚類分析進(jìn)行告警知識庫自學(xué)習(xí)和故障自動處理等。只有前兩個(gè)方面做好了，才能保證提前預(yù)估故障并進(jìn)行預(yù)修復(fù)從而達(dá)到規(guī)避問題的效果，這是最理想的狀態(tài)。 標(biāo)準(zhǔn)化是前提。也就是說我們所有的監(jiān)控平臺也好，運(yùn)維平臺也好，都要遵循統(tǒng)一的開發(fā)和設(shè)計(jì)標(biāo)準(zhǔn)，這樣不僅能夠提升產(chǎn)品質(zhì)量而且利于以后的擴(kuò)展和維護(hù)。這里分享一下我們運(yùn)維體系產(chǎn)品研發(fā)的原則：產(chǎn)品標(biāo)準(zhǔn)化、系統(tǒng)平臺化、監(jiān)控服務(wù)化、組件模塊化、腳本插件化。 產(chǎn)品化思維。由研發(fā)思維向產(chǎn)品化思維轉(zhuǎn)變。前面已經(jīng)提到過，運(yùn)維平臺的用戶不止是運(yùn)維人員，還有大量的研發(fā)人員。因此我們要從研發(fā)的角度考慮運(yùn)維產(chǎn)品設(shè)計(jì)，充分考慮研發(fā)需求的同時(shí)注重服務(wù)的流程化，也可以理解為需求驅(qū)動。 還有一個(gè)概念，是運(yùn)維中臺?，F(xiàn)在京東也在做一些中臺相關(guān)的工作，同樣我們運(yùn)維領(lǐng)域也需要中臺，比如我們可以把監(jiān)控?cái)?shù)據(jù)集中處理、清洗、告警、通知、分析等主要數(shù)據(jù)處理作為中臺，把統(tǒng)計(jì)數(shù)據(jù)、大數(shù)據(jù)分析的結(jié)論數(shù)據(jù)等封裝為數(shù)據(jù)組件，這樣其他的一些相關(guān)應(yīng)用可以作為前臺，接入到運(yùn)維中臺，這個(gè)方面我們也已經(jīng)做了一些嘗試了，取得了不錯的效果。 還有就是注重業(yè)務(wù)增值。我們往往針對運(yùn)維平臺的設(shè)計(jì)只注重提高研發(fā)效率，而較少考慮業(yè)務(wù)增值。我們在嘗試的業(yè)務(wù)增值的例子：統(tǒng)計(jì)服務(wù)器、網(wǎng)絡(luò)設(shè)備、物理設(shè)備的廠商、型號以及故障率，提供故障率較高的型號報(bào)表，這樣采購的時(shí)候也更有針對性。再比如提供各應(yīng)用、部門的資源使用率報(bào)表以及低資源使用率榜單，以此督促資源使用率較低的應(yīng)用或部門進(jìn)行縮容整改。 過程改進(jìn)。運(yùn)維體系的建設(shè)不是一蹴而就的，需要結(jié)合過程改進(jìn)的工具和方法不斷迭代優(yōu)化。  閉環(huán)。在整個(gè)智能運(yùn)維體系中包含諸多資源管理平臺、監(jiān)控平臺、運(yùn)維平臺等，平臺之間在數(shù)據(jù)和流程上是分散的，在 DevOps 平臺中將這些平臺串連起來以達(dá)到閉環(huán)的效果。DevOps 平臺貫穿運(yùn)維管理的全流程，可以說是整個(gè)智能運(yùn)維體系實(shí)現(xiàn)閉環(huán)的關(guān)鍵。比如我們在發(fā)布應(yīng)用的時(shí)候，從應(yīng)用的申請、資源的申請，到代碼編譯、測試，甚至到監(jiān)控，變更，一直到這個(gè)機(jī)器下線、應(yīng)用下線，我們都整合到 DevOps 平臺，這樣就做到了閉環(huán)。在做智能運(yùn)維體系建設(shè)的時(shí)候，如果達(dá)不到閉環(huán)的狀態(tài)，那么整個(gè)運(yùn)維流程就不完善，無法實(shí)現(xiàn)對運(yùn)維事件的實(shí)時(shí)跟蹤。這樣的閉環(huán)也促進(jìn)了資源的生命周期管理、流程管理以及審計(jì)管理等生態(tài)建設(shè)。 大規(guī)模實(shí)時(shí)監(jiān)控平臺的實(shí)踐方案 京東物流大規(guī)模實(shí)時(shí)監(jiān)控平臺從 2018 年初開始構(gòu)建。我們經(jīng)歷了三個(gè)大的階段： 第一階段針對京東物流特殊的 IT 環(huán)境，我們實(shí)現(xiàn)了從 0 到 1 重新建立一套完整的大規(guī)模實(shí)時(shí)監(jiān)控平臺。 監(jiān)控平臺不同于普通業(yè)務(wù)平臺，普通業(yè)務(wù)平臺并發(fā)量峰值大多與時(shí)間相關(guān)，或者隨時(shí)間波動。監(jiān)控平臺最大的特點(diǎn)是 24*7 全時(shí)段監(jiān)控，平臺的壓力負(fù)載情況一直處于較高的狀態(tài)。所以監(jiān)控平臺一定要做到低延時(shí)、高并發(fā)、高可用。以下是我們架構(gòu)設(shè)計(jì)考慮的關(guān)鍵點(diǎn)：
那我們是如何從架構(gòu)方面落地實(shí)現(xiàn)的呢？我們將整體系統(tǒng)架構(gòu)拆分為底層數(shù)據(jù)處理架構(gòu)和業(yè)務(wù)架構(gòu)，底層數(shù)據(jù)處理架構(gòu)負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)的采集、數(shù)據(jù)清洗、校驗(yàn)、告警和通知操作。業(yè)務(wù)架構(gòu)負(fù)責(zé)監(jiān)控?cái)?shù)據(jù)統(tǒng)計(jì)分析、展現(xiàn)。 首先我們采用被動監(jiān)控的方式，通過部署監(jiān)控 Agent，把監(jiān)控?cái)?shù)據(jù)收集到 Kafka 消息隊(duì)列里。消費(fèi)模塊從 kafka 拿到數(shù)據(jù)后轉(zhuǎn)存到 jimdb（京東內(nèi)部的內(nèi)存數(shù)據(jù)庫中間件）中，jimdb 實(shí)際是一個(gè)內(nèi)存的分布式消息隊(duì)列。這里加了一層 jimdb 的隊(duì)列。為什么要加這層呢？因?yàn)槲覀內(nèi)绻苯酉M(fèi) Kafka，Kafka 有分區(qū)的概念，不同的分區(qū)之間可以并發(fā)生產(chǎn)消息，但是 Kafka 的分區(qū)是消耗磁盤 IO 的，如果我們建的分區(qū)太多，這個(gè)磁盤 IO 可能就會是一個(gè)瓶頸，而且意味著我們要需要更多的硬件資源?？紤]到這一點(diǎn)，我們增加了 jimdb 層，它是一個(gè)生產(chǎn)者消費(fèi)者模型的分布式消息隊(duì)列，理論上可以有無數(shù)個(gè) Consumer，這些 Consumer 之間并發(fā)消費(fèi)數(shù)據(jù)，從而實(shí)現(xiàn)并發(fā)數(shù)據(jù)處理。 1.0 版本我們還注重降本增效，從應(yīng)用維度統(tǒng)計(jì)了所有部門、應(yīng)用的資源使用率。監(jiān)控平臺建立起來之后，我們發(fā)現(xiàn)某些應(yīng)用或是機(jī)器的使用率很低，資源沒有得到充分利用，還有很大的優(yōu)化空間。于是我們提供了一些低使用率榜單，定時(shí)發(fā)送督促各個(gè)業(yè)務(wù)條線縮容，這也是業(yè)務(wù)增值的一個(gè)體現(xiàn)。  第二階段實(shí)時(shí)監(jiān)控平臺 2.0 的時(shí)候，針對京東目前多個(gè)監(jiān)控系統(tǒng)并存、監(jiān)控?cái)?shù)據(jù)沒有互通的問題，我們把所有的監(jiān)控平臺的監(jiān)控?cái)?shù)據(jù)整合在一起，接入了京東目前所有的監(jiān)控系統(tǒng)，包括 log 監(jiān)控、Docker 監(jiān)控，MDC 的監(jiān)控，DBS 的數(shù)據(jù)庫監(jiān)控，還有調(diào)用鏈監(jiān)控等，把數(shù)據(jù)收集起來做統(tǒng)一的報(bào)警和分析。一方面有助于對應(yīng)用進(jìn)行更加全方位的數(shù)據(jù)分析與監(jiān)控狀態(tài)評估，另一方面也有助于后期建立根因分析的時(shí)候結(jié)合分布式跟蹤系統(tǒng)去構(gòu)建業(yè)務(wù)拓?fù)洹?/p>  在 2.0 版本，我們會把所有監(jiān)控平臺的指標(biāo)收集上來之后，在應(yīng)用維度做統(tǒng)一的整合。這樣在一個(gè)應(yīng)用頁面，就可以看到這個(gè)應(yīng)用相關(guān)的所有監(jiān)控信息，比如操作系統(tǒng)維度的指標(biāo)，數(shù)據(jù)庫相關(guān)指標(biāo)、應(yīng)用性能相關(guān)指標(biāo)以及日志相關(guān)的指標(biāo)等。此外，我們還加入了日志分析的相關(guān)功能，使用的是業(yè)界比較成熟的方案：通過 agent 將日志發(fā)送到 Kafka，Kafka 里面做一些 Cluster，F(xiàn)ilter，最后存儲和索引。  第三階段有了前面兩個(gè)大版本的支撐，我們監(jiān)控平臺的 3.0 版本開始向 AIOps 發(fā)力。下圖是產(chǎn)品的大體規(guī)劃。左側(cè)是一些普通的接入服務(wù)，監(jiān)控平臺首先進(jìn)行數(shù)據(jù)采集、清洗的工作。在數(shù)據(jù)處理層上新增了可視化、事件處理、知識庫、動態(tài)檢測、動態(tài)預(yù)知等模塊。這些功能點(diǎn)屬于 AIOps 領(lǐng)域的初級功能都已經(jīng)基本實(shí)現(xiàn)了。其他還有數(shù)據(jù)分析，包括容量預(yù)測、趨勢預(yù)測和分析，也都有所涉及，目前我們重點(diǎn)在 AIOps 其他領(lǐng)域進(jìn)行探索。 預(yù)測是 3.0 版本里的一個(gè)重點(diǎn)，大體上分為故障預(yù)測、容量預(yù)測和性能預(yù)測。我們之前嘗試了業(yè)界基于 RSTM 的一個(gè)算法，該算法是基于時(shí)序數(shù)據(jù)預(yù)測的一個(gè)經(jīng)典算法，實(shí)際使用后的預(yù)測效果還是很不錯的，參考下圖。 在 3.0 方面，我們還做了一些可視化的事情。在備戰(zhàn) 618、雙十一期間可以把主流程關(guān)鍵應(yīng)用的監(jiān)控狀態(tài)信息直觀地顯示在監(jiān)控大屏上。任何的異?；蛘邎?bào)警都可以實(shí)時(shí)看到。大屏左側(cè)和右側(cè)展示的是性能方面的數(shù)據(jù)，比如 CPU、Load、磁盤，還有數(shù)據(jù)庫的一些關(guān)鍵指標(biāo)，下面則是實(shí)時(shí)滾動的告警信息。 智能故障定位與處理實(shí)踐在故障處理方面我們比較好的一個(gè)實(shí)踐是快照機(jī)制。當(dāng)監(jiān)測到異常時(shí)系統(tǒng)會在觸發(fā)報(bào)警的時(shí)刻立即觸發(fā)快照，在系統(tǒng)上抓一些現(xiàn)場信息，現(xiàn)場快照信息包含：占用 CPU 較高的線程排名、JVM 內(nèi)存堆棧信息、網(wǎng)絡(luò)信息以及磁盤 io 信息等。在發(fā)出告警通知的同時(shí)提供該快照信息的訪問鏈接。快照頁面同時(shí)也會列出該告警前后半小時(shí)內(nèi)各種指標(biāo)的趨勢情況，供研發(fā)去定位問題。要注意的一點(diǎn)是我們在存儲快照信息時(shí)沒有把快照存到統(tǒng)一的服務(wù)端，而是直接存在機(jī)器里面。其原因是 JVM 內(nèi)存堆棧通常較大，若將快照信息發(fā)送至遠(yuǎn)端統(tǒng)一存儲那么勢必增加網(wǎng)絡(luò)壓力，可能會影響到業(yè)務(wù)的正常運(yùn)行。 另外我們也在根因分析上做了一些嘗試。在做根因分析的時(shí)候，我們首先要做的就是要把指標(biāo)和應(yīng)用的一些關(guān)聯(lián)拓?fù)錁?gòu)建出來。指標(biāo)和應(yīng)用的拓?fù)湟蕾囮P(guān)系應(yīng)該如何去構(gòu)建呢？這主要依賴于分布式跟蹤系統(tǒng)進(jìn)行自動探測應(yīng)用拓?fù)洹５趯?shí)際應(yīng)用中，通常我們探測的拓?fù)潢P(guān)系比較復(fù)雜需要結(jié)合人工標(biāo)注的方式為拓?fù)湓黾酉鄳?yīng)的權(quán)重作為拓?fù)湟蕾囮P(guān)系的一個(gè)修正。有了應(yīng)用拓?fù)渲g的依賴關(guān)系之后，基于大量歷史告警數(shù)據(jù)進(jìn)行自學(xué)習(xí)，分析每個(gè)故障時(shí)間點(diǎn)應(yīng)用和指標(biāo)之間的關(guān)聯(lián)關(guān)系匯總為知識庫數(shù)據(jù)，并存儲到知識庫系統(tǒng)。這個(gè)不斷完善的知識庫系統(tǒng)可以作為研發(fā)定位問題的依據(jù)，也可以作為故障自動處理的依據(jù)，還可以作為運(yùn)維機(jī)器人的知識來源。同時(shí)，知識庫也支持人工添加一些常見的故障以及故障原因并給予較高的分析權(quán)重?；诓粩嘈拚臉I(yè)務(wù)拓?fù)潢P(guān)系，系統(tǒng)就可以自動找出一個(gè)或幾個(gè)故障的根因。 APM 在京東物流的落地實(shí)踐關(guān)于 APM，Google Dapper 可以說是所有 APM 產(chǎn)品的鼻祖?；?Dapper，近年來也出現(xiàn)了非常多的優(yōu)秀的 APM 產(chǎn)品。比如商業(yè)化的 APM 廠商：New Relic/聽云等，還有一些比較優(yōu)秀的開源項(xiàng)目：Pinpoint/Zipkin/Cat/EagleEye/OpenTracing/SkyWalking 等。各種 APM 產(chǎn)品各有優(yōu)劣，結(jié)合自身業(yè)務(wù)需求并充分對比分析后我們選擇基于 pinpoint 進(jìn)行二次開發(fā)實(shí)現(xiàn) APM。它的缺點(diǎn)在于性能方面比 Zipkin、SkyWalking 要差一點(diǎn)，但是 pinpoint 也有項(xiàng)目不具備的優(yōu)勢，比如接入簡單無需修改代碼，再比如可以跟蹤到代碼級別等等。目前有很多國內(nèi)外的廠商都在做 APM 的產(chǎn)品，如果企業(yè)計(jì)劃做 AIOps 的話我們不推薦直接使用廠商的產(chǎn)品，因?yàn)閺S商的 APM 底層數(shù)據(jù)對客戶是不透明的。而自主研發(fā) APM 平臺最大的意義在于 APM 里面有大量的數(shù)據(jù)是我們可以使用的，通過對這些基礎(chǔ)數(shù)據(jù)進(jìn)行大數(shù)據(jù)分析以及數(shù)據(jù)挖掘之后，可以為 AIOps 提供很多數(shù)據(jù)來源。如果使用廠商的產(chǎn)品，在很多方面底層數(shù)據(jù)的使用就不是那么自由了。 下面介紹一下我們在 APM 方面的進(jìn)展，我們基于 pinpoint 開發(fā)的 Jtrace 分布式跟蹤系統(tǒng)擁有 7 大能力：
關(guān)于性能方面，我們從以下幾個(gè)方面進(jìn)行了優(yōu)化：
優(yōu)化后性能損失與目前流行的 Zipkin 相近。相對于我們獲取的數(shù)據(jù)精度來說，這個(gè)是可以接受的結(jié)果。 AIOps 的落地規(guī)劃下面我們談?wù)劷裉斓淖詈笠粋€(gè)主題：AIOps 的落地規(guī)劃。 前面已經(jīng)有提及，AIOps 主要從發(fā)現(xiàn)問題、解決問題、規(guī)避問題三個(gè)方面來設(shè)計(jì)和實(shí)施。對于發(fā)現(xiàn)問題，很多在做 AIOps 的廠商都已經(jīng)做的很完善了，包括異常檢測，根因分析、智能告警、性能分析、事件分析、日志分析等。對于解決問題這一塊，整個(gè)業(yè)界還處在一個(gè)探索的階段，我們的思路是以自學(xué)習(xí)結(jié)合人工標(biāo)注的知識庫為基礎(chǔ)整合異常反饋、深度學(xué)習(xí)、決策樹等 AI 技術(shù)，實(shí)現(xiàn)故障自動處理。針對非危險(xiǎn)處理動作實(shí)施自動處理并記錄日志，對于高危操作則通過流程審批確認(rèn)后執(zhí)行。針對規(guī)避問題這一目標(biāo)，則是我們對于 AIOps 的愿景。我們希望通過對大數(shù)據(jù)的分析和預(yù)測能夠?qū)θ萘俊⑿阅?、故障進(jìn)行精準(zhǔn)預(yù)測，并提前做好自動應(yīng)對措施以避免問題的產(chǎn)生。如果實(shí)現(xiàn)了這個(gè)目標(biāo)，那么 AIOps 算是真正落地了。 最后和大家分享一下，AIOps 落地的規(guī)劃階段圖。我們也參考了清華大學(xué)裴丹教授的一些想法，將 AIOps 的落地分為幾個(gè)層次：
綜上，AIops 的落地需要學(xué)術(shù)界和工程界的通力合作，任重而道遠(yuǎn)。但好在目前業(yè)界對于 AIOps 的探索和實(shí)踐熱情較高，也有很多階段性的實(shí)踐成果。只要有清晰的建設(shè)思路和規(guī)劃，相信不久的將來 AIOps 很快會在各大企業(yè)開花結(jié)果。屆時(shí)實(shí)現(xiàn)“咖啡運(yùn)維”將不再是難事！ 作者介紹 付正全，京東物流架構(gòu)師，國家認(rèn)證信息系統(tǒng)項(xiàng)目管理師，曾任浪潮集團(tuán)系統(tǒng)架構(gòu)師，專注監(jiān)控運(yùn)維平臺研發(fā) 工作 8 年，研究過市場上數(shù)十家廠商的監(jiān)控運(yùn)維平臺產(chǎn)品， 對 DevOps 和監(jiān)控平臺有比較深入的研究。目前負(fù)責(zé)京東物流火眼監(jiān)控平臺的架構(gòu)設(shè)計(jì)和開發(fā)工作。 |
|
|
