AIOps 在汽車產業的正確應用

AIOps在汽車產業的正確應用 由因果與預測AI所實現的自動化與精確答案 報告內容 介紹AI的承諾 介紹 第 1 章異常檢測與警報 AI的承諾 AI正在推動企業軟體¹的下個創新週期，使其實現新層次的智慧型自動化與垂直集成。隨著現今企業系統規模的不斷擴大，數位化和雲端運算的優勢與技術複雜性和營運風險相伴而生。AI驅動的軟體智慧承諾能解決這些挑戰，並實現新世代的自動化雲端企業系統。 第 2 章獲得最佳監控資料 第 3 章AI營運與根源分析 對數位化程度高的客戶而言，他們很注重客戶體驗，這也對汽車產業公司造成了越來越大的壓力。事實上，客戶對於完美體驗的需求正在推動汽車產業的創新，而能夠提供卓越客戶體驗的公司則會在競爭中展現無與倫比的優勢。 第 4 章影響分析與基礎根源 第 5 章自動化補救第 6 章自動化與系統集成 1AI Technologies——《William Blair Industry Report》，2018年6月28日 超越檢測錯誤，實現自我修復 AI的承諾 想像這個似曾相似的挑戰：基於微服務的大型應用程式中出現的異常，導致全球範圍內的服務都影響，大量警報不斷出現。您的應用程式實際上包含數百萬計的依賴關係，您該如何找到原始的錯誤？傳統的監控工具並沒有太大的幫助。這些工具會收集指標並產生警報，但卻很少告訴您最一開始究竟發生了什麼問題。 藉由將一切自動化，實現自動化營運、促進創新並提供與客戶互動的新型態方式。 根源分析 智慧DevOps 相較之下，想像一個能提供精準「答案」的智慧系統，而這些答案通常是異常的技術根源與修復問題的解方。若這樣的智慧準確而可靠，則可信任它會在大部分使用者注意到故障之前，就觸發自動化補救程序。 以準確而可靠的根源分析取代不斷出現的大量嘈雜警報。 透過智慧效能與迴歸測試，提高創新速度與軟體品質。 AI與自動化正處於即將徹底改變營運領域遊戲規則的臨界點。這可不僅限於單一環節，而是貫串了整個數位化價值鏈。從軟體開發到服務遞送，再到與客戶的互動，每個環節都可以透過收集與智慧應用的方式改進。智慧集成與自動化即將推動企業軟體的下個創新週期。 智慧客戶互動 自動化補救 利用智慧資料以改善客戶體驗，包含對故障與投訴的自動化補救。 依據系統健康狀況和真實的使用者需求，執行異常補救與效能最佳化。 在AIOps具可靠的成績紀錄 Dynatrace協助全球頂尖組織簡化雲端複雜性，並加速數位化轉型。Dynatrace平台的核心是因果AI引擎「Davis」。與依據相關性實行的機器學習方式不同，Davis的設計目標為處理現代雲端環境的複雜性。Davis會即時處理數兆的依賴關係，持續監控系統全棧的系統退化與效能異常，並提供精確答案。會依據業務影響優先考量這些答案，並確定問題根源。這使得開發、IT、安全性與業務團隊能花費更少的力氣在故障排除之上，有更多時間去創新與實現改革性的業務結果。 「Dynatrace聽起來很不賴，但它不僅兌現了所有承諾，甚至還做得更多。我們能完全掌握使用者體驗，還能在信心滿滿的情況下加快軟體的創新與遞送速度——Dynatrace真的對我們走上成功的數位化之路大有幫助。」 如何變得更靈活並改善使用者體驗 Porsche Informatik意識到，若想變得真正靈活，就必須具備完全不同的效能監控與管理方式。在評估市場後，它選擇了Dynatrace，因為Dynatrace能針對IT環境的每一層提供完整的可見性，還能即時觀察與分析使用者對話，同時給予所有雲端平台與服務相應的原生支援。 ——Porsche Informatik總經理暨數位長Manfred Immitzer 第 1 章 異常檢測與警報 見解 自動化營運的概念環繞著如何執行更佳的故障排除之上，最終目標是減少平均恢復時間(MTTR)。而這能透過自動異常檢測與警報，也就是快速平均發現時間(MTTD)去實現。然而，如欲進一步減少MTTR時間則需要執行自動根源分析。 挑戰 傳統監控工具專注會注重在應用程式效能指標與基準方式之上，以區別正常與故障行為的差異。定義異常閾值是棘手的任務，需要進階統計學如機器學習的協助。然而，即使是最優質的基準方式也不足以應對雲端的需求。 在現代的微服務架構之下，單一的故障可能會影響多重連接的服務，這些服務隨後也會跟著故障。因此，單一問題會觸發多重警報。我們稱之為「警報風暴」或嘈雜警報。 傳統監控解決方案無法解決這個問題。仍必須由人類操作者去理解警報涵義。問題分類變成了耗時且時常令人沮喪的過程，通常必須組成專門的應對團隊並花費漫長的時間解決。 找到可靠方式自動確定潛在的根源是非常重要的事。 微調基準的確會有所幫助，但卻無法解決警報風暴的問題。若想真正解決，我們必須跳脫框架，直接嘗試找到潛在的根源。 減少警報噪音有兩種非常不同但皆需透過AI實行的方式： 使用故障樹分析的確定性AI 預測至2026年，汽車產業中的人工智慧(AI)市值會超過一百二十億美元。 ——《Marketwatch》 •確定性AI通常用於執行安全工程時使用的逐步故障樹分析 • 在幾近即時的狀態下運作•輕鬆可視化結果，以精確查明根源並協助您了解影響 •機器學習AI會採用將資料在同一個多維模型相互關連的統計方式 •構建這樣的模型需要時間，也會在動態環境下延遲 •需要人類詮釋以確定根源 第 2 章 獲得最佳監控資料 挑戰 見解 完整的系統可見性是自動化營運的必要前提，包含可靠的自動化補救。我們不僅需要對應用程式的全面見解（包含容器與功能即服務），還要具備對所有雲端基礎設施、網路、CI/CD途徑與真實使用者體驗層級的見解。在許多情況下，資料收集本身是免費的，因為所有的主要雲端提供商都會提供監控API，且開源工具也非常豐富。然而，以下考量也很重要： 在不同監控工具的環境下，營運人員必須理解來自各種來源的多種不同輸入資料意義。如此提高了在態勢感知與診斷中出錯的可能性。目前，僅有5%應用程式受到監控。²目標是達成全面的端到端可見性。 某家大型汽車製造商解決問題所花費的時間只剩下過去的20%。 •檢測與部署更新時需要執行多少手動操作？•監控代理是否能自動整合至短暫運作的功能或容器元件中？當組態改變時，是否還需要額外執行手動檢測？• 指標為粗略抽樣還是具高逼真性？•是否具足夠的中繼資訊與環境以構建統一的資料模型？ 環境具豐富的資料 若要完成真正的根源分析，所收集的資料必須具高逼真性（執行最低程度的抽樣或完全未抽樣）且環境豐富，以創造即時的拓撲圖與服務流程圖。 服務流程圖 拓撲圖 服務流程圖會提供一種交易視圖，說明從單一服務或申請角度出發的服務呼叫順序。服務流程圖顯示整個交易的逐步順序，而拓撲圖則是更高層次的抽象圖，僅顯示一般依賴關係。服務流程需要具高逼真性的資料，必須執行最低程度的抽樣或完全未抽樣。 拓撲圖會捕捉並讓整體應用程式環境可視化。這包括垂直堆疊（基礎設施、服務與流程）與水平依賴關係（即所有進出的呼叫關係）。最佳的監控解決方案會提供自動發現新環境元件與近乎即時的更新功能。 第 3 章 AI營運與根源分析 見解 未採用AI的企業將面臨不可能完成的任務。隨著企業採用混合的多雲環境，巨量的資料與複雜的環境對於人類而言非常難以監控、理解與採取行動。 挑戰 「Dynatrace是我們部署過的最佳解決方案 我們正迅速進入一個新的時代中，而人類將不再是解決IT問題或進行程式碼部署的主要行動者。雲端與AI解決方案環繞著自動化，所以未來的DevOps不會像現在一樣需要這麼多的人工干預。為了使AIOps（真正的自動化雲端營運）完美運作，我們需要的系統不只必須識別出錯誤，還要能精確查明真正的根源。 之一；給出了我們所有問題的答案。」 未採用AI的汽車公司將面臨不可能完成的任務，最終將消亡。隨著汽車產業採用混合的多雲環境，巨量的資料與複雜的環境對於人類而言非常難以監控、理解與採取行動。 ——U-Haul軟體開發總監Brian Rutherford 現代高度動態的微服務架構運作在混合的多雲環境中。基礎設施與服務可以隨著系統負載的需求，迅速啟動或關閉。確定異常根源所需耗費的心力遠超乎人類所能承受的範圍。 運用確定性AI找出根源 Dynatrace的AI引擎「Davis」使用應用程式拓撲與服務流程圖，再配合具高逼真性的指標以執行故障樹分析。故障樹會展現出現警報的所有垂直與水平拓撲依賴關係。請參考以下右側圖表中的可視化範例。 1.網頁應用程式表現異常，例如回應速度減緩（請見圖片左上）。 2.Davis先「檢查」下方的垂直堆疊，發現一切正常，沒有問題。3.從這裡開始，Davis就追蹤了所有的交易，並檢測到服務1的依賴關係也表現出異常。此外，所有進一步的依賴關係（服務2與3）也表現出異常。4.自動化根源檢測包含如範例所示的所有相關垂直堆疊，還會對造成問題的因素執行排序，以確定哪個因素對系統有最負面的影響。5.在這個範例中，其根源為其中一台Linux主機的CPU飽和。 確定性AI能自動並準確地確定技術異常的根源。這是實現真正AIOps的必要條件。我們會在下個部分更深入探討自動化補救的必要條件。 理解問題發展 確定性故障樹分析能產生精確、可解釋的結果。這種方式可用於逐步重現問題發展與解決過程，並在拓撲圖中可視化受影響的元件。這是一個非常強大的功能，因為它讓DevOps團隊能從一開始就更深入了解問題，將分類和研究的時間降到最低。 問題發展資料是自動化補救的關鍵。由於此功能可透過應用程式介面(API)進入，因此可觸發一系列的補救步驟解決問題，這種解決方式像外科手術一樣精準，且速度快到沒有任何人類操作者能做到。 第 4 章 影響分析與基礎根源 影響嚴重性 並不是所有的消失容器或主機都算是問題，而無人使用的緩慢服務也不需要立即關注。因此，進階軟體智慧系統能評估問題的嚴重性： 見解 在現代動態的微服務應用程式中，基礎設施與服務會視需求以迅捷無比的速度啟動與關閉。對健康的系統而言這樣是正常的表現。 使用者影響 消失的容器可能是為了最佳化資源而故意引發的事件，但也可能是意外中斷的徵兆，必須立刻執行緩解措施。AI必須能夠區別異常與刻意為之的改變間的差異。 有多少使用者在受檢測問題發生後受到了影響？在理想情況下，此數字應依據真實的使用者呈現，而不是對歷史資料進行外插法處理。 挑戰 受影響的服務呼叫 系統的某些部分並不是為人類互動而設計的。在這種情況下，受影響的服務呼叫數量是衡量嚴重性的良好指標。 對自動化補救而言，精準而可靠地確定技術根源非常重要，但僅僅是這樣還不夠。我們還需要衡量異常嚴重性的方式，以及能判別最初導致技術根源的跡象。 業務影響 隨著軟體智慧解決方案漸漸遍及企業的端到端，範圍從使用者操作到基礎設施都囊括其中，便有了將系統效能映射至關鍵績效指標(KPI)的可能。例如零售商可以在系統運作緩慢期間評估銷售金額，並與過去的參考時間框架進行比較。 2個應用程式：使用者操作時間變長 基礎根源 在11月8日06:58至07:54檢測到問題753（問題發生至結束歷時56分鐘）。此問題影響真實使用者。 技術根源會確定故障對象。 654998400已分析差異 基礎根源會具體說明故障原因。 以下為典型的基礎根源： 根源 業務影響分析 •部署：運用CI/CD工具鏈收集指標與事件，並實現問題與特定部署的相互關聯（並在需要時執行回溯）。•第三方組態變化：這可能與潛在雲端基礎設施或第三方服務的變化有關。•基礎設施的可使用性：在許多情況下，主機或單一程序的關閉或重啟會導致問題出現。 依據我們的依賴關係分析來看，所有事件皆有相同的根源。 對問題開始後前十分鐘的受影響服務呼叫和真實使用者進行分析，顯示出以下潛在影響。 查看目標客製化服務 1.17k受影響使用者 回應時間變長 目前的回應時間（19.6秒）超過自動檢