SRE 入門：從後端 RD 到網站可靠性工程

是什麼？

SRE（Site Reliability Engineering，網站可靠性工程）是 Google 在 2003 年左右提出的維運方法論，一句話總結：用寫軟體的方式來做維運。

傳統 Ops（維運）的工作是手動敲指令、值班救火、寫 runbook；而 SRE 把「維運問題當成軟體問題來解」——能用程式自動化的，就不要用人力重複做。SRE 工程師大多是會寫程式的後端工程師，只是把精力放在「讓系統穩定地跑」而不是「做新功能」。

那跟 DevOps 差在哪？可以這樣理解：

DevOps 是一種「打破開發與維運高牆」的文化與理念（CI/CD、自動化、共同負責）；SRE 則是 Google 對這套理念的「具體實作版本」，帶來可量化的指標（SLO）、錯誤預算等明確制度。常聽到的一句話是：「class SRE implements DevOps」——SRE 是 DevOps 的一種介面實作。

核心：可靠度的量化（SLI / SLO / SLA）

這三個是 SRE 最重要的詞彙，務必分清楚。它們是「指標 → 目標 → 合約」的遞進關係。

關鍵直覺：

• SLI 是現實：從監控系統量出來的事實，例如「P99 延遲 240ms」、「錯誤率 0.03%」。
• SLO 是你的內部目標：通常比 SLA 嚴格，留一點安全邊際。
• SLA 是法律合約：違反要付出金錢或信譽代價，所以 SLA 一定比 SLO 鬆，當作最後防線。

SLO 數字背後的「可容忍停機時間」非常重要，這是談判可靠度成本的依據：

錯誤預算 Error Budget

如果 SLO 是 99.9%，那剩下的 0.1% 就是你的「錯誤預算」——允許出錯的額度。以每月為例：

錯誤預算 = 1 - SLO = 1 - 0.999 = 0.001（0.1%）
換算停機時間 ≈ 30 天 × 24 小時 × 60 分 × 0.001 ≈ 43 分鐘 / 月

錯誤預算的精神在於把「衝功能」和「保穩定」之間的拉扯變成一個數字遊戲，而不是吵架：

• 預算還很多 → 代表系統很穩，可以放心發版、做實驗、上新功能（甚至「故意」承擔一點風險）。
• 預算快燒完 → 暫停新功能發布，全力修穩定性問題，直到預算回補。
• 預算燒光 → 凍結發版（feature freeze），只允許修 bug 與穩定性改善的變更。

這套機制讓開發團隊與 SRE 團隊的目標一致：與其爭論「能不能上線」，不如看錯誤預算的餘額來決定。它把「可靠度」變成一個雙方都認可、可被預算管理的特性。

四大黃金訊號（Four Golden Signals）

來自 Google SRE 一書，是替任何線上服務做監控時「至少要先量」的四個面向。對後端 RD 來說，這四個訊號幾乎涵蓋了一個 API 服務的健康狀況。

可觀測性三支柱（Logs / Metrics / Traces）

要量出上面那些訊號，靠的是「可觀測性（Observability）」的三大資料來源。詳細內容請見 observability 主題，這裡先一句話定位各自角色：

• Metrics（指標）：可彙總的數字時間序列（QPS、錯誤率、延遲分位數），便宜、適合告警與儀表板。回答「系統現在健不健康？」
• Logs（日誌）：離散的事件紀錄，資訊量大，適合事後追查細節。回答「這個請求到底發生什麼事？」
• Traces（追蹤）：一個請求跨多個服務的完整路徑與耗時，適合定位分散式系統瓶頸。回答「慢在哪一段？」

事故管理與 Postmortem

當錯誤預算正在被快速消耗、服務真的出事了，就進入「事故管理（Incident Management）」流程。

嚴重度分級（Severity）

事先定義好等級，才能讓「該叫醒誰、該多快回應」有共識：

值班 On-call

由團隊輪流擔任「第一線接告警」的人。健康的 On-call 制度應該：告警必須「可行動」（不該半夜被無意義的告警吵醒）、有清楚的 runbook、輪班負擔合理、補休或補償到位。

無究責事後檢討（Blameless Postmortem）

事故結束後寫的檢討文件。核心精神是 對事不對人：假設每個人在當下都已盡力做出合理決定，問題出在「系統與流程」讓錯誤得以發生，而不是某個人「不小心」。一份典型骨架：

消除 Toil（重複勞動）

Toil 指的是那種「手動、可重複、無長期價值、會隨服務成長而線性增加」的維運工作——例如每次發版都要手動跑十個步驟、每天手動清 log、每次擴容都要人工改設定。

Toil 的特徵：手動、重複、可自動化、戰術性（救火而非建設）、沒有持久價值、隨規模等比成長。

為什麼要消滅它？因為 toil 會吃光工程師的時間，讓人沒空做真正能提升可靠度的工程改善，最後陷入「越忙越救火、越救火越忙」的惡性循環。

部署與發佈可靠度

很多事故來自「發新版」，所以「怎麼安全地發版」是 SRE 的核心戰場。重點是讓變更可以漸進、可觀測、可快速回滾：

• 藍綠部署（Blue-Green）：同時準備新舊兩套環境，流量一次性切換，出問題就切回去，回滾極快但成本是雙倍資源。
• 金絲雀部署（Canary）：先把新版本放給一小部分流量（例如 5%），盯著黃金訊號與錯誤預算，沒問題才逐步放大。
• 快速回滾（Rollback）：任何發布都必須有「一鍵退回上一個穩定版本」的能力，這比「修好再上」更快止血。

後端 RD 的 SRE 學習路線

這是本課最實用的一段，直接回答「從後端 RD 想做 SRE，要照什麼順序學」。重點是先學會量化與看懂系統，再學自動化與底層，依優先序排列：

C# / .NET 實務銜接

把上面的觀念落到 .NET 服務上，最快讓服務「變得可觀測」的四件事：

健康檢查（Health Checks），讓編排器（K8s）與負載平衡器能探活：

builder.Services.AddHealthChecks()
    .AddCheck("self", () => HealthCheckResult.Healthy())
    .AddNpgSql(connectionString, name: "database")
    .AddRedis(redisConnectionString, name: "redis");
 
var app = builder.Build();
// liveness：行程還活著嗎；readiness：可以接流量了嗎
app.MapHealthChecks("/health/live");
app.MapHealthChecks("/health/ready");

指標（Metrics），用 .NET 內建的 System.Diagnostics.Metrics 暴露黃金訊號：

var meter = new Meter("MyApp.Api");
var requestCounter = meter.CreateCounter<long>("http_requests_total");
var latencyHistogram = meter.CreateHistogram<double>("http_request_duration_ms");
 
// 在中介軟體裡記錄每個請求
requestCounter.Add(1, new KeyValuePair<string, object?>("status", statusCode));
latencyHistogram.Record(elapsedMs);

結構化日誌（Structured Logging），讓日誌可被查詢、可關聯：

// 用具名參數而非字串拼接，後端日誌系統才能依欄位搜尋
logger.LogInformation(
    "Order {OrderId} processed for {CustomerId} in {ElapsedMs}ms",
    order.Id, order.CustomerId, elapsedMs);

OpenTelemetry（OTel），一次到位地把 Metrics / Traces / Logs 匯出到後端（Prometheus、Jaeger、Grafana 等）：

builder.Services.AddOpenTelemetry()
    .WithMetrics(m => m
        .AddAspNetCoreInstrumentation()
        .AddMeter("MyApp.Api")
        .AddOtlpExporter())
    .WithTracing(t => t
        .AddAspNetCoreInstrumentation()
        .AddHttpClientInstrumentation()
        .AddOtlpExporter());

常見誤區

實戰補充（Q&A）

Q：SLO 到底該訂多少？ A：不要憑感覺。先用監控量出「目前實際的 SLI」（例如過去 90 天成功率是 99.92%），把 SLO 訂在「略低於現況、且使用者能接受」的位置，例如 99.9%。訂太高會永遠在違約救火，訂太低則失去約束力。跑一兩季後依錯誤預算的消耗狀況再調整。

Q：SRE 和 DevOps 差在哪？ A：DevOps 是一種打破開發與維運壁壘的「文化與原則」，比較抽象；SRE 是 Google 對這套原則的「具體實作」，帶來明確的制度，例如 SLO、錯誤預算、toil 上限、無究責檢討。可以說 SRE 是一種「有明確規則手冊的 DevOps」。

Q：小團隊也需要 SRE 嗎？ A：需要的是「SRE 的思維」，不一定是「專職 SRE 團隊」。小團隊通常由後端 RD 兼任，重點先做三件事：(1) 替關鍵服務訂一個 SLO；(2) 把黃金訊號做成儀表板與告警；(3) 出事後寫一份簡短的無究責檢討。等規模成長、toil 變多，再考慮設立專職角色。

理解測驗

重點整理