概述

基于人工智能的操作 （AIOps） 是人工智能和傳統 AM/IM 操作的融合。與所有其他領域一樣，AI 將對運營管理產生重大影響。當 AI 的電源應用于操作時，它將重新定義應用程序和支持應用程序/基礎結構的管理方式。

多個應用程序同時運行可生成大量數據。數據從網絡層直接生成到 API 調用對最終用戶的延遲。用戶期望獲得應用程序體驗，而不會出現絲毫的性能中斷。

可以從堆棧的不同層獲取數據，這成為推斷見解的豐富來源。操作的復雜性導致了算法 IT 操作 （AIOps） 平臺的創建。平臺解決方案使用 AI 和 ML 從監控數據中獲得見解，并通過增強人工決策來推動自動化解決方案。

重要用例和解決方案

應用程序監控

應用程序指標跟蹤響應時間、請求/分鐘、時間刻度加班錯誤率以及識別其行為趨勢等內容。此外，還捕獲了 CPU 利用率、內存利用率和負載平均值等基礎結構指標，以了解基礎結構層如何支持以滿足應用程序的不同負載條件。隨著應用程序復雜性的增加，很難從預期模式檢測異常。如果被忽視，這些異常可能會導致潛在的中斷。

解決 方案

可以在不同作用域（包括應用程序級別、服務級別、事務級別和外部依賴項）分析和發現更改模式。首先，確定什么構成正常的系統行為，然后辨別與正常系統行為的背離。AIOps 可以通過精確定位源來準確突出顯示這些異常值，這有助于實時更好地實現 RCA。此外，它還可以防止潛在的中斷和基礎結構中斷。

事務跟蹤

業務事務范圍從點對點應用程序連接之間的簡單同步消息交換到更復雜的異步通信。要跟蹤事務，需要流一個復雜的跟蹤和監視解決方案。長時間運行的多步異步事務傳輸 IT 基礎架構，跨越多種技術、層等。

解決 方案

復雜的交易經常變形和拆分，從而通過標記或統計采樣技術挑戰標準跟蹤和分析。通過檢查方法調用和單個消息有效負載內容，關聯它們并呈現任何掛起或現有行為和性能中的違規的直觀可視化，將事務拼接在一起

本地化缺陷

管理軟件質量是軟件開發生命周期中的一大問題進入生產環境之前，識別和修復缺陷非常重要。生產中發現的任何缺陷都會產生巨大的成本。在此上下文中，查找 Bug 被認為是最耗時且最具挑戰性的活動，因為可用資源有限。因此，在軟件工程中需要全/半自動化技術來增強手動調試過程。如果開發人員獲取了一些提示，其中 Bug 可能被本地化，則調試將變得更加高效

解決 方案

各種圖形挖掘算法/技術可用于本地化軟件缺陷。這些技術依賴于檢測故障和傳遞跟蹤之間的區分子圖。當故障未以罕見的代碼模式顯示時，這些方法可能不適用。另一方面，許多方法側重于選擇可能有缺陷的程序組件（語句或謂詞），然后根據這些組件的可疑程度和執行跟蹤上下文根據控制流圖對它們進行排名

到達基線

性能基準確定應用程序和基礎結構的組件在不同的負載條件下的性能。負載條件為”正常”、”操作”、”準”、”應力”、”峰值”、”斷點”等，基線是一組規則或閾值，用于單個指標的閾值，預計在上限和下限之間有所不同。傳統上，這些關聯是通過在收集在定義的時間間隔內收集的性能數據并實時部署以在發生任何性能偏差時通知的性能數據后運行機器學習算法來建模的。這種方法非常適合組件，但與現代開發方法的”相關性”點無效。

解決 方案：

超融合基礎架構管理、域驅動應用程序開發、分布式計算激增、多態編程和持久性的影響改變了軟件組件的開發和部署方式。需要不斷在動態擴展/縮小的基礎基礎架構之上部署軟件組件的頻繁更改。這種范式轉變強制模型構建練習使用近實時數據，以保持與應用程序和基礎結構組件中的最新更改相關。這些模型需要使用實時源來學習新規則并不斷發展。

預測問題

APM 中的智能警報是動態檢測異常。要使警報具有智能性，該工具需要可配置以了解應用程序的性質及其行為，以便它可以檢測異常。定義靜態閾值很常見;例如，如果此服務呼叫需要三秒鐘以上才能返回，則引發警報。但是，識別要監視的重要指標及其針對不同應用程序使用模式的閾值是非常繁瑣的，因此需要智能方法來基準應用程序的正常性，并在出現異常行為時發出通知如今，工具足夠智能，可以了解應用程序的行為并建立基線，允許您定義在分析基于基線的請求時要使用的策略，并在存在需要查看的實際問題時智能警報。

責任編輯：ct