譯者 | 劉汪洋

審校 | 重樓

想象一下，完全沉浸在編程氛圍中，甚至忘記了代碼的存在。不用敲鍵盤，只需讓 Cursor 和 Sonnet 幫你搞定一切。遇到 bug 時，你不去排查問題，而是把錯誤信息丟給大語言模型（LLM ）然后復制粘貼修復方案。代碼已經超出你的理解范圍，但它居然還能正常運行。這就是 OpenAI 創始成員 Andrej Karpathy 所說的Vibe Coding（氛圍編程）。

Karpathy 把這描述為周末小項目的有趣嘗試，但現實中，Vibe Coding——大量依賴 LLM 編寫代碼——已經大范圍出現。谷歌報告 AI 生成了其 25% 的新代碼，在行業的許多領域，這個比例可能更高。很多人爆料說，包括 HubSpot 在內的公司里的軟件工程師已不能自己寫代碼，只能通過提示詞指導 LLM。我認為，Vibe Coding 是構建軟件的未來。

但當 AI 生成的代碼在生產環境中出 bug 導致服務中斷時會怎樣？接下來，我來探討這個問題，并分享一些讓你的工程團隊做好準備的想法。

Vibe Coding 很有趣，但遇到服務中斷就沒那么好玩了

擁有熟悉代碼庫的技術高手至關重要。強大的工程組織會通過在團隊成員間共享知識，確保沒有工程師成為單點故障。

故障發生時，通常會找來了解受影響部分的工程師快速解決問題。但隨著越來越多的代碼由 LLM 生成，深入理解代碼庫的工程師會越來越少，這會讓服務中斷更難診斷和修復。

加州大學伯克利分校的博士生 Shreya Shankar 在一條廣受關注、瀏覽量超過 3 億的每分鐘 14,000 美元，團隊可不能在解讀 LLM 寫的代碼上浪費時間。

Vibe Coding 遇上Vibe 故障處理

AI 生成的代碼不會消失，有 61% 的工程團隊正在使用生成式 AI，這一趨勢只會更強。下面是如何為未來的故障管理做準備。

先用 AI 驅動的故障管理工具，比如 Rootly 或 PagerDuty Advanced。這些工具負責處理故障的后勤工作——自動創建溝通渠道、為不同相關方起草更新，并管理事后分析。它們也開始用 AI 將當前故障與歷史案例匹配，幫你快速找到類似情況及解決人員，從而縮短平均解決時間。

接著，升級你的故障修復方式。如果能用一個工具精確找出根本原因并提出修復方案，會怎樣？這正是新一代 LLM 驅動的故障解決工具，也就是 AI-SRE 助手，像 Sentry AI 和 Datadog Bits AI正在做的事情。

這些工具處理 SRE 通常會處理的數據——錯誤日志、指標、應用跟蹤...同時還攝取非結構化的人工生成數據，如 Slack 討論、操作手冊和事后分析。它們能快速自動分析根本原因，突出顯示觸發問題的提交，可視化其對系統指標的影響，并追蹤導致服務中斷的故障鏈。這樣，當值班人員接到通知打開電腦時，根本原因分析已經擺在眼前了。

更厲害的工具不僅診斷問題，還提出解決方案。你可以在部署前審查、討論和批準修復方案，或者讓工具自動處理一切。可以理解，一些運維工程師對此持懷疑態度。如果 LLM 出現幻覺給出一個讓情況變得更糟的修復方案怎么辦？如果沒有回滾功能怎么辦？灰度部署變更可以降低風險，但這只是眾多考慮因素之一。AI 驅動的故障解決方案很有前途，但也帶來了一系列新挑戰。

不過，自愈工具并不新鮮：它們至少已存在十多年了。Facebook 在 2011 年引入了 FBAR 來自動化機架維護。Dropbox 在 2016 年推出了 Naru 來處理服務器故障、警報和修復。但這些是基于預定義規則的確定性系統，顯著降低了出錯的可能性。

在 LinkedIn 擔任高級 SRE 期間，我共同設計了一個用于分布式基礎設施的自愈機制，該機制用機器學習進行根本原因分析和修復，盡管它從未完全實施。隨著 LLM 的興起，這種方法正在成為現實，我很興奮能親眼見證。這一領域的公司正在取得實質性進展。競爭越來越激烈。市場上至少有 20 家參與者，風投資金源源不斷涌入。進入 Vibe 故障處理時代！沒錯，這個詞是我剛編的。

打不過就加入

隨著生成式 AI 給開發人員的工作效率帶來顯著提升，這一趨勢還越發明顯。那么為何不擁抱 Vibe 故障處理呢？當服務中斷發生時，只需悠閑地喝杯咖啡... 讓你的 AI-SRE 助手想辦法修復你那些 "Vibe Coding" 同事的 bug 吧。

譯者介紹

劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 Java 工程師。

原文標題：Vibe Coding Is Here — But Are You Ready for Incident Vibing? ，作者：Sylvain Kalache