快速創新：BMW的生成式AI雲端事件分析解決方案

這篇文章由BMW集團的Johann Wildgruber、Dr. Jens Kohl、Thilo Bindel和Luisa-Sophie Gloger共同撰寫。

BMW集團總部位於德國慕尼黑，是一家擁有超過154,000名員工的汽車製造商，在全球擁有30個生產和組裝設施，以及17個國家的研究與開發地點。如今，BMW集團（BMW）是全球領先的高端汽車和摩托車製造商，並提供高端金融和移動服務。

BMW Connected Company是BMW的一個部門，負責開發和運營BMW連接車隊的高端數位服務，目前全球擁有超過2300萬輛車輛使用這些服務。這些數位服務每天被許多BMW車主使用；例如，透過手機應用程式遠端鎖定或開啟車門、遠端啟動窗戶除霜、從車輛菜單購買導航地圖更新，或在車內收聽網路音樂。

在這篇文章中，我們解釋BMW如何利用AWS上的生成式人工智慧技術來幫助運行這些數位服務，確保高可用性。具體來說，BMW使用Amazon Bedrock Agents來加快修復（部分）服務中斷的過程，縮短通常繁瑣且耗時的根本原因分析（RCA）流程。這個全自動的RCA代理在大多數情況下（達到85%的準確率）能正確識別根本原因，並幫助工程師理解系統和即時獲得洞察。這一表現也在概念驗證中得到了進一步驗證，使用RCA代理處理代表性用例清楚地顯示了這一解決方案的好處，使BMW能顯著降低診斷時間。

根本原因分析的挑戰

數位服務通常是通過將多個軟體元件鏈接在一起來實現的；這些元件可能由不同的團隊建造和運行。例如，考慮遠端開啟和鎖定車門的服務。可能有一個開發團隊負責iOS應用程式，另一個團隊負責Android應用程式，還有一個團隊負責iOS和Android應用程式共用的前端後端，等等。此外，這些團隊可能地理分散，在不同地點和區域運行他們的工作負載；許多在AWS上托管，其他則在其他地方。

現在考慮一個（虛構的）情境，車主報告說透過應用程式遠端鎖定車門不再有效。是iOS應用程式導致了中斷，還是前端後端？某個地方的防火牆規則改變了嗎？內部TLS證書過期了嗎？MQTT系統出現延遲了嗎？最近的API變更中是否有意外的破壞性變更？他們實際上什麼時候部署的？還是中央訂閱服務的資料庫密碼又被更改了？

在這種情況下，確定問題的根本原因可能很困難。這需要檢查許多系統和團隊，其中許多可能因為相互依賴而失效。開發人員需要推理系統架構，形成假設，並沿著元件鏈追蹤，直到找到罪魁禍首。他們經常需要回溯並重新評估假設，並在另一條元件鏈中繼續調查。

理解這種複雜系統中的挑戰突顯了對穩健高效的根本原因分析方法的需求。考慮到這一背景，讓我們探討BMW和AWS如何合作開發使用Amazon Bedrock Agents的解決方案，以簡化和增強RCA流程。

解決方案概述

從高層次來看，這個解決方案使用Amazon Bedrock代理進行自動化RCA。這個代理擁有多個自訂工具來完成其工作。這些工具由AWS Lambda函數實現，使用Amazon CloudWatch和AWS CloudTrail等服務來分析系統日誌和指標。以下圖表展示了解決方案架構。

當事件發生時，值班工程師會向Amazon Bedrock代理描述當前的問題。然後，代理將開始調查問題的根本原因，使用其工具執行值班工程師本來需要手動執行的任務，例如搜索日誌。根據它發現的線索，代理會向值班工程師提出幾個可能的假設。工程師可以解決問題，或給代理提供指導以進一步指導調查。在接下來的部分中，我們將更仔細地看看代理使用的工具。

Amazon Bedrock代理工具

Amazon Bedrock代理在執行RCA時的有效性在於其能無縫整合自訂工具。這些工具設計為Lambda函數，使用AWS服務如CloudWatch和CloudTrail來自動化通常對工程師來說是手動且耗時的任務。通過將其能力組織成專門的工具，Amazon Bedrock代理確保RCA既高效又精確。

架構工具

架構工具使用C4圖來提供系統架構的全面視圖。這些圖表通過Structurizr增強，讓代理對元件之間的關係、依賴性和工作流程有層次的理解。這使得代理能在RCA過程中針對最相關的區域，有效縮小潛在故障的原因，根據不同系統之間的互動進行分析。

例如，如果某個問題影響特定服務，架構工具可以識別上游或下游的依賴性，並針對這些系統提出假設。這加快了診斷過程，使代理能夠根據架構進行有針對性的推理，而不是盲目地搜索日誌或指標。

日誌工具

日誌工具使用CloudWatch Logs Insights實時分析日誌數據。通過搜索模式、錯誤或異常，以及將趨勢與前一時期進行比較，它幫助代理精確定位與特定事件相關的問題，例如身份驗證失敗或系統崩潰。

例如，在涉及資料庫訪問失敗的情況下，日誌工具可能會識別出與前一小時相比，“FATAL: password authentication failed”錯誤消息的數量出現新高。這一見解使代理能迅速將故障與潛在根本原因聯繫起來，例如資料庫密碼未正確更改。

指標工具

指標工具通過CloudWatch監控關鍵指標，為代理提供系統健康狀況的實時洞察。這個工具識別關鍵性能指標中的統計異常，例如延遲、錯誤率、資源利用率或使用模式的異常高峰，這些通常會發出潛在問題或異常行為的信號。

例如，在Kubernetes內存過載的情況下，指標工具可能會在故障之前檢測到內存消耗的急劇增加或資源分配的異常。通過顯示CloudWatch指標警報，該工具使代理能夠優先考慮與資源管理不當、閾值配置錯誤或意外系統負載相關的假設，更有效地指導調查以解決問題。

基礎設施工具

基礎設施工具使用CloudTrail數據分析關鍵控制平面事件，例如配置變更、安全組更新或API調用。這個工具特別有效於識別可能觸發連鎖故障的錯誤配置或破壞性變更。

考慮一個案例，其中安全組的進入規則不小心被刪除，導致服務之間的連接問題。基礎設施工具可以檢測並將這一事件與報告的事件相關聯，為代理提供可操作的見解以指導其RCA過程。

通過結合這些工具，Amazon Bedrock代理模擬了經驗豐富的工程師的逐步推理，同時以機器速度執行任務。這些工具的模組化特性允許靈活性和自訂，確保RCA符合BMW複雜的多區域雲基礎設施的獨特需求。

在下一部分中，我們將討論這些工具在代理工作流程中如何協同工作。

Amazon Bedrock代理：ReAct框架的實踐

BMW快速RCA的核心是ReAct（推理與行動）代理框架，這是一種創新的方法，動態結合邏輯推理與任務執行。通過將ReAct與Amazon Bedrock整合，BMW獲得了一個靈活的解決方案，用於診斷和解決複雜的雲端事件。與依賴預定工作流程的傳統方法不同，ReAct代理使用實時輸入和迭代決策來適應事件的具體情況。

BMW的RCA解決方案中的ReAct代理使用結構化但靈活的工作流程來診斷和解決問題。首先，它解釋事件的文字描述（例如，“無法通過應用程式鎖定車門”），以識別系統中最可能受到影響的部分。在ReAct框架的迭代推理指導下，代理然後通過調用專門的工具來收集證據，使用在跨帳戶可觀察性設置中集中聚合的數據。通過不斷重新評估每個工具調用的結果，代理能夠鎖定潛在原因——無論是過期的證書、撤銷的防火牆規則，還是流量激增——直到找出根本原因。以下圖表展示了這一工作流程。

ReAct框架提供了以下好處：

動態和適應性 – ReAct代理根據特定事件量身定制其方法，而不是一刀切的方法。這種適應性在BMW的多區域、多服務架構中特別重要。
高效的工具利用 – 通過推理何時調用哪些工具，ReAct代理最小化冗餘查詢，提供更快的診斷，而不會過載AWS服務，如CloudWatch或CloudTrail。
類似人類的推理 – ReAct代理模擬經驗豐富的工程師的邏輯思維過程，迭代探索假設，直到識別根本原因。這一能力彌合了自動化與人類專業知識之間的差距。

通過使用Amazon Bedrock ReAct代理，顯著降低了診斷時間。這些代理不僅提高了運營效率，還使工程師能夠專注於戰略改進，而不是繁瑣的診斷。

案例研究：根本原因分析“透過iOS應用程式解鎖車輛”

為了展示Amazon Bedrock代理的實際應用，我們來探討一個可能的現實情境，涉及BMW的連接車隊與運行在雲端後端的數位服務之間的互動。

我們故意在測試環境中更改中央網路帳戶的安全組。這樣的改變導致來自車隊的請求（正確地）被更改的安全組阻擋，無法到達後端的服務。因此，測試用戶無法遠端鎖定或解鎖她的車門。

事件詳情

BMW工程師收到測試者的報告，指出移動應用程式的遠端鎖定/解鎖功能無法正常運作。

這份報告立即引發了問題：問題出在應用程式本身、前端後端服務，還是系統更深層的地方，例如MQTT連接或身份驗證機制？

ReAct代理如何解決問題

問題被描述給Amazon Bedrock ReAct代理：“iOS應用程式的用戶無法遠端解鎖車門。”代理立即開始分析：

代理首先理解整體系統架構，調用架構工具。架構工具的輸出顯示，iOS應用程式和Android應用程式都連接到前端後端API，而前端後端API本身又連接到幾個其他內部API，例如遠端車輛管理API。遠端車輛管理API負責通過MQTT消息發送命令給汽車。
代理以有針對性的方式使用其他工具：它掃描與遠端解鎖車門相關的元件的日誌、指標和控制平面活動：iOS應用程式的遠端日誌、前端後端API日誌等等。代理發現了幾個線索：

指示連接問題的異常日誌（網路超時）。
遠端車輛管理API成功調用次數的急劇下降。
控制平面活動：測試環境中中央網路帳戶的幾個安全組被更改。

根據這些發現，代理推斷並定義了幾個假設，並將這些假設按可能性排序呈現給用戶。在這種情況下，第一個假設就是實際的根本原因：中央網路帳戶中的安全組不小心被更改，導致前端後端和遠端車輛管理API之間的網路流量被阻擋。代理正確地將日誌（“fetch timeout error”）、指標（調用次數減少）和控制平面變更（安全組進入規則被刪除）相關聯，得出這一結論。
如果值班工程師想要進一步的信息，他們現在可以向代理提出後續問題，或指示代理在其他地方進行調查。

整個過程——從事件檢測到解決——只花了幾分鐘，而傳統RCA方法可能需要幾個小時。ReAct代理的動態推理能力、訪問跨帳戶可觀察性數據的能力，以及對假設的迭代，使得繁瑣的手動調查變得不再必要。

結論

通過使用Amazon Bedrock ReAct代理，BMW展示了如何改善其根本原因分析的方法，將一個複雜且手動的過程轉變為高效的自動化工作流程。ReAct框架內整合的工具顯著縮小了潛在推理空間，並實現動態假設生成和有針對性的診斷，模擬經驗豐富的工程師的推理過程，同時以機器速度運行。這一創新減少了識別和解決服務中斷所需的時間，進一步提高了BMW連接服務的可靠性，改善了全球數百萬客戶的體驗。

這一解決方案已顯示出可衡量的成功，代理在85%的測試案例中識別了根本原因，並在其餘案例中提供了詳細的見解，極大地加快了工程師的調查。通過降低新手工程師的進入門檻，使得經驗較少的團隊成員也能有效診斷問題，保持BMW運營的可靠性和可擴展性。

將生成式人工智慧納入RCA流程展示了AI在現代雲端運營中的變革潛力。能夠動態適應、上下文推理和處理複雜的多區域基礎設施，使Amazon Bedrock Agents成為希望在數位服務中保持高可用性的組織的遊戲改變者。

隨著BMW繼續擴展其連接車隊和數位產品，採用像Amazon Bedrock這樣的生成式AI驅動解決方案將在保持運營卓越和為客戶提供無縫體驗方面發揮重要作用。通過效仿BMW的例子，您的組織也可以從Amazon Bedrock Agents中受益，以進行根本原因分析，增強服務的可靠性。

開始探索Amazon Bedrock Agents以優化您的事件診斷，或使用CloudWatch Logs Insights來識別系統日誌中的異常。如果您想要實際了解如何創建自己的Amazon Bedrock代理——包括代碼示例和最佳實踐——請查看以下GitHub庫。這些工具正在為高效的RCA和運營卓越設立新的行業標準。

關於作者

Johann Wildgruber是BMW集團的轉型領導可靠性工程師，目前正在設立一個可觀察性平台，以加強ConnectedDrive服務的可靠性。Johann在運營和開發大型複雜雲解決方案方面擁有多年經驗。他對在軟體開發中應用新技術和方法感興趣。

Dr. Jens Kohl是BMW集團的技術領導者和建設者，擁有超過13年的經驗。他負責塑造Connected Vehicle雲後端的架構和持續優化。Jens在嵌入式、分散式系統和機器學習方面領導軟體開發和機器學習團隊已有超過10年。

Thilo Bindel是BMW集團的Offboard可靠性與數據工程團隊的負責人。他負責定義和實施策略，以確保BMW在Connected Vehicle領域的後端服務的可靠性、可用性和可維護性。他的目標是確保整個組織一致地建立可靠性和數據工程的最佳實踐，並使BMW集團在汽車行業及其他領域成為數據驅動可觀察性的領導者。