單一 ChaosExperiment（PodChaos pod-kill、NetworkChaos delay）只能驗證一個故障面向。真實的可靠性驗證需要多步驟編排：先注入依賴延遲，觀察 steady state 是否維持，再注入節點失效，最後驗證恢復路徑。Chaos Workflow 提供這個編排能力，把多個 fault injection 與 health check 組成可重播的驗證流程。

experiment scope 的精準控制同樣關鍵。selector 選到 production 全部 pod 的 chaos experiment 會變成真實事故。scope control 的責任是讓 blast radius 從最小範圍開始，逐步放大，每一步都有停止條件。

Chaos Workflow 設計

Chaos Workflow 是多個 ChaosExperiment 與 StatusCheck 組成的 DAG（有向無環圖），用 YAML 定義步驟順序與分支條件。

步驟類型

StatusCheck 是 workflow 的核心控制面。它在故障注入前後對目標 endpoint 做 health check，pass/fail 決定 workflow 是否繼續。StatusCheck 的 success condition 對應 6.22 steady state definition 的穩態門檻：success rate、latency、queue lag 都能作為 probe 判準。

典型 workflow 編排：NetworkChaos(delay 200ms) → StatusCheck(api-latency-ok) → PodChaos(pod-kill) → StatusCheck(recovery-within-30s)。第一個 StatusCheck 驗證延遲注入後服務仍可用；第二個 StatusCheck 驗證節點失效後恢復時間可接受。

Suspend 的使用時機

Suspend 步驟適合放在 blast radius 擴大之前。例如先在 canary namespace 跑完 chaos + StatusCheck，通過後 Suspend 等待值班工程師確認，再擴大到 production namespace。Suspend 讓自動化 workflow 在關鍵決策點保留人工判斷。

Experiment Scope Control

Scope control 的責任是讓每個 ChaosExperiment 的影響面可預測、可限制。Chaos Mesh 用 selector + mode 兩層控制。

Selector

Selector 決定哪些 pod 是實驗目標。

最安全的起點是 namespace + labelSelector + annotation 三層組合：只在 canary namespace、只選帶 chaos-eligible annotation 的特定服務 pod。annotation-based opt-in 讓團隊明確標記哪些 pod 可以被 chaos 觸及。

Mode

Mode 決定在 selector 命中的 pod 中選多少個。

從 mode: one 開始驗證基礎假設，確認 StatusCheck 通過後，逐步升級到 fixed-percent: 25 → fixed-percent: 50。每一步放大前檢查 steady state 是否仍維持，這個節奏對應 6.20 experiment safety boundary 的漸進放大原則。

Duration 與 Schedule

duration 控制單次故障注入持續多久，schedule 控制實驗重複頻率。duration 太短可能看不到系統完整的退化與恢復循環；太長則增加實際風險。初始建議：duration 設為 recovery SLA 的 2-3 倍（例如 RTO 30s 則 duration 設 60-90s），讓觀測窗涵蓋完整恢復。

實作範例

一個完整的 Chaos Workflow：先對 checkout 服務注入網路延遲，驗證 API 仍可用，再 kill pod 驗證恢復。

 1apiVersion: chaos-mesh.org/v1alpha1
 2kind: Workflow
 3metadata:
 4  name: checkout-resilience-验证
 5  namespace: chaos-testing
 6spec:
 7  entry: main
 8  templates:
 9    - name: main
10      templateType: Serial
11      children:
12        - network-delay
13        - check-api-health
14        - pod-kill
15        - check-recovery
16    - name: network-delay
17      templateType: NetworkChaos
18      networkChaos:
19        action: delay
20        delay:
21          latency: "200ms"
22        selector:
23          namespaces: [canary]
24          labelSelectors:
25            app: checkout
26        mode: one
27        duration: "60s"
28    - name: check-api-health
29      templateType: StatusCheck
30      statusCheck:
31        type: HTTP
32        http:
33          url: "http://checkout.canary/health"
34          criteria:
35            statusCode: "200"
36        timeoutSeconds: 30
37        failureThreshold: 3
38    - name: pod-kill
39      templateType: PodChaos
40      podChaos:
41        action: pod-kill
42        selector:
43          namespaces: [canary]
44          labelSelectors:
45            app: checkout
46        mode: one
47    - name: check-recovery
48      templateType: StatusCheck
49      statusCheck:
50        type: HTTP
51        http:
52          url: "http://checkout.canary/health"
53          criteria:
54            statusCode: "200"
55        timeoutSeconds: 60
56        failureThreshold: 5

GitOps 整合

Workflow 定義存在 git repo，用 ArgoCD 或 Flux sync 到 cluster。變更 chaos experiment 走 PR review，跟 code 變更同樣的 approval 流程。這讓 experiment 的修改歷史可追蹤、可審計。

RBAC 約束

Chaos Mesh 的 ServiceAccount 權限需要最小化。production namespace 的 chaos experiment 應使用獨立 ServiceAccount，只授予目標 namespace 的 ChaosExperiment create/get/list 權限。避免使用 cluster-admin 角色跑 chaos — 權限過大會讓 selector 誤配時的影響面不可控。

邊界與陷阱

StatusCheck timeout 太短：服務在 pod-kill 後需要 readiness probe 通過、load balancer 更新、cache 預熱。若 StatusCheck 的 timeoutSeconds 設太短，服務還在恢復中就被判失敗，產生 false negative。初始 timeout 建議設為預期恢復時間的 2 倍。

Selector 太寬：namespace-level selector 不加 labelSelector 會命中該 namespace 所有 pod，包含 sidecar、monitoring agent 等非目標 pod。永遠用 labelSelector 或 annotationSelector 收窄範圍。

Privilege 需求：Chaos Mesh 的 IOChaos 和 StressChaos 需要 container 的 SYS_ADMIN / SYS_PTRACE capability。安全團隊可能限制這些 capability 的使用。若無法取得 privilege，可以先用 PodChaos + NetworkChaos（不需額外 capability）建立 chaos 習慣，再逐步推進。

K8s-only 限制：Chaos Mesh 只能注入 Kubernetes 上的故障。非 K8s 環境的依賴（外部 SaaS、bare-metal DB、第三方 API）需要用 Toxiproxy（TCP-level fault）或 Gremlin（跨平台 SaaS）補充。

整合路由

• 上游概念：6.20 Experiment Safety Boundary — selector + mode 對應 blast radius 設計
• 上游概念：6.22 Steady State Definition — StatusCheck 對應穩態門檻
• 下游交接：6.23 Verification Evidence Handoff — Workflow 結果作為 release gate 證據
• 平行 vendor：LitmusChaos、Gremlin、Toxiproxy
• 案例回寫：Netflix N1（steady state hypothesis）、Netflix N2（business-hours guardrails 對應 scope control）

Load test 跑完會產生大量指標，但 CI pipeline 需要的是 pass/fail 訊號。若沒有 threshold 把指標轉成判讀結論，效能退化只能靠人工看 dashboard 發現，等到看見時通常已經累積數個版本。

另一面，threshold 的判讀品質取決於 workload model 的真實度。用 --vus 10 --duration 30s 跑出來的結果跟 production 流量結構差距太大時，threshold 通過也無法證明 production 安全。

這篇處理兩個問題：怎麼設 threshold 讓 CI gate 可靠，怎麼設 scenario 讓 workload 接近真實。

Threshold 設計

Threshold 的責任是把 load test 指標轉成 CI 的 pass/fail 訊號。k6 在所有 threshold 都通過時回傳 exit code 0，任一 threshold 失敗就回傳非零 — CI pipeline 直接用 exit code 判斷。

多指標 threshold

單一指標 threshold 容易漏風險。latency 正常但 error rate 偏高代表系統在丟請求；throughput 正常但 latency 偏高代表排隊開始堆積。完整的 threshold 至少涵蓋三個面向：

1export const options = {
2  thresholds: {
3    http_req_duration: ['p(95)<500', 'p(99)<1000'],
4    http_req_failed:   ['rate<0.01'],
5    http_reqs:         ['rate>100'],
6  },
7};

latency threshold 用 percentile 而不是 average — average 會被長尾稀釋，p95/p99 更接近使用者感知的最差體驗。

門檻來源

Threshold 的門檻從 production baseline 出發。先從 observability 系統（Grafana / Datadog）取最近 7-30 天的 p95/p99 latency 與 error rate，加上可接受退化幅度（通常 10-20%）作為 threshold。門檻太緊會讓 CI 環境噪音觸發 false positive；門檻太寬會讓真退化滑過去。

校準節奏：每月或每次重大架構變更後重新對齊 production baseline，避免 threshold 跟真實系統漂移。

Path-level threshold

不同 API path 的效能特徵不同。checkout 路徑的 latency 容忍度可能比 listing 路徑低很多。k6 的 group + tag 機制讓 threshold 可以按 path 設定：

 1import { group } from 'k6';
 2
 3export default function () {
 4  group('checkout', function () {
 5    // checkout 請求
 6  });
 7  group('listing', function () {
 8    // listing 請求
 9  });
10}
11
12export const options = {
13  thresholds: {
14    'http_req_duration{group:::checkout}': ['p(95)<300'],
15    'http_req_duration{group:::listing}':  ['p(95)<800'],
16  },
17};

path-level threshold 讓 gate 的判讀粒度從「整體效能」細化到「關鍵路徑效能」。

Scenario 設計

Scenario 的責任是讓壓測的流量結構接近 production。k6 提供五種 scenario executor，選擇取決於要控制什麼變量。

Executor 選擇判準

constant-vus 最簡單，但 throughput 會隨 response time 波動 — 伺服器變慢時 RPS 自動下降，掩蓋了真正的壓力。constant-arrival-rate 控制 RPS 穩定，能讓 threshold 的判讀基準一致，但需要設定足夠的 preAllocatedVUs 避免 k6 因為 VU 不足而主動降速。

CI regression 測試建議用 constant-arrival-rate：輸入固定、輸出可比較、版本間的差異才有意義。

Production traffic shape 對齊

用 ramping-arrival-rate 模擬 production 的流量形狀：

 1export const options = {
 2  scenarios: {
 3    peak_simulation: {
 4      executor: 'ramping-arrival-rate',
 5      startRate: 50,
 6      stages: [
 7        { target: 200, duration: '2m' },  // ramp up
 8        { target: 200, duration: '5m' },  // sustain peak
 9        { target: 50,  duration: '1m' },  // ramp down
10      ],
11      preAllocatedVUs: 300,
12    },
13  },
14};

流量形狀的參數（startRate / target / duration）從 production access log 的 peak 時段推算。Shopify 的 BFCM 準備流程把 game day 的 load test scenario 跟實際峰值形狀對齊 — 短時間爆量加高寫入比例需要特別設計 scenario 來覆蓋。

Cohort 模擬

Production 流量不是單一類型。用多 scenario 並行模擬不同 cohort：

 1export const options = {
 2  scenarios: {
 3    read_traffic: {
 4      executor: 'constant-arrival-rate',
 5      rate: 150, exec: 'readFlow',
 6      preAllocatedVUs: 200,
 7      duration: '5m',
 8    },
 9    write_traffic: {
10      executor: 'constant-arrival-rate',
11      rate: 30, exec: 'writeFlow',
12      preAllocatedVUs: 50,
13      duration: '5m',
14    },
15  },
16};
17
18export function readFlow() { /* GET 請求 */ }
19export function writeFlow() { /* POST 請求 */ }

讀寫比例從 production 的 access log 或 APM 資料推算。比例偏差會讓瓶頸位置失真 — 讀為主的模型抓不到寫入引起的 lock contention。

資料驅動

測試資料用 SharedArray 載入，避免每個 VU 各自載入造成記憶體浪費：

1import { SharedArray } from 'k6/data';
2
3const users = new SharedArray('users', function () {
4  return JSON.parse(open('./users.json'));
5});

資料來源可以是 production sample（脫敏後）或 synthetic generation。資料分佈需要接近 production — ID 範圍、key 分佈、payload 大小都會影響 query plan 與 cache 行為。

CI 整合實務

Fast path（每次 push）

固定 scenario + 短 duration（30s-2min），用 constant-arrival-rate 做 regression 偵測。threshold 設在 production baseline + 10%。這一層的目的是快速攔住明顯退化，不需要模擬完整峰值。

Slow path（merge gate）

完整 scenario + 較長 duration（5-15min），包含多 cohort 與 ramping 模擬。threshold 涵蓋 path-level 指標。這一層的目的是深層驗證變更在接近真實壓力下的行為。

結果留存

k6 結果預設輸出到 stdout。CI 整合時用 --out flag 把結果送到時序資料庫（InfluxDB / Prometheus Remote Write / Grafana Cloud k6），讓歷史趨勢可查詢。趨勢比較能偵測 threshold 內但持續惡化的 slow drift。

LinkedIn 的自動化壓測實踐把 load test 結果跟容量預測接在一起 — saturation point 隨時間的變化趨勢直接驅動擴容決策。

邊界與陷阱

Threshold variance：CI runner 的硬體差異（shared runner 的鄰居效應、network jitter、GC pause）會讓同一份 code 在不同 run 產生不同結果。控制方式：dedicated runner 消除鄰居效應、warmup iteration 丟棄前幾輪結果、多次 run 取中位數。若 variance 超過 threshold 的退化幅度，gate 判讀就不可信。

門檻過寬或過緊：threshold 永遠通過代表 gate 形同虛設；threshold 頻繁 false positive 會讓團隊忽略 CI 結果。兩者都會讓 gate 失去判讀價值。校準的判準是：過去 30 天的 threshold 結果中，真正需要關注的退化是否都被攔住，同時 false positive 率低於 5%。

Scenario 跟 production drift：production 的流量結構會隨產品演進改變。定期（每月或每次重大功能上線）用 access log 校準 scenario 的 RPS、cohort 比例與資料分佈，避免模型越跑越偏。

整合路由

• 上游概念：6.2 load testing 的 workload model 設計
• 下游能力：6.13 performance regression gate 的 baseline 管理與退化定位
• 平行 vendor：Gatling、Locust、JMeter
• 案例回寫：Shopify BFCM 容量治理（game day load test 對齊峰值形狀）、LinkedIn Automated Load Testing（持續壓測驅動容量預測）

SLO 從定義到 Prometheus 落地需要多層 rule。一個 SLO 對應 4 組 time window 的 recording rule（計算各窗口的 burn rate），再對應 fast burn 和 slow burn 兩組 alerting rule。手動維護這些 rule 容易出錯：window 參數不一致、新增 SLO 忘記補 alert、修改 SLI expression 只改了部分 rule。

Sloth 的責任是把這個過程自動化。輸入一份 SLO YAML，產出一組完整的 Prometheus recording + alerting rules，讓 SLO 維護回到宣告式：改 YAML、重新生成、載入 Prometheus。

SLO YAML 設計

Sloth YAML 的核心結構是 version → service → slos[]。每個 SLO 定義三件事：目標數字（objective）、量測方式（SLI）、告警等級（alerting）。

 1version: prometheus/v1
 2service: checkout-api
 3slos:
 4  - name: availability
 5    objective: 99.9
 6    description: "checkout API 的請求成功率"
 7    sli:
 8      events:
 9        error_query: sum(rate(http_requests_total{service="checkout",code=~"5.."}[{{.window}}]))
10        total_query: sum(rate(http_requests_total{service="checkout"}[{{.window}}]))
11    alerting:
12      name: CheckoutAvailability
13      page_alert:
14        labels:
15          severity: critical
16      ticket_alert:
17        labels:
18          severity: warning

SLI 有兩種類型。events-based SLI 用 error/total ratio 定義，Sloth 自動把 {{.window}} 參數代入各 recording rule 的 range vector。raw SLI 直接寫 PromQL expression 算 error ratio，適合非 request-based 的 SLO（如 data freshness、replication lag）。

raw SLI 範例 — data freshness：

1  - name: data-freshness
2    objective: 99.5
3    sli:
4      raw:
5        error_ratio_query: |
6          1 - clamp_max(
7            replication_lag_seconds{service="checkout-db"} / 60,
8            1
9          )

objective 數字的來源是 6.6 SLO 政策 — 先從使用者旅程定義服務承諾，再把承諾轉成 objective。Sloth 不負責決定 objective 該是多少，只負責把 objective 轉成可執行的 Prometheus rule。

alerting 分 page（嚴重，觸發即時通知）和 ticket（一般，產生工單）。兩者的 burn rate 門檻不同：page 用 fast burn window，ticket 用 slow burn window。label 設計跟 Alertmanager routing 對齊 — severity: critical 走 PagerDuty / Slack alert channel，severity: warning 走 ticket system（Jira / Linear）。

Multi-window Multi-burn-rate Alert

Sloth 預設產生 Google SRE 推薦的 4-window alert 結構。每個 SLO 生成以下 recording rules 和 alerting rules。

fast burn alert 回答「error budget 是否正在被快速吃掉」。當 5 分鐘窗口的 burn rate 超過 14.4 倍（代表如果持續下去，1 小時會消耗完整個月的 budget），觸發 page。這個門檻的設計邏輯是：越短的窗口允許越高的 burn rate 容忍，因為短窗口的 false positive 率較高，需要搭配較長窗口的確認。

slow burn alert 回答「error budget 是否在不被注意的情況下被緩慢消耗」。6 小時窗口的 burn rate 超過 1 倍（代表月底會剛好用完 budget），觸發 ticket。slow burn 常被忽略，但它是高變更頻率服務最常見的可靠性退化模式 — 每次小回歸都不夠大到觸發 fast burn，累積到月底才發現 budget 已透支。

burn rate alert 跟 6.6 SLO error budget 政策 直接對應：fast burn → 凍結變更；slow burn → 提高驗證門檻；budget 健康 → 正常發版。

Sloth 產出的 recording rule 範例（5m window）：

1- record: slo:sli_error:ratio_rate5m
2  expr: |
3    sum(rate(http_requests_total{service="checkout",code=~"5.."}[5m]))
4    /
5    sum(rate(http_requests_total{service="checkout"}[5m]))
6  labels:
7    sloth_service: checkout-api
8    sloth_slo: availability

對應的 alerting rule（fast burn）：

1- alert: CheckoutAvailabilityFastBurn
2  expr: |
3    slo:sli_error:ratio_rate5m{sloth_slo="availability"} > (14.4 * 0.001)
4    and
5    slo:sli_error:ratio_rate1h{sloth_slo="availability"} > (14.4 * 0.001)
6  labels:
7    severity: critical

fast burn alert 要求 5m 和 1h 兩個窗口同時超過門檻，短窗口防止 spike false positive、長窗口確認趨勢持續。

實作流程

CLI 生成

1sloth generate -i slo.yaml -o rules.yaml
2sloth validate -i slo.yaml

generate 產出的 rules.yaml 包含所有 recording rules 和 alerting rules，直接放入 Prometheus 的 rule_files 載入。validate 在 CI 中先行檢查 YAML 格式與 SLI expression 語法。

K8s Operator mode

Sloth 提供 K8s Operator，用 PrometheusServiceLevel CRD 定義 SLO。Operator 自動 reconcile，把 CRD 轉成 Prometheus rules 並同步到 Prometheus Operator 的 PrometheusRule 資源。

Operator mode 適合 K8s-native 環境：SLO 定義跟 service deployment 放在同一個 GitOps repo，變更 SLO 跟變更服務走同一套 PR review + CI 流程。

CI / GitOps 整合

在 CI pipeline 中跑 sloth validate 驗證 YAML，再跑 sloth generate 產出 rules，commit 進 GitOps repo。Prometheus 透過 config reload 或 Operator reconcile 載入新 rules。這條流程讓 SLO 變更有版本歷史、有 review、有 rollback 能力。

邊界與陷阱

Sloth 只支援 Prometheus 作為後端。若觀測平台是 Datadog、New Relic、Honeycomb 或 Grafana Cloud，需要各平台自己的 SLO 功能或 Nobl9 的 multi-source 整合。

SLI expression 錯誤是最常見的問題。分母為零（service 沒有流量）會產生 NaN，cascading 到所有 recording rule。label 不匹配（service label 拼錯）會產生空 series，alert 永遠不觸發。sloth validate 檢查語法但不檢查 Prometheus 中是否真的有對應 series — 上線後需要用 Prometheus query 確認 recording rule 產出非空結果。

SLO 數量增長會累積 recording rule 成本。每個 SLO 產生約 30 條 recording rule（4 windows × 多組 aggregation）。100 個 SLO 產生 3000 條 rule，Prometheus 的 rule evaluation 會消耗明顯的 CPU 和記憶體。定期監控 prometheus_rule_evaluation_duration_seconds 和 prometheus_rule_group_rules，在 rule 數量影響 evaluation latency 前調整。

升級路徑：Sloth YAML 跟 OpenSLO spec 部分相容。從 Sloth 移到 Nobl9 時，SLO 定義的語意可以保留，SLI expression 需要改寫成 Nobl9 的 data source query。這條路徑適合從 Prometheus-only 環境逐步擴展到 multi-source SLO governance。

整合路由

• 上游：6.6 SLO 與 Error Budget 政策 — SLO 定義與 objective 來源
• 下游：6.8 Release Gate — burn rate alert 觸發凍結
• 平行：Nobl9（SaaS multi-source）、Pyrra（K8s-native + UI）
• 案例回寫：Google G1（error budget policy 原典）、Honeycomb HC1（burn rate 驅動可靠性操作）

本章目標

讀完本章後、你應該能：

1. 寫 workflow（.github/workflows/*.yml）
2. 設計 PR check + matrix testing
3. 用 reusable workflows / composite actions 復用
4. 配置 environment protection + approval gate
5. 用 OIDC + cloud auth（無 long-lived secret）

最短路徑：5 分鐘把 GitHub Actions 跑起來

1# .github/workflows/ci.yml
2name: CI
3on: [pull_request]
4jobs:
5  test:
6    runs-on: ubuntu-latest
7    steps:
8      - uses: actions/checkout@v4
9      - run: npm test

日常操作與決策形狀

Workflow 設計

子議題：

• on triggers（push / pull_request / schedule / workflow_dispatch / repository_dispatch）
• job / step / action
• Matrix（OS / language version / test split）
• 對應指令範例：gh workflow run、gh run list

Cache 策略

子議題：

• actions/cache（語言依賴 / build cache）
• Cache key 設計（hashFiles + version）
• Cache scope（per branch / per repo）
• 對應 build speed optimization

Reusable workflows / composite actions

子議題：

• Reusable workflow：跨 repo 引用整個 workflow
• Composite action：把多 step 包成 action
• 對應 knowledge cards reusable-action (對應 DRY)

進階主題（按需閱讀）

Self-hosted runner

子議題：

• 內網資源 / 特殊硬體（GPU）/ macOS
• Runner group + scaling
• Security：ephemeral runner（每次新建）
• 對應 07 security

OIDC + cloud auth

子議題：

• GitHub OIDC provider
• AWS / GCP / Azure 信任 GitHub
• 無 long-lived access key
• 對應 supply chain security

Environment protection

子議題：

• environment（dev / staging / prod）
• Required reviewers
• Wait timer
• Secrets per-environment
• 對應 6.8 Release Gate

Workflow security

子議題：

• pull_request vs pull_request_target（後者有 secrets / 危險）
• third-party action pinning（commit SHA）
• GITHUB_TOKEN permissions（最小化）

Deploy workflow

子議題：

• Deploy on tag / release
• Rolling deploy / blue-green / canary
• Rollback action

排錯快速判讀

Workflow 沒觸發

操作原則：on trigger 配置 / branch filter / paths filter。判讀：Actions tab 看 trigger event。

Permission denied

操作原則：GITHUB_TOKEN permissions 不夠。判讀：workflow 加 permissions: 區段。

Cache miss

操作原則：cache key 不穩定 / hashFiles input 變化。

Secret 沒生效

操作原則：secret name / environment 不對 / pull_request from fork 不能用 secret。

Self-hosted runner 卡住

操作原則：runner offline / job queue 滿 / runner group 配置不對。

何時改走其他服務

不在本頁內的主題

• 各 Marketplace action 細節
• GitHub Enterprise self-host
• Actions pricing
• 各語言 setup-* action 細節

案例回寫

待補 GitHub Actions customer case：大規模 monorepo Actions 採用、OIDC migration、self-hosted runner scaling 案例。

下一步路由

• 上游概念：6.8 Release Gate
• 平行 vendor：CircleCI
• 下游能力：07 security（supply chain）、5 deployment（deploy gate）

規劃重點

• SLI / SLO / Error Budget：可靠性目標的量化方法、為何選 SLO 而非 100%
• Postmortem 文化：blameless / action items / 行動追蹤的閉環設計
• Toil 量化：把運維工作變成可預算的工程資產
• on-call 與 burnout：值班輪值、shadow / primary 結構、心理安全
• readiness review：服務上線前的 SRE 接管門檻

預計收錄實踐

章節列表

案例定位

Google 這個案例在講的是可靠性如何變成一套可操作的工程制度，而不是單一工具或單一事故。讀者先抓到 SLI / SLO、error budget、postmortem 與 toil 這幾個原語各自負責什麼，再把它們組成一條可執行的可靠性路徑。

判讀重點

當服務健康開始波動時，先看 SLO 是否真的被消耗，再看監控與告警是否能對應到使用者體感。當 on-call 壓力升高時，重點在團隊是否把重複性工作轉成可預算的工程投資，個人技巧層面的改善幫助有限。

可操作判準

• 能否用一句話說明每個 SLI 對應的使用者行為
• 能否從 postmortem 找到明確 owner 與完成條件
• 能否把 toil 量化成可排程的工程時間
• 能否把監控、測試、容量、開發與產品決策串成同一條路由

與其他案例的關係

Google 提供的是可靠性的語言層，其他案例提供的是具體場景層。當讀者先懂 SLI / SLO 與 postmortem 這組原語，再看 Honeycomb 的 burn rate、Atlassian 的復原節奏或 GitHub 的 status communication，就能把抽象制度接到實際事故上。

代表樣本

• SLO 與 error budget 讓團隊把可靠性變成可量化的工程目標。
• postmortem 將事故轉成可追蹤的 action items，而不是只留下檢討文字。
• toil budget 讓重複性工作變成可預算的工程投資。
• readiness review 讓服務在上線前先過可靠性門檻。
• on-call 與 burnout 讓值班成為組織設計問題，脫離個人耐力測試的框架。
• hierarchy of reliability 讓 monitoring、testing、capacity、dev、product 串成一條路由。
• blameless culture 讓檢討聚焦在系統與流程，而不是個人責任。
• embedded SRE / consulting 讓可靠性能力可以以不同介入深度落到服務團隊。

引用源

• sre.google：Google SRE 官方資源入口，收錄 books 與主題更新。
• The SRE book turns 6!：整理 SRE Book / Workbook 與延伸資源的官方入口。
• Adopting SRE: Standardizing your SLO design process：補 SLO 設計方法與實務語境。

CI pipeline 把快速回饋、慢速驗證與可重現產物切成不同層，讓每次變更都能在一致條件下被判讀。

這一層關心的是「變更能不能被穩定驗證」。pipeline 的價值在於分層、隔離與可追蹤，讓 flaky 訊號不會直接污染放行判斷。

核心判讀

CI 的健康度先看回饋節奏，再看訊號品質。fast path 應該覆蓋最常見的破壞面，slow path 負責深層驗證，artifact 則要能從同一份輸入重播。

判讀時先看四件事：

• stage 是否按成本與風險分層
• artifact 是否重用，不是每次從 source 重建
• environment variables 是否封裝，避免跨環境漂移
• flaky test 是否有治理路徑，而不是只靠 retry

分層策略

CI 分層的責任是讓不同成本的驗證跑在不同時機，讓最常見的破壞面最快被攔住，高成本驗證只在值得時跑。

Fast path

fast path 在每次 push 觸發，目標是 5 分鐘內回饋。涵蓋 lint、type check、unit test 與 contract test。這一層只驗證單一變更的語法與邏輯正確性，不碰外部依賴。

fast path 結果可信的條件是測試不依賴外部狀態。當 unit test 需要真實 DB 或 broker，它就不再屬於 fast path — 移到 slow path，或用 contract test 替代跨服務驗證。

Slow path

slow path 在 merge request 觸發，允許較長執行時間（15-45 分鐘）。涵蓋 integration test、security scan、load baseline 與跨服務 schema 相容性。這一層用真實依賴驗證變更在服務邊界上的行為。

Microsoft 的變更治理實踐把變更按風險分層，高風險變更（schema migration、payment path、config rollout）走更完整的 slow path，低風險變更只需 fast path 通過。這種分層讓 CI 資源集中在真正需要深層驗證的變更上，同時維持低風險變更的交付速度。

Scheduled path

scheduled path 定期（每日或每週）執行，涵蓋 full regression、fuzz campaign、chaos smoke test 與長時間 soak test。這一層驗證的是累積退化，而不是單次變更的破壞。

scheduled path 的判讀不看單次 pass/fail，而是看趨勢：coverage delta 是否持續下降、fuzz corpus 是否收斂、regression 新增 failure 是否集中在特定模組。

Artifact 管理

Artifact 讓同一份 build output 能從 CI 一路到 staging 到 production，每一步都可重播。

immutable artifact 的核心約束是 build 一次、部署多次。CI 產出的 container image 或 binary 帶版本標籤（commit hash + build number），後續環境不重新 build，只替換 config。這樣才能確保 staging 驗證通過的產物跟 production 部署的產物是同一份。

cache 策略影響 CI 回饋速度與可信度的平衡。dependency cache（npm / go mod / pip）加速 build，但需要定期 invalidation 避免過期依賴殘留。build output cache 則需要嚴格的 key 設計，確保 source 變更後不會沿用舊 artifact。

Stripe 的零停機遷移實踐對 artifact 有額外要求：交易路徑的變更需要 artifact 能重播到相同狀態，確保 idempotency 驗證在 CI 與 production 看到一致的行為。

Flaky test 治理

flaky test 的責任是讓 CI 訊號維持可信度。當 flaky 率持續上升，團隊會開始忽略 CI 結果，pipeline 從可靠性 gate 退化成形式流程。

識別

flaky 識別靠 retry 分析。當同一個 test case 在同一份 commit 上連續跑出不同結果，那就是 flaky 候選。按連續失敗 / 成功交替的頻率排序，比按失敗率排序更能抓到高噪音來源。

隔離

quarantine queue 是把已識別的 flaky test 從 gate-blocking path 移到 non-blocking path。quarantine 的目的是保護 gate 判讀可信度，同時維持 flaky 修復的追蹤壓力。quarantine 不是永久停靠 — 超過修復期限的 flaky test 必須決定是修復還是刪除。

判讀門檻

flaky 率超過 5% 時，CI gate 的訊號開始失真：團隊無法確定 failure 是真回歸還是 flaky。超過 10% 時，CI pipeline 實質上失去 gate 功能 — retry 變成常態，failure 預設被忽略。此時應暫停新功能開發，集中修復 flaky backlog。這些門檻是基於中大型測試套件（500+ test cases）的經驗值。測試套件較小時，單一 flaky test 的比率衝擊更大，門檻應更低。

Environment 隔離

CI 環境的隔離程度決定了測試結果的可信度下限。

Runner 隔離

shared runner 會把不同 PR 的測試跑在同一台機器上。當 integration test 需要佔用 port、寫入 local state 或消耗大量記憶體，跨 job 干擾就會出現。ephemeral runner（每次 job 用乾淨環境）消除這類問題，但成本更高。判斷點是測試是否依賴 local state — 有依賴就用 ephemeral。

Secret 管理

CI secret（API key、DB credential、cloud token）需要按環境隔離。staging secret 不應該在 PR pipeline 可用，production secret 不應該在 staging pipeline 可用。secret 洩露的常見路徑是 CI log 輸出與 artifact 殘留 — 兩處都需要遮罩。

Load test 資源池

LinkedIn 的容量 headroom 實踐把自動化壓測接進 CI。當 load test 跑在 CI 環境時，需要獨立資源池，避免壓測流量影響其他 pipeline job 的執行速度與穩定性。load test runner 的 quota 跟一般 CI runner 分開管理。

CI 作為 Release Gate 輸入

CI 的最終產出不只是 pass/fail，而是一組可供 release gate 判讀的 evidence。

Google 的 error budget 政策把 CI 定位成 release gate 的前置訊號來源：CI pipeline 產出的 evidence 直接進入 error budget 判讀流程。當 budget 消耗加速時，CI gate 的門檻隨之提高 — 從只需 fast path 通過，升級到要求 slow path 全部通過加人工 review。

案例對照

• Google：CI pipeline status 是 error budget 政策的前置訊號，budget 消耗速度直接影響 CI gate 門檻高低。
• Microsoft：按變更風險分層走不同 CI path，高風險變更需要更完整的 slow path 驗證。
• LinkedIn L1：容量 headroom 綁值班分層，CI 回饋是容量決策的輸入。
• LinkedIn L2：自動化壓測接進 CI，load test 需要獨立資源池避免干擾其他 pipeline job。
• Stripe：交易路徑的 idempotency 測試在 CI 跑，artifact 必須能重播到相同狀態。

判讀訊號

交接路由

• 6.10 contract testing：把跨服務契約納入 CI fast path
• 6.13 perf regression gate：把效能 baseline 變成 CI slow path gate
• 6.15 environment parity：CI 環境隔離是 parity 的前置條件
• 6.16 test data：把 fixture / seed 納入 CI artifact 管理
• 6.8 release gate：CI evidence 是 release gate 的主要輸入
• 6.23 evidence handoff：CI artifact checksum 進入證據交接

CI pipeline 的可靠性驗證在測試階段結束後，還需要兩道控制面才算完整。第一道是 deploy approval gate — 決定誰可以核准 production deploy、在什麼條件下放行。第二道是 credential 安全 — deploy 需要 cloud credential，但 long-lived secret 存在 CI 環境中會擴大洩漏面。

GitHub Actions 用 environment protection rules 處理第一道，用 OIDC federation 處理第二道。兩者搭配讓 deploy 流程同時滿足 6.8 release gate 的放行控制與 07 資安 的 credential 最小暴露原則。

Environment Protection Rules

Environment 是 GitHub Actions 的 deploy 分層單位。每個 environment（staging / canary / production）可以獨立設定 protection rules，讓不同風險等級的 deploy 走不同的放行流程。

Protection rule 類型

Required reviewers 是 deploy 層的 release gate。當 workflow job 標記 environment: production，GitHub 會暫停 job 直到指定 reviewer 核准。reviewer 的選擇應對齊服務 ownership — 由該服務的 on-call lead 或 tech lead 核准，避免核准權過於集中或分散。

Wait timer 提供一個緩衝窗口。deploy 前等待 N 分鐘讓團隊有時間檢查 staging 結果、確認沒有進行中的事故、或在發現問題時取消 deploy。timer 長度跟服務風險等級對齊 — 低風險服務可以 0 分鐘，交易路徑可以 15-30 分鐘。

Deployment branch policy 限制哪些 branch 可以觸發特定 environment 的 deploy。這防止 feature branch 意外 deploy 到 production。production 通常只接受 main 或 release branch。

分層建議

staging 用自動 deploy — push 到 staging branch 直接觸發 workflow，無需 approval，回饋速度最大化。production 用 required reviewer + wait timer — 確保每次 production deploy 都經過人工確認與緩衝。canary 介於兩者之間 — 可以自動 deploy 但加 wait timer，讓觀測指標有時間反映。

OIDC Cloud Auth

Long-lived credential 的風險

CI deploy 需要 cloud credential（AWS access key / GCP service account key / Azure service principal）。傳統做法是把這些 credential 存在 GitHub repository secret 或 environment secret 中。long-lived credential 的風險在於：洩漏後攻擊者可以長期使用、rotation 需要手動更新 CI 設定、credential scope 常設得比實際需求更大。

OIDC federation 的運作方式

GitHub Actions 支援作為 OIDC identity provider。workflow 在執行時可以向 GitHub 請求一個 short-lived OIDC token，cloud provider 信任這個 token 後發出 short-lived cloud credential。整個流程不需要在 CI 環境中存放任何 long-lived secret。

流程：workflow 啟動 → 向 GitHub OIDC provider 請求 token → token 帶有 repo / branch / environment 等 claim → cloud provider 的 trust policy 驗證 claim → 發出 short-lived credential（通常 1 小時有效期）。

Cloud provider 配置

AWS：在 IAM 設定 OIDC identity provider（issuer: token.actions.githubusercontent.com）、建立 IAM role 並設定 trust policy 限制 repo + branch + environment。workflow 中用 aws-actions/configure-aws-credentials action 取得 session credential。

GCP：設定 Workload Identity Federation pool + provider、建立 service account 並綁定 pool。workflow 中用 google-github-actions/auth action 取得 short-lived token。

Azure：在 Azure AD 設定 federated credential 給 app registration、限制 repo + branch + environment。workflow 中用 azure/login action。

Trust policy 的安全邊界

OIDC trust policy 必須限制到特定 repo、branch 與 environment。trust policy 寫成 wildcard（信任整個 GitHub org 的所有 repo）等於讓 org 內任何 repo 的 workflow 都能取得 cloud credential。最小權限原則：production environment 的 trust policy 只信任 repo:org/service:environment:production，不信任其他 environment 或 branch。

實作範例

 1# .github/workflows/deploy.yml
 2name: Deploy
 3on:
 4  push:
 5    branches: [main]
 6
 7permissions:
 8  id-token: write
 9  contents: read
10
11jobs:
12  deploy-staging:
13    runs-on: ubuntu-latest
14    environment: staging
15    steps:
16      - uses: actions/checkout@v4
17      - uses: aws-actions/configure-aws-credentials@v4
18        with:
19          role-to-assume: arn:aws:iam::123456789012:role/staging-deploy
20          aws-region: ap-northeast-1
21      - run: ./scripts/deploy.sh staging
22
23  deploy-production:
24    needs: deploy-staging
25    runs-on: ubuntu-latest
26    environment: production
27    steps:
28      - uses: actions/checkout@v4
29      - uses: aws-actions/configure-aws-credentials@v4
30        with:
31          role-to-assume: arn:aws:iam::123456789012:role/production-deploy
32          aws-region: ap-northeast-1
33      - run: ./scripts/deploy.sh production

staging job 自動觸發。production job 等 staging 完成後暫停，等待 environment protection rules 中設定的 reviewer 核准。兩個 job 各自用不同的 IAM role，scope 分離。

Environment secret 與 repository secret 的差異：environment secret 只在該 environment 的 job 中可用。把 production-only 的設定（如 database connection string）存在 production environment secret 而非 repository secret，避免 staging workflow 意外存取 production 資源。

邊界與陷阱

Environment protection rules 在 private repo 上需要 GitHub Team 或 Enterprise 方案。Free 方案的 private repo 無法使用 required reviewers 與 wait timer，只有 public repo 或付費方案可用。

OIDC trust policy 的常見錯誤是 subject claim 設定太寬。sub claim 的格式是 repo:{owner}/{repo}:environment:{name}（使用 environment 時）或 repo:{owner}/{repo}:ref:refs/heads/{branch}（不使用 environment 時）。用 wildcard match 或省略 environment 限制會讓非預期的 workflow 取得 credential。

Wait timer 設定要跟服務風險等級對齊。所有服務統一用 30 分鐘 wait timer 會拖慢低風險服務的 deploy velocity。對齊方式：低風險服務 0 分鐘、中風險 5-10 分鐘、高風險（交易路徑）15-30 分鐘。

Required reviewer 數量跟團隊大小對齊。只有 1 個 reviewer 等於沒有四眼原則；需要 5 個 reviewer 會造成 approval 排隊。2-3 個 reviewer 是多數團隊的平衡點。

整合路由

• 上游：6.1 CI pipeline（CI gate 通過後才進入 deploy 階段）
• 下游：6.8 release gate（environment protection 是 deploy 層的 release gate）
• 下游：6.23 verification evidence handoff（deploy 結果作為 release evidence）
• 平行：CircleCI contexts + approval jobs（同類功能的不同實作）
• 案例回寫：Microsoft 變更分層（變更風險分層對應 environment 分層）、Google Error Budget（error budget 消耗時提高 gate 門檻 → 可動態調整 required reviewer 數量）

本章目標

讀完本章後、你應該能：

1. 寫 .circleci/config.yml workflow
2. 設計 cache + workspace 加速 build
3. 用 parallelism + test splitting
4. 選 resource class（CPU / memory / macOS / GPU）
5. 評估 CircleCI vs GitHub Actions 的選用

最短路徑：5 分鐘把 CircleCI 跑起來

 1# .circleci/config.yml
 2version: 2.1
 3jobs:
 4  test:
 5    docker: [{image: cimg/node:20}]
 6    steps:
 7      - checkout
 8      - run: npm test
 9workflows:
10  ci:
11    jobs: [test]

日常操作與決策形狀

Pipeline / workflow / job 模型

子議題：

• Pipeline（一次 trigger 的執行）
• Workflow（多 job 編排、DAG）
• Job（一組 step）
• 對應指令範例：circleci local execute（本地測 config）

Orb 重用

子議題：

• Orb = package of reusable config（types / commands / jobs / executors）
• Public orb registry（circleci.com/developer/orbs）
• Private orb for company

Cache + workspace

子議題：

• Cache：跨 build 保留（dependency / build artifact）
• Workspace：同 workflow 內 job 之間傳遞
• Cache key 設計（與 GitHub Actions 類似）

進階主題（按需閱讀）

Parallelism + test splitting

子議題：

• Job parallelism N
• Test splitting by timing / name / class
• 對應 test suite 加速

Resource class

子議題：

• small / medium / large / xlarge / 2xlarge
• macOS / Arm / GPU classes
• 跟 cost 平衡

Self-hosted runner

子議題：

• Runner agent
• 適合：內網 / 特殊環境

OIDC integration

子議題：

• OIDC token → AWS / GCP（無 long-lived secret）
• 跟 GitHub Actions 同 pattern

Approval job

子議題：

• type: approval job：人工介入
• 對應 6.8 Release Gate

Cross-VCS support

子議題：

• GitHub / Bitbucket / GitLab
• 跟 GitHub Actions 只 GitHub 對比

排錯快速判讀

Build 慢

操作原則：cache miss / test 沒 split / resource class 太小。

Cache 不命中

操作原則：cache key 設計問題 / key change。

Parallelism 不均勻

操作原則：test split strategy（timing 最好但要 historical data）。

Approval 卡住

操作原則：approval job 沒人按 / on-call 不在。

何時改走其他服務

不在本頁內的主題

• 各 Orb 細節
• CircleCI Server（self-host enterprise）
• Pricing 細節

案例回寫

待補 CircleCI customer case：大規模 CircleCI 採用、macOS / iOS CI 加速案例、CircleCI → GitHub Actions 遷移案例。

下一步路由

• 上游概念：6.8 Release Gate
• 平行 vendor：GitHub Actions
• 下游能力：07 security、5 deployment

規劃重點

• Chaos Monkey 起點：在 production 隨機殺實例為何能改進架構
• Simian Army 工具鏈：Latency / Janitor / Conformity 等不同維度的 chaos
• FIT：把 chaos 從 instance 層升級到 request 層、攻擊更精細
• Chaos Maturity Model：團隊採用 chaos 的能力分級
• Steady state hypothesis：chaos 實驗的科學方法基礎

預計收錄實踐

章節列表

案例定位

Netflix 這個案例在講的是故障注入如何從實驗變成工程制度。讀者要先分辨 steady state、hypothesis、blast radius 與回復條件各自扮演的角色，才能理解為什麼 chaos 是驗證服務韌性的方法，演示層面的價值是次要的。

判讀重點

當團隊只在 staging 做演練時，先看測試是否真的碰到生產流量的分布與依賴關係。當問題需要更細的干預時，再往 FIT 這種 request-level fault injection 移動，讓故障落在真正會被客戶碰到的路徑上。

可操作判準

• 能否先寫出 steady state，再設計實驗
• 能否說清楚 blast radius 與 rollback 條件
• 能否說明為何在 business hour 做 chaos 反而更安全
• 能否判斷問題需要 instance-level 還是 request-level 注入

與其他案例的關係

Netflix 把「先驗證再承擔風險」這件事做成制度，和 AWS S3、Cloudflare 這類事故頁形成對照。前者是在可控條件下主動打破假設，後者是在失敗後回頭整理假設，因此兩者一起讀才能看懂 reliability 與 incident response 的分工。

代表樣本

• Chaos Monkey 直接驗證實例被殺掉後，服務是否仍能維持 steady state。
• FIT 把故障注入從 instance 級推進到 request 級，讓實驗更貼近真實流量路徑。
• Simian Army 讓不同故障類型有各自的注入面。
• business-hour chaos 讓測試更接近真實營運節奏。
• chaos maturity model 讓團隊知道自己在採用故障注入的哪個階段。
• steady state hypothesis 讓實驗成為可證偽的工程判斷，超越單純演示。
• latency monkey 讓延遲問題成為可以主動驗證的故障型態。
• janitor / conformity 類工具把環境清理與架構規則也納入韌性管理。

引用源

• Netflix/chaosmonkey：Chaos Monkey 的現行開源實作。
• Netflix/SimianArmy Wiki: Chaos Monkey：Simian Army 舊版 wiki，說明 business-hours chaos 的基本規則。
• Netflix/SimianArmy：Simian Army 套件入口，補齊多種 monkey 的整體脈絡。

當系統需要回答「這個流量撐不撐得住」，load test 把真實 workload model 變成可重播的壓力情境，找出吞吐、延遲與瓶頸轉折點。

這一頁關心的是實際流量長什麼樣，不是把數字推高而已。模型若不接近 production shape，壓測結果就只是在驗證假場景。

核心判讀

Load test 的品質先看模型是否貼近流量結構，再看系統在 saturation 前後的行為。曲線在 saturation 前後如何變形才是關鍵，單點 throughput 只是其中一個讀數。

判讀時的關鍵面向：

• workload 是否包含尖峰、長尾與不同 cohort
• latency 是否在接近飽和時快速劣化
• bottleneck 是否能被定位到具體 resource
• load 結果是否能回寫到 capacity planning

Workload model 設計

Workload model 的責任是把 production 流量結構轉成可重播的測試情境。模型越接近真實流量的形狀，壓測結果對容量決策的支撐力越高。

設計 workload model 時先分析三個維度：

Traffic shape：production 流量很少是均勻的。峰值時段的 request rate 可能是均值的數倍到數十倍，而且峰值持續時間、上升斜率與衰退曲線各有差異。Shopify 的 BFCM 流量結構是短時間爆量加上高寫入比例；若模型只用日均流量推算，會漏掉峰值集中在數小時內的壓力集中度。模型需要把 peak / off-peak / burst 三種時段分開描述。

Cohort 拆分：讀與寫的資源消耗模式不同，混合比例會改變瓶頸位置。API gateway 層可能由讀主導，但 checkout 或 order-create 路徑的寫入比例明顯偏高。把不同 cohort（讀 / 寫 / 混合 / 背景任務）分開量測，才能判斷瓶頸是在哪個路徑上出現。

資料量對齊：staging 環境的資料量常與 production 差一到兩個數量級。query plan、index scan、connection pool 飽和與 cache 行為都跟資料量高度相關。模型要盡可能用 production-like 資料量，或至少在結果判讀時標註資料量差異帶來的偏移。

LinkedIn 的實踐揭露另一個面向：workload model 會隨時間漂移。流量結構、使用者行為與功能上線都會改變真實壓力形狀。當 load-test 模型不再定期校準，壓測結果與 production 壓力之間的差距會持續擴大。定期用 production traffic replay 或 access log 分析重建模型，是維持壓測可信度的必要動作。

判斷 workload model 是否仍然有效的實務做法：把最近一次 load test 的 latency distribution 與 production 同時段的 latency distribution 對齊。若兩者的 p50 / p95 / p99 比率偏離超過 20%，模型已經需要校準。20% 是通用起點。latency 敏感的服務（交易、即時通訊）應使用更嚴格的門檻（10%），batch 類服務可適度放寬。偏離來源通常是三個之一：流量結構變了（新功能改變 read/write 比例）、資料量成長了（query plan 改變）、依賴行為變了（上游回應時間漂移）。

Saturation 與瓶頸定位

Saturation 的轉折點決定了系統的實際容量上限 — 在什麼負載下，系統從線性擴展轉為劣化。

判讀 saturation 先看 latency curve。在低負載時，latency 通常穩定；隨著負載上升，會出現一個 inflection point，之後 latency 開始加速上升。這個轉折點通常比 throughput ceiling 更早出現，是真正的容量邊界。

在 inflection point 之後，系統行為會進入幾種退化模式。逐漸退化型的 latency 緩慢爬升，通常來自 queue 堆積或 GC 壓力加重；崩落型的 latency 在某個點突然跳升數倍，通常來自 connection pool 耗盡或 thread pool 飽和。兩種退化的應對策略不同：逐漸退化有 load shedding 的緩衝空間，崩落型需要提早在更低負載觸發限流。壓測結果需要標註系統屬於哪種退化模式，這個資訊直接影響 stop condition 的門檻設定。

瓶頸定位需要對齊資源層。常見瓶頸包括 CPU saturation、memory pressure、connection pool 耗盡、queue depth 堆積與 disk I/O。壓測時需要同步觀測這些資源指標，才能把 latency 劣化歸因到具體 resource。歸因的價值在於讓擴容或優化的投資方向可決策：CPU 瓶頸指向 compute scaling、connection pool 瓶頸指向 pool config 或 connection reuse、queue depth 瓶頸可能指向 consumer 吞吐不足。若只看 latency 劣化但不做歸因，團隊容易直覺式擴容，花了成本卻沒打到真正瓶頸。

Pinterest 的快取可靠性案例揭露一種不直覺的瓶頸類型：cache 命中率崩落時，瓶頸會從 compute 層移到 storage throughput。回源壓力瞬間上升，資料層的 I/O 成為新瓶頸。這種情境在純 compute 壓測中看不到，需要特別設計包含 cache miss 場景的 workload。實務上，cache miss 場景可以用兩種方式模擬：清空 cache 後立即打流量（cold start），或在壓測過程中讓部分 key 過期（partial eviction）。兩者暴露的瓶頸位置可能不同，cold start 偏向 storage 吞吐、partial eviction 偏向 connection pool 與 retry 放大。

Load test 與容量規劃的接口

Load test 的產出不只是 pass/fail，它是容量規劃的主要輸入。壓測結果要能轉成 headroom 計算與成本預測。

Headroom 計算：peak load 佔 capacity ceiling 的比率決定安全緩衝。比率超過 70-80% 時，任何流量突增或依賴劣化都可能觸發 saturation。headroom 的安全值跟系統的退化模式綁在一起：崩落型退化的系統需要更大 headroom，因為從健康到故障的過渡窗口很短。LinkedIn 的做法是把 headroom 預算綁到值班分層，當 headroom 低於門檻時自動升級 on-call 層級，讓容量風險直接轉成團隊行動。

成本曲線：擴容的邊際成本會在跨越 availability zone、region 或 tier 邊界時跳升。load test 結果要標註「容量到多少時需要跨越哪個擴容邊界」，讓容量規劃能把成本跳升點納入決策。這類資訊在高峰前特別有價值：團隊能提前決定是靠 load shedding 撐過峰值，還是提前擴容跨區，兩者的成本與風險完全不同。

隔離單位的容量量測：全域容量規劃在多租戶或 cell-based 架構下會失真。Amazon 的做法是按 cell 獨立量測 saturation，每個隔離單位有自己的 headroom，避免一個 cell 的容量需求拖動全域擴容。這種設計讓 load test 的量測粒度從「整個服務」降到「每個隔離單位」，容量決策更精準。

load test 結果的完整路由是：壓測產出 saturation point 與 headroom ratio → 餵給 6.9 容量與成本邊界 做容量預算 → 餵給 6.13 performance regression gate 做持續守護。

持續性 load test 與事件性壓測

Load test 的執行模式依用途分兩類，兩者設計邏輯不同。

持續性 load test 跑在 CI pipeline 中，用固定 workload 做 baseline regression 偵測。每次變更跑同一套 scenario，比較 latency 與 throughput 是否偏離 baseline。這類測試的 workload 不需要貼近峰值，但需要穩定到能偵測 5-10% 的 regression。連到 6.13 performance regression gate 做自動化 gate。

事件性壓測 針對特定事件（產品上線、促銷、峰值季節）做一次性或年度壓測。workload 設計要貼近該事件的流量形狀與資料量。Shopify 把 game day 做成年度制度化流程：每輪 BFCM 前跑容量驗證，演練結果回寫 resiliency matrix 與 runbook，讓下一輪從更高基準開始。事件性壓測的關鍵是結果留存與回寫，不是跑完就結束。

兩類測試的分工：持續性負責守住 baseline，事件性負責探索邊界。只跑持續性會漏掉峰值場景；只跑事件性會漏掉漸進退化。

判斷要用哪一類時，先問兩個問題。第一，這個服務是否有可預期的流量事件（促銷、賽季、發布日）？有的話，事件性壓測是必要的，因為峰值壓力的形狀跟日常完全不同。第二，這個服務的變更頻率是否超過每週一次？是的話，持續性 load test 是必要的，因為 regression 可能在任何一次 deploy 進入。多數生產系統兩類都需要。

環境與工具考量

Staging vs production：staging 壓測控制成本低、風險低，但跟 production 的差異（資料量、網路拓撲、依賴行為）會讓結果偏移。Production load test（dark traffic、shadow read、canary traffic）結果更可信，但需要嚴格的 blast radius 控制與 stop condition 設計。選擇哪種環境取決於系統成熟度與風險承受能力。

Synthetic traffic 的限制：synthetic 請求不帶真實 session、auth token 或 cache warm-up 狀態，行為與真實使用者不同。對 cache 敏感的系統，synthetic traffic 可能打出比真實流量更高的 miss rate，產生虛假瓶頸。對 auth 與 session 敏感的系統，synthetic 請求可能繞過 rate limit 或 WAF 路徑，壓測結果會低估 production 的真實負載。判讀時要標註 synthetic 與 real traffic 的行為差異，避免把假瓶頸或假安全當結論。

資料隔離：production load test 需要確保測試流量不會污染真實資料。常見做法包括 shadow read（讀路徑複製、寫路徑丟棄）、test tenant 隔離（獨立資料空間）、與 feature flag 控制的 dark traffic。每種做法的隔離強度與實作成本不同，選擇時要對齊系統的資料敏感度。

工具選擇路由：CI-first 場景偏向 CLI 工具（k6）、JVM 生態偏向 Gatling、Python 團隊偏向 Locust、既有 .jmx 資產偏向 JMeter。工具對照見 vendors/。

Load test 結果的證據留存

Load test 結果需要結構化留存，讓下游（容量規劃、release gate、事故決策）可以直接調用，而不是每次都要重跑或找人解釋。

留存的最小欄位：workload model 版本、測試環境、saturation point（latency inflection 的 RPS）、throughput ceiling、主要瓶頸歸因、headroom ratio、退化模式分類、測試日期。這些欄位讓 6.23 verification evidence handoff 可以把 load test 結論直接納入 release 決策，也讓 6.9 容量與成本邊界 可以追蹤 saturation point 隨時間的變化趨勢。

若結果只以 dashboard 截圖或口頭摘要留存，下次壓測時團隊無法判斷「是系統變了還是模型變了」，校準失去基準。

案例對照

• Shopify H1：高峰型流量要求 load model 涵蓋短時間爆量與高寫入比例，game day 把事件性壓測制度化。
• LinkedIn L1：headroom 預算綁值班分層，load-test drift 需要定期校準模型。
• Pinterest P1：cache 命中率崩落改變瓶頸位置，壓測要涵蓋 cache miss 場景。
• Amazon A1：cell-based architecture 讓容量規劃按隔離單位量測，避免全域擴容失控。
• LinkedIn L2：自動化壓測接入 CI pipeline，用 production traffic replay 定期更新 saturation point，讓容量預測的輸入持續校準。

產業情境：電商與零售

電商流量的核心特徵是可預期的季節性峰值（雙十一、Black Friday、Prime Day）與不可預期的閃購爆量。兩者對 workload model 的需求不同，混用同一套模型會讓壓測結論對其中一種場景失真。

季節性峰值的 workload model 需要涵蓋三個電商特有維度：流量上升斜率（開賣瞬間的階梯式爆增 vs 活動期間的漸進增長）、讀寫比例變化（瀏覽階段讀為主 → 結帳階段寫入爆增）、庫存查詢的 cache miss 率（熱門商品快取因庫存變動頻繁失效）。Shopify 的 BFCM 容量治理把這類峰值的容量驗證制度化為年度 game day。

閃購型流量的特徵是持續時間極短（分鐘級）但倍率極高（日常的 10-50 倍）。常規壓測用日均流量推算會完全漏掉這種尖峰，需要獨立的 burst scenario 模擬開賣瞬間的並發衝擊。

轉換率是電商特有的穩態指標。load test 的判讀不只看 latency 和 error rate，還要看結帳轉換率是否在壓力下劣化。研究顯示 latency 上升 100ms 可能讓轉換率下降 1-7%，這個商業影響在純技術指標中看不到。壓測結果要同時記錄技術指標與業務指標，容量決策才能對齊商業價值。

操作判讀

判讀訊號

• workload 是合成的、跟 production traffic shape 不同
• 壓測通過但 production peak 失敗、模型未涵蓋實際模式
• 只測 throughput、不測 saturation 與 cost curve
• bottleneck 識別靠經驗、無系統定位流程
• capacity 規劃靠一次性 load test 結論、無持續對齊
• load-test 模型超過 6 個月未校準、drift 累積

交接路由

• 6.9 容量與成本邊界：load test 餵給容量規劃輸入
• 6.13 performance regression gate：load baseline 升級為持續 gate
• 6.20 experiment safety boundary：production load test 的 blast radius 與 stop condition
• 6.22 steady state definition：load test 驗證 saturation 前後的穩態維持
• 6.8 release gate：load test 結果作為 release 放行的容量證據
• 6.18 reliability metrics：把流量與可靠性指標接起來

規劃重點

• Cell-based Architecture：把服務切成獨立 cell、每個 cell 有完整 stack
• Shuffle Sharding：客戶請求映射到 cell 的隨機切分、讓單一壞客戶無法擊倒所有 cell
• Static Stability：control plane 失效時 data plane 仍能服務
• Constant Work Pattern：avoid scaling traffic in failure modes
• AWS Builders’ Library：可重用 reliability patterns 的官方文件

預計收錄實踐

章節列表

案例定位

Amazon 這個案例在講的是可靠性如何靠隔離來守住擴散邊界。讀者先看懂 cell-based architecture 與 shuffle sharding 的責任，再把它們當成控制 blast radius 的設計語言，而不是單純的 AWS 名詞。

判讀重點

當多租戶系統出現資源爭用時，cell 邊界先決定故障能擴散到哪裡。當容量壓力開始拉高時，shuffle sharding 讓風險分散到不同子集合，避免單一熱點把整個服務拖進同一個失敗模式。

可操作判準

• 能否指出一個 workload 的 blast radius 邊界
• 能否把共享基礎設施切成可獨立恢復的 cell
• 能否說明 contention 會落在哪個 shard
• 能否把 recovery 設計成分批恢復，而不是一次全開

與其他案例的關係

Amazon 的重點是把隔離變成架構語言，這和 Meta 的 region failover、Shopify 的 pod 架構、GCP 的控制面邊界都在同一條線上。差別只在於 Amazon 更早把 cell 與 shard 語言標準化，所以特別適合用來反推其他大型平台的設計選擇。

代表樣本

• cell-based architecture 讓一個 cell 壞掉時，其他 cell 仍能維持服務。
• shuffle sharding 將多租戶請求分散到不同子集合，限制單一客戶或單一熱點的擴散範圍。
• static stability 讓 control plane 失效時 data plane 仍可服務。
• constant work pattern 避免失敗模式下的額外放大成本。
• workload isolation 讓 tenancy / region / AZ 的邊界能各自承擔風險。
• failure containment 讓擴散先停在 cell 或 shard 邊界。
• push-based recovery 讓恢復節奏不依賴大規模同步操作。
• fault isolation 讓局部失效不會拖垮整個 fleet。
• constant work 讓 failure mode 不會因為多做一件事而繼續放大。

引用源

• Introducing The Amazon Builders’ Library：Builders’ Library 的官方入口。
• Workload isolation using shuffle-sharding：shuffle sharding 與 fault isolation 的官方文章。
• FAQ - Reducing the Scope of Impact with Cell-Based Architecture：cell-based architecture 與 shuffle sharding 的關係說明。

本章目標

讀完本章後、你應該能：

1. 寫 k6 test script（VU / iteration / stages）
2. 設計 threshold + CI gate（pass/fail）
3. 用 xk6 extension 擴展（gRPC / Kafka / SQL）
4. 部署 k6 Operator 做 distributed load
5. 評估 k6 vs Gatling / Locust / JMeter 的選用

最短路徑：5 分鐘把 k6 跑起來

1# 1. 安裝
2# TODO: brew install k6 / docker run grafana/k6
3
4# 2. 寫 test.js
5# TODO: import http from 'k6/http'; export default function(){ http.get(...) }
6
7# 3. 跑
8# TODO: k6 run --vus 10 --duration 30s test.js

日常操作與決策形狀

Test script 結構

子議題：

• export default function（per-VU iteration）
• export const options（VU / duration / stages / thresholds）
• Setup / teardown
• 對應指令範例：k6 run --vus 100 --duration 10m

Threshold + CI gate

子議題：

• thresholds: http_req_duration: ['p(95)<500']
• Exit code 非 0 → CI fail
• Custom metric thresholds
• 對應 6.13 Performance Regression Gate

Test pattern

子議題：

• Smoke / Load / Stress / Spike / Soak / Breakpoint
• Stages（ramp-up / steady / ramp-down）
• VU vs iteration vs RPS-based

進階主題（按需閱讀）

xk6 extensions

子議題：

• 自訂 binary：xk6 build + import extension
• 內建：HTTP / WebSocket / gRPC
• 社群：Kafka / SQL / Redis / browser
• 對應 cross-protocol load test

k6 Operator on K8s

子議題：

• TestRun CRD
• Distributed load（多 pod 模擬高 VU）
• Result aggregation
• 對應 Kubernetes vendor 頁

Grafana Cloud k6

子議題：

• Managed runner（多 region load source）
• 跟 Grafana dashboard 整合
• 跟 Loki / Tempo trace 關聯（test → APM trace）

Browser testing

子議題：

• k6 browser：Chromium-based browser testing
• 跟 Playwright 重疊但更聚焦 load
• 適合 frontend regression load test

CI integration

子議題：

• GitHub Actions / GitLab CI / Jenkins 整合
• Artifact + report upload
• 對應 6.8 Release Gate

k6 vs xk6 vs Cloud

子議題：

• k6 OSS：CLI + local script
• xk6：build custom binary with extensions
• k6 Cloud / Grafana Cloud k6：managed + UI

排錯快速判讀

Test 結果差異大

操作原則：local network / VU saturation / target 處理能力。

Threshold 太鬆 / 太嚴

操作原則：baseline 不準 / production traffic pattern 沒模擬。

Distributed load 不均勻

操作原則：k6 Operator 分配 VU 不均 / pod 規格差異。

Browser testing 慢 / 不穩

操作原則：Chromium 啟動成本 / network condition / target 反應時間。

何時改走其他服務

不在本頁內的主題

• JS 語言基礎
• k6 完整 API
• Grafana Cloud k6 pricing

案例回寫

待補 k6 customer case：Grafana Labs / k6 customer engineering blog、企業遷移 JMeter → k6 案例。

下一步路由

• 上游概念：6.13 Performance Regression Gate
• 平行 vendor：Gatling、Locust、JMeter
• 下游能力：09 performance capacity load test 模組

Fuzz test 把沒想過的輸入轉成可重播、可修補的失敗案例，補齊人工列舉無法觸及的邊界盲區。

這一頁處理的是輸入空間的盲區。當 API、parser、codec 或 schema 的邊界不清楚時，fuzz 比人工列案例更能覆蓋非預期路徑。

核心判讀

判讀 fuzz 的品質先看 target 選擇是否對準高風險輸入邊界，再看 corpus 是否持續收斂，最後看 crash 是否能轉成可回歸的修復。

重點判斷：

• fuzz target 是否足夠小，能對準單一責任
• corpus 是否持續收斂，coverage delta 是否仍為正
• crash reproduction 是否可重播到同一條路徑
• 修補後是否回寫成 regression test

Fuzz target 設計

Fuzz target 是 fuzz campaign 的最小驗證單位，責任是把外部輸入導入一個可觀測邊界的函式。

好的 target 對準單一 parser、codec、serializer 或 validation function，函式簽章接受原始位元組（如 func([]byte) 或等效形式）。target 選擇的判準有三個：這個函式是否直接處理外部輸入、邊界行為是否不清楚、crash 是否有業務影響。

target 粒度影響 fuzz 的效率與判讀價值。target 太大（整個 HTTP handler 含 auth / routing / DB 存取）會讓 crash 難以定位到具體邊界，因為 fuzz engine 需要同時探索太多分支，coverage 增長慢且 crash 歸因模糊。target 太小（單一 if 分支）會讓 coverage 增長無意義，因為分支行為已經被 unit test 覆蓋。

常見的高價值 target 類型：

Corpus 管理

Corpus 累積有效的輸入種子，讓 fuzz engine 能從已知邊界往外探索。corpus 品質直接決定 fuzz campaign 的探索效率。

初始 corpus 從三個來源收集：unit test 的既有 fixture（已知的合法與邊界輸入）、production sample 脫敏後的真實請求（反映實際流量的輸入結構）、schema 範例與文件中的合法樣本。初始 corpus 的重點是涵蓋主要合法路徑，讓 fuzz engine 從合法輸入開始 mutation，更容易觸達邊界。

持續擴充靠 coverage-guided mutation。fuzz engine 每次產生的 mutated input 若觸發了新的 code path（新分支、新呼叫），這個 input 會自動加入 corpus。隨著 campaign 進行，corpus 會累積越來越多能觸達深層分支的種子。

corpus 品質的判讀指標是 coverage delta trend — 每個時段新增的 code path 數量。coverage delta 持續為正代表 corpus 仍在有效探索；coverage delta 趨近零代表當前 target 的探索接近飽和，應考慮三個方向：切換到新 target、調整 mutation dictionary（加入 domain-specific token）、或擴充初始 corpus 的多樣性。

corpus 需要持久化管理。corpus 檔案應納入版本控制或 artifact storage，跨 CI job 保留。每次 fuzz campaign 結束時，新發現的有效種子合併回 corpus；crash input 在修復後轉成 regression fixture，從 fuzz corpus 移到 test fixture。

Crash reproduction 與 minimization

Fuzz 找到 crash 後的處理流程是 reproduce → minimize → fix → 回灌 regression test。

Reproduce：用 fuzz engine 產出的 crash input 在相同環境重跑，確認 crash 可穩定觸發。不可穩定觸發的 crash 通常來自 race condition 或環境差異，需要額外的 concurrency 或環境控制才能定位。

Minimize：minimization 把觸發 crash 的輸入縮到最小等效形式，讓 root cause 更容易定位。自動化 minimizer（如 Go 內建的 fuzz minimizer、libFuzzer 的 -minimize_crash=1）會反覆刪減 input 中的位元組，保留能觸發同一 crash 的最小子集。minimized input 通常比原始 input 短一到兩個數量級，讓開發者能直接看出觸發條件。

Fix 與 regression test：修復 crash 後，用 minimized input 作為 fixture 寫成 regression test。這個 test 確保同類 bug 不再出現，也讓未來的 refactor 不會重新打開已修復的邊界。regression test 歸入 CI pipeline 的 fast path，每次 push 都跑。

CI 整合

Fuzz 在 CI 的執行模式跟 unit test 不同。unit test 有明確的 pass/fail 結束條件，fuzz campaign 是開放式探索，執行時間越長覆蓋越廣。

CI 整合分兩種模式，對齊 6.1 CI pipeline 的分層策略：

Fast path regression（30 秒至 5 分鐘）：用既有 corpus 跑 fuzz，確認已知邊界沒退化。這個模式的目標是 regression 檢查，每次 push 觸發。corpus 裡的種子已經覆蓋了過去發現的邊界，短時間跑完可以確保修復沒被破壞、新變更沒引入已知類型的 crash。

Scheduled exploration（小時級）：定期（每日或每週）跑長時間 fuzz，讓 engine 有足夠時間做深層 mutation 與路徑探索。新發現的種子合併回 corpus，crash input 產生 issue 或 alert。這個模式的 coverage delta 是判讀 campaign 價值的主要指標。

CI 整合的關鍵是 corpus 持久化。corpus 必須跨 job 保存（cache、artifact storage 或版本控制），每次 job 從上一次的 corpus 繼續探索。若 corpus 每次從零開始，fuzz engine 會重複探索已知路徑，浪費運算資源。

Coverage 門檻與收斂判讀

Fuzz coverage 跟 unit test coverage 的意義不同。unit test coverage 衡量的是「多少行被執行過」，fuzz coverage 衡量的是「多少邊界被探索過」。同一個函式的 fuzz coverage 可以隨 corpus 擴充持續增長，因為 mutation 會觸發不同的分支組合。

判讀 fuzz campaign 是否仍有價值靠兩個指標：coverage delta trend（每小時新增多少 code path）與 corpus size growth（每小時新增多少有效種子）。兩者同時趨近零代表當前 target 的探索飽和。

飽和訊號指引兩個決策。第一，是否切換 target — 當前 target 的邊界已被充分探索，把 fuzz 資源移到另一個高風險 target 的邊際價值更高。第二，是否調整 mutation dictionary — 加入 domain-specific token（如 SQL keyword、JSON structure token、protocol magic bytes）可以讓 engine 更有效地觸達 domain-aware 的邊界。

案例對照

• Google：OSS-Fuzz 對大量基礎元件（parser、codec、serializer）做持續 fuzz，corpus 跨版本累積，crash 自動提 issue 並追蹤修復。這個規模的 fuzz campaign 說明 corpus 持久化與自動化 crash 處理是可擴展的前提。
• Stripe：API 與 serialization 邊界的 fuzz 需要 domain-specific dictionary（支付欄位、currency code、idempotency key 格式），通用 mutation 難以觸達業務語意上的邊界 crash。
• GitHub：webhook payload 與 schema 邊界的 fuzz 適合用 schema-aware fuzzer，從 OpenAPI / JSON Schema 產生結構化 mutation，覆蓋嵌套物件與型別邊界。

判讀訊號

交接路由

• 6.1 CI pipeline：fuzz regression 歸入 fast path、exploration 歸入 scheduled path
• 6.10 contract testing：schema fuzz 與契約驗證互補，contract 定義已知邊界、fuzz 探索未知邊界
• 6.16 test data：fuzz 找到的 crash input 沉澱成 seed 與 fixture
• 6.20 experiment safety boundary：長時間 fuzz campaign 在 production-like 環境跑時需要資源邊界控制
• 6.8 release gate：security-relevant fuzz crash 可作為 release 阻擋條件
• 8.9 事故型態庫：recurrent crash pattern 抽象化成型態

四類根因

計時依賴

Test 依賴特定的時間條件 — timeout、delay、animation duration。系統負載不同時，時間條件可能滿足也可能不滿足。

常見模式：

• await Future.delayed(Duration(seconds: 2)) + assertion — 如果操作在 2 秒內完成，test 通過；如果 CI 機器負載高導致操作超過 2 秒，test 失敗
• expect(stopwatch.elapsed, lessThan(Duration(seconds: 1))) — 效能斷言在不同機器上結果不同

處理策略：用事件驅動代替 timeout。等待 stream.first 代替 delay(2s) + check；用 completion signal 代替固定等待時間。如果必須用 timeout，設定寬裕的上限（10x 預期時間）而非精確的預期值。

環境差異

Test 在不同環境下行為不同 — 作業系統、檔案系統、時區、locale、DNS 解析。

常見模式：

• 檔案路徑分隔符（/ vs \）在不同 OS 下不同
• 時間格式化結果依時區而定（UTC vs local）
• 浮點數比較因 CPU 架構不同有微小差異

處理策略：用 path.join 代替硬編碼路徑；時間操作用 UTC；浮點比較用 closeTo 代替精確比較。在 CI 中固定環境變數（TZ=UTC、LANG=en_US.UTF-8）。

資源競爭

Test 依賴共享資源（port、暫存檔、資料庫行）— 平行執行時多個 test 同時存取同一資源，結果依賴執行順序。

常見模式：

• 多個 test 監聽同一個 port — 第二個綁定失敗
• 多個 test 寫入同一個暫存檔 — 內容被覆蓋
• 多個 test 操作同一個資料庫 table — 資料互相干擾

處理策略：每個 test 使用獨立的資源（隨機 port、唯一檔名、隔離的資料庫 schema）。如果資源無法隔離，sequential 執行相關 test（@sequential 標註）。

非確定性輸出

程式碼的輸出本身不確定 — Set 的迭代順序、Map 的 key 順序、非同步操作的完成順序。

常見模式：

• 斷言 Set 的 toString() 結果等於特定字串 — Set 的迭代順序不保證
• 斷言 Future.wait([a, b]).then((results) => results[0]) — a 和 b 的完成順序不固定
• 斷言 JSON 序列化的 key 順序 — Map 的 key 順序在不同實作中不同

處理策略：不斷言順序（用 containsAll 代替 equals 比較集合）；不斷言序列化格式（反序列化後比較值）；用 completion matcher 代替順序假設。

診斷步驟

發現疑似 flaky test 時的診斷步驟：

1. 確認 flaky：在乾淨環境連續跑 20 次，確認失敗是隨機的（如果每次都失敗，是 bug 不是 flaky）
2. 收集失敗訊息：記錄每次失敗的 assertion 訊息、stack trace、環境資訊（OS 版本、CI 機器 ID）
3. 分類：失敗訊息指向時間（timeout）→ 計時依賴；指向值不同 → 非確定性或環境差異；指向連接失敗 → 資源競爭
4. 修復：根據分類使用對應的處理策略

分類和修復之外，flaky test 的根因有時來自 assertion 本身的設計 — Assertion 品質三問提供判斷 assertion 是否有效的框架。如果 flaky 的根因是 mock 和真實服務的行為差異，回到 Mock 邊界判斷決策表判斷 mock 是否還適用。Protocol integration test 在 CI 中的服務 fixture 管理也是 flaky 的常見來源 — 服務啟動不完全就開始跑 test。

本章目標

讀完本章後、你應該能：

1. 用 Scala / Java / Kotlin DSL 寫 simulation（scenario + injection profile）
2. 設計 assertion + threshold 接 CI
3. 用 HAR-driven recording 從瀏覽器抓真實 user flow 起 script
4. 評估 Gatling Enterprise 分散式 vs OSS 單機高 VU 的取捨
5. 評估 Gatling vs k6 / JMeter / Locust 的選用條件

最短路徑：5 分鐘把 Gatling 跑起來

 1# 1. 安裝
 2# TODO: brew install gatling / 下載 bundle / Maven / sbt plugin
 3
 4# 2. 寫 simulation
 5# TODO: class MySim extends Simulation {
 6#         val httpProtocol = http.baseUrl("...")
 7#         val scn = scenario("...").exec(http("get").get("/"))
 8#         setUp(scn.inject(rampUsersPerSec(1).to(50).during(60))).protocols(httpProtocol)
 9#       }
10
11# 3. 跑
12# TODO: gatling.sh -s MySim / mvn gatling:test / sbt Gatling/test

日常操作與決策形狀

Simulation 結構

子議題：

• Simulation class（一個檔一個 simulation、整個 test 的根）
• scenario(...).exec(...)（一條 user journey 的步驟序列）
• httpProtocol（baseUrl / header / acceptedContent / proxy 共用配置）
• feeder（CSV / JSON / JDBC 餵 data、配合 randomFeeder / circular）

Injection profile（VU 注入節奏）

子議題：

• atOnceUsers(n)、rampUsers(n).during(t)、constantUsersPerSec(rate).during(t)、rampUsersPerSec(a).to(b).during(t)、heavisideUsers(n).during(t)
• 跟 k6 stages 對照：Gatling 用 injection step composition、k6 用 stages array — 概念近、語法不同
• Closed model（固定 VU）vs Open model（固定 rate）— Gatling 兩者都支援、production 流量多半 open model 更貼近

Assertion + threshold + CI

子議題：

• setUp(...).assertions(global.responseTime.percentile3.lt(500), global.successfulRequests.percent.gt(95))
• Assertion 失敗時 process exit code 非 0、直接接 CI pass/fail gate
• 對應 6.13 Performance Regression Gate

進階主題（按需閱讀）

HAR-driven recording

子議題：

• Chrome DevTools 匯出 HAR、gatling-recorder 從 HAR 產 simulation skeleton
• 適合：複雜 user flow（multi-step checkout / form / login redirect）懶得手寫 script
• 邊界：recording 出來是 baseline、需手動補 dynamic correlation（CSRF token / session id / form state）

Gatling Enterprise（前 FrontLine）

子議題：

• 分散式 load（多 injector node 模擬 100k+ VU）、跨 region traffic source
• Web UI 跑 test、看 dashboard、開 trend analysis
• 接 Git repo 自動 build simulation、跟 CI / Jenkins / GitLab 整合
• 對應 Kubernetes vendor 頁 的 on-K8s 部署

Async engine 跟單機高 VU

子議題：

• 引擎基於 Akka / Netty、non-blocking IO、單 thread 可驅動上千 VU
• 對比 JMeter thread-per-VU 模型、Gatling 單機 VU 上限可高 10x 起跳
• 邊界：target service 才是瓶頸時、單機更高 VU 也壓不出更多訊號、要走分散式

JVM tuning

子議題：

• Heap size（-Xms / -Xmx）跟 GC 策略（G1 / ZGC）影響高 VU 穩定性
• Connection pool / file descriptor ulimit 是常見卡關點
• Container 跑 Gatling 要注意 CPU / memory request 給足

從 JMeter 遷移

子議題：

• JMeter .jmx 沒官方 converter、要人工 port
• 適合切點：新 simulation 寫 Gatling、舊 .jmx 維護收斂後再評估
• 對應 JMeter 「既有 .jmx 資產治理」段

排錯快速判讀

單機 VU 上不去

操作原則：JVM heap / ulimit / connection pool 三層先排、再看是不是 target service 已是瓶頸（latency 漲、VU 卻沒滿）。

Response time p99 不穩

操作原則：GC pause（看 GC log）/ network jitter / target service warmup 沒做完。Steady-state 量測前要先 ramp-up + soak 5-10 分鐘。

Assertion 偶發 fail

操作原則：threshold 設在 noise level 附近、把 baseline 重跑 3 次抓 p95 區間、再設 threshold 留 buffer。

Recording 出來的 script 跑不通

操作原則：HAR 沒抓到 dynamic value（CSRF / session）、要手動加 check(regex(...).saveAs(...)) 把 response 抓出來餵後續 request。

何時改走其他服務

不在本頁內的主題

• Scala / Kotlin 語言基礎
• Gatling DSL 完整 API reference
• Gatling Enterprise pricing 跟 deployment model 細節

案例回寫

待補 Gatling customer case：金融 / e-commerce 重度 JVM 生態採用 Gatling Enterprise、HAR-driven scenario recording 在 multi-step checkout flow 的實踐。

下一步路由

• 上游概念：6.13 Performance Regression Gate
• 平行 vendor：k6、Locust、JMeter
• 下游能力：09 performance capacity load test 模組

規劃重點

• Deploy strategy：canary / staged rollout 的實作節奏
• Game Day：Stripe 公開的 game day 設計與運作
• Idempotency Key：API 設計層面的 retry safety
• Increasing reliability：從 99% 到 99.999% 的逐階段工程投資
• Capture the flag：內部紅藍演練（這是 Stripe 自有的、不是套 07 的紅藍）

預計收錄實踐

章節列表

案例定位

Stripe 這個案例在講的是交易系統如何把重試、遷移與部署都設計成可回復的操作。讀者先抓 idempotency 與 zero-downtime migration 這兩個原語，再看它們怎麼保護支付流程不被重試與變更放大。

判讀重點

當客戶端會重送請求時，idempotency key 讓 server 能把重試視為同一筆交易。當資料結構需要調整時，零停機遷移則把高風險變更拆成可驗證的小步驟，避免一次把整個 payment path 推到不可回復的狀態。

可操作判準

• 能否讓同一筆請求重送後仍得到同一個結果
• 能否把 migration 拆成可觀察、可回滾的小階段
• 能否區分 client retry 與 server duplicate processing
• 能否把 deploy strategy 和交易一致性放在同一個判準下

與其他案例的關係

Stripe 的可靠性核心是把交易語義寫進系統邊界，這和 GitHub 的 replication、一樣都在處理「重複動作不能造成雙重結果」的問題。差別在於 Stripe 面對的是金流，容錯成本更高，所以 idempotency 與 zero-downtime migration 會比一般平台更早變成硬要求。

代表樣本

• idempotency key 讓同一筆請求重送後，系統仍能回到相同交易結果。
• zero-downtime migration 把高風險資料變更拆成可驗證的小階段。
• canary deploy 讓交易流量先經過小範圍驗證。
• game day 讓支付與資料遷移的失效路徑先被演練。
• retry semantics 讓 client 重送不會變成雙重扣款。
• monitoring & alerting 讓支付路徑的異常先在訊號層浮出來。
• operational simplicity 讓流程越少分支，越容易守住交易正確性。
• safe deploy strategy 讓變更節奏和風險控制綁在一起。

引用源

• Designing robust and predictable APIs with idempotency：idempotency key 與重試安全的官方文章。
• How Stripe’s document databases supported 99.999% uptime with zero-downtime data migrations：零停機資料遷移與可靠性投資的官方案例。
• Stripe Engineering：Stripe Engineering 內容總入口，補 deploy / CI / reliability 的延伸脈絡。

Chaos test 是在可控條件下主動注入故障，驗證系統是否能在真實依賴失效時維持 steady state 與可接受的 blast radius。

這一頁關心的是失效時系統怎麼退化。chaos 的價值在於判讀系統收到故障後的退化行為是否符合預期。沒有先定義 steady state，chaos 只會變成故障展示，不會變成判讀工具。

核心判讀

判讀 chaos 的重點是對控制面、資料面與依賴鏈的回復能力做驗證，而不是單純證明服務死過一次。

重點訊號包括：

• 是否先定義 steady state 與成功條件
• 故障是否真的落在常見依賴與控制點
• blast radius 是否可量測、可縮限
• recovery path 是否能在演練後被重播

故障注入的設計流程

一輪有效的 chaos 驗證從穩態定義開始。先知道系統正常時應維持什麼行為，再設計注入去測試這個行為是否可持續。

穩態定義是整個流程的錨點。Netflix 的 chaos 實踐把 steady state 放在驗證循環的第一步 — 先定義穩態指標（SLI、business KPI、queue lag），再用故障注入去測試這些指標是否能在壓力下維持。沒有穩態定義的故障注入只能產出「系統被打壞了」的結論，無法回答「系統是否按預期退化」。

假設設計決定實驗能學到什麼。好的假設會說明「當 broker 節點離線時，訊息消費延遲應在 30 秒內回線，checkout 成功率應維持在 SLO 門檻內」，而不只是「關掉 broker 看看會怎樣」。假設越具體，實驗結果的判讀價值越高。

Blast radius 需要同時包含技術範圍與客戶範圍。技術範圍是 service、region、cluster、dependency；客戶範圍是 tenant、plan、traffic percentage 或 internal-only cohort。從最小範圍開始，逐步放大，每一步都要確認停止條件仍可執行。

停止條件讓實驗可控。當 SLO burn rate 超門檻、customer impact 出現或 cost 異常上升時，實驗應立即終止。停止條件要連到可觀測訊號，不能靠臨場討論決定是否繼續。

注入類型與層次

故障注入按依賴類型分層。不同依賴的失效模式不同，預期退化也不同，實驗設計需要對應調整。

Broker outage 驗證的是非同步依賴的容錯能力。當 broker 節點或 partition 不可用時，生產端應有 retry 與 fallback，消費端應能在恢復後 drain backlog 而不是 replay storm。測試時需要確認 DLQ 設定正確、消費 lag 有監控、恢復後的 backpressure 不會壓垮下游。

DB latency 驗證的是同步依賴在退化時的行為。延遲注入比完全斷線更接近真實故障 — production 常見的是 slow query、connection pool exhaustion 或 replica lag，而不是 database 完全離線。測試時需要確認 timeout 是否會級聯：一個慢查詢拖住連線，其他請求開始排隊，最終 thread pool 或 goroutine 耗盡。

Node restart 驗證的是服務在節點層級的恢復能力。graceful shutdown 是否正確 drain 連線、readiness probe 是否能阻止 load balancer 過早送流量、cold start 是否會因 cache miss 或 JIT warmup 造成短暫效能劣化。

Network jitter 驗證的是跨服務通訊的韌性。jitter 注入需要模擬真實的 latency distribution（長尾、間歇性），而不是固定延遲。測試時需要關注 retry 行為：固定 retry 在 jitter 環境下可能放大流量，需要搭配 retry budget 控制。

注入粒度：instance-level vs request-path

故障注入有兩個主要粒度，適用場景不同。

Instance-level injection（如 Chaos Monkey）在節點層注入故障 — 關閉 instance、斷開網路、暫停程序。這個粒度驗證的是基礎設施韌性：load balancer 能否切流、auto-scaling 能否補位、graceful shutdown 能否完成。優點是簡單、接近真實硬體故障；缺點是粒度粗，無法精準驗證特定依賴路徑。

Request-path injection（如 FIT）在請求路徑層注入故障 — 對特定 API call、dependency request 或 service-to-service 通訊植入 timeout、error 或延遲。這個粒度驗證的是應用韌性：fallback 是否生效、circuit breaker 是否觸發、retry 是否安全。優點是精準、blast radius 小；缺點是需要更深的 instrumentation，建置成本較高。

兩者不互斥。instance-level injection 適合驗證基礎設施層的回復能力，request-path injection 適合驗證應用層的容錯邏輯。團隊可以從 instance-level 開始建立 chaos 習慣，再逐步引入 request-path injection 提升驗證精度。第三種粒度是 infrastructure-level injection（AZ failure / region failure），由 cloud provider 的 chaos 工具（如 AWS FIS、Azure Chaos Studio）支援，驗證的是跨 AZ 冗餘與 failover 路由。

執行時段與環境

故障注入的執行時段與環境直接影響驗證價值。

Business hours vs off-peak

在 business hours 執行 chaos 能同時驗證系統韌性與團隊應變能力。人員在線可即時觀測、依賴流量接近真實、通訊鏈條（值班升級、跨團隊協作、內外部狀態更新）被完整測到。off-peak 雖然短期風險低，但測到的多是「工具可執行」，不是「服務在真實壓力下可承受」。

選擇 business hours 執行的前提是 guardrails 到位：時段限制在可支援的工作時間、blast radius 從小範圍開始、abort trigger 連到明確門檻、事後回寫進工程控制面。風險來自 guardrails 的缺失。

Staging vs production

Staging 適合驗證工具整合與基礎假設：注入能否生效、dashboard 能否呈現訊號、stop condition 能否觸發。但 staging 與 production 之間通常存在環境漂移 — traffic pattern 不同、dependency 配置不同、connection pool 大小不同、cache warmup 狀態不同。在 staging 通過的實驗，不能直接等同於 production 可承受。

Production chaos 的價值在於驗證真實依賴路徑。它需要從最小 cohort 開始（internal traffic、canary region、特定 tenant），搭配完整 stop condition 與 rollback path。Production chaos 需要 stop condition 作為安全網。團隊可以從簡單的 stop condition（如 error rate 超門檻就停止）起步，隨經驗累積逐步精細化。

證據結構與回寫

Chaos 實驗的產出是可決策的證據。當實驗結果能直接回答「這個依賴的容錯能力是否足夠」，chaos 才從測試活動升級為可靠性控制面。

Steady-state impact 是最核心的證據欄位。它回答的問題是「系統在故障期間是否維持了服務承諾」。若 SLI 維持在 SLO 門檻內，代表容錯機制有效；若偏離，需要記錄偏離幅度、持續時間與影響範圍。

Abort trigger record 讓團隊知道 stop condition 是否可執行。若停止條件被觸發但執行延遲，代表觀測或通訊鏈條有缺口；若停止條件沒被觸發但影響已擴大，代表門檻設定需要校準。

這四個欄位接到 6.23 verification evidence handoff 後，可直接成為 6.8 release gate 的放行輸入。release decision 從「主觀討論」轉成「政策驅動」：有證據支持容錯能力 → 放行；abort 被觸發 → 凍結並修復；fallback 失敗 → 補 action item 再重驗。

規模差異

Chaos 的設計在不同規模下差異顯著。單服務 chaos 與跨區 chaos 打到的系統層不同，blast radius 控制方式也不同。

單服務 chaos

單服務 chaos 驗證的是一個服務對其直接依賴的容錯能力。blast radius 限在該服務的 instance、replica 或 traffic cohort 內。適合驗證 circuit breaker、fallback、timeout、retry 與 graceful degradation。

跨區 chaos 與 failure localization

跨區 chaos 驗證的是故障在區域或依賴鏈上的擴散行為。Amazon 的 cell-based architecture 把多租戶服務的故障域限制在 cell 內 — 一個 cell 的異常不會擴散到其他 cell，恢復策略從全域搶救轉為分批收斂。Meta 的 region failover 實踐則關注控制面故障的跨區擴散 — 當核心網路或 BGP 配置異常跨越區域邊界，恢復動作本身可能成為新的放大器。

兩者共同的判讀重點是：故障是否被限制在預期邊界內。單服務 chaos 的邊界是 instance 與 dependency；跨區 chaos 的邊界是 region、cell 與 shared dependency。blast radius 越大，stop condition 與 rollback path 的設計要求越高。

產業情境：串流與媒體服務

串流服務的故障注入需要考慮觀眾正在觀看的即時性。CDN 節點失效、origin server 延遲或 transcoding pipeline 中斷都會直接造成 buffering 或畫質降級，使用者的容忍窗口以秒計。

串流的 steady state 指標跟一般 web service 不同：buffering ratio（觀眾看到轉圈的時間比例）、bitrate stability（畫質是否頻繁跳動）、video start time（按下播放到第一幀的延遲）。這些指標直接反映觀看體驗，chaos 實驗的假設必須用這些指標定義穩態，而非只用 HTTP success rate。

CDN 有多層快取（edge / mid-tier / origin），某一層失效時流量會 fallback 到下一層。chaos 要驗證的是 fallback 路徑能否承受突增的回源流量，以及 adaptive bitrate 策略是否能平滑過渡到較低畫質，而非直接中斷播放。回源流量的放大倍數取決於該層的快取命中率 — 命中率越高的層失效，回源放大越劇烈。

直播事件的 chaos 約束更嚴格。VOD 內容可重試、可重播，直播沒有第二次機會。直播前的 chaos 演練需要模擬「直播進行中 CDN 節點失效」的場景，驗證備援路徑的切換速度是否在觀眾可感知門檻（通常 2-5 秒）內。Netflix 的 chaos 實踐原始動機即是保護串流觀看體驗，其 steady state hypothesis 的設計直接適用於串流場景。

案例對照

• Netflix：Steady State、Chaos 與 FIT：把故障注入變成科學化驗證循環，四元素（steady state / hypothesis / blast radius / abort condition）提供 chaos 設計的結構。FIT 把注入粒度推進到 request path，讓測試更接近真實依賴路徑。
• Netflix：Business-Hours Chaos Guardrails：business hours 執行的前提是 guardrails 到位（時段限制、範圍限制、abort trigger、事後回寫），驗證的不只是系統韌性，也包含團隊應變能力。
• Netflix：FIT 證據交接：把 FIT 輸出結構化成四個決策欄位，讓實驗結果直接驅動 release gate。
• Amazon：Shuffle Sharding 與 Cell 邊界：cell-based architecture 讓恢復策略從全域搶救轉為分批收斂，是跨區 chaos 設計的前提。
• Meta：Region Failover 邊界治理：跨區依賴與控制面故障的回復順序，說明 blast radius 在大規模系統中的擴散治理。
• Shopify：BFCM 容量治理與 Game Day：game day 把演練、壓測與隔離單位連成一條線，適合補充高峰型場景的 chaos 設計。

判讀訊號

判讀 chaos 的品質不只看實驗是否通過，要看實驗設計是否能產出可信結論。

• chaos experiment 只測 happy path 的故障：只關掉不重要的服務、只在低流量時段跑，通過了也無法證明高價值路徑的容錯能力。判讀條件：注入目標是否對應服務的關鍵依賴路徑。行動：把注入目標對齊服務的 top-3 關鍵依賴。
• broker / DB / network 故障無自動演練、靠真事故學：沒有定期 chaos 的團隊只能從真實事故中學習，學習成本高且機會不可控。判讀條件：chaos 是否有固定節奏，而非只在事故後才啟動。行動：排入季度 chaos sprint、從最小 blast radius 開始。
• chaos 暴露問題沒修、紀錄堆積：實驗發現缺口但 action item 沒有 owner、沒有 deadline，同類問題反覆出現。判讀條件：action item 是否進入 6.21 reliability debt backlog 並被追蹤。行動：每次 chaos 結束後 action item 指定 owner + deadline。
• production chaos 只在低流量時段跑、訊號失真：低流量時段的依賴行為、流量模式與團隊狀態都跟 production peak 不同，通過了不代表高峰時可承受。判讀條件：是否有 business-hours 或接近 peak 的驗證補充。行動：至少每季補一次 business-hours chaos 驗證。
• 故障注入工具跟 production 不同 stack、結果不可信：staging 用不同的 broker、database 或 network 配置做 chaos，結果無法外推到 production。判讀條件：實驗環境與 production 的差異是否被記錄並納入結論限制。行動：在結論中標註環境差異、逐步推進 production chaos。
• chaos 結果沒進 runbook：值班人員不知道特定依賴失效後的預期退化行為，事故時仍靠臨場推理。判讀條件：chaos 結論是否已回寫到對應服務的 on-call runbook。行動：每次 chaos 完成後回寫 runbook 的「依賴失效預期行為」段。

交接路由

• 6.7 DR / rollback rehearsal：chaos 暴露的回復路徑問題進入 DR 演練
• 6.12 idempotency / replay：注入重複訊息驗證冪等能力
• 6.14 dependency budget：對依賴注入故障驗證 reliability budget
• 6.20 experiment safety boundary：chaos 的 blast radius、stop condition 與權限約束
• 6.22 steady state definition：chaos 開始前的穩態定義
• 6.23 verification evidence handoff：chaos 證據接到 release gate
• 8.6 drills / on-call readiness：chaos 結果回饋到值班訓練

本章目標

讀完本章後、你應該能：

1. 用 GUI 設計 test plan（thread group / sampler / listener / assertion）
2. 跑 non-GUI mode 給 CI
3. 用 Distributed mode（master / slave）擴張 VU
4. 用 JMeter Plugins Manager 加擴展
5. 評估 JMeter vs 現代 CLI-first（k6 / Gatling / Locust）的選用

最短路徑：5 分鐘把 JMeter 跑起來

1# 1. 安裝
2# TODO: brew install jmeter / 下載 zip
3
4# 2. GUI 設計 .jmx
5# TODO: 開 jmeter GUI、加 Thread Group / HTTP Sampler / Listener
6
7# 3. CI 跑 non-GUI mode
8# TODO: jmeter -n -t test.jmx -l result.jtl -e -o report/

日常操作與決策形狀

Test plan 結構

子議題：

• Thread Group（VU + ramp-up + loop count）
• Sampler（HTTP / JDBC / JMS / FTP / Java Request）
• Listener（aggregate report / view tree / graph）
• Assertion（response / duration / size）

Non-GUI mode for CI

子議題：

• -n non-GUI
• -t test file / -l log file
• -e -o 產生 HTML dashboard
• Exit code 0 / 1（搭配 backend listener / assertion）

Distributed testing

子議題：

• Master / slave 配置
• RMI port 設定
• Result aggregation 在 master

進階主題（按需閱讀）

Plugins Manager

子議題：

• jmeter-plugins.org plugins
• 常用：PerfMon / Dummy Sampler / Custom Thread Groups / WebSocket
• 安裝管理：Plugins Manager 安裝後可 UI 管

Recording controller

子議題：

• HTTP(S) Test Script Recorder
• Browser proxy 設定
• 適合：快速錄製 user flow

CSV data set / parameterization

子議題：

• CSV Data Set Config
• 各 thread 取不同資料
• 適合 data-driven test

CI / Jenkins integration

子議題：

• Jenkins JMeter plugin
• Performance plugin（trend analysis）
• 對應 6.13 Performance Regression Gate

既有 .jmx 資產治理

子議題：

• XML 不友善 git diff
• 大 test plan 可讀性差
• 改用 module 拆 + Test Fragment
• 對應企業遷移到 k6 / Gatling 評估

排錯快速判讀

High VU 起不來

操作原則：JVM heap 不夠 / GUI 模式有限制（永遠 non-GUI for production load）。

Listener 拖慢

操作原則：View Results Tree 記錄太多 → 改 simple data writer / disable detail。

Distributed RMI 連不上

操作原則：firewall + RMI port 不對。

Assertion noise

操作原則：assertion failed 多但實際 OK → response time / size 設過嚴。

何時改走其他服務

不在本頁內的主題

• 完整 plugins 列表
• BeanShell / Groovy scripting
• JMeter internal architecture

案例回寫

待補 JMeter customer case：企業內部 JMeter 大規模採用案例、JMeter → k6 遷移案例。

下一步路由

• 上游概念：6.13 Performance Regression Gate
• 平行 vendor：k6、Gatling
• 下游能力：09 performance capacity

規劃重點

• Pod-based Architecture：多租戶切分、商家隔離設計
• BFCM 準備：年度峰值的 capacity planning 流程
• Resiliency Matrix：列舉服務與失效模式的對照表
• Toxiproxy / Resiliency tooling：Shopify 開源的 chaos 工具
• Database sharding：MySQL 分片策略與 online resharding

預計收錄實踐

章節列表

案例定位

Shopify 這個案例在講的是峰值流量如何被提前吸收，而不是在事故當下硬扛。讀者先抓 capacity planning、performance testing 與 pods architecture 的分工，再看它們怎麼把 BFCM 這種季節性壓力轉成可管理的工程節奏。

判讀重點

當流量會在短時間內暴增時，先做容量模型與壓測，再確認 pods 邊界能否切住故障擴散。當資料平台也在同一波壓力下成長時，重點不只在擴容，而在是否能保住查詢、寫入與回放的穩定節奏。

可操作判準

• 能否在 peak 之前說出容量上限與安全緩衝
• 能否把壓測結果對應到真實流量模型
• 能否讓 pods 邊界成為故障隔離單位
• 能否在高峰前完成演練與當日指揮節奏對齊

與其他案例的關係

Shopify 的價值在於它把峰值準備寫成年度節奏，這和 LinkedIn 的 capacity planning、AWS S3 的區域風險、Discord 的流量驚奇都能互相對照。讀這頁時要抓的是「先把峰值變成可預測問題」，而不是等事故來了才補救。

代表樣本

• BFCM 前的 capacity planning 讓峰值壓力先被模型吸收，而不是直接落在事故當下。
• pods architecture 把多租戶流量切成較小隔離單位，限制故障擴散。
• performance testing 讓真實峰值在演練階段就可見。
• resiliency tooling 讓團隊能在高峰前驗證失效模式。
• database resharding 讓高峰下的 stateful 系統仍能持續擴容。
• incident rehearsal 讓當日指揮與復原節奏先對齊。
• resiliency matrix 讓每個服務與失效模式都有明確對照。
• Toxiproxy 讓 TCP 層故障注入成為可重用工具。

引用源

• Capacity Planning at Scale：BFCM 前的容量規劃與驗證方法。
• Performance Testing At Scale—for BFCM and Beyond：BFCM scale testing 與壓測節奏。
• A Pods Architecture To Allow Shopify To Scale：pods 架構與隔離設計。
• How to Reliably Scale Your Data Platform for High Volumes：資料平台在高流量下的可靠性方法。

失敗模式預判是在變更上線前，主動尋找驗證覆蓋的缺口。責任是把「我們漏掉了什麼」從事後驚訝變成事前盤點。

這一頁處理的是驗證邊界。當某個環節一旦失效就會放大事故，pre-mortem 與 FMEA 的工作是提前把那個環節標出來，讓團隊能在上線前決定是補驗證、收窄範圍還是延後變更。

核心判讀

驗證缺口的核心問題是變更是否被差異化控制、回復路徑是否經過驗證。

重點訊號包括：

• 高風險變更是否有獨立 gate
• 負載模型是否包含失敗流量特徵
• 故障演練是否覆蓋 partial failure 與連鎖失效
• rollback 與 runbook 是否有時限驗證

Pre-mortem 流程

Pre-mortem 的核心假設是「這個變更已經在 production 造成事故」，然後反向推導可能的失敗路徑。這個方法的價值在於成本極低（只需要一次結構化討論）但能暴露驗證盲區。

流程分四步：

列出依賴與資料路徑：把變更涉及的服務依賴、資料寫入路徑與外部呼叫畫出來。重點是找出「變更直接或間接觸及的系統邊界」，包括 schema、config、依賴服務版本與流量路由。

對每條路徑問失敗影響：對每條路徑假設失敗，判斷影響範圍。問的是「如果這條路徑斷了 / 慢了 / 回傳錯誤，影響會擴散到哪裡」。影響範圍包含直接依賴方、上游呼叫者、使用者可見行為與資料一致性。

判斷現有驗證覆蓋：對每條失敗路徑，檢查現有 CI、load test、chaos experiment、contract test 是否能攔住這個失敗。重點是找出「我們認為有覆蓋但實際沒覆蓋」的路徑 — 例如 CI 有 unit test 但沒有 integration test 覆蓋跨服務呼叫，或 load test 有 throughput 驗證但沒有 retry storm 場景。

識別驗證缺口並路由：未覆蓋的失敗路徑進入兩條路由。上線前能補的缺口回寫到 6.19 reliability readiness review，作為上線前檢查項目。上線前補不了的缺口回寫到 6.21 reliability debt backlog，作為可排序的改善項目。

Pre-mortem 的常見失效是流程走了但結論沒路由。當缺口被列出但沒有 owner、沒有 deadline、沒有連到 readiness review 或 debt backlog，pre-mortem 就只是會議紀錄。

FMEA 分類軸

Failure Mode and Effects Analysis 按失效模式分類驗證缺口。按模式分類的好處是讓團隊能判斷「缺口屬於哪一類」，然後沿對應章節的路由去補。

Gate failure

Release gate 缺少高風險變更的差異化控制。當所有變更走同一條 CI pipeline、同一套 gate 門檻，高風險變更（schema migration、payment path、config rollout）的驗證強度跟日常小改動相同，gate 實質上對高風險變更無效。

判讀條件：高風險變更是否有獨立的 gate 流程；gate 門檻是否隨變更風險等級調整。Microsoft 的變更治理實踐把變更按風險分層，高風險變更需要更嚴的放行條件與更完整的驗證路徑。回到 6.8 release gate 補差異化門檻。

Load failure

Workload model 沒覆蓋失敗流量特徵。壓測模型通常反映正常流量，但事故時的流量形狀完全不同：retry storm 放大請求量、cascade timeout 佔住連線、queue backlog 堆積改變消費節奏。當壓測模型只包含正常流量，通過壓測不代表系統能承受失敗流量。

判讀條件：workload model 是否包含 retry 放大、timeout cascade 與 queue 堆積場景。回到 6.2 load test 補失敗流量模型。

Recovery failure

Rollback 或 DR 路徑在事故前沒被驗證過。團隊假設 rollback 可用，但 schema 已經不向下相容；團隊假設 failover 可用，但 failover config 跟 production 已經漂移。recovery failure 的特徵是「有計畫但沒跑過」。

判讀條件：rollback 是否在過去 90 天被 rehearsal 驗證過；DR failover config 是否跟 production 同步。回到 6.7 DR / rollback rehearsal 建立定期驗證節奏。

Detection failure

告警延遲或缺失，問題被使用者先發現。當 SLO alert 覆蓋不足、dashboard 缺少關鍵路徑的訊號、或告警門檻設定過寬，團隊的 MTTD（mean time to detect）會拉長到使用者回報之後。detection failure 讓所有下游反應（止血、升級、溝通）都延遲。

判讀條件：關鍵路徑的 MTTD 是否在可接受範圍；SLO alert 是否覆蓋使用者可見的服務承諾。Netflix 的 chaos 實踐把 steady state 定義放在驗證的第一步 — 沒有穩態定義，告警就無法判斷系統是否偏離正常，detection 變成盲目。回到 04 可觀測性 補訊號覆蓋。

失敗模式嚴重度評估

FMEA 傳統用 severity × probability × detectability 三軸評估風險優先序。在可靠性驗證的語境中，這三軸可以簡化為可操作判讀：

三軸的交叉決定驗證投資順序：high severity + high probability + low detectability 的缺口最先處理。反過來，low severity + low probability 的缺口可以先記錄在 6.21 reliability debt，不需要立即補驗證。

嚴重度評估的陷阱是把評分當目標。三軸的責任是排序驗證投資，讓團隊在有限時間內先補最危險的缺口。當評分本身變成需要維護的文件，評估的維護成本會超過它帶來的判讀價值。

服務環節問題地圖

TeamCity 案例暴露的是 gate failure：CI 入口本身被繞過時，後續所有 gate 都失效。判讀條件是 CI pipeline 的存取控制是否被納入驗證範圍，而不只是 pipeline 內容。

Change Healthcare 案例暴露的是 recovery failure：事故影響擴散到營運層面時，技術回復完成不代表服務恢復。判讀條件是 DR plan 是否涵蓋跨系統依賴的恢復順序，而不只是單一服務的 rollback。

案例對照

Google 的 error budget 政策把 gate 門檻跟 budget 消耗綁在一起：budget 健康時走正常 gate，budget 快速消耗時提高門檻。這種做法讓 gate failure 的偵測從「事後觀察回滾率」轉成「事前看 budget 消耗趨勢」。

Shopify 的 resiliency matrix 是 FMEA 的制度化形式：service × failure mode 的矩陣，每格填入防護狀態（covered / gap / in-progress），gap 欄直接成為 game day 的演練題目。這種做法讓 FMEA 從一次性盤點變成持續維護的驗證清單。

跟其他章節的整合

Pre-mortem 與 FMEA 的產出需要路由到三個下游：

• 6.19 reliability readiness review：上線前能補的缺口進入 readiness checklist
• 6.20 experiment safety boundary：需要驗證的失敗假設轉成 chaos / load test 的實驗設計
• 6.21 reliability debt backlog：上線前補不了的缺口進入可排序的改善 backlog

路由清晰度決定 pre-mortem 的實際價值。當缺口被識別但沒有路由到具體章節的具體動作，pre-mortem 就只是風險清單。

判讀訊號

交接路由

• 6.2 load test：補失敗流量模型（retry / timeout / queue）
• 6.7 DR / rollback rehearsal：補回復路徑驗證
• 6.8 release gate：補高風險變更的差異化 gate
• 6.19 reliability readiness review：pre-mortem 缺口轉成上線前檢查
• 6.20 experiment safety boundary：失敗假設轉成實驗設計
• 6.21 reliability debt backlog：未修缺口進入可排序 backlog
• 04 可觀測性：detection failure 回到訊號覆蓋
• 6.23 verification evidence handoff：FMEA 結論作為 readiness 證據
• 08 事故處理：pre-mortem 假設在事故中被驗證時回寫

SLO 與 error budget 是把可靠性從口號變成政策的工具。SLO 定義的是服務要對哪個使用者旅程負責，error budget 定義的是這個責任在一段時間內可以承受多少退化。當這兩個條件被寫清楚，可靠性就能從「感覺上應該穩」變成「超過哪個門檻就要暫停、降風險或修復」。

這個節點先處理目標，再處理門檻。先問服務要守住什麼體驗，再問這個體驗要用哪些訊號衡量，最後才決定 burn rate 到多少時要 freeze。這樣寫的好處是，讀者會先理解政策責任，再理解數字本身。

大綱

• SLI 選型：user-journey-centric vs system-metric
• SLO 目標訂定：可達性、商業意義、頻率窗
• error budget：burn rate、policy、freeze 條件
• 跟 04 觀測 的訊號交接
• 跟 6.8 release gate 的凍結觸發
• 跟 8.1 事故分級 的門檻對齊
• 反模式：cargo-cult 99.99%、SLO 無人擁有、burn rate 無 alert

核心判讀

SLO 的責任是讓團隊知道自己到底在保護什麼。當讀者看到一個 SLO 時，第一個問題是這個數字是否對應使用者行為、商業風險與回復成本；數字高低要放在這個脈絡中判讀。

error budget 的責任是把風險傳導成決策。當 burn rate 開始上升時，團隊先確認 budget 還剩多少、目前的變更是否會放大風險、freeze 條件是否已經被觸發。這裡的重點是路由清楚，數字只是路由的輸入。

SLI 選型

SLI 選型的責任是把使用者旅程轉成可量測訊號。好的 SLI 先描述使用者能否完成重要任務，再選擇最能代表該任務的 log、metric、trace 或 client-side signal。

Availability 適合描述同步 API 與 user-facing request。它需要清楚定義分母與分子，例如只計算有效請求、排除客戶端取消，或把 timeout、5xx 與 business failure 分開。

Latency 適合描述體驗壓力。平均值容易掩蓋長尾，可靠性政策通常需要 percentile 或 histogram，並且要對應使用者旅程，再用單一 process 的 handler time 作為診斷輔助。

Freshness 適合描述資料管線、search index、cache projection 與 read model。這類服務即使 API 回應成功，資料過舊仍會破壞使用者體驗。

Correctness 適合描述金流、帳務、庫存、資料同步與 migration。這類可靠性目標需要資料校驗與 reconciliation，而不只看 request 成功率。

Durability 適合描述 queue、event log、object storage 與資料寫入。它關心寫入後能否找回、重播、備份與回復，常和 RPO / RTO 一起定義。

SLO 政策

SLO 政策的責任是把可靠性目標轉成團隊行為。數字本身只是門檻，政策要說明目標的 owner、時間窗、例外條件、檢視頻率與觸發後動作。

User journey 是 SLO 的錨點。checkout、login、message delivery、search freshness、invoice generation 都比 CPU 或 memory 更適合承載可靠性承諾，因為它們能直接對應使用者結果。

SLI formula 需要可重算。分母包含哪些 request、分子如何判定成功、資料來源來自 server-side 還是 client-side、sampling 有哪些限制，都需要寫進政策。

Objective 需要結合商業風險與回復成本。99.9% 與 99.99% 的差異不只是小數點，而是代表可接受 downtime、工程投資、成本與變更節奏的差異。

Freeze action 讓 error budget 進入工程決策。當 budget 消耗過快時，團隊需要知道哪些變更暫停、哪些修復可繼續、哪些例外需要 owner 核准。

Error Budget 與 Burn Rate

Error budget 的責任是把可靠性退化轉成可管理的風險餘額。它讓團隊在「追求穩定」與「持續變更」之間有共同語言。

Burn rate 要看短窗與長窗。短窗能捕捉快速事故，長窗能避免一次性尖峰造成過度反應；兩者一起使用，才適合觸發 page、ticket 或 release freeze。

Budget warning 適合做風險整理。團隊可以檢查近期 deploy、feature flag、migration、capacity、dependency 與 incident review action item，判斷是否需要降低變更速度。

Budget critical 適合觸發 release gate。此時可靠性風險已經從觀測層進入決策層，團隊需要把發布、rollback、capacity 與 incident readiness 放在同一張表中判讀。

Budget exhausted 適合觸發可靠性改善。改善內容可能是修 bug、補 capacity、降低 alert noise、補 runbook、重設 SLO 或清理 reliability debt。

判讀訊號

• SLO 數字無 owner、過半年沒檢視
• burn rate 無 alert、只有 monthly review
• error budget 耗盡但 deployment 節奏不變
• SLI 用 system metric（CPU / memory）、不對應 user journey
• 目標數字是抄來的（99.9 / 99.99）、無商業 anchor

案例對照

Google 提供的是制度原點，因為它把 SLO、post-incident review 與 toil budget 串成可管理的可靠性文化。Honeycomb 提供的是訊號層的延伸，因為 high-cardinality 與 burn rate alert 讓 SLO 可以在真實流量下被看見。Stripe 則把 SLO 風格的決策壓到交易語義上，讓 idempotency 與 migration 不會因為重試而失真。

當讀者把這三個案例放在一起，就會看見 SLO 不只是「填一個百分比」，而是把不同層級的風險接到同一條路由：制度、訊號與交易正確性。這也是本節章節要建立的核心能力。

Error Budget 三對齊跟 Release Gating

Error budget 三對齊是把「SLI 範圍」「SLO 目標」「Budget gate 觸發點」分別跟「使用者價值 / 可接受承諾 / 交付節奏」綁定的設計練習。任一條未對齊、policy 就會跟團隊行為脫鉤 — SLI 不對齊使用者價值、policy 就保護錯的東西；SLO 不對齊承諾、團隊就追錯目標；Gate 不對齊交付節奏、政策就無人遵循。

對應 G1 Google Error Budget Policy：揭露 SLO policy 設計的三個對齊 — 使用者行為對齊（哪些 journey 直接反映服務價值 → SLI 範圍）、可靠性承諾對齊（什麼水準算服務仍可接受 → SLO 目標）、交付節奏對齊（可靠性消耗到哪裡要改變發布策略 → Budget gate）。

三對齊完成後、release gate 可從「主觀風險判斷」轉成「政策驅動」：

• budget 健康：正常發版
• budget 快速消耗：啟用變更限速、提高驗證門檻
• budget 透支：凍結非必要變更、先修復與回補訊號

把 budget gate 跟 6.8 release-gate 變更分層段 綁定、讓「budget 三階段」對應「release gate 三層放行決策」。

Error budget 是「可靠性 vs 交付節奏」的平衡工具、不是被追求的固定分數。當 budget 被 KPI 化、SLI 範圍會被縮小、告警會被延後、例外條件會被擴張 — 三者都降低 budget 的判讀可信度。

Burn Rate 雙窗監控

Burn rate 雙窗監控是把「budget 消耗速率」拆成短窗（急性事故）跟長窗（慢性退化）兩個 channel、各自觸發不同回應的設計。比固定閾值告警更接近使用者體感、且能區分「需立即頁」跟「需排修復節奏」。

對應 HC1 Honeycomb Burn Rate 驅動可靠性操作：揭露 fast burn / slow burn 雙窗監控的價值 — 固定閾值告警在高變化流量下容易失真、burn rate 提供比固定閾值更接近使用者體感的判讀方式。

雙窗監控的設計：

• Fast burn（短窗、高消耗率）：捕捉急性事故、觸發 page 立即響應
• Slow burn（長窗、低消耗率持續累積）：捕捉慢性退化、觸發 ticket 排入修復節奏

兩窗一起用、避免單一閾值在不同流量型態下失真。Honeycomb 自家平台展示 burn rate 訊號可以跟 trace outlier path 對接 — 看到 burn rate 上升、能直接跳到具體退化 trace（這是 Honeycomb 的產品特色、tracing-first 對 burn rate 的補強）。vendor-neutral 的同類概念見 4.3 tracing-context 跟 4.6 sli-slo-signal 的訊號設計。

控制面

SLO 與 error budget 的控制面是把可靠性訊號接到發布、事故與改善流程。SLO 只有在能改變團隊行為時，才會成為政策。

1. SLI 設計回到 4.6 SLI 量測與 SLO 訊號設計。
2. 資料品質限制回到 4.17 Telemetry Data Quality。
3. Budget warning 進入 release risk review。
4. Budget critical 進入 6.8 Release Gate。
5. 事故觸發與復盤回寫進入 8.1 事故分級 與 8.5 復盤。

SLO policy 需要定期校準。服務規模、使用者旅程、依賴型態與商業風險變化後，原本的 SLI、objective 與 freeze 條件也要重新檢視。

SLO policy 也需要例外流程。重大資安修補、合規變更、資料修復或客戶承諾可能需要在 budget 緊張時繼續推進；例外應記錄 owner、理由、風險與回退條件。

產業情境：金融科技

金融服務的 error budget 治理需要把合規週期納入凍結條件。交易關鍵路徑（payment / settlement / reconciliation）的 SLO 破壞可能直接觸發監管通報義務，budget 消耗到門檻時的升級路徑必須包含合規人員。

交易路徑的 SLI 選型需要涵蓋 correctness（reconciliation error rate），availability 和 latency 通過但對帳失敗仍然是 SLO 破壞。correctness SLI 的量測來源通常是日終或即時的 reconciliation pipeline，跟 availability SLI 的即時 request-level 量測有不同的時間粒度。

Budget 凍結的觸發條件除了 burn rate，還要對齊監管報告週期。若 budget 在季末報告前已消耗過多，凍結應提前啟動，因為報告期間內的可靠性退化會被放大審視。這個提前量取決於報告週期長度與修復節奏 — 月報制的提前量比季報制短。

Error budget 政策的升級路徑需要跟 compliance team 對齊。budget warning 階段通知工程 owner；budget critical 階段同時通知合規人員；budget exhausted 階段啟動合規審查流程。這個分層讓合規介入的時機跟工程介入同步，避免事後才發現可靠性退化已觸發通報義務。

金融場景的 budget 恢復比一般 SaaS 慢。恢復期間需要額外的 reconciliation 驗證（確認退化期間無交易錯漏）才能宣告 budget 回補。若 reconciliation 發現差異，budget 恢復會被延後直到差異被解決。這個約束讓金融服務的 freeze 持續時間通常比一般服務長。

常見反模式

SLO 反模式通常來自把目標數字當成可靠性制度本身。數字需要對應旅程、資料、owner 與決策，才有工程意義。

Cargo-cult 99.99% 的問題在於缺少服務脈絡。高可用目標會增加架構、成本、演練與值班負擔；低可用目標則會增加使用者與商業風險。合理目標要從服務承諾回推。

System metric SLO 會讓可靠性偏向基礎設施視角。CPU 健康不代表 checkout 成功，pod running 不代表資料新鮮；系統指標適合支援 diagnosis，user journey 指標適合承載 SLO。

交接路由

• 04 訊號治理：SLI / burn rate metric 設計
• 06.8 release gate：error budget 耗盡觸發 freeze
• 06.9 capacity / cost：容量不足傳導為 SLO 風險
• 06.14 dependency budget：依賴可靠性納入 SLO 算式
• 08 事故閉環：burn rate alert 啟動條件
• 08.13 repeated / toil：error budget 撥用 toil reduction
• 06.18 reliability metrics：SLO 跟 DORA / SPACE 的指標分層

本章目標

讀完本章後、你應該能：

1. 寫 Locust user class + task
2. 跑 standalone + distributed mode
3. 自訂 client（非 HTTP、如 gRPC / WebSocket）
4. 設計 task weight + on_start / on_stop hook
5. 評估 Locust vs k6 / Gatling 的選用

最短路徑：5 分鐘把 Locust 跑起來

1# 1. 安裝
2# TODO: pip install locust
3
4# 2. 寫 locustfile.py
5# TODO: class User(HttpUser): wait_time = ..., @task def hello(self): ...
6
7# 3. 跑
8# TODO: locust -f locustfile.py --host=http://target
9# TODO: 瀏覽器 http://localhost:8089 操作

日常操作與決策形狀

User class + task

子議題：

• HttpUser / FastHttpUser（FastHttpUser 用 geventhttpclient、效能高）
• @task decorator + weight
• on_start / on_stop（per-VU setup / teardown）
• 對應 Python class inheritance

Distributed mode

子議題：

• master：協調 + 收集 metric
• worker：實際發送 request
• locust --master / locust --worker --master-host=...
• 多 worker 突破 Python GIL 限制

Web UI vs headless

子議題：

• Web UI（dev / interactive）
• Headless（--headless --users N --spawn-rate N --run-time T）
• 對應 CI 整合：CSV report

進階主題（按需閱讀）

自訂 client（非 HTTP）

子議題：

• 任何 Python lib 都可包成 user
• gRPC / WebSocket / database / queue 都行
• request event 手動 fire

Custom request

子議題：

• self.client.get/post（HTTP）
• 自訂 event emission
• Custom statistics

locust-plugins 生態

子議題：

• locust-plugins：第三方 plugin（CSV report enhanced / Postgres / Kafka / etc）
• Custom shape（dynamic load profile）
• TaskSet / SequentialTaskSet

CI integration

子議題：

• Headless mode + exit code
• CSV / JSON report
• 對應 6.8 Release Gate

Distributed scaling

子議題：

• Kubernetes 部署
• 多 region load source
• Result aggregation

排錯快速判讀

High VU 跑不上去

操作原則：Python GIL + 單 worker 限制、用 distributed mode。判讀：CPU / network bottleneck？

Worker disconnect

操作原則：master / worker network 不通、heartbeat timeout。判讀：log + master UI。

Custom protocol 報告不正確

操作原則：手動 event fire 缺 / metric name 不對。

Memory leak

操作原則：long run test、user state accumulate。判讀：on_stop cleanup。

何時改走其他服務

不在本頁內的主題

• Python 語言基礎
• gevent / asyncio 內部
• locust-plugins 完整列表

案例回寫

Case 庫稀薄：本 cases/ 目錄目前沒有以 Locust 為主軸的案例。可參考候選方向：

• 待補 Locust customer case：Python-heavy 團隊 load test 採用案例、distributed Locust 大規模部署案例
• 候選 case：Pinterest（ML serving / 推薦系統壓測場景）、Spotify（squad-based 各團隊自管壓測）— 若未來收錄需先在 cases/ 補正文，本欄再寫實際 link

下一步路由

• 上游概念：6.13 Performance Regression Gate
• 平行 vendor：k6、Gatling
• 下游能力：09 performance capacity

本輪規劃採問題驅動方法、用 SRE 領域 first-class 詞彙（SLI / SLO / Error Budget / Failure Mode / Chaos Hypothesis），把驗證議題拆成問題節點，蒐集公開 SRE 實踐作為服務級案例庫，再把控制面交接到可觀測性、部署平台與事故處理模組落地。

驗證角色

可靠性驗證的角色是把「系統會不會在真實壓力下失敗」變成可預演的工程問題。這一層不負責寫測試語法，也不負責定義服務功能，而是負責定義哪些失效值得被主動打破、哪一種訊號可以證明風險存在、哪一種門檻可以阻止變更往下流。

當讀者把驗證看成流程，就會自然分出三個層次。第一層是訊號，先知道要看什麼。第二層是演練，先知道要怎麼打。第三層是放行，先知道什麼情況需要暫停或退回。這三層分別對應可觀測性、可靠性驗證與交付平台的責任。

問題節點

問題節點先描述失效風險，再描述驗證手段。這樣寫的好處是，讀者能先理解「為什麼要驗證」，再看到「怎麼驗證」，讓工具名回到解題手段的位置。

這張表的責任是提供路由。每一列都要回到服務案例庫，從公開實踐找出真實世界的樣本，把問題節點和失效模式綁在一起。

案例庫讀法

案例庫的責任是提供幾種反覆出現的失效與驗證模式。Google、Netflix、Amazon、Stripe 與 Shopify 這五個 T1 案例，分別對應量化門檻、主動故障注入、隔離邊界、交易正確性與峰值準備。

當讀者遇到某個驗證節點卡住時，可以先問三個問題。第一，現在缺的是訊號還是門檻。第二，失敗是在單一服務內還是在依賴鏈上。第三，這種風險更像回歸、容量、變更還是恢復問題。這三個問題會把讀者導向不同案例頁，也會把讀者導回可觀測性、部署平台或事故處理的交接節點。

Vendor / Platform 清單

實作工具見 vendors — T1 收錄 CI（GitHub Actions / CircleCI）、Load test（k6 / Gatling / JMeter / Locust）、Chaos（Chaos Mesh / LitmusChaos / Gremlin / Toxiproxy）、SLO（Nobl9 / Sloth）共 12 個 vendor 骨架。跟 cases/ 是不同維度（cases 是教學案例來源、vendors 是實作工具）。

進入工具比較前，先回到 觀測、可靠性與事故服務選型 判斷目前缺的是驗證層能力，還是缺少可觀測性的訊號 baseline 或事故處理的接手流程。可靠性工具選型要以「能否安全驗證失敗」為主軸，CI、load、chaos 或 SLO 工具名稱只是落地選項。

Deep article（工具自身的配置、故障、容量）跟 migration playbook（跨工具遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

規劃方向

本輪規劃的核心是把模組從「驗證手段列表」升級成「失敗風險節點 + 服務級案例庫」兩層結構：

1. 問題節點先行：6.1-6.5 主章已建立、補 6.6（SLO/Error Budget）/ 6.7（DR & Rollback Rehearsal）/ 6.8（Release Gate & Change Cadence）/ 6.9（Capacity & Cost）等節點，不綁特定框架。
2. 服務級案例庫：以公開 SRE 實踐（Google / Netflix / Amazon / Stripe / Shopify 等）作 cases，每個服務一個資料夾、累積架構脈絡與多次驗證案例。
3. 資安驗證是其中一類：跟 07 的交接點維持，但 07 的紅藍隊框架不外推到本模組 — SRE 自有 Failure Mode / Pre-mortem / FMEA / Chaos Hypothesis 等 first-class 詞彙、不需要藉攻防隱喻表達。

不經實作即可推進的理由：可靠性的價值在「失敗模式預判與驗證設計」，這層跟具體框架解耦，SRE 公開素材成熟，符合先建概念層的條件。

模組方法

問題驅動方法的核心是讓案例退到證據角色，讓知識網以失敗風險為主體。

1. 先定義驗證環節問題與失敗風險邊界。
2. 再定義判讀訊號（容量門檻、退化曲線、依賴失效模式）與門檻條件。
3. 接著定義交接路由與前置控制面。
4. 最後在問題觸發時引用對應服務的 SRE 案例。

模組分工定位

本模組提供觀念、判讀與路由。實作細節由對應模組承接，確保概念層與實作層分工清晰。

• backend/04-observability：可觀測性模組，負責訊號定義、SLO 量測與 alert 治理實作。
• backend/05-deployment-platform：rollout、rollback、流量切換與環境管理實作。
• backend/07-security-data-protection：權限、稽核與高風險演練約束實作。
• backend/08-incident-response：事故處理模組，負責事故指揮、分級與復盤的事中事後流程。

從章節到實作的 chain

各章節交付三樣：問題節點清單、判讀訊號、控制面 link。判讀完成後沿兩條 chain 進入 implementation：

1. Mechanism chain：點問題節點表的 [control-name] link 進 knowledge-cards、那層展開機制 / 邊界 / context-dependence。例：[circuit-breaker] 的 knowledge-card 是該 control 的 mechanism SSoT。
2. Delivery chain：章節「交接路由」欄位指向下游模組，包括可觀測性（訊號 / SLO）、部署平台（rollout / rollback）、資安與資料保護（權限約束）與事故處理（事故閉環）。

兩條 chain 走完，控制面交付完整。Implementation 強度取決於兩條 chain 的完成度，章節閱讀本身完成 routing 階段。

跟既有模組的串接

本模組是「觀測 → 驗證 → 事故」閉環的中段、承接資安概念判讀、同時餵給事故處理閉環。資安驗證僅是驗證的一個子集、其他多數驗證是容量 / 變更 / 依賴類。

觀測、驗證與事故閉環交接基線：

• 來自 可觀測性平台：SLO / SLI 量測 baseline、production 訊號是 chaos hypothesis 與 SLO 政策的依據。沒有可信訊號就沒有可信驗證。
• 餵給 可觀測性平台：驗證需求驅動訊號設計 — chaos experiment 需要新 metric、load test 需要新 dashboard、SLO 政策需要新 alert rule。
• 餵給 事故處理與復盤：把事前演練結果作為事中決策素材、game day 暴露的 runbook 缺口直接補進值班與演練能力建設。
• 來自 事故處理與復盤：事故 post-incident review action items 回寫成新 chaos / DR 演練題目。
• 詳細閉環說明：見 Observability / Reliability / Incident Response 閉環。

07 資安交接基線：

• 來自 7.4 資料保護與遮罩治理：承接資料外送與回復排序的驗證場景。
• 來自 7.7 稽核追蹤與責任邊界：承接事件證據完整性與回查演練。
• 來自紅隊 7.R4 資源濫用與可用性破壞：承接壓力放大路徑與降級回復驗證。
• 來自 7.23 資安與可靠性的共同控制面：承接 rollback、containment、degradation 共用語意。

與語言教材的分工

語言教材處理測試程式如何寫得可讀、可重現、可定位。Backend reliability 模組處理測試如何在 CI、環境、資料庫、broker、網路與部署流程中被執行。

企業案例補充

可靠性案例補充的重點是「驗證機制如何被制度化」。閱讀時先抓它在保護哪一種風險，再對照本模組的驗證節點與放行門檻。

若要延續案例擴充，先從 0.14 企業選型案例圖譜 找到對應規模與產業，再回到本模組決定要補哪一類驗證節點（6.6、6.19、6.20、6.22、6.24）。案例頁與主章的關係是「案例提供壓力樣本，主章提供放行規則」。

產業情境回寫覆蓋 7 個產業，每個產業回寫到 2 個最相關的章節。不同產業的約束類型不同（監管 / 即時互動 / 合規 / 季節峰值 / 多租戶 / 即時交付 / 邊緣可靠性），通用章節覆蓋不到的差異由產業情境段補齊。

跨語言適配評估

可靠性驗證使用方式會受語言的測試框架、fixture 生態、並發測試能力、型別系統、fuzz 支援與容器化工具影響。同步 runtime 要測 thread pool、connection pool 與 timeout；async runtime 要測 event loop blocking、task cancellation 與 backpressure；動態語言要用 contract test 與 runtime validation 補足 schema 風險；強型別語言要把型別安全延伸到外部 payload 與 migration 相容性。

主章規劃

註：6.1-6.25 已完成概念層與第一篇實作示範正文，案例庫可支援 SLO、readiness、experiment boundary、evidence handoff 與 release gate 實作路由。後續工作重點是案例深挖與主章回寫密度，不是章節補齊。

個案前拓展空間

個案前拓展的責任是先建立驗證判準，再讓服務案例成為證據。可靠性驗證適合補「怎麼安全地驗證失敗」這類跨服務流程，不適合先把 Google / Netflix / Amazon 的故事直接展開。

本輪先完成其中三個前置章節：Reliability Readiness Review、Experiment Safety Boundary 與 Steady State Definition，並補強 6.6 SLO / Error Budget 政策。服務案例完成後，若教訓是「上線前準備不足」，回寫 Reliability Readiness Review；若是「實驗本身造成過大影響」，回寫 Experiment Safety Boundary；若是「反覆事故沒有被工程化」，回寫 Reliability Debt Backlog；若是「chaos 沒有穩態定義」，回寫 Steady State Definition。

後續深化方向

06 後續深化以「多事件案例鏈、驗證證據欄位統一、事故路由回寫」為主。可靠性驗證承接 04 的訊號可信度，並把結果穩定交給 08 的 incident 決策流程。

實作探討入口

進入實作層時，06 建議先做一條最小 release gate：同一個變更同時具備 SLO 狀態、readiness 結論、experiment 證據、rollback 條件 四欄，並寫入 6.23 供 8.19 直接調用。

首篇示範已完成： 6.25 Provider Dependency Release Gate 實作示範。

完成條件是每篇都能回答四件事：可靠性目標、驗證訊號、停止或凍結條件、事故或發布路由。這樣可靠性章節才會成為「觀測 → 驗證 → 事故」閉環的中段，而不是測試工具清單。

服務案例庫規劃

服務作為案例單位、累積架構脈絡與多次驗證實踐。每個服務一個資料夾、收錄該服務的 SRE 實踐、failure mode 與 chaos / DR 案例。資料夾位置：content/backend/06-reliability/cases/{vendor-service}/。

T1（必寫、SRE 教學標竿）

T2（補不同視角）

T3（補完）

模組完成狀態

主章 6.1-6.25 已完成首輪正文，服務案例庫第一批正文已補齊（T1：Google / Netflix / Amazon / Stripe / Shopify；T2/T3：LinkedIn / Honeycomb / Microsoft / Spotify / Pinterest / Meta）。目前重點從「補章節骨架」轉為「補案例深度與跨章節回寫」。

案例正文入口見 可靠性案例庫。每篇案例至少要能回寫一個章節判準（例如 6.6、6.19、6.20、6.22、6.23、6.24），避免案例只停留在事件敘事。

第二批案例深挖已補 Google 與 Netflix 的第二篇正文： Google Postmortem Closure 治理 與 Netflix Business-Hours Chaos Guardrails。兩者分別對應 6.21 / 8.5 / 8.22 與 6.19 / 6.20 / 6.22 / 8.6 的制度化回寫。

深挖批次 B 已補 Google 第三篇制度案例： Google Toil Budget 與 Automation 投資政策。這篇把 toil ratio 直接接到 6.8 / 6.21 / 8.22，補齊「值班壓力 → 工程投資 → release gate」的決策鏈。

第三批案例補強已補 Netflix 第三篇： FIT 證據交接與 Release Gate 回寫。這篇把故障注入結果直接接到 6.23 / 6.24 / 8.19 / 8.22，補齊「實驗結果 → 放行決策 → 事故調用」的鏈路。

Case-First 第四批：8 章 stage 2 擴充

依 Case-First + Agent Team Review 流程 完成 8 個章節的 case-driven 擴充（commit 3c33ea9 / 41c0101）、覆蓋全部 15 個 content case：

擴充紀律對應 Case-First Module Workflow 的五階段流程、用 agent team review 三維度（寫作規範 / 案例引用 / 跨章一致性）驗證、case fidelity 達 88%。

下一輪推演大綱

推演資產化的完成條件是讓讀者能從一個失敗風險出發，找到驗證節點、服務 case 與回寫章節。完成後可靠性模組才進入穩定維護狀態。

本輪全面推進（2026-06-23）

主章 6.1-6.25 全部從骨架擴充到完整內容（最小 75 行、中位 113 行、最大 176 行），覆蓋概念定位、判讀訊號、案例回寫與交接路由。案例庫補齊 T1/T2/T3 第二批正文共 9 篇（Amazon A2 / Stripe S2 / Shopify H2 / LinkedIn L2 / Meta M2 / Honeycomb HC2 / Microsoft MS2 / Spotify SP2 / Pinterest P2），11 個 vendor 各有 2+ 篇案例。Vendor deep article 新增 4 篇（k6 / Chaos Mesh / Sloth / GitHub Actions）。產業情境回寫 3 組（FinTech → 6.6+6.8 / Gaming → 6.22+6.24 / Healthcare → 6.7+6.19）。經過三輪多輪審查（寫作規範 / cadence 同質化 / steelman reality test）修法。

目前模組處於穩定維護狀態。剩餘 backlog：8 個 vendor 的 deep article（CircleCI / Gatling / JMeter / Locust / LitmusChaos / Gremlin / Toxiproxy / Nobl9）、08 模組的 06 反向引用補齊、判讀訊號表格補行動建議欄。

Tripwire

• 寫 T1 服務第 3 個時、若 case 之間無共通分類軸 → 改用單服務獨立檔，不開資料夾。
• 寫到第 9 主章發現章節覆蓋 60%+ → 軸線過於相似、合併或重切。
• 進服務實作模組時 routing chain 走不通 → 回頭補對應主章。

既有可引用卡片

• load test
• chaos test
• fuzz test
• idempotency
• schema migration

DR 演練與 rollback rehearsal 是把回復能力從「有計畫」變成「經過驗證」的工具。DR 關心的是系統在災難後能不能回來，rollback rehearsal 關心的是變更失敗時能不能退回安全狀態。兩者的責任是把回復路徑變成可驗證流程。

這個節點先處理路徑，再處理速度。先確認資料能不能回來、服務能不能切回來、回復後會不會再掉回去，然後才談 RTO / RPO。這樣讀，會比直接背指標更接近真實系統的恢復成本。

核心判讀

DR 的責任是證明回復路徑存在，而且可實際走通。只要 backup 還沒被 restore 驗證過，它就只是備份，不是復原能力。只要 failover config 沒跟 production 對齊，它就只是文件，不是操作路由。

rollback rehearsal 的責任是把失敗變更的退路先跑過。當 deployment 出現問題時，團隊需要知道自己是能回退、必須 roll forward，還是必須先止血再處理資料。這個判斷來自平常 rehearsal 的累積，臨場才不會陷入猜測。

Rollback vs Roll-forward 的判斷條件

變更失敗時的第一個決策是退回還是往前修。這個判斷取決於變更是否可逆，以及新資料是否已經依賴新版結構。

rollback 的前提是變更可逆：schema 仍向下相容、feature flag 可關閉、routing 可切回前一版。當這些條件成立時，rollback 通常比 roll-forward 更快收斂，因為退回的行為已經被驗證過（它就是前一版的 production 狀態）。

roll-forward 的前提是修復比退版快且安全。當新版已經寫入不可回退的資料（新欄位被使用、新格式被下游消費、交易已在新路徑完成），退版會造成資料遺失或不一致，此時 roll-forward 是被迫的選擇，不是偏好。

兩者之間存在灰色地帶：schema migration 已執行但流量尚未切換、feature flag 已開啟但影響範圍有限。這類情境需要事前在 rehearsal 中定義判斷條件，而不是事中討論。第三種常見路徑是先 rollback 止血（降低 customer impact），確認穩定後再推出修復版 roll-forward。這個 hybrid 策略的前提是 rollback 安全且修復方案已知。

Stripe 的 expand/contract migration 模型 說明交易系統的 rollback 需要同時處理 schema 相容與冪等重播。當 idempotency key 與業務操作邊界一致時，rollback 後的重試才能產生正確結果。這個案例揭露的判讀條件是：rollback 安全性不只看部署層，還要看資料語義層。

Restore 驗證

備份的價值在還原時才能被證明。restore drill 的責任是證明備份能在需要時變成可用的服務狀態。

restore 驗證分三個層次，每一層回答不同的問題。

資料完整性：還原後的資料是否完整。驗證手段包含 row count 比對、checksum 校驗、reconciliation query。這一層的失敗模式通常是 backup 時段選擇不當（跨越 batch job 執行期）或 incremental backup 鏈條斷裂。

服務可用性：還原後的系統是否能正常回應。資料完整不代表服務可用 — config、secret、schema version、connection pool 設定都可能在 restore 後失效。這一層需要在 restore 完成後跑 smoke test 與 health check，確認服務能處理請求。

恢復時間量測：實際 RTO 是否符合承諾。如果承諾 4 小時 RTO 但 restore 本身需要 6 小時，這個承諾就是空的。量測要包含從決策啟動到服務恢復的完整時間，不只是資料還原時間。Roblox 2021 的 73 小時 outage 說明 recovery 不是切回流量就結束 — 資料一致性重建、快取預熱與依賴服務的啟動順序都會拉長實際恢復時間。

演練類型

這些演練的共同點是：演練本身要留下證據。沒有輸出，就沒有辦法判斷回復能力到底有沒有被建立。

Tabletop 的重點是決策路由清晰度。參與者在紙上走一遍事故情境，回答「誰負責決定切換」「什麼條件觸發升級」「通訊延遲多長可接受」。這個類型成本最低、頻率應最高，適合用來發現流程漏洞與角色模糊。

Partial failover 的重點是切換腳本與監控覆蓋。選擇一個子系統或單一 availability zone 做真實切換，驗證自動化腳本是否可執行、監控是否能在切換過程中保持可見性。這個階段常暴露的問題是：腳本假設的前提條件在 production 不成立，或監控在切換過程中產生大量 false positive。

Full region failover 的重點是資料一致性與恢復順序。Meta 的 2021 年事故顯示，跨區 failover 的最大風險在恢復順序 — 控制面與資料面共用路徑時，先恢復哪條路徑會直接決定整體恢復時間。當恢復動作本身依賴尚未恢復的控制面服務，恢復會陷入循環等待。

演練節奏與升級

演練是按風險層級安排的循環流程。

每輪演練產出的缺口應回寫到 6.21 reliability debt backlog，成為下一輪演練的驗證目標。Google 的 postmortem action item closure 治理說明把事故教訓轉成有 owner 與完成條件的改進項，這個機制同樣適用於演練缺口：P0 缺口應在下個 release 週期前修復，P1 缺口應排入固定追蹤。

Shopify 的 BFCM 準備流程把年度高峰前的 game day 當作 DR 演練的自然觸發點。容量模型、隔離邊界與 failover 路徑在 game day 中一起驗證，每輪暴露的缺口回寫成下一輪的準備 checklist。這種做法讓演練節奏跟業務節奏對齊，不是額外負擔。

DR 與 chaos 的邊界

DR 演練與 chaos testing 都涉及故障情境，但驗證目標不同。

Chaos 驗證的是系統在故障持續期間能否維持服務。它的成功條件是 steady state 不被破壞，停止條件是 steady state breach。chaos 實驗結束後，系統應該仍在運作。

DR 驗證的是系統在災難發生後能否回來。它的成功條件是恢復路徑可執行且符合 RTO / RPO 承諾，停止條件是恢復時間超過 RTO 或資料遺失超過 RPO。DR 演練結束時，系統經歷了一次完整的失效與恢復循環。

兩者的交集是 failover drill：chaos 關心切換期間的服務退化程度，DR 關心切換完成後的恢復品質。在實務上，成熟團隊會把 chaos experiment 的結果作為 DR 演練的輸入 — chaos 發現的弱點變成 DR 演練的測試案例。Amazon 的 cell boundary 與 static stability 設計讓恢復可分批執行，同時服務 chaos 驗證（局部故障不擴散）與 DR 驗證（分批恢復可預測）。

產業情境：醫療系統

醫療系統的 DR 演練受合規（HIPAA / GDPR health data）和臨床連續性的雙重約束。演練設計需要同時滿足技術恢復目標與臨床安全要求。

演練排程需要跟臨床作業週期對齊。手術高峰、急診高峰與夜班交接時段都應避免做 failover 演練，因為演練造成的短暫服務中斷可能直接影響臨床決策。可執行窗口通常是週末凌晨或排定的維護時段。

恢復順序由臨床風險決定。EMR（電子病歷）系統優先於醫囑系統、PACS（影像系統）與行政系統。這個順序跟技術依賴不完全重疊 — 技術上 PACS 可能先恢復更快，但臨床上 EMR 的中斷風險更高。恢復順序的設計需要臨床代表參與，技術團隊單獨決定會漏掉臨床優先級。

Restore 驗證需要額外的 audit trail 完整性檢查。HIPAA 要求能追蹤誰在什麼時間存取了哪些病患資料，恢復後的資料若 audit trail 斷裂，即使資料本身完整也不符合合規要求。restore drill 的校驗清單需要把 audit trail 連續性納入必檢項。

醫療紀錄的 RPO 通常比一般 SaaS 更嚴格，接近零資料遺失。遺失的醫療紀錄可能直接影響用藥決策或手術判斷，RPO 設定需要對齊臨床風險而非技術方便性。

演練證據本身也需要合規留存。DR 演練紀錄、恢復時間量測、缺口清單與改善追蹤都是合規審計的輸入。沒有留存的演練在審計視角等同未演練。

產業情境：IoT 與製造系統

IoT 裝置的 rollback 成本遠高於雲端服務。雲端服務的 rollback 是 deploy 前一版 container image，秒級生效；IoT 裝置的 rollback 需要 OTA（Over-the-Air）推送，受限於裝置連線狀態、頻寬、電量與儲存空間。部分裝置可能在 rollback 過程中斷線，進入新舊版本混合的不一致狀態。

DR 演練需要包含「裝置不在線」場景。工業場景的裝置可能在偏遠地點、離線數天到數週。DR 計畫需要回答「離線裝置重新上線後，如何安全地同步到正確版本」，以及混合版本期間的相容性處理。

安全關鍵系統（製造產線控制、醫療設備、車載系統）的回退約束比一般軟體更嚴格。firmware 缺陷可能造成物理傷害，rollback 後需要跑功能安全測試（IEC 61508 等級的驗證），確認回退版本在目標硬體上的行為符合安全規格。

A/B firmware partition 是 IoT 的 DR 基礎設計。裝置保留兩個 firmware slot（active / inactive），更新寫入 inactive slot，驗證通過後切換到新 slot。失敗時切回原 active slot，整個過程在裝置本地完成，不需要額外 OTA 推送。這個設計讓裝置的 rollback 路徑跟 Amazon A2 的 static stability 概念對齊 — 即使控制面（OTA server）不可用，裝置仍能用本地 slot 切換完成回退。

案例對照

判讀訊號

交接路由

• 05 部署平台：blue-green / region failover 實作
• 6.4 chaos testing：chaos 暴露的弱點變成 DR 演練題目
• 6.11 migration safety：migration rollback 演練
• 6.12 idempotency / replay：replay 是 DR 回復的前提
• 6.21 reliability debt backlog：演練缺口回寫
• 6.25 provider dependency release gate：provider 變更的 rollback 實作示範
• 8.3 止血回復：演練結果作為事中決策素材
• 8.6 演練與值班：DR 結果回饋到團隊技能建設
• 8.15 vendor 事故：多 vendor / 多區 failover 路徑

本章目標

讀完本章後、你應該能：

1. 部署 Chaos Mesh 到 K8s cluster
2. 設計 PodChaos / NetworkChaos / IOChaos experiment
3. 用 Chaos Workflow 編排多步驟實驗 + steady state probe
4. 控制 blast radius（namespace / labelSelector / mode）
5. 跟 6.20 Experiment Safety Boundary 對齊 chaos 實驗審批

最短路徑：5 分鐘把 Chaos Mesh 跑起來

1# 1. 安裝
2# TODO: curl -sSL https://mirrors.chaos-mesh.org/v2.7.0/install.sh | bash
3
4# 2. 跑第一個 PodChaos
5# TODO: 寫 podchaos.yaml、kubectl apply
6# TODO: action: pod-kill / selector / mode
7
8# 3. Dashboard
9# TODO: kubectl port-forward svc/chaos-dashboard 2333:2333

日常操作與決策形狀

CRD 設計

子議題：

• PodChaos：pod-kill / pod-failure / container-kill
• NetworkChaos：delay / loss / duplicate / corrupt / partition
• IOChaos：delay / errno / mistake / attrOverride
• StressChaos：CPU / memory pressure
• 對應 GitOps：Helm / Kustomize 管 experiment

Chaos Workflow

子議題：

• 多步驟 chaos 編排（serial / parallel）
• Suspend / resume 控制
• Probe（steady state validation）
• 對應 6.20 Experiment Safety Boundary

Chaos Dashboard

子議題：

• 視覺化 experiment timeline
• Experiment archive
• Event log
• RBAC

進階主題（按需閱讀）

Blast radius 控制

子議題：

• namespace 限制
• labelSelector / value mode（one / all / fixed / fixed-percent / random-max-percent）
• annotationSelector
• Pause / resume 緊急中止

Schedule 與 GitOps

子議題：

• Schedule CRD 定期 chaos
• ArgoCD / Flux 整合
• Experiment as code review

跟 LitmusChaos / Gremlin 對比

子議題：

• Chaos Mesh：CRD-driven、PingCAP 主導
• LitmusChaos：ChaosHub experiment / CNCF graduated
• Gremlin：商業 SaaS、跨平台
• 選擇判讀：K8s OSS first → Chaos Mesh / Litmus；商業跨平台 → Gremlin

Steady state 驗證

子議題：

• HTTP / TCP / Pod / podHTTPChaos
• Probe success threshold
• 跟 9.13 SLO 對應 burn rate

排錯快速判讀

Experiment 沒生效

操作原則：先 kubectl describe podchaos 看 status、再看 webhook + RBAC。

Blast radius 過大

操作原則：mode 設 all 或 percent 設太高、影響超出預期。預防：先 dry-run / staging 測試。

Pause 不及時

操作原則：experiment running 中要 pause、不是 delete（delete 不會 cleanup state）。

Dashboard 連不上

操作原則：service 沒暴露、RBAC 不對。

何時改走其他服務

不在本頁內的主題

• 完整 CRD spec
• Chaos Mesh internal architecture
• 各 fault type 詳細 parameter

案例回寫

待補 Chaos Mesh customer case：PingCAP / TiDB 客戶 Chaos Mesh 案例、CNCF Chaos Mesh adopters。

下一步路由

• 上游概念：6.20 Experiment Safety Boundary
• 平行 vendor：LitmusChaos、Gremlin
• 下游能力：8 incident response（chaos finding 進 IR 流程）

Release gate 是把放行決策從「看起來可以」變成「條件已經達成」的控制面。它的責任是把哪些變更可以進、哪些變更要等、哪些變更必須先補證據說清楚，擋住所有變更從來不是目標。當 gate 被寫成政策，團隊就能用同一套條件判斷 CI、SLO、migration、相容性與高風險時段。

這個節點先處理節奏，再處理工具。先問變更是否應該放行，再問這次放行需要哪些訊號與檢查。當 gate 被看成節奏控制，讀者就會明白為什麼 freeze 是可靠性政策的一部分，視為例外會弱化整套節奏控制。

大綱

• release gate 的核心責任：把放行決策從個人判斷變成可驗證條件
• gate 類別：CI 通過、SLO 健康、error budget 餘額、migration 可逆、相容性檢查
• 變更節奏：deploy frequency、batch size、change failure rate（DORA 四指標）
• freeze 條件：error budget 耗盡、事故進行中、高風險時段
• 跟 6.6 SLO 的耦合：error budget 是 gate 的一個條件
• 跟 05 部署 的交接：gate 通過後 rollout 策略接手
• 反模式：gate 流於形式、freeze 無 owner、緊急修復繞過 gate 變常態

核心判讀

gate 的責任是把放行條件具體化。CI green 只代表測試通過，不代表服務可以安全進 production；SLO 健康只代表目前風險可接受，不代表任何變更都能繼續推；migration 可逆只代表退路存在，不代表已經證明回退完全無害。這些條件要一起看，才知道 gate 有沒有真的在做事。

資料庫 migration 的 gate 要把 evidence 放回 rollout 階段判讀。Expand、backfill、cutover 與 contract 需要不同 checks：compatibility result、validation query、mismatch rate、replication lag、rollback window 與 owner。完整欄位形狀可接到 1.7 Schema Migration Rollout 證據。

freeze 的責任是把風險攔住。當 error budget 耗盡、事故正在進行、或高風險時段已到時，freeze 不應該被視為拖延，而應該被視為維持可靠性的一種放行決策。這樣的政策，會比只看 CI 更接近真實的部署世界。

判讀訊號

• gate 只看 CI green、不看 SLO / error budget / migration 可逆性
• emergency bypass 從例外變週常
• freeze 條件無 owner、沒人知道誰能解凍
• change failure rate 沒量、無法評估 gate 是否有效
• migration 沒做向後相容檢查、rollback 後資料不一致

案例對照

Google 很適合用來看 gate 需要什麼政策語言，因為它把 SLO、error budget 與 post-incident review 連成一套治理系統。Stripe 則適合用來看交易場景下的 gate，因為 idempotency、canary 與 migration safety 會把放行和交易正確性綁在一起。Shopify 可以補峰值節奏，因為 BFCM 前的 gate 不只是測試通過，而是要確定高峰時仍能守住容量與隔離。

Amazon 和 Meta 則提供更偏架構層的 gate 視角。前者告訴我們隔離邊界與 blast radius 會直接影響哪些變更可以放行，後者則顯示 control plane 變更如果沒有足夠的 gate，可能直接把整個區域或整個公司拖進事故。把這些案例一起看，gate 就不再只是 CI 的最後一步，而是整個變更節奏的控制面。

Stripe 的 canary deploy 實踐把金流場景的 progressive rollout 跟交易指標綁在一起：每一批放量用 checkout success rate、duplicate charge、退款率判斷是否安全。金流的 feedback loop 比一般功能長（結帳 → 確認 → 對帳 → 退款），觀察窗必須對齊這個延遲。

gate 類別

這張表的重點是每一類都要對應 owner 與回退條件，分類只是組織方式。沒有回退條件的 gate，只是心理安慰。

變更分層跟 gate 政策

變更分層是把變更依失敗代價跟回退成本切成不同 gate 政策的控制面。讓高風險變更承受高 gate 成本、低風險變更不被高成本拖累、是分層治理的核心責任。可重複套用的做法是先做變更分層、再對應分層 gate 政策。

對應 MS1 Microsoft 變更治理與可靠性門檻：揭露「變更分層 + 漸進發布 + 復盤回寫」三個機制、適用大型 SaaS 高頻變更累積回歸的場景。對應 G2 Google Postmortem AI Closure：揭露 P0/P1 action item 必須綁定 release gate、未完成不得放行關聯變更（這層綁定讓 gate 從 release 工具升級為事故治理工具）。詳見 6.21 Action Item 分級跟 Release Gate 綁定。

可操作的分層方法：

• 低風險變更（配置微調、文案、UI 細節）：CI green + SLO 健康 即可放行
• 中風險變更（新 feature、依賴升級）：加 canary + per-version SLI 偏差檢查
• 高風險變更（schema migration、payment / auth 路徑、跨 region rollout）：加 evidence package + 高風險時段 freeze + P0 action item closure 檢查

高風險層的三類變更要拆開治理、彼此 gate 機制不同：schema migration 的 gate 重點是 expand/contract 階段對齊跟 rollback 路徑（詳見 6.11 migration-safety）；跨 region rollout 的 gate 重點是 ordered failover 跟 blast radius 限制（詳見 6.14 dependency-reliability-budget）；payment / auth 路徑的 gate 重點在交易一致性跟 idempotency（詳見後段「交易類變更的 gate 設計」跟 6.12 idempotency-replay）。三者皆屬高風險、但失敗模式跟回退路徑完全不同。

分層後高風險變更得到匹配的 gate 強度、低風險變更不被拖累、整體交付節奏跟可靠性同步提升。

交易類變更的 gate 設計

交易類變更的 gate 同時承擔可用性跟正確性兩條軸。除了服務健康（一般 gate 已覆蓋）、還要守住交易結果一致性；回退條件也要多看一層：rollback 是否會觸發資料不一致。

對應 S1 Stripe Idempotency 與零停機遷移：揭露 idempotency key + expand/contract migration + canary + rollback gate + transaction observability 四機制組合、適用支付類「可用性 + 正確性同時守住」的場景。

交易類變更的 gate 跟一般 release gate 差別在：

• 一般 release gate 看「服務是否健康」、交易類 gate 還要看「交易結果是否一致」
• 一般 release gate 看「回退是否可行」、交易類 gate 要看「回退是否會引發資料不一致」
• 一般 release gate 看「per-version SLI 偏差」、交易類 gate 要看「duplicate request collapse ratio」「migration phase error drift」「canary transaction anomaly」這類交易專屬訊號

把交易類變更的 gate 從一般 release gate 分出來、寫進獨立 checklist、由 6.12 idempotency-replay 跟 6.11 migration-safety 提供具體欄位。

產業情境：金融科技

金融服務的 release gate 需要把交易正確性放在跟可用性同等的位置。一般 SaaS 的 gate 主要看 error rate 和 latency；金融服務的 gate 需要加上 duplicate detection、settlement 一致性與 compliance audit trail。

變更風險分層跟交易路徑綁定。碰到 payment path 的變更（provider 切換、timeout 調整、retry 策略、settlement 流程）自動升級到高風險 gate，不論變更看起來多小。payment path 的變更即使只改一個 timeout 值，也可能影響交易成功率、重試行為與對帳結果。

Gate 通過條件需要包含交易專屬欄位。idempotency 驗證確認重試不會產生重複扣款；reconciliation 通過確認結算數字一致；audit trail 完整確認每個決策都可追溯。這三項跟一般的 CI green / SLO healthy 是不同維度的檢查，需要獨立 checklist。

高風險變更的 canary 觀察窗需要涵蓋結算週期。一般 feature rollout 的觀察窗是分鐘到小時級；金融變更的觀察窗需要涵蓋 T+1（隔日結算）甚至 T+2，因為交易確認延遲、退款申請與對帳差異可能在數小時到數天後才暴露。觀察窗太短會讓問題在全量放行後才被發現。

Rollback 決策需要考慮已完成交易的一致性。當新版已處理交易且交易已進入結算流程，rollback 可能比繼續 roll-forward 更危險 — 退回舊版的 schema / 邏輯可能無法正確處理新版產生的交易紀錄。這個判斷跟 6.7 rollback vs roll-forward 的判斷條件 對齊，但金融場景的資料不可逆性更高。

產業情境：IoT 與製造系統

IoT 的 release gate 需要處理「一旦推出就難以全面回收」的不可逆壓力。雲端服務的 deploy 可以秒級 rollback；IoT firmware 一旦推送到裝置，回收需要每台裝置個別 OTA，受限於連線狀態與頻寬。

裝置碎片化要求 gate 按硬體版本分群驗證。同一產品線可能有多個硬體版本（rev A / B / C），每個版本的 firmware 相容性不同。release gate 需要按硬體版本群組各自跑 checks，通過的群組才放行推送，不能全域一次放行。

IoT 的 canary 是按裝置群組分批推送，而非按流量百分比分流。推送順序通常是：內部測試裝置 → beta 用戶 → 特定區域 → 全域。每批的觀察窗需要比雲端更長（天到週），因為裝置的 failure mode 可能在特定環境條件下才觸發 — 溫度、濕度、網路品質、電力穩定度都是變數。

OTA 推送一旦開始，中途停止意味著部分裝置已更新、部分未更新。stop condition 需要同時監控「已更新裝置的健康度」和「混合版本之間的相容性」。若新舊版本的通訊協議不相容，部分更新的裝置群可能會觸發新的 failure mode。

安全關鍵系統（車載、醫療設備、工業控制）的 gate 需要額外的功能安全驗證（IEC 61508 / ISO 26262 等），通過合規驗證是放行的前置條件。這類 gate 的 owner 通常跨越工程與合規兩個團隊。

Amazon A2 的 static stability 跟 IoT 的離線運作需求對齊 — 裝置在控制面（OTA server）不可用時，用本地快取的配置繼續運作，回復路徑不依賴已故障的控制面。

交接路由

• 6.1 CI pipeline：CI evidence 是 release gate 的主要輸入
• 05 部署：canary / progressive delivery 實作
• 06.6 SLO：error budget 餘額查詢
• 06.10 contract testing：契約通過作為放行條件
• 06.11 migration safety：可逆性檢查
• 01.7 Schema Migration Rollout 證據：把 migration evidence 轉成 gate decision、checks、stop condition 與 rollback window
• 06.13 perf regression gate：退化作為 freeze 條件
• 07 資安：高風險變更的權限約束
• 08 事故閉環：事故進行中 freeze 觸發
• 06.17 feature flag：rollout 的細粒度控制層
• 06.18 reliability metrics：CFR 是 gate 健康度

本章目標

讀完本章後、你應該能：

1. 部署 Litmus 到 K8s
2. 從 ChaosHub 引用現成 experiment
3. 寫 ChaosWorkflow（多步驟 + probe）
4. 設計 Probe（HTTP / Cmd / K8s / Prometheus）做 steady state
5. 評估 Litmus vs Chaos Mesh vs Gremlin 的選用

最短路徑：5 分鐘把 Litmus 跑起來

1# 1. 安裝
2# TODO: helm install litmus litmus/litmus -n litmus --create-namespace
3
4# 2. 從 ChaosHub 引用 experiment
5# TODO: kubectl apply -f https://hub.litmuschaos.io/...
6
7# 3. 跑 experiment + 看 ChaosResult
8# TODO: kubectl apply -f chaosengine.yaml
9# TODO: kubectl describe chaosresult <name>

日常操作與決策形狀

CRD 設計

子議題：

• ChaosExperiment：experiment 定義
• ChaosEngine：bind experiment 到 target
• ChaosResult：執行結果

ChaosHub experiment

子議題：

• 現成 experiment marketplace
• Generic / Kafka / Cassandra / GCP / AWS / VMware experiments
• 自訂 experiment 上傳 Hub

ChaosWorkflow

子議題：

• Argo Workflow-based
• 多步驟 chaos 編排
• Schedule trigger

進階主題（按需閱讀）

Probe-based steady state

子議題：

• HTTP probe / Cmd probe / K8s probe / Prometheus probe
• 跟 chaos 同步 / 序列執行
• Success threshold 設計

ChaosCenter（control plane）

子議題：

• 跨 cluster chaos 管理
• ChaosResult dashboard
• RBAC 控制

Harness ChaosNative（商業）

子議題：

• 商業支援版本
• 跟 Harness CD 整合
• Enterprise governance

跟 Chaos Mesh 對照

子議題：

• Litmus：workflow-centric、ChaosHub
• Chaos Mesh：CRD-driven、Dashboard 友善
• 選擇判讀：現成 experiment 庫 → Litmus；fault types 多樣 → Chaos Mesh

Chaos as Code

子議題：

• ChaosWorkflow YAML version control
• GitOps integration
• PR-based chaos review

排錯快速判讀

Experiment fail to start

操作原則：ServiceAccount + RBAC 不對、experiment image pull 失敗。判讀：kubectl describe chaosengine。

Probe 失敗

操作原則：probe 條件設錯 / target 沒準備好。判讀：ChaosResult 看 probe verdict。

Hub experiment 引用版本不對

操作原則：experiment.yaml 跟 Litmus version 不對齊。判讀：Litmus version + experiment compatibility。

Workflow 卡住

操作原則：Argo Workflow 卡 → 看 Argo pod log。

何時改走其他服務

不在本頁內的主題

• ChaosHub 各 experiment 詳細 parameter
• Argo Workflow 內部
• Litmus 商業版本 detail

案例回寫

Case 庫稀薄：本 cases/ 目錄目前沒有以 LitmusChaos 為主軸的案例。

• 待補 LitmusChaos customer case：CNCF graduated 後客戶採用案例、Harness ChaosNative 客戶
• 候選 case：Meta（K8s-native region failover chaos）、Microsoft（Chaos Studio 對照組）— 若未來收錄需先在 cases/ 補正文

下一步路由

• 上游概念：6.20 Experiment Safety Boundary
• 平行 vendor：Chaos Mesh、Gremlin
• 下游能力：8 incident response

• 容量規劃的核心：peak demand × headroom × growth curve
• headroom 訂定：成本 vs 突發承載 tradeoff
• capacity test 跟 6.2 load test 的差異：load 看 throughput、capacity 看 saturation 與 cost curve
• 成本作為驗證輸入：autoscaling 上限、預算告警、queue lag 跟成本的關係
• 跨層容量：DB connection、queue、cache、CDN、第三方 API rate limit
• 跟 6.6 SLO 的耦合：SLO 達成的容量代價
• 反模式：容量規劃只看 CPU、autoscaling 無上限、成本失控用降級掩蓋

概念定位

Capacity 與成本邊界是把容量規劃跟成本約束一起看，責任是讓系統能承載預期負載，同時不把成本曲線推到不可接受區域。

這一頁處理的是規模化之後的 trade-off。容量不是越高越好，真正的目標是找到能維持 SLO、又不浪費資源的區間。

核心判讀

判讀 capacity 時，先看 saturation 點，再看成本曲線是不是隨之失控。

重點訊號包括：

• autoscaling 是否有清楚上限與成本門檻
• 依賴層是否先於應用層成為瓶頸
• peak forecast 是否涵蓋活動、季節性與推廣事件
• 降級是否被當成例外策略，而不是常態容量替代

案例對照

• Shopify：高峰型流量把容量與成本的邊界推得很清楚。
• LinkedIn：互動型服務常先在某個依賴層出現瓶頸。
• Amazon：大規模系統常把成本與可靠性一起做優化。

高峰型容量治理：Game Day + Capacity Planning

高峰型容量治理是把「可預期的非典型流量」當獨立治理面操作的能力。涵蓋 baseline 預估、邊界隔離、game day 驗證跟 resiliency matrix 對齊四個面向。日常擴容靠 autoscaling、高峰需要的是預先驗證跟邊界控制 — 峰值期間擴容延遲跟依賴抖動會疊加放大成事故。

對應 H1 Shopify BFCM 容量治理與 Game Day：揭露四個機制對應上述四個面向 — capacity planning baseline（高峰前可承受上限是多少）、pod/isolation boundary（故障影響如何限制在局部）、game day（高峰前如何驗證假設）、resiliency matrix（服務與失效模式如何對齊）。

可重複套用的做法：

三個治理面性質不同、不是同一個時間軸的三步驟：

• Capacity planning（forecast + headroom 模型）：高峰前 N 週開始、整合 forecast、headroom、依賴 quota — 不只看單一 CPU 數字、要看整條依賴鏈的瓶頸層
• Game day（production-like 假設驗證）：高峰前 N 天執行、把 runbook、matrix、驗證腳本、放行門檻當固定資產輸出、不是「跑完就好」
• Isolation boundary（runtime 故障擴散控制）：高峰當下持續運作、cell 邊界跟 graceful degradation 把故障限制在最小可影響範圍、補強 autoscaling 來不及的延遲段

把每輪活動輸出的缺口回寫成固定資產（不只是「一次性專案」），下一輪準備就能從更高基準開始。

容量跟值班分層的協同

容量跟值班分層的綁定責任是讓「容量門檻」跟「升級路徑」在同一個 trigger 觸發：接近 headroom 限制時值班自動分層、避免事故發生才升級。這個綁定需要三件事配合：runtime 訊號（headroom 預算）、接手機制（三層值班）、模型校準（壓測驗證）。

對應 L1 LinkedIn Capacity Headroom 與 On-call 分層：揭露三個機制對應上述三件事 — headroom 預算（何時進入風險區）、primary/secondary/SME 三層值班（何時由誰接手）、自動化壓測（模型是否貼近現況）。前兩個是 runtime 治理、後者是 model 校準、屬於不同邏輯位階。

容量規劃要回答「擴容門檻是多少」、值班分層要回答「接近門檻時誰接手」。兩者綁定後、高峰期值班分層自動觸發、不需等事故發生才升級。詳見 8.12 IC handoff for long incident。

快取容量的特殊性

快取容量治理的核心責任是失溫時資料層仍可承受。headroom 不是看快取 QPS、是看命中率下滑後的回源放大係數 — 快取本身可能耐 10x 流量、資料層可能撐不到 1.5x。

對應 P1 Pinterest 快取可靠性與容量驚奇治理：揭露三個機制 — cache headroom（命中率下滑能承受多久）、graceful degradation（快取失效時如何降級）、rewarm strategy（熱資料如何有序回填）。

快取容量規劃的核心問題是失溫時資料層能承受的回源放大係數。命中率從 95% 掉到 80% 意味資料層流量 4x、能否承受決定快取退化會不會升級為事故。預先設計 graceful degradation 路徑跟 rewarm 節奏、能避免快取失溫變成連鎖退化。詳見 2.9 cache stampede rollback。

產業情境：電商與零售

電商的容量規劃受峰值倍率與峰值持續時間的雙重約束。為年度一次的峰值預留全年容量成本過高，但峰值容量不足會直接損失營收 — 容量不足在電商是可量化的商業損失（每分鐘宕機對應可估算的 GMV 損失），技術事故與營收衝擊直接掛鉤。

峰值容量策略有三種模式，各自的成本與風險形狀不同。全年預留是最安全但成本最高的做法，適合峰值與日常倍率差距小（< 3x）的服務。彈性擴容依賴 auto-scaling 在峰值到來時及時反應，但擴容延遲（分鐘級）加上依賴層的 warm-up 時間可能讓尖峰初期無法承接。峰值前臨時擴容需要提前 provision 並用 game day 驗證擴容路徑，是中等成本但需要較高工程投入的選項。多數大型電商混用三者：核心路徑全年預留、彈性層 auto-scale、輔助服務臨時擴容。

降級策略在電商有明確的不可降級邊界。推薦引擎、搜尋排序、個人化功能可以在壓力下退回簡化版或靜態結果，但結帳路徑（購物車 → 付款 → 訂單確認）不能降級 — 結帳流程中斷等於訂單流失，使用者不會等系統恢復後重新結帳。降級策略的設計需要把服務按「可降級 / 不可降級」分層，壓力下優先保護不可降級路徑的資源配額。

下一步路由

• 06.2 load testing：capacity 輸入來自 workload model
• 06.9 reliability metrics：容量與成本要有量測口徑
• 06.13 perf regression gate：效能退化通常伴隨成本上升

判讀訊號

• autoscaling max 設無限大、或長期未觸碰
• 容量規劃只看 CPU、忽略 connection pool / queue / 第三方 quota
• peak 流量 forecast 是直線外推、未考慮 promo / seasonal / 行銷事件
• 成本告警觸發後才回頭討論容量
• 降級邏輯被當成常態容量緩衝、而非例外保護

交接路由

• 04 觀測：saturation metric、cost dashboard
• 05 部署：HPA / autoscaling policy
• 06.6 SLO：容量不足導致 SLO 風險
• 04.15 cost attribution：observability 成本作為總體成本一部分

本章目標

讀完本章後、你應該能：

1. 部署 Gremlin agent 到 VM / container / K8s
2. 設計 attack（resource / state / network）+ blast radius
3. 跑 Scenario / GameDay + 報告交付
4. 用 Halt button 緊急中止
5. 評估 Gremlin vs Chaos Mesh / LitmusChaos 的選用

最短路徑：5 分鐘把 Gremlin 跑起來

1# 1. 註冊 + 取得 team API key
2# TODO: gremlin install or container agent
3
4# 2. 第一個 attack
5# TODO: gremlin attack-container --target ... --type cpu
6
7# 3. Dashboard 看 attack timeline
8# TODO: app.gremlin.com

日常操作與決策形狀

Attack types

子議題：

• Resource：CPU / memory / disk / IO
• State：shutdown / process kill / time travel
• Network：blackhole / DNS / latency / packet loss
• Application：custom error inject

Blast radius + magnitude

子議題：

• Target selection（host / container / K8s pod）
• Magnitude（影響度、CPU %、latency ms）
• Duration（短到分鐘 / 長到小時）
• Halt button：emergency stop

Scenario / GameDay 設計

子議題：

• Multi-step attack scenario
• GameDay 跨 team 演練設計
• Report 自動產生

進階主題（按需閱讀）

Cross-platform agent

子議題：

• VM agent（Linux / Windows）
• Container agent（Docker / Kubernetes DaemonSet）
• Cloud agent（AWS / GCP / Azure）
• Agent-less mode（限制較多）

Enterprise audit + RBAC

子議題：

• Team / Project / Role 設計
• Attack approval workflow
• Audit log
• SSO / SAML

跟 OSS chaos 對比

子議題：

• Gremlin：商業 / 跨平台 / GameDay / 報告
• OSS（Chaos Mesh / Litmus）：成本低 / K8s-only / 自管
• 選型判讀：企業合規 + 跨平台 → Gremlin；K8s-only + 預算敏感 → OSS

Halt button

子議題：

• 緊急 stop 所有 active attack
• 對應 6.20 Experiment Safety Boundary
• 跟 incident response 連動

Application-level fault

子議題：

• Gremlin ALFI（Application-Level Fault Injection）
• SDK integration
• Custom exception inject

排錯快速判讀

Agent 連不上 Gremlin

操作原則：API key / network 不通、proxy 配置錯。

Attack 沒生效

操作原則：target selection 沒匹配 / agent 沒安裝。

Halt 不及時

操作原則：halt button 全 active attack 立即停、但已造成影響不會回滾。

Blast radius 過大

操作原則：magnitude / duration 設過大、影響超預期。修法：staging 先測 / 分階段放大。

何時改走其他服務

不在本頁內的主題

• Gremlin pricing
• 各 attack parameter detail
• Agent internal

案例回寫

待補 Gremlin customer case：Stripe / Shopify / Slack 直接公開的 Gremlin GameDay engineering blog（目前以 cases/ 內的可靠性脈絡引用為主）。

下一步路由

• 上游概念：6.20 Experiment Safety Boundary
• 平行 vendor：Chaos Mesh、Toxiproxy
• 下游能力：8 incident response

Contract testing 在服務邊界上驗證 producer 與 consumer 的相容性，把跨團隊協作的隱性期待變成可執行的契約。

這一頁處理的是服務邊界上的信任問題。當服務彼此頻繁演進，契約測試是避免變更互相踩踏的最小保護層。契約對準的是真實 consumer 的期待，而不是抽象的 spec 文件。

核心判讀

好的 contract testing 會明確劃出兼容視窗，並把驗證放進 CI 或 release gate。

判讀時看三件事：

• 契約是否對準真實 consumer，而非假想 client
• schema evolution 是否有明確 compatibility window
• 失敗是否能回到責任邊界，而非只看到測試紅燈

Consumer-driven vs Provider-driven

契約驗證有兩個驅動方向，適用場景不同。

Consumer-driven：consumer 先定義對 producer 回應的期望（欄位、型別、值域），producer 驗證是否能滿足。這種做法讓驗證對準真實消費需求 — consumer 只關心它用到的欄位，producer 可以自由演進不被使用的部分。缺點是 consumer 數量多時，契約管理成本上升：每個 consumer 維護自己的契約檔，producer 需要跑所有 consumer 契約才能確認相容。

Provider-driven：producer 定義 API spec（OpenAPI / gRPC schema），consumer 驗證自己能否適配。producer 主導 schema 演進節奏，consumer 接收變更通知並更新。這種做法適合公開 API 或 consumer 數量大且不可控的服務。缺點是可能漏掉 consumer 依賴的隱性行為 — spec 上合規但語意變了，consumer 仍會失敗。

判斷依據：consumer 少且已知（內部微服務）→ consumer-driven；consumer 多或不可控（公開 API / 平台整合）→ provider-driven。兩者可混用：核心 consumer 用 consumer-driven 保護關鍵路徑，其他 consumer 靠 provider spec 覆蓋。

契約驗證的三個層次

契約驗證按深度分三層，每一層攔截不同類型的破壞。

Schema 結構是最基礎的防線。欄位缺失或型別錯誤會直接導致 runtime 解析失敗。這一層成本低、回饋快，適合放在 CI fast path。

語意相容攔截的是「schema 通過但行為不同」的問題。例如某個欄位從 nullable 改成 required，或 enum 新增一個值但 consumer 的 switch 沒有 default branch。這類問題在結構層驗證不出來，需要 consumer 定義語意期望（Pact interaction 的 matcher / assertion）。

向後相容性是跨版本共存的保障。Avro 和 Protobuf 有內建 compatibility mode（backward / forward / full）；JSON Schema 需要外部工具（如 json-schema-diff）做版本比較。向後相容性驗證的成本最高，但能攔截最嚴重的破壞 — 一旦 event 寫入 broker，舊版 consumer 就必須能解析它。

Schema 演進規則

Schema 演進按協議類型有不同的安全邊界。

API schema（OpenAPI / gRPC）

API schema 的演進判讀：新增可選欄位通常安全；移除欄位、重新命名欄位、或把可選改成必填是 breaking change；型別變更（如 int32 → int64）視 consumer 的容忍度而定。gRPC 的 field number 機制讓欄位新增與移除的相容性比 JSON 更明確 — 未知 field number 被忽略，已知 field number 被刪除會觸發 default value，兩者都有可預測行為。

Event schema（Avro / Protobuf / JSON Schema）

Event schema 的相容性要求比 API 更嚴格。API 的 breaking change 可以靠 versioning（/v2/）隔離，event 一旦寫入 broker 就跟所有版本的 consumer 共存。backward compatibility（新 schema 能讀舊資料）是最低要求；forward compatibility（舊 schema 能讀新資料）讓 consumer 可以延遲升級。

Schema registry（Confluent Schema Registry / AWS Glue Schema Registry）提供集中式的相容性 gate：producer 註冊新版 schema 前，registry 自動比對相容性規則，拒絕 breaking change。這個 gate 比 CI 更早攔截，因為它在 schema 發布時就生效。

DB schema 演進的契約驗證銜接到 6.11 migration safety — expand/contract pattern 讓新舊版本共存，本質上跟 event schema 的 backward compatibility 是同一個問題。

CI 整合

Contract test 在 CI 的位置跟 unit test 不同 — 需要跨服務的契約同步。

Fast path：producer 的 schema 變更觸發 consumer 的 contract test。實作上需要 CI 能跨 repo 觸發（webhook / pipeline trigger），或用 contract broker（如 Pact Broker）做非同步驗證。fast path 只跑受影響 consumer 的契約，保持回饋速度。

Slow path：完整 contract matrix 驗證 — 所有 consumer × producer 組合。這個矩陣在 merge gate 或 scheduled path 跑，覆蓋 fast path 漏掉的間接影響。矩陣規模隨服務數增長，需要 selective matrix（只跑有變更的 producer 相關 consumer）控制成本。

失敗處理：contract test 失敗時的責任分派是關鍵流程。失敗可能來自 producer 的 breaking change，也可能來自 consumer 的 expectation 過期。Pact 的 can-i-deploy 機制提供自動化判斷：比對 producer 當前版本與 consumer 上次驗證通過的版本，定位責任方。

案例對照

• Stripe：外部整合的 API 需要嚴格的 backward compatibility — 交易 API 的 breaking change 會直接影響商戶收入，schema 演進靠 expand/contract 逐步過渡。
• Shopify：跨服務 deploy 順序錯誤是高峰期常見事故源 — contract test 攔截 schema 不相容，讓 deploy 順序有驗證依據。
• GitHub：API 與 webhook 的契約覆蓋面廣，契約失配會直接影響整合生態。

判讀訊號

交接路由

• 6.1 CI pipeline：contract test 作為 fast path 的跨服務驗證
• 6.8 release gate：contract 通過作為放行條件
• 6.11 migration safety：DB schema 演進的契約驗證
• 6.14 dependency budget：依賴契約穩定性
• 6.15 environment parity：契約覆蓋的環境邊界
• 6.16 test data：fixture shape 契約
• 6.17 feature flag：flag 不同分支的契約覆蓋
• 05 部署：跨服務 deploy 順序協調

本章目標

讀完本章後、你應該能：

1. 跑起 Toxiproxy server + 設 listener / upstream proxy
2. 用 client SDK 注入 latency / partition / bandwidth toxic
3. 整合 Toxiproxy 到 integration test（before/after test hook）
4. 用 Docker Compose 整合
5. 評估 Toxiproxy vs Chaos Mesh NetworkChaos 的選用

最短路徑：5 分鐘把 Toxiproxy 跑起來

1# 1. 啟動 server
2# TODO: docker run -d -p 8474:8474 -p 26379:26379 ghcr.io/shopify/toxiproxy
3
4# 2. 建 proxy（Redis 為例）
5# TODO: curl -X POST localhost:8474/proxies -d '{"name":"redis","listen":"0.0.0.0:26379","upstream":"redis:6379"}'
6
7# 3. 注入 toxic
8# TODO: curl -X POST localhost:8474/proxies/redis/toxics -d '{"type":"latency","attributes":{"latency":1000}}'

日常操作與決策形狀

Toxic types

子議題：

• latency：增加延遲
• bandwidth：限制頻寬
• slow_close：connection close 慢
• timeout：connection timeout
• slicer：把 TCP packet 切片
• limit_data：limit 傳輸量

API + Client SDK

子議題：

• HTTP API（8474 default）
• Client SDK：Go / Ruby / Python / JS
• Programmatic toxic enable/disable

Integration test pattern

子議題：

• before each test 設 toxic
• after each test cleanup
• Test isolation：每 test reset proxy state

進階主題（按需閱讀）

Docker Compose 整合

子議題：

• service depends_on toxiproxy
• 應用透過 toxiproxy connect 真正 DB / cache
• environment variable 切換 toxiproxy vs direct

Reproducible chaos

子議題：

• Toxic seed（reproducible random）
• Toxic stream（upstream / downstream）
• 對應 test reproducibility

跟 Chaos Mesh NetworkChaos 對比

子議題：

• Toxiproxy：CI / integration test、TCP 層
• Chaos Mesh：production、K8s pod 層
• 選擇判讀：testing CI → Toxiproxy；K8s staging chaos → Chaos Mesh

跟 client retry / circuit breaker 配合

子議題：

• 驗證 client 對 dependency failure 的應對
• Retry budget / backoff 測試
• Circuit breaker trigger 測試
• 對應 knowledge cards retry-budget

排錯快速判讀

Proxy 連不上

操作原則：先 curl :8474/proxies 看 proxy state、再看 network。

Toxic 沒生效

操作原則：toxic enabled 但 attribute 設錯。判讀：API GET toxics 看當前狀態。

Test state pollute

操作原則：test 間沒 reset proxy、state 殘留。修法：每 test 開頭 reset。

Performance overhead

操作原則：Toxiproxy 本身有 latency overhead（μs 級）、不適合 production sensitivity。

何時改走其他服務

不在本頁內的主題

• Toxic 內部實作
• 各語言 SDK 完整 API
• TCP protocol 細節

案例回寫

Shopify 自家：Toxiproxy 是 Shopify 開源、Shopify reliability cases 多有引用。

Case 庫稀薄：Toxiproxy 主要 case 集中在 Shopify 自家、其他 adopter 案例待補。

• 待補 Toxiproxy adopter case：其他公司用 Toxiproxy 做 dependency failure 測試
• 候選 case：Pinterest（cache failure mode integration test）、Spotify（squad 自管 integration chaos）— 若未來收錄需先在 cases/ 補正文

下一步路由

• 上游概念：6.20 Experiment Safety Boundary
• 平行 vendor：Chaos Mesh、Gremlin
• 下游能力：knowledge cards retry-budget

問題場景

高變更頻率服務最常見的失效是小幅回歸連續累積，單點故障反而少見。每次回歸都不夠大，不會立刻觸發全停；但連續幾週後，使用者體感持續惡化，團隊才發現可靠性債已經超標。

這種情境需要的是「連續消耗判讀」，不是單次事故判讀。error budget policy 就是把連續消耗變成可操作的放行規則。

決策機制

政策設計先做三個對齊，再做門檻定義。

有了這三個對齊後，release gate 可以從「主觀風險判斷」轉成「政策驅動」：

1. budget 健康：正常發版。
2. budget 快速消耗：啟用變更限速、提高驗證門檻。
3. budget 透支：凍結非必要變更，先修復與回補訊號。

可觀測訊號

政策有效與否要靠訊號判讀，不靠會議共識。

常見陷阱

把 error budget 當 KPI 會讓政策失真。這個機制的責任是「保護可靠性與交付節奏的平衡」，不是讓團隊追求某個固定分數。當 KPI 化開始主導行為，常見結果是 SLI 縮小、告警延後或例外條件過度擴張，最終反而降低判讀可信度。

下一步路由

要把這個案例落到制度層，先回到 6.6 定義政策欄位，再到 6.8 實作 gate。若你發現訊號不足，先補 4.16 與 4.20。

• migration 的核心約束：schema 變更必須跟程式碼版本相容
• expand / contract 模式：先擴展（雙寫 / 雙讀）、再收斂（移除舊欄位）
• 雙寫驗證：shadow read、checksum 比對、流量採樣
• 線上 DDL 工具：pt-online-schema-change / gh-ost / Vitess online schema change
• 大表 migration 策略：批次、節流、避開 peak
• rollback 路徑設計：每階段必須可逆
• 跟 6.10 contract testing 的整合：schema 契約驗證
• 跟 6.8 release gate 的整合：migration 可逆性作為 gate 條件
• 反模式：schema change 跟 code deploy 同 PR、rollback 變不可能；大表 ALTER 直接打、production 鎖表；新欄位 NOT NULL 無 default

概念定位

Schema migration 是把 schema migration 從一次性事件變成可逆、可漸進的 rollout 流程，責任是避免資料結構變更直接把 production 推向不可回復狀態。

這一頁關心的是結構變更的節奏。當 code 與 schema 必須一起演進，安全做法是保留回退與相容窗口，一次到位的思路會壓縮容錯空間。

核心判讀

判讀 migration 時，先看每一步是否可逆，再看它是否能在 peak 外執行。

重點訊號包括：

• expand / contract 是否真的分開
• rollback 路徑是否先於 production 變更設計
• 大表操作是否有節流與 dry-run
• 雙寫 / shadow read 是否有一致性驗證

案例對照

• Pinterest：資料結構與產品演進常同步變化。
• GitHub：大規模平台 migration 容易把結構風險放大。
• Stripe：金流系統對 migration rollback 與一致性要求特別高。

交易類 migration 的特殊性

交易類 migration 同時承擔可用性跟正確性兩條軸。一般 schema migration 失敗的代價是停機、交易類失敗的代價額外包含結果不一致（重複扣款、訂單漏建、reconciliation 缺口）。守住兩條軸需要 idempotency + 漸進遷移 + 可回退發布 + 交易路徑可追溯四件事配合。

對應 S1 Stripe Idempotency 與零停機遷移：揭露四個機制對應上述四件事 — idempotency key（同一交易重送如何得到同一結果）、expand/contract migration（資料變更如何與新舊版本共存）、canary + rollback gate（發版異常如何快速收斂）、transaction-path observability（交易路徑是否可追溯）。

交易類 migration 的關鍵 observables：

• duplicate request collapse ratio：重試是否被正確合併
• migration phase error drift：遷移各階段錯誤是否收斂
• canary transaction anomaly：小流量交易是否出現偏差
• payment trace consistency：trace 是否完整覆蓋交易關鍵欄位

把這四個機制視為「交易類 migration 的安全 baseline」、跟 6.12 idempotency-replay 共用 idempotency key 設計、跟 6.8 release gate 交易類變更段 共用 canary 條件。

交易類 migration 的反模式是把 migration 當「資料庫任務」獨立執行、跟 release gate 分離。正確做法是把 migration 跟 release 綁定治理、用同一套 evidence 跟 rollback 條件判讀。

下一步路由

• 01.6 資料庫轉換實作：雙寫、回填、切流與回滾
• 01.7 Schema Migration Rollout 證據：把 migration plan 落成 validation query、evidence package、release gate 與 decision log
• 06.8 release gate：把可逆性放進放行條件
• 06.10 contract testing：先驗 schema 相容性
• 08.5 post-incident review：migration 類事故通常需要結構化復盤

判讀訊號

• migration 失敗只能 forward-fix、無 rollback 路徑
• 大表 ALTER 在 peak 時段執行造成鎖表
• 程式碼跟 schema 必須同步部署、deploy 失敗風險高
• 雙寫期間無一致性驗證、cutover 後才發現資料漂移
• migration 工具無 dry-run、production 才知道執行時間

交接路由

• 01.6 資料庫轉換實作：執行層流程
• 01.7 Schema Migration Rollout 證據：production rollout evidence 與 gate 欄位
• 0.C4 營運後技術轉換：決策層判讀
• 06.7 DR / rollback：migration rollback 演練
• 06.8 release gate：可逆性檢查
• 06.10 contract testing：schema 契約驗證
• 08.5 post-incident review：migration 引發的事故型態

規劃重點

• Capacity Planning：跨 region / 跨服務的容量預測方法
• On-call 結構：primary / secondary / SME escalation
• Operability culture：把可運維性納入服務設計門檻
• Internal tooling：LinkedIn engineering blog 公開的內部工具設計

預計收錄實踐

案例定位

LinkedIn 這個案例在講的是中大型平台如何把容量規劃、自動化壓測與 metrics 收集做成可運營的系統。讀者先抓 capacity planning、on-call tiers 與 self-service metrics 的關係，再看它們怎麼把 operability 變成團隊責任。

判讀重點

當 replication latency 上升時，先看 headroom 是否足夠，再看壓測與自動化是否真的覆蓋了常見瓶頸。當 on-call 需要多層升級時，重點是每一層是否知道何時接手、何時回退，階層形式本身是次要的。

可操作判準

• 能否把容量預測連到實際 growth rate
• 能否讓 load testing 自動化到可重用
• 能否把 metrics collection 做成 self-service
• 能否清楚劃分 primary、secondary 與 SME escalation

與其他案例的關係

LinkedIn 的焦點是把 operability 變成日常流程，這和 Shopify 的峰值準備、Microsoft 的治理模式、Spotify 的平台化做法都很接近。差別在於 LinkedIn 更強調內部工具與 metrics pipeline，適合拿來當「中型平台如何長大」的範本。

代表樣本

• automated load testing 把壓測變成日常流程，而不是臨時活動。
• self-service metrics 讓團隊不用等平台工程師才能看見關鍵訊號。
• on-call tiers 讓升級與接手邏輯有固定路徑。
• capacity planning 讓 replication latency 與 headroom 直接相連。
• site reliability engineering 讓中型平台開始形成自己的可靠性職能。
• internal tooling 讓 operability 變成平台化能力而不是個人技巧。
• project waterbear 類演練讓內部故障情境能被規律化測試。
• primary / secondary / SME escalation 讓責任與知識分工更清楚。

章節列表

引用源

• Welcome to the LinkedIn Engineering Blog：LinkedIn Engineering Blog 的入口。
• Taming Database Replication Latency by Capacity Planning：容量規劃與 replication latency 的經典案例。
• Eliminating toil with fully automated load testing：自動化壓測與 operability 的實踐。
• Scaling the collection of self-service metrics：metrics pipeline 與可運維性基礎。

本章目標

讀完本章後、你應該能：

1. 在 Nobl9 定義 SLO（SLI / target / time window）
2. 配置 error budget + burn rate alert（multi-window）
3. 設計 composite SLO（跨服務組合）
4. 用 OpenSLO YAML 管 SLO as code
5. 評估 Nobl9 vs Sloth / Pyrra / vendor 內建 SLO

最短路徑：5 分鐘把 Nobl9 跑起來

1# 1. 註冊 Nobl9 + connect data source
2# TODO: app.nobl9.com、connect Datadog / Prometheus
3
4# 2. 寫 SLO YAML（OpenSLO）
5# TODO: SLO spec with service / indicator / objective
6
7# 3. sloctl apply
8# TODO: sloctl apply -f slo.yaml

日常操作與決策形狀

SLO 定義

子議題：

• SLI（Service Level Indicator）：metric to measure
• Objective：target percentage
• Time window：rolling / calendar
• 對應 knowledge cards burn-rate

Error budget

子議題：

• Budget = (1 - SLO target) × time window
• Consumed budget / remaining budget
• 跟 release gate 對應（budget 用完 → freeze deploy）

Burn rate alert

子議題：

• Multi-window multi-burn-rate alert
• Fast burn alert（短期 high rate）+ slow burn alert（長期 low rate）
• 對應 Google SRE burn rate alerting

進階主題（按需閱讀）

Composite SLO

子議題：

• 跨多 service 組合成單一 SLO
• 適合：user journey SLO（不只單一 service）

OpenSLO 標準

子議題：

• Vendor-neutral SLO spec
• YAML 配置
• 跟 Nobl9 主導
• 對應 vendor lock-in 取捨

Data source 整合

子議題：

• Datadog / Prometheus / New Relic / CloudWatch / Splunk / AppDynamics / Honeycomb / Lightstep
• 多 source SLO 統一 view
• 對應 04 observability 模組

Alert routing

子議題：

• 跟 PagerDuty / Opsgenie / Slack 整合
• 跟 08 incident response 對應

Service catalog + governance

子議題：

• Project / Service / SLO 階層
• Role-based access
• Audit log

SLO as code

子議題：

• sloctl CLI
• YAML version control
• CI integration

排錯快速判讀

SLO calculation 不準

操作原則：SLI query 不對 / data source 延遲。判讀：raw metric vs SLO calculation 比對。

Alert noise

操作原則：burn rate window 設過短 / threshold 過嚴。

Data source disconnect

操作原則：API key / network / quota。

Composite SLO 行為不符預期

操作原則：composite 算法（AND / OR / custom）不對。

何時改走其他服務

不在本頁內的主題

• OpenSLO 完整 spec
• Nobl9 pricing
• sloctl 完整 CLI reference

案例回寫

待補 Nobl9 customer case：企業 SLO 治理採用案例、OpenSLO adopter。

下一步路由

• 上游概念：knowledge cards burn-rate
• 平行 vendor：Sloth
• 下游能力：04 observability、08 incident response

本文是跨 vendor migration playbook、cross-link Jenkins 跟 GitHub Actions。跑 migration-playbook-methodology 6 維 audit 後對映 Schema = High（Groovy DSL ↔ YAML workflow）→ Type A phased translation。

Pipeline 5 段 lifecycle 的對位 + 翻譯

本文按 pipeline lifecycle 5 段 組織內容（variant E）— 不是「為什麼遷」driver 開頭，是 Jenkins vs GHA 對 5 段各自的處理：

跑 6 維 diff dimension audit：

Schema = High（其他 Medium-Low）→ Type A phased translation 為主、加 paradigm + operational 獨立段。

為什麼遷：cost / vendor / cloud-native 三條 driver

• Cost：Jenkins self-hosted 是「免費 software + 高 ops cost」、GHA 按 minute 計費對中小團隊更便宜
• Vendor consolidation：repository 已在 GitHub、整合進 GHA 省一個外部系統
• Cloud-native：GHA matrix build + reusable workflow 對 cloud-native deploy（K8s / serverless）有 first-class action

Phase 0：Audit + classify

 1# Jenkins workspace 盤點
 2find . -name "Jenkinsfile" -o -name "*.groovy"
 3# 列所有 pipeline file
 4
 5# 統計 plugin 使用
 6# Jenkinsfile 內 import / @Library / sh "tool plugin..."
 7grep -rE "@Library|import|tools\s*\{" Jenkinsfile*
 8
 9# 每 pipeline 評估 complexity
10# - Simple linear pipeline: 1-3 stage、無 shared library
11# - Medium: parallel stage + 2-5 shared library
12# - Complex: 條件分支 + 動態 stage + 10+ plugin / 5+ shared library

Audit output：

• 列「100 個 pipeline、35 simple / 50 medium / 15 complex」
• 每 complexity level 估翻譯時間（simple 0.5 day / medium 2 day / complex 5-10 day）
• Plugin 依賴清單對應 GHA action 替代品

Phase 1：Schema 對位（Groovy DSL ↔ YAML）

 1// Jenkins Declarative Pipeline
 2pipeline {
 3  agent { label 'docker-build' }
 4  stages {
 5    stage('Test') {
 6      parallel {
 7        stage('Unit') { steps { sh 'mvn test' } }
 8        stage('Integration') { steps { sh 'mvn verify' } }
 9      }
10    }
11  }
12  post {
13    failure { mail to: 'devops@', subject: 'Build failed' }
14  }
15}

 1# GHA Workflow 對等
 2name: CI
 3on: [push]
 4jobs:
 5  test:
 6    runs-on: [self-hosted, docker-build]
 7    strategy:
 8      matrix:
 9        suite: [unit, integration]
10    steps:
11      - uses: actions/checkout@v4
12      - name: Run ${{ matrix.suite }}
13        run: |
14          case "${{ matrix.suite }}" in
15            unit) mvn test ;;
16            integration) mvn verify ;;
17          esac
18  notify-failure:
19    needs: test
20    if: failure()
21    runs-on: ubuntu-latest
22    steps:
23      - uses: dawidd6/action-send-mail@v3
24        with:
25          to: devops@
26          subject: Build failed

對位差異：

• parallel { ... } → strategy.matrix（粒度不同、matrix 是「同 step 不同參數」、parallel 是「不同 step」）
• post.failure → 獨立 job + if: failure()
• @Library shared library → reusable workflow（uses: ./.github/workflows/reusable.yml）
• Jenkins tools { jdk 'java17' } → setup-java action（手動配 toolchain）

Phase 2：Translation pipeline（3-tier hybrid）

對應 Splunk → Elastic translation 同 3-tier：

• Tier 1：community tool（jenkins-to-actions converter、cover 簡單 pipeline 30-50%）
• Tier 2：LLM-assisted（Claude / GPT 翻 medium complexity、人工 verify）
• Tier 3：manual（shared library 改 reusable workflow / conditional 動態 stage 重寫）

Phase 3：Parallel run（雙 CI 跑 4-8 週）

1Repository ──┬─→ Jenkins webhook ──→ Jenkinsfile pipeline
2             └─→ GitHub Action ────→ .github/workflows/ci.yml
3
4Compare:
5- 同 commit 兩端結果一致
6- Latency / cost / artifact location 對齊

Diff dashboard 列「test pass rate / build time / failure mode」三 metric、跑到 95%+ 一致才進 cutover。

Phase 4：Cutover + cleanup

• Disable Jenkins webhook
• GHA 成 primary CI
• Jenkins 留 standby 2 週 fallback
• Decommission Jenkins controller + agents

Production 故障演練

Case 1：Shared library equivalence、reusable workflow 表達不足

徵兆：複雜 Jenkins shared library（含 Groovy class / closure / 動態變數）翻成 reusable workflow 後失準、某些動態邏輯無法表達。

根因：Jenkins Groovy 是 imperative + 完整 programming language；GHA reusable workflow 是 declarative YAML、limited expressiveness。

修法：

1. 複雜邏輯外包到 script：reusable workflow 只當 orchestrator、複雜邏輯放 .github/scripts/*.sh 或 actions/javascript-action
2. 自定 composite action：multi-step logic 包進 composite action、reuse 程度比 reusable workflow 高
3. 退役過度設計的 shared library：trans 過程暴露 90% library code 其實只用 10%

Case 2：Ephemeral workspace、build cache 失敗

徵兆：cutover 後 build time 從 5 分鐘漲到 20 分鐘；Maven / Gradle / node_modules / Docker layer 每次都重抓。

根因：Jenkins agent workspace persistent、build cache 跨 build 保留；GHA ephemeral runner 每次新 VM、cache 預設沒帶。

修法：

1. actions/cache@v4：cache key 用 hashFiles('**/pom.xml') 等 lock file、cross-build 復用
2. Self-hosted runner with cache：critical pipeline 跑 self-hosted runner、persistent volume
3. Docker layer cache：用 docker/build-push-action 配 BuildKit cache、不 rebuild full image

Case 3：Plugin 不對等、CI feature 退化

徵兆：Jenkins 用 50+ plugin、GHA action marketplace 找不到對應；team 對 SonarQube quality gate / Jira integration / custom report 等失去 first-class 支援。

根因：Jenkins plugin ecosystem 20+ 年累積、GHA marketplace 5 年；某些 niche plugin 在 GHA 沒對等 action。

修法：

1. API-based integration：用 curl 對 vendor API 直接 call、不依賴 plugin / action
2. 自寫 action：critical feature 自寫 composite / JavaScript action、publish 到 marketplace
3. 退役舊 plugin：trans 期間 audit plugin 真實使用、80% 可退役

Case 4：Self-hosted runner setup + scaling

徵兆：production workload 需要 GPU / large memory runner；GHA hosted runner spec 不夠、想用 self-hosted runner、發現 scaling / security / monitoring 比 Jenkins agent 複雜。

根因：GHA self-hosted runner 是 ephemeral、scaling 需要 runner controller（actions-runner-controller on K8s）；跟 Jenkins agent / Kubernetes plugin 對應但 setup 不同。

修法：

1. actions-runner-controller (ARC)：K8s-native runner scaling、跟 Jenkins K8s plugin 對應
2. Runner labels：用 label 路由 job（runs-on: [self-hosted, gpu, linux]）
3. Security：ephemeral runner 用 short-lived token、不跨 job persist secret

Case 5：Matrix build vs parallel stage 表達差

徵兆：Jenkins 有 動態 parallel（runtime 決定要跑哪些 stage、按 input 變動）；GHA matrix 是 static at workflow load time、表達不到。

根因：GHA matrix 是 declarative、workflow parse 時 expand；runtime 動態決定 stage 需要用 if: condition + 多 job。

修法：

1. 動態 matrix：用 jobs.set-matrix 先跑一個 job 算 matrix、輸出 JSON、後續 job strategy.matrix: ${{ needs.set-matrix.outputs.matrix }}
2. conditional job：每個 dynamic stage 寫獨立 job + if: 控制觸發
3. 重設計：90% 動態邏輯其實可改 static matrix + condition、純 runtime 動態通常是 over-engineering

Capacity / cost

判讀：100+ pipeline organization 切 GHA 通常 6-12 月 ROI 持平、之後省 ops cost；< 30 pipeline 早就該切。

整合 / 下一步

跟 GitLab CI 對位

GitLab CI YAML 語法跟 GHA 接近、shared library 對應 include:、self-hosted runner 對等；Jenkins → GitLab CI migration 流程跟本文鏡像對稱、3-tier translation pipeline 通用。

跟 Circle CI 對位

CircleCI orb 對等 GHA composite action；跨 SaaS CI 切換比 Jenkins → GHA 簡單（都 YAML-based）。

反向 migration（GHA → Jenkins）

少數 enterprise（金融 / 政府）合規要求 self-hosted CI / on-prem；GHA → Jenkins 鏡像對稱、注意 Jenkins shared library 表達力更強、reusable workflow 內 dynamic 邏輯可不必拆。

下一步議題

• Reusable workflow + composite action 混用：reusable workflow 適合 跨 repo orchestration、composite action 適合 單 repo logic encapsulation
• OIDC + cloud deploy：用 OIDC token 取代 long-lived cloud credential、是 GHA migration 順便升級的機會
• Cost optimization：minute-based billing 對 high-volume CI 需要 monitoring + budget alert

相關連結

• Target vendor：GitHub Actions
• 平行 vendor：CircleCI
• 平行 migration playbook（Type A）：Splunk → Elastic Security / MySQL → PostgreSQL
• Methodology：Migration playbook methodology

問題場景

很多團隊 postmortem 寫得完整，但事故仍反覆發生。根因通常是 action item 沒有被制度化追蹤，分析能力本身不是瓶頸。當改進工作和日常 feature 競爭同一批資源時，沒有 closure 機制的 action item 很容易被延後到失效。

治理機制

可靠的 closure 機制要先把 action item 分級，再對應不同完成標準。

分級之後要做三件事：

1. 為每個 action item 指派單一 owner。
2. 寫出可驗證完成條件（不是「優化」「強化」這類抽象字）。
3. 把 closure 狀態納入固定 review cadence。

可觀測訊號

常見陷阱

最常見陷阱是把 action item 當作「會後待辦」而不是 release policy 的一部分。這會讓高風險改進沒有實際約束力。正確做法是把 P0/P1 項目直接綁到 release gate，未完成時不得放行關聯變更。

下一步路由

先在 8.19 Incident Decision Log 保留 action item 的決策脈絡，再到 8.22 Incident Evidence Write-back 回寫觀測與驗證項目。若要把 closure 變成制度，回到 6.21 Reliability Debt Backlog 進行排序治理。

引用源

• Google SRE Book
• Google SRE Workbook

這三類服務常被一起採購或一起導入，但它們回答不同問題。觀測平台回答「現在發生什麼」，可靠性工具回答「失敗前能否先驗證」，事故平台回答「事情發生後誰做什麼」。選型時先分清能力層，再比較 vendor、SaaS、OSS 或自建方案，能降低工具堆疊與流程空轉的風險。

選型錨點

選型錨點是先問服務要降低哪一種操作不確定性。當團隊只知道系統「好像怪怪的」，優先補訊號；當團隊知道風險但缺少安全驗證路徑，優先補可靠性驗證；當團隊知道事故已發生但協作混亂，優先補事故流程。

訊號層的責任是讓系統行為可被查詢與判讀。這一層的選型重點是資料模型、查詢能力、關聯能力、保留成本與告警品質；產品名稱排在後面，因為 log、metric、trace 與 error event 是否能互相串接，才是事故時真正影響判讀速度的條件。

驗證層的責任是讓風險在事故前被安全暴露。這一層的選型重點是測試是否接近真實 workload、故障注入是否有停止條件、SLO 是否能被量測、release gate 是否能阻止高風險變更；工具越強，越需要 blast radius 與權限邊界。

響應層的責任是讓事故進入可交接流程。這一層的選型重點是 paging、升級、角色分工、狀態更新、decision log、stakeholder mapping 與 post-incident action tracking；工具的價值來自流程一致性，通知訊息數量只是輔助訊號。

閉環層的責任是把事故與演練教訓回寫到系統設計。這一層可能由 incident platform、ticket system、runbook repository 或內部 workflow 承擔；判準是 action item 是否能被排序、驗證、關閉，並回到訊號治理、可靠性演練或事故流程。

判讀順序

操作服務選型的穩定順序是「症狀 → 缺口 → 能力 → 工具」。症狀描述使用者痛點或工程痛點，缺口描述目前缺少的判讀或流程，能力描述需要補的系統責任，工具才是最後的落地選項。

客訴比告警早代表系統的外部痛點先於內部訊號出現。這種情境應先補服務健康指標、使用者可感知訊號與 alert runbook，再討論要用哪個監控平台；否則平台上線後仍可能只收集到工程師方便看的資料。

trace 接不上 queue 代表跨邊界關聯失效。這種情境應先檢查 trace context、correlation id、message metadata 與 sampling 策略，再選擇 OpenTelemetry backend、APM SaaS 或 log search 方案。

發版後才發現容量曲線崩壞代表驗證層缺少 gate。這種情境應先建立 workload model、baseline、回歸門檻與 release gate，再選 load test 工具或 performance dashboard。

chaos 實驗影響超出預期代表驗證工具先於安全邊界。這種情境應先定義 steady state、blast radius、停止條件與授權範圍，再決定使用 chaos mesh、fault proxy 或商業 chaos 平台。

多人同時修事故但決策互相覆蓋代表響應層缺少 command model。這種情境應先定義 incident commander、scribe、owner、decision log 與 handoff，再導入 IR 平台或 chat workflow。

對外狀態更新慢於內部復原代表 stakeholder 節奏不足。這種情境應先定義影響評估、更新頻率、外部狀態頁與客戶溝通責任，再選 status page 或 customer comms 工具。

服務組合策略

服務組合策略的核心原則是先選最小閉環，再擴展平台覆蓋。完整閉環至少包含一個可判讀訊號、一個可驗證門檻、一個可接手流程與一個可回寫的 action tracking；缺任一層時，工具組合就會變成單點能力。

雲端原生整合適合雲端邊界清楚的團隊。它能快速取得 infrastructure 訊號、IAM 整合與預設 dashboard，但跨外部 SaaS、跨語言 trace 或高基數探索時，需要提前確認資料出口與查詢能力。

OSS 可組裝平台適合有平台團隊維護 ingestion、storage、query 與 dashboard 的組織。它能降低 vendor lock-in 並保留彈性，但容量規劃、升級、安全修補、保留策略與 on-call 都會變成內部成本。

All-in-one SaaS 適合需要快速建立可觀測、告警與事故協作的團隊。它能把 log、metric、trace、APM、paging 或 workflow 整合在單一產品，但成本模型、資料保留、客製化限制與資料治理要在導入前確認。

混合式最小閉環適合已經有多套工具的團隊。它的重點是定義哪個系統是 alert source、哪個系統是 incident source of truth、哪個系統負責 action item closure；整合邊界比新增工具更重要。

導入順序

導入順序的責任是降低一次導入多套工具的失敗風險。觀測、驗證與事故服務應依照事故風險與團隊成熟度逐層補齊，功能清單只適合放在能力判準之後。

1. 先補最小訊號：定義 SLI、error rate、latency、dependency failure、queue lag 與 customer-facing symptom。
2. 再補最小告警與 runbook：讓 alert 指向可執行動作，避免只把噪音送到 on-call。
3. 接著補驗證門檻：把 load、contract、migration、chaos 或 SLO 變成 release 前後的 gate。
4. 然後補事故協作：定義 paging、severity、角色、decision log、status update 與 post-incident review。
5. 最後補閉環治理：把偵測缺口、演練缺口與 action item 回寫到觀測、驗證與事故流程。

這個順序讓工具投資跟風險暴露同步。若團隊在沒有基本訊號時先導入 incident workflow，事故流程會缺少證據；若在沒有實驗安全邊界時先導入 chaos 工具，驗證本身會變成風險來源；若在沒有 action tracking 時只做 postmortem，復盤會停在文字紀錄。

交接路由

交接路由的責任是把服務選型判斷送到正確模組。選型章只決定「需要哪一類能力」，後續模組負責欄位、流程、工具與實作細節。

• 需要判斷訊號是否足以支援診斷時，進入 可觀測性平台。
• 需要判斷失敗是否能被安全驗證時，進入 可靠性驗證流程。
• 需要判斷事故是否能被接住與回寫時，進入 事故處理與復盤。
• 需要比較具體 vendor 時，先讀各模組的 vendors index，再回到本章確認工具是否補到正確能力層。

完成判準

本章完成的判準是能把工具需求翻成能力需求。當團隊能說清楚「我們缺的是訊號、驗證、響應還是閉環」，選型討論才適合進入 vendor 比較。

檢查時可以問四個問題：

1. 現在的痛點是看不見、驗不過、接不住，還是回寫斷掉？
2. 這個工具補的是哪一層能力，會產生哪些新操作成本？
3. 導入後誰負責維護資料品質、流程品質與 action closure？
4. 如果三個月後事故型態改變，哪個 tripwire 會提醒團隊重新評估？

• 為何 idempotency 是分散式系統一級屬性：retry / failover / replay 的前提
• idempotency key 的設計：來源、生命週期、儲存
• exactly-once 是幻象、at-least-once + idempotent 才實際
• replay 驗證：從 log / event store 重播能否得到相同最終狀態
• 跟 03 message-queue 的關係：consumer idempotency 是延伸專題
• payment / order / messaging 的 idempotency 模式差異
• 跟 6.4 chaos 的整合：注入重複訊息驗證冪等
• 反模式：idempotency 只靠 DB unique constraint、無 key 設計；retry 後副作用重複；replay 路徑從未驗證