Proxmox 網頁介面擅長什麼，又在哪些情況下會需要再開第二個畫面

這件事值得直截了當地說出來，因為一般人往往假設相反的情況：Proxmox 網頁介面是好的。它幾乎呈現了系統能做的所有事，不會把狀態藏在友善的摘要後面，也不會說謊。很多人只靠它就在運行重要的基礎架構，而且他們並不是將就。

公平看待這一點並不是出於客氣。如果說不出一項工具擅長什麼，大概也說不清楚它究竟哪裡不方便，而後面這句才是有用的。

它擅長的地方

它很完整。幾乎每一項功能在介面中都有對應的位置。沒有一大堆只能靠編輯檔案才能完成的事，這在這類工具中比聽起來還要少見。

它不會假裝。數值未知時，看起來就是未知。工作失敗時，失敗會連同輸出一起顯示出來。把這些情況粉飾過去的介面，在真正需要真相的那一刻之前都很討喜。

它與底層系統緊密對應。畫面上看到的東西對應到真實的物件，因此在介面中學到的知識可以轉移到命令列，反之亦然。自創抽象層的工具，教會的是工具本身，而不是系統。

它速度快，而且一直都在。不需要安裝代理程式，不需要另外維持運作的服務，也沒有第二個可能故障的東西。

摩擦真正所在的地方

不在任何單一畫面上。而在於答案分散在好幾個畫面上的問題。

試著問：如果這顆磁碟今晚故障，哪些機器會停擺。介面能回答這個問題。打開儲存區，記下上面有什麼，再逐一打開每台機器，檢查它的磁碟，並把中間結果記在腦中。四個畫面加上一次腦中的合併，下次再問時又得重來一遍。

再問：這台機器實際上是經由哪個橋接器連到外部世界的。形狀相同。機器、橋接器、實體連接埠，而合併發生在記憶中。

再問：套用這項變更之前，它會影響到哪些東西。這裡介面只能幫上一部分，因為答案並沒有儲存在任何地方：必須沿著關係一路往前推導出來。

這些都不是功能上的缺口。所需的每一項事實都存在且正確。代價在於組合，而且每次提出這個問題都要付出一次，而不是付一次就好。

為什麼這個代價平常看不見，直到某一天看得見

在平靜的午後，打開四個畫面並不算負擔。感覺就像一般的管理工作，因為它本來就是。

它只會在兩種情況下變得昂貴。一是事故發生時，合併在時間壓力下進行，錯誤的合併會產生一個看似篤定的錯誤答案。二是面對不熟悉的系統時，還不知道存在哪些關係，因此也不知道漏查了什麼。

這就是為什麼管理同一台伺服器多年的人，常常表示完全感覺不到摩擦，而上週才接手伺服器的人卻覺得處處受阻。兩者對同一個介面的描述都是準確的。

第二層介面不該做的事

它不該取代第一層。原生介面仍是系統實際狀態的參考依據。任何與它不一致的內容，依定義就是錯的；鼓勵使用者不再查看原生介面的第二層，本身就是一種風險。

它不該自創模型。如果第二層教的是 Proxmox 中不存在的概念，腦中就得一直維護一份對照翻譯，而翻譯會逐漸走樣。

它不該隱藏失敗。比底層系統更輕易回報成功的一層，比沒有這一層還糟。

誠實的判斷方式

不要問哪個介面比較好。要問最常提出的是哪些問題，以及這些問題的答案是在單一畫面上，還是分散在四個畫面。

如果平常的問題都是單一物件的問題，例如啟動這台機器、調整那顆磁碟的大小、檢查那份備份，原生介面就能直接回答，第二層只會白白多出一個步驟。

如果平常的問題是關係類的問題，例如什麼依賴這個、這會影響到什麼、這實際上在哪裡執行，那麼這些正是每次都要付出代價的問題，也是加裝任何東西唯一誠實的理由。

Atlas 的做法

Atlas 在 Proxmox 介面旁邊運作，而不是取代它，而且正是針對上述這些關係類問題。

資源鏈會從機器一路畫到實體磁碟，網路鏈則從機器一路畫到實體連接埠，因此原本在腦中進行的合併，改在畫面上完成。差別僅止於此：同樣的事實，組合一次並維持組合好的狀態。

變更執行之前，會列出它將影響的資源，也就是把第三個問題變成可以直接閱讀、而不必自行推導的內容。

而且它是映照 Proxmox，而不是取代其模型：使用者、角色、群組與 API 權杖都是 Proxmox 自己的，權限在登入時向 Proxmox 詢問，Atlas 不會另建一套需要同步維護的平行概念。在這裡學到的，到了那邊依然成立。