單一 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 驅動可靠性操作）

Monolith 與 Microservice 的責任差異

Monolith 用「同一個程式碼庫、同一個部署單位、同一個資料庫」換取低協作成本與簡單事務語意。Microservice 用「獨立程式碼庫、獨立部署、獨立資料邊界」換取團隊獨立性、技術選型彈性與局部故障隔離。

讀者要從這張表反推自己的真實壓力來源。如果痛點是「部署互相卡住、發布頻率被別人拖慢」，拆分能解決；如果痛點是「程式碼太亂、新人看不懂」，拆服務只會把亂的範圍擴大成跨服務契約混亂。

這張表是兩端對比、實際系統常落在中間。常見折衷形態：

• Modular monolith（單一部署 + 模組化邊界）：保留 monolith 的部署簡單、用模組邊界防止程式碼互相穿透。Shopify、Basecamp、Stack Overflow 是大規模長期維持的代表 — monolith 不是進化中段、是 valid endgame。
• Macro-services（少量大服務、5-15 個）：避免 microservice 的極端碎片化、保留拆分帶來的部署獨立性。是多數中型團隊的實際終點、不是過渡形態。
• Cell-based architecture（多 cell 各自獨立、跨 cell 共用標準介面）：AWS、Slack、DoorDash 用來控制 blast radius — 把整個系統複製成多個 isolated cell、每個 cell 內可以是 monolith 或 microservice。

拆分不是進化方向、是壓力應對工具。維持 monolith 在某些情境（極小團隊、PMF 前期、無 DevOps 能力）是更負責任的選擇。

拆分軸的判讀

服務邊界不只一條軸。常見的四條軸對應不同的壓力來源，正確的拆法是「壓力在哪裡、就沿那條軸拆」，不是同時動四條軸。

資料邊界

當兩塊業務的資料生命週期不同、一致性需求不同、查詢模式不同時，資料邊界已經形成。例如訂單資料需要強一致性與長期保留，瀏覽紀錄可以最終一致性、定期清理。把這兩類資料放同一個 schema 會讓 backup、migration、index 策略互相干擾。

判讀訊號：同一張表上不同欄位的 read/write QPS 差三個數量級、同一個 transaction 同時寫入多種業務概念、schema migration 一動就要鎖住整個業務的寫入。

團隊邊界

當兩塊業務由不同團隊維護、發布節奏不同、技術棧偏好不同時，團隊邊界已經形成。Conway’s Law 反過來操作：用服務邊界保護團隊邊界，避免一隊改動觸發另一隊重 review。

判讀訊號：PR review 跨團隊比例過半、發版需要協調多個團隊、技術升級（語言版本、framework 升級）因為其他團隊未準備好而被擋住。

部署邊界

當部分功能需要獨立的部署節奏、獨立的擴展策略、獨立的可用性等級時，部署邊界已經形成。背景批次工作要按小時排程、API 服務要 7×24 線上、報表服務只在工作日運行，三者放同一個部署單位會讓最嚴格的可用性要求拖累其他。

判讀訊號：高峰時某個功能擴展速度跟不上、低峰時某個功能浪費資源、單一發版策略覆蓋不了所有功能的風險等級。

流量邊界

當不同功能的流量形狀、失敗代價、SLO 等級不同時，流量邊界已經形成。付款 API 一秒 100 個請求、商品搜尋一秒 10000 個請求、後台報表一天 100 個請求，三者放同一個服務會讓彼此爭資源，付款被搜尋擠掉是業務災難。

判讀訊號：高頻 endpoint 壓爆低頻 endpoint 共用的連線池、不同 endpoint 的 latency 分布同時惡化、無法針對核心交易設定獨立的 SLO 跟 alert。

其他常見拆分軸

上面四條是技術驅動的主要拆分軸。實務上還有其他軸常成為真實驅動力、要一併納入判讀：

• 失敗代價 / blast radius 軸：核心交易（掛了會有業務災難）跟邊緣推薦（掛了沒人在意）的可用性等級差距大、適合拆開降低 blast radius。跟 SLO 軸高相關但不同 — 重點在「失敗時誰受影響」的範圍隔離。
• 變更頻率 / 風險軸：high-velocity 實驗功能跟 stable 核心應拆開、降低實驗對核心穩定性的牽連。跟團隊軸高相關但獨立 — 同一團隊也可能維持兩種變更頻率的程式碼。
• 資料敏感度 / 合規邊界：PCI / PII / 醫療資料的隔離常是合規硬要求（GDPR data residency 強制資料拆境），不是技術選擇。這類軸跟資料邊界相關但服從不同壓力。
• 組織非技術約束：併購整合、外部合規節奏、團隊 reorg、預算切分都會強制拆分 — 比 metric 訊號更早觸發、技術上不一定最佳但無法繞過。

這些軸跟前四條可以同時生效、也可能彼此衝突（合規逼資料拆境、但流量軸建議聚合）。處理衝突時優先順序通常是「合規 > 失敗代價 > 部署 / 流量 > 團隊 > 資料 > 變更頻率」、但每個組織會有自己的權重。

拆分時機的判讀

拆分時機不能等到「已經痛到動不了」才開始，那時候拆分要付的代價最高。也不能在「還沒長出邊界」時提早拆，那會用 microservice 的協調成本懲罰一個還沒到規模的系統。

提早訊號（可以開始準備但不一定立刻動手）：

• 程式碼裡同一份邏輯被三個 PR 同時修改、merge conflict 增加
• 同一個 service 的不同功能開始有不同的擴展需求
• 不同團隊對同一個發版視窗的需求開始衝突

該動手訊號（再拖就要付高昂代價）：

• 任何一個功能改動需要 freeze 整個服務發版
• 局部高峰擴展時整個服務一起擴展，成本翻倍
• 一個團隊的事故會直接影響另一個團隊的營運指標
• 跨團隊 deadlock：A 等 B 改完才能上、B 等 A 改完才能上

過晚訊號（拆分要付遷移代價）：

• 已經出現過跨團隊事故、且復盤結論是「無法分離責任」
• DB 連線池在多個業務間爭搶、無法用 connection pool 隔離解決
• 部署平台跑不動：CI 太慢、build 太大、本地開發無法啟動完整環境

拆分代價與回退路徑

拆分不是免費操作。每多一個服務，就多一份運維成本、跨服務 trace 成本、契約治理成本。讀者要在拆分前認知這些代價，而不是事後才發現。

拆分失敗的回退路徑要在拆分前設計好。常見回退策略：保留原 monolith 程式碼一段時間（雙寫期），新服務出問題可以切回；先拆讀路徑驗證流量，再拆寫路徑；用 feature flag 控制是否走新服務。沒有回退路徑的拆分一旦撞牆，會比不拆更難收拾。

拆分後的通訊優先級：事件 > 同步 RPC

拆完後跨服務通訊有兩條路：同步 RPC（gRPC、REST）跟異步事件（message queue、event bus）。預設應該選事件、保留 RPC 給「真的需要同步回應的查詢」。

理由：

• 失敗代價隔離：服務 A 發事件給 B、B 掛了不影響 A — 事件留在 queue 等。同步 RPC 下、B 掛了 A 也跟著掛
• 流量解耦：事件本身就是 buffer、能吸收 burst。同步 RPC 是 throughput 的硬上限、A 的尖峰 = B 的尖峰
• 可重放：事件可以重放（replay）做資料修補、debug、新服務 backfill。同步 RPC 過了就過了
• 服務獨立演進：事件 schema 可以加欄位向下相容、consumer 慢慢 adapt。RPC interface 改動是 breaking change

該用同步 RPC 的少數場景：使用者請求路徑需要立即回應（「使用者按下查詢、顯示結果」）、且兩個服務都在同一個 latency budget 內。其他都優先事件。

詳見 03 模組訊息佇列 跟 0.3 非同步與事件傳遞選型。

反例：拆分過度的收回

服務拆分的反向動作是合併。當拆分後發現「服務間呼叫太頻繁、近乎同步、跨服務事務太多」時，代表這條邊界拆錯了。處理方式是把這兩個服務合回去，繼續增加跨服務工具只會堆疊複雜度。

判讀「該合併」的訊號：服務 A 與 B 之間每秒幾百次同步呼叫且失敗會連鎖、A 改動必定觸發 B 改動且兩者由同一團隊維護、跨服務事務佔總業務動作比例過高、跨服務 latency 是 SLO 主要消耗者。

合併不是失敗。它代表團隊已經理解這條邊界不該存在，及時收回比硬撐更負責任。Modular monolith（單一部署、模組化邊界）是常見的折衷形態：保留模組邊界、避免分散事務代價、未來壓力出現時再分拆。

判讀訊號

常見誤區

把「technical debt」當成拆分理由。Monolith 程式碼髒亂的解法是重構，不是拆服務。拆服務只是把髒亂從單庫變成跨服務契約混亂，問題並沒有消失。

把「跟風 microservice」當成決策。沒有業務壓力、團隊規模不到位、運維能力不夠的情況下拆服務，新的協作成本會壓垮整個團隊，這比 monolith 的痛苦更大。

把拆分當成單向操作。沒有設計回退路徑、沒有保留合併選項，拆錯了就只能硬撐。成熟的服務演進策略要把「拆」跟「合」當成雙向可逆操作。

定位邊界

本章專注「該不該拆、沿哪條軸拆、拆完怎麼收尾」。當問題進入具體拆分後的部署、流量、觀測責任，分別交給以下模組：

• 服務獨立部署 → 05 deployment platform
• 跨服務交接與事件 → 03 message queue
• 跨服務觀測與 trace → 04 observability
• 跨服務一致性與冪等性 → 03 idempotency-replay + outbox pattern

案例回寫

服務拆分判讀可用以下案例回寫：

• 9.C23 Netflix：把關聯式 DB 統一到 Aurora、效能 +75%、成本 -28% — 反例方向：原本各 microservice 各自 DB 造成運維碎片化、最後做 consolidation；對照本章「拆分過度的收回」段。
• 5.C2 Condé Nast：EKS 平台整併與標準化 — Condé Nast 把多 brand 各自的 K8s cluster 整併到統一 EKS 控制面、降低跨團隊運維分歧。對照本章「拆分代價 / 運維複雜度」段：拆出去快、合回來慢、設計時就要評估這種非對稱性。
• 9.C12 Riot Games：246 個 EKS cluster 的多遊戲多地區治理 — Riot 的拆分軸是「遊戲 × 地區 × 環境」三維交集、246 個 cluster 是這三軸的笛卡兒積取一個 subset。對照本章「拆分軸 / 部署邊界」段：實務上的拆分常常是多軸交集、不是單軸推進。

Netflix Aurora consolidation 是反例最有教學價值的一筆 — 它證明「拆 microservice 各自 DB → consolidation 回 Aurora」是 valid endgame、拆服務不是單向操作。Condé Nast 跟 Riot Games 補充另兩條維度：碎片化的運維代價、多軸交集的設計複雜度。把這三筆放回「拆分時機判讀」框架的不同節點上、能看出拆分決策的本質是「沿哪幾條軸 + 接受哪些代價」的組合。

跨模組路由

1. 與 0.1 後端服務能力地圖 的交接：拆分前要先理解每塊責任屬於哪種能力分類，避免拆出語意混亂的服務。
2. 與 0.5 流量與資料量評估 的交接：流量軸拆分要先有流量基線。
3. 與 03 message queue 的交接：拆分後跨服務通訊優先用事件、不是同步 RPC。
4. 與 9.13 擴展軸 的交接：拆分常常是水平擴展的前提（無狀態服務拆分後才能獨立水平擴展）。

下一步路由

規模成長路線下一站 → 9.13 擴展軸與 Stateless 前提：拆分後接著要為每個服務選擇擴展軸。

其他延伸方向：

• 實作層：服務如何獨立部署 → 5.2 Kubernetes 部署策略
• 事件層：拆分後跨服務通訊設計 → 03 模組訊息佇列

本文 不 展開 vendor 機制細節（partition key 設計 / consistency level / RU sizing / connection management 等）— 那些屬 per-vendor deep article 的責任、本文在每個軸後 cross-link 過去。本文也 不 比較三家「誰比較強」— 三 vendor 在 workload-by-workload 適配光譜上各有位置、寫成優劣比較會誤導讀者把選型壓成單軸。

問題情境：讀者進來時的真實壓力

典型啟動壓力分兩類：

第一類、團隊評估 document / KV / multi-model NoSQL 三家、文件都說「scalable schema-less」、看不出實際取捨。讀者徵兆是「我的資料是 document-shaped 還是 KV-shaped？」「partition key 該怎麼選？」「Atlas 跟 Cosmos DB MongoDB API 不一樣的點在哪？」「Cosmos DB multi-model 是真用得到還是行銷話術？」「on-demand vs provisioned 怎麼選？」

第二類、既有 PostgreSQL / MySQL workload 撞 connection limit（surge 下 1K-5K pool 是隱性天花板、F1.7）、想換 KV 但不知道是否適合。讀者徵兆是「我已經有 Memcached、還要再加 MongoDB cache 層嗎？」「DynamoDB 適合當 OLTP 嗎？」「換 NoSQL 是不是解 connection 問題的銀彈？」

這兩類讀者進來時的 真實問題 不在 vendor 之間、在 workload 自己屬哪一型。Case anchor 覆蓋六個 unique 角度：

• 多型 document workload — 9.C38 Toyota Connected（車載 sensor schema 隨車型演進、20 個 Atlas DB blast radius 切分）
• Document 跨雲 hedging — 9.C37 Forbes（自管 → Atlas、6 個月遷移、跨雲彈性）
• 同 model 換 vendor 的 dogfood signal — 9.C30 Microsoft 365（MongoDB → Cosmos DB MongoDB API、保留 driver、wire compat 限制）
• KV-as-buffer 正向用例 — 9.C15 Tixcraft（DynamoDB 寫入緩衝、6750x 彈性、後端慢消費）
• PK 天然均勻典範 — 9.C5 Amazon Ads（90M reads/sec 年度峰值、KV pattern 純粹）
• Federated DB 真實系統 — 9.C36 Coinbase（MongoDB + DynamoDB + Memcached + mongobetween + freshness token）

Workload shape × access pattern × consistency 三軸前置判讀

進三家 vendor 對比前先回答：你的 workload 屬哪一型？三軸的組合決定 vendor 候選清單、軸不識別清楚直接比 vendor 是把選型壓成「品牌偏好」、不是工程決策。

軸 1 — 資料形狀：document / KV / 不清楚

資料形狀的核心判讀是 aggregate root 邊界是否明確 跟 schema 是否會隨產品演進新增欄位。document 適合的場景是資料天然多型、單筆記錄欄位差異大、應用層用 aggregate root 模式存取；KV 適合的場景是資料形狀固定、access pattern 數量少（< 5 種）、固定 lookup by key。

第三列的「暫緩 NoSQL」是反指標。NoSQL（特別是 DynamoDB single-table design）的核心假設是「access pattern 在設計時已知、後續變動有限」。資料模型還在探索、access pattern 半年內會大幅增減的場景、PostgreSQL + JSONB 給的彈性遠高於 NoSQL — JSONB 欄位可以演進、ad-hoc query 可以用 SQL 跑、未來釐清穩定 access pattern 後再選 NoSQL 不遲。

軸 2 — Access pattern 穩定度（KV 適用度前置判讀）

KV 適用度的核心判讀是 partition key 天然均勻度。partition key 不均勻會讓 vendor 廣告的「scale infinitely」變成「scale 到 hot partition 為止」、單一 logical key 流量超過該 partition 上限就 throttle 或 latency spike（F1.1）。

• 天然均勻 PK + 穩定 access pattern（meeting_id / player_id / message_id / user_id）→ DynamoDB / Cosmos DB Table API 適用、PK 不需 composite key 修補。Amazon Ads 用 ad_id 撐 90M reads/sec、Zoom 用 meeting_id、Capcom 用 player_id、PayPay 用 message_id、Disney+ 用 user_id — 五個 case 都揭露同一 frame：業務天然存在均勻 key 時 KV 是最自然的選擇。
• 天然不均勻 PK（event_id 一場演唱會集中 / date 時間序集中）→ 需 composite key 或 write sharding 修補。Tixcraft（9.C15）用 event_id + user_id_hash composite key 把單一熱門演唱會的 6750x spike 攤平到 partition 上 — 不是 DynamoDB 自身彈性、是 partition key 均勻分散的結果（F1.2）。
• Access pattern 變動頻繁（探索期、< 5 種 query 還會增加）→ 不適合 DynamoDB single-table design、回 RDB。Single-table 把 access pattern 編進 PK / SK 結構、增加新 query 等於改 schema、改 schema 等於重新 load 資料、成本不對。

KV 適用度判讀的延伸細節（hot partition 反模式 / composite key 設計 / adaptive capacity）見 DynamoDB partition key antipatterns。

軸 3 — Consistency 需求是否可接受 eventual

Consistency 需求的核心判讀是 跨 partition / 跨 region transaction 是否為產品契約。三家 vendor 都支援單 partition / 單 region 強一致、但 cross-partition / cross-region transaction 的機制跟限制差異大。

• 可接受 eventual / session consistency：DynamoDB（default eventually consistent reads、可選 strong）、Cosmos DB（5 個 consistency level、default session）、MongoDB（read concern 多級）— 三家都可以、選擇看其他軸。多數 KV / document workload 屬此類（social timeline、watchlist、message queue、analytics aggregation）。
• 需要強一致 cross-partition transaction：DynamoDB 跨 partition transaction 限制（單一 transaction 最多 100 個 action、跨 region 不支援）、MongoDB 4.0+ 支援 multi-document transaction 但 sharded cluster 仍有 limitation、Cosmos DB 跨 logical partition transaction 受限 — 都不如 SQL／distributed SQL 自然、應回 DB4 entry point 評估 Aurora DSQL / Spanner / CockroachDB。
• 跨 region active-active write：三家機制完全不同 — Cosmos DB multi-region write 跟 Strong consistency 是 互斥 設定（CAP 取捨硬約束、見 Cosmos DB multi-region write conflict SSoT 主寫位置）；DynamoDB Global Tables 走 LWW（last-writer-wins）conflict resolution；MongoDB Atlas 跨 region 需手動 conflict 處理。三家不在同一光譜、選擇前必看各 vendor outline 的機制段。

Migration path 三型（跨 case 合成 frame）

本段是 跨 case 合成 frame、不是單一 case 揭露 — 從 Coinbase（9.C36）/ Forbes（9.C37）/ Microsoft 365（9.C30）三 case 萃取的共通結構（F2.1）。

讀者進來時通常不是綠地、是 既有系統演進。三型遷移路徑的風險、ROI、適用條件完全不同、選錯路徑會推到錯的 vendor。

第一型：保留原 DB + 補周邊工具

不換 vendor、加 connection proxy（mongobetween / pgbouncer 類）、加 cache（Memcached + freshness token）、加 predictive scaling — 主資料層不動、應用層跟 ops 層補強。

• 代表 case：Coinbase（9.C36）保留 MongoDB Atlas、自建 mongobetween 把 60K connections/min 降到 ~2K（一個量級）、用 Memcached + freshness token 撐 1.5M reads/sec、用 ML predictive scaling 把擴容時間從 70 → 25 分鐘提前 60 分鐘
• 路徑成本：中（自建工具、需要工程資源 build & operate proxy / cache layer / ML model）
• 風險：低（主資料層不動、回滾代價小）
• ROI：保留主資料 schema + access pattern、解 driver / 部署模型 / cache 一致性瓶頸
• 適合：MongoDB（或主 DB）資料層撐得住、但應用層 connection storm / cache miss / 擴容慢卡瓶頸；團隊有工程能力 build 跟 maintain 周邊工具

延伸實作細節見 MongoDB connection management（per-vendor article、cross-link 待寫稿）。

第二型：同 DB 換託管

自管 → managed（Atlas / Cosmos DB / DocumentDB）、保留 schema 跟 access pattern、遷移期 6 個月量級。

• 代表 case：Forbes（9.C37）自管 MongoDB → MongoDB Atlas、保留 CMS schema、6 個月遷移、揭露「TCO 改善 25%」
• 路徑成本：中（dual-write + shadow read 驗證、driver 行為差異、operation runbook 重寫）
• 風險：中（dual-write 期間雙寫一致性、cutover 時點選擇）
• ROI：operation transfer（DBA bandwidth 釋放給 schema design / query tuning）+ TCO 改善
• 適合：自管 ops burden 大（DBA bandwidth 被 backup / patching / replica lag 吃光）、不想換 model

Scope warning（Forbes 25% TCO）：「25% TCO 改善」是 Forbes 特定流量規模（120M MAU、70+ Atlas region）下的數字、不普適。引用要帶條件 — 不要寫成「Atlas 比自管便宜 25%」這種 vendor-neutral 結論。實際省多少要看自管當下的 license / hardware / ops 工時分配、跟 Atlas 在你流量規模下的 pricing tier。

第三型：換 vendor 保留 model

MongoDB → Cosmos DB MongoDB API、或 MongoDB → DocumentDB — wire protocol + driver 不變、底層架構整個換、ops 模型整個換。

• 代表 case：Microsoft 365（9.C30）MongoDB → Cosmos DB MongoDB API、保留 MongoDB driver
• 路徑成本：高（dual-write per query pattern 驗證、wire compat ≠ 100% 行為相同、aggregation pipeline 跟 transaction 行為要逐項驗證）
• 風險：高（每個 query pattern 都可能踩到不相容 edge case、cutover 點選擇難）
• ROI：跨 vendor 換（Azure 生態 / multi-model API / global distribution）+ 保留應用層 driver code

Scope warning（Microsoft 365 dogfood）：Microsoft 365 是 Microsoft 自家 dogfood、case 沒揭露具體 throughput / latency / cost 數字（F2.17）。dogfood 是 高權重 selection signal（雲商賭自家旗艦產品）、但 不是 production benchmark（沒公開數字可比對）。引用要明示「dogfood signal」而非「production proof」。

Scope warning（100% wire compat）：Cosmos DB MongoDB API 廣告「100% wire compatibility」是 vendor 行銷話術、實際是「在某些 query pattern 下相容」（F2.9）。遷移時必須 dual-write per query pattern 驗證 — 不是看 vendor 文件 spec list、是用 production query corpus 跑一遍實測行為。Phase 0 audit checklist 應列出 unsupported aggregation stage、transaction edge case、index behavior 差異、change stream 跟 Change Feed 對應關係。

延伸 Cosmos DB MongoDB API vs SQL API 選型見 Cosmos DB MongoDB API vs SQL API。

第四型不在 DB3 範圍：paradigm shift 換引擎

KV → SQL 或 SQL → distributed SQL 屬 paradigm shift、應進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree。本文範圍是 DB3 三家內部選型、不展開 paradigm shift。

從 RDB 撞牆來的快速路徑

讀者若從 PostgreSQL / Aurora connection limit 撞牆過來、想評估 KV 替代、依撞牆訊號直接 route 到對應 article、不必先跑完三軸前置判讀：

• 撞 connection limit（surge 下 pool 1K-5K 隱性天花板、long-lived TCP 占滿）→ HTTP API 模型（no long-lived connection）的 KV 直接接寫入緩衝、進 dynamodb/single-table-design-pattern 的「durable queue / write buffer」段（Tixcraft 9.C15 路徑：DynamoDB 接訂單、傳統 server 慢消費）、或評估 Cosmos DB Table API
• 撞單 primary 寫入上限（單 leader 寫吞吐天花板、read replica 無法分擔寫）→ multi-primary distributed SQL 路徑、進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree 的 Path A（DoorDash 1.636 M QPS 單主寫入撞牆）
• 撞單一 DB 撐不下 + 多 workload 形狀並存（read-heavy / write-heavy / analytics 混在一個 DB）→ federated DB 模式、看 9.C36 Coinbase（MongoDB + DynamoDB + Memcached + mongobetween）+ 9.C29 Lemino（PostgreSQL → DynamoDB 揭露 RDB connection limit 隱性 bottleneck）

進 dynamodb/single-table-design-pattern 前先確認軸 1 / 軸 2 的 access pattern 穩定度跟 PK 天然均勻度 — connection limit 訊號 必要但不充分、KV 適用度 4 軸還是要走完、避免「為了解 connection 把不穩定 access pattern 硬塞 single-table」反模式。

Federated DB + system role 視角（跨 case 合成 frame）

本段也是 跨 case 合成 frame（F2.18 + F1.6）— 三個 rich case（Coinbase / Toyota / Forbes）都揭露 production 系統是 DB + 周邊工具 組合、不是單一 DB monolithic 撐起來。

讀者常誤以為「全用 X」是正解 — 全用 MongoDB、或全遷 DynamoDB、或全換 Cosmos DB。真實 production case 揭露兩個更前置的事實：(a) production 系統是 federated（多 DB 按 workload 分流）、不是 monolithic；(b) 每個 vendor 在系統中扮演 特定角色（control plane vs data plane vs cache）、不是 all-purpose store。

Federated DB by workload

Coinbase（9.C36）production 配置：MongoDB Atlas（document 主資料、identity service）+ DynamoDB（部分固定 KV workload）+ Memcached（read cache）+ mongobetween（connection proxy）+ Kinesis（event stream）。不是「全用 MongoDB」也不是「全遷 DynamoDB」、是按 workload shape 分流。

Toyota Connected（9.C38）：MongoDB Atlas 20 個 DB（microservice 拆 blast radius）+ Lambda + Kinesis + Redis + Kubernetes。20 個 DB 不是吞吐撐不住（18B txn/月 ≈ 7K txn/sec、單一 cluster 撐得下）、是 microservice ownership + blast radius 切分（F2.6）。

Forbes（9.C37）：MongoDB Atlas + 中介 abstraction layer + 50+ microservice。abstraction layer 隔離 schema 變動、避免 50 個服務都依賴 DB schema 細節（F2.3）。

三 case 揭露的共同 frame 是：寫 production 系統時假設「DB 一個服務搞定」、忽略 cache / queue / proxy / abstraction layer 跨層責任、會撞 connection limit / cache miss / cross-region replication 等隱性瓶頸。

System role：control plane vs data plane

DynamoDB 在 surge 場景能撐 nearly infinitely 不是 DynamoDB 自己神奇、是 系統架構解耦 的結果（F1.6）：

• Control plane（metadata、state、user record）：DynamoDB / MongoDB / Cosmos DB 適合 — 流量是 small payload + high QPS pattern
• Data plane（影音、大型 BLOB、media stream）：CDN / S3 / object storage、不在 DB3 範圍 — 流量是 large payload + bandwidth-bound
• Cache layer：Redis / Memcached / DAX（DynamoDB 補位）— 跟主 DB 形成跨層架構、處理讀峰值 + read-your-own-write 一致性

三個 case 揭露同一 frame：Zoom 視訊 metadata 走 DynamoDB、影音走 WebRTC / edge servers；Disney+ watchlist 走 DynamoDB、影片串流走 CDN + S3；Capcom game state 走 DynamoDB + DAX、game server 走 EKS。把影音串流塞 DynamoDB 是違反 control plane vs data plane 分離、容量規劃會錯（每筆 1KB 的 KV vs 每筆 100MB 的 media chunk 是不同 workload）。

三 vendor 對比 10 軸

下表是三 vendor 在 selection 階段的 10 軸對比。每個軸後續都有 per-vendor deep article 展開機制、本文不重複展開。

軸的延伸子段

部署 topology / 跨雲 hedging：三家 topology 是 vendor lock-in 跟 跨雲彈性 的硬取捨。Forbes 選 Atlas 不是當下省錢（自管 MongoDB 也可以、TCO 改善是副作用）、是 未來雲商策略尚未底定 的 hedging — Atlas 提供 AWS / GCP / Azure 三家部署、未來換雲不用換 DB（F2.10）。對照 DynamoDB / Cosmos DB / Spanner / Aurora 都是單雲鎖定 — 選了就跟著該雲商生態走。團隊雲商策略已底定（深度用 AWS / Azure / GCP 其一）時、單雲 vendor 通常較划算（更好的 IAM 整合、更深的 ops 工具、單一 support 通道）。跨雲價值真正成立是 策略不確定 或 合規要求多雲 場景。

Capacity 抽象：三家 capacity 抽象的 思維遷移成本 可能高過 vendor 廣告的價差（F2.12）。MongoDB 用 CPU + IOPS + working set RAM 三軸思維、跟自管 PostgreSQL / MySQL 類似、團隊轉換成本低。DynamoDB 用 WCU/RCU 抽象、要學「估每個操作消耗多少 unit」、加上 on-demand / provisioned / adaptive capacity 三模式選擇。Cosmos DB 用 Request Unit（RU）抽象、1 RU ≈ 1 KB document 的 strong read 成本、寫 ~5 RU、複雜 query 數百 RU — 工程師要學會用 RU 思考、不是用 CPU 思考、團隊知識遷移成本可能高。容量規劃延伸見對應 vendor 的 sizing article。

Partition / shard key 可逆性：三家 不在同一光譜、是選 vendor 前必做的 access pattern audit 重點（F2.15）。MongoDB reshardCollection（4.4+）可改、但成本高、需要 cluster downtime 或長時間 background migration。DynamoDB partition key 技術上可改、實作上用 backfill（建新 table、新 PK、雙寫舊新、cutover）— ops 工作量大但可逆。Cosmos DB partition key 不可改、改 partition key 等於 export-recreate-import — 對 1TB+ 資料是大型 migration 工程。三家不可逆性遞增、選 Cosmos DB 前必須前期完整 access pattern audit、不能「先上 production 之後再調」。

Consistency model：三家機制設計哲學不同。MongoDB read concern 是 per-operation 選擇（同一 client connection 可以混用）；DynamoDB strong vs eventual 是 per-read 選項（write 端統一強一致）；Cosmos DB 5 個 level 是 account-level default + per-request override、且 Strong 跟 multi-region write 互斥（CAP 硬約束）。設計上 MongoDB 最 flexible、Cosmos DB 最 explicit、DynamoDB 介於中間。延伸機制細節見 Cosmos DB consistency levels engineering、Cosmos DB multi-region write conflict（SSoT 主寫位置）。

Multi-model 差異化：Cosmos DB 是 唯一單一服務支援 5 API 的雲商 DB（SQL / MongoDB / Cassandra / Gremlin / Table）— 對照 AWS 走多產品覆蓋（DynamoDB KV + DocumentDB MongoDB-compat + Neptune graph + Keyspaces Cassandra-compat）、GCP 走多產品覆蓋（Firestore + Spanner + Bigtable）。multi-model 的差異化價值是 減少多 DB 並存運維 — 一個產品團隊只養一個 service、一套 IAM、一套 backup / DR、一套 monitoring。但 是否真用上 multi-model 要看團隊實際 workload — 多數團隊只用 1-2 個 API、單一 model 的競品（DynamoDB / MongoDB）可能更專注（F2.16）。

失敗模式（cross-vendor 反模式）

下列七條是三 vendor 都會踩、跨 case 共通的反模式。Per-vendor 特定反模式（例如 DynamoDB on-demand 隱性 hot partition、MongoDB schema 三代並存）在 per-vendor deep article。

反模式 1：把 DynamoDB 當 OLTP

訊號：access pattern 還在探索期、5+ 種 query 還會增加、強一致 cross-partition transaction 是產品契約。應回 PostgreSQL / Aurora、不是繼續加碼 DynamoDB single-table design。

DynamoDB 的 正確 用法包含 control plane KV（Zoom / Disney+ / Capcom）跟 durable queue / write buffer（Tixcraft 9.C15 揭露的非 OLTP 正向用例、F1.3）— DynamoDB 接「訂單」寫入、不是即時生效、是讓 traditional server（金流 / 票庫）用自己能承受的速度消費。這層解耦讓「前端可以擴 130 倍、後端不用同步擴」。

反模式 2：把 MongoDB 當 KV

訊號：access pattern 固定、PK 天然均勻、不需要 aggregation pipeline、document 內部從不展開（只查 root 欄位）。

應改 DynamoDB / Cosmos DB Table API。MongoDB 在這場景的 overhead（document overhead / connection model / aggregation engine 未用上）不划算 — KV vendor 的單筆讀寫成本更低、scaling 模型更簡單。

反模式 3：把 Cosmos DB 當跨雲服務

訊號：團隊評估 multi-cloud DR / 跨雲 portability、看到 Cosmos DB 文件強調「global distribution」就以為支援跨雲。

Cosmos DB 是 Azure-only、global distribution 指 Azure 內跨 region。想跨雲應改 MongoDB Atlas。multi-model 差異化是 Azure 生態內 的價值（F2.16）— 一旦離開 Azure、Cosmos DB 的所有獨特優勢都不存在。

反模式 4：federated DB 假設「全用 X」

訊號：寫架構設計時假設「DB 一個服務搞定」、不規劃 cache / queue / proxy / abstraction layer。

Production 真實系統都是 federated（Coinbase / Toyota / Forbes 都是）。寫架構時假設一個 DB 搞定會撞 connection limit（surge 下 RDB 第一個爆點、F1.7）/ cache miss（單靠 DB 撐不住讀峰值）/ cross-region replication（跨 region 一致性處理錯）等隱性瓶頸。預先設計 federated topology + 跨層責任分配、不是事後補。

反模式 5：誤判 dogfood case 數字

訊號：引用 Microsoft 365 / Amazon Prime Day 等 dogfood case 時、把它當 production benchmark、抄具體數字當 sizing 依據。

Dogfood case 數字常 不公開 或 不適用 customer-facing（F2.17 + F1.10）— Amazon Prime Day 「90M reads/sec」是年度峰值最高一秒不是平均、Microsoft 365 直接沒給數字、Google Spanner「10 億 req/sec」是 Google 全使用者加總不是單客戶配額。寫架構時引用要明示 selection signal（雲商賭身家、值得當高權重 vendor 訊號）vs production benchmark（具體 sizing 數字）— 兩者不可混為一談。

反模式 6：partition key 一上 production 才發現不可逆

訊號：選 Cosmos DB / DynamoDB 時、partition key 設計沒做完整 access pattern audit、上 production 一段時間後發現 hot partition、想改 PK。

三家不在同一光譜（見前段對比表）— MongoDB shard key 4.4+ 可改但成本高、DynamoDB 可 backfill 改、Cosmos DB 不可改 必 export-recreate。選 Cosmos DB 前要前期完整 access pattern audit、列所有預期 query 跟對應 PK 訪問頻率、確認最熱 PK 流量在單一 partition 容量上限內（F2.15）。

反模式 7：wire compatibility 當 100% 行為相同

訊號：選 Cosmos DB MongoDB API 或 DocumentDB、看到「MongoDB compatible」就假設 MongoDB driver 跑得起來就是相容、跳過 query pattern 驗證。

Wire compat ≠ 行為 100% 相同（F2.9）。Cosmos DB MongoDB API 廣告「100% wire compatibility」是行銷話術、實際是「在某些 query pattern 下相容」— aggregation pipeline 某些 stage 不支援、transaction edge case 行為差異、index 行為差異都會踩到。遷移必須 dual-write per query pattern 驗證、不是看 vendor spec list。

不該選 DB3 的訊號（升 SQL / 升 distributed SQL 路徑）

下列四條訊號出現時、選擇應跳出 DB3 範圍。

• JOIN-heavy + 強 normalize workload：應留 PostgreSQL（包括 PostgreSQL + JSONB 混合方案）、不該塞 NoSQL 再 $lookup。aggregation pipeline 的 $lookup 性能遠不如 SQL JOIN、在 sharded cluster 還有限制。
• 強一致 cross-region transaction 是產品契約：應進 DB4 entry point 評估 distributed SQL（CockroachDB / Spanner / Aurora DSQL）。三家 NoSQL 的 cross-region transaction 都有 limitation、不該當主路徑。
• 大流量 + 跨業務 fleet 治理：Aurora 200 cluster 模式（9.C4 DraftKings 揭露的 business sharding fleet）可能更合適、進 Aurora fleet 治理。NoSQL 的 fleet 治理工具鏈（cluster lifecycle / cross-cluster query / unified IAM）通常不如 managed SQL 成熟。
• 資料模型還在探索 + access pattern 變動快：暫緩 NoSQL 選型、用 PostgreSQL + JSONB 過渡。JSONB 給 document-like flexibility、SQL 給 ad-hoc query power、未來釐清穩定 access pattern 後再選 NoSQL 不遲。

下一步路由（per-vendor outline 子組）

讀者識別 workload type（軸 1-3）+ migration path（三型）+ system role（federated / control plane）後、進對應 per-vendor 子組繼續深化。

MongoDB 子組

• 入門：schema design pattern（contract layer 三選一：DB 層 validator / app 層 abstraction / 混合）
• 容量：shard key selection（單 cluster vs 多 cluster blast radius、Toyota 20 DB 模式）
• Migration：migrate to Atlas（同 DB 換託管型）

DynamoDB 子組

• 入門：single-table design pattern（access pattern 設計 + 適用度前置判讀）
• 機制：consistency model optimization（strong vs eventually consistent 取捨）

Cosmos DB 子組

• 入門：MongoDB API vs SQL API（API model 選型、四層 framing）

跨層架構（federated DB / cache / proxy）

跨層架構的延伸內容見對應 per-vendor connection management / cache layer article（後續會寫）— 本文只在軸 2 / federated frame 點到、不展開機制。

進 DB4 evaluation

若需要強一致 cross-region SQL / paradigm shift（KV → distributed SQL 或 SQL → distributed SQL）、進 DB4 entry point: Aurora DSQL / Spanner / CockroachDB decision tree。

Knowledge card 路由

本文涉及的 knowledge card：

• document-store — document model 的核心概念跟 aggregate root 邊界
• hot-partition — KV vendor 的 partition 容量上限機制
• database-sharding — shard key 跟 partition key 設計
• consistency-level — strong / eventual / session 三類取捨
• vendor-lock-in — 單雲 vs 跨雲的 hedging 取捨
• distributed-sql — 跳出 DB3 進 DB4 的概念入口

流程定位

後端部署的主要風險是有狀態依賴。前端 artifact 可以直接回退上一份靜態檔，後端服務一旦寫入新資料、消費 queue message 或呼叫外部 side effect，rollback 就不再只是換回舊 image。發布流程要先定義新舊版本如何短暫共存，再決定 migration 與流量切換順序。

Build 階段負責產生可部署服務。服務版本要能從 runtime 反查 commit、workflow run、image digest 與 migration 版本，讓事故時能快速定位哪一次變更進入環境。

Contract test 階段負責驗證跨邊界相容。API response、database schema、queue message 與 config key 都是契約；只測 service 內部函式，通常抓不到新舊版本並存時的破壞性變更。

Migration 階段負責推進資料狀態。安全 migration 通常採 expand-and-contract：先加相容欄位或表、部署可讀新舊格式的程式、回填資料，最後移除舊格式。直接在同一次 release 刪欄位與切程式，會讓 rollback 失去空間。

Rollout strategy 階段負責控制新版本接到的流量。Rolling、canary 與 blue-green 都需要可信 readiness；readiness 應檢查服務能否接流量，而不只是 process alive。

Rollback strategy 階段負責定義失敗時的處理路由。後端 rollback 常見做法是 app rollback、config rollback、traffic rollback 或 forward fix；資料已被新程式寫入時，forward fix 往往比直接資料回滾安全。

Migration 順序

Migration 順序的責任是保留相容窗口。資料結構變更應讓至少兩個相鄰程式版本能共存，避免部署中途任何一端先完成都造成服務不可用。

1. 新增向前相容 schema，例如新增 nullable column 或新表。
2. 部署可同時讀舊欄位與新欄位的程式。
3. 執行 backfill 或 background migration。
4. 切換讀取來源或寫入路徑。
5. 觀察穩定後移除舊欄位、舊 index 或舊 message 格式。

這個順序的價值是可停止。若第 3 步回填異常，可以暫停 backfill，不必立即回退 app；若第 4 步切換後錯誤率升高，可以先切回舊讀取路徑，再評估資料修補。

Rollout 判讀

Rollout 判讀要同時看技術指標與業務副作用。服務能啟動不代表能安全接流量；API error、queue lag、database lock、第三方 API 錯誤與核心業務漏斗都可能是發布問題。

這些訊號要先接到發布流程。若指標只存在 dashboard 裡、workflow 不知道如何判讀，團隊仍會在事故當下靠人工臨場決策。

常見反模式

反模式的共同問題是把後端部署當成單一 deploy 動作。後端發布的本質是多個相依狀態的協調流程。

下一步路由

• 後端部署總覽：回 後端部署 CI/CD。
• Migration 術語：讀 Migration。
• Gate 原理：讀 CI gate 與 workflow 邊界。

服務定位

Cloudflare WAF 的核心定位是 把攻擊擋在 origin 之前的一站式 edge security。流量打到 Cloudflare anycast IP、經過 WAF / DDoS / Bot / Rate Limit / Page Shield 多層處理、再 proxy 到 origin。這跟 AWS WAF 跑在 AWS 內部 ALB / CloudFront / API Gateway 前是不同部署模型 — AWS WAF 流量 已經進到 AWS、Cloudflare WAF 流量 還沒到 origin。對 origin 是 任意雲 / on-prem 的客戶、Cloudflare 是天然選項；對 AWS-only 客戶、AWS WAF 整合更深但 edge 範圍小。

跟 Fastly Next-Gen WAF（前 Signal Sciences）相比、Cloudflare 走 signature + managed rule + ML 混合、Fastly NG-WAF 走 語意分析 + behavioral detection（不靠 regex signature）。Cloudflare managed rule 覆蓋廣但 false positive 較常見、需要 sensitivity tuning；Fastly NG-WAF 預設較低 FP 但需要 自己定義業務 anomaly。

關鍵張力：客戶信任的不只是 WAF rule 攔截能力、還包括 Cloudflare control plane 的安全性。Cloudflare 2023 control plane token 跟 Cloudflare 2026 route leak 兩個事件展示：vendor 自己被打進去 / 自動化配置失誤時、客戶側 直接修不了、只能等公告 + 客戶側 token rotation + emergency bypass。

本章目標

讀完本頁、讀者能判斷：

1. Cloudflare WAF 在 edge security stack 中承擔哪一段（DDoS / WAF / Bot / Page Shield / API Shield）、哪些要靠 origin 自己做
2. Managed Rule vs Custom Rule 的取捨、sensitivity tuning 跟 false positive curve
3. Cloudflare control plane 出事時的客戶側補強路徑（API token rotation、Origin Rules bypass、第二邊界 fallback）
4. 何時用 Cloudflare、何時走 AWS WAF / Fastly NG-WAF 的取捨

最短判讀路徑

判斷 Cloudflare WAF 配置是否健康、最少看四件事：

• 誰能改 WAF 規則：Cloudflare account 的 admin / member role 配置、API token scope（不要用 Global API Key、用 scoped API token + 限定 zone / 限定 permission）、Audit Log 是否同步到 SIEM
• 規則覆蓋面：Managed Ruleset（OWASP Core Ruleset + Cloudflare Managed Ruleset + Exposed Credentials Check）是否開、Sensitivity（Low / Medium / High）對應的 FP rate 是否監控、Custom Rule 是否進版控（Terraform provider）
• 入口暴露：origin IP 是否曝光（DNS 直查 / 歷史 SAN cert / 子域名）、Argo Tunnel / Authenticated Origin Pull 是否強制、繞過 Cloudflare 直連 origin 的路徑是否封住
• 證據可回查：Security Events Log 是否同步到 SIEM（Logpush 推到 R2 / S3 / Splunk）、Page Shield 偵測異常 script 是否 alert、API token 異常操作（特別 zone settings 變更）是否 alert

四件事任一缺失、就是 Audit Log 與 Entry Point Protection 邊界的待補項目。

日常操作與決策形狀

Managed Ruleset 分層：Cloudflare 提供三類 managed rule — OWASP Core Ruleset（OWASP CRS、寬覆蓋、FP 較多）、Cloudflare Managed Ruleset（Cloudflare 維護、針對熱門 CMS / framework）、Exposed Credentials Check（檢測登入流量中的已洩漏 credential）。production 通常開全部三套 + 各設適當 sensitivity。Sensitivity 不是「敏感度越高越好」— High sensitivity 攔截更多 borderline traffic、business-critical endpoint 可能誤殺合法請求。建議從 Log Mode 開始、觀察 1-2 週的 FP pattern、再切到 Block。

Custom Rule（Cloudflare Rules）：用 Rules language（類 SQL 表達式）定義條件 + 動作（Block / Challenge / Log / JS Challenge / Managed Challenge）。常見用法：geo block（特定國家）、known bad IP（threat intel feed）、URI path-based limit（admin endpoint 限定 IP）、header anomaly（缺 User-Agent / 異常 Referer）。所有 Custom Rule 走 Terraform provider 進版控、避免 console 直接改、變更走 PR review。

Rate Limiting：跟 WAF rule 是 獨立 product、配置是 threshold + window + action（例：1000 req/min per IP → challenge）。Rate Limiting 比 WAF 適合處理 legitimate-looking high volume（credential stuffing、scraping、API abuse）。注意 NAT pool IP 的問題 — 一個公司 / ISP NAT 出口可能合法產生高 QPS、簡單 per-IP rate limit 會誤殺、需要組合 cf.threat_score 或 cookie-based identification。

Bot Management（單獨 SKU）：免費版 WAF 不含 Bot Management、需要 Pro / Business / Enterprise 才有。Bot Management 用 ML + behavioral fingerprint 區分 human / good bot（搜尋引擎）/ likely bot / verified bot、給 bot score（1-99）。客戶在 Custom Rule 用 cf.bot_management.score < 30 之類條件挑出 likely bot 處理。簡單 user-agent 過濾擋不住現代 headless browser、必須走 Bot Management。

Page Shield（JS supply chain 防護）：Page Shield 監測客戶網頁載入的 JS / connect 來源、發現 新出現的腳本 或 已洩漏的 script（CT log + threat intel）就 alert。意義是 防 third-party script 被供應鏈攻擊（類 Magecart）— WAF 攔不住、因為攻擊發生在 browser 端 而非 origin 流量。需要在 Page 載入 Page Shield 的 monitoring script。

API Shield：用 OpenAPI schema validation、auto-discovery API endpoint、mTLS 驗證、JWT validation。對於有 schema 的 API、可以擋掉 schema 不符的請求（多餘欄位、型別錯誤、缺必要欄位）— 比 generic WAF rule 精準。

Origin 暴露面收緊：Cloudflare 唯一有效的前提是 流量必須經過 Cloudflare。如果攻擊者拿到 origin 真實 IP（DNS 歷史記錄、漏洞披露網站、SSL cert SAN）、可以繞過 Cloudflare 直打 origin。控制方法：origin firewall 只允許 Cloudflare IP range 入站、Argo Tunnel（origin 主動建 outbound 連線到 Cloudflare、不開任何入站 port）、Authenticated Origin Pull（origin 用 cert 驗證請求來自 Cloudflare）三選一或組合。

API token 治理：避免 Global API Key（全帳號 root token）、改用 scoped API token（限 zone + 限 permission + 限 IP + 限 TTL）。token 進 Secret Management / Vault、定期 rotate。對應 Cloudflare control plane token 2023 揭示的 lesson：Cloudflare 自己也踩過 token 治理不足、客戶側不能假設 vendor 完美。

核心取捨表

選 Cloudflare WAF 的核心訴求：多雲 / on-prem origin + 需要 整套 edge security suite（DDoS + WAF + Bot + Page Shield + API Shield） + 接受 Cloudflare 控制面風險、且有預算做 Enterprise tier 才能拿到完整功能。純 AWS-internal app + ALB origin 用 AWS WAF 整合更直接。

進階主題

Workers + Workers AI 作為 custom logic：當 managed rule + custom rule 表達力不夠（例：根據 user account tier 決定 challenge 強度、整合內部 risk score API）、可以用 Cloudflare Workers 寫 JavaScript / TypeScript / Rust 在 edge 執行。Workers AI 提供 edge ML inference、可以做 inline content moderation 或 anomaly detection。代價是 Workers code 進 Cloudflare 控制面、變更要走部署流程、debug 跟 origin 是兩條 trace。

Logpush 跟 SIEM 整合：Cloudflare Security Events 量大、free / Pro 在 dashboard 看、Business / Enterprise 走 Logpush 到 R2 / S3 / Splunk / Datadog / Sumo Logic。production 必須走 Logpush、不能只在 dashboard — 事件 30 天保留期是 Cloudflare 端、SIEM 留更久。Logpush 也是 SIEM 上做 跨來源 correlation 的前提（WAF event + origin app log + IdP log）。

Multi-account / Tenant：大企業有多個 Cloudflare account（不同 BU / 不同產品線）、要走 Cloudflare for SaaS 或 Account-level access、API token scope 要限定 account。Single account 多 zone 是常見小組織配置、但跨組織 / 跨產品線必須拆 account 隔離 admin compromise blast radius。

Magic Transit / Zero Trust integration：Magic Transit 是 L3 DDoS（不只 HTTP、TCP / UDP 也 anycast）、Zero Trust 是 employee access（取代 VPN）。跟 WAF 是不同產品、但常一起部署 — Magic Transit 防 L3/L4 attack、WAF 防 L7、Zero Trust 防內部 east-west。

排錯與失敗快速判讀

• Managed Rule 誤殺合法請求：High sensitivity 開後 business endpoint 變慢 / 報錯 — 看 Security Events 找 rule_id、用 Custom Rule skip 該 rule 在特定 path / 特定 user-agent、不要全 zone 關 rule
• Bot Management 太嚴 / 太鬆：bot score threshold 設不對、合法 API client 被當 bot、或攻擊者拿到 verified bot 假冒 — 用 Bot Analytics 看分數分布、調整 threshold 同時加白名單（API key + IP CIDR）
• Rate Limit 誤殺 NAT 用戶：per-IP rate limit 在 NAT 出口 IP 上炸 — 改 per-session（cookie-based）或 cf.threat_score 條件
• Origin IP 外洩：DNS 歷史 + 漏洞披露 + cert SAN 揭露真實 origin、攻擊繞 Cloudflare 直打 — 換 IP + 開 origin firewall（只允許 Cloudflare CIDR）+ Argo Tunnel
• API token over-scoped：CI / 第三方 SaaS 拿到 Global API Key、整 account 都被改 — 改 scoped token、限 zone + permission + IP、進 Vault
• Security Events 沒進 SIEM：事件只在 dashboard、跨來源 correlation 沒法做 — 配 Logpush + alert 規則
• Page Shield 沒裝：客戶端 JS 被植入、伺服器端日誌看不到攻擊、第三方 script CDN 被打 — 啟用 Page Shield + CSP report-uri 雙軌
• 第二邊界沒設：完全依賴 Cloudflare、Cloudflare 出事流量全停（2023 / 2026 自家事件）— 高 SLA 服務應該設 fallback origin / secondary DNS（如 Route53 health check failover 到 Fastly 或直連 origin）

何時改走其他服務

不在本頁內的主題

• Cloudflare 完整 product line（Workers / Pages / R2 / D1 / Magic Transit / Zero Trust 各自細節）
• WAF Rules language 完整語法 reference
• Page Shield / API Shield Enterprise tier 完整功能對照
• 各 PCI DSS / SOC 2 / FedRAMP 合規矩陣
• Cloudflare 在中國的部署模式（JD Cloud Union 合作）

案例回寫

Cloudflare WAF 在 07 案例庫有 兩個直接 vendor-level 事件 + 多個 edge-exposure 對照：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：AWS WAF、Fastly Next-Gen WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：HashiCorp Vault（Cloudflare API token 存放）、Okta（Cloudflare admin 走 SSO）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件 / Cloudflare 自家事件如何 routing 進 IR）
• 官方：Cloudflare WAF Documentation

服務定位

Vault 的核心定位是 跨雲 + 跨環境 + 跨 secret 形態的單一 secret 控制面。當組織同時跑 AWS + GCP + on-prem K8s、又需要 dynamic database credential + 內部 PKI + envelope encryption、用三個 cloud-native service 拼起來會出現 secret 治理鏈不連續（AWS 的 secret 怎麼授權 GCP service 取用、on-prem app 怎麼拿短期 cloud credential、內部 CA 跟外部 ACM 怎麼分工）。Vault 把這層 統一抽象 — 應用端只跟 Vault 講話、Vault 後端接各雲 KMS / database / PKI。

跟 AWS Secrets Manager / Google Secret Manager 相比、Vault 多了：dynamic credential engine（cloud-native 對應產品有限）、transit engine 做 encryption-as-a-service、PKI engine 自簽內部憑證、跨雲統一介面。代價是 自管運維（HA cluster、auto-unseal、replication、upgrade）— 跟自管 Keycloak 的取捨同類。HCP Vault（HashiCorp Cloud Platform）是 HashiCorp 託管版、把運維交還、但綁 HashiCorp。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret 適合 Vault（dynamic credential、跨雲、PKI、encryption-as-a-service）、哪些直接用雲端 native service 即可
2. Vault deployment 的最低安全需求（auto-unseal、HA、audit device、policy、replication）
3. Vault 自己出事時的降級路徑（seal storm、root token 復原、audit log gap）
4. 何時用 Vault、何時走 Secrets Manager / Google Secret Manager / Azure Key Vault 的取捨

最短判讀路徑

判斷 Vault deployment 是否健康、最少看五件事：

• 誰能做什麼：root token 是否已 revoke、policy 是否走 path-based least privilege、admin 是否走 OIDC / AWS IAM auth 而不是 token、break-glass token 是否離線存
• Auth method 收緊：AppRole / Kubernetes / OIDC / JWT auth 哪些開、role 對應的 policy 是不是過寬、TTL 是否短、bound_* 條件是否鎖（namespace / audience / subject）
• Secret engine 設定：KV v2 開 versioning？dynamic engine（database / aws / pki）lease TTL 多久、max TTL 限制是什麼、revocation 是否驗證生效
• Seal / unseal 治理：是否走 auto-unseal（KMS-backed）、recovery key 持有者跟 Shamir threshold、replication 跟 DR cluster 是否同步
• 證據是否可回查：audit device（file / syslog / socket）是否多 channel、是否同步到 SIEM、replay 攻擊防護是否開（HMAC + nonce）

五件事任一缺失、就是 Audit Log 與 Secret Management 邊界的待補項目。

日常操作與決策形狀

Auth method 設計：AppRole 適合不在雲端 metadata 內的 workload（on-prem、CI runner）但 secret_id 本身要妥善保管；Kubernetes auth 適合 K8s 內 workload、用 ServiceAccount token + projected token；AWS IAM auth 適合 AWS 內 workload、走 STS 簽名驗證、不需要存 secret；OIDC / JWT 適合 human admin + CI（GitHub Actions / GitLab CI 走 OIDC token）。每個 auth method 對應 一組 role、role 綁 policy 跟 TTL。

Secret engine 分層：KV v2（static secret + version history）作為基線；dynamic database engine（PostgreSQL / MySQL / MongoDB）發短期 DB user、max_ttl = 1h 級別、過期 Vault 自動 revoke；AWS / Azure / GCP secret engine 對 cloud account 發短期 STS credential / service account key；PKI engine 自簽憑證、跟 cert-manager 整合做 K8s workload mTLS；transit engine 做 envelope encryption — app 把資料丟給 Vault 加密、key 不離 Vault。

Policy（path-based）：Vault policy 是 path + capabilities（create / read / update / delete / list / sudo）的 mapping。常見錯配：給 secret/* read 等於整個組織所有 secret 都看得到、應該用 secret/data/{team}/* 之類前綴限定；admin policy 不要給 sudo 太寬、policy 變更走 PR review + CI apply。

Rotation 跟 lease 治理：static secret（KV）的 rotation 是 app 自己做（拿新 secret 後手動 update）；dynamic secret 是 Vault 控制 lease 生命週期、app 只要在 TTL 內續租即可。對應 Failure: Credential Rotation Without Scope：static secret 的 rotation 必須有 scope map — 哪些 service 用了同一把 secret、哪個 service 支援零停機 rotation、誰是 last to be rotated。沒這份 map 就會發生「rotate 後某個被遺忘的 cron job 認證失敗、整個下游崩」。

Seal / unseal 設計：Vault 啟動時 sealed、必須 unseal 才能服務。Shamir secret sharing 是預設（5 key holders、3 threshold）— 任何重啟需要找齊 3 個人合 unseal、production 場景幾乎都該換 auto-unseal（用 AWS KMS / GCP KMS / Azure Key Vault 當 master key custodian）。代價是 把 master key 託給雲廠 — 不接受的組織保留 Shamir + 嚴格 key holder rotation。

Audit device 是 必開：Vault 預設不開 audit、要手動 enable（vault audit enable file path=/var/log/vault_audit.log）。沒 audit device 在 production = 事故時 連 token 被誰用過都查不到。建議多 channel（file + syslog + 推到外部 SIEM）— 單一 channel 失效（disk full、socket broken）Vault 會拒絕請求、影響 availability、所以多 channel 是必要冗餘。

Break-glass 與 root token：初始化時產生的 root token 應該 用完立刻 revoke、改用 admin policy + OIDC auth。break-glass scenario 用 recovery key 重新發 root token、recovery key 走 Shamir 多人持有 + 離線存。

核心取捨表

選 Vault 的核心訴求：跨雲 + dynamic credential + 內部 PKI + transit encryption 至少滿足兩項、且能投入 SRE 量能跑 HA cluster、有 SIEM 接 audit log、能接受 self-hosted 的 upgrade / cert / DB 運維成本。單純需要 AWS-only static secret rotation、直接用 Secrets Manager 更便宜更簡單。

進階主題

Dynamic credential 的 lease 生命週期治理：dynamic engine 發出的 credential 都帶 lease ID、Vault 在 TTL 到期時自動 revoke（database engine 真的會 DROP USER、cloud engine 真的會 DeleteAccessKey）。設計時要算清楚 app 連線池的 connection lifetime — DB connection 持續用同一組 credential、credential lease 過期但 connection 還在會出現 staled credential 問題。常見作法：lease TTL > connection idle timeout * 2、加 lease renewal mechanism（app 在 TTL 50% 時主動 renew）。

Transit engine（encryption-as-a-service）：app 不持 encryption key、把 plaintext 丟給 Vault encrypt API、拿 ciphertext 回來；解密時把 ciphertext 給 Vault decrypt API。Key 完全不離 Vault、所有 cryptographic operation 在 Vault 內、app 只需要 encrypt / decrypt capability。對應 Storm-0558 signing key chain 的對照啟示：key 不能 export 是減 blast radius 的關鍵設計 — transit 把這個原則內建。

PKI engine + cert-manager 整合：Vault PKI engine 可以當內部 root CA + intermediate CA、issue 短期 cert（hours-level）給 K8s workload；cert-manager 用 Vault PKI issuer 自動更新 cert。比起手動跑 OpenSSL CA、Vault PKI 的優勢是 cert lifecycle 進 Vault audit、跟 secret rotation 用同一套 evidence chain（呼應 credential rotation scoped evidence）。

Namespace（Enterprise）跟 multi-tenancy：Enterprise 版 namespace 是 tenant 邏輯隔離、每個 namespace 有自己的 auth method、policy、secret engine。OSS 版沒 namespace — 多團隊共用 Vault 要靠 path 命名規約 + policy prefix 拼隔離、邊界較鬆。大組織通常需要 namespace 才能避免單一 admin 跨 team 越界。

Replication（Enterprise）：Performance Replication（主從 + 多 region active）跟 DR Replication（純 standby）是兩個獨立功能。production HA 通常需要 同 region 的 cluster + 跨 region 的 DR replication、recovery key 跟 unseal 機制要跨 cluster 一致。

排錯與失敗快速判讀

• Audit device 沒開：production 啟動時忘了 enable audit、事故發生時無 forensic data — 啟動 checklist 必含「enable audit before serving traffic」、SRE runbook 用 health check 驗
• Policy 過寬：給整個 secret/* read、單一 token 等於拿到全公司 secret — 用 path prefix 限定到 {team}/{env}/*、policy review 走 PR
• Dynamic credential lease 太長 / 沒 max_ttl：DB user 跑了一週還沒收、攻擊者只要拿到一次就長期可用 — 設定 lease TTL = 1h、max_ttl = 24h
• Auto-unseal KMS access 沒監控：AWS KMS / GCP KMS 的 Vault auto-unseal key 沒 alert 異常使用 — KMS 端設 alert（GetKeyValue / Decrypt 突增）
• Replication lag 沒 alert：Performance / DR replication 落後幾分鐘到幾小時、failover 時拿到 stale state — Prometheus 監控 vault.replication.* metric
• Root token 未 revoke：初始化時的 root token 還在用、policy / audit / OIDC 全 bypass — 初始化 checklist 強制 revoke、CI 跑 vault token lookup 驗證 root 不可用
• Sealed 後 unseal key 找不到人：production cluster 緊急 restart、Shamir threshold 3 但有 1 個 key holder 在度假 — production 必須 auto-unseal、recovery key 走 break-glass 流程

何時改走其他服務

不在本頁內的主題

• Vault 完整 API reference 跟 CLI 詳盡用法
• 每個 secret engine 的內部實作細節（DB connection pool、cloud SDK 呼叫順序）
• Enterprise 各 license tier 的功能對照
• Terraform / Ansible 跟 Vault 整合的完整步驟
• 各 auth method 的 OIDC / SAML provider 設定教學

案例回寫

Vault 在 07 案例庫沒有直接 vendor-level 事件、以下案例採對照引用：

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.13 偵測覆蓋率與訊號治理
• 平行：AWS Secrets Manager、Google Secret Manager、Azure Key Vault
• 下游：AWS KMS / Google Cloud KMS（Vault auto-unseal master key custodian）
• 下游：cert-manager（用 Vault PKI engine 作為 K8s workload cert issuer）
• 跨模組：8 事故處理 vendor 清單（Vault 事件如何 routing 進 IR 流程）
• 官方：Vault Documentation

服務定位

Okta 是 人類身份的控制面、不是 cloud resource permission engine。把 cloud IAM（AWS IAM、Google Cloud IAM、Azure RBAC）的角色指派交給 Okta 是常見組合 — Okta 負責「這個人是誰」、雲端 IAM 負責「這個身份能對 resource 做什麼」。Workforce Identity Cloud（員工）跟 Customer Identity Cloud（消費者、原 Auth0）是兩個產品線、安全模型跟事件分布都不同（本頁聚焦 Workforce、Auth0 見 Auth0 vendor）。

跟自管 IdP（Keycloak）相比、Okta 把 issuer 信任、signing key 生命週期、support tooling 都託管出去 — 代價是 第三方控制面的事故會直接打到自己（Okta 2022 Sitel 環境洩漏、2023 support system HAR token 外洩、2023 cross-tenant impersonation）。跟 cloud-native SSO（AWS IAM Identity Center）相比、Okta 的核心優勢是 多雲 + SaaS app 數百個 integration 預先建好、不是綁單一雲廠。

本章目標

讀完本頁、讀者能判斷：

1. Okta 該承擔哪一段 identity 控制（SSO / MFA / lifecycle / federation）、哪一段該交給雲端 IAM
2. Okta tenant 的信任邊界與最低稽核需求（admin role、API token、SCIM、support workflow）
3. Okta 自己出事時的降級路徑（emergency access、break-glass、out-of-band MFA）
4. 何時用 Okta、何時走 Auth0 / Keycloak / AWS IAM Identity Center 的取捨

最短判讀路徑

判斷 Okta 配置是否健康、最少看四件事：

• 誰能做什麼：Super Admin / Org Admin / Read-Only Admin 的人數、是否走 Okta 自己的 access request workflow、是否強制 phishing-resistant 認證
• 憑證在哪裡：API token 的 owner、scope、TTL、是否走 OAuth service app 而不是 personal API token；service account 是否獨立 audit
• 入口如何暴露：SSO 是 SAML 還是 OIDC、IdP-initiated 是否關閉、admin console 是否限 IP / device trust、helpdesk reset 是否要 callback / out-of-band 驗證
• 證據是否可回查：System Log 是否同步到 SIEM、admin / token / impersonation 事件是否 alert、是否保留 90 天以上

四件事任一缺失、就是 Audit Log 與 Authorization 邊界的待補項目。

日常操作與決策形狀

Onboarding / lifecycle：HR 系統推 SCIM 進 Okta、Okta 推 SCIM 到下游 SaaS / 雲端 SSO。決策點是 誰是 source of truth — HRIS 還是 Okta 自己。混用會造成 stale account 與例外帳號無法收。

Policy（authentication）：Sign-On Policy 跟 Authentication Policy（New Policy Framework）兩套並行、要避免規則交疊。高風險操作（admin login、寫權限應用）應該強制 phishing-resistant factor（WebAuthn / passkey）、不只是 push MFA（Uber 2022 揭露：純 push MFA 抗不過 fatigue）。

MFA factor 選擇：避免 SMS / voice 作為主要 factor。Okta 2024 把 telephony 推給客戶 BYO（Okta BYO Telephony case）— 信任邊界從「Okta 全管」變成「客戶自己挑簡訊供應商」、若沒同步調整威脅模型會把 SMS swap 風險吃下來。

API token / OAuth service app：personal API token 容易隨人員離職 stale、應該走 OAuth service app（client credentials）並把 scope 收到最小。token 不存 source code、走 Secret Management 取用。

Exception / break-glass：至少 2 個 break-glass admin、credential 離線存（紙本保險箱 / secret management 隔離 tenant）、走獨立 MFA（hardware key、不依賴主要 Okta tenant 的 push）、季度驗證可用。Okta tenant 整個失聯時這是唯一退路。

Audit / handoff：System Log 推進 SIEM、特別 alert 三類事件 — admin role 變更、API token 建立、impersonation / support access。Okta 2023 support system 事件展示：如果客戶沒 alert support impersonation 的 session、就只能等 Okta 公告。

核心取捨表

選 Okta 的核心訴求：跨雲 + 大量 SaaS app + lifecycle 要自動化、且能接受第三方控制面風險、有預算做完整 SIEM / break-glass / 第三方應變流程。

進階主題

Federation 跟 workload identity：Okta 對人類 SSO 強、對 workload identity 較弱。CI / 服務間用 AWS IAM role 的 OIDC trust、Google workload identity federation 比把 Okta API token 散到服務裡更安全。

Cross-tenant 邊界：B2B 合作（partner、contractor）要清楚是「partner 用自己 IdP 做 federation 進來」還是「partner 在我的 Okta tenant 開帳號」。2023 cross-tenant impersonation 事件（Okta Cross-Tenant case）揭示：admin 工具若沒限定 tenant scope、單一 admin compromise 會跨多 tenant 擴散。

Device trust / posture：Okta Device Trust + EDR signal 是補 phishing-resistant MFA 之後的下一層 — 確認 使用者 對之外、確認 裝置 健康。BYOD 比例高的組織這層做不起來就靠人類因子守。

Identity Threat Protection / ITP：Okta 2024 推的事件偵測 add-on、補 session anomaly、credential stuffing、impossible travel 等場景。本質是把 SIEM detection 的一部分內建、不是取代外部 SIEM。

排錯與失敗快速判讀

• Admin account 過多：經常超過必要 — 用 Group Rules + Access Request workflow 收斂、把日常操作用 Read-Only Admin + 特定權限 group 替代
• API token stale / 散落：personal API token 跟著員工離職留下 — 季度盤點、改 OAuth service app
• SMS MFA 還是預設：MFA enrollment 沒強制 WebAuthn / passkey、新員工選最弱 factor — Authentication Policy 應該限制可選 factor
• System Log 沒進 SIEM：事件只在 Okta UI、alert 沒接 on-call — 用 Log Streaming（CloudWatch / S3 / Splunk HEC）打進 SIEM、特定事件接 alert runbook
• Helpdesk reset 無 callback：MGM 2023 / Caesars 2023 都是 helpdesk social engineering、需要 callback + out-of-band 驗證、不是 ticket 上看到「我忘記密碼」就 reset
• Support 工具 session 沒監控：Okta 2023 support 事件揭示需要 alert support impersonation session 進入我的 tenant 的事件 — System Log 有對應事件、但通常沒 default alert

何時改走其他服務

不在本頁內的主題

• Okta 完整 SAML / OIDC 規格細節、SCIM schema 客製
• Workforce vs Customer Identity Cloud 完整功能對照
• Okta 各定價層級的功能差異
• 各 SaaS app 的 SSO 接線教學

案例回寫

下一步路由

• 上游：7.2 身分與授權邊界、7.13 偵測覆蓋率與訊號治理
• 平行：Auth0 vendor、Keycloak vendor、AWS IAM Identity Center
• 下游：AWS IAM / Google Cloud IAM / Azure RBAC（Okta 之後的 cloud resource permission 層）
• 跨模組：8 事故處理 vendor 清單（Okta 事件如何 routing 進 IR 流程）
• 官方：Okta Documentation

服務定位

Splunk 的核心定位是 任意 log source 的統一查詢平台、SIEM 是其上的 application layer（Splunk Enterprise Security app）。底層是 Splunk Enterprise（自管）或 Splunk Cloud Platform（SaaS）、頂層產品包含：Enterprise Security (ES) — premium SIEM app、含 correlation rule、Risk-Based Alerting、ITSI 整合；SOAR（前 Phantom）— security orchestration / automated response；UBA（User Behavior Analytics）— ML-based anomaly detection。

跟 Elastic Security 比、Splunk 走 deeper but more expensive — SPL 比 KQL / EQL 表達力更強、detection content（Splunk Security Content 公開 YAML rules）覆蓋廣、ES app 的 Risk-Based Alerting 是業界先驅；但 ingestion-based pricing 在 TB/day 級別會痛。跟 Datadog Security 比、Splunk 走 security-first、Datadog Cloud SIEM 是 observability platform 加上 security view；Datadog 適合 cloud-native + 中等規模、Splunk 適合 enterprise + 跨 on-prem。跟 Google Security Operations（前 Chronicle）比、Google Security Ops 走 fixed-price by data、massive scale、Splunk 是 per-GB 累進、超大規模反而 Google 划算。

關鍵張力：ingestion-based 計費 ↔ 偵測覆蓋率 是 Splunk 客戶最大的 trade-off。為了省錢選擇性 ingest log（只進 Windows Event Log 不進 Linux auth log、只進 prod 不進 dev）、結果 Storm-0558 / Uber MFA 那種跨來源 correlation 抓不到。要看清楚自己 容忍多少偵測盲點換多少預算。

本章目標

讀完本頁、讀者能判斷：

1. Splunk 在 SOC stack 中承擔哪一段（log aggregation / SIEM / SOAR / UBA）、哪些要外接（Vault 管 service token、IdP log 來源治理）
2. SPL / correlation rule / detection content 的 ownership 設計（誰寫、誰 review、誰調 false positive）
3. Ingestion pricing trap 的應對（log priority tiering、Cribl / Cribl Stream 做 pre-filter、Splunk SmartStore 把冷資料丟 S3）
4. 何時用 Splunk、何時走 Elastic / Datadog / Google Security Ops 的取捨

最短判讀路徑

判斷 Splunk deployment 是否健康、最少看四件事：

• 誰能改 correlation rule：Splunk admin / ES admin / KV store admin 的人數、SPL search 跟 saved search 是否走版控（Git → git-fusion / Splunk Cloud Versioned Configs）、rule change 是否經 PR review
• Ingestion 治理：哪些 source 進 Splunk（IdP audit log / cloud control plane log / endpoint log / network log / app log）、是否有 log priority tier（critical / standard / archive）、Cribl Stream 是否在前面做 pre-filter / routing
• Detection content coverage：Splunk Security Content（公開 YAML rule library）有多少 enabled、是否跟 MITRE ATT&CK 對照、自家 custom rule 是否補 organization-specific anti-pattern
• Alert quality / SOC handoff：alert volume per day、SOC analyst triage time、false positive rate、alert 是否進 SOAR playbook 自動處理低風險、跟 8 incident response 的 routing 是否定義

四件事任一缺失、就是 Detection Coverage and Signal Governance 邊界的待補項目。

日常操作與決策形狀

Ingestion architecture：log 進 Splunk 三種路徑 — Universal Forwarder / Heavy Forwarder（agent-based，自管 host）、HTTP Event Collector (HEC)（push log via HTTP endpoint、SaaS / serverless workload 預設）、Splunk Add-on for 各 cloud / SaaS（cloud-native log pull）。production 通常混用：endpoint 用 Universal Forwarder、cloud control plane 用 Add-on（AWS / GCP / Azure / Okta）、自家 app 用 HEC。在前面接 Cribl Stream 做 routing / filtering / sampling 是大型 deployment 的標準補位。

SPL（Search Processing Language）：類 Unix pipe 的 | 串接（index=ids sourcetype=auth | stats count by user | where count > 100）、表達力強但學習曲線陡。SPL 是 first-class concept、不只是查詢工具 — saved search 變 correlation rule、scheduled search 變 alert、accelerated search 變 data model 加速。SPL 寫得好不好直接決定 偵測規則品質 + 查詢成本。

Correlation rule / Notable Event：ES app 把 high-confidence finding 轉成 Notable Event、進 Incident Review queue。Correlation rule 的反例是 single-event alert（看到一個 SSH brute force attempt 就 alert、SOC analyst 一天看 10000 個沒意義）— production rule 應該是 time-bounded aggregation（過去 5min 內 100 個 brute force from same IP）+ cross-source correlation（brute force IP 同時出現在 cloud control plane access）。

Detection content lifecycle：Splunk Security Content 是 Splunk 維護的 OSS detection rule library、YAML format、跟 MITRE ATT&CK 對應。組織通常 先 import 全部 baseline、再選擇性 disable noisy 規則 + 新增 organization-specific 規則。Rule change 走 PR review、staging tenant 跑 24-48hr 觀察 false positive curve 才 promote 到 production。對應 Detection Engineering Lifecycle 的章節原則。

Risk-Based Alerting (RBA)：ES app 7.0+ 引入、給每個 user / asset 累積 risk score（取代逐 finding alert）、累積到 threshold 才 alert。處理 alert fatigue 的工程化做法：5 個 low-confidence signal 加總超過 threshold 比單一 high-confidence alert 更接近真實 attack pattern。對應 Alert Fatigue and Signal Quality。

SOAR integration：Splunk SOAR（前 Phantom）接 alert + playbook 自動執行 — 例如 leaked credential 自動 rotate（拉 Vault API）、suspect IP 自動加 firewall block（拉 Cloudflare WAF custom rule）、suspect user 自動 force MFA re-enroll（拉 Okta API）。playbook 進版控、定期 dry-run、不能黑箱 production fire-and-forget。

Ingestion pricing 治理：Splunk 按 ingestion volume（GB/day）計費、TB-scale deployment 年費千萬美元級別。實務治理：tier 1 log（IdP / cloud control plane / payment processor / DB audit）進 Splunk hot index、tier 2 log（app log / web access log）按 sampling / filtering 進 Splunk、tier 3 log（debug / verbose）走 SmartStore 到 S3 / GCS 冷儲存、或繞過 Splunk 直接打到 Elastic / data lake。Cribl Stream 在 forwarder 前 pre-filter 是業界標準作法、可省 30-50% ingestion cost。

SmartStore 跟冷熱分離：SmartStore 把 indexer 的 warm + cold bucket 放到 S3 / Azure Blob / GCS、indexer 只保留 hot data + cache。意義是 retention 從幾個月延長到幾年但 cost 不線性漲。production deployment 幾乎都該開、不開等於每年砸錢買 EBS。

核心取捨表

選 Splunk 的核心訴求：Enterprise scale + 跨 on-prem + detection content 跟 SOC tooling ecosystem 成熟、且能投入預算（千萬美元級別 license + Cribl pre-filter + SmartStore 冷儲存治理）+ 有 SOC team 維護 correlation rule 跟 SOAR playbook。中等規模 cloud-native 直接走 Datadog / Google Security Ops 更划算。

進階主題

Enterprise Security app 的 Risk-Based Alerting：RBA 把「事件 → alert」改成「事件 → risk score → 累積 → alert」、是 alert fatigue 的工程化解法。實作要決定 risk decay window（多久後 risk score 衰減）、risk attribution（同一台 EC2 上多 user 的 risk 怎麼分）、per-asset vs per-user threshold。配對 Uber 2022 MFA Fatigue 的 lesson：單一 MFA fail 不該 alert、5min 內 50 個 fail + 新裝置 + 異常地理就是 high risk。

Common Information Model (CIM) + Data Model：Splunk CIM 把不同 source 的欄位 normalize 到統一 schema（authentication / network_traffic / web 等 data model）。意義是 SPL 跨 source 寫一次、不用為 Okta log / Azure AD log / CrowdStrike log 各寫一份。CIM 配合 Add-on 自動 mapping、organization 寫 custom source 需要自己定 CIM mapping。

Multi-tenant deployment：MSSP / 大型集團多 BU 共用一個 Splunk 部署、用 index（隔離 data）+ role / capability（隔離 access）+ App（隔離 dashboard / search）三層。注意 Splunk admin 在跨 tenant 場景是高權限角色、應該走 break-glass 流程 + audit。

Cisco 整合（2024+）：Cisco 收購後 Splunk 跟 Cisco XDR / Talos threat intel / Cisco Secure Endpoint 整合加速。對 Cisco-heavy 環境是 ecosystem 一致性增加；對非 Cisco 環境暫時影響有限、但長期 roadmap 會有 Cisco-specific 加值。

排錯與失敗快速判讀

• Alert volume 爆炸 / SOC 看不完：correlation rule 寫成 single-event alert、或 false positive baseline 沒調 — 用 RBA 改 risk-based、staging tenant 跑 48hr 觀察再 promote
• Detection coverage 出事故時才發現缺：critical log source 沒進 Splunk（為了省錢）— 補回 tier 1 log priority、用 Cribl Stream 對 tier 2 / 3 做 sampling 而非整批不 ingest
• Ingestion cost 暴衝：新 source 加入沒 review、debug log 直接打進 Splunk — Cribl Stream 前置 + license usage dashboard alert + indexer ingestion quota
• SPL search 慢 / 卡 search head：full-fidelity search on 1TB raw event、沒用 data model acceleration — 改用 accelerated data model、限定 time range、用 tstats 而非 stats
• Correlation rule false positive 多：rule 寫得太寬、env-specific noise 沒 tune — staging tenant 跑 1 週統計 FP、tune threshold、加 lookup table 排除已知合法 source
• SOAR playbook 黑箱 fire-and-forget：自動 disable account 結果誤殺 CEO — playbook 走 approval gate for high-impact action、defaults to containment not deletion
• Splunk admin 太多 / 沒 break-glass：日常運維用 admin token、admin compromise blast radius 太大 — 收 admin 角色、改 power user + 特定 capability、break-glass 走 Vault

何時改走其他服務

不在本頁內的主題

• SPL 完整語法 reference、saved search 跟 macro 進階用法
• Splunk Cloud Platform vs Splunk Enterprise 的功能對照細節
• Splunk Observability Cloud（前 SignalFx 收購、跟 Datadog 直接競爭、屬 observability 不屬 security）
• ITSI（IT Service Intelligence）— 屬 ITSM / observability、不在資安範圍
• SOAR playbook 的具體實作（Phantom Python SDK）

案例回寫

Splunk 在 07 案例庫沒有直接 vendor-level 事件、但所有 detection-related case 都是 SIEM 偵測覆蓋率的對照：

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Elastic Security、Datadog Security、Google Security Operations
• 下游：Google DLP / Microsoft Purview（DLP signal 進 Splunk）
• 跨類：Okta（IdP log source）、HashiCorp Vault（SOAR playbook 拉 API）、Cloudflare WAF（WAF log + auto-block）
• 跨模組：8 事故處理 vendor 清單（Notable Event → IR routing）、4 observability（log pipeline 共用）
• 官方：Splunk Documentation

服務定位

k6 是 Grafana Labs 旗下的 scriptable load testing 工具、2021 年被 Grafana 收購。產品線分兩層：k6 OSS（Go 寫的 engine + JS API 描述 scenario、CLI 為主、output 可丟 Prometheus / InfluxDB / JSON / CSV）跟 Grafana Cloud k6（前 k6 Cloud、SaaS 多 region runner + 結果保存 + 跟 Grafana Cloud dashboard / Loki / Tempo 同 plane）。底層 engine 是 Go、不是 JS — JS 只是 scenario 描述層、runtime 由 Go 跑、所以單機 VU 容量比 Python-based 工具高出一個量級。

跟 JMeter 比、k6 走 code-first + CI-friendly、JMeter 走 XML / GUI + plugin ecosystem；JMeter 在 protocol 廣度（JDBC / LDAP / JMS / FTP）跟非工程團隊操作勝出、k6 在版控、PR review、artifact pipeline 勝出。跟 Locust 比、k6 用 JS、Locust 用 Python；Locust 對 Python team 自然、但 Python GIL 讓單機 VU 容量受限、需多 worker、k6 單機可跑數千 VU。跟 Gatling 比、Gatling 走 JVM + Scala/Java/Kotlin DSL、適合 JVM-heavy 團隊；k6 的 threshold + Grafana ecosystem 整合在 release gate 場景更直接。

定位

k6 適合把壓測納入工程流程。當團隊已經能描述 traffic shape、endpoint mix、arrival rate、think time 與 stop condition，k6 可以把這些模型寫成腳本，讓每次 release、capacity review 或 peak-event readiness 都能重跑同一組驗證。

這個定位讓 k6 接到三個主章。它從 9.2 Workload Modeling 接收流量模型，從 9.4 Saturation Discovery 接收 ramp-up 與 knee point 判讀，從 9.10 Production-Side 驗證 接收 canary、dark launch 或 production-like load test 的安全邊界。

適用場景

API 壓測是 k6 最穩定的入口。Checkout、login、search、order query、payment callback mock 與 internal API 都可以用 scenario 表達，並用 threshold 把 latency、error rate 與 throughput 轉成 pass / fail 訊號。

CI performance gate 是 k6 的常見價值。團隊可以在 merge、nightly、pre-release 或 game day 前跑固定 baseline，觀察 p95 / p99、error rate、throughput 與 regression trend，再把結果交給 6.13 Performance Regression Gate。

Peak readiness rehearsal 適合用 k6 表達階段式負載。活動前可以用 ramping arrival rate 模擬 T-90、T-30、T-7、T-1 與 T-0 的負載階段，並把結果回寫到 9.11 高峰事件準備。

最短判讀路徑

判斷 k6 deployment 是否健康、最少看四件事：

• Scenario design：用 executor: ramping-arrival-rate 而非 constant-vus、把 RPS / arrival rate 設成 first-class、VU 由 engine 自動算；scenario 描述跟 9.2 Workload Modeling 的 endpoint mix、think time、cohort 對得起來
• Threshold gate：thresholds 區塊明確寫 p95 / p99 / error rate / throughput、CI fail 條件清楚、不靠人眼看 summary 判斷 pass / fail
• Output 進 observability stack：--out experimental-prometheus-rw 把 metric remote-write 到 Prometheus、Grafana dashboard 接 k6 同 datasource、結果跟 target service 的 saturation metric 在同一張圖上看
• k6 Cloud vs CLI 邊界：本地 CLI 跑 baseline + CI、Grafana Cloud k6 跑跨 region / 大規模 / 結果 retention；不要把 CI gate 放 Cloud（成本 + 時間不對）、也不要本地單機硬跑 100k VU（runner 自身瓶頸假象）

四件事任一缺失、就是 scenario 已經寫得不完整、threshold gate 失效、或 runner 觀測缺失。

選型判準

腳本化價值來自可重跑。一次性的壓測只能回答當天配置能撐多少；可版本化 scenario 可以回答 release 後容量曲線有沒有漂移，並讓退化調查回到同一份 workload model。

CI 友善價值來自交接成本低。壓測結果要能轉成 artifact、threshold、trend 與 gate decision，才會從「工程師手動跑工具」變成 release 流程的一部分。

API 導向價值來自後端路徑明確。k6 很適合 checkout API、search API、internal API 與 webhook receiver；如果主要問題是完整 browser UX、第三方真實支付或多裝置同步，文章要把資料準備、side effect 與環境隔離另外寫清楚。

跟其他工具的取捨

k6 和 JMeter 的主要差異是工作方式。k6 偏程式化腳本、CLI、CI artifact 與工程流程；JMeter 偏 GUI、protocol plugin、既有企業測試流程與非工程團隊協作。

k6 和 Gatling 的主要差異是生態與語言。k6 使用 JavaScript-style 腳本，Gatling 偏 JVM / Scala / Java / Kotlin 生態；團隊語言能力與既有 pipeline 會影響維護成本。

k6 和 Locust 的主要差異是團隊技能與模型表達。Locust 使用 Python，對 Python 團隊與 custom user behavior 很自然；k6 的 threshold、CLI 與雲端 / Grafana 生態讓 release gate 整合更直接。

k6 和 Vegeta 的主要差異是場景複雜度。Vegeta 適合簡單 HTTP load、CLI workflow 與快速 saturation 探測；k6 適合較完整的 multi-step scenario、threshold 與長期 baseline。

核心取捨表

選 k6 的核心訴求：API-first scenario + CI gate + Grafana / Prometheus ecosystem 已用、且團隊接受 JS DSL。Protocol 廣度需求大、走 JMeter；Python team、走 Locust；JVM-heavy、走 Gatling。

進階主題

k6 Browser：基於 Chromium + Playwright API、跑在 k6 同 scenario 內、可混 protocol-level 跟 browser-level load（前段 API call、後段真實 browser flow）。意義是「pure API load 跟 real user UX 在同一份 scenario」、不用維護兩套工具。但 browser VU 比 protocol VU 重幾十倍、runner cost 要重新算。

xk6 extensions：用 Go 寫 k6 extension、補 protocol（Kafka / Redis / SQL / AMQP）或 output（custom backend）。xk6 build 生出客製 binary、organization 可維護自家 extension。意義是 k6 不只跑 HTTP — Kafka producer load / Redis hot-key probe 都能用同一個 scenario harness。

Grafana Cloud k6（前 k6 Cloud）：SaaS 跑 multi-region runner、結果保存、跟 Grafana Cloud dashboard / Loki / Tempo / Prometheus 同 plane。適合 跨 region 真實延遲驗證、大規模 distributed run、結果 retention + team share。跟 Grafana Cloud 已用的團隊 ecosystem 一致；只用 OSS 的團隊走 k6 Operator on k8s。

Distributed execution：自管 distributed 走 k6 Operator on Kubernetes、scenario 拆 instance、結果 aggregate 到 output。意義是不需要 k6 Cloud 也能跑跨機器 load、但 runner pool 自管成本 + 結果 aggregation 自己處理。

Output integration：--out experimental-prometheus-rw 直接 remote-write 到 Prometheus、Grafana dashboard 一張圖看 k6 client metric + target service saturation；--out cloud 上 Grafana Cloud k6；--out json=... 落地檔案給 CI artifact；--out influxdb 接 InfluxDB（legacy）。Loki 用來接 k6 console log、Tempo 用來接 k6 trace（若 scenario 帶 W3C trace context）。

排錯與失敗快速判讀

• VU 跑不上去 / runner CPU 滿：scenario 寫了重 JS 邏輯（big JSON parse、複雜 regex、crypto）— 把 setup-once 邏輯搬 setup()、不要每 VU iteration 重算
• Resource throttling 假象：runner 機器 CPU / network bandwidth / file descriptor 自身瓶頸、target service 還沒到 saturation — 換大機 / 多 runner / 看 runner 自身 saturation metric 排除
• Threshold 設過嚴 / CI 一直 red：threshold 抄 production SLO 不留 budget — staging tenant 跑 5-10 次抓 baseline distribution、threshold 設 baseline + buffer、不是 SLO 直接搬
• p95 看起來好但 user 抱怨慢：scenario endpoint mix 跟 production traffic shape 不符 — 補 production endpoint distribution、按 weight 配 scenario、跟 9.2 Workload Modeling 對齊
• Script logic 太重 / VU iteration 不穩：在 scenario 內做 token refresh / large payload 處理、iteration 時間漂移 — 用 executor: ramping-arrival-rate 鎖 RPS 而非 VU count、iteration 時間漂移由 engine 吸收
• 結果無法回放 / 找不到 baseline：output 沒落 artifact、Grafana dashboard 沒存 time range — 每次 run 強制 --out json + tag scenario version + push 到 evidence package

操作成本

k6 的主要成本是 workload model 維護。腳本本身容易寫，真正的成本在 production endpoint mix、資料分布、tenant / region / user cohort、think time 與 peak shape 的持續校正。

Runner 成本會隨負載規模上升。單機 runner 適合小型 API baseline；跨 region、數十萬 RPS 或長時間 soak test 需要分散式 runner、網路成本、目標服務隔離與觀測儲存。

測試資料治理是高風險成本。Checkout、payment、order、email、notification 與 webhook 路徑都可能產生 side effect，因此 scenario 要明確定義 test tenant、idempotency key、mock boundary、cleanup 與 stop condition。

Evidence Package

k6 結果應回寫到 evidence package。最小欄位包括 scenario version、target environment、time range、VUs / arrival rate、threshold、p95 / p99、error rate、throughput、target service saturation metric、known gap 與 owner。

Evidence package 的核心用途是讓 release gate 能判斷。k6 的 threshold pass 只是其中一個訊號；gate 還要看 target service 的 CPU、connection、DB latency、cache hit rate、queue lag 與 cloud cost。

案例回寫

k6 目前在 09 案例庫中主要作為工具類承接點，案例主角仍是負載形狀與驗證節奏。它可回寫到 9.C15 Tixcraft 售票壓測 的 pre-event load test 判讀、9.C1 Prime Day readiness 的 staged validation、9.C28 FanDuel 雙峰 workload 的多模型壓測需求、9.C2 GR8 Tech FIFA World Cup readiness 的 54000 TPS @ 25ms p95 驗證、以及 9.C7 Lyft 8x peak 跨 100+ 微服務的獨立 threshold 設計。

這些案例提供的是負載形狀與工程節奏。k6 頁引用案例時，要把 case 轉成 workload model、ramp-up、threshold、runner 規模與 stop condition，並讓工具回到可替換的承載選項 — 例如 GR8 Tech 25ms p95 是 threshold pass / fail 的硬目標、Lyft 的「8x 是特定服務、不是全部 8x」要拆成 per-service scenario。

下一步路由

• 上游：9.2 Workload Modeling
• 上游：9.3 壓測工具選型
• 上游：9.4 Saturation Discovery
• 跨模組：6.13 Performance Regression Gate
• 官方：Grafana k6 documentation

本章是 01 模組的基礎章節之一、之後章節（1.3 transaction boundary / 1.10 KV / Document 容量規劃 / 1.11 全球分散式 OLTP / 1.12 大規模 DB 遷移實戰）都會回引這層的概念。跨模組對接 9.4 Saturation Discovery 跟 9.5 瓶頸定位流程。

本章目標

學完本章後、讀者能夠：

1. 理解資料庫 client 為什麼應該共用
2. 分辨 query、exec、rows 與 transaction 的不同邊界
3. 了解連線池參數對高併發的影響
4. 設計多層 connection pool 架構（app + middleware + DB）
5. 識別 hot row / lock contention 並選擇對策
6. 用 read replica 擴 read traffic、注意 replication lag
7. 用 context 與 timeout 控制慢查詢
8. 判斷什麼情況該換 KV / 緩衝模式而非繼續硬擴 SQL

【觀察】資料庫 client 通常代表連線池入口

多數後端語言的資料庫 client 都會包住連線池或連線管理能力。一般情況下、服務會在啟動時建立可重用的 database handle、讓 request handler、worker 或 service layer 共用它、並在需要時從池子裡取出可用連線。

這種模型的好處是：

• 呼叫端不用自己管理每個連線的生命週期
• 多個 request 或 worker 可以同時發出資料庫操作
• 連線回收與重用由 sql.DB 處理

【判讀】高併發需要有界連線

高併發時的核心風險是把 application concurrency 誤解成 database concurrency。語言端的 thread、task、coroutine 或 goroutine 可能很容易建立、但資料庫有自己的容量上限；連線池只是把壓力從應用端平滑地送到下游、無法消滅壓力。

連線池調校的核心觀念是：

• SetMaxOpenConns 太低、request 會在應用端排隊。
• SetMaxOpenConns 太高、可能把 DB 直接打滿。
• SetMaxIdleConns 影響高峰與尖峰之間的重用效率。
• SetConnMaxLifetime / SetConnMaxIdleTime 影響長連線與資源回收節奏。

第一個爆的通常是連線、不是 CPU 或 disk

SQL DB 在 surge 場景的 first bottleneck 不是 CPU、也不是 disk I/O、是 連線數量。原因：傳統 RDB（PostgreSQL、MySQL）每個連線吃記憶體 + 一個 process / thread、connection pool 上限通常 1K-5K。流量湧入時、application 想開更多連線、DB 直接拒絕（PostgreSQL：FATAL: too many connections）、看起來像 DB 故障、實際是連線數限制。

對應 9.C29 Lemino — NTT DOCOMO 串流平台選 DynamoDB 而非 RDB 的原因之一是「connection limit 在快速流量增加時變成 bottleneck」。DynamoDB 的 HTTP API 模型沒有 connection state、天然解決這個瓶頸。

判讀順序：surge 期間 DB 看起來慢、先 SHOW PROCESSLIST / pg_stat_activity 看連線數、再看 CPU / disk。連線數已經滿、再加 CPU 沒用；要加 middleware pool（pgBouncer / ProxySQL）或換 HTTP-based DB。

多層 Connection Pool 架構

實務上 production-grade 服務的 connection pool 通常分三層：

Layer 1：Application pool（每個 instance 內）

• 每個 application instance 維護自己的 driver-level pool
• 典型大小：30-50 connection / instance
• 工具：HikariCP（Java）、SQLAlchemy pool（Python）、sql.DB（Go）

Layer 2：Middleware pool（共享層）

• PostgreSQL：pgBouncer（最常見、transaction pooling）、PgCat（rust、支援 sharding）
• MySQL：ProxySQL（query routing + pool）
• 為什麼需要：多個 application instance 同時打 DB、總 connection 數會爆
• pgBouncer 把 1000 application connection mux 到 50 個 DB connection、應用感覺有 1000 connection、DB 只看到 50

Layer 3：Database 端 max_connections

• PostgreSQL default 100、實務常設 200-500
• MySQL default 151、實務常設 1000-5000
• 每個 connection 吃記憶體（PG ~10MB、MySQL ~3MB）、設太高會 OOM

典型配置範例（中型網路服務）：

150 application instance × 30 connection (app pool)
2  → pgBouncer transaction pool (4 instance × 100 connection)
3  → PostgreSQL primary (max_connections = 200)

1500 application connection mux 到 200 DB connection、4 倍 multiplexing。

反模式：

• 跳過 middleware pool、application 直連 DB
• 應用 instance 50 個 × 30 connection = 1500 connection、PostgreSQL 直接拒絕

對應 9.C29 Lemino case — RDB connection limit 是 surge 場景的隱性 bottleneck、Lemino 選擇遷移到 DynamoDB 而不是擴 connection pool（因為 HTTP-based KV 沒這個問題）。

Query 反模式如何放大連線池壓力

連線池被占滿的根本原因不只是「連線數不夠」、還有「單一連線被占用的時間太長」。Query 反模式直接放大每筆 request 的連線占用時間：

• N+1 query 讓一個 request 占用連線從 1 個 round trip 拉長到 N+1 個。同樣的 throughput、需要 N+1 倍的連線數來 sustain
• Long-running transaction 把一個連線從幾毫秒占用變成幾秒，相當於把連線池的有效容量除以幾百倍
• 缺索引的 query 在熱表上跑 full scan、單筆 query 從 10ms 變成 1-5 秒、連線占用時間放大兩個數量級
• SELECT * 載入大欄位：reader 在反序列化大物件期間連線一直 hold、不是 query 本身慢、是 serialization overhead 拉長占用

這些反模式單獨看是「query 寫法問題」、但放到連線池語境就是「連線池容量被間接削減」。先用 1.13 query 反模式 的清單收回連線占用時間、再考慮加 9.14 connection pooler 中介層 — 順序顛倒會讓 pooler 治標不治本。

【策略】讀取與寫入要分開看

讀取的核心風險通常是慢查詢、掃描過大、N+1、熱點資料與連線被占住太久。寫入的核心風險則常常是 transaction 太大、衝突太高、鎖時間太長、重試邏輯不清楚。

讀取

• 用索引支援常見查詢條件。
• 避免一次載入過多資料。
• 需要分頁時、先考慮游標或穩定排序。
• 熱讀資料可以在上層加 cache、同時保留資料庫作為正式狀態來源。

寫入

• transaction 只包住真正需要一致性的範圍。
• transaction 範圍只保留必要資料操作、外部 API 呼叫、使用者等待或長迴圈應放在交易外。
• 高衝突寫入要搭配重試、唯一鍵或明確去重策略。
• 需要高吞吐時、先評估批次化、分段處理與有界並發。

詳見 1.3 Transaction Boundary 對 transaction 設計的深度討論。

Hot Row / Lock Contention 識別與處理

當多個 request 同時想 update 同一筆資料、會在 DB 層出現 lock contention。這跟 KV 的 hot partition 是同類問題、但 機制不同。

典型 hot row 場景：

• inventory counter：所有用戶搶同一個 product 庫存
• counter / metrics：實時計數器（view count、like count）
• queue / job ledger：所有 worker 競爭同一個 job table
• session：高頻 session 更新

識別訊號：

• pg_stat_activity / SHOW PROCESSLIST 顯示大量 lock waiting
• 整體 QPS 沒滿、但某些 endpoint p99 飆
• pg_locks / INFORMATION_SCHEMA.INNODB_LOCK_WAITS 有大量等待

對策：

1. 分散熱點：

• counter shard：把 1 個 counter 拆成 N 個 sub-counter、寫入時隨機選一個、讀取時 SUM
• 例：view_count_0 ~ view_count_9 → 10 倍寫入吞吐
• 對應 Hot Partition 卡片 在 SQL DB 的對應做法

2. Asynchronous batching：

• 不要每次點擊就 update counter、先進 in-memory buffer、定期 flush
• 應用層 Redis INCR + 定期同步回 SQL

3. Optimistic concurrency control：

• 用 WHERE version = ? 樂觀鎖、避免 SELECT FOR UPDATE
• 衝突時應用層 retry

4. 換 KV / cache：

• counter workload 本來就不適合 SQL transaction
• 用 Redis INCR、DynamoDB 的 atomic counter

5. Queue + worker 序列化：

• 把搶資源的 request 排隊、worker 序列化處理
• 對應 9.C15 Tixcraft 案例 — 售票把 inventory 搶購塞進 DynamoDB queue、legacy server 慢慢消費、避免 SQL hot row

Read Replica Scaling

當 read traffic 超過 primary 吞吐、用 read replica 擴 read。

Read replica 機制：

• PostgreSQL：streaming replication（async / sync）
• MySQL：async replication（binlog）
• Aurora：storage-level replication（lag 10-30ms）

Routing 策略：

1. Read / write split（application-level）：

• 應用層判斷 query 類型、寫走 primary、讀走 replica
• 工具：ProxySQL（MySQL）、application 自管

2. Routing 自動化（middleware）：

• pgBouncer + 路由規則
• HAProxy + health check

3. Stale read 容忍策略：

• 「能容忍秒級 stale」的 read → replica（用戶 profile、報表）
• 「不能 stale」的 read → primary（剛寫入後的查詢、餘額確認）
• read-after-write consistency：用 session token 標記「剛寫過」、N 秒內讀走 primary

Replication lag 監控：

• PostgreSQL：pg_stat_replication.replay_lag
• MySQL：SHOW SLAVE STATUS\G 的 Seconds_Behind_Master
• Aurora：CloudWatch AuroraReplicaLag
• 對應案例：9.C4 DraftKings Aurora — replication lag 從 30 秒降到 10-30ms、是切換到 Aurora 的關鍵改善

注意事項：

• replica 數量不是無限、Aurora 最多 15 個、PostgreSQL 通常 3-5 個（chain replication 更多但複雜）
• 跨 region replica 通常 async、不能保證 read-after-write
• 對應 9.C28 FanDuel Super Bowl 5-10x peak、需要動態加 replica

儲存層 replication vs compute 層 replication

Aurora / Cosmos DB / Spanner 的 replication 跟傳統 PostgreSQL streaming replication 是兩種本質不同的設計、決定 read replica 怎麼擴、replication lag 落在什麼量級、容量規劃要顧哪些瓶頸。

傳統 RDB（compute 層 replication）：

• primary 寫入後、把 WAL / binlog 流到 replica
• replica 自己 replay log、消耗 CPU 跟 disk
• primary 寫入量大、replica 跟不上、replication lag 飆
• 加 replica 增加 primary 的 replication 負擔、不能無限加

Aurora / Cosmos DB（storage 層 replication）：

• compute 跟 storage 分離、storage 是分散式 log-based
• replication 在 storage 層 處理、不經過 compute
• replica 不用自己 replay、直接讀同一份 storage
• 加 read replica 不增加 primary 寫入負擔
• replication lag 從 30 秒級降到 10-30ms（Aurora）

為什麼這層差異反映在應用層設計：compute 層 replication 的 replication lag 通常在秒級、應用層必須處理「剛寫的資料 N 秒內讀不到」的情境 — 常見補丁是 read-after-write consistency（session token 標記「剛寫過」、N 秒內走 primary）、cache invalidation 延遲、或刻意走 primary 的關鍵查詢路徑。Storage 層 replication 的 lag 在毫秒級、這些補丁多半不需要、read 可以幾乎無條件走 replica。對應 9.C4 DraftKings — 從 30 秒到 10-30ms 不只是「快」、是讓整個應用層 cache invalidation 跟 session routing 邏輯大幅簡化。對應 9.C23 Netflix Aurora consolidation — Aurora 75% performance improvement 主要來自 storage layer 設計、不是 CPU 改善。

選型含義：如果應用層 依賴 read-after-write（餘額確認、剛寫的查詢、session 狀態）、storage 層 replication 比 compute 層 replication 大幅簡化設計。代價是 vendor lock-in 加深、應用層綁定特定雲商。

對應 9.C32 Clearent Azure SQL Hyperscale 跟 Aurora 是同類設計（log-structured 分散式 storage）、選哪家看 application 已在哪個 cloud、技術哲學一致。Sharding 觸發點（managed DB 容量上限）跟業務一致性需求決定 sharding 粒度的討論、見 1.11 Sharding 粒度跟業務一致性需求。

【執行】查詢與 rows 的生命週期要收乾淨

查詢回傳 rows 後、呼叫端要負責把它關掉、並檢查迭代錯誤。這不只是記憶體管理問題、也會影響連線何時能回到池子裡。

典型模式是：

 1rows, err := db.QueryContext(ctx, "SELECT id, name FROM users WHERE status = ?", status)
 2if err != nil {
 3    return err
 4}
 5defer rows.Close()
 6
 7for rows.Next() {
 8    var id int64
 9    var name string
10    if err := rows.Scan(&id, &name); err != nil {
11        return err
12    }
13}
14if err := rows.Err(); err != nil {
15    return err
16}

【策略】慢查詢要靠 timeout 與上層限流處理

在高併發服務裡、database timeout 應由 request timeout、client timeout 與資料庫 timeout 共同定義。語言端需要能把取消、deadline 或 timeout 往資料庫 client 傳遞、讓慢查詢在合理時間內釋放資源。

如果下游開始變慢、通常要搭配：

• request-level timeout
• worker pool 或 semaphore
• queue 長度限制
• 降級或拒絕策略

這樣做的目標是避免應用自己堆出大量等待中的工作、最後把問題放大成整個服務卡死。

什麼時候該換 KV / 緩衝模式而非繼續硬擴 SQL

SQL 的 transactional 模型有結構性限制、超過某個規模硬擴 SQL 不如換工具。

換工具的訊號：

1. Connection saturate 但 CPU / RAM 還閒：connection 是 SQL 的早期 bottleneck。對應 9.C29 Lemino — RDB connection limit 是 surge 場景的瓶頸、換 DynamoDB（HTTP-based、無 connection 概念）解決。

2. Hot row contention 無法分散：應用層改不了 schema、無法把 counter shard、SQL 就是 contention 源頭。換 Redis atomic counter / DynamoDB atomic update。

3. Write throughput > 50K WPS 單機：sharding 工程成本變高、不如換 KV 或分散式 SQL。詳見 1.10 KV / Document DB 容量規劃 或 1.11 全球分散式 OLTP。

4. Flash-sale spiky workload：用 SQL 接搶購、connection 跟 lock 都會爆。對應 9.C15 Tixcraft 用 DynamoDB 當 durable queue、legacy SQL 慢慢消費。

5. 跨 region 強一致 OLTP：傳統 PostgreSQL / MySQL 跨 region 是 async、滿足不了強一致。換 Spanner / Aurora DSQL / CockroachDB（1.11）。

不要因為「現在 SQL 慢」就跳結論換 NoSQL — 先確認問題是 結構性的（connection、contention、跨 region）、不只是 調校問題（index、query、cache）。

【延伸】語言端的責任是邊界

這一章不討論 PostgreSQL、MySQL、SQLite 的語法差異、也不討論 migration 工具本身。語言端需要掌握的是：怎麼共用 database client、怎麼控制並發、怎麼縮小 transaction、怎麼把 timeout 和取消傳下去。

具體 schema、index、isolation level 與 migration 寫法、會放在這個模組的其他資料庫教材中。

案例對照

9.C1 Prime Day 是高併發章節的 上限參考點：Amazon 自家 Prime Day 在 24 小時內、DynamoDB 服務 1.51 億 RPS 毫秒級回應、Aurora 處理 5000 億次 transaction。這份數字的意義不是「要達到這個量級」、而是給定 可預期峰值 跟 無限預算 時、AWS 自家服務的設計上限長這樣。讀本章其他內部 baseline（connection pool、replica lag、isolation level）時、要記得最終物理上限遠高於大部分服務日常會碰到的水位。

跨語言適配評估

資料庫高併發邊界會受語言 runtime 影響。Thread-based runtime 要管理 thread pool 與 connection pool 的比例；async runtime 要確認 database driver 是否真正非阻塞（很多老 driver 只是包了 sync 在 thread pool 上、會吃 thread limit）；輕量 task runtime（Go、Erlang）要限制同時查詢數量、避免把大量 task 轉成下游連線壓力。強型別語言可以用型別保護 row mapping 與錯誤分類；動態語言則需要用 migration、runtime validation、contract test 與 fixture 保護 schema 邊界。

小結

高併發下處理 SQL 的核心原則：

1. database client 共用、不要每 request 新建
2. 連線池可控 — 三層架構（app pool + middleware + DB max_connections）
3. transaction 要短 — 詳見 1.3
4. rows 要關、避免連線被占住
5. timeout 要傳遞 — 從 request 一路到 DB
6. Hot row 要識別 — counter shard、optimistic concurrency、async batching、或換 KV
7. Read replica 要會用 — 但注意 lag、stale read 容忍度
8. 下游壓力要限流 — request timeout、worker pool、queue 長度、降級拒絕
9. 知道什麼時候換工具 — connection saturation、hot contention、flash-sale、跨 region 強一致都是 SQL 結構性限制的訊號

應用端並發可以很多、但資料庫連線必須受控、這兩者的邊界要分開管理。

讀「峰值」數字的工程細節

容量規劃時看到「100 萬 ops/分鐘」、「150 萬 RPS」這類數字、要拆三個維度看、否則容量規劃會錯位。

容量數字的三個口徑

最大瞬時 是觀測得到的最高峰值、通常是年度某秒、不能拿來訂 baseline。在 Grafana / CloudWatch / Datadog 上看 max 指標就是這個數字 — 用來知道系統 曾經 撐過多少、不是 日常 要撐多少。

99 百分位平均 是 capacity 規劃的主要依據。在監控工具看的是 p99 隨時間的平均值（rolling 30 天或 90 天）— 代表 99% 的時間流量低於這個水位。Auto-scaling 上限通常訂在這個值的 1.5-2 倍、確保 99% 時間有足夠 headroom。

常態流量 是 average / median、訂 cost baseline 跟 auto-scaling 的下限。在 PaaS（Aurora Serverless、Cosmos DB serverless）這是「最低保留容量」的依據；在 IaaS 是「永遠開著的 instance 數量」。

9.C5 Amazon Ads 揭露這個議題：「9000 萬 reads / 秒」通常是年度峰值最高一秒、不是平均。讀案例時要區分這三個口徑、否則容量規劃會錯位。

對應 9.C4 DraftKings — 「100 萬 ops/分鐘」≈ 17K ops/秒、跨 200 個獨立 cluster 平均下來每 DB 約 80 ops/秒。讀峰值要看 分散到多少 shard、不只看總數。

延遲改善要看 percentile、不是平均

「延遲降 90%」這類敘述要追問：是 p50 還是 p99？兩者改善幅度通常差很多、平均值會掩蓋尾巴問題。

對應 9.C20 Zomato — 「90% 延遲降」實際可能是 p50、p99 / p999 改善幅度通常較小。判讀重點：用戶體驗主要受 p99 / p999 影響、不是 p50。看到「平均 50ms 降到 5ms」要追問「p99 從多少降到多少」、否則可能用戶感受沒改善。

延遲監控的必要 percentile：p50、p95、p99、p99.9。p99.9 對 1000 個 request 才偵測一次、但通常代表系統最差表現、是 SLO breach 的早期訊號。

Headroom budget：事件型 vs 突發型峰值

Headroom budget 是 提前預留的容量空間、給可預期或不可預期的峰值用。讀「Super Bowl +50% no sweat」這種敘述、工程意義是團隊事前預留了 headroom、不是 vendor 神奇。

對應 9.C4 DraftKings — Super Bowl 是已知事件、+50% 是歷史經驗、所以可以提前 pre-scale。整個 system headroom 預留至少 50%、加上 read replica 動態加減、才能讓 50% 增幅變成「不流汗」。

兩種峰值的 headroom budget 規劃完全不同：

事件型峰值（已知時間 + 已知幅度）：

• 例：Super Bowl、Black Friday、票券開賣、財報日
• 規劃做法：歷史 peak × 預期成長 × headroom（通常 1.5-2x）= baseline、事件前 scheduled scale-up
• headroom 預算可以較低（20-30%）、因為峰值可預測、可在事件前測試
• 對應 9.11 高峰事件準備

突發型峰值（未知時間或未知幅度）：

• 例：突發新聞、KOL 推廣、競爭對手出包導致流量湧入、病毒式擴散
• 規劃做法：常態 baseline 預留高 headroom（50-100%）、加 auto-scaling 跟動態 capacity
• headroom 預算要高、因為事故發生前沒時間 scale
• 對應 9.C2 GR8 Tech AI 預測式擴容

判讀重點：事件型 headroom 適合可預測峰值、突發型 headroom 適合不可預測峰值；兩者預算邏輯不同。把事件型 headroom 套用在突發型場景、突發事件發生時容量會不足；把突發型的高 headroom 套用在事件型、會付大量浪費成本。

讀寫峰值錯位：dual peak workload

部分業務有 讀峰值跟寫峰值不同時段 的特性、容量規劃要按 peak 之和 而非 單一 peak。

對應 9.C4 DraftKings — 「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」。比賽進行時讀爆量（用戶看餘額、看下注狀態）、比賽結束 payout 時寫爆量（賠付寫進帳本）、兩個 peak 錯位。

容量規劃含義：

• 不能只規劃「讀 peak + 寫常態」或「寫 peak + 讀常態」
• 要規劃「讀 peak 跟寫 peak 各自的容量」、即使不同時發生、底層 DB 都要撐
• read replica 動態增減可以平滑讀 peak、但寫 peak 要靠 primary capacity 撐住

類似 dual peak 業務：

• 體育博彩：比賽中讀、payout 時寫（DraftKings）
• 票券：開賣前 30 分鐘讀爆量（用戶看座位）、開賣瞬間寫爆量（搶票）
• 電商促銷：促銷前讀爆量（用戶看價格）、促銷瞬間寫爆量（下單）
• 股票交易：開盤前讀爆量（看開盤價）、開盤瞬間寫爆量（送單）

判讀重點：dual peak workload 是業務 天然 特性、不是異常。容量規劃要識別這層、否則尖峰時段會踩到沒預期的瓶頸。

關鍵路徑切分：低頻流量保護

當系統有「高頻流量（如選位、瀏覽）」跟「低頻但關鍵流量（如付款、結算）」共存時、必須切分、否則高頻流量會塞爆低頻路徑、讓低頻關鍵業務無法完成。

對應 9.C15 Tixcraft — 拓元把 Payment EC2 拉出來、直連傳統金流 server、不放在搶票流量會打到的 ELB / DB 後面。讓「選位 + 下單」的高頻流量塞爆時、「付款」的低頻流量仍能跑。

切分策略：

• 資料路徑切分：高頻 query 走 DynamoDB / read replica、低頻關鍵 query 走 primary
• 連線池切分：高頻 service 跟低頻 service 用不同 connection pool、避免高頻吃光連線
• runtime 切分：低頻關鍵 service 部署到獨立 instance、不跟高頻共用 CPU / memory
• 限流切分：高頻 endpoint 設高限流、低頻關鍵 endpoint 設保護性低限流（避免 cascading failure）

判讀重點：切分前要先盤「哪些流量是業務關鍵但量小」、這些路徑要事先保護、不能等爆了再分開。

下一步路由

• 上游：Connection Pool 卡片
• 上游：1.13 應用層查詢反模式與 Query 預算（connection saturation 常因 N+1 / long transaction 放大、先檢查 query 寫法）
• 平行：1.2 Schema Design、1.3 Transaction Boundary
• 下游：1.10 KV / Document DB 容量規劃（SQL 不夠用時的替代）/ 1.11 全球分散式 OLTP / 1.12 大規模 DB 遷移實戰（換 DB engine 的決策跟流程）
• 跨模組：9.4 Saturation Discovery、9.5 瓶頸定位流程、9.6 容量規劃模型、9.13 擴展軸（hot row 是不可分散瓶頸的 application 層表現）
• Vendor：PostgreSQL、MySQL、Aurora
• 規模成長路線下一站 → 2.2 cache aside 與失效策略（連線池 / replica 擴完後、進入應用層快取設計）
• MongoDB connection storm 深入：MongoDB connection 管理與 cache 層 / replica set read preference
• Aurora read replica 擴展：Aurora read replica scaling（reader endpoint / lag 治理）
• Freshness token 卡片：Freshness Token（read-after-write 保證選項）

教學路線：SQL baseline 與交易演進

PostgreSQL 服務頁的教學目標是建立 SQL baseline。讀者讀完後要能用 PostgreSQL 理解 transaction、schema evolution、query boundary、connection pressure 與 managed / distributed SQL 的比較基準。

定位：OLTP 預設、SQL 工程深度

PostgreSQL 跟 MySQL 是兩大 SQL OLTP 主流、但設計取捨明顯不同：

• PostgreSQL 偏 特性深度 — JSON、GIS、full-text search、partial index、CTE、window function 都成熟
• MySQL 偏 簡單 query 效能 + 分片生態 — Vitess / PlanetScale 提供超大規模 database sharding

選 PostgreSQL 的核心訴求：需要進階 SQL 特性、需要長期 schema evolution 彈性、信任 community-driven 演進、想避免單一 vendor lock-in（PostgreSQL 是 open source、可跨雲 / on-prem）。

容量特性

PostgreSQL 沒有「vendor 給的容量數字」、要靠 instance 配置 + tuning 推估。但有幾個工程上限要知道：

單一 primary 寫吞吐：

• 一般 m5.4xlarge 級 instance：5K-10K WPS（依 schema、index、commit fsync）
• 高階 r6i.16xlarge + io2 storage：30K-50K WPS
• 超過這個級別 → 應用層 database sharding 或換 Aurora / Spanner

Connection 上限：

• 預設 100 connection、每個 connection ~10MB RAM
• 1000+ connection 必須 pgBouncer / PgCat 共享 pool
• 對應 9.C29 Lemino case — RDB connection limit 是 surge 場景的隱性 bottleneck

Read replica：

• streaming replication：1 個 primary + 多個 standby（async / sync）
• 跨 AZ replication lag 通常 < 100ms、跨 region 可能秒級
• 跟 Aurora 比、自管 PostgreSQL replication lag 較大

Storage 上限：

• 單一 table 32 TB（PostgreSQL 設計上限）
• 實務上單表超過 1 TB 開始有 vacuum / index 問題、建議 partition

適用場景

1. 多用途 OLTP、複雜查詢：

• 複雜 JOIN、CTE、window function、subquery
• 訂單系統、會員系統、訂閱方案、權限 RBAC
• 需要 strong consistency + ACID transaction

2. JSON / 半結構化資料：

• JSONB column 支援 indexing、partial query
• 比 MongoDB 適合 主要結構化 + 部分 JSON workload
• 不適合主要 document workload（用 MongoDB / Cosmos DB）

3. 地理 / 全文檢索：

• PostGIS 是業界標準 GIS extension
• 全文檢索（ts_vector）對中等規模夠用、超大規模用 Elasticsearch

4. 進階特性需求：

• partial index（WHERE 條件下才建 index）
• exclusion constraints（避免 booking 重疊）
• range types（時間 / 數字範圍）
• logical decoding / CDC（Debezium、pgcapture）
• foreign data wrapper（query 跨 DB）

5. 跨雲 / on-prem 部署：

• 不想 vendor lock-in
• 可用 Patroni / Stolon / pg_auto_failover 做 HA
• 對應 1.11 全球分散式 OLTP 的 CockroachDB / Aurora DSQL 比較段

6. 中小規模高峰場景：

• 流量 < 10K WPS 級別、PostgreSQL 自管或 RDS 通常夠
• 流量更高、考慮 Aurora（同 wire protocol、storage 升級）

不適用場景

1. 極高寫入吞吐（單機 > 50K WPS）：

• 必須進入 database sharding 或分散式 SQL
• 替代：CockroachDB、TiDB、Spanner、應用層 sharding

2. 全球 multi-region active-active write：

• PostgreSQL 是 single primary、不支援 multi-region active-active
• 替代：Aurora DSQL、Spanner、CockroachDB multi-region

3. KV 簡單查詢 + sub-10ms p99：

• PostgreSQL connection 開銷 + parsing + planning 已經 1-3ms
• KV-pattern workload 用 DynamoDB / Redis / Cosmos DB 更便宜更快

4. 大規模 OLAP：

• PostgreSQL 定位在 OLTP，analytics workload 交給 OLAP 系統
• 大數據分析用 ClickHouse / BigQuery / Snowflake / Redshift / Synapse

5. 連線量極大 SaaS（每個用戶一個 connection）：

• 即使有 pgBouncer、超大連線量仍是 PostgreSQL 結構性限制
• 對應 9.C29 Lemino 案例 — 流量上升 connection 爆是換 DynamoDB 的主因

跟其他 vendor 的取捨

vs MySQL：

• PostgreSQL：SQL 特性深、JSON / GIS / window 完整、replication 較簡單但 lag 較大
• MySQL：簡單 query 效能好、replication 機制成熟、Vitess 分片生態強
• 選 PostgreSQL：需要進階 SQL、複雜 query、JSON workload
• 選 MySQL：高併發簡單 query、需要 sharding、已用 MySQL 生態

vs Aurora（同 PostgreSQL wire protocol）：

• PostgreSQL：自管 / RDS、特性接近 upstream、跨雲可用
• Aurora：AWS managed、storage / compute 分離、更多 read replica
• 選 PostgreSQL：跨雲、想最新特性、預算敏感
• 選 Aurora：AWS 生態、需要更快 failover + 更多 read replica
• 詳見 Aurora vendor page

vs CockroachDB（PostgreSQL wire protocol 相容）：

• PostgreSQL：single-primary OLTP、SQL 特性完整
• CockroachDB：multi-region 強一致 SQL、PostgreSQL wire 相容但部分特性缺
• 選 PostgreSQL：single-region 或 read replica 跨 region 夠
• 選 CockroachDB：必須 multi-region active-active write
• 詳見 1.11 全球分散式 OLTP

vs Spanner / Aurora DSQL（全球分散式 SQL）：

• PostgreSQL：傳統設計、跨 region 是 async replication
• Spanner / Aurora DSQL：全球線性化、跨 region 強一致
• 選 PostgreSQL：90% 場景夠用、便宜、容易
• 選 Spanner / Aurora DSQL：金融交易、ticketing inventory、必須全球強一致

vs DynamoDB：

• 詳見 1.10 KV / Document DB 容量規劃 的 connection model 對比段

vs Neon（PostgreSQL serverless）：

• PostgreSQL：standard、自管或 RDS
• Neon：branch-based、scale-to-zero、適合 dev / preview environment
• 選 Neon：dev / preview、稀疏 workload、CI 用
• 選 PostgreSQL：production sustained workload

容量規劃要點

1. Connection pool 必須有：

• 直接連 1000+ connection 會壓垮 PostgreSQL
• pgBouncer（最簡單、transaction pooling）
• PgCat（rust 寫的進階替代、支援 sharding）
• application 層 pool（HikariCP、SQLAlchemy pool）
• 通常組合使用：application pool 30-50 connection × 多 instance → pgBouncer 共享 → PostgreSQL 200 connection
• 對應 Connection Pool 卡片

2. Replication 配置：

• streaming replication：async / sync / quorum
• 跨 AZ async：lag 通常 < 100ms、failover 1-2 分鐘
• 跨 AZ sync：lag 接近 0、但寫入要等 standby ack、會降寫吞吐
• 跨 region 通常 async
• HA 工具：Patroni（最常見）、pg_auto_failover、Stolon

3. Vacuum 跟 bloat 治理：

• PostgreSQL MVCC 會留下 dead tuples、必須 vacuum
• autovacuum 配置：throttle 大表、避免在 peak 跑
• bloat 監控：pg_stat_user_tables 看 dead_tup ratio
• 大表 vacuum 可能要 hours、影響 maintenance window

4. 大表 partitioning：

• 單表 > 1 TB 建議 partition（按時間、按 tenant）
• partition pruning 讓 query 只掃需要的 partition
• partition 限制：cross-partition unique constraint、跨 partition join 較慢

5. Index 策略：

• 預設 B-tree、適合大多數 query
• partial index 對 boolean / status column 特別有用
• GIN / GiST 對 JSON / full-text / GIS
• index 太多會拖累寫入、定期 review 未用 index（pg_stat_user_indexes）

安全、DR 與角色分工

PostgreSQL 的 production 完整性不只來自 SQL 特性，也來自資料存取、備份復原、升級責任與事故證據的分工。這一段補上 PG baseline 原本留在 limitation 的三個缺口：Security / RLS / audit logging、cross-region DR、application developer vs DBA / SRE 視角。

Access control / RLS 的判讀重點是把資料責任放在資料層與 application 層之間分工。PostgreSQL 支援 role、grant、schema、function security 與 row-level security；但 RLS 會把授權邏輯拉進 database，適合 multi-tenant row isolation、資料平台或共享 reporting schema，日常 OLTP 仍要保留 application authorization 與 audit trail。

TLS / credential 的判讀重點是連線安全與憑證生命週期。Self-managed PostgreSQL 要處理 server cert、client cert、DB user rotation 與 connection pool 重連；managed PostgreSQL 常把 certificate、IAM auth 或 secret integration 交給平台，但 application pool、migration tool 與 read replica 仍要一起更新。

Cross-region DR 的判讀重點是 RPO / RTO 與資料一致性。自管 PostgreSQL 可用 streaming replication、WAL archiving、PITR 與 Patroni 做 region failover；Aurora 把 backup、PITR 與 Global Database 交給 AWS；真正 active-active 或 global strong consistency 需求要回到 CockroachDB、Spanner 或 Aurora DSQL，single-primary PostgreSQL 保留為 region failover 與 async DR 路線。

Developer / DBA split 的判讀重點是把日常責任寫進流程。Application developer 擁有 query shape、transaction boundary、repository adapter 與 migration contract；DBA / SRE 擁有 backup、replication、pooler、extension、vacuum、index maintenance 與 DR drill；release gate 需要把兩邊 evidence 合在同一份 decision log。

Managed PG 與相容變體路由

PostgreSQL wire protocol 已成為 managed SQL 與 distributed SQL 的相容目標。選型時要區分「PostgreSQL 本體」、「managed PostgreSQL」、「PostgreSQL-compatible distributed SQL」與「PostgreSQL extension ecosystem」四種不同責任。

Managed PG 變體的引用規則是先查 compatibility，再談 migration。Extension whitelist、backup / restore API、logical replication 支援、connection endpoint 行為與 pricing 都是時間敏感 claim；實作前要回到官方文件確認版本，並把確認日期留在 migration plan 或 decision log。

Deep article + Migration playbook（已完成）

補充正文路由

當前 deep article、migration playbook、補充正文與 hands-on 已 cover replication / HA / OSC / connection / CDC / sharding / multi-master / MVCC / query opt / index / partitioning / JSONB / FTS / extension（含 TimescaleDB / pgvector / PostGIS）/ backup / slot / SQL features / upgrade / migration / security / DR / managed variant 等維度。下列補充正文用來承接 overview 中提到的延伸議題：

• Logical decoding plugins deep dive：wal2json / pgoutput / decoderbufs 對位、CDC pipeline 整合
• pg_partman advanced：retention 跟 child partition 自動 management
• Connection pooler comparison：PgBouncer vs Pgcat vs Odyssey 細部對比
• Aurora I/O-Optimized vs standard：cost model 取捨
• AlloyDB / Cloud SQL 比較：GCP managed PG 選型

上述補充篇已完成正文，並保留既有引用路徑。Logical decoding 接 Logical Replication + Debezium 與 Replication Slot Management；pg_partman advanced 接 Declarative Partitioning；pooler comparison 接 Connection Scaling 與 pgBouncer Config；Aurora cost 接 → Aurora；AlloyDB / Cloud SQL 接 Managed PG Comparison。

案例對照

PostgreSQL 沒有直接的 09 case（多數 09 case 用 managed vendor）、但作為 baseline 跟遷移源頭 在許多 case 出現：

已知 Limitation 與 Audit 紀錄

本 vendor 頁的 22 篇 deep article + 6 篇 migration playbook 經過 4-reviewer audit（A 寫作規範 / B 跨檔一致性 / C 技術準確性 / D 框架偏誤）、Phase 1-3 修法完成。承認以下 limitation：

• PG narrative bias：pgvector / TimescaleDB / extension-ecosystem / Citus 四篇對「PG 取代專業 DB」描述偏 PG-favoring；對手 vendor（Pinecone / InfluxDB / Vitess）的優勢段相對簡短。讀者選型時、請以 cost / ops / scale 三軸綜合判斷、不依本 vendor 頁單一視角。
• Anti-recommendation 深度不一：bdr-multi-master / extension-ecosystem 有「99% 不需要」明確邊界、其他篇章邊界較柔（如「Vector 量 > 5-20M」是粗略門檻）。實際 production 決策請參考多 vendor 對照 + 自家 workload 量測。
• Sibling cross-link 狀態：MySQL ↔ PG sibling、PG 既有 ↔ 新章節 cross-link 已補（refer #136 卡）；本輪同步補 Aurora / CockroachDB / Spanner / Cosmos DB / DynamoDB vendor 頁的反向 sibling 路由，剩餘精修可在各 migration playbook 補更細的 step-by-step 對照。
• 時間敏感 vendor claim：Aurora DSQL（2024-12 preview / 2025-05 GA）/ pgvector（0.8 iterative scan）/ TimescaleDB version matrix / DSQL extension 支援範圍持續演進、本 vendor 頁以 2025-2026 公開狀態為準、實作前請以 vendor 官方 docs 為準（refer #137 卡）。
• 補充維度已正文化：Security / RLS / audit logging、cross-region DR、application developer vs DBA 視角分工、YugabyteDB / TiDB migration playbook、specialized PG variants 已補成正文。本輪也補上跨 vendor 反向連結與時間敏感 claim 路由；下一輪可集中在 migration playbook 的操作步驟與 lab 化。

詳細 audit findings 跟修法見 #136 Sibling Vendor Cross-Link Bidirectionality / #137 Vendor Feature 時間敏感性 / #138 Cross-Reviewer Convergence。

常見陷阱

• connection 沒 pool 直接連：1000 application instance × 30 connection = 30K connection、PostgreSQL 撐不住
• 沒 vacuum 治理：dead tuple 累積、table bloat、query 變慢
• 大表沒 partition：> 1 TB 單表的 vacuum / index rebuild 變成事故
• index 不 review：寫吞吐被舊 index 拖垮
• 跨 AZ sync replication 給寫入吞吐高的 workload：每次 commit 等 standby ack、寫吞吐減半
• logical replication 拖太多 publication：可能造成 primary WAL 堆積、disk 爆

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：MySQL vendor、Aurora vendor（managed PostgreSQL）
• 操作：PostgreSQL Hands-on（local lab、pool、PITR、migration evidence、HA drill）
• 上游：1.1 高併發資料存取、1.3 Transaction Boundary
• 下游：1.10 KV / Document DB 容量規劃（PostgreSQL 不適用時的替代）/ 1.11 全球分散式 OLTP（PostgreSQL 不夠用時的升級路徑）
• 跨模組：9.5 瓶頸定位流程 — connection / replication lag / vacuum 都是 PostgreSQL 常見 bottleneck 源
• 官方：PostgreSQL Documentation

壓測理論的角色是讓「加機器能不能解決」這個問題從直覺變成可推導。沒有理論基礎時、容量決策容易陷入「跑壓測 → 看數字 → 加機器」的盲試循環；有理論之後、可以從「現在的延遲 / 吞吐 / 並發量」反推「瓶頸在哪個資源、加什麼有效」。

本章是 9.2-9.12 的共同基礎。後續章節的 workload modeling、saturation discovery、capacity planning、SLO 都會回引本章的數學工具。讀者可以把這章當作「容量規劃的最小詞彙表」、其他章節是這些詞彙的應用情境。

本章不深入推導公式、聚焦在 工程意義。讀完之後讀者能回答：為什麼系統在 80% utilization 就該擴、為什麼加機器會邊際效益遞減、為什麼 sub-ms 延遲需求會反推架構選擇。

Little’s Law：穩態系統的最小數學工具

Little’s Law 用一條等式 L = λW 把三個變數綁在一起：L 是系統內平均並發數、λ 是請求到達率、W 是請求平均逗留時間。這個關係在 穩態（流量已穩定、不在 warmup 階段）必然成立、不需要假設特定分布或服務模式。

工程上最有價值的用法是「反推」。給定預期 RPS λ = 1000 跟 SLO latency 上限 W = 200ms、能算出系統最大穩態並發 L = 1000 × 0.2 = 200。這個 200 直接對應「connection pool size」「thread pool size」「async worker count」這類容量參數 — 訂得比 200 小、系統撐不住預期流量；訂得比 200 大太多、資源浪費。

反向也成立。當 connection pool 卡死在某個 size L、latency budget W 已訂、能算出可支撐的 RPS。這個算法在 capacity planning 階段比 ramp-up 壓測更快、可以先用 Little’s Law 篩掉明顯撐不住的配置、再用壓測驗證剩下的候選。

對應案例：Coinbase sub-ms 把 W 訂在 sub-millisecond、所有架構選擇都從這個 W 反推；Tubi ML p99 < 10ms 從 W 反推 feature lookup 必須 cache hit 路徑、不能回到持久 store。

詳見 Little’s Law 卡片。

Queueing Theory：為什麼 80% 利用率就是 knee

排隊論（M/M/c 模型）解釋了一個常見直覺：「系統在 50% utilization 看似還很閒、80% 就該擴、90% 已經太晚」。這個直覺不是經驗法則、是 數學必然。

M/M/c 系統的平均 queue length 跟 utilization 之間是非線性關係。當 utilization 從 50% 漲到 70%、queue length 約增加 2-3 倍；從 70% 漲到 90%、queue length 增加 10 倍以上。latency 跟 queue length 成正比（Little’s Law 又出現）、所以 latency 也呈現同樣的指數成長。

工程意義：健康系統運轉在 50-70% utilization、超過 80% 就接近 knee、超過 90% 進入不可預測區。「為什麼明明還沒滿就 saturate」的答案就在這條曲線。autoscaler 的 target metric 通常訂在 60-70%、是 queueing theory 推導出的安全邊界、不是工程師憑感覺。

多 server 模型（M/M/c）比單 server（M/M/1）有顯著容量優勢：c 個 server 的有效容量遠超 1 個 server 容量 × c。這也解釋了為什麼水平擴容（多開幾個 instance）通常比垂直擴容（單機加 CPU）划算 — 不只是規模、是 queue 行為的本質差異。

對應案例：GR8 Tech 25ms p95 把 p95 維持在 25ms 同時撐 54K TPS、靠的是 永遠不讓系統進入 knee、AI 預測讓擴容窗口縮短到 reaction time 內。

Universal Scalability Law：擴容會邊際失效

USL（Neil Gunther 提出）的公式 throughput(N) = N / (1 + α(N-1) + βN(N-1)) 解釋了「為什麼加機器到某個點之後 throughput 反而下降」。兩個常數 α 跟 β 描述系統的擴展限制：

• α 是必須序列化的部分（Amdahl’s Law 的對應）。distributed lock、coordinator、單一 leader DB 都是 α 來源。α 越大、線性擴容越早 plateau。
• β 是節點間互相通訊的成本（crosstalk）。cache invalidation broadcast、consensus quorum、cross-region replication 都是 β。β 比 α 更危險、會讓 throughput 在 N 大到某點後 反向下降。

工程上 α 比較好處理 — 把序列化部分拆細、用 partition 切分、用 sharded coordinator。β 比較難 — 通訊本質就需要協調、降低 β 通常要重新設計分散式協議（例如 Spanner 用 TrueTime 把跨節點交易的協調成本降低）。

對應案例：Spanner 線性擴展到 10 億 req/sec — TrueTime API 讓跨地區交易的 β 降到可接受、達成傳統 OLTP 做不到的線性；Coinbase RAFT consensus — RAFT 的 quorum 通訊讓 β 不可降、所以 選擇不橫向擴、改用 z1d + Cluster Placement Group 榨單機。

詳見 USL 卡片。

Saturation Curve：linear → knee → cliff

實際系統的 latency vs throughput 曲線分三段。第一段是 linear region — utilization 低、latency 平穩、加流量幾乎不影響 latency。第二段是 knee — utilization 接近 80%、latency 開始指數成長、再加流量會明顯變慢。第三段是 cliff — 系統進入不穩定區、latency 不可預測、可能 timeout、可能 cascade failure。

容量規劃的關鍵概念是 knee point = 設計容量上限。健康系統運轉在 knee 以下 50-70%、留出 headroom 應付 burst 跟 forecast 誤差。沒有量過 knee 的系統等於「不知道距離崩潰多遠」 — 平日看起來穩、實際隨時可能因為一個小 spike 進入 cliff。

不同 system 的 knee 位置差異很大。stateless service 通常 knee 在 80% CPU；DB 因為 lock contention、knee 可能在 60% utilization；broker / queue 因為 disk I/O bottleneck、knee 可能在 50%。容量規劃時不能一概而論、必須個別量測。

每次重大改動後必須 re-test knee。新增功能、改 ORM、升級 library、調 GC tuning、改 cache 策略 — 任何一個都可能讓 knee 往不好的方向移。

對應案例：Tixcraft DynamoDB IOPS 20 → 135K — partition 設計均勻時 saturation point 可以推到極遠（6750x 擴展）；Amazon Ads 9000 萬 RPS — 線性擴展靠 partition key 均勻、不靠 vendor 神話。

詳見 Saturation Point 卡片。

反推：從業務 KPI 到系統參數

理論工具的真正價值在「反推」 — 不是先設計系統再量測 saturate 多少、是 先訂業務目標再反推系統參數。這層思維把容量規劃從 reactive（撐到撐不住才擴）變成 proactive（按業務需求預先配置）。

反推流程通常從 latency budget 開始（詳見 9.12 SLO 與 Performance Budget）：

1. 從 user-perceived end-to-end latency（例如 p99 500ms）開始
2. 拆到每個 stage（網路、CDN、application、cache、DB、第三方）的 latency 配額
3. 配額決定每個 stage 的設計選擇 — DB 配 50ms → 不能跨 region、application 配 100ms → 不能多層 microservice hop
4. 配額 + 預期 RPS → Little’s Law 算每個 stage 的並發
5. 並發 → 每個 stage 的容量需求 → 實例數 / connection pool size / cache size

反推失敗的常見徵兆：算出來的某個 stage 容量超過 vendor 提供的上限（例如「需要 50 萬 DynamoDB RCU」可能超過單一 table partition 上限）、或某個 stage latency 配額過短（例如 cross-AZ 網路至少 1-2ms、配 0.5ms 不可能達成）。這時要回頭調整 SLO 或重新設計架構。

詳見 Latency Budget 卡片。

案例對照

下一步路由

• 下游：9.2 Workload Modeling（把模型量化成 production traffic）
• 下游：9.4 Saturation Discovery（實測 knee point）
• 跨章節：9.12 SLO 與 Performance Budget（latency budget 拆解）

既建知識卡片

• Little’s Law
• Universal Scalability Law
• Saturation Point
• Latency Budget
• Tail Latency

觀察

2025 年 Prime Day 期間 AWS 主要服務的峰值數字（引自 AWS News Blog）：

基礎設施層面：AWS Graviton 處理器承擔超過 40% 的 EC2 compute、部署超過 87,000 顆 Inferentia / Trainium AI 晶片、AWS Outposts 對機器人下達 5.24 億條指令（年增 160%）。

判讀

Prime Day 是「可預期極端峰值」的標竿。它的容量問題不是「會不會撐住」、而是「準備到什麼程度才划算」。對應主章問題節點：

1. Capacity Planning（9.6）：年度活動的容量計算可以用歷史 baseline × 預期成長 × headroom 三項相乘、但 Prime Day 規模下、每一項的不確定性放大都會變成數百萬美金成本差異。Amazon 公開的年增率（API Gateway +30%、CloudFront +43%、ECS on Fargate +77%）顯示連 Amazon 自己每年的成長預測都不能直線外推。
2. Performance Observability（9.8）：DynamoDB 「1.51 億 RPS、毫秒級回應」這種敘述同時包含吞吐與延遲、是 production-grade 容量地圖的最小單位。只說吞吐不說延伸分布、容量資訊不完整。
3. Improvement Loop（9.9）：FIS 混沌實驗 8 倍於 2024 顯示 Amazon 把「在 Prime Day 之前主動製造失敗」當成必修課、不是事後檢討。這層投資跟容量規劃同等重要。

策略

這個案例可以抽出三個跨平台可重用的工程做法。

1. 把可預期峰值寫進服務級 SLO：Prime Day 在 SQS / Lambda / DynamoDB / Aurora 都建立了內部 SLO baseline、平日跑在 baseline 之下、峰值是擴張到「設計容量」而不是「實驗容量」。這跟 9.12 SLO 與 Performance Budget 直接對齊。
2. pre-scaling + scheduled capacity：CloudFront 43%、API Gateway 30% 的年增率都是 提前算進 容量計畫、不是當天 reactive 擴容。對應 EC2 Auto Scaling 的 predictive / scheduled scaling 模式。
3. 事前主動製造失敗、不靠當天 reactive：FIS 8x 成長代表「在 Prime Day 之前 6800 次 chaos test」、把驗證成本前置到容量規劃階段。這條跟 06.4 Chaos Testing 形成閉環 — 06 講失敗模式驗證、09 講容量地圖、兩者在 Prime Day 級別的事件上必須一起做。

跨平台等效：GCP 的 Compute Engine MIG + Predictive Autoscaler、Azure 的 VM Scale Sets + Predictive Autoscale、Kubernetes 生態的 KEDA + Karpenter 都可以實作同樣的 pre-scaling 策略。差異是 vendor 整合度、不是工程概念。

下一步路由

• 想規劃年度活動容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備
• 想設計可預期峰值的 SLO → 9.12 SLO 與 Performance Budget + 06.6 SLO 與 Error Budget 政策
• 想做事前混沌驗證 → 06.4 Chaos Testing + 06.22 Steady State Definition
• 對照不同形狀的峰值 → 9.C2 GR8 Tech（事件型不可預期峰值）/ 9.C3 Coinbase（無峰值低延遲）

引用源

• AWS services scale to new heights for Prime Day 2025: key metrics and milestones
• Conquering Peak Retail Events with AWS
• Predictive scaling for Amazon EC2 Auto Scaling

觀察

Meta 指出快取在 promotion、shard move、故障恢復時容易引入不一致，單靠傳統 invalidation 很難在大規模系統維持穩定。

判讀

當快取已是核心路徑，資料新鮮度問題會直接變成服務正確性問題。這時候轉換重點是把一致性追蹤與異常定位制度化，改一個 TTL 解決不了結構問題。

策略

1. 先定義 inconsistency 來源點與觀測點。
2. 將 mutation tracing 納入治理，而不是只看命中率。
3. 把一致性指標接到告警與回退條件。

下一步路由

先回 2.2 cache aside 與 2.3 TTL/eviction，再接 4.17 telemetry data quality。

引用源

• Cache made consistent

觀察

FOQS 從區域安裝轉為全域架構，目標是讓災害期間佇列資料仍可被存取，並控制遷移期間的延遲與可用性風險。

判讀

當 queue 成為跨區關鍵路徑，轉換焦點是 discoverability、routing freshness 與 tenant 遷移節奏。

策略

1. 先建立全域路由層，再分批搬遷租戶。
2. 針對 stale routing 做補貨延遲治理。
3. 用零停機遷移策略保留客戶端連續性。

下一步路由

回 3.1 broker basics 與 3.2 durable queue。

引用源

• FOQS disaster-ready migration

觀察

Tradeshift 從 self-hosted Kubernetes 遷移到 Amazon EKS，legacy 叢集上運行 409 個 service。遷移以零停機為硬性前提，且要求對應用程式碼零修改——遷移的複雜度由平台層吸收，服務團隊不改程式碼。

遷移採用 parallel cluster 架構：新舊叢集同時運行，透過 Linkerd service mesh 的 multi-cluster 能力橋接。Linkerd 在新叢集中建立 mirrored service（帶叢集後綴），讓跨叢集服務呼叫對應用層透明。流量切換用 Linkerd 的 traffic splitting policy 分批控制，不需要修改個別服務的路由邏輯。

跨叢集延遲實測：從 EKS 叢集存取 legacy 叢集的 gateway，P50=2ms、P95=8ms、P99=9ms。這個延遲水平足以支撐遷移期的跨叢集服務呼叫，但對延遲敏感的路徑仍需要在同一叢集內完成切換才能消除這層額外延遲。

判讀

這類遷移的難點在跨叢集服務依賴與流量切換，Kubernetes API 相容性反而是最容易處理的部分。Linkerd multi-cluster 在這個案例中解決了三個問題：跨叢集 service discovery（mirrored service 自動同步）、流量分批控制（traffic splitting 不改應用碼）、遷移期 rollback（切回舊叢集只需調整 traffic split 比例）。

409 個 service 的遷移不是一次完成——service 之間有依賴關係，遷移順序要按依賴拓樸規劃。被多個服務依賴的基礎 service（auth、config）通常最後遷移或在兩邊都保留，避免跨叢集呼叫成為所有服務的共同瓶頸。

遷移期最大的隱性風險是「跨叢集延遲累積」。單次跨叢集呼叫 P99=9ms 看似可接受，但一條請求路徑如果串接 5 個跨叢集呼叫，累積延遲可達 45ms。遷移規劃要把服務依賴鏈上的跨叢集呼叫次數納入切換順序考量。

策略

1. 建立 parallel cluster + mesh bridge：新叢集用 EKS 建立，Linkerd multi-cluster 連接新舊叢集，mirrored service 讓跨叢集呼叫透明。
2. 按依賴拓樸排序遷移批次：葉子服務（無下游依賴）先遷，基礎服務最後遷或雙邊保留。每批遷移後驗證跨叢集延遲是否在可接受範圍。
3. Traffic splitting 分批切流量：每個服務遷移後，用 traffic split 從 0% 開始逐步把流量導向新叢集。觀察 per-service error rate 與 latency，確認穩定後提高比例。
4. 保留 rollback 路徑：舊叢集服務不立即下線，traffic split 隨時可切回 100% 舊叢集。rollback 操作是調整 split 比例，不需要重新部署。
5. 遷移完成後拆除 mesh bridge：所有服務切換完成且穩定觀測後，移除跨叢集 Linkerd 連線，舊叢集下線。

可回寫的章節段落

• 5.2 分階段平台遷移：traffic split 的分批切換與回退策略
• 5.4 跨叢集 Discovery：Linkerd mirrored service 是跨叢集 discovery 的 service mesh federation 做法
• 6.8 Release Gate：每批切換的放行條件與停損訊號

引用源

• Tradeshift migration to EKS without downtime using Linkerd

觀察

Cloudflare 在 2026-01-22 發生 route leak，成因是自動化路由政策配置錯誤，導致流量擁塞與延遲提升。

判讀

控制面自動化帶來速度，也提高錯誤一次性放大的風險。關鍵是補強變更守門與回復策略，停止自動化會退回更差的狀態。

策略

1. 路由政策變更要有 pre-check 與 blast radius 評估。
2. 建立快速撤回機制與明確責任路由。
3. 把同類事件寫入 tripwire，觸發強制重評估。

下一步路由

回 7.14 governance exception/tripwire 與 8.3 containment/recovery。

引用源

• Cloudflare route leak incident (2026-01-23)

事故摘要

Atlassian 官方 PIR 指出，2022-04-05 起有 775 客戶受影響，部分恢復歷時長達 14 天。事故起因是維運腳本使用了錯誤識別資訊，導致站點被刪除，後續需要多工作流並行恢復與驗證。

事件特徵是「影響客戶數有限，但每一個客戶的恢復成本高」，因此恢復策略必須分批與分層。

判讀訊號

事故路徑

1. 維運腳本操作錯誤導致多租戶站點被刪除。
2. 客戶無法存取產品並建立支援事件。
3. 事故升級後成立跨職能指揮團隊，24x7 推進恢復。
4. 恢復以分批方式進行，並持續更新 status 與客戶通訊。
5. 事後回寫到 soft delete、恢復自動化與通訊流程改善。

可回寫控制面

下一步路由

• 事故通訊： 8.4 Incident Communication
• 客戶影響評估： 8.20 Customer Impact Assessment
• 事中決策紀錄： 8.19 Incident Decision Log
• 證據回寫流程： 8.22 Incident Evidence Write-back
• 穩態與恢復完成： 6.22 Steady State Definition

引用源

• Post-Incident Review on the Atlassian April 2022 outage
• Update on the Atlassian outage affecting some customers

事故摘要

AWS 在 2017-02-28 發生 Amazon S3 Northern Virginia（US-EAST-1）服務中斷。官方摘要指出，S3 團隊當時正在排查 billing system 進度偏慢問題；9:37AM PST，一位授權 S3 團隊成員依既有 playbook 執行命令，原本只要移除少量 billing 相關子系統 server，但其中一個輸入值錯誤，導致移除的 server set 比預期大。

被移除的 server 同時支援 S3 的 index subsystem 與 placement subsystem。index subsystem 管理該 region 內所有 S3 object 的 metadata 與位置資訊，GET、LIST、PUT、DELETE 都依賴它；placement subsystem 負責新 object 的 storage allocation，PUT 還需要它才能運作。這兩個子系統被迫完整重啟，導致 S3 API 在重啟期間無法正常服務。

判讀訊號

事故路徑

1. S3 團隊排查 billing system 進度偏慢問題。
2. 授權成員依既有 playbook 執行移除少量 server 的操作命令。
3. 命令輸入值錯誤，移除的 server set 比預期大。
4. 被移除容量同時支援 index subsystem 與 placement subsystem。
5. 兩個子系統需要完整重啟，S3 API 在重啟期間無法正常服務。
6. 依賴 S3 的其他 AWS 服務在 US-EAST-1 同步受影響。
7. AWS 先用 AWS Twitter feed 與 Service Health Dashboard banner text 溝通，直到 SHD individual service status 可以更新。
8. index subsystem 先恢復足夠容量，再逐步恢復 GET / LIST / DELETE；placement subsystem 完成後，PUT 才恢復正常。

這條路徑顯示：事故起點是內部操作工具缺少數量與容量下限保護，外部流量尖峰在此無關。真正放大事故的是共享子系統、區域依賴與通訊入口對同一服務的依賴。

可回寫控制面

下一步路由

• 觀測證據包： 4.20 Observability Evidence Package
• 實驗安全邊界： 6.20 Experiment Safety Boundary
• 穩態與恢復完成： 6.22 Steady State Definition
• 事故通訊： 8.4 Incident Communication
• 止血與回復： 8.3 Containment / Recovery Strategy
• 事中決策紀錄： 8.19 Incident Decision Log
• 證據回寫流程： 8.22 Incident Evidence Write-back

引用源

• Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region

事故摘要

Cloudflare 在 2019-07-02 發布新的 WAF Managed Rule 後，規則中的 regex 觸發 catastrophic backtracking，導致 edge CPU 快速打滿。事故影響約 27 分鐘，症狀是大量 502/503 與延遲激增。

這起事件屬於典型「控制面配置推送 → data plane 全網受影響」模式。錯誤並非單點節點故障，而是由一致推送機制把同一錯誤同步擴散到整個 edge 網路。

判讀訊號

事故路徑

1. 控制面推送新 WAF 規則到全球 edge。
2. 規則 regex 在特定輸入下產生高計算成本。
3. edge CPU 被規則執行成本吃滿，請求處理能力下降。
4. 5xx 與延遲擴散成全球可見症狀。
5. 回滾規則後，CPU 與可用性逐步恢復。

這條路徑顯示：事故擴散速度主要由「推送覆蓋範圍」決定，而不是由「單機故障率」決定。

可回寫控制面

下一步路由

• 回寫訊號治理： 4.17 Telemetry Data Quality
• 回寫規則成本訊號： 4.21 Rule-level CPU Signal Governance
• 回寫規則推送閘門： 6.24 Rule Rollout Safety Gate
• 回寫驗證與安全邊界： 6.20 Experiment Safety Boundary
• 回寫事中決策與證據： 8.19 Incident Decision Log
• 回寫跨模組閉環： 8.22 Incident Evidence Write-back

引用源

• Details of the Cloudflare outage on July 2, 2019

事故摘要

Fastly 官方摘要指出，2021-06-08 的全球 outage 由平台既有軟體 bug 觸發，觸發條件來自一個有效的客戶配置變更。故障在短時間內影響大範圍 edge 節點，並在隔離配置後逐步恢復。

這類事故不是「客戶配置錯誤」或「平台單點故障」的二選一，而是配置與平台行為交互下的系統性風險。

判讀訊號

事故路徑

1. 平台先前部署引入可被特定條件觸發的 bug。
2. 客戶推送有效配置，觸發 bug。
3. 大範圍 edge 節點回應錯誤，形成全球 outage。
4. 團隊定位並隔離觸發配置，服務逐步恢復。
5. 事後回寫驗證、隔離與恢復流程。

可回寫控制面

下一步路由

• 規則/配置成本訊號： 4.21 Rule-level CPU Signal Governance
• 證據包： 4.20 Observability Evidence Package
• 規則推送閘門： 6.24 Rule Rollout Safety Gate
• 事故通訊： 8.4 Incident Communication
• 證據回寫流程： 8.22 Incident Evidence Write-back

引用源

• Summary of June 8 outage

判讀訊號

風險與邊界

把合規當成部署後補強會抬高長期成本。較穩定的做法是在選型時就定義證據鏈、資料邊界與回復順序，避免後續跨模組反覆返工。

下一步路由

先補 4.12 的審計訊號，再用 6.8 定義合規變更門檻。

業務背景

一家處理線上支付的金融科技公司，每日交易量約 200 萬筆，涵蓋信用卡收單、轉帳與退款。每季有外部稽核查核交易處理的完整性與存取控制，事故發生時法務需要在 48 小時內提供特定交易的完整處理鏈證據。

初期系統把所有 log 寫到同一個 log group — application debug、request trace、交易狀態變更與使用者存取紀錄全混在一起。稽核人員要從數 TB 的 log 中撈出特定交易的完整軌跡，每次查詢耗時數小時。

技術挑戰

Operational log 與 audit log 混合

Application log 記錄 debug 資訊（SQL timing、cache hit/miss、retry），audit log 記錄業務事件（交易建立、狀態變更、存取紀錄）。兩者混在同一個 pipeline 時，retention 策略互相衝突 — debug log 留 14 天夠用，但 audit log 法規要求保留 5 年。統一設成 5 年讓儲存成本暴增，統一設成 14 天則遺失合規證據。

PII 暴露在 log 中

早期 log 直接印出 request body，信用卡號跟身分證字號散落在各種 log entry。稽核指出 PII 在 log 系統中的暴露面超過業務需要，但 log 已經寫入後無法回溯修改。

Event correlation 斷裂

交易從建立到完成經過多個服務（checkout-api → payment-gateway → settlement → notification），但各服務的 log 使用不同的 correlation key。Checkout 用 order_id，payment-gateway 用 payment_ref，settlement 用自己的 batch_id。稽核要求「給我交易 X 的完整處理鏈」時，工程師需要手動在三個系統各自查詢再人工拼接。

解法

Audit log 分離

把 audit event 獨立到專屬 pipeline：交易狀態變更、使用者存取、權限變動、退款操作各自產生結構化 audit event，寫入 immutable storage（append-only、禁止刪除與修改）。Operational log 維持 14 天 retention，audit log 走 5 年 retention + cold archive。

分離的判準是「這筆紀錄是否可能被稽核或法務要求提供」。是 → audit pipeline；否 → operational pipeline。灰色地帶（例如認證失敗 log）歸入 audit pipeline — 寧可多留不可少留。

PII redaction pipeline

在 log ingestion 階段加入 redaction processor：信用卡號遮罩為末四碼、身分證字號完全移除、email 保留 domain 遮罩使用者名稱。Redaction 發生在寫入儲存之前，原始資料不落地。

需要完整 PII 的場景（如詐欺調查）走另一條授權存取管道，跟觀測 pipeline 分離。

統一 correlation key

所有服務在交易入口處產生 trace_id 和 transaction_id，兩個 key 同時寫入每一筆 audit event 和 operational log。稽核查詢用 transaction_id 就能撈出跨服務的完整處理鏈，不需要手動拼接。

取捨

分離 pipeline 的最大成本在 routing 規則的維護 — 新服務上線時要確認 audit event 走對 pipeline。解法是在 SDK 層提供 emit_audit_event() 函式，讓 routing 在 producer 端決定，不依賴下游 pipeline 的內容判斷。

回寫教材的連結

• 4.12 Audit Log Governance：audit log 分離的設計原則與 PII 治理。
• 4.20 Observability Evidence Package：把 audit trail 包成可交接的 evidence package。
• 4.18 Observability Operating Model：audit pipeline 的 ownership 歸 platform team 還是 compliance team。
• 4.3 Tracing Context：跨服務 correlation key 的 propagation 設計。

判讀徵兆

讀者在自己的系統看到以下訊號時，應該回讀本案例：

• 稽核或法務要求提供某筆交易的完整處理鏈，工程師需要超過 1 小時才能拼出來
• Log retention 設定跟法規要求不一致，但沒人確切知道差多少
• PII 出現在 log search 結果中，但沒有系統性的遮罩機制
• Application log 跟 audit log 用同一套 retention policy，儲存成本持續上升但沒人敢縮短
• 事故後法務要證據，發現關鍵時段的 log 已經因為 retention 過期而被刪除

事故摘要

Google Cloud 在 2019-06-02 發生美國多區域 network congestion，官方摘要指出多個 US region 出現 elevated packet loss，影響持續約 3 至 4 小時以上，並牽動多個 GCP 與非 Cloud 服務。

這類事故本質是共享網路資源退化造成的跨產品連鎖事件，單一服務壞掉反而好處理。

判讀訊號

事故路徑

1. 美國多區域網路容量在高壓下出現壅塞與丟包。
2. 多個 GCP 產品受同一網路瓶頸影響，出現延遲與錯誤。
3. 工程團隊進行流量與容量調整，逐區域回復。
4. 狀態頁持續更新受影響範圍與恢復進度。
5. 事後回寫區域隔離、容量保留與跨產品協調流程。

可回寫控制面

下一步路由

• 觀測證據包： 4.20 Observability Evidence Package
• 事故通訊： 8.4 Incident Communication
• 事中決策紀錄： 8.19 Incident Decision Log
• 證據回寫流程： 8.22 Incident Evidence Write-back
• 實驗安全邊界： 6.20 Experiment Safety Boundary

引用源

• Google Cloud Networking Incident #19009
• An update on Sunday’s service disruption

事故摘要

GitHub 在 2018-10-21 22:52 UTC 因例行網路設備維護引發 network partition，導致跨區 MySQL replication topology 進入異常狀態。應用層在切換後持續寫入新主站，形成跨區未對齊寫入，事故最終歷時約 24 小時 11 分鐘。

官方 post-incident analysis 指出，團隊選擇 fail-forward，而不是直接切回原主站，原因是要優先保護資料完整性，避免產生更大不一致。

判讀訊號

事故路徑

1. 例行網路設備維護造成 East 與主資料中心連線中斷。
2. Orchestrator 在 partition 下進行主從重新選舉與切換。
3. 連線恢復後，應用寫入已落在新主站，形成跨站寫入差異。
4. 團隊凍結部署並轉人工處理拓撲與一致性風險。
5. 選擇 fail-forward，逐步恢復服務與處理 backlog。
6. 事故結束後回寫跨資料中心設計、通訊粒度與演練策略。

可回寫控制面

下一步路由

• 事故通訊： 8.4 Incident Communication
• 止血與回復： 8.3 Containment / Recovery Strategy
• 事中決策紀錄： 8.19 Incident Decision Log
• 證據回寫流程： 8.22 Incident Evidence Write-back
• 資料庫轉換實作： 1.6 資料庫轉換實作
• Migration rollout evidence： 1.7 Schema Migration Rollout 證據
• 選型決策層： 0.C4 營運後技術轉換
• 穩態與恢復完成： 6.22 Steady State Definition

引用源

• October 21 post-incident analysis
• October 21 Incident Report

事故摘要

Roblox 在 2021-10-28 至 2021-10-31 經歷長時間服務中斷。官方更新指出問題來自內部系統在高負載下的細微通訊 bug 與連鎖壓力，不是外部攻擊或流量尖峰事件。

這類 prolonged outage 的特徵是：初期根因不明、修復需分階段、恢復後仍有長尾調整。

判讀訊號

事故路徑

1. 平台在高負載場景下出現核心基礎設施壓力失衡。
2. 使用者面大量失敗，服務不可用。
3. 團隊跨功能長時間排查、逐步恢復基礎能力。
4. 恢復後持續做長尾穩定化與後續結構改善。

可回寫控制面

下一步路由

• 止血與回復： 8.3 Containment / Recovery Strategy
• 事故通訊： 8.4 Incident Communication
• 長事故交班： 8.12 IC Handoff
• 證據回寫流程： 8.22 Incident Evidence Write-back
• 穩態與恢復完成： 6.22 Steady State Definition

引用源

• An Update on Our Outage
• Roblox Return to Service

規劃重點

• 區域依賴擴散：S3 us-east-1 失效會牽動 console、IAM、ECR、CloudFormation 等控制面
• Blast radius 範例：subsystem 失效如何意外擴散到看似無關服務
• 控制面 / 資料面分離設計：為何 S3 把兩者拆開、失效時表現差異
• Recovery 節奏：metadata service 重啟為何耗時、為何不能熱重啟

預計收錄事故

案例清單

• 2017 US-EAST-1 Service Disruption
• 2021 US-EAST-1 Control Plane Degradation
• 2023 Control Plane Accountability and Communication Pattern

建議閱讀順序

1. 2017 US-EAST-1 Service Disruption
2. 2021 US-EAST-1 Control Plane Degradation
3. 2023 Control Plane Accountability and Communication Pattern

案例定位

AWS S3 這個案例在講的是區域控制面失效如何透過依賴鏈條放大成多服務事故。讀者先看懂控制面與資料面分離的責任，再把 us-east-1 這類事件當成 blast radius 與恢復節奏的教學範本。

判讀重點

當內部工具誤觸或控制面出現異常時，第一件事是先切開受影響的依賴路徑，擴容在此階段幫助有限。當服務恢復時，metadata service 與下游依賴通常不會同時回穩，所以恢復順序比單純重啟更重要。

可操作判準

• 能否分辨故障落在控制面還是資料面
• 能否指出哪個依賴把事故擴成區域事件
• 能否把恢復順序寫成可執行的 runbook
• 能否在復原後回頭檢查 blast radius 是否被正確限制

與其他案例的關係

AWS S3 是區域控制面事故的基準頁，和 Cloudflare、Fastly、GCP 一起讀時，最能看出「小變更如何變成大擴散」。這頁也能拿來對照 GitHub 與 Azure AD，因為它們同樣在處理共享依賴被一個節點拖垮後的恢復節奏。

代表樣本

• 2017 年 us-east-1 typo 事故顯示單一控制面誤觸可以牽動整個區域。
• 2021 年 us-east-1 多服務退化則示範了控制面與下游服務如何一起受影響。
• 其他公開 PIR 可以拿來對照 AWS 的回顧格式如何隨時間演化。
• S3 的案例也能對照控制面與資料面拆分後的恢復順序。
• metadata service 的恢復節奏常常比使用者看到的 outage 更長。
• region dependency 讓看似獨立的 AWS 服務一起進入失效鏈。
• blast radius 的核心是依賴鏈條被拉長後的擴散，單一服務層面的評估不足以涵蓋。
• post-incident report 的寫法能對照 AWS 如何對外說明與內部修復。

引用源

• Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region：2017 年 S3 us-east-1 事故的官方摘要與時間線。
• Introducing The Amazon Builders’ Library：S3 類事故所屬的大型系統操作與恢復脈絡。
• Workload isolation using shuffle-sharding：補 blast radius 與隔離思路。

本章目標

讀完本章後、你應該能：

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 設計方法與實務語境。

對「多服務多實例 container orchestration、需要 rolling update / blue-green / canary、跨雲 / 跨環境統一抽象」這條路徑、Kubernetes 是首選。

本章目標

讀完本章後、你應該能：

1. 用 kubectl 部署 Deployment + Service、配置 probe / resource limit
2. 設計 rolling update / pod disruption budget 避免服務中斷
3. 選 Ingress controller（nginx / traefik / GLBC / ALB Controller）
4. 看懂 pod stuck / probe fail / OOMKilled / drain timeout 訊號
5. 評估 managed（GKE / EKS / AKS）vs 自管 vs Operator 進階場景

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

 1# 1. 本機跑 kind（需先安裝 kind + docker）
 2kind create cluster --name dev
 3
 4# 2. 部署 Deployment + Service
 5kubectl create deployment nginx --image=nginx:stable-alpine
 6kubectl expose deployment nginx --port=80 --type=ClusterIP
 7
 8# 3. 驗證
 9kubectl get pods,svc,deploy
10kubectl port-forward svc/nginx 8080:80

日常操作與決策形狀

kubectl 核心指令

子議題：

• 資源生命週期：apply / create / delete / get / describe / logs / exec
• Rolling update：set image / rollout status / rollout undo
• Debug：events / port-forward / cp / top
• 對應指令範例：kubectl get pods -A、kubectl describe pod <name>、kubectl logs -f

Workload 設計

Pod lifecycle 是 K8s 的核心抽象。子議題：

• Deployment（stateless）/ StatefulSet（stateful）/ DaemonSet（per-node）/ Job / CronJob
• Pod 多 container（sidecar / init container）
• 對應 5.2 K8s deployment

Probe / Resource limit / QoS

子議題：

• Liveness（活著嗎）/ Readiness（接流量嗎）/ Startup（啟動完了嗎）— 三 probe 各自責任
• Resource limit（requests / limits）+ QoS class（Guaranteed / Burstable / BestEffort）
• 對應 Platform lifecycle contract

進階主題（按需閱讀）

Rolling update / disruption budget

對應案例 5.C9 反例：cutover without drain。子議題：

• maxSurge / maxUnavailable 配置
• PodDisruptionBudget 限制 voluntary disruption
• Preemption / priority class

Ingress / Service mesh integration

子議題：

• Ingress controller 選擇（nginx / Traefik / ALB Controller）
• Gateway API（next gen Ingress）
• Service mesh integration（Envoy-based Istio / Linkerd）
• 對應 5.C7 Airbnb Istio

Operator pattern / CRD

子議題：

• CRD（CustomResourceDefinition）+ Controller 模式
• Operator framework（OperatorSDK / kubebuilder）
• 常見 Operator：Prometheus / Cert-manager / Argo CD

Managed vs self-managed

對應案例 5.C1 Tradeshift self-managed → EKS、5.C2 Condé Nast EKS、5.C3 Orbitera managed K8s、5.C4 Mobileye EKS、5.C5 Miro EKS。子議題：

• Self-managed（kubeadm / Cluster API）的 control plane 維運成本
• Managed（GKE / EKS / AKS）的限制（版本鎖定 / managed addon）
• 遷移路徑跟回退設計

Multi-cluster / Federation

子議題：

• Federation v2 / Cluster API multi-cluster
• Cross-cluster service mesh（Istio multi-cluster）
• 對應 5.C6 Airbnb cluster scaling

Cluster autoscaling

子議題：

• Horizontal Pod Autoscaler / Vertical Pod Autoscaler
• Cluster Autoscaler / Karpenter
• 跟 09 performance capacity 對照

排錯快速判讀

Pod stuck（Pending / CrashLoopBackOff）

操作原則：先 kubectl describe pod 看 events、再 kubectl logs 看 container 訊息。

1kubectl describe pod <name>           # 看 Events 段的 scheduling / pull / probe 訊息
2kubectl logs <name> --previous        # 看 crash 前一輪的 container log

判讀路徑：Pending → resource 不足 / nodeSelector 不匹配；CrashLoopBackOff → exit code + log 找原因。

Probe failure 造成不停 restart

操作原則：probe path / initial delay / timeout 配置錯。判讀：describe pod 看 probe events。

OOMKilled

操作原則：memory limit 太低、container 被殺。判讀：describe pod 看 last state reason。修法：raise limit 或優化 application memory。

Rolling update stuck

對應 5.C9 反例。判讀路徑：新 pod 起不來 → readiness 失敗 → 舊 pod 不下線 → 卡住。

Drain timeout

操作原則：kubectl drain 失敗、PDB 限制太緊。判讀：kubectl describe pdb。

何時改走其他服務

不在本頁內的主題

• 完整 kubectl 指令 reference
• YAML manifest 完整 schema
• 各 Operator 細節
• 各語言 client-go API

案例回寫

直接相關案例

下一步路由

• 上游概念：5.2 K8s deployment
• 平行 vendor：Docker、Envoy
• 下游能力：6 reliability（release gate）、8 incident response

本頁先給最短路徑、再展開日常 instrumentation 跟 Collector 部署、最後進階治理（sampling / semantic conventions / logs 成熟度）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 OTel SDK 或 auto-instrumentation 對應用程式做 instrumentation
2. 配置 OTLP exporter 把 telemetry 送到任一 backend
3. 部署 OTel Collector（agent / gateway 模式）作為 backend 切換抽象層
4. 區分 head-based vs tail-based sampling、選擇對應策略
5. 評估從 vendor SDK 遷移到 OTel SDK 的相容性風險

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

1# 1. 應用程式加 auto-instrumentation（範例：Python）
2# TODO: opentelemetry-bootstrap -a install
3# TODO: opentelemetry-instrument --traces_exporter otlp --metrics_exporter otlp python app.py
4
5# 2. 啟動 OTel Collector
6# TODO: docker run -p 4317:4317 -p 4318:4318 otel/opentelemetry-collector-contrib
7
8# 3. Collector 配置範例
9# TODO: otel-collector-config.yaml with otlp receiver + exporter to backend

最短路徑驗證 telemetry 從 app → Collector → backend 串通。實際 production 要評估 sampling、retention、cardinality。

日常操作與決策形狀

Instrumentation 模式

子議題：

• Auto-instrumentation：Java / Python / Node / .NET / Ruby / Go 各語言成熟度不同
• Manual instrumentation：開發者寫 trace span / metric instrument
• Library instrumentation：opentelemetry-instrumentation-（HTTP client / DB / framework）

OTLP exporter 配置

子議題：

• OTLP gRPC（4317）vs HTTP（4318）
• Endpoint / headers / authentication 配置
• 對應指令範例：環境變數 OTEL_EXPORTER_OTLP_ENDPOINT、OTEL_EXPORTER_OTLP_HEADERS

Collector 部署模式

子議題：

• Agent：跟應用程式同 host / pod、做 local buffer + enrichment
• Gateway：集中部署、跨多 agent 接收、做 sampling / routing
• Sidecar：K8s sidecar pattern、跟 pod 同生命週期
• 對應配置：receivers / processors / exporters pipeline

深入：OTel Collector 部署模式：agent / gateway / sidecar 與 pipeline 設計（三種位置責任分工、pipeline 設計、collector 失效 / 記憶體壓力 / backpressure 故障演練、容量成本邊界）。

進階主題（按需閱讀）

Auto-instrumentation 跨語言成熟度

子議題：

• Java：最成熟、auto-instrumentation 廣度最大
• Python：成熟、覆蓋主流 framework
• Node：成熟、async context propagation 較複雜
• Go：較弱（runtime 不支援 monkey patching）、多用 manual
• .NET：成熟、跟 Application Insights 對齊
• Ruby / PHP：相對較弱、覆蓋主流 framework

Sampling 策略

對應案例 4.C7 Datadog OTel migration。子議題：

• Head-based sampling：trace 開始時決定保留與否、低成本但 lose context
• Tail-based sampling：trace 完成後決定（依錯誤 / 延遲）、Collector 要 buffer 整個 trace
• Sampling rate 配置（global / per-service / probabilistic）
• 對應工具：OTel Collector 的 tail_sampling processor、Refinery（Honeycomb）

Semantic conventions

子議題：

• HTTP / DB / messaging / RPC 等的 attribute 命名規範
• Resource attributes（service.name / service.version / deployment.environment）
• Span name / status code convention
• Migration：應用層用 OTel semantic conventions、避免 vendor-specific naming

Logs in OTel

子議題：

• Logs 比 metrics / traces 較晚進 OTel spec（v1.0 較新）
• Log signal 設計：log record 跟 span 關聯（trace_id / span_id）
• 跟 Loki / Elastic / CloudWatch 的整合
• 從現有 logging library 移轉的路徑（log-forwarding vs SDK）

Vendor SDK vs OTel SDK 遷移

對應案例 4.C4 X-Ray to OpenTelemetry 與 4.C7 Datadog OTel。子議題：

• 動機：避免 vendor lock-in、多 backend 並存、開源治理
• 風險：vendor-specific feature 損失（profiling / RUM 整合）
• 遷移路徑：dual ship → cutover → cleanup
• 對應 4.C9 反例：OTel migration signal drift

Resource detection

子議題：

• 自動偵測 cloud provider（AWS / GCP / Azure）resource attributes
• K8s resource detector（pod / namespace / cluster）
• Container resource detector
• 對應配置：OTEL_RESOURCE_ATTRIBUTES

排錯快速判讀

Telemetry 沒到 backend

操作原則：先確認 SDK 配置正確、再看 Collector 是否收到、最後看 exporter 是否成功。

1# TODO: 設 OTEL_LOG_LEVEL=debug 看 SDK 內部 log
2# TODO: 看 Collector internal metrics（zPages / Prometheus exporter）

判讀路徑：SDK → Collector → backend、三段各自獨立、要逐層 isolate。

Cardinality explosion

操作原則：metric attribute 含 high-cardinality 值（user_id / session_id）會爆 backend 成本。判讀：看 backend 的 series 數量、找 attribute 來源。

Trace span gap

操作原則：trace 不完整、看 context propagation 是否在跨 service / 跨 thread 邊界丟失。

Auto-instrumentation 不生效

操作原則：確認 SDK 版本跟 library version 對應、agent 啟動方式正確。對應 4.C7 Datadog OTel migration 的踩坑經驗。

Sampling 過頭 / 不足

操作原則：sampling rate 跟 backend 預算 + debug 需求對齊。判讀：debug 時找不到 trace（sampling 過頭）vs backend 成本爆（sampling 不足）。

何時改走其他服務

不在本頁內的主題

• 各語言 SDK 完整 API
• OTLP protocol binary format
• 各 backend 的 OTel 整合細節（見各 backend vendor 頁）
• OTel project governance / sig 細節

案例回寫

直接相關案例

跨 vendor 對照

下一步路由

• 上游概念：4.17 Telemetry Data Quality
• 平行 vendor：所有 04 vendor 都可作 OTel backend
• 下游能力：4.20 Observability Evidence Package

服務定位

PagerDuty 的核心定位是 signal → human → action 的中介層、把 alert source（觀測、SIEM、合成監控、cloud control plane）變成具體某個人手機震動 + 24 小時內可追蹤的 incident timeline。它是 routing engine + on-call schedule 的事實標準、定位有別於 alert source 和溝通平台。

跟上游 07 章的 detection stack 是直接 wire：Splunk ES app 產生的 Notable Event 透過 Splunk-PagerDuty integration 或 SOAR playbook 變成 PagerDuty incident、severity 直接帶過來；Cloudflare WAF 的高分 rate-limit / bot block 透過 webhook 進 PagerDuty Event API v2、再經 Event Orchestration 判斷是丟 SecOps schedule 還是 platform schedule。這條鏈最常壞在 severity 對應不一致（Splunk medium 在 PagerDuty 變 P1）、跟 integration 沒 deduplication key（一次 attack 100 個 Notable Event 各起 100 個 incident）。

跟 Opsgenie / incident.io / Grafana OnCall 的差異在 ecosystem 跟 IR 模型 — PagerDuty 走 enterprise + AIOps + Process Automation 重資料堆疊、incident.io 走 Slack-native + collab-first、Opsgenie 綁 Atlassian、Grafana OnCall 是 OSS 自管。選 PagerDuty 的核心理由通常是 AIOps + Process Automation + Jeli postmortem 整合的 ecosystem maturity、不是 paging 功能本身。

關鍵張力：alert volume ↔ responder burnout 是 PagerDuty 客戶最常見 trade-off。為了「不漏 alert」把 grouping / deduplication 設很寬、結果 on-call 一週被叫醒 20 次、3 個月後人員流失。要看清楚自己 容忍多少漏報換多少 responder sustainability、不是把 alert source 全開到 PagerDuty 當保險。

本章目標

讀完本頁、讀者能判斷：

1. PagerDuty 在 alert pipeline 中承擔哪一段（routing / schedule / incident workflow）、哪些要外接（Slack 通訊、Jeli postmortem、Process Automation 對接 runbook）
2. Service / escalation policy / schedule 的 ownership 設計（誰建 service、誰改 escalation、誰能 override schedule）
3. Event Orchestration 的 deduplication / grouping / dynamic routing 設計、跟上游 SIEM 的 severity mapping 一致性
4. 何時用 PagerDuty、何時走 Opsgenie / incident.io / Grafana OnCall 的取捨

本頁不教 PagerDuty console 操作步驟、也不列 pricing tier — 那些 vendor 官方文件已經完整。本頁重點在 判讀問題：怎麼看一個 PagerDuty deployment 健康與否、哪些 config 是 high blast radius、跟上下游（07 detection / 04 observability / Jeli postmortem）怎麼接。

最短判讀路徑

判斷 PagerDuty deployment 是否健康、最少看四件事：

• 誰能 ack / escalate / resolve：on-call rotation 有沒有人、escalation policy 第二層第三層是不是同一個人、有沒有 break-glass 流程（primary 失聯時誰補位）。schedule override 是否走 PR / approval、還是 console 直改沒留痕。
• Escalation policy 設計：每層 escalation timeout（5min / 10min / 15min）是否符合 SLO、是否有 無人 ack 自動上報主管 規則、跨時區 schedule 是否避免半夜 page 給 off-shift 區域
• Event Orchestration 設定：alert deduplication key 是否正確（同一 host + 同一 alert type 合併）、grouping rule 是否避免 alert storm、dynamic routing 是否依 service / severity / time 分軌到不同 schedule
• SOAR / Process Automation playbook 觸發點：哪些 incident 自動觸發 runbook（restart / rotate token / scale up）、approval gate 是否設在高風險動作、playbook 失敗有沒有 fallback 回 human page

四件事任一缺失、就是 Drills and On-call Readiness 的待補項目。

日常操作與決策形狀

Service / team / escalation

PagerDuty 的 service 對應一個應用 / component、是 incident 的最小 ownership 單位。一個 service 綁一個 escalation policy（N 層、每層 X 分鐘 timeout）、一個 schedule（rotation + override）。production 部署用 Terraform PagerDuty provider 進版控、不在 console 直改 — 因為 schedule / escalation 是高 blast radius config、誤改可能讓半夜 alert 漏掉。Service 通常按 Service Ownership 對齊組織結構、不是按技術 stack 切：把一個微服務 stack 拆成 10 個 service 看似乾淨、但 incident 起來時 responder 要同時 ack 10 個 incident 對 SLO 不利、合理粒度通常是 一個 product team 一個 service。

Event Orchestration + Response Play

Event Orchestration 是 alert → incident 的工程化路由層、處理 deduplication / grouping / dynamic routing 三件事。deduplication 用 dedup_key（同 host + 同 check type 合併、避免 100 個 alert 起 100 個 incident）、grouping 用 time window + tag（同一服務 5min 內多個 alert 合一）、dynamic routing 依 severity / time / service tag 分軌到不同 schedule。Response Play 則是 incident 起來後自動執行的動作 bundle — page additional responder、建 Slack channel、發 status page、call conference bridge。Response Play 應該走 PR review、不能 console 直加 — 一個誤設的 Response Play 可能在每個 P1 自動 page 整個 leadership。

Severity mapping 跟上游一致性

上游 source（Splunk Notable Event / Datadog monitor / Cloudflare WAF alert）的 severity 跟 PagerDuty incident urgency 要 對應表化、不是各自為政。常見錯位：Splunk medium 在 PagerDuty 變成 high urgency（半夜被吵醒）、或 Cloudflare 高分 bot block 進來只標 low（真實 attack 漏報）。實務做法是寫一張 severity translation table 進 Event Orchestration、source severity → PagerDuty urgency 一對一寫死、變更走 PR review。對應 Incident Severity Trigger 的判讀標準。

核心取捨表

選 PagerDuty 的核心訴求：多 service 大組織 + AIOps 對 alert storm 有 ROI + Process Automation 對接 runbook + Jeli postmortem 整合需求。Slack-first 小組直接 incident.io、Atlassian-heavy 走 Opsgenie、預算敏感 OSS 走 Grafana OnCall。

進階主題

Event Orchestration deduplication / grouping：deduplication 跟 grouping 是兩個層次 — dedup 是 同一事件多次發送只算一個（用 dedup_key）、grouping 是 多個相關事件合成一個 incident（用 time window + service / tag）。設定太寬會漏 alert（不同 root cause 被合併、漏報重要事件）、設定太窄會 alert storm。實務做法是 先寬後窄 — 上線初期用較寬 grouping 觀察、再依 false-merge 案例收窄。

AIOps Machine Learning：PagerDuty AIOps 用 ML 做 alert clustering + probable root cause + change correlation — 多個 alert 自動歸成 cluster、推測 root cause、跟近期 deploy / config change 對照。風險是 黑箱：ML 把不相關 alert 合一、SOC analyst 看不到原始事件就 ack；或把真實 incident 歸到 noise cluster。production 應該開、但 保留 manual ungroup 機制 + 定期 audit cluster accuracy。

Process Automation + Splunk SOAR 整合：PagerDuty Process Automation（前 Rundeck）做 runbook 自動執行 — restart / scale / rollback / rotate token。對接 Splunk SOAR 形成 incident enrichment + auto-remediation 鏈：Splunk SOAR 在 incident 起來時自動拉 context（user / host / IP recent activity）寫進 PagerDuty incident note、再依 playbook 觸發 PagerDuty Process Automation 做動作。高風險動作（disable account、rotate prod credential）必走 approval gate、不能 fire-and-forget。

Jeli postmortem 整合（2023 收購後）：PagerDuty incident resolve 後可以一鍵 import 進 Jeli、自動帶 timeline / responder list / Slack transcript、開始做 interview + narrative。對應 Jeli vendor — Jeli 走「learning from incident」方法論、不是只生 root cause report、強調 near miss 跟 human factor 也要分析。

Service ownership / Service Standards：PagerDuty Service Standards 把 service 的 escalation policy / runbook link / business criticality / oncall coverage 做成 checklist、organization 可以看哪些 service 沒達標。對 platform team 是治理工具、避免某 service「沒人 oncall 但有 alert source」。配對 Repeated Incident Toil 的反模式：service 沒人 own 但 alert 一直響、最後變 noise 被全部靜音、真實 incident 進來時也漏報。

Status page 整合：PagerDuty incident 可以自動同步到 Atlassian Statuspage / Instatus 對外 status page、但 自動同步 是雙刃刀 — internal P1 不一定是 customer-facing、誤公告影響品牌。實務做法是 只同步 customer-facing severity 的 incident、用 Event Orchestration 加 tag (customer_facing: true) 才觸發 statuspage update、其他 incident 走人工 publish。

排錯與失敗快速判讀

• Escalation 漏配 / primary 失聯沒人補：escalation policy 第二層第三層是同一個人、或 off-shift 時無人 ack — 改成跨層異人 + break-glass policy（自動 page manager-on-call）+ 半年 audit
• Schedule 跨時區算錯：把 UTC schedule 套到亞太工程師、結果半夜 page off-shift — schedule 用 follow-the-sun rotation、或在 schedule layer 加 time restriction
• Event Orchestration deduplication 太寬：不同 root cause 的 alert 被 dedup 成同一 incident、漏報 — 收窄 dedup_key（加 service + alert_type）、保留 manual unmerge
• Event Orchestration grouping 太窄：同一事故 100 個 alert 各起 100 個 incident、alert storm、on-call 看不完 — 放寬 time window grouping、或開 AIOps clustering
• AIOps ML 黑箱誤合：真實 incident 被歸到 noise cluster、responder 沒看到 — 開 ML cluster audit dashboard、每月 sample review、保留 manual ungroup 機制
• Slack notification stale：PagerDuty Slack app token 過期 / channel 改名、incident 通知沒進 Slack — Slack integration health check + fallback channel + on-call 應該收 mobile push 不只看 Slack
• Response Play 自動誤觸：Play 設成 P1 自動 page leadership、結果一個 noise P1 把整個 C-level 半夜叫起來 — Play 必走 PR review、defaults to additional engineer not leadership、leadership page 走人工升級

何時改走其他服務

PagerDuty 不是所有 IR 場景都適合：

選對需求形狀比選 vendor 重要：startup 一開始走 Slack-native incident.io、規模上來 alert storm 多了再評 PagerDuty AIOps、Atlassian 重度用戶 Opsgenie bundle 划算。

不在本頁內的主題

• 各 integration 完整 setup / Pricing 細節 / AIOps ML 內部演算法
• Response Play 跟 Process Automation 的具體 playbook 實作（Rundeck DSL）
• Jeli 的 narrative + interview workflow（屬 postmortem 章節）

案例回寫

PagerDuty 公開 customer 多為大型 SaaS / 平台、下列案例可作為「paging 設計如何影響事故 detect → ack → mitigate 時間 + 怎麼跟 07 detection 鏈起來」的閱讀脈絡：

下一步路由

• 上游：Drills and On-call Readiness、Incident Severity Trigger
• 平行：Opsgenie、Grafana OnCall、incident.io
• 下游：Incident Decision Log、Jeli（postmortem 接手）
• 跨類：Splunk（Notable Event source）、Cloudflare WAF（WAF alert source）
• 官方：PagerDuty Documentation

對「任務隊列、worker pool、複雜 routing、RPC over messaging」這條路徑、RabbitMQ 是業界主流。本頁先給最短路徑、再展開日常 publisher / consumer 操作與 exchange 設計、最後進階治理（quorum queue、cluster、federation）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 docker 跑起 RabbitMQ + management UI、驗證 broker 健康
2. 用 CLI / Management API 建 exchange、queue、binding
3. 設計 exchange type（direct / fanout / topic / headers）對齊路由需求
4. 看懂 queue depth、unacked、connection / channel 數量訊號、定位故障層
5. 評估 quorum queue、stream、federation、shovel 等規模化議題

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

 1# 1. 啟動 RabbitMQ + management plugin
 2docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management
 3
 4# 2. 建 exchange / queue / binding（rabbitmqadmin 可重現、Management UI 在 http://localhost:15672、預設 guest/guest）
 5docker exec rabbitmq rabbitmqadmin declare exchange name=demo.direct type=direct
 6docker exec rabbitmq rabbitmqadmin declare queue name=demo.q
 7docker exec rabbitmq rabbitmqadmin declare binding source=demo.direct destination=demo.q routing_key=demo
 8
 9# 3. 用 rabbitmqctl 驗證 broker 狀態
10docker exec rabbitmq rabbitmqctl list_queues
11docker exec rabbitmq rabbitmqctl list_exchanges
12docker exec rabbitmq rabbitmqctl list_bindings

最短路徑驗證「broker 起來、UI 能訪、能 enqueue/dequeue」。實際寫程式用 AMQP client、見日常操作。

日常操作與決策形狀

CLI 與 client API

子議題：

• CLI 指令對照表（rabbitmqctl / rabbitmq-diagnostics / rabbitmqadmin）
• Management API 形狀（HTTP API、適合自動化）
• AMQP client 配置：connection / channel / consumer prefetch / publisher confirm
• 對應指令範例：rabbitmqctl list_queues name messages messages_unacknowledged consumers

Exchange types 與 routing 設計

Exchange 承擔訊息分流責任、不同 type 對應不同路由語意。子議題：

• Direct：精準 routing key 匹配（point-to-point）
• Fanout：忽略 routing key、廣播到所有 binding queue
• Topic：層級式 routing key（* 單層、# 多層萬用字元）
• Headers：依 message header 路由（少用）
• 對應指令：宣告 exchange / queue / binding 的 CLI 與 client 範例

Queue 設計與 ack/nack 策略

Ack/nack 是 RabbitMQ 的 delivery 控制點。子議題：

• Durable queue vs transient queue
• Manual ack vs auto ack（後者等同 at-most-once）
• Prefetch 設定（backpressure + 併發控制）
• Dead-letter exchange（DLX）配置
• Message TTL 與 queue length limit

進階主題（按需閱讀）

本段主題已展開為 deep article：classic vs quorum vs stream 選型、network partition 與 cluster 一致性、DLQ retry escalation。下列子議題段保留選題判讀入口。

Classic queue vs Quorum queue vs Stream

子議題：

• Classic queue：原生持久化 queue、mirrored queue 已 deprecated
• Quorum queue：Raft-based、取代 mirrored、跨節點一致性
• Stream（3.9+）：append-only log、log-based 模型、類似 Kafka 但仍是 RabbitMQ 體系
• 三種模型的選擇判讀（throughput、retention、replay 需求）

Federation 與 Shovel

子議題：

• Federation：upstream / downstream broker 鏈接、適合鬆耦合跨資料中心
• Shovel：點對點轉發、適合單純訊息搬運
• 跨區 / 多 cluster 場景的選擇

Erlang clustering 與 network partition

子議題：

• Cluster 拓樸（disc node、ram node）
• cluster_partition_handling 策略（ignore、autoheal、pause_minority）
• 腦裂偵測與處理

多 vhost / 多租戶

子議題：

• Vhost 隔離（namespace、ACL、user permission）
• User / Role / Permission 設計
• Per-vhost resource limit（max connection、max queue）

Prefetch 與 consumer 併發控制

子議題：

• Prefetch count 對 throughput / fairness 的影響
• Channel-level vs Consumer-level prefetch
• 配合 retry budget 控制重試壓力

RabbitMQ Cluster Operator（K8s）

子議題：

• Cluster Operator vs 自管 StatefulSet
• 持久化卷（PVC）與資料保護
• 升級流程（rolling restart 與資料完整性）

Plugin 機制與多協議

子議題：

• MQTT plugin（IoT 場景、橋接 device-to-broker）
• STOMP plugin
• 對應 3.1 broker basics 的 QoS / ACK 機制橋接

排錯快速判讀

Queue 堆積（messages 增加、unacked 不收斂）

操作原則：先看 consumer 是否存在、再看 ack 速率 vs publish 速率、最後看 prefetch / poison message。

1rabbitmqctl list_queues name messages messages_unacknowledged consumers

判讀路徑：無 consumer（client crash）→ consumer 慢（下游卡）→ poison message 卡住（看單一 message redelivery 次數）。

Connection / Channel limit

操作原則：client 設計不當會用滿 connection / channel，看每個 connection 的 channel 數。

1rabbitmqctl list_connections
2rabbitmqctl list_channels

Disk alarm 觸發

操作原則：disk 低於 disk_free_limit、broker 暫停 publisher。判讀：保留期太長 / 訊息大小 / 未消費 queue 過大。

Memory alarm 觸發

操作原則：記憶體超過 watermark、broker 觸發 paging、publisher 變慢。判讀路徑：訊息累積、consumer 失聯、queue 設定錯誤。

Network partition（腦裂）

操作原則：cluster 節點互相不可達、看 cluster_partition_handling 與 partition log。對應 3.C9 語義誤配 思路。

何時改走其他服務

不在本頁內的主題

• 各語言 AMQP client 完整 API（依官方文件）
• 所有 plugin 細節（只列主流 plugin）
• RabbitMQ Streams 跟 Kafka 的詳細對照（見 Kafka vendor 頁）

案例回寫

RabbitMQ 專屬案例（C23-C33）

跨 vendor 對照

MQTT plugin + Cluster Operator 缺直接 customer case：可補 RabbitMQ 官方 native MQTT blog 跟 K8s Operator docs、後續若有 customer 案例可加。

下一步路由

• 上游概念：0.3 非同步選型、3.1 broker basics
• 平行 vendor：Kafka、NATS
• 下游能力：3.2 durable queue、3.4 consumer 設計

對「通用快取、session store、rate limit counter、leaderboard、distributed lock」這條路徑、Redis 是事實標準。本頁先給最短路徑、再展開日常 CLI / API 與 key 設計、最後進階治理（cluster / persistence / modules）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 docker 跑起 Redis、用 redis-cli 驗證
2. 用 SET / GET / EXPIRE / DEL / KEYS 操作、區分 6 大 data types 適用場景
3. 設計 key naming + TTL + eviction policy 對齊 cache miss 行為
4. 看懂 hit rate / memory pressure / eviction / replication lag 訊號
5. 評估 Cluster vs Sentinel、AOF/RDB、modules、授權變動下的選擇

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

1# 1. 啟動 Redis
2# TODO: docker run -d --name redis -p 6379:6379 redis:7
3
4# 2. 連線
5# TODO: docker exec -it redis redis-cli
6
7# 3. 驗證 SET / GET / EXPIRE
8# TODO: SET foo bar / GET foo / EXPIRE foo 60 / TTL foo

最短路徑驗證「Redis 起來、能讀寫 + TTL」。實際應用見日常操作。

日常操作與決策形狀

CLI 與 client API

子議題：

• redis-cli 指令對照表（SET / GET / DEL / EXPIRE / TTL / KEYS / SCAN / MGET / MSET）
• Client library 配置：connection pool / timeout / pipeline / cluster mode
• Pub/Sub vs Streams 的選用判讀
• 對應指令範例：INFO replication、CLIENT LIST、SLOWLOG GET

Key design 與 data types

不同 data type 對應不同資料形狀。子議題：

• String：cache / counter / config flag
• Hash：object cache（避免反覆 serialize）
• List：queue / activity feed（小規模）
• Set：membership / tag
• Sorted set：leaderboard / time-series sliding window
• Stream：log-style queue / event stream
• HyperLogLog / Geo：approximate count / 地理座標

Key naming 規範：<service>:<entity>:<id>:<field>、用 : 分層、避免大 key（單 key > 10KB / list 長度 > 10K）。

TTL 與 eviction 策略

TTL 跟 eviction 是 cache 行為的核心旋鈕。子議題：

• 顯式 EXPIRE vs SET EX 設 TTL
• maxmemory + maxmemory-policy（allkeys-lru / allkeys-lfu / volatile-lru / volatile-ttl / noeviction）
• TTL 設計：固定 TTL vs 動態 TTL vs 不設 TTL
• 對應指令：CONFIG SET maxmemory 2gb、CONFIG SET maxmemory-policy allkeys-lfu

進階主題（按需閱讀）

Cluster vs Sentinel

子議題：

• Sentinel：HA 模式、無 sharding、適合單 master 容量足夠
• Cluster：sharding 模式、16384 hash slot、橫向擴展容量
• Hash tag {...} 強制 multi-key 同 shard
• Cluster failover 對 PEL（Streams）跟 distributed lock 的影響

AOF / RDB 持久化策略

子議題：

• AOF（append-only file）：fsync 策略（always / everysec / no）、rewrite
• RDB（snapshot）：save 策略、backup 還原
• 混合模式：AOF + RDB
• 持久化在 cache 場景的取捨（持久化是回填還是 source-of-truth）

Eviction policy 詳細

子議題：

• LRU vs LFU：access pattern 對選擇的影響
• volatile-* vs allkeys-*：只淘汰有 TTL 的 vs 全 key
• approximate LRU 的 sampling 影響
• 對應 2.3 TTL eviction

Distributed lock

子議題：

• SETNX + EXPIRE 模式
• Redlock 算法（多 master quorum）+ 取捨爭議
• Redlock 何時不夠：fence token / lease renewal
• 對應 2.5 distributed lock

Pub/Sub vs Streams

子議題：

• Pub/Sub：fire-and-forget、訂閱者離線會錯過
• Streams：append-only log、consumer group + PEL
• 何時用 Streams 取代 Pub/Sub
• Redis Streams 細節見 03 messaging 模組 Redis Streams vendor

Redis Modules

子議題：

• RedisJSON / RedisSearch / RedisTimeSeries / RedisBloom / RedisGraph
• Module 隨授權變動受影響、Valkey 部分 fork
• Module 在 ElastiCache 的支援限制

授權變動與選型影響

子議題：

• 2024 RSALv2 / SSPL 變動的影響範圍
• 對 managed service（ElastiCache 改 default 為 Valkey）的衝擊
• 從 Redis 遷 Valkey 的相容性路徑
• 商業 vs OSS 邊界

Hot key 處理

子議題：

• Hot key 偵測（redis-cli –hotkeys、MONITOR 慎用）
• Hot key 解法：local cache + Redis 兩層、key 拆分（讀多寫少場景）
• 對應 2.6 high concurrency

排錯快速判讀

Hit rate 下降

操作原則：先看 cache pattern 是否變（新功能 / TTL 變短）、再看 origin 壓力是否擴大。

1# TODO: INFO stats（看 keyspace_hits / keyspace_misses 比例）

判讀路徑：TTL 太短 → eviction 太積極 → key 命名變動造成 cache miss → origin 失敗 retry storm。

Memory pressure / eviction 異常

操作原則：先看 maxmemory + maxmemory-policy 設定、再看 key size 分布。

1# TODO: INFO memory / MEMORY USAGE <key> / --bigkeys

Hot key

對應案例 2.C5 Shopify Write-Through。判讀路徑：某 key 的 QPS 遠高於其他、單 shard CPU 接近 100%、其他 shard 閒置。

Replication lag

操作原則：replica 跟 master 差距、看 INFO replication 的 master_repl_offset vs slave_repl_offset。對 2.C1 Meta Cache Consistency 的對照。

Cache stampede（雷霆崩潰）

對應反例 2.C9 Cache Stampede Rollout。判讀路徑：TTL 同時過期 → 大量 cache miss → origin 被打爆 → 連鎖失敗。修法：jitter TTL、early refresh、singleflight 模式。

何時改走其他服務

不在本頁內的主題

• 各語言 Redis client 完整 API
• Redis command 百科（詳查 redis.io/commands）
• Redis Stack 商業 modules 細節
• AOF / RDB 內部 binary format

案例回寫

直接相關案例

跨 vendor 對照

下一步路由

• 上游概念：2.2 Cache Aside、2.3 TTL eviction
• 平行 vendor：Valkey、Memcached
• 下游能力：2.5 distributed lock、2.6 high concurrency

本章目標

學完本章後，你將能夠：

1. 用需求類型辨識後端服務分類
2. 區分資料儲存、快取、訊息傳遞、觀測與部署平台
3. 判斷一個問題應先進入哪個 backend 模組
4. 避免把所有外部技術都混成同一種「基礎設施」

【觀察】需求會先表現成系統症狀

後端服務選型通常從症狀開始。產品需求或事故描述裡會出現一些可觀察訊號：

這張表是索引。真正的選型要看每個訊號背後的資料生命週期、流量形狀與操作需求。

【判讀】資料長期存在通常先看資料庫

資料庫解決的是「系統承認哪份資料是正式狀態」。如果資料需要長期保存、支援查詢、維持交易一致性、被多個 request 共同讀寫，選型應先進入資料庫與持久化模組。

接近真實網路服務的例子包括：

• 電商訂單需要保存付款狀態、出貨狀態與退款紀錄
• 會員系統需要保存帳號、權限、登入方式與審計資料
• SaaS 產品需要保存 workspace、plan、billing 與使用量

這類問題的核心是 source of truth。快取可以加速讀取，queue 可以延後處理，log 可以協助診斷，但正式狀態仍需要清楚的資料模型與一致性邊界。

下一步可讀：資料庫與持久化。

【判讀】讀取壓力集中通常先看快取

快取解決的是「同一類資料被重複讀取時，如何降低正式資料來源壓力」。如果資料本身已經有 source of truth，但熱門資料導致資料庫或下游 API 壓力過高，選型應先進入快取與 Redis 模組。

接近真實網路服務的例子包括：

• 商品詳情頁被大量瀏覽，但商品資料變更頻率低
• 使用者權限或 Feature Flag 每個 request 都要查
• 即時服務需要快速查詢 client presence 或 topic 訂閱狀態

這類問題的核心是讀取路徑與失效策略。快取要回答資料何時過期、何時更新、下游失敗時如何回應、cache miss 尖峰如何保護系統。

下一步可讀：快取與 Redis。

【判讀】工作跨出 request 通常先看訊息傳遞

訊息佇列解決的是「工作離開目前 process 或 request 後，如何可靠地被處理」。如果一個 request 需要觸發後續工作、等待外部系統、重試、批次處理或跨服務通知，選型應先進入訊息佇列與事件傳遞模組。

接近真實網路服務的例子包括：

• 付款成功後要寄信、更新 CRM、發送推播與建立出貨任務
• 使用者上傳影片後要轉檔、產生縮圖與通知完成
• IoT 裝置上報資料後要清洗、聚合與觸發告警

這類問題的核心是 delivery semantics。系統要決定是否需要持久化、是否允許重複投遞、失敗是否重試、consumer 如何水平擴展。

下一步可讀：訊息佇列與事件傳遞。

【判讀】看不見系統行為通常先看觀測平台

可觀測性平台解決的是「服務發生什麼、為什麼發生、影響範圍多大」。如果事故發生後只能看單機 log，無法串起 request、事件、下游依賴與容量趨勢，選型應先進入可觀測性模組。

接近真實網路服務的例子包括：

• API 偶爾變慢，但無法判斷是資料庫、外部 API 還是部署節點問題
• queue lag 上升，但不知道 producer 變快還是 consumer 變慢
• WebSocket client 斷線增加，但缺少連線生命週期與地區資訊

這類問題的核心是操作訊號。log、metric、trace、dashboard 與 alert 需要共用欄位與關聯方式，才能讓工程師從症狀回到原因。

下一步可讀：可觀測性平台。

【判讀】服務交付不穩通常先看部署平台

部署平台解決的是「服務如何被啟動、更新、擴容、接流量與停止」。如果問題集中在 rolling update、liveness、load balancer、service registry、service discovery、container image 或資源限制，選型應先進入部署平台與網路入口模組。

接近真實網路服務的例子包括：

• 發版時部分 request 失敗，舊 pod 和新 pod 切換不穩
• 服務需要水平擴展，但 client 不知道該連到哪個 instance
• shutdown 時仍有背景工作或長連線尚未清理

這類問題的核心是平台合約。程式要提供 health、readiness、shutdown 與資源使用訊號；平台要提供流量入口、排程、發版與回滾能力。

下一步可讀：部署平台與網路入口。

進入規模成長路線時、能力地圖之外還要看四條額外章節：10.1 服務拆分與邊界判讀 處理「該不該拆服務」、0.19 雲端服務對照地圖 處理「該選哪家 vendor」、9.13 擴展軸與 Stateless 前提 處理「該怎麼擴容」、1.13 應用層查詢反模式 處理「擴容前先優化什麼」。

小結

後端服務選型先從需求類型開始。資料長期存在先看資料庫，讀取壓力集中先看快取，工作跨出 request 先看訊息傳遞，系統行為缺少可見性先看觀測平台，服務交付不穩先看部署平台。分類清楚後，後續產品選型與實作細節才會有正確位置。

訊息代理（broker）的核心責任是解耦 producer 與 consumer，讓非同步工作具備可排隊、可重試、可隔離的傳遞路徑。它定位在傳遞與協調層。

broker 跟 protocol 是兩個獨立的軸

Broker 是訊息分發的具體實作產品（RabbitMQ、Kafka、NATS、EMQX）、protocol 是訊息交換的線路規格（AMQP、MQTT、STOMP、Kafka wire protocol）。兩個軸獨立、形成多對多關係：

• 一個 broker 可實作多個 protocol：RabbitMQ 主走 AMQP、透過 plugin 也支援 MQTT 跟 STOMP；NATS 主走自家 protocol、JetStream 額外提供 KV 與 Object Store API
• 一個 protocol 可被多個 broker 實作：MQTT 由 EMQX / HiveMQ / Mosquitto / RabbitMQ MQTT plugin 各自實作；AMQP 主要是 RabbitMQ 跟 Apache Qpid

選型討論時要分清「我需要的是 protocol（如 device 端要 MQTT 因為輕量 / IoT 標準）」還是「broker 產品（如 RabbitMQ vs EMQX 的運維 / 生態取捨）」。當 protocol 跟 broker 都需要、會出現 protocol 橋接場景 — 例：device 端透過 MQTT 連 RabbitMQ MQTT plugin、broker 內部把 MQTT topic 自動映射成 AMQP routing key、AMQP-side consumer 用 routing key 訂閱。

這層分離也影響故障判讀：device 連不上是 protocol 層問題、broker 之間 routing 錯是 broker 內部 plugin / mapping 問題、consumer 收不到是 AMQP binding 問題 — 三層各自獨立、不能混為一談。

broker、queue、consumer 的分工

broker 管理訊息儲存、分發與確認流程；queue 或 topic 承載傳遞單位；consumer 承擔業務處理。分工清楚後，故障判讀才能定位在正確層級：投遞故障、消費故障或下游依賴故障。

producer 發送成功只代表 broker 已接收（publisher confirm），不代表業務結果完成。業務完成需要 consumer 提交副作用並確認進度。

push 與 pull 模型

push 模型由 broker 主動推送訊息，適合低延遲場景；pull 模型由 consumer 主動拉取，適合吞吐控制與批次處理。實務上常結合使用：broker 管理可見性與重試，consumer 控制節流與併發。

模型選擇重點是背壓控制。當下游變慢時，系統是否能限制消費速率並保留恢復空間，是穩定性的關鍵。

傳遞語意（delivery semantics）

三種常見 delivery semantics：

1. at-most-once：可能丟失，不重送，低延遲低成本。
2. at-least-once：可能重複，需冪等保護，最常見實務語意。
3. exactly-once：語意成本高，通常在特定邊界內成立，需要嚴格協議與系統支持。

實務上多數後端系統採 at-least-once，再用 consumer 去重與補償達到業務可接受結果。

ack / nack 流程

ack/nack 是 delivery 控制點。ack 代表該訊息可從待處理集合移除；nack 代表稍後重試或分流。ack 時機過早會造成資料遺失，過晚會造成重複處理與堆積。

穩定流程是：完成核心副作用後再 ack，暫時故障走受控重試，持續故障走 DLQ 隔離。

語意保證的不同實作機制

同一層 delivery semantics、不同 broker 用不同協議機制達成。讀懂 broker 行為的關鍵、是辨認「at-least-once」這個語意承諾、底下是哪種具體機制負責 — 故障訊號跟操作旋鈕跟著不同。

三種常見實作機制：

三個機制的工程含義不同。QoS handshake 把可靠性責任拉到 wire protocol 層、適合 device-to-broker 場景但 broker-to-consumer 還要另外處理；broker ACK 把責任放在 consumer 處理完才確認、適合「處理即承諾」的任務隊列；replication 把責任放在訊息已被多份保存、適合「寫入即承諾」的事件流。

機制差異的故障訊號

機制決定故障表現。同樣是「訊息重複投遞」、不同機制要看不同訊號：

• QoS handshake：QoS 1 重傳是設計、QoS 2 重傳代表握手失敗 — 看 broker 端的 PUBREL / PUBCOMP 完成率
• Broker ACK：ack timeout 觸發 redelivery 是設計、頻繁 redelivery 代表 consumer 處理慢或下游卡 — 看 consumer 處理時間 vs ack timeout、視訊號為 backpressure
• Replication：producer retry 觸發 duplicate 是設計、ISR shrink 代表 broker 副本不穩 — 看 ISR 狀態 vs producer acks 設定

機制差異的操作旋鈕

挑 broker 等同於挑「可調的旋鈕集合」。把「業務需要的語意」轉成「實際要調的旋鈕」、是 broker 選型落地的關鍵步驟：

• 想保證「不丟」用 MQTT：QoS 等級提到 2、開 session persistence
• 想保證「不丟」用 RabbitMQ：consumer 走 manual ack、配 DLQ、設 prefetch 限併發
• 想保證「不丟」用 Kafka：producer acks=all、min.insync.replicas ≥ 2、consumer commit-after-process

機制不同、可調旋鈕不同、operator 要熟悉的訊號也不同。這是「broker 系統複雜度」的真實來源 — 不是「broker 難安裝」、而是「broker 旋鈕集合的學習與調校曲線」。

判讀訊號

常見誤區

把 broker 當成保證業務正確性的元件，會把消費責任與補償責任遺漏。broker 保證傳遞語意，業務正確性要由 consumer 設計承擔。

把 exactly-once 當成預設目標，也容易過度設計。先定義可接受失敗代價，再選擇對應語意，通常更符合實務。

Broker 規模化的角色變化

Broker 在規模化服務承擔的責任從「單隊列工具」轉到「平台治理問題」— 容量規劃焦點從擴 broker 變成多租戶隔離、配額管理、跨團隊觀測標準化。

對應 3.C6 Uber Kafka Infrastructure Evolution — Uber 事件平台服務眾多團隊、focus 從 broker 容量是否充足轉到 team 之間的隔離邊界。對應 3.C4 LinkedIn Tiered Clusters — 規模化必然分層 cluster、按業務特性跟可靠性需求分配不同叢集、高優先 workload 跟低優先 workload 各自獨立。

規模化的三個角色階段（依據 3.C6 / 3.C4 / 早期服務對照、整理出三個典型階段）：

• 單隊列工具（規模尚小階段）：一個 Kafka cluster、所有 service 共用、broker 擴容是主要工作、團隊各自管理自己的 topic
• 多租戶平台（中大型階段）：跨團隊共用 cluster、平台 team 設定 quota、topic 命名規範、容量配額、觀測標準。3.C6 描述 Uber 在這階段「標準化 topic 治理與故障處理流程」、把跨團隊運維責任收斂到平台層
• 分層治理平台（規模化階段）：不同業務特性走不同 cluster（critical / standard / experimental）、跨 cluster 路由跟治理變主要工作。3.C4 描述 LinkedIn「依流量與可靠性需求分層」、高優先 workload 提供獨立保護