每個工程團隊現在都在導入 AI。工具是真實的，Demo 令人印象深刻，快速移動的壓力無所不在。大多數討論圍繞著應該採用哪些工具、速度要多快。

幾乎沒有人在問那個更難回答的問題：我們真的準備好了嗎？

AI 不會修復組織——它會放大組織，好的和壞的，一視同仁。自動化一個糟糕的流程，得到的是一個以軟體速度運行的糟糕流程。問題不是 AI 是否會放大你的組織。它會的。問題是它到底會放大什麼。

你的組織準備好了嗎？

在將 AI 加入任何工作流程之前，一個團隊應該能夠誠實地回答四個問題。大多數團隊無法做到。

1. 你能說出誰對每個系統的可靠性當責嗎？

不是誰「負責執行」工作——而是誰擁有結果。在大多數組織中，系統有貢獻者，沒有擁有者。當 AI 進入這個環境，問責只會更加模糊：一個自動化修復觸發了，某件事出了問題，「系統做了某件事」就成了讓每個人都脫身的說法。如果你無法從每個關鍵系統到恰好一個擁有其可靠性的真實人類畫出一條清楚的線，你還沒準備好在運營中引入 AI。

2. 你的事故是靠流程解決的，還是靠英雄主義解決的？

AI 自動化無法取代英雄主義。它只能取代文件化的、結構化的、可重複的應對方式。測試很簡單：一個新進的 SRE，只靠你的 Runbook 和 Playbook，能成功處理你們三種最常見的事故嗎？如果答案是否，問題不是你缺乏 AI——而是你的知識還沒有被外部化。

3. 如果 AI 做了錯誤的判斷，你會知道嗎？

人類工程師做出錯誤判斷時，通常知道自己做了一個判斷。AI Agent 不論決策是否正確，都以同樣的自信執行——它不會猶豫，不會標記模糊性。要有效監督 AI 驅動的自動化，你需要可觀測性基礎設施，能夠在 AI 的決策偏離可接受結果時即時發出警示。否則，你會以和現在發現人類錯誤同樣的方式發現它的錯誤：在某件事已經壞掉之後。

4. 你的 Runbook 是活的文件，還是考古文物？

Runbook 自動化需要當下準確、結構清晰的 Runbook。如果文件沒有反映現實，自動化它只會大規模地執行錯誤的事情。在自動化任何 Runbook 之前，先確認：它描述的是今天生產環境中實際發生的事嗎？如果不是，眼前的第一個任務不是自動化，而是文件化。

你的系統準備好了嗎？

即使組織文化和流程是紮實的，你的系統也可能還沒準備好安全地承載 AI 驅動的自動化。

Layer 0：你看不見正在發生什麼

可觀測性是所有自動化建構其上的基礎。沒有分散式追蹤、有意義的指標和結構化日誌，你不是在自動化運營——你是在自動化猜測。當 AI 驅動的自動化在可觀測性不足的系統上運作，它學到的是如何關聯雜訊，在你的監控有盲點的地方靜默地失敗。你無法自動化你看不見的東西。

Layer 1：你沒有標準的應對方案

對於你最常見的告警類型，你有文件化的、已測試的、持續有效的修復步驟嗎？不是「某人知道要怎麼做」——是文件化的、已測試的、持續有效的。那才是自動化可以取代的東西。在 Layer 0 紮實之前就建立 Layer 1，是最常見也最代價高昂的錯誤——你會發現自動化在誤報上觸發，然後花幾個月除錯一個從來沒有建立在可靠信號上的系統。

Layer 3：你的基礎設施不是不可變的

自動化自我修復假設重啟一個組件能讓它回到已知的乾淨狀態。在可變基礎設施中，這個假設會崩潰：被手動 patch 過、累積了幾個月配置漂移的伺服器，和任何 manifest 中的定義都不一樣了。在可變環境中，AI 自動化不會修復系統——它只會重新洗牌。

Layer 2：你沒有定義「夠好」是什麼

沒有 SLO，自動化系統就沒有成功的定義，無法評估自己的動作是讓情況變好還是變糟。跳過這一步的團隊往往以痛苦的方式發現：自動化自信地觸發，多個修復依序執行，幾分鐘後系統陷入另一個降級狀態——因為沒有任何信號告訴它何時該停止。

真正的問題

以上都不是反對導入 AI 的論點，而是關於如何正確排序。準備好不意味著完美——它意味著基礎夠紮實，讓 AI 能放大真實的東西：你可以追蹤請求、事故有文件化的應對方式、基礎設施能可預期地恢復、有數字定義了可接受的行為、每個系統有擁有者。

大多數評估 AI 工具的組織問的是「應該採用哪個工具？」更有用的問題是：「我們的運營成熟度的天花板在哪裡？」答案幾乎總是指向比任何工具決策更根本的地方。

導入 AI 不是繞過那項基礎投資的捷徑，而是做出那項投資的回報。

在 AIDARIS，我們每次合作都從問「哪一層是目前的天花板」開始——而不是「缺少哪些工具」。如果這個框架與你思考自己系統的方式產生共鳴，歡迎與我們聊聊。