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

服務定位

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

教學路線：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

本章目標

讀完本章後、你應該能：

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）

對「多服務多實例 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

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

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

Environment Protection Rules

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

Protection rule 類型

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

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

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

分層建議

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

OIDC Cloud Auth

Long-lived credential 的風險

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

OIDC federation 的運作方式

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

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

Cloud provider 配置

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

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

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

Trust policy 的安全邊界

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

實作範例

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

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

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

邊界與陷阱

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

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

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

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

整合路由

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

服務定位

Auth0 是 customer identity 的控制面、不是員工 SSO（員工走 Okta Workforce 或 AWS IAM Identity Center）。雖然 Auth0 於 2021 被 Okta 收購、目前屬「Customer Identity Cloud」產品線、跟 Workforce Okta 是 同公司不同 control plane：tenant 叢集、事件分布、signing key 託管路徑都分開、Okta Workforce 的事故（2022 Sitel、2023 support system HAR）並未直接打到 Auth0 customer。

跟自管 Keycloak 比、Auth0 把 Universal Login UI、social connection 預建、Rules / Action runtime、attack protection 都託管出去 — 代價是 SaaS 計費、token issuance / login attempt 都計量、流量大的 B2C 場景遇到 credential stuffing 不擋會吃成本。跟 AWS Cognito / Firebase Auth 比、Auth0 的核心優勢是 developer-first tenant 體驗 + 預建 social connection（Google / Facebook / Apple / Microsoft 等數十種）+ Action hook 寫 JS 客製。

本章目標

讀完本頁、讀者能判斷：

1. Auth0 該承擔哪一段 customer identity 控制（login flow / token broker / profile store / B2B Organizations）、哪一段該回到自己的 app
2. Auth0 tenant 的信任邊界與最低稽核需求（admin role、management API token、Action 程式碼、connection 設定）
3. Auth0 流量出事或母公司事件時的降級路徑（fallback connection、token rotation、anomaly throttle）
4. 何時用 Auth0、何時走 Cognito / Firebase Auth / Keycloak 的取捨

最短判讀路徑

判斷 Auth0 tenant 是否健康、最少看四件事：

• 誰能做什麼：Dashboard admin、Management API token 的 owner 與 scope、Action 是否走 code review、tenant 之間（dev / staging / prod）是否分離且授權獨立
• 憑證在哪裡：Management API token / M2M client 的 scope 與 TTL、社交 connection 的 client secret 存放位置、signing key（per-tenant）的 rotation 節奏、是否啟用 Custom Domain（避免 token issuer 暴露 *.auth0.com 域名）
• 入口如何暴露：登入走 Universal Login（託管 UI）還是 Embedded Login（嵌自家 app）、Cross-Origin Authentication 是否打開、Attack Protection（bot detection / brute-force / breached password / suspicious IP throttling）配置強度
• 證據是否可回查：Tenant Log 是否同步到 SIEM（Log Stream 推 HTTP / Datadog / Splunk）、登入失敗 / Action 例外 / Management API 變更是否 alert、保留期是否符合合規要求

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

日常操作與決策形狀

Tenant 與環境分離：Auth0 的 tenant 是邏輯隔離的多租戶 SaaS、不是物理叢集。每個環境（dev / staging / prod）開獨立 tenant、避免 dev 的 Action bug 打到 prod 流量、避免共用 client secret 跨環境洩漏。tenant 間用 auth0-deploy-cli 同步配置、Action 程式碼進版控。

Connection 設計：Database Connection（Auth0 託管帳密 store）跟 Social / Enterprise Connection（OIDC / SAML federation 到 Google / Microsoft / Okta）是兩種來源。決策點是 user 是否要進 Auth0 profile store — 純 federation 不存密碼、純 Database Connection 是 Auth0 替 app 管帳密表。混用要清楚 primary identity 與 linked account 的合併規則。

Action / Rule hook 的風險：Action（新框架）跟 Rule（舊框架）讓 tenant admin 在 login pipeline 注入 JS 程式碼（pre / post login、M2M、send email 等）。這是 Auth0 強大但也是 最大的供應鏈攻擊面 — Action 可以 require() npm package、惡意 dependency 會在每個 login flow 執行。應該 pin dependency 版本、code review、用最小權限的 Management API scope、定期掃 dependency CVE（思維對齊 紅隊 supply chain 案例）。

Universal Login vs Embedded Login：Universal Login 把登入 UI 託管在 Auth0 domain（或 Custom Domain）、user 跳轉到該頁完成登入後 redirect 回 app — 防 phishing / CSRF 的成本由 Auth0 吃。Embedded Login 把登入表單嵌進自己 app 並用 /co/authenticate 端點 — 看似 UX 順、但要自己防 XSS、CSRF、CORS、credential leak、且要打開 Cross-Origin Authentication（暴露額外攻擊面）。預設選 Universal Login、Embedded 只在 UX 強需求且能承擔安全成本時開。

Management API token / M2M client：Management API 控制整個 tenant（建 user、改 client secret、改 Action 程式碼）。token 不該長期存在程式碼或 CI；改用 M2M Application（client credentials grant）拿短期 token、scope 收到最小（read:users ≠ update:users ≠ update:actions）、走 Secret Management 取用。

Attack Protection 配置：B2C 流量大、登入嘗試本身計費也是攻擊面。Brute-force Protection（單 IP 多失敗鎖 user）、Suspicious IP Throttling（單 IP 多失敗鎖 IP）、Breached Password Detection（已洩漏密碼禁用）、Bot Detection（CAPTCHA / risk score）四個機制都該打開、否則 credential stuffing 既吃成本也提高帳號被接管的機率。

Break-glass 與 fallback：B2C 場景沒有「員工備用 admin」概念、break-glass 是 確保使用者在 Auth0 暫不可用時仍能登入。常見作法：app 端容忍 Auth0 暫時失敗、提供 magic link / email OTP 的替代登入路徑（透過獨立 ESP）、或預先發放長 TTL 的 refresh token 撐過短時故障。tenant 管理面則維持至少 2 個獨立 admin、credential 離線存。

Audit / handoff：Tenant Log 透過 Log Stream 推 SIEM、alert 三類事件 — Management API 對 Action / Connection / Client 的變更（供應鏈）、登入異常突增（credential stuffing）、support impersonation / Auth0 員工 access tenant 的紀錄（control plane）。

核心取捨表

選 Auth0 的核心訴求：customer identity + 大量 social / enterprise connection + 要 developer 客製 login flow、且接受 SaaS 計費與第三方控制面風險、能投入 SIEM / Action 程式碼治理 / attack protection 配置。

Microsoft 生態（Entra External ID / 前 Azure AD B2C）是另一個 B2C / B2B 選項、本表沒列入主要競品 — 它在 M365 / Azure 重度組織內是合理選擇、但 social connection 預建廣度跟 developer-centric tenant 體驗仍不及 Auth0。M365 重度 + B2C 需求的組織可同時評估 Entra ID 的 External ID 產品線。

進階主題

Action / Rule 的供應鏈治理：Action 程式碼進版控、走 PR review、auth0-deploy-cli 部署。Action 引用的 npm dependency pin 版本、避免 ^ / ~、CI 跑 SCA 掃 CVE。新增 Action 時 default scope 給 read-only、需要寫操作另外升級。Action secret（OAuth credential、API key）走 Action Secret 管理、不寫死在程式碼。

B2B Organizations：Auth0 Organizations 把同 tenant 內的多客戶（B2B 場景）邏輯隔離 — 每個 organization 有自己的 connection、branding、member。設計點是 user 是 organization member 還是 tenant-wide user、跨 organization 操作的 admin 是否有 organization scope。Organization 之間的隔離是 tenant 內邏輯層、共享底層 control plane、不能等同實體 tenant 隔離。

Adaptive MFA / Step-up Authentication：Auth0 Adaptive MFA 用 device / location / behavioral signal 動態升級 MFA 要求（impossible travel、新裝置、低信任 IP）。屬付費 add-on、本質是把 risk-based 認證內建。對 B2C 場景比強制全 user MFA 友善、但要把 risk threshold 跟 false positive 容忍度 設清楚、避免合法 user 被連續挑戰流失。

Custom Domain：預設登入網域是 <tenant>.auth0.com、揭露使用 Auth0 與 tenant 名稱、且 issuer 是 Auth0 子網域。Custom Domain 把 issuer 改成自己網域（如 login.example.com）、user 看到的 URL 一致、降低 phishing 對照成本。屬付費功能、production app 預設應該開。

Cross-Origin Authentication 的攻擊面：Embedded Login 必須開 Cross-Origin Authentication、讓 app 域名直接呼叫 Auth0 的 /co/authenticate。風險是 XSS 拿到 token、CSRF 偽造登入、third-party cookie 政策變動讓 silent auth 壞掉。Universal Login 不需要這個、所以同樣風險不存在 — 這是 Universal Login 推薦的核心理由。

排錯與失敗快速判讀

• Management API token 散落 / 過權：CI / 後端服務各自存 token、scope 都給 update:users / update:actions — 改 M2M Application + 最小 scope、定期 rotate、用 Secret Management 集中取用
• Action 直接 require 未 pin 的 npm package：login flow 每次都拉最新版、惡意 dependency 直接執行 — pin 版本、code review、定期掃 CVE
• 登入嘗試暴增 / 計費突增：Attack Protection 沒開或門檻太鬆、credential stuffing 吃額度 — 打開 Bot Detection、Brute-force、Suspicious IP Throttling、配合 Anomaly Detection
• 使用 Embedded Login 又沒控 XSS：自家 app 一旦 XSS、token 直接被偷 — 改 Universal Login、或補上嚴格 CSP / DOM 防護、定期 pen test
• Tenant Log 沒進 SIEM：事件只在 Dashboard、無法跨系統 correlation — 配 Log Stream 打到 SIEM、特定事件接 alert runbook
• 沒 Custom Domain：phishing 對照成本低、issuer 暴露 vendor — 配 Custom Domain、TLS cert 自管或走 Auth0 託管
• B2B Organizations 缺 scope 限制：admin 工具沒按 organization scope、單一 admin compromise 跨 organization 擴散 — 思維對齊 Okta Cross-Tenant 2023 的 lesson

何時改走其他服務

不在本頁內的主題

• Auth0 完整 OIDC / OAuth2 規格細節
• Action / Rule 完整 API 與 trigger 清單
• B2B Organizations 完整 schema 與 SDK 整合教學
• Auth0 定價層級的詳細功能對照
• 各 social connection provider 的 OAuth app 註冊步驟

案例回寫

Auth0 在 07 沒有直接案例（母公司 Okta 的事件並未直接打到 Auth0 customer），以下案例採對照引用、抽取對 Auth0 customer 的 lesson。要注意的是 缺直接案例不等於 vendor 沒有風險 — Auth0 自 2021 被 Okta 收購以來未公開重大 vendor 級事件、但同類 SaaS IdP 的歷史事件（Okta 集團、signing key 託管、credential stuffing）都是 Auth0 customer 的可預期風險面、不該等到第一次出事才補控制：

下一步路由

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

服務定位

Secrets Manager 的定位是 AWS-only workload 的 static secret 控制面、跟 SSM Parameter Store SecureString 在 存 secret 這層功能重疊、但設計目的不同。Parameter Store 是 parameter 管理（free tier、advanced parameter 每 10000 個約 $0.05、KMS 加密但無 staging label 與 rotation Lambda）；Secrets Manager 是 secret 管理（每個 secret per month $0.40 + API call、有 staging label / rotation Lambda / Resource Policy / Cross-Region Replica）。價差 8 倍以上、選擇基準在 是否需要 rotation 跟 cross-account sharing。

跟 Vault 比、Secrets Manager 是 單一雲、簡單、低運維、Vault 是 跨雲、dynamic credential、高表達力。AWS-only 組織用 Vault 等於多扛一個 HA cluster 運維成本只為了拿 KV engine 跟 RDS rotation、ROI 不划算；反向跨雲組織用 Secrets Manager 等於每個雲都自己一套 secret store、治理鏈會斷。跟 Google Secret Manager / Azure Key Vault 比、設計理念類似（雲廠 managed、KMS 加密、IAM 授權）但 rotation 機制各家不同 — Secrets Manager 用 built-in Lambda 四階段 flow、GSM 用 Pub/Sub event 觸發自寫 Cloud Function、Azure 用 Key Vault rotation policy + Event Grid。

本章目標

讀完本頁、讀者能判斷：

1. 哪些 secret 用 Secrets Manager、哪些可以下放到 Parameter Store、哪些該走 Vault 的 dynamic credential
2. Secrets Manager 的 雙層 grant 模型（Resource Policy + IAM Policy）跟 KMS encryption key custody 怎麼配
3. Built-in rotation 跟 Custom Rotation Lambda 的設計邊界、staging label 在 zero-downtime rotation 內的角色
4. 何時 Secrets Manager 已經不夠用、要往 Vault / 跨雲 broker 走

最短判讀路徑

判斷一個 Secrets Manager 部署是否健康、最少看四件事：

• 誰能 GetSecretValue：IAM Policy 那邊是不是用 secretsmanager:GetSecretValue 限定到 特定 secret ARN（不是 *）、Resource Policy 是不是只允許特定 principal（不是 Principal: *）、跨帳號 share 有沒有用 ABAC tag 限縮
• KMS key custody：secret 用 AWS-managed key（aws/secretsmanager）還是 customer-managed key（CMK）— production 應該全部 CMK、key policy 限定 only Secrets Manager service principal 可用、KMS key 持有者跟 secret 持有者要分離
• Rotation 設定：rotation 開了沒、rotation interval 多久、Lambda 過去執行 success rate、staging label 在 rotation 過程中是否依序 promote（AWSPENDING → AWSCURRENT → AWSPREVIOUS）
• CloudTrail data event：GetSecretValue 是 Data event、預設不記、要手動開 data event logging — 沒開等於事故時看不到 誰拿了 secret、只看得到 management API（CreateSecret / UpdateSecret）

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

日常操作與決策形狀

Resource Policy + IAM Policy 雙層 grant：Secrets Manager 跟 S3 bucket policy 同模型 — IAM Policy 控制 principal 端能做什麼、Resource Policy 控制 secret 端允許誰來、兩者要 都同意 才放行。常見錯配：Resource Policy 寫 Principal: "*" 加 aws:SourceAccount condition 想做跨帳號 share、但 condition 漏寫或寫錯就變成公開可讀。跨帳號 share 一定要明確列 Principal: arn:aws:iam::123456789012:role/AppRole、不要靠 wildcard + condition 拼隔離。

IAM Policy 細粒度授權：secretsmanager:GetSecretValue 該限定到 specific secret ARN（不是 *）、配合 ABAC tag condition（secretsmanager:ResourceTag/team = payments）限縮 blast radius。對應 CircleCI 2023 Secrets Rotation — CI 出事時要能依 tag 快速列出 CI runner 可拿的所有 secret、沒這套 tag 就只能盲目 rotate 全部。

KMS encryption key 選 CMK 不是 default：每個 secret 用一把 KMS key 加密、預設用 AWS-managed key aws/secretsmanager、production 應該換 customer-managed key（CMK）。差別在 key policy 是不是自己控 — AWS-managed key 的 policy 同 account 任何 service 可呼叫、CMK 的 key policy 可以鎖到 only Secrets Manager service principal 加 only specific role 可 Decrypt。對應 Storm-0558 的對照啟示：key 的 blast radius 來自 key policy、用 CMK 把 policy 寫窄是減 blast radius 的關鍵動作。

Built-in Rotation Lambda 只限 AWS native DB：Secrets Manager 內建 rotation template 涵蓋 RDS（PostgreSQL / MySQL / MariaDB / Oracle / SQL Server）/ Aurora / Redshift / DocumentDB — 拿 AWS 提供的 Lambda template、設定 rotation interval（最短 1 天、最長 365 天）、Secrets Manager 自動排程觸發。其他 DB（self-hosted PostgreSQL、MongoDB Atlas、Snowflake）或 API key 要寫 Custom Rotation Lambda、走 4-step state machine：createSecret（產新 credential 存為 AWSPENDING）、setSecret（把新 credential 寫到 target system）、testSecret（用新 credential 驗證可連）、finishSecret（promote AWSPENDING → AWSCURRENT）。Lambda 任一步失敗 Secrets Manager 會 rollback、舊 credential 不受影響。

Staging Label（AWSCURRENT / AWSPENDING / AWSPREVIOUS）：staging label 是 指向 version 的 pointer、app 一律用 GetSecretValue 不帶 VersionStage 拿 AWSCURRENT、rotation 過程中 Secrets Manager 先把新 credential 標 AWSPENDING、testSecret 過後 promote 到 AWSCURRENT、舊的降到 AWSPREVIOUS。設計初衷是 zero-downtime rotation — 但 只有 app 端支援 AWSPREVIOUS fallback 期間才有意義：rotation 完成瞬間有些 app instance 還拿著舊 credential，target system 應該同時接受 AWSCURRENT 跟 AWSPREVIOUS（DB rotation template 會在 setSecret 階段保留舊 user 一段時間）。對應 Failure: Credential Rotation Without Scope：scope map 沒做、AWSPREVIOUS 窗口期太短、長尾 batch job 拿到舊 credential 就掛。

Cross-Region Replica：multi-region app 把 secret replicate 到其他 region、replica 在 replica region 有獨立 ARN、KMS key 跟 rotation 都要在 replica region 各自配（不能跨 region 共用 KMS key）。replica 是 讀副本、寫只能在 primary region、rotation 觸發後新 version 自動 sync 到 replica（有秒級延遲）。failover 時 app 直接讀 replica region ARN、不需要 cross-region call。

Cross-Account Sharing：跨帳號 share secret 走 Resource Policy + 對方帳號 IAM Policy 雙向授權 — Resource Policy 列對方 account 的具體 role ARN、對方 role 的 IAM Policy 加 GetSecretValue 對應 ARN。KMS key 也要跨帳號授權（KMS key policy 加對方 role 的 Decrypt 權限）— 漏了 KMS 授權會出現 GetSecretValue 成功但 Decrypt 失敗 的詭異錯誤。

核心取捨表

選 Secrets Manager 的核心訴求：AWS-only + 大部分 secret 是 static 或 AWS native DB credential + 需要 cross-account share 或 rotation Lambda + 不想 / 沒量能自管 Vault。如果只是要存 config（feature flag、non-sensitive endpoint）、Parameter Store 8 倍便宜；如果跨雲 + 需要 dynamic credential / transit / PKI、Vault 才能滿足。

進階主題

Custom Rotation Lambda 設計：4-step state machine 是 idempotent contract — Lambda 必須能被 Secrets Manager 重試任意步驟而不破壞狀態。常見實作陷阱：createSecret 不檢查 AWSPENDING 是否已存在、重試時又產生一把新的、AWSPENDING 對不上 setSecret 寫進去的；setSecret 沒處理「target system 已經有同名 user」的情況、第二次跑會卡住。Template 提供的 PostgreSQL rotation Lambda 用 cloning approach — 在 DB 內 clone 一份 user、改密碼、保留舊 user 跨 rotation 一個週期、下次 rotation 才 drop。

Resource Policy + ABAC tag 跨帳號：跨帳號 share 時用 ABAC tag 條件比硬列 role ARN 有彈性 — Resource Policy 寫 Condition: aws:PrincipalTag/team = payments、對方 account 任何帶該 tag 的 role 都可讀。代價是 tag 治理 變成 critical control：對方 account 內誰能 attach tag = 誰能拿 secret、IAM Policy 要鎖 iam:TagRole 跟 iam:UntagRole 權限。

Rotation 失敗的監控訊號：Lambda 執行失敗會在 CloudWatch 留 invocation error、Secrets Manager 把 rotation 標記為 failed、但 secret 仍可用（AWSCURRENT 保留舊 version）— 容易出現 半年沒 rotate 成功但 app 看起來正常 的盲區。要監控 SecretsManager.RotationFailed event（EventBridge rule）+ LastRotatedDate metric 超過 rotation interval 1.5 倍就 alert。

跟 AWS IAM 整合：誰可以 GetSecretValue 完全由 IAM 控制、最佳實踐是 workload role 拿 secret（EC2 instance role / ECS task role / Lambda execution role / EKS IRSA）、不要硬把 AWS credential 塞進 secret 再給 application read。Secret 內容應該是 DB password / API token / third-party credential、不應該是 AWS credential（AWS credential 用 IAM role 短期 STS 拿就好）。

CloudTrail data event 的成本權衡：開 GetSecretValue data event 等於每次 secret 取用都進 CloudTrail、高 QPS application 一天可能跑數百萬筆、CloudTrail 成本（每 100k events 約 $0.10）跟 S3 儲存成本會明顯上升。降本作法：在 EventBridge 用 filtering（只送特定 sensitive secret 的 data event 到 SIEM）、CloudWatch Logs 端設 retention 短一點（7-30 天熱資料、長尾走 S3 + Athena）。

排錯與失敗快速判讀

• GetSecretValue AccessDenied 但 IAM Policy 看起來對：檢查 Resource Policy 是否限定 source account / VPC、檢查 KMS key policy 是否允許該 role Decrypt — 兩層 grant + KMS 三點任一缺都會 AccessDenied
• 跨帳號 secret 拿不到：Resource Policy 沒列對方 role、或 KMS key policy 沒給對方 Decrypt 權限 — 跨帳號要同步配三處（Resource Policy + 對方 IAM + KMS key policy）
• Rotation 一直失敗但沒人發現：沒設 EventBridge alert on RotationFailed、AWSCURRENT 保持舊 version、app 正常但 secret 過期 — 必設 LastRotatedDate metric alert
• App 拿到 stale secret rotation 後爆掉：app 端用了 SDK cache（如 AWS SDK 的 Secrets Manager Cache）、rotation 完成後 cache 沒 invalidate — cache TTL 要短於 staging label 重疊窗口、或實作 retry-on-auth-fail 觸發 cache refresh
• CloudTrail 看不到誰拿 secret：沒開 data event logging — 在 CloudTrail trail 設定加上 AWS::SecretsManager::Secret 為 data resource
• 跨 region replica rotation 失效：rotation Lambda 只在 primary region 配、replica region 沒對應 Lambda — 每個 region 各自配 Lambda、或乾脆只在 primary rotate 讓 replica 自動 sync
• AWSPREVIOUS fallback 沒生效 batch job 掛：rotation Lambda finishSecret 太快 drop 舊 user、batch job 拿到舊 credential 連 DB 失敗 — DB rotation template 預設保留舊 user 一個 rotation 週期、custom Lambda 要自己實作雙軌窗口

何時改走其他服務

不在本頁內的主題

• Secrets Manager 完整 API reference 跟 SDK 用法
• 每種 RDS engine 的 rotation Lambda template 內部 SQL 細節
• AWS pricing 詳細計算（每 region 略有差異）
• Terraform / CDK 跟 Secrets Manager 的 IaC 整合
• AWS account organization / SCP 怎麼限制 secret 建立

案例回寫

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

下一步路由

• 上游：7.6 秘密管理與機器憑證治理、7.13 偵測覆蓋率與訊號治理
• 平行：HashiCorp Vault、Google Secret Manager、Azure Key Vault
• 下游：AWS KMS（Secrets Manager 加密 key custodian、CMK 與 key policy 治理）
• 下游：AWS IAM（誰可以 GetSecretValue、跨帳號 share 的 principal 來源）
• 跨模組：8 事故處理 vendor 清單（secret 外洩事件如何 routing 進 IR 流程）
• 官方：AWS Secrets Manager Documentation

服務定位

AWS WAF 的核心定位是 跟 AWS 服務深度耦合的 L7 防護層。Web ACL 直接掛 AWS resource、規則用 IAM policy 管理、log 進 Kinesis Firehose / CloudWatch Logs / S3、跟 AWS Shield Standard（內含、L3/L4 DDoS）自動整合。這跟 Cloudflare WAF 在 origin 之前的 edge 攔截不同 — AWS WAF 流量 已經進到 AWS 邊界、不是擋在外部。對 origin 跑在 ALB / CloudFront / API Gateway 後的客戶、AWS WAF 是天然選項；origin 在其他雲或地端、AWS WAF 觸不到。

跟 Fastly Next-Gen WAF 相比、AWS WAF 走 signature + managed rule group 偵測模型、不像 Fastly NG-WAF 走語意 / behavioral；AWS WAF 的 Managed Rule Group 來自 AWS Managed 與 AWS Marketplace 第三方（Fortinet、F5、Imperva 等）、客戶端 看不到 rule logic、debug 時要靠 sampled request 反推。

計費模型也是關鍵差異：AWS WAF 按 per-Web-ACL + per-rule + per-request 計費（單 ACL $5/月、單 rule $1/月、$0.60 per 1M request），Managed Rule Group 算多 rule、開太多套 ruleset 與流量大時帳單會明顯漲。Cloudflare 是 plan-tier 計費（Pro / Business / Enterprise）、不會因為多開 rule 線性漲價。

本章目標

讀完本頁、讀者能判斷：

1. AWS WAF 在 AWS-internal 防護 stack 中承擔哪一段、哪些要靠 AWS Shield / VPC / CloudFront 補位
2. Web ACL scope（Regional vs CloudFront）的選擇與跨 region 部署成本
3. Managed Rule Group / Custom Rule / Rate-based Rule 的取捨、Bot Control add-on 是否值得開
4. 何時用 AWS WAF、何時走 Cloudflare WAF / Fastly NG-WAF 的判準

最短判讀路徑

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

• Web ACL scope 對不對：CloudFront distribution 必須掛 CloudFront scope（強制在 us-east-1 建立 ACL）、ALB / API Gateway 必須掛 Regional scope（每個 region 各一份）；scope 配錯掛不上去、跨 region 部署是否用 IaC（Terraform / CloudFormation）同步複製 ACL
• Managed Rule Group 與 sensitivity：是否啟用 AWSManagedRulesCommonRuleSet（CRS）、AmazonIpReputationList（已知惡意 IP）、AnonymousIpList（VPN / proxy / Tor）、KnownBadInputsRuleSet（已知 exploit pattern）、Marketplace rule 是否在 Count mode 觀察 1-2 週 FP 再切 Block
• Logging 有沒有開：Web ACL log 預設關閉、必須手動配 Kinesis Firehose / CloudWatch Logs / S3 destination；event 是否進 SIEM（見 7.13 偵測覆蓋率與訊號治理）、是否能對 sampled request 反推 rule 行為
• IAM 邊界：誰能 update Web ACL（wafv2:UpdateWebACL、wafv2:UpdateRuleGroup）、是否限定 admin role 才能改、CI 是否只有 wafv2:Get* / List* 用來 verify、敏感變更是否走 Change Management / Audit Log

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

日常操作與決策形狀

Web ACL 與 scope：Web ACL 是 AWS WAF 的 規則容器、必須 attach 到 AWS resource。Scope 兩種：Regional（給 ALB / API Gateway / App Runner / AppSync / Cognito User Pool、每 region 獨立）與 CloudFront（給 CloudFront distribution、必須在 us-east-1 建立、全球生效）。同一個 ACL 不能跨 scope 共用；跨 region 部署同一套規則必須複製 ACL、用 Terraform / CloudFormation 管理避免 drift。

Rule action 五種：每個 rule 觸發時可以做 Block（直接 403）、Allow（跳過後續 rule、放行）、Count（不擋、只記錄、用於 dry-run 觀察 FP）、CAPTCHA（出題給人類解、bot 過不去）、Challenge（silent JS challenge、無感驗證）。新 rule 上線標準動作是先 Count 1-2 週看 sample、確認 FP 在容忍範圍才切 Block。CAPTCHA / Challenge 是 Bot Control add-on 配套、要額外計費。

Managed Rule Group（managed by AWS / Marketplace）：AWS Managed（免費含在 WAF）涵蓋 Common Rule Set（OWASP top10 對應）、Known Bad Inputs、SQL Database、Linux、Unix、Windows、Anonymous IP List、Amazon IP Reputation List、Account Takeover Prevention (ATP)、Account Creation Fraud Prevention (ACFP)。AWS Marketplace（付費）來自 Fortinet / F5 / Imperva / Cyber Security Cloud 等。Marketplace 規則 不公開 rule logic、攔錯時只能用 sampled request 反推、debug 比 AWS Managed 困難。

Custom Rule（statement + 條件）：Custom Rule 用 statement（match condition + transformation）組合：IP Set match、Geo match、Regex Pattern Set、Size constraint、SQL injection match、XSS match、String match（含 header / body / URI / query 各部位）。複雜條件用 AND / OR / NOT 組合、上限是每 Web ACL 5,000 Web ACL Capacity Units（WCU）— 規則越複雜 WCU 越高、Marketplace 大型 rule group 可能直接吃掉一半 budget。

IP Set / Regex Pattern Set：IP Set 存 IPv4 / IPv6 CIDR 清單、Regex Pattern Set 存正則表達式集合。兩者都是 獨立資源、可在多個 Web ACL 引用、單獨更新（不必動 Web ACL 結構）。實務上 threat intel feed 應該 push 到 IP Set、用 Lambda 自動 sync、不用手動加。

Rate-based Rule：限制 單一 aggregate key 在滾動 5 分鐘窗口內的請求數、超過 threshold 觸發 action。aggregate key 可選 IP、Forwarded-IP（看 X-Forwarded-For）、HTTP method、URI path、Header、Cookie 或組合。關鍵陷阱：CloudFront 後 origin ALB 必須用 Forwarded-IP、否則 Rate-based Rule 看到的全是 CloudFront 邊緣節點 IP、所有真實使用者被合併計算、要嘛全擋要嘛全放。

Logging 必須手動開：Web ACL log 預設關閉、destination 三選一：Kinesis Data Firehose（推到 S3 / Splunk / Datadog）、CloudWatch Logs（簡單但貴）、S3（直寫、需自己處理 partition）。production 通常走 Kinesis Firehose → S3 + Athena query、配合 SIEM 拉 alert。沒開 log 等於 攻擊發生時沒證據、事後無法回查。

跟 AWS Shield 整合：所有 AWS WAF 客戶自動含 Shield Standard（L3/L4 DDoS、免費、SYN flood / UDP reflection 等基礎防護）。Shield Advanced 是付費 add-on（$3,000/month per organization + per-resource fee + data transfer out fee）、提供 24/7 DRT（DDoS Response Team）、cost protection（DDoS 期間 AWS service scaling fee 補貼）、進階分析。一般客戶 Shield Standard 已足夠；金融 / 政府 / 高知名度品牌需要 Shield Advanced 的 DRT 與 cost protection。

Lambda@Edge / CloudFront Functions 補位：當 WAF rule statement 表達不出複雜業務邏輯（geofencing + business hour + user tier 組合、JWT claim 解析後判斷 routing）、用 Lambda@Edge（Node.js / Python、跑在 CloudFront 邊緣節點、4 個 phase：viewer-request / origin-request / origin-response / viewer-response）或 CloudFront Functions（純 JS、輕量、低延遲、只在 viewer-request / viewer-response）補位。Lambda@Edge 適合複雜邏輯、CloudFront Functions 適合 header rewrite / 簡單 routing；兩者都不能取代 WAF managed rule、但補位 WAF 表達力上限。

跟 AWS IAM 整合：誰能改 Web ACL 是 IAM policy 決定（wafv2:CreateWebACL、wafv2:UpdateWebACL、wafv2:AssociateWebACL、wafv2:UpdateRuleGroup 等 action）。production 標準配置：admin role 才能 update、CI / 開發者只有 wafv2:Get* / List* 用來 verify、敏感變更走 Change Management + CloudTrail audit log。

核心取捨表

選 AWS WAF 的核心訴求：AWS-internal app + origin 跑在 ALB / CloudFront / API Gateway / App Runner 後 + 想跟 IAM / CloudTrail / Shield 同套 control plane 治理。Origin 不在 AWS、或要 把攻擊擋在抵達雲之前、應該走 Cloudflare WAF 或 Fastly NG-WAF。

進階主題

AWS WAF Bot Control（add-on）：付費 add-on、用 AWS 自家 bot fingerprinting 區分 verified bot（搜尋引擎）/ signal: automated browser（headless Chrome 等）/ signal: known bot（已標記 IoT / scraper），給每個請求 bot category label。Custom Rule 在 label 上做條件、決定 Block / Challenge / CAPTCHA。比 user-agent 過濾準很多、但要額外計費（per-request）。Bot Control 有兩個 inspection level：common（便宜、基礎指紋）與 targeted（貴、含 JavaScript challenge、CAPTCHA、token-based）。

Fraud Control（ATP / ACFP）：Account Takeover Prevention（ATP）跟 Account Creation Fraud Prevention（ACFP）是 Managed Rule Group 的特殊類別、需付費啟用。ATP 看登入端點的 credential stuffing、ACFP 看註冊端點的 bot signup。兩者都用 AWS 自家 threat intel（被竊憑證 list、行為模型）打 label、客戶側用 Custom Rule 處理。對有 login / signup 端點的 SaaS / 電商有價值、純內部後台不必開。

CAPTCHA / Challenge：AWS WAF 內建 CAPTCHA puzzle 與 silent JS Challenge、可在 rule action 直接呼叫。Challenge 在客戶端執行 proof-of-work、合法瀏覽器無感、headless 工具卡住；CAPTCHA 是視覺題、人類解、bot 不會。Production 標準做法：Bot Control 給 label → Custom Rule 看 label → likely bot 走 Challenge、known bad 走 Block、人類流量直接 Allow。

ACM Private CA + WAF 對 mTLS：AWS WAF 本身不做 mTLS 驗證、mTLS 是 ALB / API Gateway / CloudFront 自己的功能（搭配 AWS ACM Private CA 簽發 client cert）。WAF 在 mTLS 完成後才看 L7 流量、可以用 HTTP header match（mTLS 後 ALB 注入 client cert 資訊到 header）做進一步 rule。Internal API 用 mTLS + WAF 是常見組合。

Lambda@Edge 補 inline business logic：複雜判斷（user tier × geo × business hour × A/B test）WAF rule statement 表達不出來、用 Lambda@Edge 在 viewer-request phase 解析 JWT、查 internal risk API、回 response header 給 WAF 後續判斷。代價：Lambda@Edge 部署只能在 us-east-1、code 更新傳播到全球 edge 要幾分鐘、debug 是分散式 CloudWatch Logs。

排錯與失敗快速判讀

• Web ACL 掛不上 CloudFront：scope 配成 Regional、CloudFront 拒絕 attach — Web ACL 必須在 us-east-1 + CloudFront scope 才能掛 CloudFront；ALB / API Gateway 反過來只能掛 Regional scope
• Rate-based Rule 全擋 / 全放：CloudFront 後 origin 看到全部都是 CloudFront IP、aggregate key 沒換 Forwarded-IP — 改用 Forwarded-IP（X-Forwarded-For）作 aggregate key，並設 Fallback behavior
• Managed Rule Group 誤殺合法請求：CRS High sensitivity 開後 file upload / rich text editor 端點被 Block — 找 sampled request 看 rule_id、用 Scope-down statement 限定該 rule 在某 path 不執行、或開該 rule 為 Count、不要關整個 group
• Marketplace Rule 攔不明流量：Marketplace rule logic 不公開、sampled request 看到 rule label 但不知為何 — 切該 rule 到 Count mode 觀察、若無 attack 跡象換 AWS Managed 同類 rule
• WCU 超限：Web ACL 上限 5,000 WCU、加 Marketplace + 多個 AWS Managed 就會爆 — 看 Capacity Used、移除重疊 rule、把 Custom Rule 表達式簡化（少用 transformation chain）
• Logging 沒設 / 設錯：事件發生後沒有完整 log 可查、只有 sampled request（保留 3 小時、機率抽樣） — 必開 Logging configuration 到 Kinesis Firehose / S3 / CloudWatch Logs、確認 IAM role 有 firehose:PutRecord 權限
• IAM 權限過寬：CI account 拿到 wafv2:* 整 zone 都能改 — 收斂到 wafv2:Get* / List* 唯讀、敏感寫入限 admin role + MFA + Change Management
• 跨 region 部署 drift：手動在 console 改 us-east-1 ACL、其他 region 沒同步 — 用 Terraform / CloudFormation IaC 管理、PR review、CI plan 檢查 drift
• Shield Standard 不夠擋大型 L7 DDoS：Standard 只防 L3/L4、L7 attack 靠 WAF Rate-based Rule + Bot Control — 若反覆遭遇大型 L7 DDoS、評估 Shield Advanced 的 DRT + cost protection 是否值得

何時改走其他服務

不在本頁內的主題

• AWS WAF Classic（v1）的遷移細節 — 本頁全以 WAFv2 為準
• 完整 WCU 計算規則與每個 statement 的 WCU cost reference
• Marketplace 第三方 rule group 各家功能矩陣
• AWS WAF 在 GovCloud / China region 的差異
• Bot Control / ATP / ACFP 完整 label schema reference

案例回寫

AWS WAF 在 07 案例庫無直接 vendor-level case、但多個 case 對應 WAF 作為 修補窗口期臨時控制 與 entry point 治理 的角色：

下一步路由

• 上游：7.3 入口治理與伺服器防護
• 平行：Cloudflare WAF、Fastly Next-Gen WAF
• 下游：7.4 資料保護與遮罩治理（WAF block 不夠時、資料層也要遮罩）
• 跨類：AWS IAM（誰能改 Web ACL）、AWS ACM（mTLS client cert）、AWS Secrets Manager（rule update 用的 API key）
• 跨模組：8 事故處理 vendor 清單（WAF block 事件如何 routing 進 IR）
• 官方：AWS WAF Documentation

服務定位

Elastic Security 的核心定位是 Elastic Stack 上的 security solution、底層是 Elasticsearch（資料層）+ Kibana（查詢與 UI 層）+ Fleet / Elastic Agent（採集層）、頂層產品分三條：Elastic SIEM（log aggregation + detection rule + Case + Timeline）、Elastic Defend（前 Endgame 收購而來、EDR + endpoint protection、跟 CrowdStrike / SentinelOne 同層）、Elastic Cloud Security（CSPM + CWP、雲端資源 misconfig 與 workload 防護）。

跟 Splunk 比、Elastic 走 OSS-friendly + resource-based pricing — TB-scale ingestion 不直接漲費用（要 scale node 但邊際成本遠低於 Splunk per-GB 累進）、Sigma rule 社群可直接 import 5000+ 規則；但 Splunk Security Content 跟 SOAR / RBA 等 detection content + SOC tooling 成熟度仍高一個量級。跟 Datadog Security 比、Elastic 跨 on-prem + 多雲、可自管也可 Elastic Cloud SaaS；Datadog 是 SaaS-only、適合純 cloud-native。跟 Google Security Operations 比、Elastic 多查詢語言（KQL / EQL / Lucene / ES|QL）、Google 走 YARA-L 單一統一語言、超大規模 ingestion Google 反而划算。

關鍵張力：多查詢語言模型 同時是 Elastic 的優勢跟負擔。EQL 寫 attack chain sequence 比 SPL correlation 更直接、KQL 過濾快、ES|QL 寫 aggregation 像 SQL 直覺、Lucene 處理 full-text；但 SOC team 要決定哪個 rule 用哪個語言、不能讓每個 analyst 各寫各的。

本章目標

讀完本頁、讀者能判斷：

1. Elastic Security 在 SOC stack 中承擔哪一段（log aggregation / SIEM / EDR / CSPM）、哪些要外接（Okta IdP log、Vault secret rotation）
2. KQL / EQL / Lucene / ES|QL 四種查詢語言的職責分工（誰用在哪種 rule、誰負責教育 SOC）
3. Resource-based pricing 的治理（cluster sizing、hot-warm-cold tier、Searchable Snapshots、Elastic Cloud Serverless）
4. 何時用 Elastic、何時走 Splunk / Datadog / Google Security Ops 的取捨

最短判讀路徑

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

• 誰能改 detection rule：Elastic Security app 的 rule editor 權限、detection-rules repo（Elastic 官方 OSS rule 庫）有沒有 fork 進組織版控、rule change 是否走 PR review + staging space 驗證
• 採集治理：Fleet 統一管 Elastic Agent policy / 還是散落 Beats（filebeat / metricbeat / auditbeat / winlogbeat）各自設定、log source 是否分 hot / warm / cold tier、Searchable Snapshots 是否開
• Detection content coverage：Elastic Prebuilt rules + Sigma 社群規則 import 多少 enabled、是否跟 MITRE ATT&CK 對照、EQL sequence 規則覆蓋多少 attack chain pattern
• Alert quality / SOC handoff：alert volume per day、Case 跟 Timeline 是否進入日常 SOC workflow、ML anomaly job 是否在線 + threshold 是否 tuned、跟 8 incident response 的 routing 是否定義

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

日常操作與決策形狀

Ingestion architecture：log 進 Elastic 三種主路徑 — Elastic Agent + Fleet（現代部署的預設、單一 agent 收 system / endpoint / cloud / app log、中央 Fleet server 統一管 policy）、Beats（filebeat / metricbeat / auditbeat / winlogbeat 等專用 agent、Fleet 推出前的傳統做法、現在持續支援但建議遷移到 Elastic Agent）、Logstash（pipeline-style ETL、用在 enrich / filter / route 複雜場景）。production 通常 Elastic Agent + Fleet 為主、Logstash 補 ETL 缺口。

KQL / EQL / Lucene / ES|QL 的職責分工：四種查詢語言各有 first-class 場景。KQL（Kibana Query Language）是 Kibana 預設過濾語法、user.name : "alice" and event.action : "logon-failed"、簡單直觀、適合 dashboard / Discover 過濾。EQL（Event Query Language）做 sequence pattern matching、sequence by user.name [authentication where event.outcome=="failure"] [authentication where event.outcome=="success" and source.geo.country != "TW"]、表達 attack chain 比 SPL correlation 更直接。Lucene 是底層 full-text query、特殊需要時直接寫。ES|QL（Elasticsearch Query Language、2024+）是新版 SQL-like、FROM logs-* | WHERE event.category == "authentication" | STATS count = COUNT(*) BY user.name、寫 aggregation 直覺；屬新語言、production 採用 cadence 還在跟進中。

Detection rule 種類：Elastic Security 的 rule type 是六種 first-class 概念、不是只有「query rule」一種 — Query rule（KQL / Lucene 觸發）、EQL rule（sequence pattern）、Threshold rule（聚合超過閾值、例如同一 IP 5min 內 login fail > 100）、ML rule（綁 Elastic ML anomaly job、anomaly score 超過閾值觸發）、New term rule（首次出現的 entity、例如某 user 第一次從某國登入）、Indicator match rule（事件 enrich 比對 threat intel feed、IoC hit 觸發）。production rule 經常組合多種 — query rule 做粗篩、EQL rule 抓 sequence、threshold + ML 補 baseline anomaly。

Sigma rule import：Sigma 是 OSS 通用 detection rule 格式（YAML、跨 SIEM 可移植）、社群維護 5000+ 規則。Elastic 支援直接 import Sigma rule 轉成 Elastic detection rule、是 Elastic 拉開跟商業 SIEM 距離的 OSS 槓桿。實務做法：先 import Sigma baseline + 全部走 staging space 跑 false positive 觀察、再 enable 到 production；不要直接全 enable、Sigma rule 跨 SIEM 通用所以 environment-specific tuning 必須自己做。

Case + Timeline：Case 是 incident 容器、聚合 alert + comment + assignment + status；Timeline 是 SOC analyst 的 investigation workspace、可以 pin event / annotate / link related alert、產出 investigation narrative。兩者組合是 Elastic 的 SOC workflow first-class、不是外掛 — 對應 Splunk ES 的 Notable Event + Incident Review、但 Elastic 走 OSS 化、Case 可 export markdown 進 ticketing。

Elastic Defend（EDR）：前 Endgame 收購整合、提供 endpoint detection + prevention（malware block / ransomware protection / behavior detection）、跟 CrowdStrike Falcon / SentinelOne 同層。Elastic Defend 跑在 Elastic Agent 內、policy 從 Fleet 推。實務上多數 SIEM 客戶不會用內建 EDR、而是外接專業 EDR feed 進 Elastic SIEM；但 OSS-friendly + 預算敏感的中型客戶可以直接整合到一個 stack。

Cross-cluster search：跨多個 Elastic cluster 統一查詢（remote_cluster:index-name）、適合 multi-region / multi-tenant SOC、不需要把所有 log 搬到單一 cluster。對應 Splunk Cloud federated search。實務場景：歐洲 GDPR 資料留在 EU cluster、美國 cluster query 過去做 incident investigation 而不複製資料。

ML jobs（anomaly detection）：Elastic ML 內建 unsupervised anomaly detection、pre-built ML job library 覆蓋 SOC 常見場景（user behavior baseline、host login pattern、port scan detection、rare process）。ML rule 綁 ML job、anomaly score 超過閾值觸發 detection rule。對應 Splunk UBA、但 Elastic ML 是 stack 內建、不是 add-on app。

Resource-based pricing 治理：Elastic Cloud 按 cluster size（node count × node size）計費、不按 ingestion volume — 意義是 ingest 多 log 不直接漲費用、但要 scale node 維持查詢效能。實務治理：hot tier（最近 7-30 天、SSD 高效能 node）、warm tier（30-90 天、低 IO node）、cold tier / frozen tier（90 天以上、Searchable Snapshots on S3 / GCS、查詢慢但成本極低）。對應 Splunk SmartStore、但 Elastic frozen tier 把 retention 從幾個月延長到幾年、cost 不線性漲。

核心取捨表

選 Elastic 的核心訴求：OSS-friendly 文化 + resource-based pricing 友善 + Elastic Stack 已作為 observability 在用、團隊有能力跨四種查詢語言（或至少把 EQL 跟 KQL 雙語分工清楚）、能接受 detection content 跟 SOAR 成熟度 trade-off。TB-scale ingestion 時 Elastic 比 Splunk 省 60-80% license cost 是最大誘因、但要算進 cluster sizing 跟 SRE 維運的隱形成本。

進階主題

EQL sequence pattern（時序攻擊鏈）：EQL 的 sequence by 是 Elastic 表達 attack chain 的 first-class 武器、比 SPL correlation 直接。例如 MFA fatigue 寫成 sequence by user.name with maxspan=5m [authentication where event.outcome=="failure"] [authentication where event.outcome=="failure"] [authentication where event.outcome=="success" and source.ip != known_ip]、序列邏輯直接表達。配對 Uber 2022 MFA Fatigue lesson：MFA fail 序列 + 新裝置 success 直接觸發。

Elastic Defend endpoint response：除偵測外、Defend 支援 host isolation（隔離受感染 endpoint 但保留 SOC 連線）、process kill、file quarantine 等 response action、直接從 Kibana Security app 觸發。對應 CrowdStrike Real Time Response。production 採用前要設 approval gate、避免 SOC analyst 誤觸動 production server。

CSPM / CWP（Elastic Cloud Security）：CSPM（Cloud Security Posture Management）對 AWS / GCP / Azure 帳號做 misconfig 掃描（S3 bucket public、IAM over-permission、security group 0.0.0.0/0）、對照 CIS Benchmark；CWP（Cloud Workload Protection）對 Kubernetes workload 跑 runtime detection。屬較新的功能、跟 Wiz / Lacework 等專業 CNAPP 比覆蓋還在追趕。

Cross-cluster search 跨環境 federated query：multi-region SOC 的 first-class 工具 — query 寫 FROM logs-auth-*, eu-cluster:logs-auth-*、Elastic 自動路由跨 cluster。實務注意：跨 cluster query 延遲較高、要設 timeout；資料合規（GDPR）必須留意 query 結果是否包含跨境資料、不是搬資料但 query 結果回傳算不算傳輸要法務確認。

Sigma 規則社群：Sigma 是 OSS detection rule 通用格式、Elastic 是 Sigma 主力使用者（內建 importer + Elastic 工程師參與 Sigma upstream）。實務做法：fork SigmaHQ repo 進組織版控、CI pipeline 自動轉 Sigma → Elastic detection rule、staging space 跑 false positive curve、promote 到 production；不要每次 manually import。

Elastic Cloud Serverless（2024+）：新模型、按 workload type（search / observability / security）計費、不再按 cluster size — 減少 sizing 決策、autoscaling 由 Elastic 託管。屬新模型、production 採用 cadence 還在跟進中、適合 greenfield 部署或 PoC、existing cluster 遷移 roadmap 還在演進。

排錯與失敗快速判讀

• Alert volume 爆炸 / SOC 看不完：Sigma rule 全 enable 沒 tune、或 threshold rule 閾值太低 — staging space 跑 1 週統計 FP、tune threshold、加 exception list 排除已知合法 source、ML rule 補 user-specific baseline
• EQL sequence rule 跑不動 / timeout：sequence span 太長（24h）或 by field cardinality 太高、查詢成本爆炸 — 縮短 maxspan、限定 index pattern、加 pre-filter 條件
• Cluster 查詢慢 / Kibana 卡：hot tier 塞太多舊資料、沒做 hot-warm-cold tier 分層 — 開 ILM（Index Lifecycle Management）policy 自動 rollover、warm tier 用便宜 node、cold / frozen 走 Searchable Snapshots
• Fleet agent enrollment 失敗：Fleet server 跟 Elasticsearch 之間網路 / 憑證 / token 問題 — 檢查 Fleet server health、確認 enrollment token 未過期、agent log 看 specific 錯誤
• Sigma rule import 後大量 FP：Sigma rule 是 cross-SIEM 通用、沒有 environment-specific exclusion — 不要全 enable、staging tune 後再 promote、加 exception list（known scanner IP / 內部測試帳號）
• Resource-based pricing 超預算：node 過度 scale 或 hot tier 留太多 — 開 hot-warm-cold ILM、把 retention 超過 30 天的 index 推到 frozen tier on S3、Searchable Snapshots 是預設應該開
• ML job anomaly score 不準：training data 包含已 compromise 期間、baseline 被汙染 — 確認 training window 在乾淨期、定期重訓、配 detection rule 用 anomaly_score > 75 而非 > 50

何時改走其他服務

不在本頁內的主題

• KQL / EQL / ES|QL 完整語法 reference、Lucene query DSL 進階用法
• Elasticsearch index sharding / replica / ILM tuning 細節（屬 observability / 資料工程範圍）
• Elastic Observability（APM / logs / metrics）— 屬 observability 不屬 security
• Elastic Cloud Serverless 詳細 sizing 與 pricing 模型（2024+ 新模型、變動中）
• Elastic Stack 自管的維運（cluster upgrade、Kibana plugin 開發）

案例回寫

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

下一步路由

• 上游：7.13 偵測覆蓋率與訊號治理、Detection Engineering Lifecycle
• 平行：Splunk、Datadog Security、Google Security Operations
• 下游：Google DLP / Microsoft Purview（DLP signal 進 Elastic SIEM）
• 跨類：Okta（IdP log source）、HashiCorp Vault（secret rotation API）、Cloudflare WAF（WAF log + Sigma rule 對接）
• 跨模組：8 事故處理 vendor 清單（Case → IR routing）、4 observability（Elastic Stack 共用 log pipeline）
• 官方：Elastic Security Documentation、detection-rules repo

服務定位

JMeter 是 Apache Software Foundation 的 OSS load testing tool、Java 寫、用 XML 描述 thread group / sampler / listener 組成的 test plan（.jmx 檔）、支援 GUI 與 CLI（non-GUI / headless）雙模式。它是業界最老牌、protocol 覆蓋最廣的壓測工具 — sampler 直接覆蓋 HTTP、JDBC、JMS、SOAP、FTP、SMTP、IMAP、TCP、JUnit、OS process 等。

跟 k6 比、JMeter 走 GUI-driven + protocol 廣、k6 走 code-first（JavaScript）+ HTTP 為主；JMeter 適合 QA 團隊維護、k6 適合 dev / SRE 寫進 CI。跟 Locust 比、JMeter 用 XML + plugin、Locust 用純 Python class、custom client 彈性 Locust 強但 protocol 內建支援 JMeter 廣。跟 Gatling 比、JMeter 偏 GUI / 多 protocol、Gatling 偏 JVM DSL（Scala / Java / Kotlin）+ async runtime、單機 throughput Gatling 較高但 protocol 廣度與既有資產承接 JMeter 勝。

關鍵張力：GUI / protocol 廣度 ↔ 單機 throughput / CI 友善度 是選 JMeter 的根本取捨。GUI 適合 QA 團隊與跨角色協作、.jmx 又有 plugin 生態與十多年累積；代價是 XML diff 難 review、GUI listener 吃記憶體、CI 整合相比 k6 / Gatling 多一層 packaging。

JMeter 適合測試資產已經存在的組織。當團隊有大量 .jmx 測試計畫、QA 團隊用 GUI 維護 scenario、或壓測需要跨 HTTP、JDBC、JMS 與其他 plugin protocol，JMeter 的價值在於承接組織流程，而不只是產生 HTTP 負載。這個定位讓 JMeter 接到 9.3 壓測工具選型 與 9.10 Production-Side 驗證。它能支援 production-like test 的多系統 dependency，但 evidence package 要補上測試計畫版本、plugin 版本、runner 配置與結果保存方式。

適用場景

多 protocol 壓測是 JMeter 的主要入口。企業服務常同時需要測 HTTP API、JDBC query、JMS queue、FTP 或 mail flow，JMeter 的 sampler 與 plugin 生態能讓同一份測試計畫覆蓋多種 dependency。

GUI 協作適合非純工程團隊。QA、測試中心或受監管環境常需要可視化測試設計、審核與交接，JMeter 的 GUI 能降低跨角色溝通成本。

Legacy 測試資產適合保留 JMeter。既有 .jmx 檔案、listener、plugin 與報表流程如果已經運作多年，重寫到 k6、Gatling 或 Locust 的機會成本要用維護收益抵銷。

最短判讀路徑

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

• Thread group 設計：thread count / ramp-up / loop count / duration 是否反映真實流量模型、有沒有用 Stepping Thread Group（plugin）或 Concurrency Thread Group 控制 arrival rate、不是把 thread 當「user」直接綁
• Listener 配置：GUI listener（View Results Tree / Aggregate Report / Graph）只在 design / debug 階段開、正式跑必須改 Simple Data Writer 輸出 JTL、結果分析交給離線 HTML report 或外部 Grafana
• Distributed mode 設定：單機 thread 上限約 3000-5000（受 JVM heap 與 thread context switch 限制）、超過要走 master + slave（remote engine）；slave 機器 plugin / JMeter version / JVM 參數要跟 master 一致、否則結果不可信
• GUI vs CLI 模式區分：GUI 是 design / debug only、production load 一律走 jmeter -n -t plan.jmx -l result.jtl；GUI 跑大規模測試會把 listener 拉爆記憶體、結果反而失真

四件事任一缺、就是 9.3 壓測工具選型 邊界的待補項目。

選型判準

多 protocol 價值來自 dependency coverage。當 workload model 包含 database、queue、file transfer 或 legacy endpoint，JMeter 可以把不同 dependency 的壓力放在同一個測試計畫中觀察。

GUI 協作價值來自跨角色可見性。這個優點會帶來版本控制成本，因為 XML diff 不容易 review；團隊要補上 naming、folder structure、parameterization 與 review checklist。

跟其他工具的取捨

JMeter 和 k6 的主要差異是 workflow。JMeter 偏 GUI、plugin 與既有企業流程；k6 偏 code-first、CLI、threshold 與 CI artifact。

JMeter 和 Gatling 的主要差異是 scenario 表達。JMeter 用 test plan、thread group、sampler 與 listener 組裝；Gatling 用 JVM DSL 描述 simulation，較適合工程團隊維護複雜 flow。

JMeter 和 Locust 的主要差異是自訂能力。JMeter 依賴 plugin 與 sampler，Locust 可以直接用 Python library 實作 custom client；如果 protocol 特別特殊，Python 團隊可能更適合 Locust。

JMeter 和 Vegeta 的主要差異是複雜度。Vegeta 適合快速 HTTP saturation probe；JMeter 適合多步驟、多 dependency 與可交接測試計畫。

操作成本

JMeter 的主要成本是測試計畫治理。.jmx 檔案可以累積大量 listener、debug sampler、hard-coded variable 與過期 assertion，長期不整理會讓壓測結果失去可追溯性。

Runner 成本來自 JVM 與 listener。GUI listener 適合開發階段觀察，不適合大規模壓測；正式測試要使用 non-GUI mode，把結果輸出成 JTL、HTML report 或外部 metrics。

Plugin 成本來自版本漂移。不同 runner、不同工程師機器或 CI image 的 plugin 版本如果不一致，同一份測試計畫可能產生不同結果，因此要把 plugin 清單、JMeter 版本與 container image 固定下來。

Evidence Package

JMeter 結果應回寫到 evidence package。最小欄位包括 test plan version、JMeter version、plugin list、runner topology、thread group 設定、ramp-up、duration、p95 / p99、error rate、throughput、target saturation metric 與 known gap。

Evidence package 的核心用途是讓結果可審查。JMeter 測試計畫常由多人維護，gate decision 要能追到哪一版 .jmx、哪一組 runner、哪一批測試資料與哪一個目標環境。

進階主題

JMeter Plugins 生態：jmeter-plugins.org 社群維護的 plugin 集合補齊原版 JMeter 的不足 — Custom Thread Groups（Stepping / Ultimate / Concurrency / Arrivals）讓 thread schedule 反映真實 arrival rate、PerfMon 抓 remote server CPU / memory、Throughput Shaping Timer 直接以 RPS 為目標而非 thread count、Dummy Sampler 拿來 mock dependency。Plugin Manager 統一安裝、CI image 要把 plugin 清單固定（PluginsManagerCMD.sh install <plugins>）避免漂移。

BlazeMeter Cloud / Distributed execution：自建 distributed mode（master + slave 跨多 VM）成本高 — slave 機器要同 JMeter 版本、同 plugin、同 JVM 參數、RMI port 開通、結果回傳網路足夠。BlazeMeter（Perforce / 前 CA）是 JMeter SaaS、直接吃 .jmx 跑 cloud-scale 壓測、附 geo-distributed runner、適合短期 spike 測試不想自建 distributed cluster 的團隊。trade-off 是 vendor lock-in 跟 per-test 計費 — 長期高頻測試自建較划算。

Distributed mode 細節：master 機器發 control plane（thread group 配置、test plan 分發）、slave 跑 thread 並回傳 sample 結果。瓶頸常出在 master 收結果（RMI / 自訂 protocol），不是 slave 跑不動 — 大規模測試應該關掉 GUI listener、用 Backend Listener 把 metric 即時推到外部時序資料庫、master 只收彙整指標而非每個 sample。同步要點：所有 slave 用同一份 .jmx 與 test data CSV，CSV 不能依賴 master local path。

Backend Listener + Grafana 整合：JMeter 原生 Backend Listener 支援 InfluxDB / Graphite / Elasticsearch、把 active thread / response time / hit / error 即時推出去、Grafana 配 official JMeter dashboard 即時看 throughput / latency curve。這個組合取代 GUI listener、是 distributed mode 的標準觀測方式 — listener overhead 從 master 移到外部時序系統、master 不再被 GUI 拉爆。配合 4 observability 的時序資料庫已有時、JMeter metric 進同一個 Grafana、跟 application 端的 latency / error 並列、加速 6.13 Performance Regression Gate 的對照判讀。

排錯與失敗快速判讀

• GUI 模式吃記憶體爆 / OOM：GUI listener（View Results Tree / Graph）會把所有 sample 留在 heap、跑大規模就 OutOfMemoryError — 設計階段才開 GUI、正式跑切 jmeter -n non-GUI、listener 用 Simple Data Writer 寫 JTL 而非 in-memory aggregate
• Listener 拖累 throughput / 結果失真：太多 listener 同時開、每個 sample 都被多個 listener 處理、JMeter 自身成為瓶頸 — 正式測試只留 Simple Data Writer + Backend Listener、結果分析離線跑 jmeter -g result.jtl -o report/ 產 HTML
• Thread group 計算錯 / 真實流量對不上：把 thread 當「user」直接設、忽略 think time + ramp-up、結果壓出來的是 thread 全速跑而非業務流量 — 改用 Concurrency Thread Group 或 Throughput Shaping Timer 直接以 RPS 為目標、配 Constant Timer 模擬 think time
• Distributed mode 結果跟單機對不上：slave 機器 plugin / JMeter version / JVM heap 不一致、或 CSV 路徑只存在 master — 把 slave 環境 container 化（同 Docker image）、CSV 隨 .jmx 一起分發、--remote-start 統一啟動
• .jmx XML diff 不可 review / merge conflict 多：多人同時改測試計畫、GUI 改完 XML 結構大變 — 拆 fragment（Test Fragment + Module Controller）、scenario 分檔、parameterization 走外部 CSV / properties、PR review 看截圖 + 跑結果而非 raw XML diff
• Plugin 版本漂移 / CI 結果不可重現：dev 機器 plugin 跟 CI image 不同版 — 固定 plugin manifest、CI image 用 PluginsManagerCMD.sh install-for-jmx plan.jmx 從 plan 自動安裝、版本鎖到 image tag
• HTTPS / TLS 連線數爆炸：JMeter 預設每 thread 一個 TLS handshake、large thread count 把 server TLS 拖垮、結果反而測到 TLS 不是 app — 開 HTTP Cache Manager 跟 KeepAlive、必要時調 httpclient4.idletimeout

案例回寫

JMeter 在 09 案例庫中適合作為 enterprise load test 承接點。它可回寫到 9.C15 Tixcraft 售票壓測 的 pre-event validation、9.C17 BookMyShow ticketing 的售票流量模型、9.C1 Prime Day readiness 的 staged validation、9.C13 Hotstar IPL 1860 萬同時觀看 的全球直播 pre-event rehearsal、以及 9.C14 Standard Chartered 跨 7 個受監管市場的 Aurora 4000 TPS 容量驗證。

這些案例提供的是複雜業務流程與活動前驗證節奏。JMeter 頁引用案例時，要把 case 轉成 thread group、ramp-up、data set、dependency sampler 與 result artifact，並讓負載數字回到業務流程判讀 — 例如 Hotstar 的「集中地理區 CDN 壓力」要在 JMeter 用 per-region thread group 模擬、不是把全球流量塞進單一 runner。

下一步路由

• 上游：9.3 壓測工具選型
• 上游：9.10 Production-Side 驗證
• 平行：k6、Gatling、Locust
• 跨模組：6.13 Performance Regression Gate
• 官方：Apache JMeter documentation

教學路線：高併發 OLTP 與分片生態

MySQL 服務頁的教學目標是把「簡單 SQL 查詢」推進到高併發 OLTP、replication、online schema change 與 sharding governance。讀者讀完後要能判斷 MySQL 何時是成熟預設、何時已經進入 Vitess / PlanetScale 或 application sharding 的討論。

定位：高併發簡單 SQL + 強分片生態

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

• MySQL 偏 簡單 query 效能 + 分片生態 — InnoDB clustered index 對 primary key range query 特別快、Vitess 提供超大規模透明 database sharding
• PostgreSQL 偏 特性深度 — 詳見 PostgreSQL vendor page

選 MySQL 的核心訴求：需要超大規模分片（> 100 TB、> 100K WPS）、簡單 query 為主、已用 MySQL 生態工具鏈（gh-ost、pt-online-schema-change）。

容量特性

單一 primary 寫吞吐：

• 標準 InnoDB：10K-30K WPS（依 row size、commit sync、index 數量）
• 高階 instance + 優化 schema：50K-100K WPS
• 超過此級別 → Vitess sharding 或 PlanetScale

Connection 上限：

• 預設 max_connections = 151、實務常設 1000-5000
• 每個 connection thread stack ~3 MB + session buffer 累積、active 高峰時 ~8-10 MB（thread + sort/join buffer）
• 仍建議 ProxySQL / connection pool 限制 backend connection 數

Replication：

• async / semi-sync / GTID-based
• 跨 AZ async lag 通常 < 100ms
• 跨 region 通常用 chain replication 或 binlog 同步

Storage 上限：

• 單一 table 64 TB（InnoDB 設計上限）
• 實務超過 1 TB 表建議分片

適用場景

1. 大規模 OLTP + 分片需求：

• 流量 > 50K WPS、必須進入 database sharding 設計
• 用 Vitess / PlanetScale 透明 sharding、應用層幾乎不必改
• 對應產業：超大網路服務（GitHub、Shopify、Slack）

2. 簡單 query 為主：

• primary key lookup、簡單 range query
• 不太用 CTE、window function、複雜 JOIN
• InnoDB clustered index 對這類 workload 特別快

3. 既有 MySQL 生態工具：

• gh-ost / pt-online-schema-change（online schema migration）
• Orchestrator（HA topology 管理）
• ProxySQL（query routing + connection pool）
• Maxwell / Debezium MySQL（CDC）

4. 強一致 transaction 但容忍部分 SQL 功能缺失：

• 不需 partial index、不需 JSONB indexing
• 不需 PostGIS、用 spatial extension 夠

5. Aurora MySQL（managed 路徑）：

• 從自管 MySQL 上 AWS、保留 wire protocol
• 詳見 Aurora vendor page

不適用場景

1. 需要 PostgreSQL 等級的 SQL / JSON 特性：

• 複雜 CTE、recursive query、window function
• JSON Schema validation、JSONB GIN indexing
• PostGIS 等深度 extension

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

• MySQL 設計是 single primary、跨 region 是 async
• 替代：Aurora DSQL、Spanner、Vitess multi-cluster

3. 大規模 OLAP：

• MySQL 定位在 OLTP，analytics workload 交給 OLAP 系統
• 替代：ClickHouse、BigQuery、Snowflake

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

• 跟 PostgreSQL 一樣有 parsing / planning 開銷
• 替代：DynamoDB、Redis

跟其他 vendor 的取捨

vs PostgreSQL：

• 詳見 PostgreSQL vendor page 對比段
• 摘要：MySQL 適合超大規模分片、PostgreSQL 適合進階 SQL 特性

vs Aurora MySQL（同 wire protocol）：

• MySQL（自管 / RDS）：可跨雲、彈性高
• Aurora MySQL：AWS managed、storage / compute 分離、更多 read replica
• 選自管 MySQL：跨雲需求、預算敏感
• 選 Aurora MySQL：AWS 生態深、需要 storage scaling

vs PlanetScale（Vitess managed）：

• MySQL（自管 + Vitess）：完全控制、可自管分片
• PlanetScale：managed Vitess、branch-based schema migration
• 選 MySQL + Vitess：team 有能力管 Vitess、預算敏感
• 選 PlanetScale：想 zero ops、branch-based workflow

vs TiDB：

• MySQL：single-primary、傳統分片靠 Vitess
• TiDB：MySQL wire protocol 相容、HTAP（OLTP + OLAP 同庫）、跨 region 強一致
• 選 MySQL：已有 MySQL 投資、不想換引擎
• 選 TiDB：需要跨 region 強一致 + OLAP 同庫

vs Vitess（self-managed sharding layer）：

• Vitess 本質是 MySQL 上層的 sharding layer
• 由 YouTube 設計、捐贈 CNCF
• 適合超大規模 MySQL 集群、需要透明 sharding

vs DynamoDB（document/KV 替代）：

• MySQL：SQL、有 transaction、ad-hoc query、connection-based
• DynamoDB：KV、partition 透明、無 connection 限制、5 個 9 SLA
• 選 MySQL：需要 ad-hoc query、複雜 JOIN、SQL transaction
• 選 DynamoDB：access pattern 固定、AWS-only、想避免 connection limit 問題
• 詳見 1.10 KV / Document DB 容量規劃 的 connection model 對比

vs Spanner / CockroachDB / Aurora DSQL（distributed SQL）：

• MySQL + Vitess：自管 sharding、operational 重、跨雲可用
• Spanner / CockroachDB / Aurora DSQL：分散式 SQL、跨 region 強一致、transparent sharding
• 選 MySQL + Vitess：已有 MySQL 投資、有能力管 Vitess、預算敏感
• 選 distributed SQL：需要 multi-region 強一致、不想自管 sharding
• 詳見 1.11 全球分散式 OLTP

vs MongoDB（document 替代）：

• MySQL：SQL + JSON column 補充
• MongoDB：document 為主、aggregation pipeline 強、schema-flexible
• 選 MySQL：主要結構化、少量半結構化
• 選 MongoDB：document 占主要 schema、aggregation 工作負載

容量規劃要點

1. Sharding 是 MySQL 大規模的核心：

• 單一 MySQL primary 寫吞吐有上限
• Vitess / PlanetScale 用 keyspace + shard 切分
• shard key 設計類似 DynamoDB partition key — 必須均勻
• 大規模案例：Shopify（多 shard 分散）、Slack（per-team sharding）

2. Online schema change 是必備：

• ALTER TABLE 直接跑會 lock 整個 table
• gh-ost（GitHub）/ pt-online-schema-change（Percona）/ Vitess online DDL 用 ghost table 漸進 migrate
• 大表 schema change 可能跑 hours / days、要排程

3. Replication 跟 GTID：

• GTID-based replication 比 binlog position 容易管 topology
• semi-sync replication 保證至少一個 standby ack 才 commit
• async replication 高吞吐但 lag 較大

4. Connection management：

• ProxySQL 是 MySQL 生態的 connection pool 標準
• 提供 query routing（讀 → replica、寫 → primary）
• 對應 9.C29 Lemino case — RDB connection limit 議題對 MySQL 同樣適用

5. InnoDB tuning：

• innodb_buffer_pool_size：dedicated server 70-75%、shared server 30-50%（詳見 InnoDB Tuning）
• innodb_flush_log_at_trx_commit：1（durable）vs 2（faster）vs 0（fastest, 不安全）
• innodb_io_capacity：依 storage 類型調整

Anti-recommendation 與升級路由

MySQL 的成熟生態容易讓讀者過早引入重工具。這一段補上 deep article audit 提到的 anti-recommendation 缺口：先說何時維持簡單 MySQL 路徑，再說何時升級到 ProxySQL、Orchestrator、gh-ost、Vitess、PlanetScale 或 distributed SQL。

Replication 的簡單路徑是 GTID + async replica + 明確 read routing。當 failover 仍靠人工判斷、replica re-pointing 反覆出錯、或 semi-sync fallback 沒有被監控時，才需要把 Orchestrator、ProxySQL 與 incident runbook 放進同一條 HA 路徑。

Online schema change 的簡單路徑是先判斷 MySQL 8.0 instant / inplace DDL 能否 cover。只有大表 rewrite、長時間 metadata lock、FK / trigger 複雜互動或 maintenance window 不足時，才讓 gh-ost / pt-online-schema-change 成為主線工具。

Sharding 的簡單路徑是延後到資料形狀穩定後再做。Vitess 能把 MySQL 推到超大規模，但它也引入 VTGate、VTTablet、VReplication、VSchema、resharding workflow 與跨 shard transaction 邊界；shard key 還沒穩定時，應先用 schema、index、read replica、partition 與容量治理延長單 primary 壽命。

Managed sharding 的簡單路徑是先確認團隊想轉移哪一層責任。PlanetScale 解的是 Vitess operation、branch-based schema workflow 與 managed failover；FK、cross-shard query、connection pool 與 cost model 仍要在 migration playbook 中驗證。

Deep article + Migration playbook（已完成）

補充正文路由

當前 deep article、migration playbook、補充正文與 hands-on 已 cover ops / schema / failover / tuning / SQL features / sharding / backup / migration / security / audit / document / OLAP / memory / metadata lock 等維度。下列補充正文用來承接 overview 中提到的延伸議題：

• Encryption at rest + TLS in transit + key management：對應 PG TLS-mTLS 議題
• Audit log + SIEM 整合：MySQL Enterprise Audit Plugin 跟 Splunk / Elastic Security 整合
• MySQL Document Store（X-Protocol）：少用但對特定 use case 有興趣
• Multi-source replication topology：1 個 replica 從 N 個 primary 拉、用於 sharded environment 整合
• HeatWave（MySQL OLAP add-on）：Oracle 推的 HTAP solution、跟 ClickHouse / Snowflake 對比
• Cross-buffer memory contention deep dive：buffer pool / connection thread / temp table / sort buffer 之間的 RAM 競爭、跟 OS swap 互動
• Metadata lock deep dive：DDL / long-running SELECT / FK 互動造成的 stalls

上述補充篇已完成正文，並保留既有路由。Encryption / TLS / key management 接 TLS / mTLS 與 Secret Management；audit log 接 Audit Log 與 07 資安資料保護；Document Store 接 MongoDB vendor 與 1.10 KV / Document DB 容量規劃；multi-source replication 接 Replication Topology；HeatWave 接 OLAP 替代路由；memory contention 接 InnoDB Tuning；metadata lock 接 Lock Contention 與 Online Schema Change Tools。

已知 limitation（多輪 audit 結論）

17 篇 batch 跑過 4-reviewer audit（寫作規範 / 跨檔一致性 / 技術準確性 / 結構性質疑）後留下的 limitation：

• Framework bias：5 篇 migration playbook 全落在 Type A / C / E、沒一篇 Type B / D / F。這反映 MySQL 領域 migration 的本質（多數情境是 schema 差 / operational 轉手 / paradigm shift）、也可能反映 6 type framework 的覆蓋限制
• Anti-recommendation 已補 overview 路由：本頁新增「Anti-recommendation 與升級路由」作為總入口；各 deep article 之後仍可逐篇補「何時維持簡單設計」段。
• Real case anchor 已下沉：本頁「真實案例 anchor」把 Shopify、Slack、GitHub gh-ost、YouTube / Vitess 與既有 09 case 串回 deep article；Shopify CDC、gh-ost workflow、YouTube / Vitess 與 Netflix Aurora consolidation 已補到對應 deep article 的 production case 段。
• PG 對比 narrative：對比段公允度尚可、但 PG 弱點（vacuum ops 開銷 / connection-per-process model / replication slot 治理）較少在 MySQL 視角展開、單方面對比偶有偏 MySQL 不利

案例對照

MySQL 沒有直接的 09 case（大規模 MySQL 多在 engineering blog、不在 vendor case study）、但作為 baseline / 遷移源 在多處出現：

真實案例 anchor

MySQL 真實案例的責任是把大規模 OLTP 的機制壓力放回正文。案例不只證明「某公司使用 MySQL」，而是提供 schema change、CDC、sharding、connection、queue 整合或 managed migration 的壓力來源。

案例下沉規則是先放 overview，再進 deep article。當某個案例只支撐服務定位，留在本頁；當案例提供具體操作訊號，例如 Shopify 的 Debezium connector scaling、GitHub 的 gh-ost workflow 或 YouTube 的 Vitess topology，對應 deep article 要保留 production case 段、讓讀者能從機制直接跳到案例。

常見陷阱

• 直接 ALTER TABLE 大表：lock 表 hours、production 停擺、必須用 online schema change
• 不用 GTID：replication topology 變更困難、recover from failure 容易出錯
• buffer pool 太小：cache miss 高、IOPS 飆升
• shard key 選錯：hot shard 出現、整體吞吐達不到名義
• connection 沒 pool：跟 PostgreSQL 同樣問題、用 ProxySQL
• semi-sync 對高吞吐 workload：每次 commit 等 ack、寫吞吐降一半

下一步路由

• 完整 T1 對照：01-database vendors index
• 平行：PostgreSQL vendor、Aurora vendor（managed MySQL）
• 操作：MySQL Hands-on（local lab、ProxySQL、OSC、replication failover、backup restore、Vitess sandbox）
• 上游：1.1 高併發資料存取、1.3 Transaction Boundary
• 下游：1.10 KV / Document DB 容量規劃（MySQL 不適用時的替代）
• 跨模組：9.5 瓶頸定位流程 — connection / replication / lock contention 常見 MySQL bottleneck
• 官方：MySQL Documentation、Vitess、PlanetScale

對「事件驅動架構、CDC、跨系統事件分發、長期保留 + replay」這條路徑、Kafka 是業界事實標準。本頁先給最短路徑、再展開日常 producer / consumer 操作與 topic 設計、最後進階治理（多租戶、跨區、自動修復）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 docker-compose 跑起 Kafka + KRaft、驗證 broker 健康
2. 用 CLI 建 topic、produce / consume 訊息、看 partition 分布
3. 設計 producer acks / idempotence / consumer commit 策略對齊 delivery semantics
4. 看懂 consumer lag、ISR shrink、rebalance 訊號、定位故障層
5. 評估 multi-tenant、cross-region、tiered storage、self-healing 等規模化議題

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

最短路徑用 KRaft 模式（取代 ZooKeeper、單節點即可跑）、避免初學者卡在 ZK 安裝。

 1# 1. 啟動 Kafka（apache/kafka 內建 KRaft、單一容器即含 broker + controller）
 2docker run -d --name kafka -p 9092:9092 apache/kafka:latest
 3
 4# 2. 建 topic（CLI 在容器內 /opt/kafka/bin/）
 5docker exec kafka /opt/kafka/bin/kafka-topics.sh --create --topic demo --partitions 3 \
 6  --bootstrap-server localhost:9092
 7docker exec kafka /opt/kafka/bin/kafka-topics.sh --describe --topic demo \
 8  --bootstrap-server localhost:9092
 9
10# 3. 驗證 produce / consume
11docker exec kafka bash -c "echo hello | /opt/kafka/bin/kafka-console-producer.sh \
12  --topic demo --bootstrap-server localhost:9092"
13docker exec kafka /opt/kafka/bin/kafka-console-consumer.sh --topic demo \
14  --from-beginning --max-messages 1 --bootstrap-server localhost:9092

最短路徑只驗證「broker 起來、能寫能讀」。實際寫程式用 producer / consumer client、見日常操作。

日常操作與決策形狀

CLI 與 client API

子議題：

• CLI 指令對照表（kafka-topics / kafka-configs / kafka-consumer-groups / kafka-acls）
• Producer client 配置：acks / batch.size / linger.ms / compression / enable.idempotence
• Consumer client 配置：auto.offset.reset / enable.auto.commit / max.poll.records / max.poll.interval.ms
• 對應指令範例：kafka-topics.sh --describe、kafka-consumer-groups.sh --describe --group <id>

Topic 設計

Topic 承擔事件的邏輯邊界。子議題：

• Partition 數規劃（並行度 vs metadata 成本）
• Replication factor 與 min.insync.replicas（資料保護等級）
• Retention policy（time-based vs size-based、compact vs delete）
• Key 策略（ordering 範圍、hot partition 避免）

Producer 與 Consumer 設計

設計決定 delivery semantics 實際達成。子議題：

• Producer：acks=0/1/all 對應的可靠性取捨、idempotence、transaction 邊界
• Consumer：commit 策略（auto vs manual）、commit 時機與 at-least-once / at-most-once 對應
• Consumer group：rebalance protocol（eager vs cooperative）、static membership
• 對應指令：producer 配置範例、consumer 配置範例、kafka-consumer-groups.sh --describe

進階主題（按需閱讀）

本段主題多數已展開為 deep article：consumer rebalance 與 lag 診斷、replication / ISR / exactly-once、retention 與 tiered storage、Schema Registry 與 schema 演進、multi-tenant quota 與 ACL 治理。下列子議題段保留每個主題的選題判讀入口。

Multi-tenant 與配額治理

對應案例 3.C6 Uber Kafka 事件平台。子議題：

• Producer / Consumer quota（byte rate、request rate）
• ACL 設計（principal、resource、operation）
• Topic 命名規範與 ownership
• 對應指令：kafka-configs.sh --alter --add-config 'producer_byte_rate=...'、kafka-acls.sh --add

Cross-region 與分層叢集

對應案例 3.C1 Meta FOQS 與 3.C4 LinkedIn Tiered Clusters。子議題：

• MirrorMaker 2 配置（active-active vs active-passive）
• 分層叢集策略（critical / standard / experimental）
• 跨區 consumer 路徑與 routing freshness

Topic 生命週期治理

對應案例 3.C3 LinkedIn TopicGC。子議題：

• Topic 活躍判準（last produce / consume timestamp）
• 自動回收條件與稽核
• Metadata 壓力訊號（controller log、partition 數量上限）

Replication 與 exactly-once 升級

對應案例 3.C9 反例：語義誤配。子議題：

• acks=all + min.insync.replicas ≥ 2 + producer idempotence
• Kafka transaction 與 read_committed 邊界
• 端到端 exactly-once（Kafka Streams 場景）

Self-healing 與自動修復

對應案例 3.C7 LinkedIn Self-Healing。子議題：

• 可自動修復故障類型（disk full、broker offline、under-replicated partition）
• 自動修復 vs 人工升級邊界
• 修復過程的證據鏈納入觀測

KRaft 與 Schema Registry

子議題：

• KRaft mode 取代 ZooKeeper（運維簡化、metadata 治理）
• Schema Registry（Confluent / Apicurio）與 Avro / Protobuf
• Schema 演進策略（forward / backward / full compatibility）

Tiered storage

子議題：

• 冷熱分層（hot tier on local disk、cold tier on S3）
• Retention 設計與成本
• Read 路徑差異（hot vs cold）

Kafka Connect 與 CDC

子議題：

• Source connector / Sink connector 模型
• Debezium CDC pipeline 與 outbox 整合
• Connect cluster 治理與 schema evolution

排錯快速判讀

Consumer lag 暴增

操作原則：先看 lag 是「均勻分布」還是「集中在少數 partition」、再定位 consumer 慢 vs partition 不平衡。

1kafka-consumer-groups.sh --describe --group <id> --bootstrap-server localhost:9092
2# 輸出含 CURRENT-OFFSET / LOG-END-OFFSET / LAG 逐 partition 列、可看 lag 集中在哪幾個 partition

判讀路徑：consumer 慢（CPU / GC / 下游 I/O）→ producer 突增 → partition 不平衡（key 分布）。

ISR shrink 與 under-replicated partition

操作原則：ISR 縮小代表 follower 跟不上 leader、看 broker 健康 / 網路 / disk。

1kafka-topics.sh --describe --under-replicated-partitions --bootstrap-server localhost:9092
2# 輸出為空代表所有 partition 同步正常；列出的 partition 即 ISR 落後者

Rebalance storm

操作原則：consumer 頻繁加入 / 離開觸發 rebalance、看 session.timeout.ms 與 max.poll.interval.ms。

Offset reset 或重複消費

對應反例 3.C9。判讀路徑：commit 策略錯誤、broker 端 offset 過期、auto.offset.reset = earliest。

Schema 不相容

操作原則：producer 升級 schema、consumer 未升、看 compatibility level。

何時改走其他服務

不在本頁內的主題

• 各語言 client API reference（依官方文件）
• Kafka Streams / ksqlDB（另開 stream processing 章節）
• Confluent 商業功能（Confluent Cloud、Control Center）

案例回寫

既有通用案例（C1-C10）

Kafka 專屬案例（C11-C22）

KRaft 缺直接 customer case：目前依官方 KIP-833 / Confluent 公告為準、後續若有 customer 一手案例可補。

下一步路由

• 上游概念：0.3 非同步選型、3.1 broker basics
• 平行 vendor：RabbitMQ、NATS
• 下游能力：3.4 consumer 設計、6.12 idempotency / replay

本章目標

讀完本章後、你應該能：

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

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

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

日常操作與決策形狀

Pipeline / workflow / job 模型

子議題：

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

Orb 重用

子議題：

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

Cache + workspace

子議題：

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

進階主題（按需閱讀）

Parallelism + test splitting

子議題：

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

Resource class

子議題：

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

Self-hosted runner

子議題：

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

OIDC integration

子議題：

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

Approval job

子議題：

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

Cross-VCS support

子議題：

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

排錯快速判讀

Build 慢

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

Cache 不命中

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

Parallelism 不均勻

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

Approval 卡住

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

何時改走其他服務

不在本頁內的主題

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