Amazon 可靠性設計的核心責任是把失效影響限制在局部邊界。當系統採用多租戶與大規模共享資源，隔離策略必須先於恢復策略被定義，否則任何回復動作都會變成全域風險。

問題場景

多租戶服務常見的放大路徑是「單租戶異常 → 共享資源飽和 → 全域退化」。若路由與容量都沒有明確邊界，團隊只能在事故後做整體降載，代價高且恢復慢。

cell-based architecture 與 shuffle sharding 提供的是前置結構：先限制擴散，再談恢復。

決策機制

機制核心問題交付結果
Cell 邊界一個失效最多影響到哪裡局部故障域
Shuffle sharding熱點租戶如何避免重疊影響隨機子集合隔離
Static stability控制面失效時資料面如何維持降級持續服務
Constant work失敗模式下是否維持固定工作量防放大設計

這組機制讓恢復策略從「全域搶救」轉為「分批收斂」。在可用性與成本取捨上，局部隔離通常比全域冗餘更可持續。

可觀測訊號

訊號判讀重點對應章節
shard contention熱點是否跨 shard 擴散6.14
cell error isolation ratio錯誤是否被限制在局部6.20
recovery batch completion分批恢復是否可預測8.3
control-plane dependency lag控制面異常是否拖累資料面4.13

常見陷阱

把 sharding 當成純擴容手段會忽略隔離責任。當分片策略只服務容量，沒有對齊失效邊界，事故時仍會看到跨租戶共振。真正的設計重點是「隔離優先，擴容其次」。

下一步路由

要把案例轉成可執行設計，先定義 6.14 的依賴預算與共享邊界，再在 6.20 驗證局部化假設。事故時的分批回復流程回到 8.14。