"Reliability"
- Chaos Mesh：Workflow、Scope Control 與 Steady State Probe
用 Chaos Workflow 編排多步驟實驗、用 selector 與 mode 控制 blast radius、用 StatusCheck 做 steady state probe。
- k6：Threshold CI Gate 與 Scenario 設計
用 threshold 把 load test 結果變成 CI pass/fail，用 scenario 讓 workload model 貼近 production traffic shape。
- Sloth：SLO YAML 與 Multi-burn-rate Alert 生成
用宣告式 YAML 定義 SLO，自動生成 Prometheus multi-window multi-burn-rate recording 與 alerting rules。
- 6.1 CI pipeline
CI pipeline 的分層策略、artifact 管理、flaky 治理與 release gate 輸入
- GitHub Actions：Environment Protection 與 OIDC Cloud Auth
用 environment protection rules 做 deploy approval gate、用 OIDC 取代 long-lived cloud credential。
- 6.2 load test
把 production 流量結構轉成可重播壓力情境，定位 saturation 轉折與容量邊界
- 6.3 fuzz campaign
用自動化輸入探索覆蓋未知邊界：target 設計、corpus 管理、crash reproduction 與 CI 整合
- Flaky test 根因分類
計時依賴 / 環境差異 / 資源競爭 / 非確定性輸出 — 四類 flaky test 根因的辨識和處理策略
- 6.4 chaos testing
把故障注入從工具操作升級成可驗證流程：先定義穩態，再按依賴類型設計注入、控制 blast radius 與收集證據
- 6.5 失敗模式預判（Pre-mortem 與 FMEA）
用 pre-mortem 反向推導失敗路徑、用 FMEA 分類軸評估驗證缺口，把可靠性盲區變成可排序的改善輸入
- 6.6 SLO 與 Error Budget 政策
把可靠性目標轉成可驗證量測與凍結條件
- 6.7 DR 演練與 Rollback Rehearsal
把回復路徑從紙面計畫變成定期可重播、可量測的驗證流程
- 6.8 Release Gate 與變更節奏
把驗證、migration、相容性納入放行判準
- 6.9 容量與成本邊界
把容量規劃跟成本約束變成驗證輸入
- 6.10 Contract Testing 與 Schema 演進
把跨服務 / API / event schema 的隱性期待變成可驗證契約，控制演進相容性
- Google：Error Budget 政策如何決定發布節奏
把 SLO 消耗量轉成 release gate，讓可靠性與交付速度共用同一套決策語言。
- 6.11 Migration Safety 與 DB Rollout
把 schema migration 從一次性事件變成可逆、可漸進的 rollout 流程
- Jenkins → GitHub Actions：Pipeline 5 段 lifecycle 的對位 + 翻譯
Jenkins → GHA 是 Type A 高 schema 差 migration、主軸是 Groovy DSL → YAML workflow 翻譯；本文按 pipeline 5 段 lifecycle（source → build → test → scan → deploy）逐段對位、5 個 production 踩雷（shared library equivalence / ephemeral workspace / plugin gap / self-hosted runner / matrix build 表達差）
- Google：Postmortem Action Item Closure 治理
把 blameless postmortem 從會議文件變成可追蹤的可靠性治理機制：action item 分級、完成條件與回寫節奏。
- 0.12 觀測、可靠性與事故服務選型
從訊號、驗證與響應三層能力判斷操作控制服務的選型順序
- 6.12 Idempotency 與 Replay 驗證
把重試、重播與冪等性從口頭約定變成可驗證屬性
- 0.13 操作控制 vertical slice 實作入口
用一個服務串起觀測證據、可靠性驗證、事故決策與回寫閉環
- Google：Toil Budget 與 Automation 投資政策
把 toil 從感受問題轉成預算問題：用時間配比與自動化回報機制，避免 on-call 壓力長期侵蝕可靠性工程。
- 6.13 Performance Regression Gate
把效能 baseline 從一次性壓測變成持續對齊的 release gate，涵蓋 baseline 設定、判讀方法、variance 控制與退化定位
- 6.14 Dependency Reliability Budget
把內外依賴的可靠性納入 SLO 計算與設計約束
- 端到端資料完整性
從 SDK 到 storage 的資料損失地圖 — 每個環節的損失類型、控制策略、完整性指標、被自己 SDK DDoS 的防護
- 6.15 Environment Parity 與漂移控制
把 staging / preprod / prod 之間的差異視為一級風險，按漂移來源分類偵測與治理
- 6.16 Test Data Management
把 fixture / seed / production-like data 作為跨模組共用 artifact，治理資料層次、遮罩策略與可重現性
- 6.17 Feature Flag Governance
把 feature flag 從上線開關升級為有角色分類、lifecycle 管理與 debt 治理的 runtime artifact
- 6.18 Reliability Metrics Governance
DORA / SPACE 指標的選用、量測陷阱、anti-gaming 與團隊階段適配
- 6.19 Reliability Readiness Review
把上線前、重大變更前與高風險操作前的可靠性準備度變成可檢查門檻
- 6.20 Experiment Safety Boundary
定義 chaos、load test、DR drill 的 [blast radius](/backend/knowledge-cards/blast-radius/)、停止條件與權限約束
- Honeycomb：以 Burn Rate 驅動的可靠性操作
把 SLO burn rate 直接連到值班決策與改善優先序，降低高噪音告警造成的判讀失真。
- Netflix：Steady State、Chaos 與 FIT 的驗證路徑
把故障注入從工具操作升級成可驗證流程：先定義穩態，再設計注入與回復條件。
- 6.21 Reliability Debt Backlog
把反覆事故、演練缺口與手動修復累積成可排序、可關閉的 reliability debt
- Netflix：Business-Hours Chaos 與 Guardrails
Chaos Monkey 為何刻意在 business hours 執行：把即時應變能力納入驗證，並用 guardrails 限制實驗風險。
- 6.22 Steady State Definition
在 chaos 與 failover 前先定義系統應維持的穩定狀態與可接受退化
- Netflix：FIT 證據交接與 Release Gate 回寫
用 Failure Injection Testing 產出的證據直接驅動 release gate：把實驗結果轉成可放行、可凍結、可回退的決策欄位。
- 6.23 Verification Evidence Handoff
把 SLO、load、chaos、DR 與 readiness 結果包成 release / incident 可用證據
- 6.24 規則推送安全閘門
把規則、策略與控制面配置推送從部署步驟升級為可靠性 gate，避免小變更在秒級擴散成全網事故。
- 6.25 Provider Dependency Release Gate 實作示範
以 payment provider 變更示範 release gate 如何結合 evidence、stop condition 與 rollback window。
- Amazon：Shuffle Sharding 與 Cell 邊界的失效局部化
用 cell 與 shuffle sharding 將多租戶故障限制在局部，讓恢復策略可分批執行。
- LinkedIn：Capacity Headroom 與 On-call 分層
把容量預測與值班分層綁在一起，降低高峰時段的升級混亂與恢復延遲。
- Amazon：Static Stability 與 Constant Work Pattern
控制面失效時資料面如何維持服務：用快取、預計算與固定工作量避免恢復放大。
- Honeycomb：Production Excellence 與 Test in Production
用 high-cardinality observability 把 production 變成安全的驗證環境：feature flag、progressive rollout 與即時回饋的配合。
- LinkedIn：Automated Load Testing 與 Capacity Forecasting
持續壓測驅動容量預測：用自動化回饋取代一次性壓測的容量規劃。
- Meta：Region Failover 與可靠性邊界
把跨區故障視為邊界治理問題，透過分區隔離與回復順序控制失效擴散。
- Stripe：Idempotency 與零停機遷移的交易安全設計
把 API 重試與資料遷移放在同一套安全模型，維持支付交易的一致結果。
- Meta：BGP 事故與控制面恢復順序
當回復工具依賴已故障的系統：2021-10 事故揭露控制面恢復順序與 out-of-band 存取的設計約束。
- Pinterest：Storage Migration 與 Data Infrastructure Reliability
大規模儲存遷移的可靠性設計：用 dual-write、shadow read 與 staged cutover 讓 PB 級資料基礎設施變更可漸進、可驗證、可回退。
- Spotify：Backstage Service Catalog 與 Reliability Metadata
用 service catalog 治理分散團隊的可靠性資訊：ownership、SLO 狀態、依賴圖與 runbook 的單一入口。
- Stripe：Canary Deploy 與 Progressive Rollout 治理
金流場景如何用交易指標驅動放行節奏：延遲確認、duplicate 偵測與自動回退。
- Microsoft：變更治理與可靠性門檻
透過分層變更管理與發布閘門，降低大型 SaaS 平台的系統性回歸風險。
- Shopify：BFCM 容量治理與 Game Day 驗證節奏
把季節性流量峰值轉成年度可靠性流程，透過容量模型、演練與隔離策略提前吸收風險。
- Microsoft：Safe Deployment Practices 與 Resilience Patterns
大型 SaaS 用 ring-based deployment 控制變更擴散，用標準化 resilience patterns 讓依賴失效時的降級行為可預測。
- Shopify：Pod Architecture 與 Resiliency Matrix
多租戶隔離與系統化失敗模式盤點：pod 邊界控制擴散、resiliency matrix 驅動演練。
- Pinterest：快取可靠性與容量驚奇治理
針對快取層失效與流量突增，建立容量緩衝、退化路徑與重建節奏。
- Spotify：平台工程與可靠性契約
用平台契約統一服務團隊的可靠性最低標準，降低跨團隊變更造成的隱性風險。
- Cutover Window
說明正式切換發生的觀察窗口、停止條件與回退判讀範圍
- Rollback Window
說明變更進入 production 後還能用哪種方式回退或改路線的時間與條件
- Fail-forward
說明無法回到舊狀態時如何用受控前進完成修復
- Stop Condition
說明變更、實驗或事故處理何時必須暫停、回退或改路線
- Gate Decision
說明 release gate 如何把證據轉成放行、暫停、回退或補證據的決策
- Rollback Condition
說明決策執行後出現哪些訊號時要撤回、回退或改路線
- 7.23 資安與可靠性的共同控制面
建立資安與可靠性共同控制面的交集，整合 rollback、containment、degradation 與 evidence