Microsoft：Safe Deployment Practices 與 Resilience Patterns
Safe deployment practices 的核心責任是讓大規模服務的每次變更都經過漸進驗證。ring-based deployment 把影響面從小到大排列，每一層是下一層的安全網。resilience patterns 的責任是讓服務在依賴失效時有標準化的降級行為，降低臨場判斷的成本。
問題場景
Azure 與 M365 等大型 SaaS 每天部署數千次變更，單靠人工審核不可擴展。當部署速度超過人工審查能力，需要一套自動化的漸進驗證流程來控制每次變更的風險。同時，服務間的依賴關係複雜，任何一個依賴的劣化都可能影響多個下游服務，需要標準化的降級行為避免連鎖失效。
決策機制
| 機制 | 核心問題 | 交付結果 |
|---|---|---|
| Ring-based deployment | 變更如何從小範圍漸進到全量 | 分層放行節奏 |
| Automatic rollback | health signal 異常時如何自動退回 | 自動化回退條件 |
| Resilience patterns | 依賴失效時服務如何標準化降級 | retry / breaker / bulkhead |
| Blast radius control | ring boundary 如何限制影響範圍 | 每層的最大影響面 |
Ring-based deployment 的標準路徑是 Ring 0（internal dogfood）→ Ring 1（canary）→ Ring 2（early adopters）→ Ring 3（broad）。每一層的 go/no-go 條件包含 health signal delta（跟前一版 baseline 比較）、error rate、latency percentile 與 customer impact signal。只有當前層的所有指標都在可接受範圍內，才進入下一層。
Automatic rollback 是 ring progression 的安全網。當 health signal 超過預設門檻時，系統自動回退到前一版，不需要等人工判斷。自動回退的觸發條件要嚴格定義 — 過於敏感會造成頻繁 false positive rollback，過於寬鬆會讓問題擴散到下一個 ring。
Resilience patterns 讓依賴失效時的行為可預測。retry with jitter 避免重試風暴、circuit breaker 在依賴持續失效時停止發送請求、bulkhead isolation 把不同依賴的資源池隔開。這些 patterns 的價值在於標準化 — 團隊不需要每次都從頭設計降級邏輯，而是從已驗證的 pattern 庫中選擇。
可觀測訊號
| 訊號 | 判讀重點 | 對應章節 |
|---|---|---|
| ring health delta | 每層的品質是否維持 | 6.8 |
| automatic rollback frequency | 自動回退是否過於頻繁或過少 | 6.18 |
| circuit breaker trip rate | 依賴失效是否被及時隔離 | 6.14 |
| deployment velocity | 漸進部署是否拖慢交付速度 | 6.1 |
常見陷阱
Ring progression 的觀察窗長度需要跟服務的 feedback loop 對齊。通用服務可能幾分鐘內就能看到異常，但有延遲確認的服務（結算、對帳、非同步補償）可能需要數小時甚至數天才暴露問題。觀察窗太短會漏掉延遲暴露的問題；太長會拖慢所有變更的交付速度。分服務類型設定不同觀察窗，比用統一時長更有效。
下一步路由
先把 ring-based deployment 的 go/no-go 條件寫進 6.8 Release Gate，再把 resilience patterns 的 circuit breaker 與 retry 設計接到 6.14 Dependency Reliability Budget。deployment velocity 的量測回到 6.18 Reliability Metrics，CI 整合回到 6.1 CI Pipeline。