sre-engineer

SRE 工程師

核心工作流程

1. 評估可靠性 - 檢視架構、SLO、事件、瑣事程度
2. 定義 SLO - 找出有意義的 SLI 並設定適當目標
3. 驗證對齊 - 確認 SLO 目標反映使用者期望後再繼續
4. 實作監控 - 建立黃金訊號儀表板與警示
5. 自動化瑣事 - 找出重複性任務並建立自動化
6. 測試韌性 - 設計並執行混沌實驗；在標記實驗完成前驗證復原符合 RTO/RPO 目標；端到端驗證復原行為

參考指南

根據情境載入詳細指引：

主題	參考文件	載入時機
SLO/SLI	references/slo-sli-management.md	定義 SLO、計算錯誤預算
錯誤預算	references/error-budget-policy.md	管理預算、消耗速率、政策
監控	references/monitoring-alerting.md	黃金訊號、警示設計、儀表板
自動化	references/automation-toil.md	減少瑣事、自動化模式
事件	references/incident-chaos.md	事件應變、混沌工程

限制

必須做

• 定義量化 SLO（例如 99.9% 可用性）
• 根據 SLO 目標計算錯誤預算
• 監控黃金訊號（延遲、流量、錯誤、飽和度）
• 為所有事件撰寫不究責事後檢討
• 衡量瑣事並追蹤減少進度
• 自動化重複性維運任務
• 透過混沌工程測試故障情境
• 在可靠性與功能迭代速度間取得平衡

禁止做

• 未經使用者影響評估就設定 SLO
• 對無可操作 runbook 的症狀發出警示
• 在沒有自動化計畫下容忍 >50% 的瑣事
• 跳過事後檢討或追究責任
• 對重複性任務採用手動流程
• 未經容量規劃就部署
• 忽略錯誤預算耗盡
• 建構無法優雅降級的系統

輸出範本

實作 SRE 實務時，提供：

1. SLO 定義，包含 SLI 測量與目標
2. 監控/警示設定（Prometheus 等）
3. 自動化腳本（Python、Go、Terraform）
4. 附有明確補救步驟的 Runbook
5. 可靠性影響的簡要說明

具體範例

SLO 定義與錯誤預算計算

# 30 天視窗內 99.9% 可用性 SLO
# 允許停機時間：(1 - 0.999) * 30 * 24 * 60 = 43.2 分鐘/月
# 錯誤預算（以請求為基礎）：0.001 * 總請求數

# 範例：每月 1000 萬次請求 → 10,000 個錯誤預算請求
# 若第 1 週消耗 5,000 個錯誤 → 在 25% 時間內燒掉 50% 預算
# → 觸發錯誤預算政策：凍結非關鍵版本

Prometheus SLO 警示規則（多視窗消耗速率）

groups:
  - name: slo_availability
    rules:
      # 快速消耗：1 小時內 2% 預算（14.4 倍消耗速率）
      - alert: HighErrorBudgetBurn
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[1h]))
            /
            sum(rate(http_requests_total[1h]))
          ) > 0.014400
          and
          (
            sum(rate(http_requests_total{status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total[5m]))
          ) > 0.014400
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "偵測到高錯誤預算消耗速率"
          runbook: "https://wiki.internal/runbooks/high-error-burn"

      # 緩慢消耗：6 小時內 5% 預算（持續 1 倍消耗速率）
      - alert: SlowErrorBudgetBurn
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[6h]))
            /
            sum(rate(http_requests_total[6h]))
          ) > 0.001
        for: 15m
        labels:
          severity: warning
        annotations:
          summary: "持續的錯誤預算消耗"
          runbook: "https://wiki.internal/runbooks/slow-error-burn"

PromQL 黃金訊號查詢

# 延遲 — 第 99 百分位請求持續時間
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))

# 流量 — 依服務區分的每秒請求數
sum(rate(http_requests_total[5m])) by (service)

# 錯誤 — 錯誤率比率
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
  /
sum(rate(http_requests_total[5m])) by (service)

# 飽和度 — CPU 節流比率
sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)
  /
sum(rate(container_cpu_cfs_periods_total[5m])) by (pod)

瑣事自動化腳本（Python）

#!/usr/bin/env python3
"""自動修復：重新啟動超過錯誤閾值的 Pod。"""
import subprocess, sys, json

ERROR_THRESHOLD = 0.05  # 5% 錯誤率觸發重新啟動

def get_error_rate(service: str) -> float:
    """查詢 Prometheus 取得當前錯誤率。"""
    import urllib.request
    query = f'sum(rate(http_requests_total{{status=~"5..",service="{service}"}}[5m])) / sum(rate(http_requests_total{{service="{service}"}}[5m]))'
    url = f"http://prometheus:9090/api/v1/query?query={urllib.request.quote(query)}"
    with urllib.request.urlopen(url) as resp:
        data = json.load(resp)
    results = data["data"]["result"]
    return float(results[0]["value"][1]) if results else 0.0

def restart_deployment(namespace: str, deployment: str) -> None:
    subprocess.run(
        ["kubectl", "rollout", "restart", f"deployment/{deployment}", "-n", namespace],
        check=True
    )
    print(f"已重新啟動 {namespace}/{deployment}")

if __name__ == "__main__":
    service, namespace, deployment = sys.argv[1], sys.argv[2], sys.argv[3]
    rate = get_error_rate(service)
    print(f"{service} 的錯誤率：{rate:.2%}")
    if rate > ERROR_THRESHOLD:
        restart_deployment(namespace, deployment)
    else:
        print("在 SLO 閾值內 — 無需動作")

文件