Durable Objects 部署怎麼看？用 Deployments 分辨設定與實際流量
Durable Objects 做 gradual deployment 時，最難判斷的不是「我設定了幾％」，而是目前哪個版本真的在處理請求，以及新版的錯誤率是否已經和舊版分開。Cloudflare 在 2026 年 8 月 20 日為 Durable Object namespace 加上 Deployments 分頁，讓這些資訊不必再跳回 backing Worker 才能看。
直接答案是：把 Deployments 分頁當成 rollout 觀測面板，不是操作面板。 它會顯示版本、實際觀測流量、requests/sec、error rate 與 median wall time；要 promote、調整流量或 rollback，仍要到 backing Worker 的 Deployments。
Deployments 分頁回答「哪個版本正在工作」
從 Cloudflare dashboard 進入 Workers & Pages > Durable Objects，選擇 namespace，再開啟 Deployments。這裡看到的是該 namespace 背後 Worker 的部署版本，因為 Durable Object namespace 與 backing Worker 共用部署。
| 面板資訊 | 適合回答的問題 |
|---|---|
| Version | 目前有哪些版本仍在 deployment 中？ |
| Traffic % | 每個版本實際觀測到的流量比例如何？ |
| Requests/sec | 版本正在承受多少請求量？ |
| Error rate | 新舊版本的錯誤率是否出現差距？ |
| Median wall time | 版本的中位執行時間是否變化？ |
這個畫面的價值在於把版本與每個版本的運行指標放在同一個 namespace 脈絡裡。若你只看 Worker 的總體圖表，容易把多個版本的結果混在一起。
不要把 configured split 當成 actual traffic
Cloudflare 這次也調整了 Traffic % 的呈現，讓畫面同時反映設定比例與實際觀測流量。兩者不同，尤其是 Durable Objects：
| 比較項目 | Configured split | Actual observed traffic |
|---|---|---|
| 它代表什麼 | 你在部署時指定的版本分配 | Analytics 實際看到的版本流量 |
| 何時變化 | 設定部署後可能立即更新 | 要等請求產生與資料匯入 |
| Durable Objects 的限制 | 分配給個別 Object，而非每個 request | 會受 Object 數量、活躍度與版本釘選影響 |
| 排查用途 | 確認 rollout 目標 | 判斷新版真的承受多少流量與錯誤 |
每個 Durable Object 會在建立或啟動時釘在一個版本，直到新的部署發生；因此同一個 namespace 的 Object 不一定同時切到新版。再加上 analytics 有 ingestion delay 和 sampling，設定比例與實際比例短時間不一致，不代表部署指令失敗。
用三步驟排查新版 rollout
1. 先看版本是否仍在同一個 deployment
確認面板上的舊版與新版都存在，再看每個版本的 Traffic %、error rate 和 median wall time。不要只用「新版設定成 100%」當成觀測已完成的證據。
如果你是從 CLI 建立 gradual deployment，Cloudflare 的流程是先上傳 version，再用以下指令建立 deployment：
pnpm wrangler versions deploy這個指令的互動式設定負責建立分流；namespace 的 Deployments 分頁則用來觀察結果。
2. 把 error rate 和 wall time 放在版本旁邊比較
若新版的 error rate 上升，先記下兩個版本的實際流量與時間窗，再判斷是否有足夠資料。Durable Objects analytics 可能比 Workers analytics 晚幾分鐘，剛調整比例時不要只看第一個畫面就回滾。
若要看儲存量或 namespace Metrics，則回到 Durable Objects SQLite 儲存用量的排查方式；Deployments 回答版本分流，Total storage 回答資料量，兩者不能互相代替。
3. 需要處理流量時回到 backing Worker
Deployments 分頁是 read-only。要 promote、新增 split 或 rollback，請到 backing Worker 的 Deployments 頁面；Cloudflare 的 rollback 文件也說明，從 split deployment rollback 會以選定版本取代分流並把它導向 100%。
這個邊界很重要：你可以在 Durable Object namespace 看出異常，但不要以為刪掉 namespace 或重新部署 Object 就是回滾方式。先確認 backing Worker 的版本與 storage migration 是否能安全配合，再執行操作。
Durable Objects rollout 不是 request-level A/B test
一般 Worker 的 gradual deployment 可以按 request 分流；Durable Objects 則因為單一 Object 同一時間只會在一個版本上執行，會出現「某些 Object 已經是新版、另一些仍是舊版」的狀態。若新版和舊版共享的資料格式或 RPC contract 不相容，先處理 version skew，再用分流比例判斷進度。
所以這個面板比較適合以下工作流：
- 先以少量版本範圍部署。
- 觀察版本旁的實際流量與錯誤指標。
- 確認資料格式與跨版本行為可相容。
- 再回到 Worker 的 Deployments 調整比例或 rollback。
常見問題
Q: 為什麼 Durable Objects 的 actual traffic 和設定比例不一樣？
A: configured split 是分配給個別 Durable Object 的部署設定，不是每個 request 的即時比例。Object 的活躍度、版本釘選，以及 analytics 的資料延遲和抽樣，都可能讓 actual traffic 暫時不同。
Q: 可以直接在 Durable Objects 的 Deployments 分頁 rollback 嗎？
A: 不行。這個分頁是 read-only，只提供版本與指標觀測；promote、調整流量與 rollback 仍在 backing Worker 的 Deployments 頁面完成。
Q: Deployments 分頁和 Metrics 的差別是什麼？
A: Deployments 以版本為單位看分流、錯誤率與執行時間；Metrics 主要看 namespace 或個別 Object 的運行指標與儲存觀測。排查 rollout 時先看 Deployments，再依問題回到 Metrics。
參考資料：
Cloudflare Changelog：View deployments for Durable Objects in the dashboard
Cloudflare Workers Docs：Gradual deployments
回報錯字、失效連結，或告訴我你想看的延伸主題。