問起 Google 的軟體工程作品，多數人會說 Gmail、Maps、Bigtable、Colossus；但其實有大量「使用者看不到」的工程在 SRE 內部進行。本章透過容量規劃工具 Auxon 的案例展示 SRE 軟體工程的價值與實踐。

為什麼 SRE 內部要寫軟體？#

Google 規模逼出許多自製工具——市場上工具不夠大。SRE 內部開發的優勢：

• 生產第一手知識：天生考慮可擴展性、優雅降級、與基礎建設整合
• 直接的使用者回饋：客戶是其他 SRE，誠實高訊號
• 次線性成長：SRE 規模成長若要落後於服務成長，必須靠自動化

對個別 SRE 而言，軟體工程專案也提供：

• 職涯發展機會
• 程式碼能力的維護
• 平衡 On-Call 與中斷工作的長期專案出口
• 吸引並留住背景多樣的工程師

案例：Auxon 與容量規劃#

傳統容量規劃的痛點#

四步循環：

1. 蒐集需求預測
2. 設計 build 與配置計畫
3. 審查與簽核
4. 部署與設定資源

傳統做法的問題：

• 天生脆弱：任何看似小的變更（服務效率退化、客戶採用提升、資源交付延遲）都會迫使整個計畫重來
• 耗時且不精準：用試算表做 bin packing（NP-hard），不僅難以擴展、易錯，還會逼團隊「簡化需求」以求可行
• 意圖丟失：到達執行端時只剩「X 核 in cluster Y」，原始的 why、自由度全部消失

解法：意圖式容量規劃（Intent-based）#

「指定需求，而非實作」——把服務的依賴與參數（intent）程式化編碼，由電腦自動產生配置計畫；需求變更時重新生成新計畫。

意圖的不同抽象層級：

1. 「我要 cluster X、Y、Z 各 50 核」（純資源請求）
2. 「我要 region YYY 任 3 個 cluster 共 50 核」（加入自由度）
3. 「我要每個地理區的需求都被滿足，且具備 N+2 冗餘」（人類可理解的目標）
4. 「我要 service Foo 達 5 個 9 的可靠性」（最抽象，影響可見）

Google 經驗：服務在跨到第 3 階時可獲得最大效益——既具自由度，又有可理解的後果。最成熟的服務可達到第 4 階。

意圖的前置資料#

• 依賴關係（dependencies）：服務 Foo 需要 Bar 在 30 ms 網路延遲內，且 Bar 又依賴 Baz、Qux——巢狀
• 效能指標（performance metrics）：把「需求量 N」翻譯成「資源量」與「下游依賴量」
• 優先順序（prioritization）：資源不足時要犧牲什麼

意圖式規劃把優先順序的取捨變得透明、公開、一致——資源不足必然帶來取捨，但能避免黑箱化的政治。

Auxon 的主要元件#

• Performance Data：服務的 scaling 模型
• Per-Service Demand Forecast Data：未來需求趨勢
• Resource Supply：基本資源（機器）的可用性——線性規劃中的上界
• Resource Pricing：基本資源的成本——線性規劃的最小化目標
• Intent Config：人類可讀的意圖定義
• Auxon Configuration Language Engine：把 Intent Config 轉成機器可讀的 protobuf 請求
• Auxon Solver：以混合整數／線性規劃求解，可平行於上千機器
• Allocation Plan：求解結果——哪個資源給哪個服務、無法滿足的需求也明列

開發過程的教訓#

開發者就是使用者#

Auxon 團隊持續維護生產系統 On-Call——既是產品的開發者也是消費者。

失敗會直接影響團隊；新功能需求來自第一手經驗。這買到的擁有感與內部信譽極為重要。

近似先於完美#

「Launch and iterate」對 SRE 軟體尤其關鍵。

初版用 Stupid Solver（簡單啟發式）：永遠不會給出真正最佳解，但證明願景可行；solver 介面被抽象掉，後續無痛換成 LP。

對需求模糊處：把設計做得通用且模組化。

• 整合各家自動化系統 → 不為每家寫獨家整合，而是讓 Allocation Plan 通用，讓 client 自己接
• 機器效能資料缺乏 → 抽象成單一介面，使用者可換不同模型

推廣與採用#

別低估「socialize」的工夫——單一簡報或 email 公告絕對不夠。需要：

• 一致的訊息
• 使用者倡議者
• 資深工程師與管理層的背書

設定期望#

在「願景目標」與「最小可行（MVP）」之間取得平衡：

• 承諾太多太早 → 失去信譽
• 承諾太少 → 沒人有動力試

Auxon 的做法：短期立即解決手動 bin packing 的痛苦，長期沿用同一份設定檔擴展更大效益。

挑對客戶#

• 初版不去碰已有 home-grown 解法的大團隊（他們痛苦不夠）
• 鎖定還沒有容量規劃流程、本來就要做設定的小團隊 → 早期成功 → 早期客戶變倡議者
• 寫案例研究、量化效益（時間節省、瑣事減少）

客服#

給早期採用者白手套服務：手把手協助上手。

自動化常帶有情感擔憂（「我會被 shell script 取代」）；面對面工作可以改變敘事——使用者不是失去工作，而是擁有設定、流程、最終成果。

不可知（agnostic）設計#

「Come as you are, we’ll work with what you’ve got」——使用者不必先換工具才能用 Auxon。避免為了某 1–2 個大客戶過度客製。

不要把「100% 採用率」當成成功#

長尾的最後一哩往往邊際成本太高、報酬太低。

培育 SRE 軟體工程文化#

適合做的 vs. 不適合做的專案#

✅ 好專案：

• 有第一手領域經驗的工程師願意做
• 使用者技術力高，能提供高訊號 bug report
• 顯著好處：減少瑣事、改善既有基建、簡化複雜流程
• 與組織目標對齊，便於跨部門背書

❌ 不該碰：

• 一次動到太多元件
• 必須全有或全無、無法迭代
• 過度具體只服務 1% 的組織
• 過度抽象、過度泛用以致沒人覺得它解決自己的問題

配置人手與時間#

• 跨經驗組合：通才 + 廣度知識者 + 必要時引入專家（OR、量化分析、統計、最佳化）
• 不中斷的專案時間是必需——切換 task 比想像中耗
• SRE 仍需維持 SRE 角色：保留生產第一線視角，避免變成內嵌的全職開發

起步建議#

引入軟體工程模式到 SRE 組織既是技術挑戰也是組織變革：

• 創建並傳達清楚訊息：先說服 SRE「為什麼這對他們有好處」
• 評估組織能力：找 PM、TPM 補齊「使用者導向」缺口
• Launch and iterate：先挑簡單、可達成、無爭議的題目，半年釋出節奏建立信譽
• 不降低標準：code review、E2E 測試、像審其他服務一樣審你的工具

建立 SRE 軟體工程信譽需要長時間累積，但一次失誤就可能崩盤。

結語#

當 SRE 規模成長，內部軟體工程的回報愈來愈高。Auxon 等專案展示了 SRE 第一手生產經驗轉化為解決長期問題的能力——同時讓 SRE 規模可以次線性追上服務成長，這對公司、SRE 組織、個別 SRE 都是三贏。