本文整理自 2019 年 QCon 北京站上京東物流架構(gòu)師付正全的演講，主要介紹了京東物流大規(guī)模實(shí)時(shí)監(jiān)控平臺(tái)、AIOps 和 APM 的相關(guān)實(shí)踐。

為了支撐業(yè)務(wù)的高速發(fā)展，京東物流在智能運(yùn)維體系的落地和構(gòu)建方案上一直迭代優(yōu)化、持續(xù)演進(jìn)。從構(gòu)建基于系統(tǒng)指標(biāo)的實(shí)時(shí)大規(guī)模智能監(jiān)控平臺(tái)到融合多個(gè)部門多個(gè)監(jiān)控平臺(tái)的統(tǒng)一監(jiān)控平臺(tái)實(shí)踐，再到基于 APM 的智能運(yùn)維體系落地。通過實(shí)時(shí)告警、實(shí)時(shí)預(yù)警、故障智能處理以及全方位的應(yīng)用維度數(shù)據(jù)分析，大大縮短了研發(fā)人員定位問題的效率，有力保障了大促期間各系統(tǒng)的平穩(wěn)運(yùn)行。

我們?cè)跇?gòu)建這套運(yùn)維體系的時(shí)候大體上分為以下三個(gè)階段：

• 構(gòu)建實(shí)時(shí)的大規(guī)模監(jiān)控平臺(tái)。這個(gè)階段是一個(gè)從 0 到 1 的過程，從基礎(chǔ)的 CMDB 系統(tǒng)建設(shè)到建設(shè)大規(guī)模實(shí)時(shí)監(jiān)控平臺(tái)。

• 第二階段在監(jiān)控平臺(tái)的基礎(chǔ)上整合了京東現(xiàn)有的多個(gè)應(yīng)用監(jiān)控系統(tǒng)。結(jié)合應(yīng)用維度的數(shù)據(jù)整合，進(jìn)一步完善了監(jiān)控?cái)?shù)據(jù)維度的同時(shí)極大提高了研發(fā)人員進(jìn)行故障定位的效率。

• 第三階段我們開始了 APM 和 AIOps 相關(guān)的一些嘗試。

下面我會(huì)從以下幾個(gè)方面來介紹今天的內(nèi)容：

• 智能運(yùn)維發(fā)展的現(xiàn)狀和趨勢

• 智能運(yùn)維體系建設(shè)方法論

• 大規(guī)模實(shí)時(shí)監(jiān)控平臺(tái)的實(shí)踐方案

• 智能故障定位與處理實(shí)踐

• APM 在京東物流的落地實(shí)踐

• 智能運(yùn)維落地規(guī)劃

智能運(yùn)維的發(fā)展

關(guān)于智能運(yùn)維的發(fā)展，我們將發(fā)展過程分為以上七個(gè)階段。前三個(gè)階段從手工運(yùn)維發(fā)展到面向業(yè)務(wù)服務(wù)的主動(dòng)管理。第四個(gè)階段是服務(wù)驅(qū)動(dòng)，該階段建立了統(tǒng)一的 CMDB 系統(tǒng)，這時(shí)候我們需要服務(wù)的流程化來支撐整個(gè)運(yùn)維體系，比如一些工單系統(tǒng)等等。

運(yùn)維發(fā)展的第五階段是自動(dòng)化和平臺(tái)化，該階段將運(yùn)維工具、流程集成為統(tǒng)一的運(yùn)維平臺(tái)，提供資產(chǎn)管理、監(jiān)控告警、故障處理等運(yùn)維服務(wù)，此時(shí)已經(jīng)構(gòu)建了初步的平臺(tái)化的運(yùn)維體系。目前多數(shù)企業(yè)還是處在自動(dòng)化和平臺(tái)化的階段。

下一階段是數(shù)據(jù)化。監(jiān)控平臺(tái)、運(yùn)維平臺(tái)將持續(xù)產(chǎn)生大量的數(shù)據(jù)，這一階段我們運(yùn)維平臺(tái)的主要任務(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)主要有：

• 做傳統(tǒng)運(yùn)維的人越來越少了。傳統(tǒng)運(yùn)維依賴人工操作，有時(shí)也被戲稱為“人肉運(yùn)維”。目前我們京東物流已經(jīng)沒有做傳統(tǒng)運(yùn)維的人員了，大家全部都轉(zhuǎn)向了運(yùn)維開發(fā)，這也是一個(gè)趨勢。在傳統(tǒng)運(yùn)維人員減少的同時(shí)，我們管理的機(jī)器數(shù)量卻翻倍了，這是我們面臨的一個(gè)比較大的問題。

• 網(wǎng)絡(luò)拓?fù)淙找鎻?fù)雜。微服務(wù)出現(xiàn)之后，網(wǎng)絡(luò)拓?fù)潢P(guān)系更加復(fù)雜了，資源頻繁的彈性伸縮，導(dǎo)致 CMDB 和其他應(yīng)用信息無法做到實(shí)時(shí)管理。

• 運(yùn)維專家資源匱乏。運(yùn)維行業(yè)要求硬件、系統(tǒng)、網(wǎng)絡(luò)、腳本語言、開發(fā)能力、應(yīng)用運(yùn)維等多領(lǐng)域的知識(shí)儲(chǔ)備，一名優(yōu)秀的運(yùn)維專家需要長期運(yùn)維工作經(jīng)驗(yàn)的積累。另外，目前運(yùn)維從業(yè)者減少也導(dǎo)致了運(yùn)維專家尤其是有豐富經(jīng)驗(yàn)的運(yùn)維專家資源匱乏的現(xiàn)狀。

• 運(yùn)維平臺(tái)日趨復(fù)雜。很多公司發(fā)展到一定的規(guī)模之后，因?yàn)榍捌诘陌l(fā)展規(guī)劃不足，可能每個(gè)部門都有自己的運(yùn)維或者監(jiān)控平臺(tái)，平臺(tái)繁多就容易形成數(shù)據(jù)孤島，這樣就造成了研發(fā)人員在使用的時(shí)候非常不便。

拓?fù)?/h3>

以前大家可能面對(duì)的是一個(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í)候就非常被動(dòng)，這也是我們面臨的一個(gè)問題。

APM

APM 是近幾年才興起。據(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)的升級(jí)之外還需要運(yùn)維團(tuán)隊(duì)由背鍋、救火式的被動(dòng)運(yùn)維向主動(dòng)發(fā)現(xiàn)、處理、規(guī)避問題的主動(dòng)運(yùn)維轉(zhuǎn)變來驅(qū)動(dòng)。

以上說到的諸多挑戰(zhàn)和新技術(shù)的發(fā)展倒逼運(yùn)維人員主動(dòng)尋求變化，不能像以前一樣，一提到運(yùn)維就是背鍋俠或者救火隊(duì)員。要改變這種被動(dòng)運(yùn)維的方式，首先就要轉(zhuǎn)變思想：運(yùn)維也可以主動(dòng)?？梢詮哪男┓矫嬷鲃?dòng)呢？

• 產(chǎn)品意識(shí)?，F(xiàn)在很多公司都在提倡技術(shù)輸出、產(chǎn)品輸出。京東目前的定位也是技術(shù)驅(qū)動(dòng)，不止在電商類、物流類的上有輸出，運(yùn)維也需要對(duì)外輸出，做一些產(chǎn)品化，可復(fù)用的組件。

• 可以做一些技術(shù)運(yùn)營的工作。比如把一些組件或者平臺(tái)在整個(gè)公司內(nèi)部推廣，甚至對(duì)外推廣。如果有比較好的項(xiàng)目還可以考慮開源，借助社區(qū)的力量進(jìn)一步發(fā)展。

• 架構(gòu)運(yùn)維。包含代碼、項(xiàng)目標(biāo)準(zhǔn)化，優(yōu)化開發(fā)流程，推進(jìn)項(xiàng)目標(biāo)準(zhǔn)實(shí)施。目前很多大型公司都在進(jìn)行中臺(tái)化轉(zhuǎn)型，架構(gòu)運(yùn)維是中臺(tái)戰(zhàn)略能否落地的關(guān)鍵。

• 還可以做一些業(yè)務(wù)增值類的工作。比如對(duì)一些運(yùn)維事件做智能處理，自動(dòng)擴(kuò)容縮容，這樣可以避免很多未來的一些問題。

智能運(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)控平臺(tái)，平臺(tái)繁多就容易形成數(shù)據(jù)孤島，導(dǎo)致數(shù)據(jù)串不起來，無法做全面的數(shù)據(jù)分析工作。

上面這張圖是京東物流的運(yùn)維體系規(guī)劃。最下層是資源層，包括物理資源、虛擬資源、應(yīng)用、中間件以及數(shù)據(jù)庫。上層是平臺(tái)層。在平臺(tái)層，我們建立了維護(hù)基礎(chǔ)數(shù)據(jù)的 CMDB 系統(tǒng)，在 ITSM 管理方面，集成了事件管理、問題管理、值班管理等運(yùn)維流程化管理模塊。在 CMDB 系統(tǒng)基礎(chǔ)上我們建設(shè)了大規(guī)模資源監(jiān)控平臺(tái)、網(wǎng)絡(luò)監(jiān)控平臺(tái)以及多個(gè)運(yùn)維平臺(tái)。京東物流在全國 550 個(gè)大型倉庫中還運(yùn)營著幾百個(gè)庫房的集群，針對(duì)庫房運(yùn)維管理我們建設(shè)了庫房運(yùn)維和數(shù)據(jù)庫運(yùn)維平臺(tái)。通過 DevOps 平臺(tái)將 CMDB、監(jiān)控、運(yùn)維等多個(gè)平臺(tái)數(shù)據(jù)關(guān)聯(lián)起來，形成閉環(huán)，從而建立基礎(chǔ)的運(yùn)維體系。

再往上，是數(shù)據(jù)化層。在這一層，我們期望通過對(duì)監(jiān)控和運(yùn)維平臺(tái)產(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)行告警知識(shí)庫自學(xué)習(xí)和故障自動(dòng)處理等。只有前兩個(gè)方面做好了，才能保證提前預(yù)估故障并進(jìn)行預(yù)修復(fù)從而達(dá)到規(guī)避問題的效果，這是最理想的狀態(tài)。

標(biāo)準(zhǔn)化是前提。也就是說我們所有的監(jiān)控平臺(tái)也好，運(yùn)維平臺(tái)也好，都要遵循統(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)平臺(tái)化、監(jiān)控服務(wù)化、組件模塊化、腳本插件化。

產(chǎn)品化思維。由研發(fā)思維向產(chǎn)品化思維轉(zhuǎn)變。前面已經(jīng)提到過，運(yùn)維平臺(tái)的用戶不止是運(yùn)維人員，還有大量的研發(fā)人員。因此我們要從研發(fā)的角度考慮運(yùn)維產(chǎn)品設(shè)計(jì)，充分考慮研發(fā)需求的同時(shí)注重服務(wù)的流程化，也可以理解為需求驅(qū)動(dòng)。

還有一個(gè)概念，是運(yùn)維中臺(tái)?，F(xiàn)在京東也在做一些中臺(tái)相關(guān)的工作，同樣我們運(yùn)維領(lǐng)域也需要中臺(tái)，比如我們可以把監(jiān)控?cái)?shù)據(jù)集中處理、清洗、告警、通知、分析等主要數(shù)據(jù)處理作為中臺(tái)，把統(tǒng)計(jì)數(shù)據(jù)、大數(shù)據(jù)分析的結(jié)論數(shù)據(jù)等封裝為數(shù)據(jù)組件，這樣其他的一些相關(guān)應(yīng)用可以作為前臺(tái)，接入到運(yùn)維中臺(tái)，這個(gè)方面我們也已經(jīng)做了一些嘗試了，取得了不錯(cuò)的效果。

還有就是注重業(yè)務(wù)增值。我們往往針對(duì)運(yùn)維平臺(tái)的設(shè)計(jì)只注重提高研發(fā)效率，而較少考慮業(yè)務(wù)增值。我們?cè)趪L試的業(yè)務(wù)增值的例子：統(tǒng)計(jì)服務(wù)器、網(wǎng)絡(luò)設(shè)備、物理設(shè)備的廠商、型號(hào)以及故障率，提供故障率較高的型號(hào)報(bào)表，這樣采購的時(shí)候也更有針對(duì)性。再比如提供各應(yīng)用、部門的資源使用率報(bào)表以及低資源使用率榜單，以此督促資源使用率較低的應(yīng)用或部門進(jìn)行縮容整改。

過程改進(jìn)。運(yùn)維體系的建設(shè)不是一蹴而就的，需要結(jié)合過程改進(jìn)的工具和方法不斷迭代優(yōu)化。

閉環(huán)。在整個(gè)智能運(yùn)維體系中包含諸多資源管理平臺(tái)、監(jiān)控平臺(tái)、運(yùn)維平臺(tái)等，平臺(tái)之間在數(shù)據(jù)和流程上是分散的，在 DevOps 平臺(tái)中將這些平臺(tái)串連起來以達(dá)到閉環(huán)的效果。DevOps 平臺(tái)貫穿運(yùn)維管理的全流程，可以說是整個(gè)智能運(yùn)維體系實(shí)現(xiàn)閉環(huán)的關(guān)鍵。比如我們?cè)诎l(fā)布應(yīng)用的時(shí)候，從應(yīng)用的申請(qǐng)、資源的申請(qǐng)，到代碼編譯、測試，甚至到監(jiān)控，變更，一直到這個(gè)機(jī)器下線、應(yīng)用下線，我們都整合到 DevOps 平臺(tái)，這樣就做到了閉環(huán)。在做智能運(yùn)維體系建設(shè)的時(shí)候，如果達(dá)不到閉環(huán)的狀態(tài)，那么整個(gè)運(yùn)維流程就不完善，無法實(shí)現(xiàn)對(duì)運(yùn)維事件的實(shí)時(shí)跟蹤。這樣的閉環(huán)也促進(jìn)了資源的生命周期管理、流程管理以及審計(jì)管理等生態(tài)建設(shè)。

大規(guī)模實(shí)時(shí)監(jiān)控平臺(tái)的實(shí)踐方案

京東物流大規(guī)模實(shí)時(shí)監(jiān)控平臺(tái)從 2018 年初開始構(gòu)建。我們經(jīng)歷了三個(gè)大的階段：

第一階段

針對(duì)京東物流特殊的 IT 環(huán)境，我們實(shí)現(xiàn)了從 0 到 1 重新建立一套完整的大規(guī)模實(shí)時(shí)監(jiān)控平臺(tái)。

監(jiān)控平臺(tái)不同于普通業(yè)務(wù)平臺(tái)，普通業(yè)務(wù)平臺(tái)并發(fā)量峰值大多與時(shí)間相關(guān)，或者隨時(shí)間波動(dòng)。監(jiān)控平臺(tái)最大的特點(diǎn)是 24*7 全時(shí)段監(jiān)控，平臺(tái)的壓力負(fù)載情況一直處于較高的狀態(tài)。所以監(jiān)控平臺(tái)一定要做到低延時(shí)、高并發(fā)、高可用。以下是我們架構(gòu)設(shè)計(jì)考慮的關(guān)鍵點(diǎn)：

• 實(shí)時(shí)大數(shù)據(jù)處理、高并發(fā)

• 微服務(wù)化、分布式、高可用、負(fù)載均衡

• 產(chǎn)品化、標(biāo)準(zhǔn)化、組件化、插件化

• 可擴(kuò)展、可配置

• 對(duì)外接口設(shè)計(jì)、數(shù)據(jù)訪問安全

那我們是如何從架構(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)。

首先我們采用被動(dòng)監(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 可能就會(huì)是一個(gè)瓶頸，而且意味著我們要需要更多的硬件資源?？紤]到這一點(diǎn)，我們?cè)黾恿?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)控平臺(tái)建立起來之后，我們發(fā)現(xiàn)某些應(yīng)用或是機(jī)器的使用率很低，資源沒有得到充分利用，還有很大的優(yōu)化空間。于是我們提供了一些低使用率榜單，定時(shí)發(fā)送督促各個(gè)業(yè)務(wù)條線縮容，這也是業(yè)務(wù)增值的一個(gè)體現(xiàn)。

第二階段

實(shí)時(shí)監(jiān)控平臺(tái) 2.0 的時(shí)候，針對(duì)京東目前多個(gè)監(jiān)控系統(tǒng)并存、監(jiān)控?cái)?shù)據(jù)沒有互通的問題，我們把所有的監(jiān)控平臺(tái)的監(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)警和分析。一方面有助于對(duì)應(yīng)用進(jìn)行更加全方位的數(shù)據(jù)分析與監(jiān)控狀態(tài)評(píng)估，另一方面也有助于后期建立根因分析的時(shí)候結(jié)合分布式跟蹤系統(tǒng)去構(gòu)建業(yè)務(wù)拓?fù)洹?/p>

在 2.0 版本，我們會(huì)把所有監(jiān)控平臺(tái)的指標(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，最后存儲(chǔ)和索引。

第三階段

有了前面兩個(gè)大版本的支撐，我們監(jiān)控平臺(tái)的 3.0 版本開始向 AIOps 發(fā)力。下圖是產(chǎn)品的大體規(guī)劃。左側(cè)是一些普通的接入服務(wù)，監(jiān)控平臺(tái)首先進(jìn)行數(shù)據(jù)采集、清洗的工作。在數(shù)據(jù)處理層上新增了可視化、事件處理、知識(shí)庫、動(dòng)態(tài)檢測、動(dòng)態(tài)預(yù)知等模塊。這些功能點(diǎn)屬于 AIOps 領(lǐng)域的初級(jí)功能都已經(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ù)測效果還是很不錯(cuò)的，參考下圖。

在 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í)滾動(dòng)的告警信息。

智能故障定位與處理實(shí)踐

在故障處理方面我們比較好的一個(gè)實(shí)踐是快照機(jī)制。當(dāng)監(jiān)測到異常時(shí)系統(tǒng)會(huì)在觸發(fā)報(bào)警的時(shí)刻立即觸發(fā)快照，在系統(tǒng)上抓一些現(xiàn)場信息，現(xiàn)場快照信息包含：占用 CPU 較高的線程排名、JVM 內(nèi)存堆棧信息、網(wǎng)絡(luò)信息以及磁盤 io 信息等。在發(fā)出告警通知的同時(shí)提供該快照信息的訪問鏈接?？煺枕撁嫱瑫r(shí)也會(huì)列出該告警前后半小時(shí)內(nèi)各種指標(biāo)的趨勢情況，供研發(fā)去定位問題。要注意的一點(diǎn)是我們?cè)诖鎯?chǔ)快照信息時(shí)沒有把快照存到統(tǒng)一的服務(wù)端，而是直接存在機(jī)器里面。其原因是 JVM 內(nèi)存堆棧通常較大，若將快照信息發(fā)送至遠(yuǎn)端統(tǒng)一存儲(chǔ)那么勢必增加網(wǎng)絡(luò)壓力，可能會(huì)影響到業(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)行自動(dòng)探測應(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í)庫數(shù)據(jù)，并存儲(chǔ)到知識(shí)庫系統(tǒng)。這個(gè)不斷完善的知識(shí)庫系統(tǒng)可以作為研發(fā)定位問題的依據(jù)，也可以作為故障自動(dòng)處理的依據(jù)，還可以作為運(yùn)維機(jī)器人的知識(shí)來源。同時(shí)，知識(shí)庫也支持人工添加一些常見的故障以及故障原因并給予較高的分析權(quán)重?；诓粩嘈拚臉I(yè)務(wù)拓?fù)潢P(guān)系，系統(tǒng)就可以自動(dò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ù)需求并充分對(duì)比分析后我們選擇基于 pinpoint 進(jìn)行二次開發(fā)實(shí)現(xiàn) APM。它的缺點(diǎn)在于性能方面比 Zipkin、SkyWalking 要差一點(diǎn)，但是 pinpoint 也有項(xiàng)目不具備的優(yōu)勢，比如接入簡單無需修改代碼，再比如可以跟蹤到代碼級(jí)別等等。目前有很多國內(nèi)外的廠商都在做 APM 的產(chǎn)品，如果企業(yè)計(jì)劃做 AIOps 的話我們不推薦直接使用廠商的產(chǎn)品，因?yàn)閺S商的 APM 底層數(shù)據(jù)對(duì)客戶是不透明的。而自主研發(fā) APM 平臺(tái)最大的意義在于 APM 里面有大量的數(shù)據(jù)是我們可以使用的，通過對(duì)這些基礎(chǔ)數(shù)據(jù)進(jìn)行大數(shù)據(jù)分析以及數(shù)據(jù)挖掘之后，可以為 AIOps 提供很多數(shù)據(jù)來源。如果使用廠商的產(chǎn)品，在很多方面底層數(shù)據(jù)的使用就不是那么自由了。

下面介紹一下我們?cè)?APM 方面的進(jìn)展，我們基于 pinpoint 開發(fā)的 Jtrace 分布式跟蹤系統(tǒng)擁有 7 大能力：

• 分布式事務(wù)跟蹤

• 自動(dòng)檢測應(yīng)用拓?fù)?/p>

• 水平擴(kuò)展支持大規(guī)模服務(wù)集群

• 代碼級(jí)別的可見性，這是相對(duì)于其他產(chǎn)品最大的不同，它可以跟蹤方法堆棧，特別清晰。

• 使用字節(jié)碼增強(qiáng)

• 集成了 SQLAdvisor，在抓到 SQL 之后，我們會(huì)分析到哪些是比較慢的 SQL，慢的 SQL 到底慢在哪里，我們可以通過這個(gè)給出一些優(yōu)化建議

• 智能化采樣率，基于業(yè)務(wù)訪問量自動(dòng)調(diào)整采樣率，大大降低了業(yè)務(wù)性能方面的開銷

關(guān)于性能方面，我們從以下幾個(gè)方面進(jìn)行了優(yōu)化：

• 使用二進(jìn)制格式（thrift 協(xié)議），高壓縮比，在網(wǎng)絡(luò)傳輸上可以減輕很多開銷。

• 使用變長編碼和格式優(yōu)化數(shù)據(jù)記錄（thrift CompactProtocol）

• 用常量表替換重復(fù)的 API 信息，SQL 語句和字符串

• 智能采樣率

• 使用異步數(shù)據(jù)傳輸來最小化應(yīng)用線程中止

• 使用 UDP 協(xié)議傳輸數(shù)據(jù)

優(yōu)化后性能損失與目前流行的 Zipkin 相近。相對(duì)于我們獲取的數(shù)據(jù)精度來說，這個(gè)是可以接受的結(jié)果。

AIOps 的落地規(guī)劃

下面我們談?wù)劷裉斓淖詈笠粋€(gè)主題：AIOps 的落地規(guī)劃。

前面已經(jīng)有提及，AIOps 主要從發(fā)現(xiàn)問題、解決問題、規(guī)避問題三個(gè)方面來設(shè)計(jì)和實(shí)施。對(duì)于發(fā)現(xiàn)問題，很多在做 AIOps 的廠商都已經(jīng)做的很完善了，包括異常檢測，根因分析、智能告警、性能分析、事件分析、日志分析等。對(duì)于解決問題這一塊，整個(gè)業(yè)界還處在一個(gè)探索的階段，我們的思路是以自學(xué)習(xí)結(jié)合人工標(biāo)注的知識(shí)庫為基礎(chǔ)整合異常反饋、深度學(xué)習(xí)、決策樹等 AI 技術(shù)，實(shí)現(xiàn)故障自動(dòng)處理。針對(duì)非危險(xiǎn)處理動(dòng)作實(shí)施自動(dòng)處理并記錄日志，對(duì)于高危操作則通過流程審批確認(rèn)后執(zhí)行。針對(duì)規(guī)避問題這一目標(biāo)，則是我們對(duì)于 AIOps 的愿景。我們希望通過對(duì)大數(shù)據(jù)的分析和預(yù)測能夠?qū)θ萘?、性能、故障進(jìn)行精準(zhǔn)預(yù)測，并提前做好自動(dòng)應(yīng)對(duì)措施以避免問題的產(chǎn)生。如果實(shí)現(xiàn)了這個(gè)目標(biāo)，那么 AIOps 算是真正落地了。

最后和大家分享一下，AIOps 落地的規(guī)劃階段圖。我們也參考了清華大學(xué)裴丹教授的一些想法，將 AIOps 的落地分為幾個(gè)層次：

• 機(jī)器學(xué)習(xí)算法層，這些是純學(xué)術(shù)界的知識(shí)，需要學(xué)術(shù)界的創(chuàng)新和積累

• 算法層，作為學(xué)術(shù)界和工程界的結(jié)合層，我們會(huì)抽象出來很多運(yùn)維界相關(guān)算法庫作為原始算法層。

• 以算法層為基礎(chǔ)構(gòu)建一些可復(fù)用的組件，如決策樹，故障樹等等。

• 有了組件之后，就可以基于組件做。

綜上，AIops 的落地需要學(xué)術(shù)界和工程界的通力合作，任重而道遠(yuǎn)。但好在目前業(yè)界對(duì)于 AIOps 的探索和實(shí)踐熱情較高，也有很多階段性的實(shí)踐成果。只要有清晰的建設(shè)思路和規(guī)劃，相信不久的將來 AIOps 很快會(huì)在各大企業(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)維平臺(tái)研發(fā) 工作 8 年，研究過市場上數(shù)十家廠商的監(jiān)控運(yùn)維平臺(tái)產(chǎn)品， 對(duì) DevOps 和監(jiān)控平臺(tái)有比較深入的研究。目前負(fù)責(zé)京東物流火眼監(jiān)控平臺(tái)的架構(gòu)設(shè)計(jì)和開發(fā)工作。