你認為DevOps很難理解嗎?可以先了解AIOps。調研機構Gartner公司于5年前首次創造了這個術語，AIOps的含義如今已從“Algorithmic IT Operations(基于算法的 IT 運維)”轉換為“AI Operations(人工智能運維)”。使用通用算法幫助IT運營團隊的想法并不是那么新穎。有人可能會說，AIOps試圖趕上人工智能的宣傳和炒作浪潮，也有一些運維和監視工具制造商試圖增加人工智能的成分。如果要求10個人來定義AIOps的話，就可能會得到10個不同的定義：這類似于以前很少有人就云計算的定義達成共識一樣。

 

DevOps研究所的研究主管Eveline Oehrlich對此進行了描述：“AIOps解決方案使IT運營和其他團隊能夠通過對即將到來的數據量和類別進行更好的分析，以改善關鍵流程、任務和決策。采用這些工具可以自動快速接收大量數據。機器學習用于分析數據并提供可預測或警告發現的問題。這些新發現的知識可以用于自動化或決策。”

 

IT領導者需要能夠了解并解釋一些關于AIOps的常見誤解，這些誤解可能來自組織的領導者、同事、合作伙伴和客戶。以下將解釋各種AIOps方法符合或不符合業務目標的原因。

 

 

因此，以下深入地研究推動當前AIOps勢頭增長的因素以及IT團隊所看到的收益。例如，如果組織已經在使用容器和Kubernetes，那么可能會有喜歡自動驅動集群的想法，那么現在可以立即開始實施AIOps。

 

 

如果想將AIOps引入組織，則可能會想購買一種AIOps產品，并計劃在一年中部署并完成。在運營堆棧中添加了另一種產品，并且增加了復雜性，如何處理更多的復雜性?

 

首先，考慮當前AIOps產品提供的常見功能，仔細查看當前的工具集，并評估存在漏洞的地方：

 

•基線：用于度量和其他基于時間序列的數據。

•根本原因分析：連接多個信息源并深入掘取。

•異常檢測：預測未來并警告偏差。

•相關性：例如指標和票證之間的相關性。

•模擬：假設場景。

 

人們會看到AIOps是一種功能，而不是獨立的產品。對于某些功能來說，專用工具的功能并不夠，因為可能只將所有工具進行互連，才會產生“魔法”。這就像單個神經元無法構成大腦一樣。

 

 

俗話說，“在學會跑步之前需要先學會走路。”原有的監控措施并沒有什么問題，只是需要在系統環境中增加指標、日志和可觀察性。因此，首要任務是使其運營變得簡單。如果遇到太多警報，需要確定最重要的警報。如果沒有從關鍵應用程序中獲取指標，則開始實施指標。開始定義組織需要滿足的服務水平指標(SLI)和一些服務水平目標(SLO)。

 

在這樣做的同時，就會發現監控設置中的一些盲點，并提高工作的可視性和運營能力。在遇到障礙之后，人工設置警報閾值不再起作用，那么現在是使用新工具的時候了。

 

了解局限性始終是改進的第一步，因此，AIOps的旅程始于收集數據并理解這些數據。如果人工智能研究人員涉足新領域，那么要做的第一件事就是進行探索性數據分析(EDA)。這包括了解數據特征，例如什么是列名，什么是值以及什么是語義場景。

 

同樣，AIOps工作的第一步將是確保組織可以輕松地收集和訪問所有運營數據，并且能夠將其可視化。這不僅意味著當前的數據，也意味著歷史數據。

 

只有在這樣做之后，才能開始下一步旅程，嘗試尋找新的信號和見解，并將其投入自動化的行動中。

 

 

有些人將AIOps看作是運營中的一種文化變革，就像DevOps運動因相關的文化變革而聞名一樣。DevOps結合了開發和運營團隊的兩種文化思想，創造出一種以速度和試驗為特征的新文化。如今，人們理所當然地認為DevOps專業人員同時使用開發人員和運營工具集中的工具。將會看到諸如統一的基礎設施或應用程序開發團隊之類的東西為運行其代碼提供了服務水平指標(SLI)。

 

現在，可以將數據科學家角色添加到組合中，將會獲得AIOps。換句話說，使用探索性數據分析(EDA)之類的方法或Jupyter Notebooks之類的工具來使組織的卓越運營變得更好，這將推動更多的IT專業人員進入AIOps領域。

 

人工智能/機器學習的社區實際上也是如此，它仍然與部署模型的運營方面脫節。如果數據科學家變得更像人工智能工程師并且接受和理解DevOps的優勢和挑戰，那又會怎樣?然后隨著時間的推移，人們會將注意力轉移到IT領域的問題上：很有趣的是，采用人工智能技術，在識別有關貓的圖片方面可能比人類還要強大，但識別壞硬盤方面對于人工智能技術來說仍然是一個挑戰。

 

 

因此，如果AIOps不是一種產品，那么將在哪里產生?一旦發現數據集之間存在某種關聯，或者多次發生中斷，就希望AIOps自動執行某些運行或指導如何解決中斷問題。

 

而這個“魔法”發生在工具之間的結構中。它可以體現在零售價格較小的連接層中，例如聊天機器人為用戶提供了到相關系統的鏈接，從而使從指標儀表板跳轉到調試控制臺變得更加容易。

 

但是關聯如果不是因果關系，即使使用AIOps工具找到了兩組指標之間的相關性，仍然需要對其進行驗證，并決定將來是否要對它采取行動。或者，相關性可以幫助確定中斷的原因。

 

一切都是為了更好地理解和管理設置的復雜性，然后集成自動化的幫助程序和操作。

 

 

這正是開源軟件發揮重要作用的地方。在開源產品中，組織可以在任何級別讀取代碼并理解正在做什么。將其轉換為運營領域，用戶能夠在軟件堆棧的每一層公開指標并跟蹤數據，并理解其含義。新一代數據中心建立在Kubernetes的基礎上，Kubernetes大量使用了微服務和API驅動的軟件部署流程。如今，監視API調用非常簡單。從本質上來說，可觀察性意味著可以隨時以任何細節層次檢查景觀。使用一些數據科學工具可視化并指導瀏覽數據，可以幫助進行根本原因分析和故障排除。

 

現在，組織使用相同的范例來部署和管理自己的應用程序，將它們容器化，然后重新使用監視堆棧，可以檢查和觀察其應用程序堆棧。

 

因為使用了相同的工具，所以可以輕松地將平臺和應用程序中的指標關聯起來。 Prometheus已經成為該領域中的實際監控標準，并且本身是由API驅動的。而類似的項目(例如Loki和Jaeger)，可以幫助進行日志和跟蹤。

 

然后，組織可以使用諸如Open Data Hub或Kubeflow之類的Kubernetes本地數據科學平臺來收集和分析所有數據。

 

對于IT團隊而言，其好處是減少了摩擦并實現了深度集成，其標準是通過開源工具實施的。

 

 

也許組織無法擁有足夠的數據。但是如上所述，這些數據必須干凈且易于理解。因此，組織可以收集自己的數據池并訓練自己的人工智能模型，實際上，所有商業AIOps工具都需要這樣做，因為沒有內置的預先訓練的智能。

 

但是，如果可以在公共數據上訓練一些通用模型，然后將其用作訓練自己的模型的基準，那該怎么辦?沒有人希望從頭開始，而是希望獲得更多的幫助。數據庫應用程序很可能會為常見的工作負載和架構提供自己的模型。然后根據組織特定需求將學習內容轉移到特定設置中。這將是一個開始，根據自己的需求進行區分。

 

例如在一個公共云項目中，平臺和工作負載在社區中運行，而運營數據(例如度量、日志和票證)則在開放源代碼許可下發布。這是為了使數據科學家能夠創建開放和免費的模型。

 

 

任何采用DevOps工作方式的IT領導者都知道，改變習慣需要不斷的實踐。對于采用AIOps思維方式的IT團隊也是如此。可以從一個容易理解的問題開始做起，然后經歷開發AIOps功能的演進周期，努力實現更多的人工智能輔助、人工智能增強，最后是人工智能自動化的IT運營。

 

文化的改變需要組織中的擁護者、贊助者和榜樣。與其陷入對人工智能的宣傳和炒作，不如先采用，理解基本原理，并解決問題。每一次革命性的創新都是從小事開始的。人們在未來可能會為思想開放的工程師、運營專家以及先進的平臺和操作堆棧所能完成的工作感到驚訝。

 

版權聲明：本文為企業網D1Net編譯，轉載需注明出處為：企業網D1Net，如果不注明出處，企業網D1Net將保留追究其法律責任的權利。