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

驗證角色

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

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

問題節點

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

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

案例庫讀法

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

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

Vendor / Platform 清單

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

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

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

規劃方向

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

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

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

模組方法

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

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

模組分工定位

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

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

從章節到實作的 chain

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

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

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

跟既有模組的串接

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

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

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

07 資安交接基線：

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

與語言教材的分工

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

企業案例補充

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

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

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

跨語言適配評估

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

主章規劃

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

個案前拓展空間

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

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

後續深化方向

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

實作探討入口

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

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

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

服務案例庫規劃

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

T1（必寫、SRE 教學標竿）

T2（補不同視角）

T3（補完）

模組完成狀態

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

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

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

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

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

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

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

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

下一輪推演大綱

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

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

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

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

Tripwire

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

既有可引用卡片

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