主動瞭解 Release利用人工智慧簡化流程 DevOps

下午2點17分，生產環境版本發布卡住了。 Slack上的討論串越來越多。有人打開了三個儀錶板。有人開始查看日誌。發布經理聯繫了唯一一個「真正了解這個模板運作方式」的工程師。

隨著企業軟體交付規模的擴大，發布自動化變得至關重要，但也日益複雜。模板透過重複使用和嵌套不斷加深，腳本也隨著時間的推移而不斷累積。 「解決方案」往往以經驗法則的形式存在。一旦出現問題，團隊就會浪費大量時間在螢幕上切換、關聯訊號和向上匯報問題，從而拖慢交付速度並增加營運風險。

主動瞭解 Release 改變團隊運作方式 Digital.ai Release 在關鍵時刻，它直接在內部引入了一個大型語言模型（LLM）介面。 Digital.ai Release使用戶能夠使用自然語言與平台進行互動。透過分析 Release 系統數據和對運行環境的理解，請詢問 Release 能夠立即提供答案，因此團隊無需在使用者介面中找到即可了解發布操作中發生的情況。

主動瞭解 Release：願景和出貨時間

主動瞭解 Release 旨在解決企業中一個簡單的現實問題：使用者無法快速獲得準確的、具有情境意義的答案。 Release 無需瀏覽多個螢幕和手動搜尋。此產品方向著重於利用以下方面的數據來回答問題： Release 提供即時服務的系統 Release 清晰度和更高的使用者自主性。

為了避免將現狀與計劃混淆，本文分為兩部分：

現已推出（MVP）：狀態感知
旨在加快分診速度並更清晰地評估出院健康狀況。

接下來的計畫（路線圖）：指導幫助和故障排除
已明確標註為路線圖，並可能隨時變更。

今天，問問 Release 專注於 狀態感知系統知識和故障排除是計畫中的路線圖領域，不屬於目前版本的一部分。

現已推出（MVP）：跨平台狀態感知 Releases

即使資料存在，發布狀態也常常分散在儀錶板、日誌、審核流程和任務檢視中。要回答諸如「哪些功能正在運作？」、「哪些功能失敗了？」、「哪些功能被阻塞了？」之類的基本問題，需要手動關聯或升級處理。

主動瞭解 Release （MVP）提供對話式訪問 Release 狀態和執行上下文，以便發布經理能夠了解 DevOps 工程師和平台工程師可以更快找到答案，無需點擊多個視圖。 MVP 的重點明確在於狀態感知，能夠提供即時且清晰的資訊。 Release 系統數據。

狀態意識問題類型	問什麼 Release 提供	示例提示	輸出範例
hr@hksouv.com Release 健康概覽	總結整體發布狀態：已完成的工作、進行中的任務以及任何失敗/阻礙因素	「請向我展示當前狀態 Release CustomerA_Prod_Deploy“	“CustomerA_Prod_Deploy 正在進行中：16項任務中已完成12項，1項正在重試，3項待定。還有兩項審批尚未完成。
早期檢測 Release 風險	標記風險與障礙：失敗的任務、長時間運行的任務、阻礙進度的依賴項	“此次發布是否存在任何風險或障礙？”	“兩項任務的工期均已超出預期；一項依賴項阻礙了下一階段的進行。待審批事項：安全審批。”
故障定位	識別先前運行中失敗的任務並總結失敗原因。	“在上次服務 B 的部署中，哪些任務失敗了？”	“集成測試因超時失敗。資料庫遷移因缺少變數而失敗。”

MVP狀態感知功能已上線 Release 26.01 並被定位為以下部分的一部分 SaaS的 審判動議，核心人物包括 Release 經理們， DevOps 工程師和平台工程師。

下一步計畫（路線圖）：擴展代理功能 + 引導式幫助 + 故障排除

即將推出的創新將擴展 Ask Release 超越地位意識 操作指南 以及 更快的問題解決.

1）系統技術訣竅

主動瞭解 Release 成為產品內指南，透過提供逐步指導，幫助使用者從意圖過渡到執行， Release使用者可在需要時獲得針對性指導。他們可以提出具體問題，並立即獲得符合標準的最佳實踐、針對特定任務的後續步驟，幫助新團隊成員更快上手，並提高團隊間的一致性。

權限	用戶獲得的（即時價值）	主要用例	示例提示
符合標準的最佳實踐	符合貴組織慣例及控制措施（命名、門禁、審核、環境規則）的指導原則	預設採用受控交付：確保範本和版本發佈在各個環境中都遵循必要的控制措施	“如何使用我們的標準模式添加生產審批門？”
具體任務的後續步驟	針對特定任務的逐步說明（建立範本、新增審核、重複使用元件、設定變數）	加快常見工作流程的執行速度：完成例程 Release 無需切換工具或等待專家即可完成任務	“在多個範本中重複使用共用步驟的建議方法是什麼？”
更快提升	加快新團隊成員的入職速度，並方便偶爾使用的使用者快速上手。	新用戶引導 + 自助服務啟用：縮短新用戶和不常用用戶達到工作效率所需的時間	“我應該如何建立開發→測試→生產環境的架構才能符合我們的治理要求？”
更穩定	已驗證的模式以相同的方式應用於各個團隊	大規模標準化：減少團隊間的差異，提升可靠性，簡化審計流程	“我們在各種環境下進行審批和關卡設置的標準方法是什麼？”

2）故障排除

主動瞭解 Release 提供上下文感知故障排除功能，將故障轉換為清晰、可操作的步驟。當故障時，請諮詢 Release 幫助使用者理解故障的簡單語言解釋、關聯上下文以找出可能的根本原因、指導解決步驟以及可重複的恢復路徑。

權限	用戶獲得的（即時價值）	主要用例	示例提示
簡明易懂的失敗解釋	清楚總結失敗的原因、失敗地點及其意義—無需解碼日誌	更快的故障排查：迅速了解故障及其範圍，以便團隊能夠立即採取行動。	“請解釋一下這項任務失敗的原因以及我接下來應該怎麼做。”
上下文關聯分析可能的根本原因	交叉引用執行訊號（任務輸出、依賴關係、批准、整合、變數）以縮小原因範圍	根本原因加速查找：減少在各個系統和螢幕間追蹤訊號所花費的時間	“與上次成功運行相比，這次失敗是新的情況嗎？究竟發生了什麼變化？”
引導式解決步驟	針對不同場景的具體步驟，包括檢查內容、重試內容和驗證內容。	Safe 恢復：透過清晰、可重複的步驟快速恢復流程。	“最快的 safe 如何採取恢復措施才能讓這個版本重新開始發布？
可重複恢復路徑	使經過驗證的恢復步驟易於在不同跑步和團隊中持續重複使用	操作標準化：減少重複調查和事件處理方式的差異	“請顯示上次遇到此錯誤時我們推薦的恢復步驟。”

結語

隨著軟體交付環境規模和複雜性的成長，挑戰不再只是自動化發布，而是如何有效率地運行這些發布流程。 safe不出所料。

模板氾濫、資訊分散、依賴專業知識，即使在成熟的組織中也會引入隱患和交付緩慢的問題。

主動瞭解 Release （MVP）旨在解決當前痛點：提高運行版本的狀態感知能力，從而實現更快的分類、更清晰的更新和更少的上下文切換，並減少對經驗知識的依賴。

由此，路線圖將擴展到：

• 在複雜的發布環境中獲得更廣泛的情報
• 針對新用戶入職和採用情況的上下文系統知識
• 故障排除指導可減少平均修復時間和重複調查

目標是 Release 能夠隨著組織規模擴展而不是成為限制的環境：在企業控制下，更快診斷、更清晰的行動和更一致的執行。