譯自 How Generative AI Can Support DevOps and SRE Workflows 。
隨著關於大語言模型(LLM)和生成式AI的討論從熱烈上升到轟動一時，有遠見的軟體團隊戴上耳機，聚焦一個重要問題：我們如何讓這項技術立竿見影？
這看起來是天作之合，畢竟技術人員會喜歡新技術，不言而喻。 因此，儘管人力資源專業人員可能需要更長時間並更謹慎地考慮如何在工作中使用生成式AI，但開發者、網站可靠性工程師(SRE)和其他技術人員都非常適合嘗試並將生成式AI 工具應用於工作中。 例如，根據Stack Overflow的一項調查，70%的開發者已經或計劃使用AI改進工作。
問題仍然存在：我們該如何讓生成式AI發揮作用？
在可預見的未來，用例會不斷湧現，但對現代軟體團隊來說，根據PromptOps CEO兼創始人Dev Nag的說法，回答這個問題很大程度上歸結為溝通，PromptOps是一個面向DevOps和SecOps團隊的 基於生成式AI的Slack助手。
「我認為企業中的所有工作，特別是對DevOps工程師來說，其實就是關於溝通，」Nag告訴The New Stack。 “不僅包括人與人之間的溝通，也包括人與機器之間的溝通。”
Nag舉了Slack、Jira或Monday等工具作為例子，但他也將DevOps常見任務中查詢應用程式取得日誌、指標和其他數據，然後根據回應採取行動視為一種溝通形式。
他指出，儘管這種交流是必要的，但也可能重複且浪費時間，這正是生成式AI能發揮巨大作用的地方。
Nag說：“語言模型和生成式AI本質上是溝通的超級加速器。它們能夠從過去的數據中找到模式，在你表達想法之前就理解你的意圖。”
PromptOps最近推出了一款生成式AI工具，它可以透過類似ChatGPT的提示，自動化並優化各種DevOps工作流程，無論是直接在Slack還是網頁端。
Nag認為，生成式AI在DevOps、SRE和其他現代軟體團隊的應用潛力是幾乎無限的。 在接受The New Stack的採訪時，他分享了六個如今可以將生成式AI應用於DevOps工作流程的範例。
生成式AI工具的6個使用案例
查詢不同工具
DevOps和SRE專業人員經常使用海量工具。 在某些組織，技術「棧」更像一座高塔。
人工查詢眾多工具的日誌和各種可觀測資料既費時又費力，效率不高。 哪裡有該指標？ 看板在哪裡？ 機器名稱是啥？ 通常怎麼稱呼？ 通常會查看什麼時間範圍？ 等等問題層出不窮。
Nag：「這些背景資訊都曾由他人完成。」生成式AI 可以讓工程師用自然語言提示直接找到所需內容，通常還可以自動啟動後續工作流程，無需離開Slack(或其他客戶端)。
“這極大節省時間，因為我不用再掌握數十種工具。” Nag說，“我可以用英語下達提示，它就可以跨工具幫我完成任務。”
2. 發現額外環境
此外，生成式AI可以根據需要自動關聯額外環境，這也很有用。 所以，儘管可以在Slack(或其他地方輸入提示)直接產生所需響應或數據，但生成式AI還可以添加導航層，在適當的時候直接連結到該響應的全文或環境。
這在速度至關重要的情況下尤其有用，最典型的就是服務中斷事件。 回應事件每花費一分鐘都代價高昂。
Nag說：“任何任務如果投入足夠時間都可完成。但問題是我們沒有時間和人手，特別是在服務中斷場景，速度至關重要，務必盡快恢復客戶體驗。”
3. 自動化和快速執行必要係統操作
就像Kubernetes之類的編排工具因為能根據期望狀態自動執行系統操作而流行起來一樣，生成式AI也可以進一步簡化和加速工作流程中的必要操作。
Nag說，雲端原生工具和平台自己也帶來複雜性。 執行各種常見運維任務(如預配服務、管理配置、設定故障轉移)通常需要與其他元件互動。
「這些任務可能接觸許多API。例如AWS API就有200多種服務。」他說。
它們語法、控制台、命令列各不相同，子命令更是汗牛充棟——幾乎沒人會全部記住。 單就這一點，Kubernetes的學習曲線就令人生畏。
Nag說，要全面掌握雲原生生態的龐雜細節幾乎不可能。 有了生成式AI，工程師不需要記住各系統與工具的細節。
使用者只需下達「擴容Pod 2個副本」或「以某種方式配置Lambda函數」等提示。 我可以把它轉換為目標系統語言的實際程式碼，自動執行。 」 Nag說，「LLM幾乎像是這些非結構化資料與結構化資料之間的蟲洞。 」
4. 撰寫事件報告
眾所周知，生成式AI在內容創作方面有巨大潛力。 這也適用於系統故障值班人員編寫事後報告的場景。
Nag指出，這類報告通常需要查看大量Slack訊息、指標、圖表、日誌等資料。
他說，LLM「可以查看Slack對話——即使是50萬行也沒問題——並總結提取關鍵發現。」它專注相關數據，過濾無用資訊——極大節省人工匯總故障原因的時間。
這再次證明了「蟲洞」效應，可以將大量非結構化資訊轉化為可操作的結構化資料。
5. 建立事件
內容創作類別還包括Nag提到的與事件管理相關的用例：建立工單。 LLM可以在事件或其他IT事件觸發的工作流程中，自動在Jira、Monday等系統建立工單並啟動後續操作。
有時這些操作正是用例4中的事件報告結果：增強的事件報告可以確定如果事件再次發生要採取的更好做法。
“下次我要創建警報，可能還需要額外基礎設施等等。” Nag說，“我們可以實際掃描對話，並將其轉化為工單。”
6. 尋找非技術文檔
最後但同樣重要的是，Nag說，他們發現越來越需要一種方法，無需大量時間就可以發現和調閱非技術文檔，例如運行手冊或公司政策——不僅包括IT政策，還包括HR福利 等常見業務政策。
「你不一定知道這些文件的儲存位置。」他說，隨著組織規模擴大，尋找流程可能非常耗時。 類似ChatGPT的提示可以在幾秒鐘內找到所需內容，而不必在各種維基或工具中搜尋。
