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

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

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

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

圖片

LLM 的實際應(yīng)用：

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

代碼生成/檢測：

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

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

自然語言到命令

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

• k8sGPT
• Warp.Dev

我的背景

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

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

工程師對生產(chǎn)事件監(jiān)控中 AI/ML 的期望：

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

• 在事件發(fā)生之前預(yù)測/預(yù)報事件
• 異常檢測，無需配置即可獲得警報
• 使用 AI 自動調(diào)查事件

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

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

CAGE 框架用于調(diào)試和生產(chǎn)調(diào)查

這個框架的靈感來自于我在之前工作中的工程經(jīng)驗以及與 Doctor Droid 開發(fā)人員的互動。我意識到，調(diào)試通常歸結(jié)為四件事：

上下文：

這指的是關(guān)于您的產(chǎn)品做什么、客戶如何與之交互、基礎(chǔ)設(shè)施如何映射到服務(wù)、功能等等的部落知識。您的客戶投訴可能無法客觀地轉(zhuǎn)化為特定的基礎(chǔ)設(shè)施組件。如果沒有能夠?qū)栴}/用例轉(zhuǎn)化為正確的上下文，即使是團隊中現(xiàn)有的開發(fā)人員也很難解決生產(chǎn)問題。

圖片

分析性思維

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

圖片

目標定義：

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

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

熵估計：

生產(chǎn)中的問題通常具有級聯(lián)的生命周期，包括問題發(fā)生前和問題發(fā)生后：

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

工程師預(yù)計即使在穩(wěn)定后也要保持完全活躍，以防系統(tǒng)熵可能增加。

實驗和學(xué)習：

以下實驗是在 Kenobi 的生產(chǎn)系統(tǒng)上進行的，Kenobi 是 Doctor Droid 在 2023 年構(gòu)建的實時分析平臺。以下是平臺的架構(gòu)：

圖片

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

實驗 1：AI 調(diào)查助手

定義此實驗的目標：

• 輸入：系統(tǒng)中觸發(fā)了警報
• 輸出：值班工程師用來調(diào)查/修復(fù)問題的調(diào)查運行手冊
• 該工具解決的問題：缺乏運行手冊/指南，導(dǎo)致調(diào)查延遲。

解決方案：

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

以下是用于“上下文”的數(shù)據(jù)源：

• 團隊的內(nèi)部值班 SOP（視情況而定）
• 添加了特定平臺中可用于調(diào)試的指標和數(shù)據(jù)源的上下文。

圖片

關(guān)于如何在微服務(wù)應(yīng)用程序中調(diào)試問題的思維模型

圖片

結(jié)果：

圖片

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

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

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

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

有了這個經(jīng)驗教訓(xùn)，我們決定將重點從智能轉(zhuǎn)移到為自動化提供框架。

實驗 2：開源框架，用于自動化生產(chǎn)調(diào)查（可選的 AI 層）

目標：

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

結(jié)果：

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

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

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

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

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

(b) 從數(shù)據(jù)生成摘要

此摘要器幫助用戶首先閱讀最相關(guān)的要點，而不是手動瀏覽所有數(shù)據(jù)。

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

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

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

1. 調(diào)查的摘要和分類：

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

圖片

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

2. 部署監(jiān)控和自動回滾：

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

圖片

3. 警報分組和降噪：

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

根據(jù)標簽、時間和歷史記錄對警報進行分組和關(guān)聯(lián)。

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

結(jié)論

經(jīng)過所有這些實驗和原型設(shè)計，我得出兩個主要結(jié)論：

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

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