# 策展 · X (Twitter) 🔥

> 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt)

> 作者：Railway (@Railway) · 平台：X (Twitter) · 日期：2026-06-04

> 原始來源：https://x.com/Railway/status/2062251588387779034

## 中文摘要

# Claude，請幫我把資料中心機櫃架好，而且不准出錯

> 本文最初發表於 Railway 部落格，為 Compute Week 第三天的系列文章
> https://blog.railway.com/p/datacenter-no-mistakes
> 作者：Charith Amarasinghe，平台工程師

我們讓 Claude 負責架設價值數千萬美元的運算資源。我們一點也不後悔。

如果 2026 年 1 月的你，跟我一樣是 Railway 的基礎設施工程師，而你的執行長剛完成了一輪一億美元的募資，你一定會想把其中很大一部分資金投入到當年最熱門的商品——DDR5 DIMM！

所以，你首先會訂購數百台強大的伺服器——這很棒。

然後呢？

要讓這筆八位數的投資真正運作起來可沒那麼簡單。我們談論的是 4 個地理區域、8 到 9 個不同的資料中心設施、半打供應商、數十家網路供應商、數十名技術人員、數百個項目、數千條線纜，以及大量的魔鬼氈。此外，所有事情都必須在 2 到 3 週的安裝窗口內完美銜接。任何一點小差錯都會導致後續延誤，讓整個時程表往後推遲好幾個月。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543409057-iaHJ6VjJsWoAA6uAdjpg.jpg)

將 $$$ 轉化為可部署運算資源前，所有步驟的粗略流程圖

與大多數公司不同，Railway 不相信「人力堆疊」；我們相信槓桿效應與高自主性——因此我們決定在規劃階段只指派 1.5 個人來處理這一切。

所以，我們到底是怎麼做到的？

## 人力瓶頸

在第一代建置時，我們還有時間上的餘裕。

我們的第一代部署分為 8 個階段，歷時 18 個月。我們會在每個區域先建立一個站點骨架，填入 20% 的容量，花幾個月做其他事情，然後再到下一個站點重複同樣的流程。從最初的骨架開始，我們以站點容量的 15-20% 為一批次，執行複製貼上的擴充，並慢慢將其填滿。

這跟上了當時的需求——每一次的伺服器訂購與安裝，大約能給我們 3 個月的容量緩衝期。到了 2026 年，以目前的成長速度，同樣的容量增量只能撐 3 週……

由於瘋狂的成長，Railway 現在同時在 AWS、GCP 以及我們自己的實體機上運行工作負載。將這種不斷增長的需求與供應鏈現狀（從 DRAM 到光纖，所有東西都需求巨大且短缺）結合起來——最好的策略就是盡可能預先訂購，一旦物料到貨就立即交付，並以最快速度使其投入運作。

更緊急的是，這甚至不只是成本問題！你買到的運算資源可能是你唯一能拿到的資源；現在連增加更多的雲端 VM 都要爭搶配額。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543409684-iaHJ6VnDBXUAAhSCHjpg.jpg)

需求迫使我們以越來越快的速度增加運算資源（此圖表尚未追蹤建置、儲存、日誌或網路節點）

2025 年那種手工打造、由人工主導的 Excel 建置文件與站點配置流程已經行不通了。即使聘請足夠的人手並讓他們上手，速度也趕不上；而且考慮到我們團隊規模很小，我們無法在不犧牲其他工作的情況下抽調人力。人類絕對是這裡的瓶頸。

那麼，我們該如何讓 LLM 來處理實體基礎設施呢？LLM 在可以反覆迭代的封閉迴圈中表現出色，所以這就是我們必須建立的東西。

## 約束條件解決所有問題……

如果我們拆解資料中心建置，它其實非常像一套真人大小的樂高積木。組件會以確定的順序和已知的零件庫進行組裝。理論上，我們可以寫一個 `build_site.py` 來產出一份神奇的 Excel 表格。這確實可行，我們去年在阿姆斯特丹區域就是這樣做的——但限制條件依然是——人類。

當你建置整個站點時，固定的模板生成效果很好，但如果腳本有一個「差一錯誤」（off-by-one error）而你沒發現，那就會接到技術人員在早上 6 點打來的電話，問為什麼 32 埠的交換器上找不到第 34 埠（真實故事）。

這些模板需要大量人工維護，任何預期的變更都會增加許多摩擦與特殊情況處理。更糟的是，如果有人在實際安裝時做了變更導致與模板不符，模板將變得無法使用，後續任何應用模板的操作都需要手動修復。

但現在是 2026 年，token（依然）很便宜。為了生成這些內容，我們首先需要給 LLM 一個運作框架，其中包括四件事：

- **實體基礎設施的版本控制**：所有硬體的增加、移除、移動操作都需要被追蹤為不可變的變更集（changesets），這些變更集可以被原子化地應用與檢查。下方是美國某資料中心的變更集歷史範例——每次變更都是一組針對裝置與線纜的「新增/移除/修改」操作。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543407624-iaHJ6V1gcW0AAUgvfjpg.jpg)

- **設計規則檢查 (DRC)**：需要存在一組可稽核的規則，針對裝置、線纜、機櫃或站點執行，以驗證它們是否符合我們的要求。下圖為變更集的 DRC 錯誤範例，顯示線纜連接不完整，更嚴重的問題會被阻擋為錯誤。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543407261-iaHJ6V5LNXEAAGPnKjpg.jpg)

- **零件庫**：每種伺服器配置、光纖模組、網路交換器或線纜都需要在資料庫中建模為一個零件，並能透過型號、製造商與訂購代碼進行追蹤。我們為每種項目定義了屬性架構，因此填充資料庫就像將目錄 URL 丟給 LLM，讓它透過 MCP 建立零件一樣簡單。對於光纖線纜，我們同時建模了通用類型與特定長度的 SKU，因為長度只有在確定機櫃佈局後才知道——這能解鎖為技術人員提供測量用的草稿佈局。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543408471-iaHJ6V79sXcAEjhQCjpg.jpg)

- **屬性與約束系統**：零件需要公開諸如「零件 X 適合 QSFP 插槽」以及「零件 Y 正面有支援 QSFP 與 QSFP-DD 光纖模組的第 3 埠」等資訊。屬性與約束越細緻越好。（例如，對於 PDU，我們建模了斷路器配置與跳脫閾值。）這些同樣是透過讓 LLM 解析規格書並建立約束資料來生成的。交換器埠的屬性編碼了埠類型與支援的光纖模組類型。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543409392-diaHJ6VCSWQAE1dIGjpg.jpg)

僅有這些基礎元件是不夠的。LLM 可以低成本生成大量資訊，因此我們需要正確的工具與可觀測性作為操作者來有效利用它們。對我們來說，這涉及另外兩件事：

1. 讓我們的內部 DCIM「Railyard」具備「即時性」，透過快速推送 UI 更新與更豐富的介面來實現。

1. 一組經過策劃的 MCP 工具與記錄流程的 skill。工具範圍從批量新增線纜，到執行設計規則檢查並回傳分頁輸出。Skill 則會引導技術人員使用這些工具進行機櫃安裝與佈線的工作流程。

有了這個設定，LLM 可以將「幫我在 sjc10 站點架設 5 台運算伺服器」這樣的指令，轉換為一組它能驗證並呈現給使用者審核的操作。

以下是其中一次執行計畫的細項：

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543409323-iaHJ6WBapXsAAiSugjpg.jpg)

執行後，裝置就會出現在 Railyard 中：

使用者可以在 UI 中查看變更集，詢問 LLM 關於最終結果的問題，然後決定是否接受並應用它。簡單吧！我們做完了對嗎？不。（抱歉，這是一篇很長的文章。）應用變更集只是操作者表示他們接受變更；它在現實中尚未真正實現。

## ……但生命週期管理能讓你保持理智

如果你與優秀的技術人員共事：他們的意見回饋價值連城。例如，如何以易於維護的方式佈線？這是一門藝術。因此，最初我們希望在獲得更多專業知識時能夠修改設計，所以應用變更集並不會讓設計永久固定，而是為每個涉及的 asset（無論是線纜還是機櫃裝置）開啟一個生命週期。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543407291-iaHJ6WJ6PWQAAUGVejpg.jpg)

我們的生命週期很簡單，有 5 種有效狀態：草稿 (Draft)、建置中 (Buildout)、啟用 (Active)、維修 (Repair) 與除役 (Decommission)。

*   **草稿 (Draft)**：這些 asset 是可變的，你可以透過變更集無懲罰地刪除或移動它們。我們假設設計在此階段仍處於變動中。迭代透過變更集進行，因此設計演進的歷史會被追蹤——包括透過變更集描述記錄的決策理由。

一旦你滿意了，就將 asset 從「草稿」提升到「建置中」。

*   **建置中 (Buildout)**：這表示資訊已發布給現場的技術人員。處於此狀態的 asset 可能已經部分安裝，因此任何變更都需要我們清楚記錄來源與最終狀態，以便技術人員進行追蹤。

將 asset 提升到「建置中」還會執行額外操作以簡化物流：

- 由於使用者可能會提升多個變更集，我們會建立一個「工作單」(Work Order)，將所有不同的線纜/裝置新增/移除/修改操作封裝在一個集合中。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543407278-iaHJ6WNj0WwAA2ypCjpg.jpg)

- 由於裝置與線纜來自組件庫，我們使用該資料自動生成「物料清單」(Bill of Materials)，包含完成工作單所需的所有採購數量。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543408710-iaHJ6WPdbWgAAgKpqjpg.jpg)

一旦技術人員完成所有工作，就會進行資格認證流程，裝置隨後被提升到「就緒」(Ready) 狀態。

「就緒」是最終的「生產中」標記，唯一可能的變更是移除或原地維修。

這讓我們能夠建模設計、建置與操作的生命週期，但這如何轉化為現實生活？

## 機櫃安裝與堆疊

在建置站點時，我們聘請了一家全球承包商，他們在我們所在的每個地理區域都有團隊。但一個關鍵挑戰在於，如何將我們整理的所有資訊轉化為對機櫃現場技術人員真正有用的格式。

我們發現，列印出來的佈線矩陣在這裡依然是王道。但與我們剛開始時不同——這份文件是我們工具的輸出，而不是輸入。使用 `go-excelize` 函式庫，我們的 Golang 後端可以輕鬆地用受影響的線纜與裝置列表填充骨架模板。

我們與承包商合作，針對他們偏好的工作流程優化了這份表格：

1. 線纜始終根據網路中的裝置層級進行排序，例如：交換器到伺服器的線纜會按交換器與埠分組並排序。

1. 線纜按機櫃拆分，以配合團隊負責人將機櫃分配給特定技術人員進行佈線的工作流程。

1. 驗證工作流程檢測到的佈線錯誤（將在未來的部落格文章中介紹）可以直接顯示在每行佈線資訊旁邊。

1. 已完成工作單的線纜會標記為綠色，讓技術人員可以直接跳過。

1. 像變更紀錄或按線纜類型分類的矩陣分解等「錦上添花」的功能，現在生成起來非常便宜。

1. 標籤字串會以與我們偏好的線纜標籤系統相容的格式自動生成。

由於表格在驗證連結時並不是最容易處理的格式，我們讓 Claude 建立了一個小型 UI，它使用相同資料的 JSON 匯出檔，但模擬了更深層的檢視。技術人員可以透過每個機櫃中的 iPad 使用此工具。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543408957-iaHJ6WUAiWQAATSy1jpg.jpg)

Techtool 是建置過程的唯讀檢視——它允許互動式地追蹤機櫃、裝置與線纜。

有些「改進」從技術人員的角度來看反而是退步；因此，我們在第一次安裝時親自到場徵求意見回饋非常重要。例如，Railyard 可以生成全彩的機櫃立面圖，但技術人員更喜歡簡單的 Excel 線框圖，因為更容易閱讀。這些線框圖是透過程式碼生成的，並添加到 Excel 匯出檔中。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543407931-iaHJ6WWoFXMAAinORjpg.jpg)

對於建置，我們提供簡單的線框立面圖以求清晰。裝置按類型進行顏色編碼，儲存格文字包含裝置名稱與安裝方向。

現在技術人員知道要安裝什麼以及安裝在哪裡，我們終於可以開始建置了。假設所有物料都在現場，且一切按計畫進行，這可能需要幾週時間。聽起來我們做完了？記住，這是一篇很長的文章，所以還沒：技術人員會犯錯，光纖模組可能會出問題，組件在運輸過程中可能會鬆動——基本上現實世界中什麼事都可能發生。驗證一切是否就緒本身就是一項艱鉅的任務，但 Claude 在這裡也能幫上忙。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543410348-diaHJ6WYu0XEAEJcpjpg.jpg)

我們最新的 Ashburn 機櫃建置中；箱子裡只是最後 10% 尚未拆封的物料。

## 用 Claude 稽核人為錯誤

在第一代站點中，硬體資格認證是我們帶著手電筒與檢查表走遍機櫃。我們會抽查幾條跳線，確認沒有任何紅色錯誤 LED，並確認在我們手動安裝作業系統後，每條伺服器連結都已連線。這能抓出 90% 的問題，但需要親自到場且耗費大量時間。剩下 10% 無法抓出的問題，在生產工作負載上線後變得太難修復。

到了第二代，手動流程已經行不通了。

首先，專案負責人無法同時出現在 3 個城市；其次，線纜、伺服器與交換器的數量太多，我們無法有效檢查。因此，我們再次建立了一個流程，讓 LLM 來承擔這項工作。

我們首先刪除了作為我們「如何建立資料中心節點」知識庫的 Notion Runbooks，並將這些步驟編碼為 `/dc-provision` skill。該 skill 指導 LLM 如何引導操作者完成設定。這包括生成指令（例如：「將筆電插入 X 埠」）以及供操作者執行的腳本。腳本是根據該特定站點的 DCIM 資料進行模板化的，減少了所需的手動工作。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543408649-iaHJ6WbE9XIAAtMRqjpg.jpg)

`/dc-provision` skill 的摘錄。

一旦基本網路配置設定完成，該 skill 就會進入資格認證流程。這由兩個主要的 harness 組成：

1. **Fabric 驗證**：MCP 工具公開了每個交換器的埠配置、埠到介面的對應、收發器 DOM 統計資料以及 LLDP 鄰居資訊。這些工具抽象化了網路裝置作業系統，因此我們能夠使用相同的前端來查詢 SONiC 與 Arista EOS 裝置。

1. **伺服器啟動至迷你 Linux 燒機環境**：在此環境中作為 PID 1 運行的 Agent 公開了一個 HTTP API，供 LLM 查詢。該 Agent 公開了硬體感測器資料、LLDP 鄰居與 `ethtool` 導出的統計資料。一個小型 dropbear SSH 伺服器允許 Claude 透過 SSH 進入進行更深入的除錯。

有了這兩個 harness，該 skill 可以驗證佈線、安裝與連接品質（光訊號強度）。該 skill 的輸入之一是裝置序號與機櫃位置的清單；LLM 可以將此資料與 LLDP 鄰居資訊、DCIM 資料以及裝置元資料進行比較，以確定裝置已按照我們的規格安裝並連接。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543409383-iaHJ6Wdc6W0AAaEG0jpg.jpg)

Claude 生成的 Fabric 驗證報告範例；隨著文件與回饋迴圈的改進，我們看到資格認證失敗的次數在每次後續建置中都在穩定下降。

伺服器資格認證需要另外寫一篇文章，解決方案是由 LLM 驅動的，但包括一個 10 小時的燒機流程，由 LLM 審查結果以發現異常值並檢測整個機群的模式。簡單的失敗（如指標超過閾值）會導致程式化失敗，但 Claude 發現了新的失敗場景，例如溫度異常的伺服器，結果發現是缺少風扇，而 BMC 並未發出警報。

所有資格認證報告都會寫入我們的 DCIM 作為備註，為 LLM 提供記憶，為操作者提供稽核軌跡，並為未來的輪值工程師提供文件。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543408250-iaHJ6WfdSWIAAei5Sjpg.jpg)

由 Claude 生成的伺服器資格認證報告——一個風扇速度感測器因轉速計故障而卡在最大值。

站點通過認證後，我們基本上已經準備好進行配置並上線；在這個過程中，我們距離在火車上讓資料中心上線又近了一步（這是許多 Railway 平台工程師的職涯目標）。但如果我們說這一切 100% 沒有問題，那就是在撒謊，實際上——大約有 99% 的成功率。

## 壞機器人……

你可能會驚訝地發現，LLM 化的建置工作流程平均表現比我們之前的人工設計要好得多。

主要的錯誤通常是由操作者驅動，或是源自給系統的錯誤約束條件——修復方法大多涉及增加更多的檢查規則並收緊約束。

例如：在進行某些線纜移動時，操作者忘記重新添加幾條線纜，導致裝置在沒有網路存取的情況下被安裝——一條驗證至少有 1 對不同交換器連結的設計規則修復了這個陷阱。

更有趣的錯誤集中在 LLM 沒有約束條件引導其正確方向的情況。例如：LLM 可以根據相位平衡與 PDU 斷路器分配來選擇電源插座，但它沒有關於垂直機櫃 PDU 上的插座相對於伺服器電源輸入位置的上下文——結果就是，機櫃底部的伺服器需要一條 3 公尺長的 C14/C13 電源線才能連接到機櫃頂部的插座。目前，我們透過一個會提示使用者輸入的 skill 來解決這個問題——但佈線部分其實可以建模得更好。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1780543408052-diaHJ6WiTWwAE56aTjpg.jpg)

4 公尺長的電源線對我們的機器人統治者來說完全沒問題。

LLM 也並非沒有錯誤，且在長 context window 下，skill 可能會變得過於寬鬆。任何 harness 沒有引導 LLM 執行嚴格步驟序列的地方，都可能導致 LLM 忘記做某些事情。例如：在 `/dc-provision` 期間，Claude 在設定過程中「忘記」了幾個步驟，導致後續的設定階段失敗。雖然它很擅長發現遺漏並修復它，沒有造成損害，但這仍然提醒我們這些系統是非確定性的，需要防護機制。我們尚未完全解決這個問題，但在過渡期間，我們發現讓 LLM 在驗證階段審查裝置配置作為最後檢查，效果非常好。

不用說，諸如驅動資料平面網路 Fabric 或轉運對等互連 (transit peering) 等關鍵部分的 BGP 設定，依然是 100% 由人工審查的。我們仍然確保任何可能影響使用者工作負載的步驟都有「人在迴圈」(human-in-the-loop)；但隨著我們擴大規模，安全的自動化也將應用於這些步驟。

這些檢查並不是對抗異常硬體的唯一防線。一旦站點通過驗證，我們會透過針對該區域的 Railway app 部署執行第二套完全獨立的測試套件——這些檢查會從使用者工作負載的角度驗證每個組件是否符合我們的規格。

## 圓滿完成

距離我們決定建立這個系統已經過了 6 個月；從我們開始實際使用它也過了 5 個月。就在過去這一週，我們透過讓作者休假、將 Claude 的控制權交給 Mark（我們的工程主管）來驗證系統是否有效，並觀察他能做到什麼程度——除了幾個小瑕疵外，表現非常出色——又有一批伺服器上線，識別出了十幾台故障伺服器，並將更多的運算資源運送到生產環境！

雖然還沒辦法在海灘上部署伺服器；但已經很接近了。

接下來是什麼？就像 Railway 的一切一樣，這只是我們的灘頭堡。隨著我們將運算資源擴大 8 倍、16 倍、32 倍及更多——我們致力於投資工具來達成目標。對於 Railyard 而言，這意味著要讓它更了解我們的基礎設施——並整合訊號，以便其 LLM 助手能看到更廣泛的模式。

這正是我們撰寫這篇文章的原因；因為驚喜的是，我們正在招募！有兩個職位特別旨在擴展我們在這裡建立的東西：**資深基礎設施工程師：資料中心**，正在尋找一位熱衷於馴服我們的金屬機器人，並將 Railyard 及其工具帶入 2027 年及以後的人才（你將擁有八位數的伺服器採購額度）；而**資深基礎設施工程師：裸機編排**，則尋找願意將這些伺服器轉化為運算資源的人才。

如果這兩個職位聽起來很有趣，或者你想為這種「從農場到餐桌」式的運算資源帶來自己的風格；請透過 careers@railway.com 與我們聯繫。

## 標籤

Deployment, 產業趨勢, 硬體, 自動化, Railway, Anthropic, Claude