打造全球最低效率資料中心指南

建造目標

本網站上的每篇指南，都會教您正確完成某項工作：依序執行命令、確認正確結果，以及辨識列出的故障模式。本指南不同。今天，我們完全假設要設計一座由金錢、電力與自大所能造出的最低效率資料中心。

我們需要一項指標，因此借用業界採用的指標：PUE（Power Usage Effectiveness），也就是設施總功率除以實際供應給運算設備的功率。超大規模資料中心的數值約為 1.1：幾乎每一瓦都用於有效工作。管理良好的企業伺服器機房可達 1.5。我們的目標是 4.0 以上，這表示每消耗 1 瓦運算功率，就有另外 3 瓦毫無作用地耗損。我們會經常引用這個數字，就像嚴謹的指南經常提到備份一樣。

站點選擇：重點就是熱

在真正的資料中心，冷卻是最大的一項營運開銷，因此我們的選址將在熱力學的主場與其對抗。理想地點是閣樓。朝南。最好再有一扇天窗，位置要能讓陽光直接照射伺服器，讓設備同時承受自身產生的廢熱與太陽熱能，形成電費帳單與恆星之間的合作。

冬季時，打開窗戶即可處理冷卻問題。真正的資料中心確實會使用室外空氣，這項技術稱為 free cooling，並且會經過工程設計、過濾及濕度控制。我們則會透過一扇同時讓雨水、花粉，以及每季至少一隻迷途鳥進入的窗戶，意外地使用這項技術。

若要展現真正的藝術性，請安裝空調，然後在距離其恆溫器 2 feet 的位置放置電暖器，並將設定溫度調高至比空調目標高 2 degrees。現在，兩台設備將持續運轉，直到永遠，完美地彼此矛盾。電力公司會在 Christmas 寄卡片給你。

一台伺服器，龐大且受人喜愛

備援會稀釋投入程度。我們的資料中心恰好只有一台伺服器，而且非常龐大，因為一台配備 512 GB RAM 的機器讓人覺得這才是基礎架構，而四台小型機器只像一張待辦事項清單。

這台伺服器有名字。不是主機名稱，而是名字。通常是 Gandalf 或 Odin。你不能將 Odin 除役。Odin 已經連續運作五年：

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

這個數字值得驕傲，因此你會將它截圖並發布；每個看到截圖的攻擊者也會覺得它很了不起：1,847 天的運作時間，代表有 1,847 天的核心漏洞沒有人修補。無論如何都不能重新開機，因為重新開機會讓你發現哪些服務是在 2021 年手動啟動，卻從未寫入 systemd 單元。沒有人記得其中哪些服務。這台伺服器如今已成為組織架構中的承重元件。

儲存裝置：速度，以及其他遺失資料的方法

磁碟已設定為 RAID 0，以提升效能。這個 0 代表允許故障的磁碟數量。若要發揮最大效果，請將陣列分散到來源各異的儲存裝置：2 顆合格的 SSD、1 顆老舊的機械硬碟，以及 1 支會議贈送的 USB 隨身碟。此陣列的可靠性與會議贈送的隨身碟完全相同，這就是設計結果。

備份由同一陣列中的 backup_final_v2_REAL 目錄處理，其中包含先前命名配置的 tarball。異地備份則以一張寫著「設定異地備份」的便利貼表示。從技術上來說，當您將這張便利貼帶回家並放在筆記型電腦上蓋時，它就已儲存在異地。

正確結果看起來應為：df 回報使用率為 97%，並計畫在下一個 sprint 處理此問題。

網路：所有事物的單一連結

DNS 伺服器在機器本身上執行。因此伺服器停止運作時，用來查明原因的 DNS 記錄也會一併失效。這稱為整合。

防火牆曾在 2021 年暫時停用，以便進行偵錯。偵錯已完成，但防火牆沒有重新啟用。路由器上的每個連接埠都轉送到伺服器，理由是「之後可以節省時間」。此外，路由器的管理面板可從 WAN 端存取，且仍使用原廠密碼，以便進行遠端管理。這不只影響你的伺服器，也影響其他人。

伺服器最近的執行溫度異常偏高，即使以閣樓的標準來看也是如此，而 top 顯示最忙碌的程序是名為 xmrig 的項目。我們假設這是正在使用的監控工具。我們沒有安裝它；它在連接埠轉送後不久自行出現，因此我們認為這表示整個環境運作良好。它全天候進行監控。

電力經由一串消費級延長線供應，這些延長線的總長度超過步行至斷路器面板的距離。從某種意義上說，這很有效率，因為你會經常前往斷路器面板。

以複雜性實現冗餘

我們拒絕在重要之處提供冗餘，現在卻在不重要之處加入冗餘。公司的首頁只有一個靜態 HTML 檔案，卻由十二個節點組成的 Kubernetes 叢集提供服務。這實現了工程師所稱的履歷導向架構：頁面仍在 nginx 原本可提供的四十毫秒內載入，但現在可能以需要顧問介入的方式發生故障。

為了隔離，叢集本身執行於虛擬機器中的虛擬機器中的虛擬機器內，每一層都增加安全性，就像 turducken 的每一層都增加一隻禽鳥。聯絡表單由九個微服務組成。其中兩個從未被呼叫過。其中一個負責承載系統，但沒有人知道是哪一個。

供暖即服務

現代伺服器會將電力轉換為運算與熱能，而我們打算最大化後者。不含 GPU 的媒體伺服器是經典作法：以 CPU 轉碼單一 4K 串流會讓 16 個核心持續滿載，並使小臥室變暖；這是一台也能播放電影的電暖器。更進取的管理員會進一步在 CPU 上執行大型語言模型，打造一台配備 API、具有 700 億個參數的電暖器；其產生 token 的速率，最好以季為單位計算。

監控程式監控自己

可觀測性很重要，因此我們在同一部伺服器上部署自行託管的 uptime 監控程式，用來監控該伺服器。Odin 停止運作時，監控程式也會隨之停止。精妙之處在於：不會觸發任何警示。沒有警示，就沒有事件。沒有事件，就代表測得的 uptime 完美無缺。月報從未如此亮眼。

為完整起見，警示電子郵件會透過同樣執行於 Odin 上的 mail server 轉送。因此，警示管線完全自給自足，就像蛇吞食自己的尾巴一樣，始終都吃得很飽。

令人不安的部分

以下是我一直拖延未寫的部分。這些內容沒有任何虛構。那台備受珍愛且無可取代的伺服器、與備份位於同一個磁碟區的 RAID 0、被「暫時」停用的防火牆、只提供一個頁面的 Kubernetes 叢集、監控自身的監控系統，我在正式環境中每一種都看過。其中有些是我今年看過的。早期剛入行時，其中一兩種還是我建置的。

真正的效率看起來很乏味，因此它當下總是輸掉爭論，卻能在十年後勝出：你從不必操心 PUE，因為有人已替你完成工程設計。機器的規模符合工作負載，而不是配合擁有者的自我想像。爆炸半徑在爆炸前就已納入考量。備份會依照排程還原測試，搭配行事曆提醒，不需要英雄式的處置。冗餘設計平淡無奇；兩個便宜的元件勝過一個卓越的元件。對我所有曾接到呼叫而處理的故障而言，始終如此。

而你能運行的最高效資料中心，就是你不必運行的資料中心。VPS 將電力、冷卻、冗餘，以及凌晨 3 點發生的硬體故障交給能以規模化方式、平淡地處理這些工作的團隊。這是基礎架構能獲得的最高評價。它也讓你保有真正有趣的部分，也就是在其上運行自己的服務，並使用一台即使損失也負擔得起的機器；你進行實驗時，應該只使用這種機器。

FAQ

我真的應該做這些事嗎？

不應該。本指南的每個章節都是有記錄的反模式，已造成大量週末損失。如果目前的設定與兩個以上的章節相似，請依照本 FAQ 所列順序，直接跳到最後一個問題，因為該順序就是處理優先順序。

實際上，好的 PUE 是多少？

超大規模資料中心的 PUE 約為 1.1；運作良好的企業機房可維持在 1.4 至 1.6；未冷卻且使用電暖器的儲藏室，確實可能超過 3。在家中無法有效與 1.1 競爭。這也說明了，將運算資源租用給有能力維持該效率的業者，在經濟上通常更合理。

使用伺服器為建築物供暖，是真的可行嗎？

可以，但必須妥善執行。多個國家的區域供熱計畫會透過熱交換器回收資料中心的廢熱，並依照設計，配合工程規劃與合約，將熱能輸送至住家。上文的諷刺之處，不是伺服器熱能可以使房間升溫，而是意外這樣做，還把這起意外稱為策略。

我的伺服器已經是這種狀況了。我首先該做什麼？

今晚先備份，備份目的地不能是該伺服器；接著執行測試還原。未經測試的備份只是一則傳聞。第二，安排維護時段套用修補程式，並執行你一直迴避的重新啟動，這樣才能在監看系統時了解哪些部分會故障。第三，拆除單一故障點：將 DNS 和監控移出該主機。其他事情可以等到較平靜的一週再處理；這三件事不能延後。