模組零案例正文 on Tarragonhttps://tarrragon.github.io/blog/backend/00-service-selection/cases/Recent content in 模組零案例正文 on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Thu, 07 May 2026 00:00:00 +0000FinTech：合規壓力下的後端選型https://tarrragon.github.io/blog/backend/00-service-selection/cases/fintech-compliance-and-selection-pressure/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/00-service-selection/cases/fintech-compliance-and-selection-pressure/<p>這個案例的核心責任是把合規壓力轉成選型條件。FinTech 場景下，資料保留、審計追溯與交易一致性通常比純效能優先。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>判讀重點</th> <th>對應章節</th> </tr> </thead> <tbody> <tr> <td>audit evidence gap</td> <td>稽核證據是否連續</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/security-data-protection-requirements/" data-link-title="0.8 資安與資料保護需求" data-link-desc="從權限分級、伺服器防護、資料遮罩、傳輸保護與稽核設計安全邊界">0.8</a></td> </tr> <tr> <td>duplicate transaction risk</td> <td>重試是否可能造成雙重結果</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/state-storage-selection/" data-link-title="0.2 狀態與資料儲存選型" data-link-desc="區分 source of truth、快取、搜尋索引、event log 與 object storage 的選型邊界">0.2</a></td> </tr> <tr> <td>release freeze frequency</td> <td>發布是否常因風險臨時凍結</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/cost-risk-tradeoffs/" data-link-title="0.6 成本、風險與選型取捨" data-link-desc="用人力成本、雲端成本、操作成本與失敗代價判斷後端能力投入順序">0.6</a></td> </tr> </tbody> </table> <h2 id="風險與邊界">風險與邊界</h2> <p>把合規當成部署後補強會抬高長期成本。較穩定的做法是在選型時就定義證據鏈、資料邊界與回復順序，避免後續跨模組反覆返工。</p> <h2 id="下一步路由">下一步路由</h2> <p>先補 <a href="https://tarrragon.github.io/blog/backend/04-observability/audit-log-governance/" data-link-title="4.12 Audit Log 邊界與 PII 治理" data-link-desc="把稽核訊號從 operational log 拆出、按法規與不變性治理">4.12</a> 的審計訊號，再用 <a href="https://tarrragon.github.io/blog/backend/06-reliability/release-gate/" data-link-title="6.8 Release Gate 與變更節奏" data-link-desc="把驗證、migration、相容性納入放行判準">6.8</a> 定義合規變更門檻。</p>這個案例的核心責任是把合規壓力轉成選型條件。FinTech 場景下，資料保留、審計追溯與交易一致性通常比純效能優先。

判讀訊號

訊號 判讀重點 對應章節
audit evidence gap 稽核證據是否連續 0.8
duplicate transaction risk 重試是否可能造成雙重結果 0.2
release freeze frequency 發布是否常因風險臨時凍結 0.6

風險與邊界

把合規當成部署後補強會抬高長期成本。較穩定的做法是在選型時就定義證據鏈、資料邊界與回復順序，避免後續跨模組反覆返工。

下一步路由

先補 4.12 的審計訊號，再用 6.8 定義合規變更門檻。

]]>Gaming：高峰流量與隔離邊界選型https://tarrragon.github.io/blog/backend/00-service-selection/cases/gaming-peak-traffic-and-isolation/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/00-service-selection/cases/gaming-peak-traffic-and-isolation/<p>這個案例的核心責任是把活動高峰轉成預先可驗證的容量與隔離決策。Gaming 場景的失效通常來自瞬間峰值與連線風暴疊加。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>判讀重點</th> <th>對應章節</th> </tr> </thead> <tbody> <tr> <td>peak burst ratio</td> <td>尖峰是否超過模型緩衝</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/traffic-data-scale/" data-link-title="0.5 流量與資料量評估" data-link-desc="用流量形狀、資料成長、hot key、保留期限與尖峰模式評估後端需求規模">0.5</a></td> </tr> <tr> <td>matchmaking queue lag</td> <td>非同步鏈路是否壅塞</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/async-delivery-selection/" data-link-title="0.3 非同步與事件傳遞選型" data-link-desc="區分背景工作、durable queue、stream、pub/sub 與 outbox 的選型邊界">0.3</a></td> </tr> <tr> <td>reconnect storm indicator</td> <td>回復是否放大負載</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/failure-observability-design/" data-link-title="0.7 錯誤定位、觀測訊號與備援切換設計" data-link-desc="從錯誤分類、定位線索、降級策略與 failover 設計服務可維護性">0.7</a></td> </tr> </tbody> </table> <h2 id="風險與邊界">風險與邊界</h2> <p>只追求低延遲而忽略隔離邊界，會在高峰時把單一熱點擴散成全域事故。選型時需要同時定義分流邏輯與分批恢復策略。</p> <h2 id="下一步路由">下一步路由</h2> <p>把容量假設回寫 <a href="https://tarrragon.github.io/blog/backend/06-reliability/capacity-cost/" data-link-title="6.9 容量與成本邊界" data-link-desc="把容量規劃跟成本約束變成驗證輸入">6.9</a>，並在 <a href="https://tarrragon.github.io/blog/backend/08-incident-response/multi-incident-coordination/" data-link-title="8.14 Multi-incident Coordination" data-link-desc="把同時多事故的優先序、資源分配與 incident command system pool 協調變成可執行流程">8.14</a> 補多事故協調規則。</p>這個案例的核心責任是把活動高峰轉成預先可驗證的容量與隔離決策。Gaming 場景的失效通常來自瞬間峰值與連線風暴疊加。

判讀訊號

訊號 判讀重點 對應章節
peak burst ratio 尖峰是否超過模型緩衝 0.5
matchmaking queue lag 非同步鏈路是否壅塞 0.3
reconnect storm indicator 回復是否放大負載 0.7

風險與邊界

只追求低延遲而忽略隔離邊界，會在高峰時把單一熱點擴散成全域事故。選型時需要同時定義分流邏輯與分批恢復策略。

下一步路由

把容量假設回寫 6.9，並在 8.14 補多事故協調規則。

]]>Healthcare：資料主權與回復順序選型https://tarrragon.github.io/blog/backend/00-service-selection/cases/healthcare-data-sovereignty-and-recovery/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/00-service-selection/cases/healthcare-data-sovereignty-and-recovery/<p>這個案例的核心責任是讓資料主權與可用性同時被治理。Healthcare 場景常同時面臨資料區域限制、最小存取原則與緊急回復需求。</p> <h2 id="判讀訊號">判讀訊號</h2> <table> <thead> <tr> <th>訊號</th> <th>判讀重點</th> <th>對應章節</th> </tr> </thead> <tbody> <tr> <td>cross-region data movement</td> <td>是否違反主權邊界</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/security-data-protection-requirements/" data-link-title="0.8 資安與資料保護需求" data-link-desc="從權限分級、伺服器防護、資料遮罩、傳輸保護與稽核設計安全邊界">0.8</a></td> </tr> <tr> <td>access audit completeness</td> <td>存取證據是否可追溯</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/state-storage-selection/" data-link-title="0.2 狀態與資料儲存選型" data-link-desc="區分 source of truth、快取、搜尋索引、event log 與 object storage 的選型邊界">0.2</a></td> </tr> <tr> <td>recovery ordering conflict</td> <td>回復步驟是否與合規衝突</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/failure-observability-design/" data-link-title="0.7 錯誤定位、觀測訊號與備援切換設計" data-link-desc="從錯誤分類、定位線索、降級策略與 failover 設計服務可維護性">0.7</a></td> </tr> </tbody> </table> <h2 id="風險與邊界">風險與邊界</h2> <p>將合規需求與 DR 流程分開設計，容易在事故時出現互斥決策。較穩定做法是先定義可恢復資料集合與不可跨境資料集合，再安排回復順序。</p> <h2 id="下一步路由">下一步路由</h2> <p>先補 <a href="https://tarrragon.github.io/blog/backend/04-observability/observability-operating-model/" data-link-title="4.18 Observability Operating Model" data-link-desc="定義 platform / service team / on-call 對訊號、dashboard、alert 與成本的 ownership">4.18</a> 的責任邊界，再在 <a href="https://tarrragon.github.io/blog/backend/06-reliability/dr-rollback-rehearsal/" data-link-title="6.7 DR 演練與 Rollback Rehearsal" data-link-desc="把回復路徑從紙面計畫變成定期可重播、可量測的驗證流程">6.7</a> 驗證回復流程。</p>這個案例的核心責任是讓資料主權與可用性同時被治理。Healthcare 場景常同時面臨資料區域限制、最小存取原則與緊急回復需求。

判讀訊號

訊號 判讀重點 對應章節
cross-region data movement 是否違反主權邊界 0.8
access audit completeness 存取證據是否可追溯 0.2
recovery ordering conflict 回復步驟是否與合規衝突 0.7

風險與邊界

將合規需求與 DR 流程分開設計，容易在事故時出現互斥決策。較穩定做法是先定義可恢復資料集合與不可跨境資料集合，再安排回復順序。

下一步路由

先補 4.18 的責任邊界，再在 6.7 驗證回復流程。

]]>營運後技術轉換：語言、工具與架構何時該換https://tarrragon.github.io/blog/backend/00-service-selection/cases/post-scale-migration-language-tool-architecture/Thu, 07 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/00-service-selection/cases/post-scale-migration-language-tool-architecture/<p>這個案例的核心責任是把「營運後轉換」變成可判讀決策，而不是技術潮流追逐。服務在成長期常會遇到早期選型與現況負載不再匹配，此時轉換的重點是風險收斂與效率改善，而不是語言偏好。</p> <h2 id="大量真實案例與轉換原因">大量真實案例與轉換原因</h2> <table> <thead> <tr> <th>案例</th> <th>轉換類型</th> <th>為什麼轉換</th> </tr> </thead> <tbody> <tr> <td>Slack：PHP 逐步遷移到 Hack</td> <td>語言/型別系統</td> <td>以漸進式靜態型別提升重構安全與開發效率，降低 runtime 才暴露型別錯誤的成本。</td> </tr> <tr> <td>Discord：Read States 服務 Go 重寫為 Rust</td> <td>語言/執行模型</td> <td>Go 服務在特定負載下出現 GC 造成的週期性延遲尖峰，Rust 以無 GC 記憶體模型降低延遲抖動。</td> </tr> <tr> <td>Dropbox：Python 2 轉 Python 3</td> <td>語言/runtime 生命週期</td> <td>Python 2 EOL 與型別工具鏈演進壓力，驅動全面升級並降低長期維護風險。</td> </tr> <tr> <td>Dropbox：內部 RPC 轉向 gRPC（Courier）</td> <td>工具/協定標準化</td> <td>多語言服務擴張後，需要統一傳輸契約、提高跨團隊可維護性與可觀測性。</td> </tr> <tr> <td>GitLab：單一資料庫拆成 Main/CI 資料庫</td> <td>資料層架構</td> <td>單庫承載產品與 CI 工作負載，容量與干擾風險上升，需以職責拆分換取穩定性。</td> </tr> <tr> <td>Notion：Postgres 單庫轉分片</td> <td>資料層架構</td> <td>寫入與資料量成長造成熱點與容量壓力，以分片提升可擴展性與故障隔離。</td> </tr> <tr> <td>Shopify：Rails 後端引入 Vitess 水平擴充</td> <td>資料層工具</td> <td>MySQL 垂直擴充成本上升，需在不中斷服務前提下取得分片與路由能力。</td> </tr> <tr> <td>Shopify：Ruby 導入 Sorbet 靜態型別</td> <td>工具/語言治理</td> <td>大型程式碼庫重構與跨團隊協作風險高，需要型別訊號降低變更不確定性。</td> </tr> <tr> <td>Figma：服務遷移至 Kubernetes</td> <td>平台/部署工具</td> <td>手工或半自動部署流程難以支撐規模成長，需要統一調度、回滾與資源治理能力。</td> </tr> <tr> <td>Cloudflare：邊緣系統由 C/NGINX 模組逐步改寫 Rust</td> <td>語言/安全性</td> <td>記憶體安全與可維護性需求提升，在高效能路徑引入 Rust 降低記憶體錯誤風險。</td> </tr> <tr> <td>Slack：關鍵服務從單體拓撲遷移到 Cell-based 架構</td> <td>架構/隔離策略</td> <td>以降低爆炸半徑與提高冗餘為目標，將重大故障影響限制在局部 cell。</td> </tr> <tr> <td>Uber：大規模微服務治理轉向 Domain-oriented 邊界重整</td> <td>架構/組織對齊</td> <td>服務數量擴張後依賴複雜度暴增，需要把技術邊界與業務邊界對齊以降低協作與故障傳染成本。</td> </tr> <tr> <td>Meta：MySQL 大規模場景導入 MyRocks</td> <td>儲存引擎/成本優化</td> <td>寫入放大與儲存成本壓力上升，透過新儲存引擎換取空間效率與寫入效能。</td> </tr> </tbody> </table> <h2 id="案例分組判讀">案例分組判讀</h2> <h3 id="語言與型別系統轉換">語言與型別系統轉換</h3> <p>語言轉換常見於「延遲抖動不可接受」或「重構風險不可接受」兩類壓力。前者多是 runtime/記憶體模型問題，後者多是大型程式碼庫可維護性問題。</p> <ul> <li>代表案例：Slack PHP -&gt; Hack、Discord Go -&gt; Rust、Dropbox Python 2 -&gt; Python 3、Cloudflare C/NGINX -&gt; Rust</li> <li>主要動機：降低 tail latency、提升記憶體安全、對抗 runtime EOL、引入更強型別訊號</li> </ul> <h3 id="資料層與儲存架構轉換">資料層與儲存架構轉換</h3> <p>資料層轉換通常源自單體資料庫在容量、隔離與可恢復性上出現結構性瓶頸，追新技術本身很少是真正驅動力。</p> <ul> <li>代表案例：GitLab Main/CI split、Notion Postgres sharding、Shopify Vitess、Meta MyRocks</li> <li>主要動機：解耦不同負載、降低熱點、取得水平擴充、降低儲存成本</li> </ul> <h3 id="平台與部署工具轉換">平台與部署工具轉換</h3> <p>平台轉換通常發生在部署頻率提升後，原本的人工作業或弱自動化無法承擔發布風險。</p> <ul> <li>代表案例：Figma 遷移 Kubernetes、Dropbox RPC 標準化到 gRPC</li> <li>主要動機：統一部署控制面、縮短發布/回滾時間、提升跨語言協作效率</li> </ul> <h3 id="架構邊界重整">架構邊界重整</h3> <p>架構重整通常是「故障會跨邊界放大」或「團隊邊界與系統邊界失配」時的修正動作。</p> <ul> <li>代表案例：Slack cellular architecture、Uber domain-oriented microservice governance</li> <li>主要動機：縮小 blast radius、讓服務責任與組織責任對齊、降低跨團隊耦合</li> </ul> <h2 id="三倍擴充案例池42">三倍擴充案例池（42）</h2> <p>這份案例池的核心責任是提供「可直接回寫實作」的案例母體，而不是只做公司清單。下面分成兩層：外部官方遷移案例（偏選型與轉換動機）與站內已整理案例（偏實作、驗證、事故教訓）。</p> <h3 id="a-外部官方遷移案例20">A. 外部官方遷移案例（20）</h3> <table> <thead> <tr> <th>案例</th> <th>轉換主題</th> <th>實作討論入口</th> </tr> </thead> <tbody> <tr> <td>Slack PHP -&gt; Hack</td> <td>漸進型別化與大型重構安全</td> <td><a href="https://tarrragon.github.io/blog/backend/01-database/database-migration-playbook/" data-link-title="1.6 資料庫轉換實作：雙寫、回填、切流與回滾" data-link-desc="同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工">1.6</a></td> </tr> <tr> <td>Discord Go -&gt; Rust</td> <td>延遲長尾與 GC 抖動治理</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/migration-safety/" data-link-title="6.11 Migration Safety 與 DB Rollout" data-link-desc="把 schema migration 從一次性事件變成可逆、可漸進的 rollout 流程">6.11</a></td> </tr> <tr> <td>Dropbox Python 2 -&gt; 3</td> <td>runtime EOL 與生態升級</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/release-gate/" data-link-title="6.8 Release Gate 與變更節奏" data-link-desc="把驗證、migration、相容性納入放行判準">6.8</a></td> </tr> <tr> <td>Dropbox RPC -&gt; gRPC</td> <td>協定標準化與跨語言維運</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/operations-platform-selection/" data-link-title="0.4 操作平台選型" data-link-desc="區分 log、metric、trace、dashboard、alert、deployment 與 reliability 的選型邊界">0.4</a></td> </tr> <tr> <td>GitLab Main/CI DB split</td> <td>單庫拆分與負載隔離</td> <td><a href="https://tarrragon.github.io/blog/backend/01-database/database-migration-playbook/" data-link-title="1.6 資料庫轉換實作：雙寫、回填、切流與回滾" data-link-desc="同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工">1.6</a></td> </tr> <tr> <td>Notion Postgres sharding</td> <td>熱點與容量壓力分片</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/traffic-data-scale/" data-link-title="0.5 流量與資料量評估" data-link-desc="用流量形狀、資料成長、hot key、保留期限與尖峰模式評估後端需求規模">0.5</a></td> </tr> <tr> <td>Shopify MySQL -&gt; Vitess</td> <td>水平擴充與線上遷移</td> <td><a href="https://tarrragon.github.io/blog/backend/01-database/database-migration-playbook/" data-link-title="1.6 資料庫轉換實作：雙寫、回填、切流與回滾" data-link-desc="同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工">1.6</a></td> </tr> <tr> <td>Shopify Ruby + Sorbet</td> <td>動態語言型別治理</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/contract-testing/" data-link-title="6.10 Contract Testing 與 Schema 演進" data-link-desc="把跨服務 / API / event schema 的隱性期待變成可驗證契約，控制演進相容性">6.10</a></td> </tr> <tr> <td>Figma -&gt; Kubernetes</td> <td>部署控制面平台化</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/operations-platform-selection/" data-link-title="0.4 操作平台選型" data-link-desc="區分 log、metric、trace、dashboard、alert、deployment 與 reliability 的選型邊界">0.4</a></td> </tr> <tr> <td>Cloudflare C/NGINX -&gt; Rust</td> <td>記憶體安全與效能路徑重寫</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/cost-risk-tradeoffs/" data-link-title="0.6 成本、風險與選型取捨" data-link-desc="用人力成本、雲端成本、操作成本與失敗代價判斷後端能力投入順序">0.6</a></td> </tr> <tr> <td>Slack monolith topology -&gt; cellular</td> <td>blast radius 局部化</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/failure-observability-design/" data-link-title="0.7 錯誤定位、觀測訊號與備援切換設計" data-link-desc="從錯誤分類、定位線索、降級策略與 failover 設計服務可維護性">0.7</a></td> </tr> <tr> <td>Uber domain-oriented microservices</td> <td>服務邊界與組織對齊</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/service-capability-map/" data-link-title="0.1 後端服務能力地圖" data-link-desc="用需求類型判斷應先評估資料庫、快取、訊息佇列、觀測平台或部署平台">0.1</a></td> </tr> <tr> <td>Meta MySQL -&gt; MyRocks</td> <td>儲存成本與寫入效率</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/state-storage-selection/" data-link-title="0.2 狀態與資料儲存選型" data-link-desc="區分 source of truth、快取、搜尋索引、event log 與 object storage 的選型邊界">0.2</a></td> </tr> <tr> <td>Pinterest HBase -&gt; TiDB</td> <td>零停機儲存遷移</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/migration-safety/" data-link-title="6.11 Migration Safety 與 DB Rollout" data-link-desc="把 schema migration 從一次性事件變成可逆、可漸進的 rollout 流程">6.11</a></td> </tr> <tr> <td>Pinterest 新 wide-column DB（RocksDB）</td> <td>資料層能力換血</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/state-storage-selection/" data-link-title="0.2 狀態與資料儲存選型" data-link-desc="區分 source of truth、快取、搜尋索引、event log 與 object storage 的選型邊界">0.2</a></td> </tr> <tr> <td>Meta MySQL Raft deploy</td> <td>failover 工具化</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/dr-rollback-rehearsal/" data-link-title="6.7 DR 演練與 Rollback Rehearsal" data-link-desc="把回復路徑從紙面計畫變成定期可重播、可量測的驗證流程">6.7</a></td> </tr> <tr> <td>Shopify MySQL upgrade program</td> <td>大規模升級治理</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/release-gate/" data-link-title="6.8 Release Gate 與變更節奏" data-link-desc="把驗證、migration、相容性納入放行判準">6.8</a></td> </tr> <tr> <td>GitLab major PostgreSQL upgrade</td> <td>主版本升級與回退窗</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/migration-safety/" data-link-title="6.11 Migration Safety 與 DB Rollout" data-link-desc="把 schema migration 從一次性事件變成可逆、可漸進的 rollout 流程">6.11</a></td> </tr> <tr> <td>AWS shuffle sharding adoption</td> <td>多租戶隔離重整</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/dependency-reliability-budget/" data-link-title="6.14 Dependency Reliability Budget" data-link-desc="把內外依賴的可靠性納入 SLO 計算與設計約束">6.14</a></td> </tr> <tr> <td>Cloudflare observability stack內建化</td> <td>觀測平台內生化</td> <td><a href="https://tarrragon.github.io/blog/backend/04-observability/observability-operating-model/" data-link-title="4.18 Observability Operating Model" data-link-desc="定義 platform / service team / on-call 對訊號、dashboard、alert 與成本的 ownership">4.18</a></td> </tr> </tbody> </table> <h3 id="b-站內可回寫實作案例池22">B. 站內可回寫實作案例池（22）</h3> <table> <thead> <tr> <th>案例</th> <th>轉換主題</th> <th>實作討論入口</th> </tr> </thead> <tbody> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/stripe/idempotency-and-zero-downtime-migration/" data-link-title="Stripe：Idempotency 與零停機遷移的交易安全設計" data-link-desc="把 API 重試與資料遷移放在同一套安全模型，維持支付交易的一致結果。">Stripe：Idempotency 與零停機遷移</a></td> <td>交易安全 + migration 並行</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/migration-safety/" data-link-title="6.11 Migration Safety 與 DB Rollout" data-link-desc="把 schema migration 從一次性事件變成可逆、可漸進的 rollout 流程">6.11</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/pinterest/cache-reliability-and-capacity-surprises/" data-link-title="Pinterest：快取可靠性與容量驚奇治理" data-link-desc="針對快取層失效與流量突增，建立容量緩衝、退化路徑與重建節奏。">Pinterest：快取可靠性與容量驚奇治理</a></td> <td>快取策略與容量重整</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/capacity-cost/" data-link-title="6.9 容量與成本邊界" data-link-desc="把容量規劃跟成本約束變成驗證輸入">6.9</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/amazon/shuffle-sharding-and-cell-boundary/" data-link-title="Amazon：Shuffle Sharding 與 Cell 邊界的失效局部化" data-link-desc="用 cell 與 shuffle sharding 將多租戶故障限制在局部，讓恢復策略可分批執行。">Amazon：Shuffle Sharding 與 Cell 邊界</a></td> <td>cell/shard 重整</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/failure-observability-design/" data-link-title="0.7 錯誤定位、觀測訊號與備援切換設計" data-link-desc="從錯誤分類、定位線索、降級策略與 failover 設計服務可維護性">0.7</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/meta/region-failover-and-reliability-boundaries/" data-link-title="Meta：Region Failover 與可靠性邊界" data-link-desc="把跨區故障視為邊界治理問題，透過分區隔離與回復順序控制失效擴散。">Meta：Region Failover 與可靠性邊界</a></td> <td>區域切換能力演進</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/dr-rollback-rehearsal/" data-link-title="6.7 DR 演練與 Rollback Rehearsal" data-link-desc="把回復路徑從紙面計畫變成定期可重播、可量測的驗證流程">6.7</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/shopify/bfcm-capacity-and-game-day/" data-link-title="Shopify：BFCM 容量治理與 Game Day 驗證節奏" data-link-desc="把季節性流量峰值轉成年度可靠性流程，透過容量模型、演練與隔離策略提前吸收風險。">Shopify：BFCM 容量治理與 Game Day</a></td> <td>高峰前治理轉換</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/load-testing/" data-link-title="6.2 load test" data-link-desc="把 production 流量結構轉成可重播壓力情境，定位 saturation 轉折與容量邊界">6.6</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/google/error-budget-policy-and-release-gating/" data-link-title="Google：Error Budget 政策如何決定發布節奏" data-link-desc="把 SLO 消耗量轉成 release gate，讓可靠性與交付速度共用同一套決策語言。">Google：Error Budget 發布門檻</a></td> <td>從速度導向轉為預算導向</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/slo-error-budget/" data-link-title="6.6 SLO 與 Error Budget 政策" data-link-desc="把可靠性目標轉成可驗證量測與凍結條件">6.2</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/microsoft/change-management-and-reliability-governance/" data-link-title="Microsoft：變更治理與可靠性門檻" data-link-desc="透過分層變更管理與發布閘門，降低大型 SaaS 平台的系統性回歸風險。">Microsoft：變更治理與可靠性門檻</a></td> <td>變更流程平台化</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/release-gate/" data-link-title="6.8 Release Gate 與變更節奏" data-link-desc="把驗證、migration、相容性納入放行判準">6.8</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/spotify/platform-engineering-and-reliability-contracts/" data-link-title="Spotify：平台工程與可靠性契約" data-link-desc="用平台契約統一服務團隊的可靠性最低標準，降低跨團隊變更造成的隱性風險。">Spotify：平台工程與可靠性契約</a></td> <td>團隊自助平台化</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/operations-platform-selection/" data-link-title="0.4 操作平台選型" data-link-desc="區分 log、metric、trace、dashboard、alert、deployment 與 reliability 的選型邊界">0.4</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/linkedin/capacity-headroom-and-oncall-tiering/" data-link-title="LinkedIn：Capacity Headroom 與 On-call 分層" data-link-desc="把容量預測與值班分層綁在一起，降低高峰時段的升級混亂與恢復延遲。">LinkedIn：Capacity Headroom 與 On-call 分層</a></td> <td>容量與值班模型重整</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/capacity-cost/" data-link-title="6.9 容量與成本邊界" data-link-desc="把容量規劃跟成本約束變成驗證輸入">6.9</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/netflix/steady-state-chaos-and-fit/" data-link-title="Netflix：Steady State、Chaos 與 FIT 的驗證路徑" data-link-desc="把故障注入從工具操作升級成可驗證流程：先定義穩態，再設計注入與回復條件。">Netflix：Steady State、Chaos 與 FIT</a></td> <td>驗證方法轉換</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/chaos-testing/" data-link-title="6.4 chaos testing" data-link-desc="把故障注入從工具操作升級成可驗證流程：先定義穩態，再按依賴類型設計注入、控制 blast radius 與收集證據">6.5</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/cases/honeycomb/burn-rate-driven-reliability-operations/" data-link-title="Honeycomb：以 Burn Rate 驅動的可靠性操作" data-link-desc="把 SLO burn rate 直接連到值班決策與改善優先序，降低高噪音告警造成的判讀失真。">Honeycomb：Burn Rate 驅動操作</a></td> <td>告警治理轉換</td> <td><a href="https://tarrragon.github.io/blog/backend/04-observability/sli-slo-signal/" data-link-title="4.6 SLI 量測與 SLO 訊號設計" data-link-desc="把可靠性目標的訊號從 metric 端設計好、餵給 6.6 SLO 政策">4.13</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/github/2018-oct21-mysql-topology-incident/" data-link-title="GitHub 2018 Oct21 MySQL Topology Incident" data-link-desc="2018-10-21 GitHub 因 network partition 觸發跨區資料庫拓撲異常的事故解析：資料一致性優先、fail-forward 決策與長時間恢復。">GitHub 2018 MySQL Topology Incident</a></td> <td>跨區 DB 拓撲決策轉換</td> <td><a href="https://tarrragon.github.io/blog/backend/01-database/database-migration-playbook/" data-link-title="1.6 資料庫轉換實作：雙寫、回填、切流與回滾" data-link-desc="同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工">1.6</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/reddit/2023-kubernetes-upgrade-incident/" data-link-title="Reddit：2023 Kubernetes 升級事故" data-link-desc="平台升級變更如何觸發服務退化，以及如何設計可回退的升級策略。">Reddit 2023 Kubernetes 升級事故</a></td> <td>平台升級失敗模式</td> <td><a href="https://tarrragon.github.io/blog/backend/05-deployment-platform/kubernetes-deployment/" data-link-title="5.2 Kubernetes 部署策略" data-link-desc="整理 deployment、probe 與 rolling update">5.2</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/discord/2022-gateway-capacity-event/" data-link-title="Discord：Gateway 容量事件與恢復節奏" data-link-desc="長連線平台在容量邊界被擊穿時，如何控制擴散並分批恢復。">Discord 2022 Gateway 容量事件</a></td> <td>容量與連線模型調整</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/traffic-data-scale/" data-link-title="0.5 流量與資料量評估" data-link-desc="用流量形狀、資料成長、hot key、保留期限與尖峰模式評估後端需求規模">0.5</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2019-regex-cpu-outage/" data-link-title="Cloudflare 2019 Regex CPU Outage" data-link-desc="2019-07-02 Cloudflare WAF 規則更新導致全球 CPU 飆升的事故解析：觸發條件、擴散機制、止血決策與可回寫控制面。">Cloudflare 2019 Regex CPU Outage</a></td> <td>規則系統推送模型調整</td> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/incident-workflow-automation-boundary/" data-link-title="8.21 Incident Workflow Automation Boundary" data-link-desc="定義哪些事故流程適合自動化，哪些決策需要保留人工確認">8.13</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/cloudflare/2023-control-plane-token-incident/" data-link-title="Cloudflare 2023 Control Plane Token Incident" data-link-desc="2023-01-24 Cloudflare service token 錯誤變更導致多產品連鎖影響的事故解析：信任邊界、擴散機制、止血策略與流程回寫。">Cloudflare 2023 Control Plane Token Incident</a></td> <td>控制面信任邊界重整</td> <td><a href="https://tarrragon.github.io/blog/backend/07-security-data-protection/security-control-handoff-to-delivery-and-incident/" data-link-title="7.18 資安控制面如何交接到部署與事故流程" data-link-desc="建立資安控制面交接到部署、可靠性與事故流程的大綱">7.12</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/fastly/2021-june-global-edge-config-triggered-outage/" data-link-title="Fastly 2021 June Global Edge Config-triggered Outage" data-link-desc="2021-06-08 Fastly 全球 edge 事故解析：有效客戶配置觸發潛藏 bug、分鐘級擴散與快速隔離恢復。">Fastly 2021 全域 Edge 配置事故</a></td> <td>配置發布流程轉換</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/release-gate/" data-link-title="6.8 Release Gate 與變更節奏" data-link-desc="把驗證、migration、相容性納入放行判準">6.8</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/aws-s3/2017-us-east-1-service-disruption/" data-link-title="AWS S3 2017 US-EAST-1 Service Disruption" data-link-desc="2017-02-28 AWS S3 us-east-1 事故解析：內部操作命令、index / placement 子系統重啟、區域依賴擴散與狀態頁依賴回寫。">AWS S3 2017 US-EAST-1 事件</a></td> <td>控制面操作模型重整</td> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/containment-recovery-strategy/" data-link-title="8.3 止血、降級與回復策略" data-link-desc="把短期止血與正式回復拆成可執行步驟">8.3</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/atlassian/2022-april-multi-tenant-deletion-outage/" data-link-title="Atlassian 2022 April Multi-tenant Deletion Outage" data-link-desc="2022-04 Atlassian 因維運腳本誤刪多租戶站點造成長時間事故的解析：恢復分批、跨團隊指揮與對外通訊節奏。">Atlassian 2022 多租戶刪除事故</a></td> <td>tenant 安全邊界重整</td> <td><a href="https://tarrragon.github.io/blog/backend/00-service-selection/cost-risk-tradeoffs/" data-link-title="0.6 成本、風險與選型取捨" data-link-desc="用人力成本、雲端成本、操作成本與失敗代價判斷後端能力投入順序">0.6</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/azure-ad/2021-identity-control-plane-disruption/" data-link-title="Azure AD：2021 身分控制面中斷事件" data-link-desc="身分服務失效時，如何評估跨產品影響與收斂優先序。">Azure AD 2021 身分控制面事件</a></td> <td>身分服務依賴治理</td> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/customer-impact-assessment/" data-link-title="8.20 Customer Impact Assessment" data-link-desc="把受影響用戶、功能、區域、金額、SLO 與補償判斷串成影響評估模型">8.20</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/gcp/2019-us-network-congestion-multi-service-incident/" data-link-title="GCP 2019 US Network Congestion Multi-service Incident" data-link-desc="2019-06-02 Google Cloud 因美國區域網路壅塞造成多服務退化的事故解析：跨產品依賴、流量控制與區域隔離判讀。">GCP 2019 多服務網路擁塞事件</a></td> <td>區域網路依賴重整</td> <td><a href="https://tarrragon.github.io/blog/backend/06-reliability/dependency-reliability-budget/" data-link-title="6.14 Dependency Reliability Budget" data-link-desc="把內外依賴的可靠性納入 SLO 計算與設計約束">6.14</a></td> </tr> <tr> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/cases/heroku/2021-routing-control-event/" data-link-title="Heroku：Routing 控制事件與多租戶影響" data-link-desc="PaaS 路由層異常時，如何限制租戶擴散並維持可用通訊。">Heroku 2021 Routing 控制事件</a></td> <td>路由控制面恢復策略</td> <td><a href="https://tarrragon.github.io/blog/backend/08-incident-response/containment-recovery-strategy/" data-link-title="8.3 止血、降級與回復策略" data-link-desc="把短期止血與正式回復拆成可執行步驟">8.3</a></td> </tr> </tbody> </table> <p>這兩層合計 42 個案例。使用方式是先在 A 層找轉換動機，再到 B 層找可操作證據與失敗模式，最後回寫到 <code>01/04/06/08</code> 的正文。</p>這個案例的核心責任是把「營運後轉換」變成可判讀決策，而不是技術潮流追逐。服務在成長期常會遇到早期選型與現況負載不再匹配，此時轉換的重點是風險收斂與效率改善，而不是語言偏好。

大量真實案例與轉換原因

案例 轉換類型 為什麼轉換
Slack：PHP 逐步遷移到 Hack 語言/型別系統 以漸進式靜態型別提升重構安全與開發效率，降低 runtime 才暴露型別錯誤的成本。
Discord：Read States 服務 Go 重寫為 Rust 語言/執行模型 Go 服務在特定負載下出現 GC 造成的週期性延遲尖峰，Rust 以無 GC 記憶體模型降低延遲抖動。
Dropbox：Python 2 轉 Python 3 語言/runtime 生命週期 Python 2 EOL 與型別工具鏈演進壓力，驅動全面升級並降低長期維護風險。
Dropbox：內部 RPC 轉向 gRPC（Courier） 工具/協定標準化 多語言服務擴張後，需要統一傳輸契約、提高跨團隊可維護性與可觀測性。
GitLab：單一資料庫拆成 Main/CI 資料庫 資料層架構 單庫承載產品與 CI 工作負載，容量與干擾風險上升，需以職責拆分換取穩定性。
Notion：Postgres 單庫轉分片 資料層架構 寫入與資料量成長造成熱點與容量壓力，以分片提升可擴展性與故障隔離。
Shopify：Rails 後端引入 Vitess 水平擴充 資料層工具 MySQL 垂直擴充成本上升，需在不中斷服務前提下取得分片與路由能力。
Shopify：Ruby 導入 Sorbet 靜態型別 工具/語言治理 大型程式碼庫重構與跨團隊協作風險高，需要型別訊號降低變更不確定性。
Figma：服務遷移至 Kubernetes 平台/部署工具 手工或半自動部署流程難以支撐規模成長，需要統一調度、回滾與資源治理能力。
Cloudflare：邊緣系統由 C/NGINX 模組逐步改寫 Rust 語言/安全性 記憶體安全與可維護性需求提升，在高效能路徑引入 Rust 降低記憶體錯誤風險。
Slack：關鍵服務從單體拓撲遷移到 Cell-based 架構 架構/隔離策略 以降低爆炸半徑與提高冗餘為目標，將重大故障影響限制在局部 cell。
Uber：大規模微服務治理轉向 Domain-oriented 邊界重整 架構/組織對齊 服務數量擴張後依賴複雜度暴增，需要把技術邊界與業務邊界對齊以降低協作與故障傳染成本。
Meta：MySQL 大規模場景導入 MyRocks 儲存引擎/成本優化 寫入放大與儲存成本壓力上升，透過新儲存引擎換取空間效率與寫入效能。

案例分組判讀

語言與型別系統轉換

語言轉換常見於「延遲抖動不可接受」或「重構風險不可接受」兩類壓力。前者多是 runtime/記憶體模型問題，後者多是大型程式碼庫可維護性問題。

  • 代表案例：Slack PHP -> Hack、Discord Go -> Rust、Dropbox Python 2 -> Python 3、Cloudflare C/NGINX -> Rust
  • 主要動機：降低 tail latency、提升記憶體安全、對抗 runtime EOL、引入更強型別訊號

資料層與儲存架構轉換

資料層轉換通常源自單體資料庫在容量、隔離與可恢復性上出現結構性瓶頸，追新技術本身很少是真正驅動力。

  • 代表案例：GitLab Main/CI split、Notion Postgres sharding、Shopify Vitess、Meta MyRocks
  • 主要動機：解耦不同負載、降低熱點、取得水平擴充、降低儲存成本

平台與部署工具轉換

平台轉換通常發生在部署頻率提升後，原本的人工作業或弱自動化無法承擔發布風險。

  • 代表案例：Figma 遷移 Kubernetes、Dropbox RPC 標準化到 gRPC
  • 主要動機：統一部署控制面、縮短發布/回滾時間、提升跨語言協作效率

架構邊界重整

架構重整通常是「故障會跨邊界放大」或「團隊邊界與系統邊界失配」時的修正動作。

  • 代表案例：Slack cellular architecture、Uber domain-oriented microservice governance
  • 主要動機：縮小 blast radius、讓服務責任與組織責任對齊、降低跨團隊耦合

三倍擴充案例池（42）

這份案例池的核心責任是提供「可直接回寫實作」的案例母體，而不是只做公司清單。下面分成兩層：外部官方遷移案例（偏選型與轉換動機）與站內已整理案例（偏實作、驗證、事故教訓）。

A. 外部官方遷移案例（20）

案例 轉換主題 實作討論入口
Slack PHP -> Hack 漸進型別化與大型重構安全 1.6
Discord Go -> Rust 延遲長尾與 GC 抖動治理 6.11
Dropbox Python 2 -> 3 runtime EOL 與生態升級 6.8
Dropbox RPC -> gRPC 協定標準化與跨語言維運 0.4
GitLab Main/CI DB split 單庫拆分與負載隔離 1.6
Notion Postgres sharding 熱點與容量壓力分片 0.5
Shopify MySQL -> Vitess 水平擴充與線上遷移 1.6
Shopify Ruby + Sorbet 動態語言型別治理 6.10
Figma -> Kubernetes 部署控制面平台化 0.4
Cloudflare C/NGINX -> Rust 記憶體安全與效能路徑重寫 0.6
Slack monolith topology -> cellular blast radius 局部化 0.7
Uber domain-oriented microservices 服務邊界與組織對齊 0.1
Meta MySQL -> MyRocks 儲存成本與寫入效率 0.2
Pinterest HBase -> TiDB 零停機儲存遷移 6.11
Pinterest 新 wide-column DB（RocksDB） 資料層能力換血 0.2
Meta MySQL Raft deploy failover 工具化 6.7
Shopify MySQL upgrade program 大規模升級治理 6.8
GitLab major PostgreSQL upgrade 主版本升級與回退窗 6.11
AWS shuffle sharding adoption 多租戶隔離重整 6.14
Cloudflare observability stack內建化 觀測平台內生化 4.18

B. 站內可回寫實作案例池（22）

案例 轉換主題 實作討論入口
Stripe：Idempotency 與零停機遷移 交易安全 + migration 並行 6.11
Pinterest：快取可靠性與容量驚奇治理 快取策略與容量重整 6.9
Amazon：Shuffle Sharding 與 Cell 邊界 cell/shard 重整 0.7
Meta：Region Failover 與可靠性邊界 區域切換能力演進 6.7
Shopify：BFCM 容量治理與 Game Day 高峰前治理轉換 6.6
Google：Error Budget 發布門檻 從速度導向轉為預算導向 6.2
Microsoft：變更治理與可靠性門檻 變更流程平台化 6.8
Spotify：平台工程與可靠性契約 團隊自助平台化 0.4
LinkedIn：Capacity Headroom 與 On-call 分層 容量與值班模型重整 6.9
Netflix：Steady State、Chaos 與 FIT 驗證方法轉換 6.5
Honeycomb：Burn Rate 驅動操作 告警治理轉換 4.13
GitHub 2018 MySQL Topology Incident 跨區 DB 拓撲決策轉換 1.6
Reddit 2023 Kubernetes 升級事故 平台升級失敗模式 5.2
Discord 2022 Gateway 容量事件 容量與連線模型調整 0.5
Cloudflare 2019 Regex CPU Outage 規則系統推送模型調整 8.13
Cloudflare 2023 Control Plane Token Incident 控制面信任邊界重整 7.12
Fastly 2021 全域 Edge 配置事故 配置發布流程轉換 6.8
AWS S3 2017 US-EAST-1 事件 控制面操作模型重整 8.3
Atlassian 2022 多租戶刪除事故 tenant 安全邊界重整 0.6
Azure AD 2021 身分控制面事件 身分服務依賴治理 8.20
GCP 2019 多服務網路擁塞事件 區域網路依賴重整 6.14
Heroku 2021 Routing 控制事件 路由控制面恢復策略 8.3

這兩層合計 42 個案例。使用方式是先在 A 層找轉換動機，再到 B 層找可操作證據與失敗模式，最後回寫到 01/04/06/08 的正文。

跨分類覆蓋與缺口

這一段的核心責任是避免案例池被資料庫議題主導。選型與轉換在實務上會同時涉及快取、訊息傳遞、觀測、部署、安全與事故治理，因此案例覆蓋要跨分類配置。

分類 目前案例密度 代表案例入口 目前缺口與補查方向
01 Database / Storage 高 1.7 Schema Migration Rollout 證據 已有遷移流程與 rollout evidence；下一步補更多 vendor 轉換對照
02 Cache / Redis 中低 Pinterest：快取可靠性與容量驚奇治理 補「快取策略轉換」案例（cache-aside -> write-through、multi-layer cache）
03 Message Queue 中低 Amazon：Shuffle Sharding 與 Cell 邊界 補「自管 broker -> managed queue」與「語義轉換（at-least-once / exactly-once）」
04 Observability 中 Honeycomb：Burn Rate 驅動操作 補「監控平台遷移」與「OpenTelemetry 導入遷移」案例
05 Deployment Platform 中 Reddit：2023 Kubernetes 升級事故 補「自建部署 -> Kubernetes/GitOps」轉換案例
06 Reliability 高 Stripe：Idempotency 與零停機遷移 持續補不同產業的 rollout/rollback 對照
07 Security / Data Protection 中低 Cloudflare 2023 Control Plane Token Incident 補「憑證、金鑰、身分邊界治理轉換」案例
08 Incident Response 高 GitHub 2018 MySQL Topology Incident 補「轉換期間事故」專題，建立遷移失敗模式索引

覆蓋門檻與缺口追蹤

這份追蹤表的核心責任是把「案例夠不夠」變成可量化判斷，而不是主觀感覺。

分類 最低門檻（篇） 目前已收錄（篇） 缺口（篇） 狀態 下一步
01 Database / Storage 12 12 0 達標 補 vendor 轉換對照深度
02 Cache / Redis 10 10 0 達標 進入案例深度擴寫與反例補充
03 Message Queue 10 10 0 達標 進入案例深度擴寫與反例補充
04 Observability 10 10 0 達標 進入案例深度擴寫與反例補充
05 Deployment Platform 10 10 0 達標 進入案例深度擴寫與反例補充
06 Reliability 10 12 0 達標 補產業多樣性與 rollback 成本對照
07 Security / Data Protection 10 10 0 達標 進入案例深度擴寫與反例補充
08 Incident Response 10 12 0 達標 補「轉換期間事故」專題索引

下一輪優先順序

門檻已達標，下一輪優先順序改為：

  1. 每分類補「失敗反例」與「轉換失敗回退案例」
  2. 每分類補「同議題不同規模企業」對照
  3. 把案例回寫到章節正文中的判讀訊號與 tripwire 欄位

回退失敗專題索引

這個索引的核心責任是讓讀者在「已經出錯」時，能快速找到對應回退失敗模式，而不是從頭重讀選型章節。

分類 回退失敗專題
02 Cache / Redis 2.C9 反例：快取切換失敗
03 Message Queue 3.C9 反例：語義切換失敗
04 Observability 4.C9 反例：OTel 訊號漂移
05 Deployment Platform 5.C9 反例：切流未先 drain
07 Security / Data Protection 7.C9 反例：憑證輪替失敗

回退判讀寫法

回退判讀的核心責任是把失敗條件寫回該分類自己的業務語境。快取看的是回源壓力與資料新鮮度；queue 看的是語義、lag 與重播；observability 看的是訊號語意漂移；deployment 看的是切流、draining 與連線生命週期；security 看的是身份、憑證作用域與控制面擴散。

這些判讀不能抽成同一份模板。每次寫案例時，先回答該分類自己的問題：哪個業務路徑受影響、哪個訊號最早失真、哪個回退動作會降低傷害、哪份證據能證明回退有效。

下一輪補查清單（非 DB 優先）

下一輪補查會優先補目前中低密度分類，目標是讓每一類至少有 8 到 12 個可回寫案例。

  1. Cache：快取策略遷移與失效治理（multi-layer、eviction、warmup）
  2. Queue：broker/語義轉換與 replay 風險控制
  3. Observability：監控平台遷移與資料品質治理
  4. Deployment：部署平台轉換與灰度/回滾策略
  5. Security：控制面信任邊界與憑證機制轉換

第二批外部案例補充（非 DB 類）

這一批的核心責任是把中低密度分類補到可用水位，讓 02/03/04/05/07 都有可引用的真實轉換案例，而不是只有資料庫案例可用。

分類 案例 轉換焦點 回寫入口
Cache Meta：Cache made consistent cache invalidation 一致性治理升級 2.1
Cache Meta：mcrouter at scale 單機快取轉成跨區路由層 2.4
Cache Meta：CacheLib + Kangaroo DRAM-only 快取轉向 flash-friendly 架構 2.5
Cache Shopify：Marshal -> MessagePack cache migration 快取序列化格式遷移與雙軌相容 2.1
Cache Shopify：Shop App write-through cache read-heavy 路徑轉 write-through 2.1
Queue Meta：FOQS disaster-ready migration 區域佇列轉全域架構且零停機 3.3
Queue LinkedIn：Running Kafka at Scale 單叢集使用模式轉 tiered cluster 3.1
Queue LinkedIn：TopicGC Kafka topic 治理從手動轉自動回收 3.2
Queue VMware Tanzu CloudHealth：Kafka -> Amazon MSK 自管 broker 轉 managed streaming 3.1
Queue Slack：Scaling job queue 背景工作通道轉 Kafka + Redis 組合 3.4
Observability AWS：X-Ray SDK/Daemon -> OpenTelemetry migration vendor SDK 轉 OTel 標準化 4.21
Observability Google Cloud：OTLP support in Cloud Trace (2025) 專有 ingest 轉 OTLP 標準入口 4.21
Observability AWS：ADOT 建立集中觀測平台 多代理轉單一 OTel pipeline 4.18
Observability AWS：EKS + ADOT + X-Ray/CloudWatch 既有監控拆散轉標準化管線 4.7
Observability Honeycomb：Burn rate operations 告警規則轉 error budget 驅動治理 4.13
Deployment Tradeshift：self-hosted K8s -> EKS (zero downtime) 自管控制面轉 managed control plane 5.2
Deployment Condé Nast：K8s platform modernization on EKS 多團隊異質集群轉統一平台 5.2
Deployment Orbitera：AWS -> GKE migration 基礎平台重置與容器編排轉換 5.2
Deployment Mobileye：workloads -> EKS 資源調度模式轉 managed K8s 5.2
Deployment Miro：microservices/K8s -> EKS managed 自維運平台轉 managed service 組合 5.2
Security/Control Plane Cloudflare：2026 route leak incident 路由政策自動化治理重整 7.16
Security/Control Plane Cloudflare：2026 BYOIP BGP withdrawal 控制面變更保護與回退策略 8.3
Security/Control Plane Cloudflare：2023 control-plane token incident token 管理邊界與供應鏈信任調整 7.11
Security/Control Plane Azure AD：2021 identity control-plane disruption 身分控制面故障隔離與恢復路由 8.8
Security/Control Plane Microsoft 365：2023 suite-wide authentication incident 身分服務相依邊界重整 8.20

第二批補查來源

  • Meta：Cache consistency / mcrouter / CacheLib / Kangaroo / FOQS / MyRocks migration
  • LinkedIn Engineering：Kafka at scale / TopicGC
  • AWS：CloudHealth Kafka -> MSK、X-Ray -> OTel migration、ADOT/EKS 實務、EKS 遷移案例
  • Google Cloud：OTLP in Cloud Trace、Orbitera -> GKE
  • Shopify Engineering：cache serialization migration、write-through cache
  • Cloudflare Post-mortem：2023/2026 control-plane 與路由事件

判讀訊號

訊號 判讀重點 對應章節
延遲分布長尾惡化 是平均值問題還是尖峰問題 0.5
重構風險持續升高 型別/契約是否不足以支撐變更 0.6
故障常跨服務放大 架構邊界是否缺乏隔離能力 0.7
發布節奏被品質問題拖慢 問題在語言、工具鏈或架構層 0.4

轉換決策資料要求

資料面向 最低需要的證據 若缺失會發生什麼事
成本面 現況維運成本與轉換成本（人力、基礎設施、機會成本） 轉換中途停擺或 ROI 判斷失真
風險面 故障型態、爆炸半徑、回退時間 上線後故障放大但無法快速止血
性能面 P50/P95/P99、吞吐、尖峰流量下的行為 只優化平均值，長尾問題仍存在
組織面 團隊技能分布、訓練成本、維運責任邊界 工具換了但組織無法承接
生命週期面 依賴版本 EOL、供應商策略、平台相容性 被動升級，且在最差時機被迫遷移
遷移可行性面 雙寫/雙跑策略、灰度範圍、指標切換門檻、回滾條件 遷移無法分段驗證，風險一次性爆發

轉換前要先回答的三個問題

  1. 現有問題是「局部優化可解」還是「結構性不匹配」？
  2. 轉換後的收益是性能、可靠性、開發效率哪一項，如何量化？
  3. 遷移期間如何維持雙軌可運行與回退能力？

如果三個問題答不清楚，通常代表先做局部治理比全面轉換更穩定。

常見誤區

把「技術新舊」當成轉換理由，容易忽略遷移期成本。可靠做法是先界定症狀與邊界，再決定要換語言、換工具，或只換架構切分方式。

下一步路由

若問題在執行時特性（延遲抖動、記憶體模型），先回 0.2 與 0.5。若是資料庫轉換已進入執行階段，直接進 1.6 資料庫轉換實作；需要把 production migration 寫成 evidence、gate 與 decision log，接 1.7 Schema Migration Rollout 證據；需要放行與回滾治理時，接 6.11 Migration Safety；若要看事故層教訓，接 GitHub 2018 Oct21 MySQL Topology Incident。

引用源

]]>