可靠性 on Tarragonhttps://tarrragon.github.io/blog/tags/%E5%8F%AF%E9%9D%A0%E6%80%A7/Recent content in 可靠性 on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Tue, 23 Jun 2026 00:00:00 +0000Static Stabilityhttps://tarrragon.github.io/blog/backend/knowledge-cards/static-stability/Tue, 23 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/knowledge-cards/static-stability/<p>Static stability 的核心概念是「資料面在 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/control-plane/" data-link-title="Control Plane" data-link-desc="負責下發策略、配置與路由決策的控制層">control plane</a> 失效時仍能維持服務」。設計約束是資料面必須快取控制面最後已知的好配置，並在控制面不可用時用快取繼續運作，不依賴控制面即時回應。</p> <h2 id="概念位置">概念位置</h2> <p>Static stability 位在 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/control-plane/" data-link-title="Control Plane" data-link-desc="負責下發策略、配置與路由決策的控制層">control plane</a> 與 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/blast-radius/" data-link-title="Blast Radius" data-link-desc="說明事故影響面如何估算與隔離">blast radius</a> 之間。它把控制面失效的影響限制在「新配置無法推送」，而非「現有服務中斷」。跟 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/steady-state/" data-link-title="Steady State" data-link-desc="說明可靠性實驗與事故恢復如何定義系統應維持的可接受狀態">steady state</a> 的關係是：static stability 定義了控制面失效期間的 degraded steady state — 服務能力受限但仍在可接受範圍。</p> <h2 id="核心機制">核心機制</h2> <p>Static stability 依賴三個機制：快取最後已知好配置（控制面失效時不嘗試重新取得）、預計算 fallback 路徑（控制面在線時就 build 好備用配置）、constant work pattern（失敗模式下的工作量跟正常時相同，避免 retry storm 放大負載）。</p> <h2 id="可觀察訊號與例子">可觀察訊號與例子</h2> <p>需要 static stability 設計的訊號是控制面重啟或網路隔離時，資料面同時不可用。典型例子是 service mesh 的 control plane 掛掉後 sidecar 無法取得路由表、導致所有服務間通訊中斷；static stability 設計讓 sidecar 用快取的路由表繼續服務。</p> <h2 id="設計責任">設計責任</h2> <p>Static stability 的責任是讓 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/rto/" data-link-title="RTO" data-link-desc="說明恢復時間目標如何約束事故回復策略">DR</a> 設計不依賴已故障的控制面。它跟 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/readiness/" data-link-title="Readiness" data-link-desc="說明 instance 何時可以安全接收流量，以及 readiness 如何和部署平台協作">readiness</a> 的關係是：static stability 是 readiness review 的前置項 — 若資料面沒有控制面失效時的自主能力，readiness 就有結構性缺口。</p>Static stability 的核心概念是「資料面在 control plane 失效時仍能維持服務」。設計約束是資料面必須快取控制面最後已知的好配置，並在控制面不可用時用快取繼續運作，不依賴控制面即時回應。

概念位置

Static stability 位在 control plane 與 blast radius 之間。它把控制面失效的影響限制在「新配置無法推送」，而非「現有服務中斷」。跟 steady state 的關係是：static stability 定義了控制面失效期間的 degraded steady state — 服務能力受限但仍在可接受範圍。

核心機制

Static stability 依賴三個機制：快取最後已知好配置（控制面失效時不嘗試重新取得）、預計算 fallback 路徑（控制面在線時就 build 好備用配置）、constant work pattern（失敗模式下的工作量跟正常時相同，避免 retry storm 放大負載）。

可觀察訊號與例子

需要 static stability 設計的訊號是控制面重啟或網路隔離時，資料面同時不可用。典型例子是 service mesh 的 control plane 掛掉後 sidecar 無法取得路由表、導致所有服務間通訊中斷；static stability 設計讓 sidecar 用快取的路由表繼續服務。

設計責任

Static stability 的責任是讓 DR 設計不依賴已故障的控制面。它跟 readiness 的關係是：static stability 是 readiness review 的前置項 — 若資料面沒有控制面失效時的自主能力，readiness 就有結構性缺口。

]]>Resiliency Matrixhttps://tarrragon.github.io/blog/backend/knowledge-cards/resiliency-matrix/Tue, 23 Jun 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/knowledge-cards/resiliency-matrix/<p>Resiliency matrix 的核心概念是「用 service × failure mode 的交叉矩陣，把系統的防護狀態從隱性假設變成可檢查資產」。每個交叉點標記 covered（有防護且已驗證）、gap（已知缺口待補）或 in-progress（防護建置中），讓團隊能系統性地追蹤 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/blast-radius/" data-link-title="Blast Radius" data-link-desc="說明事故影響面如何估算與隔離">blast radius</a> 覆蓋。</p> <h2 id="概念位置">概念位置</h2> <p>Resiliency matrix 位在 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/blast-radius/" data-link-title="Blast Radius" data-link-desc="說明事故影響面如何估算與隔離">blast radius</a> 與 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/readiness/" data-link-title="Readiness" data-link-desc="說明 instance 何時可以安全接收流量，以及 readiness 如何和部署平台協作">readiness</a> 之間。它把失敗模式盤點（FMEA / pre-mortem）的產出結構化成可追蹤矩陣，並驅動 <a href="https://tarrragon.github.io/blog/backend/knowledge-cards/game-day/" data-link-title="Game Day" data-link-desc="說明事故演練如何驗證流程、工具與團隊協作">game day</a> 演練題目的選擇 — gap 欄直接成為演練的優先目標。</p> <h2 id="可觀察訊號與例子">可觀察訊號與例子</h2> <p>需要 resiliency matrix 的訊號是團隊知道有風險但不確定哪些已有防護。典型例子是高峰活動前的準備流程：把所有關鍵服務列成行、所有失敗模式（依賴斷線 / 容量超限 / 資料污染 / 配置漂移）列成列，逐格檢查防護狀態。Shopify 在 BFCM 準備中使用這個工具把年度驗證進度視覺化。</p> <h2 id="設計責任">設計責任</h2> <p>Resiliency matrix 的責任是把 reliability debt 從模糊的「我們知道有缺口」變成可排序、可追蹤的清單。它的維護節奏跟 <a href="https://tarrragon.github.io/blog/backend/06-reliability/reliability-debt-backlog/" data-link-title="6.21 Reliability Debt Backlog" data-link-desc="把反覆事故、演練缺口與手動修復累積成可排序、可關閉的 reliability debt">6.21 reliability debt backlog</a> 對齊 — 每次演練後更新 matrix 的 gap/covered 狀態，每季 review matrix 的完整性。matrix 變成文件而不是工具（超過 6 個月未更新、gap 無 owner）是治理失敗的訊號。</p>Resiliency matrix 的核心概念是「用 service × failure mode 的交叉矩陣，把系統的防護狀態從隱性假設變成可檢查資產」。每個交叉點標記 covered（有防護且已驗證）、gap（已知缺口待補）或 in-progress（防護建置中），讓團隊能系統性地追蹤 blast radius 覆蓋。

概念位置

Resiliency matrix 位在 blast radius 與 readiness 之間。它把失敗模式盤點（FMEA / pre-mortem）的產出結構化成可追蹤矩陣，並驅動 game day 演練題目的選擇 — gap 欄直接成為演練的優先目標。

可觀察訊號與例子

需要 resiliency matrix 的訊號是團隊知道有風險但不確定哪些已有防護。典型例子是高峰活動前的準備流程：把所有關鍵服務列成行、所有失敗模式（依賴斷線 / 容量超限 / 資料污染 / 配置漂移）列成列，逐格檢查防護狀態。Shopify 在 BFCM 準備中使用這個工具把年度驗證進度視覺化。

設計責任

Resiliency matrix 的責任是把 reliability debt 從模糊的「我們知道有缺口」變成可排序、可追蹤的清單。它的維護節奏跟 6.21 reliability debt backlog 對齊 — 每次演練後更新 matrix 的 gap/covered 狀態，每季 review matrix 的完整性。matrix 變成文件而不是工具（超過 6 個月未更新、gap 無 owner）是治理失敗的訊號。

]]>