人工智能可以遵循您的指示，但仍然無法像您一樣調試問題。

譯自Why AI Can't Fix Your Production Issues，作者 Siddarth Jain。

生成式 AI和大型語言模型 (LLM) 顯著提高了各個行業和領域的生產力，從營銷到工程。作為一名早期創始人，我個人發現它們在日常工作流程中非常有用，從創建管理文檔模板到協助代碼語法。

關于 AI 如何取代工程師，已經有了很多討論，包括一篇關于為什么 AI 無法取代工程團隊的StackOverFlow博客文章。在這篇博客中，我將闡述為什么我認為 AI 雖然是一個很棒的生產力增強工具，但無法為當今的輪班工程師和 SRE 調試生產問題。

圖片

LLM 的實際應用：

充當助手的 AI 工具在整個生命周期中都非常有用。以下是我使用它們的幾個例子：

代碼生成/檢測：

LLM 是獲取函數或任務的樣板代碼的好方法。雖然我最終會重寫大部分代碼，但我確實喜歡不必從頭開始，而是從某個點（比如 30%）開始的體驗。

• Github CoPilot
• Terraform 生成器 —https://github.com/gofireflyio/aiac這里有一篇最近的博客關于用戶使用 LLM 進行 Terraform 生成/更新的體驗。

自然語言到命令

我發現 Warp 的自然語言到命令生成器非常有用，而不是使用 chatGPT 來查找新命令。但對于我第一次做的事情，或者如果我知道一個命令，我非常不愿意使用自然語言模式。它幫助我自然化并加速學習曲線，以學習語法/語言。

• k8sGPT
• Warp.Dev

我的背景

我對機器學習的經驗始于我甚至沒有將我的工作稱為機器學習的時候。作為一名 2015 年的年輕開發者，我花了一個夏天時間開發一個利用 OpenCV 對數百萬份離線文檔進行數字化和解析的應用程序。從那時起，我在各種角色中涉足了監督/無監督學習、約束優化問題、預測和 NLP。

在過去的幾年里，我一直是 Doctor Droid 的聯合創始人，這是一家專注于解決輪班工程師生活中挑戰的公司。

工程師對生產事件監控中 AI/ML 的期望：

作為一名創始人，我向其他開發者推銷不同的原型，以解決他們在“可觀察性”生命周期中遇到的部分問題。在向用戶推銷時，我經常發現，每當提到以下任何用例時，工程師的興奮程度都會格外高：

• 在事件發生之前預測/預報事件
• 異常檢測，無需配置即可獲得警報
• 使用 AI 自動調查事件

自然地，我構建了原型和工具，試圖解決其中一個或多個用例。

在我深入探討原型之前，我想分享一下我對調試的看法。

CAGE 框架用于調試和生產調查

這個框架的靈感來自于我在之前工作中的工程經驗以及與 Doctor Droid 開發人員的互動。我意識到，調試通常歸結為四件事：

上下文：

這指的是關于您的產品做什么、客戶如何與之交互、基礎設施如何映射到服務、功能等等的部落知識。您的客戶投訴可能無法客觀地轉化為特定的基礎設施組件。如果沒有能夠將問題/用例轉化為正確的上下文，即使是團隊中現有的開發人員也很難解決生產問題。

圖片

分析性思維

工程師被期望提出假設，并使用相關性和因果關系來驗證/反駁這些假設。關聯時間線和異常（通常通過肉眼觀察發現）是需要工程師進行部分分析性思維的技能——無論是觀察指標并評估它是否是異常，還是觀察異常并思考其他可能受到影響的東西（使用他們的部落知識）。

圖片

目標定義：

工程團隊的運營高度依賴于組織的業務承諾和需求。僅僅擁有分析性思維是不夠的。去年，我們正在構建一個分析平臺- 即使在部署時只有四個服務，我們也產生了 2000 多個指標，涵蓋了我們的基礎設施和應用程序（有關此應用程序的更多信息，請參見下一節）。

如果我們運用分析性思維來評估所有這些指標以進行警報，這對我們團隊中的任何人都沒有意義。因此，我們定義了 SLO 和按優先級排列的指標細化，以便我們能夠優先處理它們。這對于幫助值班工程師了解何時以及需要升級/調查/降級至關重要。

熵估計：

生產中的問題通常具有級聯的生命周期，包括問題發生前和問題發生后：

• 問題發生前：問題可能是由一個組件行為的一系列“意外”變化引起的（例如，此 Loom 事件），級聯到更多組件。
• 問題發生后：在嘗試應用修復/補丁時，輕微的故障或不準確的嘗試（例如，此 AWS 事件）可能會進一步升級問題。

工程師預計即使在穩定后也要保持完全活躍，以防系統熵可能增加。

實驗和學習：

以下實驗是在 Kenobi 的生產系統上進行的，Kenobi 是 Doctor Droid 在 2023 年構建的實時分析平臺。以下是平臺的架構：

圖片

該平臺（以其當前形式）有四個微服務，大約五位開發人員花了六個月的時間才構建出來。該平臺每天處理 20-3000 萬個事件，這些事件來自不同的來源，并在不到 10 秒的時間內將其提供給 UI 和警報評估進行查詢。您可以在此處閱讀有關該平臺的更多信息。

實驗 1：AI 調查助手

定義此實驗的目標：

• 輸入：系統中觸發了警報
• 輸出：值班工程師用來調查/修復問題的調查運行手冊
• 該工具解決的問題：缺乏運行手冊/指南，導致調查延遲。

解決方案：

原型的工作原理如下：它從 Slack 接收每個警報的 webhook。然后，原型分析警報的上下文，并嘗試通過利用用戶可用的上下文信息來推薦最相關的步驟。

以下是用于“上下文”的數據源：

• 團隊的內部值班 SOP（視情況而定）
• 添加了特定平臺中可用于調試的指標和數據源的上下文。

圖片

關于如何在微服務應用程序中調試問題的思維模型

圖片

結果：

圖片

表面上看，實驗的輸出質量看起來不錯。但是，一旦您在生產環境中對其進行測試，或者將其提供給試圖進行調查的人，值班工程師最終會遇到以下問題：

1. 通用建議：- “檢查 CloudWatch 上相關基礎設施的指標”是一個通用的建議，除非開發人員確切地知道哪些組件最相關，否則它可能意味著許多指標。
2. 錯誤的建議：- 在其中一個步驟中，建議檢查 ELK/Kibana 中的日志，但 Kibana 不在團隊的堆棧中。
3. 置信度低的補救措施：- 補救措施通常需要相關數據的支持，而當前的方法無法做到這一點。鑒于建議的通用檢查數量，在廣泛的指標上運行異常檢測的 ML 模型也不切實際。

雖然這些建議感覺是一個令人興奮的開始，但我們意識到，值班工程師通常更喜歡以下方法來縮短調試問題的時間：

• 按照文檔/運行手冊中的步驟“逐字逐句”進行
• 將其提升給可能與該問題密切相關的工程師/團隊

有了這個經驗教訓，我們決定將重點從智能轉移到為自動化提供框架。

實驗 2：開源框架，用于自動化生產調查（可選的 AI 層）

目標：

• 輸入：用戶配置其可觀察性工具及其調查運行手冊
• 輸出：當收到警報時，劇本將自動觸發，然后團隊將收到分析結果，作為對原始來源（Pagerduty/Slack/Teams 等）中警報的豐富。
• 該工具解決的問題：值班工程師需要手動調試問題，這通常會導致升級到其他工程師。

結果：

這個框架提高了參與用戶的開發效率，最高可達 70%。除了數據之外，我們還有一些額外的學習：

• 對確定性結果的偏好：鑒于在值班時提出的問題至關重要，并且存在升級或業務損失的風險，工程師更喜歡確定性結果而不是概率性結果。
• 對手動配置的抵觸：鑒于該框架依賴于用戶的調試步驟/過程，一些團隊在手動配置運行手冊方面存在挑戰，因為他們擔心這很耗時，并且重復出現的問題通常是自動化的。
• 僅在某些情況下適用：探索性問題需要用戶超越框架。

實驗 2 中的人工智能使用：

(a) 從文檔生成劇本：我們編寫了一個小型代理，它讀取現有文檔并將其映射到集成工具。該工具的目標是減少配置劇本的工作量。

此輸出類似于之前提到的關于 Terraform Generator 的博客——它仍然不是自動模式，需要用戶審查和迭代。

(b) 從數據生成摘要

此摘要器幫助用戶首先閱讀最相關的要點，而不是手動瀏覽所有數據。

如您所見，這些是輔助實現，高度依賴于中心框架。

利用 AI/ML 進行可觀察性的實際用例

AI/ML 在可觀察性領域帶來了很多機會，但它們將針對特定/狹窄的上下文設計。“生產調試”的范圍很廣，但以下列舉了三個范圍更窄的示例，這些示例是 AI/ML 今天正在使用的：

1. 調查的摘要和分類：

• 創建一個 AI 層，分析自動化框架提取的數據并將摘要發送回工程師，可以減少他們調查問題的時間。
• 多家企業已在內部實施了此功能。微軟有一篇關于此的論文，討論了他們的產品 RCACoPilot（雖然名稱是 CoPilot，但該工具在調試/調查方法上非常確定性，并且僅依賴于 LLM 進行摘要和事件分類）。

圖片

（收集階段的“處理程序”是針對每個警報/事件的用戶編寫的運行手冊。）

2. 部署監控和自動回滾：

• 在預測與異常檢測的實現中，一種常見的用例是在部署語境中，因為它們通常是問題的來源且是眾所周知
• 這種方式已被多家企業采用；以下是兩個公開已知的企業：Slack 和 Microsoft。

圖片

3. 警報分組和降噪：

• 將上下文縮小到僅警報有助于在平臺內實現智能。以下是一些 AIOps 平臺（今天）可以在用戶警報數據之上提供的智能見解：

根據標簽、時間和歷史記錄對警報進行分組和關聯。

分析警報頻率以了解它是否是一個嘈雜的警報。

結論

經過所有這些實驗和原型設計，我得出兩個主要結論：

• 即使是微不足道的采用也需要比定制配置系統的現狀少得多的噪音。
• 從第一個結論繼續，開箱即用地達到這些低噪聲閾值并不常見。優化它們通常需要為每個團隊/用例進行大量定制工作。

因此，您會看到許多工具和平臺在其可觀察性堆棧中利用 AI/ML，但它可能會局限于特定范圍，在這些范圍內協助工程師，而不是成為“工程師的全面替代”。