【51CTO.com原創(chuàng)稿件】本文首先提出一個必要且可行的“路線圖”，然后詳細闡述在 AIOps 實施過程中可采用的具體步驟，以構(gòu)建出一套 AIOps 的最佳實踐。

[[238660]]

我在與客戶交流 AIOps 的時候，他們時常覺得 AIOps 不夠成熟，以至于無法實施各種分析。

也有人認為：AIOps 的各項能力是線性發(fā)展的，他們必須事先評估和補足當前在“處理大量的事件和警報，以及統(tǒng)一化分散監(jiān)控”方面的能力成熟度，才能考慮切入 AIOps。

我非常理解他們的關注點，畢竟數(shù)十年來，分析師和供應商灌輸了僵化的 ITIL 思想和嚴格的流程，使大家都不愿為那些長期存在的問題，找到替代的解決方案。

誠然，AIOps 并未直接受到 ITIL 的約束，并能夠被分步驟地予以實施和改進，但是業(yè)界至今仍缺乏實際的行動指導。

本文通過早、中、后期九個步驟來給出 AIOps 所必要的最佳實踐。

AIOps的快速回顧

Gartner 判斷的 IT 新興市場趨勢為：傳統(tǒng)的 IT 流程與工具已不再適合處理那些由現(xiàn)代數(shù)字業(yè)務所帶來的挑戰(zhàn)。這不但與數(shù)據(jù)的傳輸速度、種類、以及體量有關，還與從線下的歷史分析轉(zhuǎn)為線上的實時分析有關。

Gartner 對于這種趨勢所給出的答案是：AIOps。它整合了 IT 服務管理（ITSM）、IT 運營管理（ITOM）和數(shù)據(jù)層面上的 IT 自動化。

AIOps 使得數(shù)據(jù)能夠駐留在支持實時應用分析和深度歷史查詢的大數(shù)據(jù)平臺之中。這些分析可以由那些支持對數(shù)據(jù)流進行無人值守式處理的機器學習來實現(xiàn)。

因此 AIOps 的基本思想是：傳統(tǒng)的 IT 工具仍然發(fā)揮效用，例如服務管理仍然處理各種請求和事件；而性能管理仍然監(jiān)視各種指標、事件和日志。

但是它們的數(shù)據(jù)被關聯(lián)、并通過機器學習的分析,從而實現(xiàn)更好、更快的決策和任務過程的自動化。

最終狀態(tài)

AIOps 的最終狀態(tài)是：要保證數(shù)據(jù)能夠順暢地從多個數(shù)據(jù)源流入一個大的數(shù)據(jù)平臺中。

該平臺能夠?qū)碜云渌麃碓春皖愋偷臄?shù)據(jù)予以吸收、分析和后期處理；通過機器學習來管理和修改分析算法。

它能夠自動觸發(fā)工作流，其輸出結(jié)果會作為二次數(shù)據(jù)源被再次反饋到系統(tǒng)之中，使得系統(tǒng)實現(xiàn)自適應，并且通過響應各種數(shù)據(jù)卷、數(shù)據(jù)類型和數(shù)據(jù)源的變化，進而自動調(diào)整和按需通知相應的管理員。

基于上述概念，我將首先提出一個必要且可行的“路線圖”，然后詳細闡述在 AIOps 實施過程中可采用的具體步驟，以構(gòu)建出一套 AIOps 的最佳實踐。

該 AIOps 路線圖共分為 9 步，他們分別是：

• 識別當前用例
• 就系統(tǒng)記錄達成一致
• 確定成功的標準、并著手跟蹤它們
• 評估當前和未來狀態(tài)的數(shù)據(jù)模型
• 分析現(xiàn)有工作流
• 開始自動化實施
• 開發(fā)新的分析工作流
• 使組織適應新的技能集
• 定制各種分析技術

早期階段

識別當前用例

鑒于各種變數(shù)情況，您最好先從自己所熟悉的方面開始。對于大多數(shù)用戶來說，他們當前的各種用例方案無法應對那些新技術的發(fā)展。因此，您可以列舉出自己當前正在處理、或準備解決的用例列表。

如下給出的切入點可方便您發(fā)現(xiàn)當前的“目標”狀態(tài)：

• 列出如何實現(xiàn)各種預期的結(jié)果
• 評估特定用例的優(yōu)先級
• 突出當前能力、工具、技能或過程中與目標所存在的差距

同時，這也是制定一個成功 AIOps 戰(zhàn)略的良好開端。通過強調(diào)這種“開啟”方式，我們會發(fā)現(xiàn)許多新的用例。

各種新的預期結(jié)果也會涌現(xiàn)出來，而它們的優(yōu)先級將隨著您的業(yè)務和技術的變化而相應地調(diào)整?？梢娦碌?AIOps 方法會給我們帶來各種新的可能性與挑戰(zhàn)。

所以說，重要的是要在一開始就能找到從當前您所處的位置前往目標的橋梁。只有找到了您面臨的問題和需要改變的地方，才能選擇正確的道路去實現(xiàn)，反之則注定失敗。

評估數(shù)據(jù)的自由度

AIOps 的首要基本元素是：來自不同工具的數(shù)據(jù)流能夠自由地匯聚到大數(shù)據(jù)存儲區(qū)中。

因此，您必須評估自己IT系統(tǒng)中獲取到的各類數(shù)據(jù)的易用性和頻率。我們理想的最優(yōu)模型為：實時地發(fā)送數(shù)據(jù)流。

然而，目前很少有 IT 監(jiān)控或服務臺（service desk）工具能夠支持向外流出數(shù)據(jù)。當然，它們迭代出的最新版本應該能以 REST API 方式提供編程上的交互與支持。

但是，如果使用的是基于諸如 Oracle 或 SQL 之類的傳統(tǒng)關系數(shù)據(jù)庫，由于它們在最初設計時并非為了支持數(shù)據(jù)的連續(xù)流出，那么即使具有可編程接口，也會對生產(chǎn)系統(tǒng)的性能產(chǎn)生巨大的影響，因此，我們可以斷言它們并不能支持數(shù)據(jù)流。

可見，在制定 AIOps 策略的早期，重要的步驟之一就是要明確自己系統(tǒng)對于數(shù)據(jù)流的支持能力，并為如下問題給出相應的答案：

• 我如何能從當前的 IT 工具中獲取數(shù)據(jù)？
• 我能得到什么樣的數(shù)據(jù)？
• 我能夠通過編程的方式來實現(xiàn)嗎？
• 我獲取這些數(shù)據(jù)的頻率是怎樣的？

通過發(fā)現(xiàn)這些約束條件，您可以考慮去更改當前的數(shù)據(jù)整合策略（例如，將批處理上傳模式轉(zhuǎn)化為流式），甚至考慮將現(xiàn)有的IT工具替換為那些支持實時數(shù)據(jù)流的軟件。

就系統(tǒng)記錄達成一致

AIOps 的第二個基本要素是：組織的協(xié)同和溝通。我建議 IT 運營和 IT 服務管理人員協(xié)作審查各種數(shù)據(jù)的需求，同時就各自的角色和責任達成共識。在此，我們主要著眼于基于共享數(shù)據(jù)上的協(xié)同決策。

這里所說的數(shù)據(jù)并不是那些已經(jīng)流入 AIOps 大數(shù)據(jù)存儲區(qū)，以待分析的數(shù)據(jù)。而是 IT 人員可以從自己環(huán)境中獲悉的、用于采取行動和做出決斷、并最終能夠跟蹤效果的那些數(shù)據(jù)。因此，整個團隊需要針對數(shù)據(jù)達成如下共識：

• 為了突破系統(tǒng)當前限制所需要的最小數(shù)據(jù)集
• 數(shù)據(jù)所在的位置
• 團隊所能共享的聯(lián)合視圖與訪問權限

根據(jù)傳統(tǒng)的 ITIL 模型，在許多成熟的組織中，滿足上述條件的系統(tǒng)是他們的服務臺。各種服務請求、事件和變更性的數(shù)據(jù)都被存放于此。

但是當 DevOps 團隊開始使用 Jira（譯者注：一種項目與事務跟蹤的工具），來記錄缺陷和功能性的改進時，該模型會受到了一定的挑戰(zhàn)。

因為在使用 APM（譯者注：一種監(jiān)控和管理應用軟件性能和可用性的工具）時，IT 運營與安全團隊是無法通過各種本地或遠程事件，來捕獲或識別多種威脅的。

因此準備實施 AIOps 就意味著：您需要在應用程序、服務或業(yè)務的價值鏈中確定所有有效的結(jié)果性指標，并制定出一個方案來匯集這些數(shù)據(jù)。

您可以在大數(shù)據(jù)平臺上構(gòu)建各種“儀表板”，來篩選出具有特定用途的大數(shù)據(jù)集，即：對不同數(shù)據(jù)源產(chǎn)生不同的視圖。

當然，您可以從“在當前環(huán)境中選擇數(shù)據(jù)子集，并將其反饋（如 Jira 工單和 APM 事件等）到已建成的記錄系統(tǒng)中”開始。

制定成功標準并開始跟蹤它們

任何成功的業(yè)務與 IT 管理都起源于了解各種關鍵性能指標（KPI）和度量標準。因此，具有可操作性的方面包括：

• 了解對哪些方面進行測量
• 實現(xiàn)一致且完備的措施
• 定期報告或提供性能衡量的可視化
• 能夠?qū)ω熑畏絾栘?/li>

一般大多數(shù) IT 工具都自帶有幾種衡量工具和模板，它們往往能夠為您提供各種參數(shù)。而我們都知道：數(shù)量是無法真正反映背后因果關系的。

如果我們只是簡單地將它們放到報表上的話，并不能給企業(yè)帶來業(yè)務上的提升。

中期階段

評估當前和未來狀態(tài)下的數(shù)據(jù)模型

數(shù)據(jù)模型評估是一個關鍵方面，但很少有人真正理解或愿意這么做。本質(zhì)上說，您必須為即將上馬的 AIOps 方案厘清各個數(shù)據(jù)源的數(shù)據(jù)模型，以保證這些模型能夠被 AIOps 的用例所識別，進而評估出不同模型間的直接交互和預期結(jié)果。

我們之所以說它具有一定的挑戰(zhàn)性，是因為大多數(shù) IT 工具的數(shù)據(jù)模型對于用戶都是不可見的。

很少有組織、甚至包括一些數(shù)據(jù)分析人員或?qū)＜?，能真正知道大?shù)據(jù)平臺（使用的是 NoSQL）與傳統(tǒng)數(shù)據(jù)庫（使用的是 SQL）的不同之處。

AIOps 實際上是在一個大數(shù)據(jù)存儲庫中關聯(lián)了來自不同 IT（和非 IT）源的數(shù)據(jù)，使得它們能夠互聯(lián)互通，從而實現(xiàn)分析和趨勢判斷。

AIOps 系統(tǒng)可以處理許多種共享的數(shù)據(jù)結(jié)構(gòu)（如下所示），而不需要額外地進行二次開發(fā)或改進：

• 時間戳： 各種事件、日志和度量中帶有時間點特征的數(shù)據(jù)，可以被聚集在一起用于關聯(lián)事件，并按照時序進行因果分析。
• 屬性： 某個事件、日志或度量所關聯(lián)的信息鍵值對（key:value）, 如“狀態(tài)”、“源”、“提交者”等，可用于在不同數(shù)據(jù)集之間創(chuàng)建關系模型。
• 歷史性：時間序列或事件活動的過往數(shù)據(jù)，可用來預測將來的表現(xiàn)或門限值，如飽和度（saturation）和退化度（degradation）。
• 效應：一天、一周、一個月等時序數(shù)據(jù)所呈現(xiàn)的趨勢或規(guī)律性，可用于關聯(lián)多個數(shù)據(jù)集、或預測可伸縮性的資源需求。
• 應用程序、服務和業(yè)務模型：如果您能夠定期進行發(fā)現(xiàn)與配置管理上的實踐，就可以用它們來通知 AIOps 平臺各種資產(chǎn)的分組、關聯(lián)、依存關系、以及做到數(shù)據(jù)的去重。

總之，通過構(gòu)建良好的時序數(shù)據(jù)，AIOps 能夠運用各種運營監(jiān)控與管理工具來關聯(lián)、分析和預測各種時序數(shù)據(jù)，進而實現(xiàn)：

• 將 IT 和非 IT 類數(shù)據(jù)相集合，例如：用戶數(shù)量+性能表現(xiàn)、延遲時間+轉(zhuǎn)換率；
• 并能增加數(shù)據(jù)的“粒度”，例如：從 5 分鐘的頻率上到 1 分鐘；
• 對數(shù)據(jù)流進行應用級的分析，例如：做到“實時”或?qū)μ囟v史時間段的查詢。

人工捕獲的事件往往是非結(jié)構(gòu)化的；而大多數(shù)設備獲取的 IT 事件 blob（譯者注：binary large object，二進制大對象）也只能達到半結(jié)構(gòu)化。

它們都存在著：格式不一致、不夠完整、大量重復等特點。因此，AIOps 應當對這些 IT 事件屬性提供范式轉(zhuǎn)換，為進一步分析做好準備。

如今，許多 AIOps 都能聚焦事件的管理、分析和關聯(lián)。一旦數(shù)據(jù)流入 AIOps 平臺，我們就必須考慮其數(shù)據(jù)結(jié)構(gòu)和完整性是否支持機器分析。

常用的一種方法是：對傳入的數(shù)據(jù)執(zhí)行“ETL”（Extract 提取、Transform 轉(zhuǎn)換、Load 加載），也就是在數(shù)據(jù)流中進行規(guī)范化和集中式轉(zhuǎn)換，以便實現(xiàn)對數(shù)據(jù)的關聯(lián)和分析。

當然，在采用 AIOps 方案之前，企業(yè)可能會面臨兩方面的壓力：

• 大量有待轉(zhuǎn)換、處理和分析的數(shù)據(jù)可能會使得當前的系統(tǒng)無法實現(xiàn)實時性、或升級成本高昂。
• 需要人工去管理和維護各種數(shù)據(jù)的結(jié)構(gòu)與標準，否則系統(tǒng)只能對已知模型進行處理，而無法適用于新的數(shù)據(jù)類型。

另外，大多數(shù)云服務系統(tǒng)也會使用“標簽”策略作為最佳實踐。它們通過對不同類型對象的屬性變量進行哈希，然后獨立于對象本身，僅使用標簽來進行引用、排序、關聯(lián)和分析。

不同于那些帶有固定公共值的預定義映射關系，標簽是能夠跟隨數(shù)據(jù)一同變化的。

NoSQL 數(shù)據(jù)庫和諸如 Elasticsearch 之類的大規(guī)模分析工具，能夠通過標簽來處理各種屬性關系。

此外，系統(tǒng)還能在數(shù)據(jù)流入時就實時地打上標簽，以避免任何具有未知特性的“盲數(shù)據(jù)”產(chǎn)生。

可見，企業(yè)需要通過具有 ETL 或標簽能力的 AIOps 大數(shù)據(jù)平臺，來實現(xiàn)對數(shù)據(jù)模型的實時評估與管控。

分析現(xiàn)有工作流

至此，我想您對 AIOps 方案的分析已經(jīng)準備就緒了。此處的分析并非來自于 IT 工具，而是您定期或不定期進行的，旨在改進流程、降低成本和提高性能的離線式手動分析。

您可以通過手動分析 AIOps 方案，以不斷迭代的方式解決自動化過程中出現(xiàn)的問題，進而減少花費在分析上的手動工作量，并提高分析的頻率和范圍。

可見，AIOps 的目的就是：減少您在手動上花費的時間和精力，通過提高速度與頻率，以實現(xiàn)對數(shù)據(jù)集的自動化實時分析。

開始實施自動化

誠然，每個人都知道自動化的價值，但是不同團隊對此有著不同的理解。隨著 DevOps 所帶來的持續(xù)集成與交付（CI/CD），IT 運營的自動化道路也發(fā)生了相應的影響。

• IT 運營（IT Ops）：著眼于自動化任務和協(xié)調(diào)各項步驟。其中包括：實現(xiàn)服務臺的工作自動化、自動給服務器打補丁、通過監(jiān)控工具來自動修正系統(tǒng)錯誤。難點在于橫跨各種工具間的步驟配合與相互聯(lián)動。
• DevOps：著眼于自動化自己的開發(fā)任務和業(yè)務流程，以消除瀑布式開發(fā)所帶來的分段式審查過程、隔離式測試、行為合規(guī)、以及運營與上線聯(lián)動等所造成的瓶頸與滯后。

可見，DevOps 的應用團隊旨在通過開創(chuàng)新的服務（如云端應用），加快集成與交付的速度與頻率。

而IT運營團隊，則需要“自動化所有”，他們需要協(xié)調(diào)的不只是 CI/CD，而是整個“鏈條”。

如果他們不知道服務何時從測試轉(zhuǎn)移到了生產(chǎn)環(huán)境，不知道誰手中的源代碼會對產(chǎn)生環(huán)境造成何種影響，不知道如何識別與度量業(yè)務開發(fā)人員積壓的工作，那么就無法真正有效地去管理好自己的自動化環(huán)境。

因此，IT 運營需要跟上 DevOps 團隊的速度和敏捷性，綜合運用工具來發(fā)現(xiàn)信息、共享信息，并通過與 DevOps 的溝通來“刷出自己的存在感”。

后期階段

開發(fā)新的分析工作流

通過中期階段對于現(xiàn)有工作流的分析，您應當能夠自動化并擴展了自己的 AIOps 方案，同時實現(xiàn)了如下方面：

• 評估現(xiàn)有工作流的價值
• 修改和改進現(xiàn)有工作流
• 基于現(xiàn)有差距開發(fā)新的工作流

一旦在 AIOps 平臺中實現(xiàn)了對現(xiàn)有流程的自動化，我們就可以進一步評估：正在分析的信息是否真正有用？其趨勢判斷的結(jié)果是否可行？以及如需更改的影響會有多大？

我們可以利用現(xiàn)有工作流的分析結(jié)果形成“正反饋”，從而開發(fā)出新的分析工作流。

使組織適應新的技能集

在角色上，IT 運營人員將從一般“從業(yè)者”轉(zhuǎn)換為“審計者”。他們應當跳出固守了十多年的對于設備完全掌控的觀念，將目光投到業(yè)務數(shù)據(jù)的分析上。

雖然不需要具有數(shù)據(jù)科學方面深度的機器分析水平，但是他們確實需要了解系統(tǒng)是如何處理數(shù)據(jù)、以及是否能夠?qū)崿F(xiàn)業(yè)務的目標。這也是 AIOps 將給 IT 運營人員帶來的最大變化。

縱然整個市場目前尚未完全成熟，但是各個企業(yè)仍值得去培養(yǎng)具有 AIOps 能力的人才。假以時日，他們必將為組織帶來結(jié)構(gòu)化的科學轉(zhuǎn)變，并讓組織從中受益。

定制各種分析技術

最后在運用 AIOps 進行 IT 運營方面，組織還需要開發(fā)出一些數(shù)據(jù)科學方面的實踐。通過數(shù)據(jù)科學家、開發(fā)者與分析師的協(xié)作，他們會開發(fā)出能在大數(shù)據(jù)集上運行的算法，并在代碼上使用 Python 或 R 語言來實現(xiàn)各種數(shù)據(jù)科學的模型。

當然，IT 運營人員不必了解過多有關數(shù)學和編程方面的知識，他們只需要能夠管理一個具有半智能、半自治能力的系統(tǒng)架構(gòu)。

他們應當能夠根據(jù) AIOps 供應商所提供的多個備選分析系統(tǒng)，選擇最適合于自己環(huán)境的組合。

在日常運營中，AIOps 平臺也將能夠提供實時的、定制的回歸分析，以輔助做出各種決策。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】