在大多數科技公司的經驗中，業務增長通常意味著基礎設施成本的同步上升。當使用者增加或功能變多，公司就得購買更多伺服器、增加更多記憶體。然而 Uber 提出了一套名為零成長堆疊（Zero Growth Stack）的策略，核心目標是將容量增長與業務需求解耦。簡單來說，就是讓服務規模繼續擴展，但實體硬體足跡（Physical Hardware Footprint）卻能保持不增長甚至下降。
這對工程師而言是一個巨大的挑戰，因為這意味著你不能透過增加資源來解決效能問題，而必須透過極致的運行時優化與嚴格的成本治理來達成。
動態優化 Go 語言運行時
Uber 的許多核心服務使用 Go 語言開發。在 Go 中，記憶體管理主要依賴垃圾回收機制（Garbage Collection, GC），而控制 GC 頻率的關鍵參數是 GOGC。傳統上，工程師會為服務設定一個靜態的 GOGC 值，但問題在於不同服務的記憶體足跡（Memory Footprint）差異極大，有的僅 100MB，有的則高達 1GB，單一的靜態設定無法兼顧所有場景。
為了突破這個限制，Uber 開發了一個名為 GOGCTunner 的函式庫。這個工具將 GC 的調整從靜態設定轉變為動態控制迴路。它會直接讀取 cgroup（Linux 用於限制進程資源的機制）的記憶體限制，並監控目前活著的物件（Live Objects）利用率，自動調整 GOGC 的數值。
其運作邏輯是將堆積記憶體（Heap Size）維持在活著物件的 1.25 倍，同時確保總記憶體利用率不超過 70% 的閾值，以防止觸發 OOM（Out of Memory，記憶體溢位導致程式崩潰）。這套自動化方案在 30 個核心服務中成功回收了 7 萬個 CPU 核心，證明了透過精準的運行時控制，可以在不增加硬體的情況下提升系統承載力。
AI 導入開發流程及其經濟代價
除了底層基礎設施，Uber 也將生成式 AI 深度整合進軟體開發生命週期（SDLC），旨在提升開發速度。其 AI 架構分為四層：平台層（透過 Michelangelo AI 作為模型閘道）、上下文層（利用 MCP Gateway 注入內部原始碼以提供背景資訊）、專業層（部署 Minion 和 Shepherd 等背景代理程式）以及審核層（使用 uReview 和 Code Inbox 進行代碼審查）。
從數據上看，這種整合非常成功：92% 的工程師每月使用 AI 代理，約 31% 的新代碼由 AI 撰寫，且自動測試工具 Autocover 每月能產生超過 5,000 個單元測試。
然而，這種效率提升帶來了嚴重的經濟壓力。由於 AI 模型通常採用 Token 計費模式（按輸入輸出字數收費），AI 相關成本自 2024 年起增長了六倍，部分開發者的每月 AI 使用成本甚至高達 2,000 美元。這導致 Uber 必須從無限制的採納轉向嚴格的成本治理，例如為每位開發者設定 1,500 美元的用量上限。
重新定義 AI 時代的效能指標
當 AI 開始大量撰寫代碼時，傳統的開發指標（如人力產出比）已不足以衡量真實價值。Uber 發現，AI 雖然能快速產出代碼和測試，但如果產出的代碼品質低劣或產生冗餘測試，反而會增加基礎設施的運維負擔。
因此，Uber 提出將衡量標準從單純的成本追蹤轉向更細粒度的指標。首先是淨代碼質量比（Net Code Quality Ratio），透過比較 AI 撰寫與人類撰寫的代碼在發布後觸發熱修復（Hotfix，緊急修補程式）的頻率，來量化 AI 的真實貢獻。
其次是單一功能的計算效率（Compute Efficiency per Feature）。這能讓工程主管判斷，AI 產出的功能所帶來的基礎設施開銷，是否與其交付的業務價值相符。
總結來說，零成長堆疊不僅僅是省錢，而是一種工程思維的轉移。它要求我們在追求 AI 帶來的高速開發時，必須同步建立對運行時性能的動態控制以及對 AI 產出品質的量化審核，確保技術的擴展不會被失控的成本所拖累。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。