前言：第二個三十天，換一個問題

上一個系列「128GB 統一記憶體的三十天」談的是怎麼把開放權重模型在 DGX Spark 上跑起來，選哪個推論引擎、量化怎麼取捨、成本怎麼算。三十天寫完，機器確實跑得動了，但同一段時間裡真正花掉我最多時間的，其實都不在那三十一篇裡。

容器升級後 GPU 突然抓不到，回頭才發現 image 的 tag 被上游換過。NFS 模型庫裡多了三份同名不同版的權重，沒人記得哪一份是實測用的那一份。連續生成影片兩小時之後節點降頻，沒有任何告警，是隔天看紀錄才知道。備份排程有跑，但還原和驗證真的確實嗎? 這些事情跟模型聰不聰明無關，跟推論引擎快不快也無關，它們全部都是維運問題。

所以第二個三十天，接續的新題目是維運。主要的場域是自建的地端資訊環境。這次要協助解決的問題是，一套跑得起來的地端環境，要補上哪些東西，才能好好長期維運呢?

屬於小型企業的機房

由於不能把某些工作或客戶的機房資料拿來當範例，先把本系列文的場域講清楚，後面三十天所有的實作與數字，主要會來自這裡，其他則是日常維運中可以分享的心得和經驗。

這不是企業機房的規模，但它具備企業機房會遇到的所有維運問題，多節點、集中儲存、GPU 熱與記憶體的邊界、跨設備的備份與還原、以及沒有人願意寫但稽核時一定會被問的變更紀錄。規模小反而是優點，每一個環節都能親手走一遍，並且把過程開源。

跑得起來與可維運之間的差距

我把這段時間碰到的問題整理之後，發現它們可以歸成四類。

第一類，服務沒有被封裝
用 docker compose 手動拉起來的服務，升級靠記憶，設定散在各處，換一台機器就要重來一次。要解決的是把服務變成可安裝、可升級、可驗證的套件，而且打包過程本身要可重現。

第二類，節點沒有被守護
GPU 節點在長時間負載下會遇到熱與記憶體的邊界，DGX Spark 的統一記憶體架構讓這件事比傳統 VRAM 更難觀察。要解決的是取樣、告警與自動降載。其他用到如採用 RTX 4090、RTX Pro 6000 的工作站、B200 伺服器之類的機器 (大到要用施耐德電器給機櫃特規的全套散熱設備與監控系統等)，都需要有守護的概念。

第三類，儲存與備份沒有被治理
模型庫的權限、版本、校驗碼，備份的排程、保留期限、還原演練，這些在單機時期都可以省略，多節點之後省不掉。

第四類，變更沒有被記錄
這是最容易被忽略的一類。升級了什麼、誰升的、什麼時候、能不能回滾，沒有紀錄的環境在出事時只能靠猜測。我主要的工作室是資訊安全、系統維運與 ISO 27001 事務，這一段會用 ITGC 的角度來寫，但落地的形式會是腳本與範本，不會是那種上課用的講義。

三十天的結構，主要會依這四類展開，並且在實務上會上調整和運用。

三十天的路線圖

第一段，開源服務封裝（Day 1 到 8）

以 Docker 或 QNAP Container Station 為目標平台，把 Open WebUI 加 Ollama、ComfyUI、Jellyfin、Roon、changedetection.io、Homepage 等服務封裝成 NAS 套件。這一段會公開打包骨架、GitHub Actions 自動打包與 release 流程、image digest 鎖定與 SHA256SUMS 的做法，讓任何人都能照同一套流程封裝自己的服務。

第二段，容量規劃、GPU 節點、儲存與備份（Day 9 到 18）

從容量規劃開始，用模型與硬體搭配矩陣推算節點與儲存規格，接著是 DGX Spark 的節點基線與熱、記憶體守護，NFS 集中模型庫的權限與版本治理，儲存路徑實測，Proxmox VE 雙節點 HA 與備份還原，NAS 的快照與 3-2-1 備份，最後一天談媒體庫外移 GCS 與 S3 的雲地整合。

第三段，可觀測性、資安維運與可稽核的變更管理（Day 19 到 30）

指標收集與 Grafana 儀表板、日誌集中與保存、防火牆日誌判讀、網路封包擷取與分析、維運工作站、資產 EOL 監看，然後進入變更管理與稽核軌跡，最後一天談 AI Agent 進入維運流程時的授權閘道，並以一年的成本與用電費用計算做總結。

關於程式碼

這個系列，我自己有一個小小的規則，每一天的文章都儘量能對應到 GitHub 上一個我自己做過的可執行專案，可能是一個套件、一支腳本或一份範本。專案數量大約二十個到三十個，主要都是我以前做到現在的既有專案，一部分則是將我以前寫過的舊私有專案改成公開專案版釋出。我會另外開一個總索引 repo，三十天結束時會有三十個可以對照的節點。

上一個系列文，談的是地端 AI 模型和架構規劃的選擇和測試、選型，而這個系列呢，談的是自己在 IT 維運相關 repo 中，放的是怎麼做的內容。

明天

Day 2 從封裝的第一步開始，聊看看薄殼架構。為什麼薄殼架構的套件中，不放大量程式碼，只放生命週期腳本與狀態頁，以及這個設計上，怎麼讓套件跟著上游 image 升級，而不用重新再打包。

系列文章與程式碼索引：onprem-ops-30days

我的前一系列文：128GB 統一記憶體的三十天：DGX Spark 地端 LLM 與生成式 AI 部署實戰