打破「專案」迷思：如何用 Google SRE 思維控制 IT 維運成本？

在企業管理會議中，當我們討論到 DevOps 或 SRE（網站可靠性工程）團隊的年度規劃時，最常聽到的質疑往往來自財務長或是執行長：

「這個 SRE 專案什麼時候會結束？」
「既然沒有完工日，那我們要如何控制預算？難道要無止盡地投入人力和軟體授權費嗎？」

這是一個非常合理，卻也最容易被誤解的問題。傳統的 IT 管理習慣用「專案（Project）」思維——有明確範圍、時間、預算——來控管風險。但 SRE 的本質是對抗系統的熵增（Entropy），這是一場沒有終點的馬拉松。

然而，「持續進行」不代表「成本失控」。事實上，SRE 擁有一套比傳統專案管理更嚴謹的成本控制邏輯。本文將引用 Google 原廠的 SRE 守則，從管理者的角度解析如何正確評估與控制現代化維運團隊的成本。

一、 為什麼用「完工日」管不好 SRE？

軟體服務與建築工程不同。建築蓋好後，維護成本相對低廉且可預測；但軟體服務只要業務在成長、流量在增加、新功能在發布，維運的複雜度就會呈現指數級上升。

如果你試圖用「專案結案」的方式來管理 SRE，通常會導致兩種下場：

1. 專案永遠無法結案：管理者覺得團隊效率低落。
2. 強制結案撤出人力：系統隨後因缺乏照料而崩潰，造成更大的商業損失。

關於成本的黑洞：Google SRE Book, Chapter 5

"Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as the service grows."

---

譯文：「瑣事 (Toil) 是指那些與維運生產服務相關的工作，它們通常是手動的、重複的、可被自動化的、戰術性的、缺乏長期價值的，並且隨著服務規模增長而呈線性增加。」

請注意 Google 提到的關鍵字：「隨著服務規模增長而呈線性增加」。這意味著，如果沒有 SRE 介入進行自動化，你的維運人力成本將與你的業務量成正比。SRE 的核心價值，正是要打破這個線性關係，讓業務增長 10 倍時，人力成本不需要也跟著增加 10 倍。

二、 管理者必修：SRE 的三大成本控制機制

既然沒有截止日期，我們該如何守住荷包？建議管理者從以下三個維度來設立「控制閥」：

1. 人力成本控制：嚴守「50% 上限原則」

Google SRE 設下了一條鐵律：SRE 團隊花在維運瑣事（Toil）的時間不得超過 50%。另外 50% 的時間必須用於寫程式、優化架構與自動化。

給管理者的具體作法：

• 定期審查團隊工時分佈。如果維運雜事超過 50%，不是「增加人力」，而是「暫停新功能發布」或「將部分維運工作退回給開發團隊」。
• 這是一條強制的成本止損線，防止高薪的 SRE 工程師淪為全職的高級客服。

2. 機會成本控制：錯誤預算 (Error Budget)

追求 100% 的系統穩定度是極其昂貴的，且邊際效益遞減。

Google SRE Book, Chapter 3

"100% is the wrong reliability target for basically everything... Extreme reliability comes at a cost: maximizing stability stops how fast you can develop new features."

關鍵洞察：「對幾乎所有事物來說，100% 的可靠性都是錯誤的目標... 極致的可靠性是有代價的：最大化穩定性會阻礙你開發新功能的速度。」

給管理者的具體作法：

• 設定合理的 SLO（例如 99.9%）。剩下的 0.1% 就是你的「預算」。
• 這是一種商業決策而非純技術決策。當系統穩定時，我們把「預算」花在快速發布新功能（賺取市場機會）；當系統不穩時，我們暫停發布（控制風險成本）。

3. 基礎設施與採購成本：SRE 即 FinOps

在雲端時代，帳單往往是隱形的殺手。SRE 團隊不僅是系統的守護者，更是「雲端財務長」。

給管理者的具體作法：

• 工具採購原則（Buy vs. Build）：如果你想採購一套 SaaS 監控軟體（如 Datadog 或 New Relic），請要求 SRE 團隊計算：「自建並維護一套開源方案（如 Prometheus）所需的工程師年薪」是否大於「軟體訂閱費」。通常情況下，採購現成工具比養人維護更便宜。
• 資源利用率優化：要求 SRE 團隊定期產出「閒置資源報告」。透過自動擴縮容（Auto-scaling）與競價實例（Spot Instances）技術，SRE 往往能幫公司省下遠超其薪水的雲端費用。

結論：從「花費」轉向「投資」

SRE 的工作確實沒有終點，但這不代表它是無底洞。相反地，它是一種將「不可控的維運成本」轉化為「可控的工程資產」的過程。

作為管理者，當你不再問「SRE 什麼時候做完」，而是改問「我們目前的自動化程度是否讓我們的人力成本低於業務增長率？」時，你就真正掌握了 DevOps 時代的獲利關鍵。

---

本文參考自 Google《Site Reliability Engineering》一書之核心概念。
#SRE #DevOps #IT管理 #成本控制 #FinOps #數位轉型