主持人：接下來由北京睿至大資料有限公司的左龍賀老師來分享睿至進取，我們眼中的AIOps。
左龍賀：大家好，我是北京睿至大資料有限公司的産品經理左龍賀，今天跟大家分享AIOps話題。剛才兩位老師分别從日常的項目客戶回報，包括效益，還有自主的産品優勢給大家分享了AIOps的一些看法。
今天我們睿至大資料這邊主要是想從 AIOps 的一些解決方案落地情況，還有我們在客戶這邊落地的時候遇到的一些問題和一些難點想跟大家坐在一起分享這樣的内容。
首先第一個片子，大概看一下整個AIOps發展的曆程，首先最早的時候是2013年提出的ITOA概念，通過技術服務手段采集存儲海量的資料，最後成品展現。
2016年提出了 AIOps 的理念，首次在它的理念裡加入了智能化的算法内容，這裡面我特地把AI和Ops分開，當時的提法隻是一個概念型的定義，并沒有把算法和一些運維場景進行深度的整合。
僅過了一年，2017年時候又針對AIOps提出了新的提升，也就是後來我們大家所熟知的智能運維概念。
從目前的情況來看，AIOps整個的市場和發展趨勢是非常看好的，是以各大廠商都在做積極的投入，也包括我們睿至大資料有限公司。在這種大環境下，首先看一下使用者所面臨的問題，随着雲計算的發展，還有一些微服務的應用，客戶這邊面臨的問題可能就越來越多，主要展現在以下三個點：
首先客戶這邊規模非常龐大，有兩個層面，一個層面相當于裝置量大，包含各種廠商，各種型号的裝置。另外由于裝置廠商數量比較多，資料量也會越來越龐大，包括格式化的，還有非格式化的資料，包括日志。
另外層面是技術非常複雜，運維客戶這邊引入了這樣的過程架構，包括虛拟化和容器的技術，是以整體來說，架構會變得異常複雜，當發生問題的時候，客戶很難快速地定位到實際的原因，也是後面衍生的問題，它的問題很難定位。
客戶很難在大量的資料裡找到他所需要關心的核心價值點。
是以，對于客戶來說，他們是想急需借助AIOps平台具有的資料分析能力和産品的功能來幫助他們解決日常手段或者現有方法不能解決的問題。
是以說，客戶對于AIOps的想法還是非常積極的，然後不同的使用者對于AIOps的一些了解可能也不太一樣。之前我這邊也跟很多的客戶做了一些溝通，我把客戶的一些想法總結了一下，基本上我跟客戶聊的時候，客戶基本上第一次去聊都會問你們平台裡大概用到哪些算法，這些算法的準确度有多高，從另外層面來說，他們認為應該每個頁面，每個功能都會有算法在裡面。
從我們睿至的角度來說，除了算法模型之外，我們這邊其實應該在目前的階段來說，畢竟有些算法還有模型不是太成熟，是以在算法的基礎上，我覺得更多的是把我們從客戶這邊彙聚在一起多角度、多元度的資料跟客戶的實際運維場景結合，然後根據使用者平時在處理問題的實際場景去盡可能給客戶提供更多的資料支援，當客戶在解決問題的時候，能更快地發現問題原因。
針對算法這塊，其實我們也是在有一些投入，但是我們還是有選擇性的會逐漸加進來。比如說我們在前期可能會加入一些算法程度比較成熟的，比如像單名額和多名額的預測，還有關聯分析，我們後面像這種故障的根源定位，還有一個關聯度的影響分析，我們逐漸是放在後面做。因為我們覺得有些算法在目前的階段來說，可能還不是那麼準确。
我們睿至對于 AIOps 的了解，或者對于它的定義大概是這樣，AIOps是通過深度整合IT資料資源，結合運維的應用場景，這個很重要。我們不論是用算法也好，還是通過整合IT資源也好，最終手段一定要根據實際的應用場景和解決問題的場景深度內建，然後才是運用我們大資料還有機器學習的技術和手段。
然後在以上的層面以多元度的分析視圖或者場景化、流程化的處理，最終給客戶提供功能或頁面，幫助使用者快速地分析問題。
這個點是我們對于AIOps的總結，它是智能化輔助的分析平台。智能化是因為引入了大資料機器學習的一些算法，輔助是因為我們覺得目前階段，算法可能并不是完全準确，它隻能是更多的提供潛在的原因，它可能會幫助使用者在衆多的原因裡和衆多的資源裡幫使用者盡可能篩選顆粒度更細節的問題，幫助使用者分析它潛在的問題。
這個是我們睿至對于AIOps的了解，可能大家對于它的了解都不太一樣，這個我們可以後面做一些更進一步的交流。
基于這樣的了解，我們整理和設計了整個AIOps的解決方案，大緻是這樣的場景。
首先，從整個方案來說，第一個階段我們認為最重要的，或者說最開始的應該是對于客戶這邊所有資料的治理工作。因為這邊我覺得這個工作對于整個AIOps方案落地來說，是比較關鍵的點。
大家在實際去做AIOps落地的時候，在前期我們針對于這種客戶資料的治理化的工作我覺得會占到整個方案落地時長或者工作量大概有40%到50%的比例。
因為往往客戶的資料首先會比較複雜，場景又會比較多變，客戶的需求也不一樣。之前有些客戶的一些内部用的元件是标準化的，需求也比較簡單，我們就可以選擇比較标準化的開元的元件。有些客戶對于要求比較高，有些金融客戶可能有些重要資料，是要求你這些資料在抽取到平台後期處理的過程中，是不允許你有丢失的情況出現。
是以，它就會針對你抽取的工具提出更高的要求，比如會要求你在抽取之前、之後你要有一個資料校驗過程，你要保證你資料的完整性，你要保證你的資料裡面沒有比較多的髒資料。
這些要求對于傳統的資料開源工具是滿足不了需求的，我們一般就會選取公司自研的處理工具去滿足客戶的需求。
同時當我們把客戶的整體資料抽取範圍定下來之後，當我們去做資料的一些格式，或者是一些方式的确認時候，往往這裡面的問題也會比較多，這個後面我們會有單獨的章節去針對這一塊可能具體去說一下它的問題。
當我們對客戶這邊的資料整體做了處理之後，我們會把客戶這邊對應的不同類别資料抽取到資料平台上，都會打上不同的标簽，後面我們會有不同的消費子產品，會從上面取相應的資料，比如對資料進行後續的入庫，可能有些資料我們可能會入到運維的知識圖譜，這裡面包含拓撲資料、關系資料，還有運維經驗資料會應用到運維的知識圖譜裡，還有入到實時分析庫裡，這裡面會根據使用者的不同需求去入。
包括日志或者一些資料還有服務的要求，是以從服務總線入到段期彙總庫還有一個流程，把單獨的資料入到長周期的彙總庫裡，這都是需要客戶不同的場景設計後邊具體的流程。
當所有的資料都标準化入到庫之後，我們後面就結合平台裡的一些算法子產品，包括分析的引擎就會從不同的庫表取相應的資料做後面的資料分析還有跑模型或者驗證的工作。
當結果出來之後，我們是通過智能運維的門戶，把相關的資料做整體的整合，最終展現給使用者去使用。
目前我們這邊計劃或者已經實作的一些場景，主要就是列在這邊，基本上跟之前兩位老師講的場景有一些重複。比如像基于全量資料的全景視圖、單名額異常預測，多名額的異常分析，還有全量資料的追蹤視圖，後面會給大家示範一下我們這邊對于AIOps幾個核心的場景。
這是我們整個方案的架構，總體來說跟剛才的圖差不多，當我們把AIOps方案落地之前，其實我們要明确一下目前來說哪些客戶是适合上AIOps的産品，它有哪些特征。
首先，它要有一些比較健全的監控運維流程自動化體系，這是一個前提，隻有了這個前提，後續才會有源源不斷的、比較豐富的、全量化的資料分析和展現。
同時還要有一定量級的曆史資料，而且這個資料一定要是連續的資料，友善我們後續針對模型實作結果。
運維水準和底層資料的标準化相對比較高，有些客戶可能這幾年連自己也不太清楚他的一些監控的名額到底存在哪些監控系統裡，他自己也不太清楚到底存在哪，包括整個業務的拓撲情況，他可能也不是很了解。
因為有些客戶他想做分析和後續的内容診斷是不太清楚它的架構，是以這時候我們想去做後續的整體分析，或者問題定位，這後面會比較難。
另外一塊AIOps建設大概分幾類人，一類是運維專家，當我們落地的時候，運維專家是客戶的主要負責人，他比較清楚運維當中的問題和難點，他可以結合難點給我們提出針對這些場景，或者問題分析的場景需求。
另外一塊，我們有算法的工程師，這樣可以結合運維專家或者客戶提出的這樣一些場景的需求，他會選擇合理的算法去适配，後面根據具體的資料進行資料和算法模型的調優。
下面還有另外一種就是大資料工程師，它的決策主要是結合場景以及資料模型的算法要求提供穩定的資料來源。
除此之外，我個人覺得可能還需要一類決策去協調它們之間的工作，比如說類似于産品經理的概念，可以從産品經理的度說，把運維專家所提出的問題整體做梳理，然後轉換成一些算法工程師還有大規模工程師容易了解的語義和場景，這樣會更好地将運維場景做一個落地。
有了這種合适的使用者環境，包括我們有了比較完整的團隊，後續可能我們就要去做這種相關成本的落地。
我們AIOps整個方案落地的時候，我們會給客戶建議分步驟實作，一般會分四個步驟，第一個階段首先我們建議客戶做它底層資料的治理和标準化，實際上隻有你把底層資料标準化之後，上層才能更好地做資料的分析。
第二個階段，在我們把資料标準化、結構化之後，可以提供這樣的一些場景，或者多元度的視圖，可以先幫助客戶從實際運維的角度去提供這種多元的資料幫助他們解決一些問題。
在第三個階段，我們是建議客戶選擇一些比較成熟的算法，然後運作在我們平台，比如像單名額的預測，多名額的關聯，這些的算法可以逐漸加入到我們的平台裡。
最後的階段就是把我們相關的算法和機器學習的模型，或者結果，然後以統一的場景結合起來給客戶提供這樣的一些服務。
首先我們這邊結合在客戶這邊實際部署或者落地的時候遇到的一些問題或者難點跟大家分享，首先在第一階段會涉及到資料的治理和标準化，這邊實際上會有幾個層面我們需要關注，首先就是整個資料的範圍規劃，另外一塊相當于資料抽取方案和這種架構的選型，第三方面是資料标準化到底怎麼定義，第四方面是針對于資料品質的要求，第五方面針對于資料安全的考量是什麼樣。
像這些問題，基本上都是我們在客戶這邊落地的時候，客戶比較關注的一些點。
首先我們看一下資料範圍規劃，首先在資料規劃的時候，我們會建議客戶分階段逐漸選取它比較有代表性的資料納入到平台裡，這樣在短時間内很難看到效果，我們建議最好從已有的業務系統裡選擇一到兩個比較核心，或者是覆寫資料比較全的對象，把它納入到平台裡，然後從這個視角把所有相關的資料，包括資料的準化做全做好。
首先這裡面我們需要确認比如規劃資料範圍内資料的存量方式，包括模式，還有資料的具體格式，資料到底是存在資料庫裡面是以資料庫的方式存在，還是以檔案的方式存在，基于這種調研的結果，我們還要再确定，因為你有些金融庫有增量抽取，有些工具對于庫表字段是有特殊要求的，你要有一些特定的字段，是要适合于做增量抽取的，如果沒有的話，可能在這個過程當中，你需要做一些調整，或者對庫表進行優化。
另外一塊，針對于我們要抽取的庫表要了解目前庫表的使用頻率，包括目前使用的使用者，從性能角度出發，我們去判斷一下庫表是直接從庫表抽取還是額外建立試圖，避免對它原有的庫表産生一些不必要的影響。好多客戶不同的資料源在不同的資料裡會有不同的時區概念，如果是時區的概念沒有樹立清楚的話，這些資料抽取過來之後，當你在前台做展現或者統一分析的時候，資料首先是不全，而且由于這種時區不同，資料有所差異性，這點需要重點看一下。
另外一點需要針對的範圍是要對應的抽取模式，比如對于庫表類比較高的，這種庫表和資料有接口分發的，我們一般建議使用者把資料先拖到特定的位置，然後再通過相應的位置上抽取，這樣就是可以保證資料的及時性，減少對于原始庫表的影響。
對于實時性要求不高的，可以通過接口分發的處理方式，我們允許周期的合理設定，因為有可能你的周期設得太長，資料上來比較慢，設的過短，對于表的影響也比較大。
剛才說到針對客戶這邊，像銀行客戶有非常重要的資料，客戶會有一些要求，這些資料在抽取的過程當中，是不允許丢失的。首先針對于子產品要求要保證高管理模式，當某個子產品發生故障的時候，你是一種叢集模式，它是持續運作的狀态，要保證資料進庫的狀态。我入庫之前和入庫之後要有完整性的校驗過程，有哪些資料丢失的，後續客戶會根據這些資料進行額外的處理方式。
另外一塊比較重要的就是針對資料标準化這塊，首先資料标準化，我們首先要定義平台的準資料模型，這個資料模型裡面就包含了我們的性能、告警、日志、變更等一些資料的标準。在這裡面尤其重要的一點就是我們配置的唯一性标準，我們一般來說會以這種資源的視角把相關的資料整體作為這種整體的彙總和檢視。
如果配置的唯一性辨別做得不夠好或者不夠多的話，其他的報警、日志、變更就很難跟資源做關聯。
一般來說，我們在去定義配置的時候，會有這樣的一些标準放到裡面，比如說像主機和配置，我們就可能是以IP作為辨別。像一些資料庫，包括中間件就是以IP+端口作為辨別。可能像這種存儲，我們會去做這種标号辨別。我們需要把性能、告警、配置、日志變更等類型的資料标準，尤其是配置的唯一性标準，其他資料都要與之關聯，才能整體做一些分析和展現。
中間環節的資料标準指的是比如我們從客戶這邊的庫表上把資料抽取出來後放到資料總線上，從資料總線上入到ES庫裡面也規定相應的标準，我們也遇到了不少的問題，這個索引一旦定的太複雜的話，你不太利于後面日常的維護和關系。如果你定的太簡單，可能存儲的資料量會比較大，這樣在前端做展現關聯或者分析的時候，從裡面取資料對于性能有很大的影響。
如果說後續我們是選用HDFS作為曆史庫，同時我們要去規劃在HDFS上的目錄和檔案的存儲結構，這跟我們ES上索引的要盡量一緻，後面你在資料做查詢，或者分析的時候，可能會比較規範或者好處理一點。
然後從資料的品質這邊，我們可能要注意幾點，第一個要提供資料的完整性的校驗能力，這個一般客戶比較關注，同時要驗證同步的資料是否有重複記錄的情況。
如果一旦你同步資料有重複的情況，包括後面我們做單名額的預測，還有做分析的時候，它在預測的結果，或者展現的時候，都會有一些問題或者很大的差異性。
而且你在最後排查的時候也不太好排查，盡量在做資料抽取的過程當中就要驗證一下哪些資料有重複，有重複的話，一解體了，二通過一些方案來解決。
另外的問題就是最後要驗證同步資料與我們預期的格式和内容是否有差異。
另外從資料安全性角度來說有兩點，第一個對于客戶這邊比較敏感的資料進行透明處理。同時，要考慮到不同使用者有種針對于不同資料權限的檢視能力。
後續我們在界面上做查詢或者分析的時候，是基于底層資料的安全性考慮的設定，它會有不同的劃分，這樣才能在界面上保證不同使用者查詢範圍是不一樣的。
第二個階段的建設點裡所關注的主要點就是因為我們底層已經有了這樣一些标準化的資料，在這個界面我們可以提供一些全景的視圖，我可以給使用者在同一範圍内檢視到多元度的資料，在這一點上，我可以提供給客戶同一個時間點内不同的變更日志告警或者其他資料的一些内容，幫助他去分析問題。
另外一點相當以在界面上要求會提供拖拽的方式，使用者可以随時定義診斷視圖，他可以快速地把核心裝置、核心名額的内容放在一個圖示裡進行定義。
另外是對于圖表的能力，比如之前在日志聚類的時候可以看到分期聚類所分析組成的具體日志明細有哪一些，基于日志的明細我可以基于日志的上下文檢視相關前後發生的事件，然後逐漸排查我這個事件具體的一些問題到底在哪。
另外一個點就是可以提供同一時間段内多元度的分析能力，還有基于時間點的上下文的檢視能力。
這就是剛才說的基于時間點可以檢視日志上下文其有其他名額資料、告警資料的能力。
第三個階段剛才也說過了，在這裡面我們的算法和模型要設計成可插拔式的，友善後續新算法的快速接入。這種算法要提供可檢視的結果以及模型參數的調優能力。
然後最終我們加入到平台裡的算法模型，尤其要和我們相關的産品和功能進行整合，不要看上去它就是單獨的算法平台，作為單一的存在，要和場景和處理過程進行一個深度的融合，幫助客戶可以很友善地使用分析出來的結果。
另外一點我們需要考慮的就是算法和模型在應用到具體場景裡的時候，可能會有不同的版本，這個模型同時會有多個不同的版本在應用，這個點可能要考慮進去，否則可能後面在算法和應用這塊會有一些不少的問題，這些基本上是我們在客戶這邊實際落地的時候遇到的一些突出的問題。
最後一個階段就是将我們的多種算法與我們的運維場景進行閉環的設計整合，不要把相關的做法作為割裂的使用。
下面從運維場景和使用者處理問題的角度出發，通過多元度的場景和算法結果結合在一起給使用者提供完整的全量使用者分析。
基于這些我們在客戶落地的一些問題，包括客戶的需求，我們這邊也設定了一些客戶的運維場景，這邊給大家大概看一下。
第一個場景就是基于業務拓撲的跟蹤視圖，這個場景我們之前主要适用于銀行客戶的場景，這邊首先我們是把客戶的業務拓撲的資料，包括它的性能資料，包括告警資料，還有跟我們場景裡面相關的日志資料可能比較彙總到我們平台來，通過我們底層的分析和處理能力，首先我們會把最近一個時間段内客戶這邊一些交易的情況做一個統計。
比如說到底交易裡面失敗有多少，成功的有多少，點到某一個失敗資料之後可能會列出來失敗交易的具體明細，點到具體的交易之後，就會自動地整合業務拓撲裡面資源的資料做比對，這裡面就會告訴我這兩個資源是跟這個交易流水号相關的，這時候使用者就可以通過點選相關的統一數字就可以檢視具體的交易日志的具體明細。
基于這些重點的交易明細，我們選擇一個點選上下文的分析選項，他就可以去檢視基于這條日志之前上下文的情況，可以幫助使用者去分析問題失敗或者是其他情況在這個之後到底出現了哪些需要使用者關注的資訊，幫助使用者去分析一些潛在的問題。
這是我們這邊第一個場景，一般是針對我們這邊的精準客戶。
第二個場景相對于基于機器學習的多名額關聯分析，這個在我們平台裡在某一天比如說某一個相關的性能名額可能産生的告警，我們會這樣的視圖，這個視圖裡首先跟你告警相關的名額一個基本的情況，包括最近的一些異常點有哪些，然後在下面，我們會列出來跟你目前告警名額相關聯的其他一些相關的名額，大概有哪些。
下面多名額的清單是通過我們多名額的關聯分析的算法得出來的，使用者也可以通過點選不名額的選項可以檢視相關名額的一些差異性，或者關聯性。
在同一個圖表上可以看到不同名額趨勢的情況，包括在某些點上的異常是否是有一些一緻的程序，通過相關曲線最早發生的異常點還有問題的一些情況，我們可以大緻判斷一下引起名額的一些主要的問題到底是有哪個名額的問題引起的。
同時，除了這個相關名額之外，我們可以在這個時間範圍内，我們右邊有一個時間點的概念，可以基于這個時間點，可以查詢，這個時間點之内的相關告警或者是日志的具體情況，這樣可以從其他的次元幫助使用者去分析一下問題可能會在哪裡。
這個在之前也說過，這裡隻是提供一緻的原因，幫助使用者提供更多的場景資訊，幫助使用者解決更多這樣的問題。
後面的第三個場景是業務畫像和故障診斷視圖。
業務畫像，我們客戶這邊一般以業務視角去做整個AIOps的場景分析，首先會有一個整體的AIOps狀态情況，這邊相當于整個AIOps可用性的分析，比如資料裡面用到資料庫，用到了中間件，當中的分析大概是什麼樣的，大概是什麼情況。
右側有一個分析的結果，它會把最近的時間段内整個系統資源的問題，有些是通過統計的算法，有些是通過分析的結果會列在這邊，讓你重點去關注。
另外這邊有智能建議，智能建議的内容會包含幾部分，一部分包含在這個時間段内進階别的告警，還有一些在這個時間段内我的核心資源一些核心名額有異常的變動，然後在這裡面去有這樣的一些提醒，讓使用者提前關注。
在下面這塊，實際上是告警關聯分析的矩陣圖，相當于在下面列的，在這個時間段範圍内，我這個業務系統下一些核心的子產品，然後它在于時間軸的前後情況下，到底發生的一些告警的情況是什麼樣的。
這裡面，我們的一些告警主要分成幾類，主要有變更類的、異常類的、告警類的，異常類的我們通過機器研究算法，也是單名額的預測把這種異常的點得出來之後轉化成告警。
這邊會列出來上面選擇的時間段内有哪些名額是異常的，你根據這個圖可以看到，名額哪些有異常的點，通過這個選取不同的名額，你可以看到具體對應的異常名額的情況。
這邊清單是跟你這邊異常名額有關系的名額到底有哪些，你可以通過這邊選擇去做一個具體的檢視。
另外一塊，相對于從日志層面，我們這邊剛才看到業務系統是有幾個次元，一個是從整體的次元，一個是從告警的次元，還有一塊是從名額的次元，下面這塊就是從日志的次元。
日志的次元主要是有兩塊，一個是日志聚類的一塊，還有日志量，日志量關注于具體哪一類的日志占某一天的時候，或者某一些時間點的時候是有一個異常突變，這樣他可能是需要重點關注的，然後日志聚類，當時我們的想法是把一些具體類别的日志通過聚類的方式提示給使用者，告訴他你目前哪一些日志比較多，這種像網絡裝置産生告警的時候，可能有一些列印出比較多的日志，這個日志最終通過聚類的方式，我們都會在前幾名，排得出來。
這樣，我們就可以根據聚類的内容可以去大緻判斷一下可能的一些問題，或者是故障的裝置到底在哪。
這一塊是業務畫像的場景，再往下是基于我們故障診斷，上面還是從告警的清單，點到某一個告警之後，首先上面顯示的是某一些告警的資訊，這邊是一個相關告警的清單，這塊是我們通過底層的算法去跟這種告警，包括内容，包括一些時間點發生前後的一個關系，然後自動地做比對，也就是說跟你這個事件相關的事件大概有哪些會列在這邊。
然後我們這邊會有一個針對于曆史告警的知識庫的東西，我們目前是通過兩種方式，一種方式是通過手動維護，另外一種方式，通過機器學習，可以去跑一些模型。
最後相當于它會拿到這樣的比對算法，然後在目前的告警内容跟我曆史庫裡的告警情況做比對，它會給出比對度排在前兩名的内容給出來，使用者可以參考曆史之前處理的一些問題具體的情況，包括處理的過程去解決他實際現實中的問題場景。
下面這塊就是以這個告警前後的時間軸，比如前五分鐘，後五分鐘，上下文的告警情況。
比如說這個告警發生前五分鐘其他資源發生了哪些告警，它是發生的變更還是産生了異常，都可以在這個圖上做整體的展現，可以幫助使用者大緻分析一下你的這一個點的發生大概是不是由于我前面幾個點的問題造成。
下面實際上通過這種另外的次元，就是日志的次元，跟你這個告警相關的日志，我們可以通過下面的選擇進行勾選，然後去檢視在這個時間段内的相關資源的日志有哪些，幫助使用者看一下分析潛在的問題到底在哪。
原文釋出時間為：2018-10-25
本文作者：左龍賀
本文來自雲栖社群合作夥伴“
高效運維”，了解相關資訊可以關注“
”。