概念位置

Funnel analysis 位在行為資料收集之後、產品決策之前。它的輸入是 event 類監控事件（使用者操作記錄），輸出是每步的轉換率。Funnel analysis 的前提是去識別化（redaction）已完成 — 分析行為資料前必須確保資料不含可識別個人的敏感欄位。

可觀察訊號與例子

產品需要 funnel analysis 的訊號是「使用者在某個流程中的完成率低於預期，但不知道卡在哪一步」。註冊流程的轉換率從填寫 email 到完成驗證只有 30%，funnel analysis 揭露 60% 的使用者在「等待驗證信」步驟流失。

設計責任

Funnel analysis 要定義步驟順序、步驟之間的時間窗口（使用者在多久內完成下一步才算轉換）、以及分群維度（按平台、來源、使用者類型拆分 funnel）。步驟定義需要和事件命名規範對齊 — funnel 的每一步對應一個具體的事件名稱。

概念位置

畫面狀態矩陣位在 BDD 操作盤點和 UI 實作之間。操作盤點描述「使用者做什麼、看到什麼」，畫面狀態矩陣把這些描述展開成每個狀態的四個面向，補上操作盤點容易遺漏的「可用操作」和「退出路徑」。矩陣產出後可以直接轉成 widget test case，也可以加上「可觀測性」欄位連接 log 設計。

可觀察訊號與例子

需要畫面狀態矩陣的訊號是實機測試時發現使用者被困在某個畫面出不去。常見情境：error 畫面只有重連按鈕沒有返回按鈕、loading 畫面沒有取消操作、connected 畫面沒有斷線或返回的出口。

設計責任

畫面狀態矩陣的設計責任是在實作前暴露導航缺口。填寫時要確保每個狀態至少有一條退出路徑，即使是 connecting 這種過渡狀態也應該提供取消操作。矩陣和 Gate 設計互補 — gate 的失敗路徑和不確定路徑應該反映在矩陣的退出路徑欄中。

概念位置

CI Pipeline 位在開發提交、pull request 與主線保護之間，常由 lint、test、build、security check 組成。

可觀察訊號

• PR 需要依賴檢查結果決定能否合併。
• 團隊需要一致的失敗判讀入口。
• 本機通過但共享流程失敗時，需要明確定位差異。

接近真實服務的例子

前端專案會把 markdown lint、browser test 與 production build 放在同一套 CI 驗證入口。後端專案則可能加入 contract test、migration check 或 image scan。

設計責任

CI Pipeline 要定義必跑檢查、失敗回饋路由與執行時間上限，讓綠燈具備可發布前提。

概念位置

UX 語境的 gate 聚焦在使用者體驗層 — 關注的是「使用者被擋住時看到什麼、能做什麼」。和 backend 語境的 gate decision 不同，後者關注的是部署流程中的品質關卡。Gate 的失敗路徑和不確定路徑應該反映在畫面狀態矩陣的退出路徑欄中。

可觀察訊號與例子

需要 gate 設計的訊號是使用者在某個功能前被阻擋且沒有替代路徑。常見情境：biometric 認證失敗後使用者無法進入 app、網路斷線後使用者被困在 loading 畫面、權限被拒後功能靜默消失但使用者不知道為什麼。

設計責任

Gate 的設計責任是確保每條路徑都有明確的使用者體驗。成功路徑通常最先被設計；失敗路徑需要提供 UX fallback（替代驗證、降級功能、返回上一頁）；不確定路徑需要 loading 指示和取消操作。開發環境可能遮蔽 gate 問題 — 模擬器跳過認證、debug build 自動授權 — 差異表讓開發者在上機前知道哪些 gate 還沒被真實驗證。

概念位置

Redaction 位在 SDK 端的事件產生和 collector 端的事件接收之間。它是監控資料安全的第一道防線 — 在資料離開使用者裝置之前處理，比 collector 端的 access control 更早介入。Redaction 和 transport 加密（HTTPS）互補：redaction 保護欄位內容，transport 加密保護傳輸過程。

可觀察訊號與例子

系統需要 redaction 的訊號是監控事件的 data 欄位可能包含使用者輸入。CLI 輸入可能含密碼（mysql -p'secret'）、API key（Authorization: Bearer sk-...）、連線字串（含帳密的 URL）。IME 個人化學習也是洩漏面 — 輸入框的內容被 IME 學習後跨 app 可見。

設計責任

Redaction 要定義預設規則（哪些欄位名稱自動 redact）、自訂 pattern（正則表達式比對敏感值）、執行時機（event 進入 buffer 前還是 flush 時）、以及 redaction 失敗的處理（丟棄整筆事件 vs 只移除敏感欄位）。

概念位置

CD Pipeline 位在 CI 驗證之後，負責 artifact promotion、部署執行、環境保護與回復路徑。

可觀察訊號

• 同一份 artifact 需要在多個環境推進。
• 發布步驟需要審核、權限或時間窗控制。
• 發布失敗時需要可回退或可修復路徑。

接近真實服務的例子

靜態站會在 CI 成功後上傳 artifact 到 hosting。後端服務會推進同一個 image tag 到 staging 與 production，並以 rollout strategy 控制風險。

設計責任

CD Pipeline 要明確定義放行條件、部署順序、例外流程與回復策略，確保發布節奏與風險控制一致。

概念位置

Cohort analysis 位在 funnel analysis 之後、策略制定之前。Funnel analysis 回答「使用者在哪一步流失」，cohort analysis 回答「哪種使用者流失率高」。兩者搭配使用：funnel 找到流失步驟，cohort 找到流失群組，策略針對特定群組的流失步驟設計。

可觀察訊號與例子

產品需要 cohort analysis 的訊號是「整體留存率或轉換率的平均值遮蔽了群組差異」。整體 30 天留存率 40%，但按註冊來源拆分後發現自然搜尋來的使用者留存 60%、廣告來的使用者留存 20% — 平均值沒有揭露這個差異。

設計責任

Cohort analysis 要定義分群維度（按什麼特徵分）、觀察指標（留存率、活躍度、付費率）、觀察時間窗口（7 天、30 天、90 天）、以及最小群組大小（群組太小時統計不顯著）。分群維度的選擇決定了分析能揭露什麼 — 按「註冊來源」分群能看到獲客通路的品質差異，按「使用的功能」分群能看到功能黏著度差異。

概念位置

UX fallback 位在 Gate 設計的失敗路徑中。Gate 的三問（成功/失敗/不確定）中，失敗路徑的具體內容就是 UX fallback。Backend 的 fallback 是系統在依賴失敗時用替代結果維持服務，UX fallback 是使用者在 gate 失敗時的操作替代方案。兩者可能並存 — server-side fallback 提供降級資料，UX fallback 決定如何呈現這些降級資料給使用者。

可觀察訊號與例子

需要 UX fallback 的訊號是 gate 失敗時使用者完全無法繼續。常見情境：biometric 設定 biometricOnly: true 導致 Face ID 失敗時沒有密碼 fallback、error 畫面只有重試按鈕沒有返回按鈕、網路斷線後所有功能不可用但部分功能不依賴網路。

設計責任

UX fallback 的設計責任是確保 gate 失敗時使用者有路可走。Fallback 的選擇取決於安全需求和使用場景 — 銀行 app 可能不提供低安全等級的 fallback，自用工具可以接受密碼 fallback 因為使用者就是 owner。安全 vs 可用性的取捨應在功能規格中顯式記錄。UX fallback 的存在應反映在畫面狀態矩陣的退出路徑欄中。

概念位置

Required Checks 位在 repository branch protection，連接 pull request 與 CI workflow 結果。

可觀察訊號

• PR 是否可合併取決於特定 checks 狀態。
• 團隊需要確保高風險變更不繞過驗證。
• CI workflow 增刪後需要同步調整合併條件。

接近真實服務的例子

專案可要求 md-check 與 Playwright tests 都通過才能合併 main。若只跑 workflow 但未設為 required，主線仍可能進入紅燈變更。

設計責任

Required Checks 要定義必要檢查集合、擁有者與變更流程，並和 workflow 命名保持一致。

概念位置

RFM 位在行為資料累積到一定量之後。它需要每個使用者的 session 歷史（計算 Recency 和 Frequency）和交易歷史（計算 Monetary）。免費產品可以用替代指標取代 Monetary — 產生的內容數量、邀請的使用者數、完成的關鍵操作數。RFM 的前提和 cohort analysis 相同：去識別化（redaction）已完成。

可觀察訊號與例子

產品需要 RFM 的訊號是「需要對不同行為模式的使用者採取不同策略」。高 R 高 F 高 M 的忠實客戶需要維護關係，低 R 高 F 高 M 的潛在流失客戶需要挽留，高 R 低 F 低 M 的新使用者需要引導降低入門門檻。

設計責任

RFM 要定義每個維度的計算方式（Recency 用天數還是週數、Frequency 的時間窗口多長、Monetary 用什麼指標）、分位數（五等分還是三等分）、群組歸納（125 種 profile 歸納成幾個可操作群組）、以及重新計算的頻率（每週還是每月）。分群結果是動態的 — 使用者行為改變時群組會變。

概念位置

Artifact 位在 build、test、package、deploy 之間，常見形式包含靜態網站檔案、container image、app bundle、安裝包與報告檔案。

可觀察訊號

• 測試與部署的輸入來源需要一致。
• 發布事故需要從線上版本反查 build run。
• 團隊需要管理產物保留時間與完整性驗證。

接近真實服務的例子

前端靜態站會把 public/ 作為 artifact，上傳後再部署。後端則用 image digest 作為 artifact 識別，推進到不同環境。

設計責任

Artifact 要定義命名、版本追溯、保留策略與完整性檢查，讓發布結果可重播、可比對、可審計。

概念位置

Artifact Handoff 位在 build、test、deploy 之間，透過 upload / download artifact 串接驗證與發布。

可觀察訊號

• 測試通過但部署後行為與測試結果不一致。
• 多環境重新 build 造成版本漂移。
• 事故追查時缺少從部署版本反查 build run 的路徑。

接近真實服務的例子

CI build 產生靜態網站 artifact，browser test 驗證該 artifact，deploy job 再發布同一份產物。容器場域則可把 image digest 當成 handoff 物件。

設計責任

Artifact Handoff 要定義產物格式、保留策略、完整性驗證與追溯欄位，讓測試結果可直接映射到發布結果。

概念位置

Error fingerprint 位在 collector 收到 error 事件之後、寫入 storage 之前。它的輸入是通過 schema validation 的 error 事件，輸出是附加了 _fingerprint 欄位的事件和更新後的 error_groups 摘要表。Fingerprint 只作用於 type: "error" 的事件 — 其他三類事件（event / metric / lifecycle）不需要去重分群。

可觀察訊號與例子

需要 fingerprint 的訊號是「dashboard 的 error 列表中，同一個 bug 因為 error message 包含動態值（user ID、timestamp、IP）而分裂成多個不同的行」。例如 "User 12345 not found" 和 "User 67890 not found" 是同一個 bug，但 name-based grouping（GROUP BY name）把它們歸為同一行時，丟失了 message 中的動態值資訊；而沒有 normalization 的 message-based grouping 會把它們分裂成兩行。

設計責任

Fingerprint 承擔的設計責任是「在 error 的精確識別和分群粒度之間找到平衡」。過粗的 fingerprint（只用 error type）把不同 bug 混在同一組；過細的 fingerprint（用完整 message 含動態值）把同因 error 分裂成多組。

自架 vs 商業方案

自架方案用規則做 fingerprint — regex normalize message（替換數字 / UUID / email / IP 等動態值）+ stack trace top N frames 做 hash。Sentry 在規則之上加了 in-app frame 過濾（忽略 framework / library frame）、source map 反解（minified JS → 原始碼位置）、和 ML-based grouping（語意相同但結構不同的 error 歸組）。差距主要在 minified / obfuscated 環境和 ML — 明文 stack trace 的場景下兩者效果相當。

完整章節

Fingerprint 演算法（基礎 / 進階 / Sentry / 自定義）、message normalization 的替換規則和風險、error_groups 表的 DDL 和 UPSERT 流程、dashboard 整合、自架方案的務實邊界 → Error Fingerprint 與去重分群。

概念位置

Environment Protection 位在部署 job 與目標環境之間，包含 reviewer、wait timer、branch policy 與 secret scope。

可觀察訊號

• 測試綠燈後仍需要人工批准才能進 production。
• 不同環境需要不同發布權限與審核規則。
• 發布失誤常來自權限配置或保護規則缺失。

接近真實服務的例子

GitHub Actions deploy job 指向 production environment，需指定 reviewer 批准後才可部署。staging 則採自動放行。

設計責任

Environment Protection 要定義環境分層、審核責任、發布時窗與例外流程，讓高風險發布有明確控制面。

概念位置

背壓位在 SDK 和 collector 之間的 HTTP 通訊層。觸發順序：collector 的寫入 channel 容量耗盡 → HTTP handler 無法送入事件 → 回 429 → SDK 收到 429 → SDK 降低取樣率（從 1.0 → 0.5 → 0.1）。背壓是全域的容量訊號 — 所有 SDK 同時收到，所有 SDK 同時降速。

可觀察訊號與例子

需要關注背壓的訊號是 collector 端的 collector.events.backpressure 計數器持續上升、或 SDK 端的 sdk.sampling.rate 低於 1.0。典型場景：行銷活動導致同時在線使用者暴增 → 所有 SDK 同時 flush → collector channel 瞬間填滿 → 全域 429 → 所有 SDK 動態降採樣。

和 DevOps 背壓的關係

DevOps 流量管控討論通用的背壓概念（TCP flow control、message queue consumer lag、circuit breaker）。本系列聚焦 SDK ↔ collector 之間的具體實作 — HTTP 429 是訊號、動態取樣是回應、Go channel 容量是觸發條件。通用概念在 DevOps 模組，監控場景的具體機制在本系列。

完整章節

背壓在四層防線中的位置（第二層 collector 單機防護）→ Ingestion Scaling。背壓造成的資料損失和控制策略 → 端到端資料完整性。

概念位置

Preview Environment 位在 pull request workflow 與正式部署流程之間，常由臨時 URL、隔離資源與到期清理組成。

可觀察訊號

• 團隊需要在合併前驗證 UI、路由或互動行為。
• 單靠測試報告不足以判斷體驗差異。
• 變更常包含環境變數、CDN 設定或靜態資產路徑。

接近真實服務的例子

前端 PR 自動建 preview URL 給 reviewer 驗證。後端則可能建立 review app 供 API 與整合測試使用。

設計責任

Preview Environment 要定義建立條件、資源上限、可見範圍與清理策略，避免成本與風險失控。

兩種取樣

靜態取樣：SDK config 中設定固定比例（例如 metric 類 0.1 = 每 10 筆只收 1 筆），在 SDK 整個生命週期保持不變。適合已知高頻但單筆 debug 價值低的事件（render.frame_time、scroll.position）。

動態取樣：SDK 在收到 collector 的 HTTP 429 後自動降低取樣率，collector 恢復正常後逐步回升。動態取樣在正常情況下不生效（取樣率 = 1.0），只在 collector 過載時啟用。和靜態取樣互補 — 靜態控制基線負載，動態應對突發。

取樣校正

分析時用取樣率還原原始量級。取樣率 0.1 時收到 100 筆事件，推估原始量為 100 / 0.1 = 1000 筆。SDK 端的 sdk.sampling.rate 指標記錄當前取樣率，讓下游分析知道如何校正。取樣校正對 funnel 和 cohort 分析有效（趨勢和比例不變），對個別事件追蹤無效（被丟棄的事件無法回復）。

設計責任

取樣承擔的設計責任是「在可觀測性覆蓋率和系統負載之間找到平衡」。Error 類事件不做取樣（每筆都可能是需要修的 bug），metric 類事件適合高比例取樣（丟幾筆不影響趨勢），event 類和 lifecycle 類取決於分析需求。

完整章節

靜態取樣率的設定 → 感測器生命週期管理。動態取樣在四層防線中的位置 → Ingestion Scaling。取樣造成的損失量化和控制 → 端到端資料完整性。

概念位置

Rollout Strategy 位在部署執行與正式流量切換之間，常見型態包含 rolling、canary、blue-green 與 phased rollout。

可觀察訊號

• 發布後需要觀察一段時間再擴大流量。
• 高風險變更不適合一次全量切換。
• 團隊需要把監控訊號綁定到擴大量決策。

接近真實服務的例子

後端 API 先以 10% canary 流量觀察錯誤率與延遲，再逐步推進。App 發布以 phased rollout 控制商店推送比例。

設計責任

Rollout Strategy 要定義推進節點、觀察指標、阻擋條件與升降級節奏，讓部署風險可被量化管理。

和 backpressure 的差異

Rate limiting 和 backpressure 都限制流量，但保護的維度不同。Rate limiting 是 per-client 的配額機制 — 每個 API key 有獨立的速率上限，一個 client 超限不影響其他 client。Backpressure 是全域的容量訊號 — collector 的寫入 channel 滿時對所有 client 回 429，不區分來源。一個 client 的失控用 rate limiting 處理（隔離問題源），全域流量過大用 backpressure 處理（全體降速）。

可觀察訊號與例子

Rate limiting 觸發的訊號是 collector 端對特定 API key 回 429 的次數上升、而其他 key 正常。典型場景：某個 SDK 版本有 bug 導致每秒產生 1000 筆事件 → per-key rate limiter 超過閾值 → 該 key 的後續 request 被回 429 → 其他 SDK 不受影響。

設計責任

Rate limiting 承擔的設計責任是「在公平性和可用性之間取得平衡」。閾值設太低，正常的 burst flush（攢批後一次送出）會被誤觸；閾值設太高，失控的 SDK 要送很多筆才被擋。合理的閾值需高於正常 burst 的事件速率。

完整章節

Per-SDK rate limiting 的實作 → Ingestion Scaling。Rate limiting 在 collector access control 中的角色 → Collector Access Control 實作。偽造流量場景下 rate limiting 和其他防護層的配合 → Client-side SDK 認證。

概念位置

Rollback Strategy 位在 deploy、rollout 與 incident handling 之間，通常要和資料遷移、feature flag 與流量切換一起設計。

可觀察訊號

• 發布後錯誤率或延遲快速升高。
• 新舊版本存在相容性風險。
• 團隊需要在分鐘級別恢復核心功能。

接近真實服務的例子

靜態站可回退前一版 artifact。後端服務可回退 image tag 並暫停新 migration。App 場域可先用 remote config 關閉新功能，再走 hotfix 發版。

設計責任

Rollback Strategy 要定義觸發條件、責任人、回退動作與回復後驗證，並定期演練。

概念位置

Deployment Dry Run 位在 build / test 完成後、production deploy 之前，通常以 preflight check、模擬發布或目標環境校驗實作。

可觀察訊號

• 正式部署常失敗於權限、路徑或配置差異。
• 團隊需要在不影響使用者前提下驗證部署條件。
• 發布流程包含高成本動作或不可逆步驟。

接近真實服務的例子

部署腳本先驗證 artifact 存在、環境密鑰可讀、目標 bucket 或 registry 可寫，再進入正式 deploy。

設計責任

Deployment Dry Run 要定義檢查範圍、成功條件、失敗回饋與執行時機，並和正式部署命令保持一致語意。

概念位置

Migration 位在 build 之後、deploy 與 rollout 之前後的關鍵路徑，常與 release gate、rollback strategy 一起設計。

可觀察訊號

• 新舊版本需要共存一段時間。
• 發布步驟包含 schema 或資料形狀變更。
• 部署失敗時要判斷是否可回退或需要 forward fix。

接近真實服務的例子

後端服務先擴充 schema，再讓新版本寫入新欄位，最後收斂舊欄位讀取；整個過程需要 migration gate 與回退方案。

設計責任

Migration 要定義相容策略、執行順序、觀測指標與異常回復路由，避免部署成功但資料邏輯失效。

概念位置

Branch Protection 位在 pull request 與主線分支之間，屬於 CI workflow 之外的治理層。

可觀察訊號

• 主線偶爾進入未驗證變更。
• workflow 已存在但合併條件未綁定。
• 團隊需要統一 reviewer 與狀態檢查門檻。

接近真實服務的例子

專案要求 md-check 與 Playwright tests 必須綠燈，且至少一位 reviewer 批准才可合併 main。

設計責任

Branch Protection 要定義必要 checks、審查規則與例外流程，並和 workflow 命名同步維護。

概念位置

Readiness / Health Check 位在 rollout、load balancer 與 runtime platform 之間，是流量切換前的核心 gate。

可觀察訊號

• 部署後健康檢查綠燈但請求仍大量失敗。
• 新版啟動中就提早接到流量。
• rollout 失敗時缺少可觀測放行條件。

接近真實服務的例子

Kubernetes liveness 通過只代表 process 存活；readiness 通過才代表連線池、依賴服務與必要資料都已準備完成。

設計責任

Readiness / Health Check 要定義檢查內容、容錯窗口與失敗處理，讓 rollout decision 有可信訊號。

概念位置

Container Registry 位在 image build、scan、promotion 與 runtime deploy 之間，連接 CI 產物與環境發布。

可觀察訊號

• 同一 tag 在不同環境對應內容不一致。
• 部署因拉取權限或鏡像不存在失敗。
• 線上 image 缺少來源與掃描紀錄的反查路徑。

接近真實服務的例子

團隊以 immutable digest 推進 staging 與 production，並透過 registry policy 控制 retention、pull 權限與 promotion 路徑。

設計責任

Container Registry 要定義命名策略、權限模型、保留策略與來源追溯，讓 image 發布具備可審計性。

概念位置

App Signing 位在 app build 與 release channel 之間，涉及 certificate、provisioning profile、keystore 與 secret 管理。

可觀察訊號

• 發布因簽章失敗中斷。
• 憑證過期導致發版中斷。
• 金鑰輪替缺乏演練造成交付風險。

接近真實服務的例子

iOS 發版需匹配正確 certificate 與 provisioning profile，Android 發版需維護 keystore 一致性與安全儲存。

設計責任

App Signing 要定義密鑰保存、輪替節奏、權限分離與緊急回復流程，確保發布能力可持續。

概念位置

Flaky Test 位在 test stage 與 release gate 之間，會放大重跑成本與判讀延遲。

可觀察訊號

• 同一 commit 重跑結果時好時壞。
• 失敗集中在等待條件、時間假設或外部依賴。
• 團隊習慣以重跑代替根因修復。

接近真實服務的例子

UI 測試在動畫未完成時抓取元素，或整合測試依賴不穩定第三方 API，都容易出現 flaky pattern。

設計責任

Flaky Test 治理要建立 owner、隔離策略、修復 SLA 與觀測指標，讓測試結果恢復可判讀性。

概念位置

Backfill 位在資料 schema、transform logic 或歷史資料修補之後，常出現在 data pipeline、database migration、search index rebuild 與 feature store 更新。

可觀察訊號

• 新欄位需要從既有資料補值。
• 歷史 partition 需要用新版邏輯重新計算。
• 補算任務需要節流、停損與對帳。

接近真實服務的例子

訂單報表新增 net_revenue 欄位時，pipeline 先讓新資料寫入新欄位，再分批 backfill 過去 12 個月的 partition，並用 row count 與金額總和比對結果。

設計責任

Backfill 要定義補算範圍、批次大小、checkpoint、停損條件與對帳方式，讓歷史資料修補成為可停止、可接續、可驗證的流程。

概念位置

Checkpoint 位在長時間 job、stream processor、batch pipeline 與 migration 任務之間，常以 partition、offset、run id、cursor 或 processed marker 呈現。

可觀察訊號

• 任務執行時間長，失敗後需要接續。
• 重跑同一區間可能造成重複寫入。
• streaming consumer 需要保存 offset 或 event position。

接近真實服務的例子

資料回填每次處理一個日期 partition，完成後寫入 backfill_runs 表。任務中斷時，下一次從最後成功 partition 的下一段開始。

設計責任

Checkpoint 要定義進度格式、提交時機、失敗恢復、重跑覆寫與觀測欄位，讓長時間任務具備可恢復性。

概念位置

Rerun 位在測試失敗、部署預演失敗、資料任務失敗或 pipeline repair 之後，負責判斷重新執行是否會改變輸出或擴大副作用。

可觀察訊號

• 同一 commit 的測試結果前後不一致。
• 資料任務部分成功、部分失敗。
• 部署 dry run 失敗後需要確認是否可安全再跑。

接近真實服務的例子

每日營收 pipeline 第三個 partition 寫入失敗。團隊先確認前兩個 partition 已完成且輸出可覆寫，再指定 run id 與 partition 範圍 rerun，避免重複計算全部歷史資料。

設計責任

Rerun 要定義可重跑條件、輸出覆寫規則、idempotency、觀測結果與人工審核門檻，讓「再跑一次」成為受控恢復策略。

概念位置

Image Digest 位在 image build、scan、registry promotion 與 runtime deploy 之間，通常以 sha256:... 形式標識 image manifest 或 image index。

可觀察訊號

• latest 或 mutable tag 造成 staging 與 production 內容分叉。
• production runtime 需要反查實際跑的 image。
• 掃描結果需要和部署內容精準對齊。

接近真實服務的例子

CI build image 後推到 registry，scan 報告綁定 digest。Kubernetes manifest 在 production 使用同一個 digest，事故時可從 running pod 反查 workflow run 與 source commit。

設計責任

Image Digest 要納入 deployment manifest、scan report、release note 與 rollback 記錄，讓 image 發布具備可追溯與可審計能力。

概念位置

SBOM 位在 build、scan、release 與 compliance review 之間，常見格式包含 SPDX、CycloneDX 或工具自訂輸出。

可觀察訊號

• 團隊需要知道 image 或 package 包含哪些 dependency。
• 漏洞公告需要快速判斷受影響 artifact。
• 高治理環境要求 release 產物附帶供應鏈證據。

接近真實服務的例子

Container image 發布時同時產生 SBOM，scan gate 依 SBOM 對照 CVE 與 license policy。若 base image 發現 critical vulnerability，團隊可查哪些 release digest 受影響。

設計責任

SBOM 要定義產出時機、格式、保存位置、artifact 對應關係與例外審核流程，讓供應鏈風險可以被查詢與治理。

概念位置

Release Channel 位在 artifact 發布與使用者取得之間，常見通道包含 internal、alpha、beta、stable、enterprise、nightly 與 rollback channel。

可觀察訊號

• 同一產品需要內測、公開測試與正式版本分流。
• 錯誤版本需要停止擴散或切回回復通道。
• 客戶端更新需要依風險分批推進。

接近真實服務的例子

桌面 app 先把 signed installer 推到 internal channel，驗證更新成功率後再推 beta channel，最後推 stable channel。若 stable 版本出現 crash，feed 可切回 rollback channel 或暫停更新。

設計責任

Release Channel 要定義通道用途、進入條件、artifact 命名、可見範圍、停損條件與回復路徑，讓版本擴散具備控制面。

概念位置

Update Feed 位在 signed artifact、release channel 與已安裝 app 之間，常包含版本號、下載 URL、signature、checksum、release notes 與最低支援版本。

可觀察訊號

• 客戶端需要自動偵測新版本。
• beta 與 stable 使用者需要看到不同版本。
• 錯誤版本需要從更新來源撤下。

接近真實服務的例子

Electron app 啟動時讀取 stable feed，取得最新 signed installer 與 signature。若新版本 crash rate 升高，團隊先撤下 feed 指向，讓未更新使用者停止取得錯誤版本。

設計責任

Update Feed 要定義簽章驗證、channel 分流、版本比較、fallback installer、撤版策略與 telemetry，讓已安裝客戶端安全升級。

概念位置

Infrastructure Drift 位在 IaC state、cloud resource、手動 hotfix 與外部 controller 之間，常由 console edit、事故修復、provider 預設值或自動調整造成。

可觀察訊號

• plan 顯示大量非預期變更。
• production 資源和 repository 宣告不一致。
• 下次 apply 可能覆蓋事故 hotfix。

接近真實服務的例子

事故中工程師在雲端 console 手動放寬 security group。服務恢復後，IaC plan 顯示 security group 與宣告檔不同；團隊需要判斷這個變更是短期 hotfix 還是應回寫成正式規則。

設計責任

Infrastructure Drift 要定義偵測頻率、owner、修復路由、state repair 與回寫規則，讓平台狀態重新回到可審查流程。

概念位置

State Lock 位在 IaC state backend、plan / apply workflow 與平台資源之間，常由 Terraform backend、Pulumi state 或平台鎖定機制提供。

可觀察訊號

• 多個 pipeline 同時 apply 同一個 workspace。
• state file 出現併發覆寫或 partial apply 後不一致。
• apply 長時間卡住需要判斷 lock 是否仍有效。

接近真實服務的例子

兩個 PR 同時修改 production network。第一個 workflow 取得 state lock 後進入 apply，第二個 workflow 等待或失敗，避免兩次變更同時寫入 state。

設計責任

State Lock 要定義 lock backend、timeout、人工解鎖條件、環境隔離與失敗處理，讓 IaC apply 保持序列化。

概念位置

Function Alias 位在 function version、traffic weight、event source 與 invocation entrypoint 之間，常見於 Lambda alias 或其他 serverless 平台的版本別名。

可觀察訊號

• 新舊 function version 需要短暫共存。
• 部分流量需要導向新版本做 canary。
• 事故時需要把入口切回上一個版本。

接近真實服務的例子

HTTP function 的 prod alias 先把 5% 流量導向 version 42。若錯誤率穩定，逐步提高權重；若錯誤率升高，alias 切回 version 41。

設計責任

Function Alias 要定義版本命名、流量權重、觀測指標、事件來源綁定與回復條件，讓函式發布具備可控入口。

概念位置

Event Source 位在 queue、topic、HTTP gateway、object storage、scheduler 與 function / worker 之間，負責把外部事件轉成執行請求。

可觀察訊號

• 函式部署成功，但 invocation 因 trigger 設定失敗。
• Queue event 重試造成同一筆資料被重複處理。
• 事件 schema 漂移導致 subscriber 解析失敗。

接近真實服務的例子

Queue 觸發的 function 以 batch 方式處理訊息。新版本解析失敗時，訊息進入 dead-letter queue；團隊先停用 trigger，再修復 function 或重放事件。

設計責任

Event Source 要定義 trigger 條件、batch size、retry、dead-letter、replay、權限與 schema 契約，讓事件驅動發布具備可觀測回復路徑。

概念位置

Validation query 位在 schema migration、data reconciliation 與 evidence package 之間。Correctness check 定義要驗什麼，validation query 則把規則落成可查、可保存、可交接的證據。

可觀察訊號

系統需要 validation query 的訊號是：

• 新舊欄位或新舊資料模型會並存一段時間
• backfill job 顯示完成，但仍需要證明資料語意正確
• cutover 前要知道 mismatch 集中在哪些資料範圍
• 事故修復後要留下可回放的資料證據

接近真實網路服務的例子

訂單服務把 status 裡的付款語意拆到 payment_state 時，validation query 可以比對每批訂單的新舊語意、缺值筆數、mismatch sample 與 replication lag 對位。這些結果會進入 release gate，而不是只停在 migration job 的成功訊息。

設計責任

Validation query 要保留 query version、time range、資料範圍、mismatch 分類與 owner。它的目標是支援 rollback window 與 incident decision log 判讀，讓團隊能知道下一步是繼續、暫停、回退讀取，還是做資料修補。

概念位置

Read compatibility 位在 dual write、cutover / switchover 與 migration gate 之間。雙寫處理寫入一致性，read compatibility 處理讀取方如何在缺值、延遲回填或版本混跑時仍能給出一致判讀。

可觀察訊號

系統需要 read compatibility 的訊號是：

• 新欄位已新增，但歷史資料尚未全部 backfill
• 新舊程式版本會同時服務流量
• rollback 後舊版本仍需要讀懂 production 資料
• 內部後台、對帳或報表的切換節奏不同於使用者可見路徑

接近真實網路服務的例子

訂單服務新增 payment_state 後，讀取時可先看新欄位，缺值時回到舊 status 的付款語意。客服後台可以先用這條相容讀取路徑驗證資料，再逐步讓使用者可見查詢改用新欄位。

設計責任

Read compatibility 要定義讀取優先順序、fallback read 條件、資料新鮮度限制與停止條件。它要搭配 validation query 與 rollback strategy，避免 cutover 後才發現舊版本或長尾讀取路徑無法判讀資料。

概念位置

Fallback read 位在 cutover / switchover、schema migration 與 rollback strategy 之間。它保留新資料結構、暫時把讀取判斷交回舊語意或舊來源，比完整 rollback 成本低且破壞性小。

可觀察訊號

系統需要 fallback read 的訊號是：

• 新欄位讀取後 mismatch 升高
• 客服後台、報表或使用者可見查詢結果漂移
• 寫入路徑已經收斂，但讀取模型或索引尚未穩定
• release gate 允許暫停 cutover，但尚未需要資料修補

接近真實網路服務的例子

訂單服務把付款狀態拆到 payment_state 後，客服後台若發現新欄位判讀 mismatch 升高，可以先回到舊 status 的付款語意讀取，讓客服分類回到基線，同時保留 backfill 與 validation query 繼續查證。

設計責任

Fallback read 要定義觸發條件、讀取優先順序、可維持多久、哪些入口適用，以及何時重新嘗試 cutover。它要與 validation query 和 incident decision log 對齊，避免讀取回退變成沒有證據的永久分岔。

概念位置

Cutover window 位在 release gate、steady state 與 evidence package 之間。Release gate 決定能否開始切換，cutover window 定義切換後多久內要看哪些訊號、達到什麼條件才算穩定。

可觀察訊號

系統需要 cutover window 的訊號是：

• 新路徑開始承接正式讀取或寫入
• 切換後需要觀察 mismatch、latency、error rate 或 lag
• 回退條件只在切換初期仍然低成本
• 多個入口會分批切換，需要分別記錄時間窗

接近真實網路服務的例子

客服後台先切到新 payment_state 讀取後，前 30 分鐘是 cutover window。這段期間要看 mismatch sample、客服查詢慢查詢、對帳補償量與 rollback window；穩定後才放行使用者可見讀取。

設計責任

Cutover window 要定義開始時間、觀察長度、通過條件、stop condition 與 owner。它應進入 evidence package 與 incident decision log，讓事後能回放切換當時的訊號。

概念位置

Mapping table 位在 backfill、data reconciliation 與 migration gate 之間。Backfill 依它轉換資料，validation query 依它判斷 mismatch，incident decision log 則依它追溯當時的判讀依據。

可觀察訊號

系統需要 mapping table 的訊號是：

• 舊欄位混合多種業務語意，需要拆到新欄位
• 多個舊狀態會對應到同一個新狀態
• 某些舊狀態需要人工確認或例外處理
• 事後要能解釋 mismatch 是資料錯誤還是轉換規則錯誤

接近真實網路服務的例子

訂單服務把 pending_payment、paid、payment_failed、refunded 對應到 payment_state 的 pending、captured、failed、refunded。這張 mapping table 同時支撐 backfill job、validation query 與 cutover gate。

設計責任

Mapping table 要保留來源欄位、新欄位、對應理由、例外狀態與 owner。高風險 mapping 要版本化，並進入 evidence package；否則資料漂移時，團隊很難判斷問題出在資料、程式還是規則本身。

概念位置

Rollback window 位在 cutover / switchover、fallback plan 與 incident decision log 之間。Rollback strategy 說明回退決策，rollback window 說明這個決策在目前階段是否仍可執行。

可觀察訊號

系統需要 rollback window 的訊號是：

• expand、backfill、cutover、contract 每一階段的回退方式不同
• 舊版本或舊資料語意只能支撐一段時間
• cutover 後仍可 fallback read，但 contract 後只能資料修復或 fail-forward
• release gate 要判斷是否還能安全暫停或回退

接近真實網路服務的例子

資料庫 migration 在 expand 階段通常能回到舊讀取；backfill 階段可以暫停與重跑；cutover 後可回到 fallback read；contract 移除舊欄位後，回退會轉成資料修補或 fail-forward。這些差異都屬於 rollback window。

設計責任

Rollback window 要寫清楚目前階段、可用回退方式、最後可回退時間、資料相容性限制與 owner。它要進入 release gate 與 incident decision log，避免事故期間把已經關閉的退路當成可用選項。

概念位置

Fail-forward 位在 rollback window、containment 與 post-incident review 之間。Rollback window 關閉後，團隊仍需要一條能限制影響、補資料、完成相容收斂的前進路線。

可觀察訊號

系統需要 fail-forward 的訊號是：

• 舊資料語意已被 contract 或不可逆寫入移除
• 回退會造成更大的資料不一致或客戶影響
• 新路徑有明確修補方案、停損條件與 owner
• 事故 decision log 需要記錄為何不回滾

接近真實網路服務的例子

資料庫 migration 已完成 contract 後，舊欄位被移除，回到舊版本會讓讀取路徑失效。此時比較可控的做法可能是暫停部分寫入、修補 mismatch、補 validation query，再讓新路徑收斂到可用狀態。

設計責任

Fail-forward 要定義 containment、修補步驟、預期效果、停止條件與回寫項目。它要搭配 evidence package 與 action item closure，避免「不能回滾」被誤用成沒有證據的硬推。

概念位置

Stop condition 位在 migration gate、cutover-window 與 steady state 之間。Gate 說明能否開始，stop condition 說明開始後看到哪些訊號必須停。

可觀察訊號

系統需要 stop condition 的訊號是：

• rollout、backfill、replay 或 experiment 會逐批擴大影響
• 指標短暫變壞時需要知道是觀察、暫停還是回退
• owner 需要在事故現場快速做一致決策
• post-incident review 要檢查當時是否該更早停下來

接近真實網路服務的例子

資料庫 migration 可以定義 mismatch_rate >= 0.1% for two consecutive batches 或 replication_lag >= 30s for 10 minutes 作為 stop condition。達到條件時，團隊先暫停下一批 backfill 或回到 fallback read，而不是等使用者回報。

設計責任

Stop condition 要包含訊號、門檻、觀察窗口、對應動作與 owner。它要進入 release gate 和 incident decision log，並且要能被 evidence package 支撐。

概念位置

Gate decision 位在 confidence、rollback window 與 incident decision log 之間。Checks 描述檢查結果，gate decision 把結果轉成放行、暫停、回退、fail-forward 或補證據。

可觀察訊號

系統需要 gate decision 的訊號是：

• CI、SLO、validation query 都有結果，但沒人知道下一步
• evidence 足以支持部分放行，但不足以支持完整 cutover
• 變更需要逐批 rollout、backfill、warmup 或 replay
• gate 要保留 owner 與 rollback window

接近真實網路服務的例子

資料庫 migration 的 gate decision 可以寫成 allow next 10% backfill; block customer-visible read cutover。這句話比 migration pass 更可操作，因為它同時說明允許前進的範圍與被擋住的風險面。

設計責任

Gate decision 要包含決策內容、支撐 checks、stop condition、rollback window 與 owner。它要能被 incident decision log 承接，讓放行後出現異常時能回放當時依據。

概念位置

Rollback condition 位在 gate decision、rollback window 與 time range 之間。Stop condition 常用於流程何時停，rollback condition 則跟某筆已做出的 decision 綁在一起。

可觀察訊號

系統需要 rollback condition 的訊號是：

• rollback、fallback、degradation 或 fail-forward 本身也可能造成風險
• IC handoff 後，新 IC 需要知道什麼條件下要改路線
• stakeholder update 需要說明目前決策如何被監控
• PIR 需要檢查當時是否有明確撤回條件

接近真實網路服務的例子

客服後台切回 legacy status fallback 後，rollback condition 可以寫成 mismatch remains above threshold after 15 minutes。這表示 fallback 沒有降低錯誤時，團隊要改成資料修補或暫停相關入口，而不是繼續等待。

設計責任

Rollback condition 要包含訊號、門檻、觀察窗口、對應動作與 owner。它要連到 query link 與 time range，讓決策撤回成為可回放的證據判讀，口頭判斷的準確度和可追溯性都不足。

概念位置

Time range 位在 dashboard、query link 與 incident decision log 之間。Dashboard 顯示狀態，query link 保留查詢入口，time range 則定義這次判讀看的時間範圍。

可觀察訊號

系統需要 time range 的訊號是：

• 同一張圖在不同時間重跑會得到不同結果
• release gate 要判斷某批 rollout 是否已穩定
• 事故交班需要知道某個 evidence 觀察的是哪段時間
• 復盤要對齊 deploy、alert、customer report 與 rollback 的先後

接近真實網路服務的例子

資料庫 migration 的 validation query 若標示 2026-05-11T02:10:00Z/2026-05-11T02:20:00Z，下一班 on-call 就能把 mismatch、replication lag 與 slow query 放回同一個 backfill batch 判讀。

設計責任

Time range 要定義開始時間、結束時間、時區、資料延遲限制與關聯事件。它應進入 evidence package 與 rollback condition，避免團隊用不同時間窗比較同一個決策。

概念位置

Query link 位在 dashboard、validation query 與 incident decision log 之間。截圖適合溝通當下狀態，query link 則保留可回放、可調整、可驗證的入口。

可觀察訊號

系統需要 query link 的訊號是：

• 事故交班時下一班需要重跑同一個判讀
• release gate 要引用具體查詢結果，而不是貼圖表摘要
• PIR reviewer 需要查證當時資料限制
• dashboard panel 版本變動可能改變圖表語意

接近真實網路服務的例子

Checkout API evidence package 可以保存錯誤率 query、p95 latency query 與 provider timeout query 的連結。資料庫 migration evidence package 則可以保存 row count、mismatch sample 與 replication lag query link。

設計責任

Query link 要保留查詢版本、參數、time range、資料來源與 owner。它要搭配 known gap 記錄查詢未覆蓋的資料範圍，避免截圖或 dashboard 名稱被誤當成完整證據。

概念位置

Data quality 位在 metrics、trace 與 incident decision log 之間。Metric、log、trace、audit log 都可能有延遲、抽樣、drop、masking 或 schema drift，這些限制要跟證據一起交接。

可觀察訊號

系統需要 data quality 的訊號是：

• trace sampling 讓某些 request path 無法完整重建
• log pipeline 有 ingest delay 或 drop
• query 只跑 primary、replica 或部分 tenant
• dashboard 結論需要標示 freshness 或 completeness 限制

接近真實網路服務的例子

資料庫 migration 的 evidence package 可以標示 primary only; replica lag still recovering，表示 validation query 可信，但 replica 讀取路徑還不能用同一份 evidence 直接放行。

設計責任

Data quality 要標示 completeness、freshness、sampling、masking、retention 與 owner。它要支援 confidence 判讀，避免 release gate 或 incident decision log 把有限資料誤當成完整事實。

概念位置

Confidence 位在 query link、known gap 與 incident decision log 之間。它不是情緒性的「我覺得」，而是基於證據完整度、資料限制與反向驗證狀態的判讀欄位。

可觀察訊號

系統需要 confidence 的訊號是：

• evidence 足以支持繼續 backfill，但不足以支持使用者可見 cutover
• 事故中某個根因還在 suspected 狀態
• release gate 需要分辨可以放行、暫停或補證據
• stakeholder update 需要避免把未確認資訊說成事實

接近真實網路服務的例子

資料庫 migration 的 evidence package 可以把 confidence 標成 suspected：validation query 顯示 mismatch 低於門檻，但 manual refund repair path 尚未被抽樣，因此只放行下一批 backfill，不放行使用者可見讀取 cutover。

設計責任

Confidence 要定義等級、證據依據、限制與下一步。它要與 known gap 和 rollback condition 一起保存，避免團隊把暫時結論當成穩定事實。

概念位置

Known gap 位在 confidence、query link 與 post-incident review 之間。Data quality 說明資料限制，known gap 則列出目前尚未被證據覆蓋的具體範圍。

可觀察訊號

系統需要 known gap 的訊號是：

• 某些 tenant、region、callback path 或 manual repair path 未被抽樣
• trace 或 log 缺少關鍵 span / field
• release gate 放行時仍有需要 follow-up 的證據缺口
• PIR 需要把缺口回寫成 readiness 或 observability 改善項

接近真實網路服務的例子

資料庫 migration evidence package 可以記錄 manual refund repair path not yet sampled。這個 known gap 會限制 cutover decision，並回寫成後續 validation query 或 audit log coverage 的改善項。

設計責任

Known gap 要描述缺口內容、影響範圍、目前風險、owner 與 follow-up。它要支援 confidence 分級，避免 evidence package 看起來完整，但實際漏掉高風險路徑。

概念位置

Outbound tunnel 位在本機進程與公網之間，取代傳統的 port-forward 或 load balancer 入口。常與 TLS / mTLS 搭配保護隧道內的傳輸安全，認證則疊在 tunnel 之後由 authentication middleware 處理。

常見實作包括 cloudflared（綁 Cloudflare 邊緣）和 Tailscale（WireGuard mesh VPN）。隧道網址是位址、不是密碼 — 認證必須疊在 tunnel 之後。

深入：5.10 Outbound Tunnel 入口與生命週期。選型案例：7.C11 Tailscale vs Cloudflare Tunnel。