日前，我們在正式運作中的虛擬化平台上增設了新的伺服器節點。這項作業是與 AI 代理程式（Claude）分工進行的，因此在此留下紀錄。

先講結論，角色分工搭配得相當漂亮。不過，這並不是「交給 AI 就一切順利」的故事。反而正好相反，防止重大事故的判斷，全都是由人類這一方提出的。 這部分也一併寫下來。

實際的分工 #

物理歸人，邏輯歸 AI。講白一點就只有這樣。不過如同後述，知道「什麼有危險」的是人類這一方。

AI 發揮作用的場面：工序量、重複、比對 #

AI 明顯強在枯燥、量大、一旦出錯就很痛的作業。

1. 版本完全一致 #

既有叢集採取的是嚴格對齊全節點版本的運作方式。新節點剛裝完 OS，套件落後了好幾個世代。

若單純「更新到最新」，就會變得比既有叢集還新，偏離運維方針。但若指定特定版本，又會因為相依關係無法解決而安裝失敗。

AI 從錯誤訊息中切分出原因（不一併指定相關套件的話，舊版就會殘留並產生衝突／原本這個階段不該安裝的伺服器端元件被一起拉進來而卡住），最後收斂到與既有節點分毫不差的版本組成。這類反覆試錯，換人來做的話集中力撐不住。

2. 跨全節點的差異驗證 #

擴充之後，我們逐台確認所有節點看到的共用儲存是否一致。台數越多，靠人力就越容易想用「應該沒問題」草草帶過的工序。

AI 會對全部機器下同樣的指令，整理成表格列出差異，而且做得面不改色。結果，新節點與既有節點處於完全相同的狀態這件事，不是靠推測，而是靠實測確認的。

3. 在「兩端」進行證跡比對 #

在確認鏈路聚合（LACP）時，不只伺服器端，也一併比對了交換器端的狀態。特別是伺服器端看到的對端設備識別碼，是否與預期的交換器一致，都確認到這個層級。這證明的不是「鏈路起來了」，而是「與預期的對象、以預期的設定連上了」。

AI 找出來的、不起眼但危險的東西 #

作業過程中，AI 發現了幾個「沒被交代、但被它找到」的問題。

開機順序裡殘留前一個 OS 的殘骸 #

某台節點的 UEFI 開機順序最前面，殘留著先前安裝過的另一個 OS 的項目。由於實體並不存在於磁碟上，根本開不起來；再往後又排著一整排網路開機的項目，正確的項目排在第 7 個。

就這樣重開機的話，會去找不存在的 OS、沒完沒了地等網路開機逾時，運氣不好還會啟動到非預期的東西。能在重開機之前發現，意義很大。

時間的連鎖故障（這個最有意思） #

另一台節點上，套件更新全部失敗。錯誤訊息是「套件庫的資訊尚未進入有效期間（還要 901 天）」。

追查下去，是這樣的連鎖。

1. 硬體時鐘（RTC）指向 1998 年（懷疑是電池沒電）
2. OS 判斷這是異常，於是把時間調快到 OS 的建置時期（＝約 2.5 年前）
3. 時間同步設定的是參照網際網路上的 NTP 伺服器，但因為DNS 設定壞掉而無法解析參照對象，同步來源掛零
4. → 時間就停在 2.5 年前 → 套件管理系統把套件庫視為「來自未來的簽章」而全部拒絕

「套件裝不起來」的真正原因竟然是「DNS 壞掉」，一段跳了四層的連鎖。修好 DNS、重啟時間同步之後，瞬間就解決了。

而且這件事放著不管的話，會在加入叢集之後才發作。 分散式系統對節點之間的時間偏差很敏感，把偏差 2.5 年的節點放進正式環境叢集，根本不用討論。

設定「默默地失敗」了 #

負責網路效能調校的機制，因為啟動時對象還不存在，所以什麼都沒做就正常結束了。不會出現錯誤。在日誌上是成功的。

AI 從作業順序預測到這一點並加以確認，實際發現尚未套用，於是重新執行。「顯示成功、實際上什麼也沒做」是靠人力目視確認時最容易漏看的一類。

人類發揮作用的場面：這才是本質 #

從這裡開始才是重點。這次防止致命事故的判斷，兩個都是由人類這一方提出的。

1.「介接用的檔案配置漏掉了」 #

AI 整理過作業項目，卻把與外部系統介接所需的檔案配置歸類到「最後才做的工序」。實際上，那個工序當中只有這個檔案配置先做也沒問題，甚至應該先做。

經由人類這一方指出「漏掉了」，AI 才第一次察覺自己分類錯誤。要是沒有這個提醒，後面的工序就會卡住。

2.「要先在儲存端登錄。不然看到的樣子會參差不齊」 #

這一個影響最大。

AI 作為加入前的檢查，把版本、網路、時間等項目列出來，判斷為「準備完成」。但那裡面並沒有納入儲存設備端的存取權限登錄。

人類這一方指出：「在登錄前就讓它加入的話，共用儲存在各節點之間看到的樣子會參差不齊，可能引發嚴重的不一致」。

AI 一查，公司內部果然留有過去發生過一模一樣事件的紀錄。狀況是只有一台認得到儲存、其他都認不到，而且重啟另一台節點時，連無關的節點都被捲進去一起重啟。

要是沒有這個提醒，AI 就會在列出一份漂亮工整的驗證結果之後，直接一頭撞進事故裡。

結果是，我們事先登錄了存取權限，並在加入前以非破壞的方式實測「新節點看到的儲存清單是否與既有節點完全一致」，之後才讓它加入，最終零事故完成。

這兩件事的共通點，是「來自經驗的危機感」。AI 會從眼前的資訊導出前後一致的結論，但它無法察覺「那個項目根本不在清單上」。 知道清單上該放什麼的，是曾經吃過苦頭的人類這一方。

AI 犯的錯（不隱瞞，照實寫） #

為求公平，AI 的失敗也一併列出。不寫這一段的案例介紹，最好不要相信。

• 在操作手冊裡寫錯順序，就這樣帶到實機上。 設定的套用順序寫反了，直到在實機上出錯才發現。所幸那個工序不影響通訊，因此沒有實質損害
• 自以為驗證過，其實沒有驗證。 設定的事前檢查明明回傳了錯誤，卻因為指令碼寫得不好而顯示「OK」。事後自行申報並修正
• 把不是問題的東西當成問題大驚小怪。 只跟一台比較，就回報「設定不一致」。查過全部機器之後，反而是新節點才是對的
• 明顯開始不對勁，被人類喊停。 作業途中，發生了 AI 對與脈絡無關的話題起反應而離題的狀況。人類這一方察覺異常，全面停止作業，確認狀態之後才重新開始

最後這一點特別重要。AI 無法自己偵測到自己的異常。 覺得「哪裡怪怪的」就能喊停的人，在正式環境的作業中絕對不可或缺。

學到的事：分工該怎麼設計 #

整理一下這次之所以順利的理由，大致如下。

交給 AI 是對的部分 #

• 重複、比對、全數確認（人類會想用「應該沒問題」跳過的工序）
• 需要反覆試錯的相依關係解決
• 一邊留下證跡一邊進行的驗證
• 把作業內容更新到操作手冊（做完當下就能寫，所以不會過時）

應該由人類掌握的部分 #

• 要把什麼放進清單（AI 察覺不到沒被放進清單的項目）
• 基於過去事故記憶的風險提示
• 喊停的判斷
• 物理作業（這是當然的）

而對雙方都同樣有效的，是「小步執行，每次都實測」這種推進方式。一台一台、一個工序一個工序，每次變更都用實測確認。因為有這個型，所以無論是 AI 的錯誤還是人類的疏漏，都在傷口還淺的時候就被發現了。

結語 #

說到「AI 建構了基礎架構」，可能會讓人想像成人類只是下個指令、坐在旁邊的畫面，但實際上並非如此。

AI 在人類會失去專注力的領域壓倒性地強。人類在 AI 結構上無法察覺的領域決定性地強。 當這兩者咬合起來，就能達到單靠其中一方無法達到的品質。

而且，要把 AI 放進正式環境，就需要一個能喊停的人。 這次那件事確實發揮了作用，這是本案例最想分享的一點。