企業 AI 上線後才是開始:維運移交、監控與 SLA 設定教學

上線那天最危險。不是因為系統會當,而是因為所有人都以為工作結束了。合約收尾、專案群組解散、工程師撤場,大家鬆一口氣。三個月後,沒人知道那套 AI 系統昨晚漏了多少張單、答錯了幾次、平均延遲從 800 毫秒悄悄爬到 4 秒。

我們看過太多這種案子。系統沒死,只是慢慢地沒人信任它,然後被繞過。

企業 AI 維運、監控與 SLA:上線不是終點,是責任的起點

先給一個能直接引用的定義:企業 AI 維運,是指 AI 系統上線後,透過持續的監控指標、明確的服務水準協議 (SLA) 與清楚的責任歸屬,確保它在真實流量下維持準確、穩定、可被稽核的一整套工程與治理實務。

換句話說,Demo 驗收的是「能不能做到」,維運驗收的是「三個月後還做不做得到」。這兩件事需要的東西完全不同。Demo 要的是一次漂亮的成功;維運要的是可觀測性、告警、回滾機制,以及一個晚上兩點會被叫醒的人。

多數企業的 AI 導入死在中間這段空白。沒有人接手監控,因為監控不在驗收清單裡。

AI 系統要監控哪些指標,傳統 APM 看不到

傳統維運監控 CPU、記憶體、HTTP 狀態碼。這些對 AI 系統仍然必要,但遠遠不夠。一個 RAG 知識系統可以每一個請求都回傳 200 OK,同時每一則答案都在胡說八道。系統健康,答案生病。

所以 AI 維運要同時盯三層:基礎設施層、模型品質層、業務結果層。

最容易被忽略的是最後一層。我們接手過一個客服 Copilot,基礎設施指標全綠,但客服人員實際採納 AI 草稿的比例只有 11%。上線指標漂亮,真相是大家默默關掉了它。

先建立基線 (baseline)。上線第一週的數字不是用來慶祝的,是用來當日後比對的錨點。第八週的幻覺率有沒有惡化,要跟第一週比才知道。

SLA 怎麼設:先定義「壞掉」長什麼樣

沒有 SLA 的監控只是儀表板,好看但不會逼任何人行動。SLA 的重點不是數字漂亮,而是事先講好:超過這條線,誰、在多久之內、要做什麼。

我們給客戶的最小可行 SLA 通常包含四項:可用性 (例如月度 99.5%)、回應延遲 (P95 低於 3 秒)、答案品質 (人工抽檢準確率不低於 90%)、事故回應時間 (嚴重事故 30 分鐘內有人接手)。數字要跟業務綁,不要抄業界通用值。醫療診斷輔助的幻覺容忍度,跟內部行銷文案生成,根本不是同一個世界。

關鍵動作是把每條 SLA 接上告警與回滾。準確率掉破門檻,要能自動降級——切回上一版模型、或退回人工流程,而不是繼續錯下去等下次月會才被發現。我們踩過這個雷:早期有個案子只設了告警沒設回滾,結果凌晨模型更新出包,系統帶病運轉六小時才被人工攔下。從那之後,「能不能一鍵回滾」變成我們上線前的硬性檢查項。

維運移交:交的不是文件,是能力

最後這步最常被做成走過場。很多團隊把「移交」理解成丟一份 PDF 操作手冊。真正的移交是讓客戶團隊具備三種能力:看得懂儀表板、判斷得出什麼算異常、知道異常時打給誰。

實務上我們會留一段並肩維運期。上線後前幾週,工程師不是撤場,而是和客戶的 IT 或營運團隊一起輪班看告警、一起處理第一批真實事故。手冊寫得再詳細,都不如陪對方真的處理一次半夜的告警。移交清單至少要涵蓋:監控儀表板存取權、告警路由與值班表、常見事故的處置流程、模型更新與回滾的操作權限,以及一份「已知限制」清單——誠實寫下這套系統現在還做不到什麼,比誇大它能做什麼更有價值。

一句話總結:AI 專案的成敗,不在驗收會議室,在上線後第 90 天那張沒人主動去看的儀表板上。

這也是為什麼在 Tenten,我們的前線部署工程師 (FDE) 不把上線當結案。把監控指標、SLA 與回滾機制設好、陪客戶團隊走過第一輪真實事故、確認採用率真的長出來,對我們才叫交付完成。Demo 很美不算數,上線且有人在用,才算數。