對於很多 Junior 工程師來說，在面試或開發時常會聽到「效率（Efficiency）」和「可靠性（Reliability）」這兩個詞。通常我們會直覺地認為：效率就是 CPU 使用率越高越好，而可靠性就是系統永遠不能掛掉。但當你面對像 Netflix 這種全球規模的系統時，這兩者之間存在著激烈的衝突。如果你為了追求極致效率將 CPU 壓到 90%，一旦流量稍微波動，系統就會立刻崩潰；但如果你為了絕對可靠而預留過多資源，公司每年將浪費數億美元。
Netflix 的工程團隊分享了他們如何透過一套數學模型與分級管理機制，在不犧牲可靠性的前提下，最大化硬體資源的利用率。
重新定義效率：從 CPU 使用率轉向風險調整價值
在基礎設施管理中，最常見的誤區就是將「效率」等同於「CPU 利用率（Utilization）」。Netflix 認為這是一個陷阱，因為同樣是 30% 的 CPU 使用率，對於不同的服務來說，其代表的風險完全不同。
他們引入了一個概念叫風險調整淨值（Risk-Adjusted Net Value）。簡單來說，效率不應該只看成本，而應該是：服務產生的業務價值 減去（運作成本 + 失敗造成的損失成本）。
這裡的關鍵在於損失函數（Loss Function）。如果是一個「播放服務（Playback Service）」，一旦失效，使用者無法看影片，損失極高；但如果是一個「推薦縮圖服務」，失效後只要提供一張預設的通用圖片即可，損失較低。因此，對於關鍵服務，我們願意花更多錢買更多緩衝（Buffer），這在數學上依然是高效的，因為它降低了巨大的潛在損失風險。
緩衝區（Buffer）與硬體供應管理
為了量化可靠性，Netflix 使用緩衝區（Buffer）來取代單純的百分比。緩衝區是指系統在進入擁塞失效（Congestive Failure，指系統因過載而導致響應時間劇增並最終崩潰的狀態）之前，還能額外承載多少流量。
在管理硬體供應時，他們採取了分層策略：
緩慢擴展服務（如資料庫等有狀態服務）：這類服務啟動慢、數據遷移久，因此必須運行在預留實例（Reserved Instances）上，並保持較大的緩衝區。
快速擴展服務（如無狀態的 API 服務）：這類服務可以快速啟動，因此可以混合使用預留實例與按需實例（On-Demand Instances），在需求高峰時快速增加容量。
此外，他們強調硬體的互換性（Fungibility）。不要死磕某一種特定的機器型號（例如只用 m7a.large），而應該定義所需的資源形狀（Shape）。當某種高效能機型在雲端供應商處缺貨時，系統能自動切換到次佳的替代方案，避免因硬體短缺導致服務無法擴展。
需求管理：從預測到動態導流
理解了供應端後，接下來是管理需求（Demand）。Netflix 將需求管理分為三個層次：
事前預測與預擴展（Pre-scaling）：根據大數據預測（例如某部熱門劇集上線）提前增加機器數量。但預擴展必須精準，過度擴展是浪費，不足擴展則會導致短暫的請求丟棄。
動態流量整形（Traffic Shaping）：這是在流量進入資料中心之前就進行處理。透過控制 DNS 導向，將流量從壓力較大的區域（例如美國東部）導向壓力較小的區域（例如美國西部），從而平衡全球資源利用率。
反應式自動擴展（Reactive Autoscaling）：當預測失敗時，系統會根據 CPU 或 RPS（每秒請求數）觸發快速擴展。他們甚至設計了錘子（Hammers）機制，在進入危險區前強制注入大量容量。
最後一道防線：優先級負載捨棄（Prioritized Load Shedding）
當所有擴展手段都來不及時，系統必須採取負載捨棄（Load Shedding），即主動拒絕部分請求以保護核心功能。
Junior 工程師最容易犯的錯是隨機丟棄請求。Netflix 採用的是優先級捨棄：首先丟棄最不重要的背景任務，接著是降級服務（例如不提供個人化推薦），最後才考慮限制核心播放功能。這就像救護車在高速公路上有優先通行權，而普通私家車必須在擁堵時等待或被分流。
總結與啟發
對於基礎設施的優化，不能只看局部，而要從系統思維出發。效率不是把 CPU 跑滿，而是在可接受的風險範圍內，將資源分配給最能創造價值的服務。
管理大規模系統的成功路徑是：數學模型定義風險 $\rightarrow$ 建立硬體互換能力 $\rightarrow$ 實施多層級流量控制 $\rightarrow$ 設定優先級保護機制。
來源：infoq.com - How Netflix Shapes our Fleet for Efficiency and Reliability
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。