為什麼人工智慧無法解決您的生產問題
人工智慧可以遵循您的指示，但仍然無法像您一樣調試問題。
譯自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 年建立的即時分析平台。以下是平台的架構：
圖片
該平台（以其當前形式）有四個微服務，大約五位開發人員花了六個月的時間才建造出來。該平台每天處理2000-3000 萬個事件，這些事件來自不同的來源，並在不到10 秒的時間內將其提供給UI 和警報評估進行查詢。您可以在此處閱讀有關該平台的更多資訊。
實驗1：AI 調查助手
定義此實驗的目標：
- 輸入：系統中觸發了警報
- 輸出：值班工程師用來調查/修復問題的調查運作手冊
- 該工具解決的問題：缺乏運作手冊/指南，導致調查延遲。
解決方案：
原型的工作原理如下：它從Slack 接收每個警報的webhook。然後，原型分析警報的上下文，並嘗試透過利用使用者可用的上下文資訊來推薦最相關的步驟。
以下是用於“上下文”的資料來源：
- 團隊的內部值班SOP（視情況而定）
- 新增了特定平台中可用於偵錯的指標和資料來源的上下文。
圖片
關於如何在微服務應用程式中調試問題的思維模型
圖片
結果：
圖片
表面上看，實驗的輸出品質看起來不錯。但是，一旦您在生產環境中對其進行測試，或將其提供給試圖進行調查的人，值班工程師最終會遇到以下問題：
- 通用建議：- “檢查CloudWatch 上相關基礎設施的指標”是一個通用的建議，除非開發人員確切地知道哪些組件最相關，否則它可能意味著許多指標。
- 錯誤的建議：- 在其中一個步驟中，建議檢查ELK/Kibana 中的日誌，但Kibana 不在團隊的堆疊中。
- 置信度低的補救措施：- 補救措施通常需要相關數據的支持，而目前的方法無法做到這一點。鑑於建議的通用檢查數量，在廣泛的指標上運行異常檢測的ML 模型也不切實際。
雖然這些建議感覺是一個令人興奮的開始，但我們意識到，值班工程師通常更喜歡以下方法來縮短調試問題的時間：
- 請依照文件/運作手冊中的步驟「逐字逐句」進行
- 將其提升給可能與該問題密切相關的工程師/團隊
有了這個經驗教訓，我們決定將重點從智慧轉移到為自動化提供框架。
實驗2：開源框架，用於自動化生產調查（可選的AI 層）
目標：
- 輸入：使用者配置其可觀察性工具及其調查運作手冊
- 輸出：當收到警報時，劇本將自動觸發，然後團隊將收到分析結果，作為對原始來源（Pagerduty/Slack/Teams 等）中警報的豐富。
- 該工具解決的問題：值班工程師需要手動調試問題，這通常會導致升級到其他工程師。
結果：
這個框架提高了參與用戶的開發效率，最高可達70%。除了數據之外，我們還有一些額外的學習：
- 對確定性結果的偏好：鑑於在值班時提出的問題至關重要，並且存在升級或業務損失的風險，工程師更喜歡確定性結果而不是機率性結果。
- 手動配置的抵觸：鑑於該框架依賴於使用者的調試步驟/流程，一些團隊在手動配置運行手冊方面存在挑戰，因為他們擔心這很耗時，並且重複出現的問題通常是自動化的。
- 僅在某些情況下適用：探索性問題需要使用者超越框架。
實驗2 中的人工智慧使用：
(a) 從文件產生劇本：我們編寫了一個小型代理，它讀取現有文件並將其對應到整合工具。該工具的目標是減少配置劇本的工作量。
此輸出類似於之前提到的關於Terraform Generator 的部落格——它仍然不是自動模式，需要用戶審查和迭代。
(b) 從資料產生摘要
此摘要器可協助使用者先閱讀最相關的要點，而不是手動瀏覽所有資料。
如您所見，這些是輔助實現，高度依賴中心框架。
利用AI/ML 進行可觀察性的實際用例
AI/ML 在可觀察性領域帶來了許多機會，但它們將針對特定/狹窄的上下文設計。 「生產調試」的範圍很廣，但以下列舉了三個範圍更窄的範例，這些範例是AI/ML 今天正在使用的：
- 調查的摘要和分類：
- 建立一個AI 層，分析自動化框架提取的資料並將摘要發送回工程師，可以減少他們調查問題的時間。
- 多家企業已在內部實施了此功能。微軟有一篇關於此的論文，討論了他們的產品RCACoPilot（雖然名稱是CoPilot，但該工具在調試/調查方法上非常確定性，並且僅依賴LLM 進行摘要和事件分類）。
圖片
（收集階段的「處理程序」是針對每個警報/事件的使用者編寫的運作手冊。）
- 部署監控和自動回滾：
- 在預測與異常檢測的實作中，一種常見的用例是在部署情境中，因為它們通常是問題的來源且眾所周知
- 這種方式已被多家企業採用；以下是兩個公開已知的企業：Slack 和Microsoft。
圖片
- 警報分組和降噪：
- 將上下文縮小到僅警報有助於在平台內實現智慧。以下是一些AIOps 平台（今天）可以在用戶警報資料之上提供的智慧見解：
根據標籤、時間和歷史記錄對警報進行分組和關聯。
分析警報頻率以了解它是否是一個嘈雜的警報。
結論
經過所有這些實驗和原型設計，我得出兩個主要結論：
- 即使是微不足道的採用也需要比定製配置系統的現狀少得多的噪音。
- 從第一個結論繼續，開箱即用地達到這些低雜訊閾值並不常見。優化它們通常需要為每個團隊/用例進行大量自訂工作。
因此，您會看到許多工具和平台在其可觀察性堆疊中利用AI/ML，但它可能會局限於特定範圍，在這些範圍內協助工程師，而不是成為「工程師的全面替代」。