我在與客戶交流 AIOps 的時候，他們時常覺得 AIOps 不夠成熟，以至於無法實施各種分析。
也有人認為：AIOps 的各項能力是線性發展的，他們必須事先評估和補足當前在“處理大量的事件和警報，以及統一化分散監控”方面的能力成熟度，才能考慮切入 AIOps。
我非常理解他們的關注點，畢竟數十年來，分析師和供應商灌輸了僵化的 ITIL 思想和嚴格的流程，使大家都不願為那些長期存在的問題，找到替代的解決方案。
誠然，AIOps 並未直接受到 ITIL 的約束，並能夠被分步驟地予以實施和改進，但是業界至今仍缺乏實際的行動指導。
本文通過早、中、後期九個步驟來給出 AIOps 所必要的最佳實踐。
AIOps的快速回顧
Gartner 判斷的 IT 新興市場趨勢為：傳統的 IT 流程與工具已不再適合處理那些由現代數字業務所帶來的挑戰。這不但與數據的傳輸速度、種類、以及體量有關，還與從線下的歷史分析轉為線上的實時分析有關。
Gartner 對於這種趨勢所給出的答案是：AIOps。它整合了IT 服務管理（ITSM）、IT 運營管理（ITOM）和數據層面上的 IT 自動化。
AIOps 使得數據能夠駐留在支持實時應用分析和深度歷史查詢的大數據平臺之中。這些分析可以由那些支持對數據流進行無人值守式處理的機器學習來實現。
因此 AIOps 的基本思想是：傳統的 IT 工具仍然發揮效用，例如服務管理仍然處理各種請求和事件；而性能管理仍然監視各種指標、事件和日誌。
但是它們的數據被關聯、並通過機器學習的分析,從而實現更好、更快的決策和任務過程的自動化。
最終狀態
AIOps 的最終狀態是：要保證數據能夠順暢地從多個數據源流入一個大的數據平臺中。
該平臺能夠對來自其他來源和類型的數據予以吸收、分析和後期處理；通過機器學習來管理和修改分析算法。
它能夠自動觸發工作流，其輸出結果會作為二次數據源被再次反饋到系統之中，使得系統實現自適應，並且通過響應各種數據卷、數據類型和數據源的變化，進而自動調整和按需通知相應的管理員。
基於上述概念，我將首先提出一個必要且可行的“路線圖”，然後詳細闡述在 AIOps 實施過程中可採用的具體步驟，以構建出一套 AIOps 的最佳實踐。
該 AIOps 路線圖共分為 9 步，他們分別是：
識別當前用例
就係統記錄達成一致
確定成功的標準、並著手跟蹤它們
評估當前和未來狀態的數據模型
分析現有工作流
開始自動化實施
開發新的分析工作流
使組織適應新的技能集
定製各種分析技術
早期階段
識別當前用例
鑑於各種變數情況，您最好先從自己所熟悉的方面開始。對於大多數用戶來說，他們當前的各種用例方案無法應對那些新技術的發展。因此，您可以列舉出自己當前正在處理、或準備解決的用例列表。
如下給出的切入點可方便您發現當前的“目標”狀態：
列出如何實現各種預期的結果
評估特定用例的優先級
突出當前能力、工具、技能或過程中與目標所存在的差距
同時，這也是制定一個成功 AIOps 戰略的良好開端。通過強調這種“開啟”方式，我們會發現許多新的用例。
各種新的預期結果也會湧現出來，而它們的優先級將隨著您的業務和技術的變化而相應地調整。可見新的 AIOps 方法會給我們帶來各種新的可能性與挑戰。
所以說，重要的是要在一開始就能找到從當前您所處的位置前往目標的橋樑。只有找到了您面臨的問題和需要改變的地方，才能選擇正確的道路去實現，反之則註定失敗。
評估數據的自由度
AIOps 的首要基本元素是：來自不同工具的數據流能夠自由地匯聚到大數據存儲區中。
因此，您必須評估自己IT系統中獲取到的各類數據的易用性和頻率。我們理想的最優模型為：實時地發送數據流。
然而，目前很少有 IT 監控或服務檯（service desk）工具能夠支持向外流出數據。當然，它們迭代出的最新版本應該能以 REST API 方式提供編程上的交互與支持。
但是，如果使用的是基於諸如 Oracle 或 SQL 之類的傳統關係數據庫，由於它們在最初設計時並非為了支持數據的連續流出，那麼即使具有可編程接口，也會對生產系統的性能產生巨大的影響，因此，我們可以斷言它們並不能支持數據流。
可見，在制定 AIOps 策略的早期，重要的步驟之一就是要明確自己系統對於數據流的支持能力，併為如下問題給出相應的答案：
我如何能從當前的 IT 工具中獲取數據？
我能得到什麼樣的數據？
我能夠通過編程的方式來實現嗎？
我獲取這些數據的頻率是怎樣的？
通過發現這些約束條件，您可以考慮去更改當前的數據整合策略（例如，將批處理上傳模式轉化為流式），甚至考慮將現有的IT工具替換為那些支持實時數據流的軟件。
就係統記錄達成一致
AIOps 的第二個基本要素是：組織的協同和溝通。我建議 IT 運營和 IT 服務管理人員協作審查各種數據的需求，同時就各自的角色和責任達成共識。在此，我們主要著眼於基於共享數據上的協同決策。
這裡所說的數據並不是那些已經流入 AIOps 大數據存儲區，以待分析的數據。而是 IT 人員可以從自己環境中獲悉的、用於採取行動和做出決斷、並最終能夠跟蹤效果的那些數據。因此，整個團隊需要針對數據達成如下共識：
為了突破系統當前限制所需要的最小數據集
-
數據所在的位置
團隊所能共享的聯合視圖與訪問權限
根據傳統的 ITIL 模型，在許多成熟的組織中，滿足上述條件的系統是他們的服務檯。各種服務請求、事件和變更性的數據都被存放於此。
但是當 DevOps 團隊開始使用 Jira（譯者注：一種項目與事務跟蹤的工具），來記錄缺陷和功能性的改進時，該模型會受到了一定的挑戰。
因為在使用 APM（譯者注：一種監控和管理應用軟件性能和可用性的工具）時，IT 運營與安全團隊是無法通過各種本地或遠程事件，來捕獲或識別多種威脅的。
因此準備實施 AIOps 就意味著：您需要在應用程序、服務或業務的價值鏈中確定所有有效的結果性指標，並制定出一個方案來彙集這些數據。
您可以在大數據平臺上構建各種“儀表板”，來篩選出具有特定用途的大數據集，即：對不同數據源產生不同的視圖。
當然，您可以從“在當前環境中選擇數據子集，並將其反饋（如 Jira 工單和 APM 事件等）到已建成的記錄系統中”開始。
制定成功標準並開始跟蹤它們
任何成功的業務與 IT 管理都起源於瞭解各種關鍵性能指標（KPI）和度量標準。因此，具有可操作性的方面包括：
瞭解對哪些方面進行測量
實現一致且完備的措施
定期報告或提供性能衡量的可視化
能夠對責任方問責
一般大多數 IT 工具都自帶有幾種衡量工具和模板，它們往往能夠為您提供各種參數。而我們都知道：數量是無法真正反映背後因果關係的。
如果我們只是簡單地將它們放到報表上的話，並不能給企業帶來業務上的提升。
中期階段
評估當前和未來狀態下的數據模型
數據模型評估是一個關鍵方面，但很少有人真正理解或願意這麼做。本質上說，您必須為即將上馬的 AIOps 方案釐清各個數據源的數據模型，以保證這些模型能夠被 AIOps 的用例所識別，進而評估出不同模型間的直接交互和預期結果。
我們之所以說它具有一定的挑戰性，是因為大多數 IT 工具的數據模型對於用戶都是不可見的。
很少有組織、甚至包括一些數據分析人員或專家，能真正知道大數據平臺（使用的是 NoSQL）與傳統數據庫（使用的是 SQL）的不同之處。
AIOps 實際上是在一個大數據存儲庫中關聯了來自不同 IT（和非 IT）源的數據，使得它們能夠互聯互通，從而實現分析和趨勢判斷。
AIOps 系統可以處理許多種共享的數據結構（如下所示），而不需要額外地進行二次開發或改進：
時間戳： 各種事件、日誌和度量中帶有時間點特徵的數據，可以被聚集在一起用於關聯事件，並按照時序進行因果分析。
屬性： 某個事件、日誌或度量所關聯的信息鍵值對（key:value）, 如“狀態”、“源”、“提交者”等，可用於在不同數據集之間創建關係模型。
歷史性：時間序列或事件活動的過往數據，可用來預測將來的表現或門限值，如飽和度（saturation）和退化度（degradation）。
效應：一天、一週、一個月等時序數據所呈現的趨勢或規律性，可用於關聯多個數據集、或預測可伸縮性的資源需求。
應用程序、服務和業務模型：如果您能夠定期進行發現與配置管理上的實踐，就可以用它們來通知 AIOps 平臺各種資產的分組、關聯、依存關係、以及做到數據的去重。
總之，通過構建良好的時序數據，AIOps 能夠運用各種運營監控與管理工具來關聯、分析和預測各種時序數據，進而實現：
將 IT 和非 IT 類數據相集合，例如：用戶數量+性能表現、延遲時間+轉換率；
並能增加數據的“粒度”，例如：從 5 分鐘的頻率上到 1 分鐘；
對數據流進行應用級的分析，例如：做到“實時”或對特定歷史時間段的查詢。
人工捕獲的事件往往是非結構化的；而大多數設備獲取的 IT 事件 blob（譯者注：binary large object，二進制大對象）也只能達到半結構化。
它們都存在著：格式不一致、不夠完整、大量重複等特點。因此，AIOps 應當對這些 IT 事件屬性提供範式轉換，為進一步分析做好準備。
分析現有工作流
至此，我想您對 AIOps 方案的分析已經準備就緒了。此處的分析並非來自於 IT 工具，而是您定期或不定期進行的，旨在改進流程、降低成本和提高性能的離線式手動分析。
您可以通過手動分析 AIOps 方案，以不斷迭代的方式解決自動化過程中出現的問題，進而減少花費在分析上的手動工作量，並提高分析的頻率和範圍。
可見，AIOps 的目的就是：減少您在手動上花費的時間和精力，通過提高速度與頻率，以實現對數據集的自動化實時分析。
開始實施自動化
誠然，每個人都知道自動化的價值，但是不同團隊對此有著不同的理解。隨著 DevOps 所帶來的持續集成與交付（CI/CD），IT 運營的自動化道路也發生了相應的影響。
IT 運營（IT Ops）：著眼於自動化任務和協調各項步驟。其中包括：實現服務檯的工作自動化、自動給服務器打補丁、通過監控工具來自動修正系統錯誤。難點在於橫跨各種工具間的步驟配合與相互聯動。
DevOps：著眼於自動化自己的開發任務和業務流程，以消除瀑布式開發所帶來的分段式審查過程、隔離式測試、行為合規、以及運營與上線聯動等所造成的瓶頸與滯後。
可見，DevOps 的應用團隊旨在通過開創新的服務（如雲端應用），加快集成與交付的速度與頻率。
而IT運營團隊，則需要“自動化所有”，他們需要協調的不只是 CI/CD，而是整個“鏈條”。
如果他們不知道服務何時從測試轉移到了生產環境，不知道誰手中的源代碼會對產生環境造成何種影響，不知道如何識別與度量業務開發人員積壓的工作，那麼就無法真正有效地去管理好自己的自動化環境。
因此，IT 運營需要跟上 DevOps 團隊的速度和敏捷性，綜合運用工具來發現信息、共享信息，並通過與 DevOps 的溝通來“刷出自己的存在感”。
後期階段
開發新的分析工作流
通過中期階段對於現有工作流的分析，您應當能夠自動化並擴展了自己的 AIOps 方案，同時實現瞭如下方面：
評估現有工作流的價值
修改和改進現有工作流
基於現有差距開發新的工作流
一旦在 AIOps 平臺中實現了對現有流程的自動化，我們就可以進一步評估：正在分析的信息是否真正有用？其趨勢判斷的結果是否可行？以及如需更改的影響會有多大？
我們可以利用現有工作流的分析結果形成“正反饋”，從而開發出新的分析工作流。
使組織適應新的技能集
在角色上，IT 運營人員將從一般“從業者”轉換為“審計者”。他們應當跳出固守了十多年的對於設備完全掌控的觀念，將目光投到業務數據的分析上。
雖然不需要具有數據科學方面深度的機器分析水平，但是他們確實需要了解系統是如何處理數據、以及是否能夠實現業務的目標。這也是 AIOps 將給 IT 運營人員帶來的最大變化。
縱然整個市場目前尚未完全成熟，但是各個企業仍值得去培養具有 AIOps 能力的人才。假以時日，他們必將為組織帶來結構化的科學轉變，並讓組織從中受益。
定製各種分析技術
最後在運用 AIOps 進行 IT 運營方面，組織還需要開發出一些數據科學方面的實踐。通過數據科學家、開發者與分析師的協作，他們會開發出能在大數據集上運行的算法，並在代碼上使用 Python 或 R 語言來實現各種數據科學的模型。
當然，IT 運營人員不必瞭解過多有關數學和編程方面的知識，他們只需要能夠管理一個具有半智能、半自治能力的系統架構。
他們應當能夠根據 AIOps 供應商所提供的多個備選分析系統，選擇最適合於自己環境的組合。
在日常運營中，AIOps 平臺也將能夠提供實時的、定製的迴歸分析，以輔助做出各種決策。
原文標題：A Roadmap toAIOps
原文鏈接：
https://dzone.com/articles/a-roadmap-to-aiops
https://dzone.com/articles/a-roadmap-to-aiops-part-2
AIOps 風向標！第10屆 GOPS 全球運維大會9.14-15
閱讀更多 高效運維 的文章
