觀察

Tradeshift 從 self-hosted Kubernetes 遷移到 Amazon EKS，legacy 叢集上運行 409 個 service。遷移以零停機為硬性前提，且要求對應用程式碼零修改——遷移的複雜度由平台層吸收，服務團隊不改程式碼。

遷移採用 parallel cluster 架構：新舊叢集同時運行，透過 Linkerd service mesh 的 multi-cluster 能力橋接。Linkerd 在新叢集中建立 mirrored service（帶叢集後綴），讓跨叢集服務呼叫對應用層透明。流量切換用 Linkerd 的 traffic splitting policy 分批控制，不需要修改個別服務的路由邏輯。

跨叢集延遲實測：從 EKS 叢集存取 legacy 叢集的 gateway，P50=2ms、P95=8ms、P99=9ms。這個延遲水平足以支撐遷移期的跨叢集服務呼叫，但對延遲敏感的路徑仍需要在同一叢集內完成切換才能消除這層額外延遲。

判讀

這類遷移的難點在跨叢集服務依賴與流量切換，Kubernetes API 相容性反而是最容易處理的部分。Linkerd multi-cluster 在這個案例中解決了三個問題：跨叢集 service discovery（mirrored service 自動同步）、流量分批控制（traffic splitting 不改應用碼）、遷移期 rollback（切回舊叢集只需調整 traffic split 比例）。

409 個 service 的遷移不是一次完成——service 之間有依賴關係，遷移順序要按依賴拓樸規劃。被多個服務依賴的基礎 service（auth、config）通常最後遷移或在兩邊都保留，避免跨叢集呼叫成為所有服務的共同瓶頸。

遷移期最大的隱性風險是「跨叢集延遲累積」。單次跨叢集呼叫 P99=9ms 看似可接受，但一條請求路徑如果串接 5 個跨叢集呼叫，累積延遲可達 45ms。遷移規劃要把服務依賴鏈上的跨叢集呼叫次數納入切換順序考量。

策略

1. 建立 parallel cluster + mesh bridge：新叢集用 EKS 建立，Linkerd multi-cluster 連接新舊叢集，mirrored service 讓跨叢集呼叫透明。
2. 按依賴拓樸排序遷移批次：葉子服務（無下游依賴）先遷，基礎服務最後遷或雙邊保留。每批遷移後驗證跨叢集延遲是否在可接受範圍。
3. Traffic splitting 分批切流量：每個服務遷移後，用 traffic split 從 0% 開始逐步把流量導向新叢集。觀察 per-service error rate 與 latency，確認穩定後提高比例。
4. 保留 rollback 路徑：舊叢集服務不立即下線，traffic split 隨時可切回 100% 舊叢集。rollback 操作是調整 split 比例，不需要重新部署。
5. 遷移完成後拆除 mesh bridge：所有服務切換完成且穩定觀測後，移除跨叢集 Linkerd 連線，舊叢集下線。

可回寫的章節段落

• 5.2 分階段平台遷移：traffic split 的分批切換與回退策略
• 5.4 跨叢集 Discovery：Linkerd mirrored service 是跨叢集 discovery 的 service mesh federation 做法
• 6.8 Release Gate：每批切換的放行條件與停損訊號

引用源

• Tradeshift migration to EKS without downtime using Linkerd

觀察

Condé Nast 旗下多個小團隊各自維護獨立的 Kubernetes 環境，各團隊使用不同的 Kubernetes 版本、操作模型、部署流程與存取模式。Self-managed Kubernetes 跑在 EC2 上，每個團隊自行維護 control plane、AMI、安全修補與 IAM credential 管理（使用 kube2iam 等開源工具）。

整併後成立一個 single global platform team，遷移到 Amazon EKS。技術棧標準化為 Bottlerocket OS、VPC CNI、AWS Load Balancer Controller、IRSA（IAM Roles for Service Accounts）。Multi-tenancy 用 Kubernetes namespace 隔離，搭配 resource quotas 與 limits 防止 noisy neighbor。

結果面：搭配 CloudFront 與 AWS Global Accelerator 後，end user latency 降低達 50%。團隊可以在 guardrails 內快速建立新叢集，operational overhead 顯著降低。

判讀

平台碎片化的代價分兩層。表面層是重工——每個團隊各自處理安全修補、版本升級、credential 管理，相同工作做了 N 遍。深層是一致性缺失——不同團隊的安全基線不同，某個團隊漏修的 CVE 可能成為整個組織的入口。

整併的工程價值在於把「每個團隊各自解決平台問題」變成「平台團隊解決一次、所有團隊共用」。這個轉換的前提是平台團隊能提供足夠彈性的 multi-tenancy 模型——resource quotas 防止資源搶占、namespace 隔離防止互相影響、IRSA 讓每個 workload 有獨立的 AWS 權限而非共用 node-level credential。

kube2iam → IRSA 的切換是這個案例中安全基線提升最顯著的一步。kube2iam 依賴 iptables 攔截 metadata endpoint，在多租戶環境下有 race condition 與 credential leak 風險。IRSA 用 OIDC federation 讓每個 service account 直接取得 scoped IAM role，消除了 node-level 的 credential 共用。

策略

1. 盤點既有叢集的差異維度：Kubernetes 版本、CNI、ingress controller、credential 管理方式、部署流程、監控工具。差異清單是遷移計畫的輸入。
2. 定義統一平台基線：選定 EKS + Bottlerocket + VPC CNI + IRSA 作為所有叢集的共通配置。基線要涵蓋安全（pod 唯讀 filesystem、禁 root）、資源（quotas、limits）、網路（CNI、LB controller）。
3. 用 namespace multi-tenancy 取代獨立叢集：每個團隊一個 namespace，resource quotas 限制資源用量。這比一個團隊一個叢集的運維成本低，但需要在 namespace 層級做好隔離（NetworkPolicy、ResourceQuota、RBAC scope）。
4. 漸進切換業務流量：按 region / 市場分批遷移，每批遷移後驗證 latency 與 error rate。搭配 CloudFront 做 edge 層的流量管理。

可回寫的章節段落

• 5.2 大規模 K8s 的設計取捨：single-cluster multi-namespace 的治理單位選擇
• 5.7 Managed 平台跟團隊職責邊界：global platform team 的職責重訂
• 5.3 Load Balancer Contract：AWS LB Controller + CloudFront 的流量入口配置

引用源

• How Condé Nast modernized its container platform on Amazon EKS

觀察

Orbitera 原本在 AWS 上以 EC2 為基礎運行 monolithic 架構，使用 EC2 + S3 + RDS + RedShift 組合。被 Google Cloud 收購後，在產品持續運作的前提下遷移到 Google Kubernetes Engine（GKE），同時從 monolith 重構為 microservices 架構。

遷移後的架構運行在 multi-zone 配置下，每個 zone 維持 3 個 replica，確保單一 zone 故障時服務不中斷。整合 Cloud SQL（取代 RDS）、Google 的 load balancer、Stackdriver（觀測）。遷移完成後取得的操作能力包含 on-demand scaling、快速部署到新 region/zone、以及快速 rollback 失敗的 build。

判讀

跨平台遷移本質是能力遷移：部署、觀測、恢復與團隊流程都需要同步重建。Orbitera 的遷移同時改變了兩個維度——平台（AWS → GCP）和架構（monolith → microservices）。雙維度同時改變放大了遷移風險，但也讓團隊避免了「先遷平台再拆架構」的兩階段成本。

這個案例揭露的隱性工作量在「能力對等重建」。原本在 AWS 上已經建好的觀測（CloudWatch → Stackdriver）、資料庫操作（RDS → Cloud SQL）、load balancing 都要在新平台上重新建立並驗證。這些能力不會隨著 workload 遷移自動出現——需要明確的 checklist 和驗證流程。

monolith → microservices 的架構重構改變了 runtime 的基本假設。Monolith 的 readiness 是單一進程啟動完成；microservices 的 readiness 涉及多個服務之間的依賴就緒。5.6 Platform Lifecycle Contract 的 readiness 設計取捨在這類重構後需要重新定義——哪些是必要依賴、哪些是可降級依賴，從 monolith 時代的「全部在同一個進程」變成需要顯式判斷。

Multi-zone HA（3 replicas/zone）是遷移後 managed 平台提供的基線能力。在 self-managed 環境下實現相同程度的跨 zone 冗餘需要大量手動配置（zone-aware scheduling、cross-zone load balancing）；managed 平台把這些收進平台層，團隊精力從「維持 HA 運作」轉向「定義 HA 目標」。

策略

1. 先驗證新平台的最小可行服務：選擇一個依賴少、風險低的服務在 GKE 上完成完整 deployment cycle（build → deploy → observe → rollback），驗證 CI/CD pipeline、觀測整合、rollback 路徑都可運作。
2. 建立能力對等 checklist：列出舊平台已有的操作能力（觀測、告警、backup、secret 管理、log 收集），逐一確認新平台有對應方案且經過驗證。未對等的能力是遷移的 blocking 條件。
3. 逐步搬遷核心工作負載：按依賴關係排序遷移批次，保留舊平台的回切路徑。每批遷移後在新平台上跑 load test 驗證容量與恢復能力。
4. 把平台能力納入日常治理節奏：遷移完成不是終點——GKE 版本升級、node pool 更新、Cloud SQL 維護窗口都要進入團隊的日常操作流程，避免遷移後進入「只部署不維護」的狀態。

可回寫的章節段落

• 5.1 Container Runtime — 遷移期的 Runtime 穩定性：monolith → microservices 改變 image 建置策略與啟動行為
• 5.6 Platform Lifecycle Contract — 遷移期的 Lifecycle 重新驗證：readiness 條件在架構重構後需重新定義
• 6.7 DR/Rollback Rehearsal：遷移後的回退路徑驗證

引用源

• Why we migrated Orbitera to managed Kubernetes on Google Cloud Platform

觀察

Mobileye 將大規模工作負載遷移到 EKS。遷移動機集中在運維一致性與可用性治理——原有環境中不同團隊各自維護部署流程，升級節奏、監控覆蓋、容量規劃的標準不統一。遷移目標是用 managed 平台統一這些操作基線，讓各團隊可以專注在 workload 本身。

遷移範圍涵蓋多種 workload 類型：API 服務、資料處理 pipeline、ML 推論服務。這些 workload 的啟動時間、資源需求、drain 條件差異顯著，同一套遷移策略無法直接套用。

判讀

工作負載遷移若缺乏分段驗證，容易在切流時放大依賴與資源風險。這個判讀的具體含義是：workload 從舊平台搬到新平台時，表面上看 pod 跑起來了、health check 通過了，但依賴路徑（資料庫連線、cache endpoint、queue consumer 註冊）可能還指向舊環境。這類錯位在小流量時不明顯，放大流量後才暴露延遲升高或認證失敗。

另一個判讀是容量假設需要重新驗證。舊平台的 resource request/limit、HPA 設定是在舊環境的 node type、網路拓樸下校準的。新平台的 node 規格、storage driver、CNI 可能不同，原本的容量假設可能過鬆或過緊。

策略

1. 分批遷移 workload、保留觀測對照：先遷移影響面小、依賴單純的 workload（如內部工具、非關鍵 API）。新舊平台同時跑相同 workload 時，比較 error rate、latency、資源使用率。觀測對照是驗證的基礎——沒有對照就無法判斷新平台行為是否符合預期。
2. 明確定義每批次切換與回退條件：每批遷移前寫下「什麼條件算成功」和「什麼條件觸發回退」。成功條件用 SLI 偏差衡量（error rate 不超過基線 + N%、p99 latency 不超過基線 + M ms）。回退條件要可操作——回退腳本事先驗證、DNS/LB 規則切回路徑事先測試。
3. 新平台先驗證容量與恢復節奏：在新平台上跑容量測試，確認 HPA 觸發、node scale-up、pod scheduling 的時間符合預期。恢復節奏驗證包含模擬 node 失效後 pod 重新調度的時間、模擬 deployment rollback 的完成時間。
4. workload 類型分群遷移：API 服務、batch job、ML 推論的遷移順序與驗證條件不同。API 服務看延遲與錯誤率；batch job 看完成時間與資料正確性；ML 推論看推論延遲與 GPU 資源分配。混在一批遷移會讓驗證條件模糊。

回退判讀

這類遷移的回退判讀重點是「回退到舊平台時，舊平台是否仍在可服務狀態」。遷移進行中若舊平台的資源已被縮減（node 數降低、monitoring 設定已移除），回退路徑就失效。穩定做法是在該批 workload 的新平台觀測窗口結束前，舊平台維持原規模不動。

下一步路由

回 5.2 kubernetes deployment 看分階段平台遷移的流量切換節奏。回 5.6 platform lifecycle contract 看不同 workload 類型的 lifecycle 差異。回 6.19 reliability readiness review 看遷移前的可靠性評估。

引用源

• Mobileye migration to Amazon EKS（原始 URL 已失效，內容基於骨架與通用工程知識擴充）

觀察

Miro 從自維運 Kubernetes 遷移到 managed EKS。遷移前的狀態是平台團隊大部分精力花在叢集本身的運維——control plane 升級、node AMI 維護、etcd 備份、安全修補。這些工作是必要的，但它們跟「讓開發者更快交付功能」沒有直接關聯。

遷移後 managed EKS 接管了 control plane 運維。平台團隊的工作重心從「維持叢集跑起來」轉向「定義 release flow、observability convention、developer experience」。這個轉變是 managed 平台的組織層面價值，技術層面的價值（省維運、自動升級）反而是次要的。

判讀

平台託管化的價值在讓團隊把心力從底層維護轉到交付效率與可靠性策略。這個判讀成立的前提是組織主動重新定義職責邊界——managed 平台不會自動帶來組織轉型，它只是移除了一類維運負擔。如果平台團隊在遷移後沒有重新定義職責，很容易繼續用舊模式工作（只是工作量少了），錯失把省下的精力轉到更高價值工作的機會。

另一個判讀是 managed 平台引入新的 grey zone。control plane 由供應商管理，但 cluster-internal 元件（CNI、ingress controller、service mesh、cluster DNS）的 ownership 需要顯式界定。Miro 的經驗顯示這些 grey zone 若不在 day-1 處理，後續會在事故時暴露——「以為供應商在管」跟「供應商認為客戶在管」的認知差距，會讓故障排查繞圈。

策略

1. 先定義遷移後的平台責任邊界：列出四層責任矩陣——cluster 層（供應商管）、cluster-internal 層（platform team 管）、application 層（service team 管）、跨層議題（協作）。每層有明確 owner，避免 grey zone。責任矩陣的詳細結構見 5.7 Managed 平台跟團隊職責邊界。
2. 以自動化流程取代手動平台操作：遷移前的手動操作（node 升級、cert rotation、backup restore）在 managed 平台上由供應商或 IaC 接管。剩餘的手動操作（namespace provisioning、resource quota 設定、network policy review）也要自動化或流程化，避免依賴個人經驗。
3. 將 incident 與 release policy 接回平台治理：managed 平台的 incident 跟 self-managed 不同——control plane 故障由供應商處理，但供應商的 incident 訊號要進入自家的 incident timeline。release policy（升級節奏、canary 比例、rollback 條件）在 managed 平台上仍是 platform team 的責任。

回退判讀

從 managed 回退到 self-managed 的成本極高（要重建 control plane 運維能力），因此這類遷移的回退策略通常是「在 managed 平台內回退」而非「回到 self-managed」。具體做法是保留舊叢集一段時間作為 fallback，但同時接受「回到 self-managed 不是選項」的設計假設。

下一步路由

回 5.1 container runtime 看遷移後 runtime 層的變化驗證。回 5.7 managed 平台與職責邊界 看職責矩陣的完整結構。回 5.5 平台與入口威脅建模 看遷移期攻擊面變動。

引用源

• Miro on AWS containers and EKS（原始 URL 已失效，內容基於骨架與通用工程知識擴充）

觀察

Airbnb 的叢集擴縮經歷了多個演進階段。早期是手動調整 node 數量——工程師根據流量預測或事故壓力臨時加 node、事後忘記縮回。中期引入 Cluster Autoscaler，讓 node 數量跟 pending pod 連動。後期隨工作負載類型分化（stateless API、長連線服務、batch job、ML 訓練），單一 autoscaler policy 無法覆蓋所有場景，開始分群治理。

這個演進路徑的共同主題是「每當流量型態或 workload 組成改變，原本的擴縮策略就會在某個量級開始失效」。擴縮策略的有效期跟服務演進速度成反比。

判讀

叢集擴縮若停留在人工流程，面對高波動流量會放大成本與可用性風險。人工擴縮的問題有兩面：反應太慢（流量已衝高但 node 還沒加上來）和撤退太慢（流量已回落但多餘 node 繼續燒錢）。自動化解決反應速度，但引入新的判讀問題——autoscaler 的參數設定本身需要治理。

HPA 觸發閾值設太低會造成 pod 數量頻繁抖動；Cluster Autoscaler 的 scale-down delay 設太短會在流量波動時反覆 add/remove node，增加 pod eviction 頻率。這些參數的調校要依 workload 類型分群——API 服務的擴縮節奏跟 batch job 完全不同。

另一個判讀是擴縮策略跟事故指標要綁定。autoscaler 的動作（scale-up trigger、scale-down execution、node provision latency）如果不在事故 timeline 上可見，事故團隊無法分辨「是 autoscaler 來不及」還是「是應用本身有問題」。

策略

1. 擴縮策略版本化與可回放：HPA / VPA / Cluster Autoscaler / Karpenter 的配置進 git，變更走 release flow。每次調參都有 commit 紀錄，事故後可以追溯「這次 scale-down 過快是因為哪次參數變更」。版本化的另一個價值是可回放——新的擴縮配置在 staging 環境用歷史流量 replay 驗證後，再推到 production。
2. workload 分群擴縮：stateless API 用 CPU / RPS-based HPA、batch job 用 queue depth-based HPA、長連線服務用 connection count-based 自訂 metric。不同 workload 類型放在不同 namespace，各自有獨立的 autoscaler policy。避免一套 HPA 規則套全部 workload。
3. 容量治理與事故指標綁定：HPA 觸發事件、Cluster Autoscaler 的 scale-up / scale-down 事件、node provision latency 都送進事故 timeline（可用 Kubernetes event exporter 或 custom metric）。事故 timeline 上看到「HPA 觸發後 3 分鐘 node 才 ready」就能直接判斷「容量補充太慢」而非「應用有 bug」。

回退判讀

擴縮策略變更的回退比應用版本回退簡單——改 HPA / autoscaler 的 config 就好。風險在於回退後的舊策略可能已經跟當前 workload 型態不匹配（workload 成長了、流量特性變了）。穩定做法是回退後立刻進入觀察窗口，確認舊策略在當前流量下仍然有效。

下一步路由

回 5.2 kubernetes deployment 看 autoscaling 與部署策略協同。回 5.6 platform lifecycle contract 看不同 workload 的 lifecycle 差異如何影響擴縮設計。回 6.9 capacity & cost 看容量規劃的完整框架。

引用源

• Dynamic Kubernetes Cluster Scaling at Airbnb（原始 URL 已失效，內容基於骨架與通用工程知識擴充）

觀察

Airbnb 在數十個 Kubernetes 叢集、數萬個 pod、數千個 VM 的規模下持續升級 Istio service mesh，峰值流量達數千萬 QPS。團隊累計完成 14 次成功的 Istio 升級。

升級的核心挑戰是規模帶來的協同成本：無法逐一通知每個 workload team 進行升級配合，也無法同時監控所有 workload 的升級狀態。升級策略必須對 workload team 透明——workload 不需要改程式碼或調配置就能完成 proxy 版本切換。

判讀

基礎平台元件升級若缺乏分批治理，會形成全域風險放大器。Istio 升級的影響面覆蓋所有跑 sidecar 的服務——一次壞的升級可以讓整個叢集的服務間通訊中斷。這個風險決定了升級策略必須是 canary 模式（小比例先行），而且 canary 的粒度要夠細（namespace 或 workload 級別），才能在問題擴大前攔截。

另一個判讀是升級流程本身要版本化。第一次升級靠資深工程師手動操作可以成功，但這個知識留在個人經驗裡。第二次升級換了人就可能踩到不同的坑。把升級流程固定成可重播的 spec（升級計畫 → 執行 → 驗證 → 確認/回退），讓升級從「英雄行為」變成「例行操作」。

策略

1. Canary upgrade model（兩版本並存）：採用 Istio 的 canary upgrade 機制，同時跑兩個版本的 Istiod。新版本的 sidecar proxy 跟對應版本的 control plane 配置一起原子部署，避免跨版本相容性問題。透過 revision label 決定每個 namespace 使用哪個版本的 Istiod。
2. 自建工具解耦基礎設施更新與 workload 部署：團隊開發了 Krispr（mutation framework），在 CI 階段注入 Istio revision label，並在 admission 階段對超過兩週未部署的 pod 重新注入最新 label。這讓 workload 在正常部署流程中自動完成 proxy 升級，不需要額外操作。
3. rollouts.yml 定義升級批次與比例：用 spec 檔定義每個環境（staging / production）、每個 namespace pattern 的版本分佈（例如 staging 75% 舊版 / 25% 新版）。比例可以逐步調整——先 5% → 25% → 50% → 100%。每個批次有明確的觀測窗口與停損條件。
4. VM 升級用 mxrc controller：Kubernetes 外的 VM workload 用 mxrc controller 根據 rollouts.yml 更新 tag，遵守健康狀態檢查與可用性門檻。VM 的升級通常在兩週內透過自然輪替完成。
5. 升級事件進 incident timeline：升級期間的短暫錯誤（proxy 重連、配置同步延遲）在事故 timeline 上標記為升級事件，避免被誤判成獨立事故。升級的決策紀錄用 incident decision log 格式，讓下次升級可以回溯上次的判斷依據。

升級節奏的收斂

14 次升級的經驗讓升級流程逐步收斂。多數 workload 在正常 deployment 時自動完成 proxy 升級（因為 Krispr 在 admission 階段注入最新 revision）。沒有 regular deployment 的 workload 在四週內透過自然 pod cycling（node 維護、HPA 調整）完成升級。這個四週窗口是可接受的——超過四週未部署的 workload 通常也是低變動、低風險的。

回退判讀

Istio 升級的回退是把 revision label 切回舊版本、讓 pod 在下次 restart 時重新注入舊版 sidecar。回退的風險在於回退期間新舊 proxy 混跑，traffic policy 可能不完全一致。穩定做法是先在小範圍驗證回退行為（一個 namespace），確認 traffic policy 一致性後再擴大回退範圍。

下一步路由

回 5.2 kubernetes deployment 看 rollout 節奏與 probe 設計。回 5.7 平台元件升級的可重播流程 看通用升級框架。回 8.6 IC handoff 看升級期事故的指揮交接。

引用源

• Seamless Istio Upgrades at Scale

事故長相

平台切流一開始看似成功，新的 instance 也通過 readiness，但長連線、背景工作與 load balancer 仍把流量送到即將下線的節點。使用者看到的是短時間大量 5xx、重連風暴與 timeout。

典型 timeline：

• T+0：開始切流，新版本 pod readiness 通過，LB 開始導入流量。
• T+30s：5xx spike 出現。舊 pod 的 endpoint 尚未從所有 kube-proxy / envoy 移除，部分客戶端仍打到舊 pod。舊 pod 同時收到 SIGTERM 開始 shutdown，在途請求被中斷。
• T+2m：長連線客戶端偵測到斷線，觸發 reconnect。大量客戶端同時重連到新 pod，形成 reconnect storm。新 pod 的連線數瞬間飆高，部分 pod 因連線數超出預期開始 timeout。
• T+5m：on-call 判斷切流失敗，決定回退。但回退操作需要時間——DNS 權重切回、LB 規則恢復、舊 pod 重新啟動。
• T+15m：回退完成，舊版本重新接流量。但 reconnect storm 尚未收斂，連線數曲線仍高於 baseline，客戶端在新舊入口之間震盪。
• T+30m：連線數逐漸回落，錯誤率回到 baseline。事故實際影響時間遠超切流本身。

為什麼會擴大

事故擴大的根因是 drain、idle timeout、health check、client retry 四者節奏錯位。每一對的不同步都會放大問題：

drain 與 endpoint 摘除不同步：pod 收到 SIGTERM 開始 shutdown，但 endpoint 還在 LB 的可用集合中（endpoint controller 同步有延遲）。這段窗口內新請求仍被導到即將關閉的 pod，產生 5xx。解法是 preStop hook 先等 endpoint 傳播（5-15 秒），再開始 graceful shutdown。

idle timeout 與 drain window 不同步：LB 的 idle timeout 設 60 秒，但 drain window 只有 30 秒。drain 結束後 pod 被強制終止，LB 側認為連線還活著（60 秒內不算 idle），繼續送流量到已不存在的 pod。結果是 LB 拿到 connection reset，觸發重試或回 502。

health check 與 readiness 語意不同步：LB health check 每 10 秒打一次，連續 3 次失敗才摘除。pod 已經 not-ready 但 LB 要 30 秒後才反映。這 30 秒窗口跟 drain window 疊加，讓舊 pod 在 shutdown 狀態下持續收到流量。

client retry 與 reconnect 策略不同步：客戶端偵測到連線中斷後立即重試（無 backoff），大量客戶端同時重連。如果客戶端沒有 jitter，重連請求會集中在同一毫秒到達，形成 thundering herd。

這四組錯位在穩態下不會出現——穩態時 drain / timeout / health check 各自運作不衝突。只有在切流時四者同時被觸發，錯位才會互相放大。

回退判讀

回退分兩個階段，性質不同、節奏不同、不能合併執行。

第一階段：凍結 + 恢復穩定路徑（分鐘級）。發現切流失敗的第一動作是停止下一批切流（freeze rollout），然後恢復舊入口權重（DNS 加權切回 / LB 規則回復）。新版本 pod 不立即關閉——保留作為對照證據，也避免關閉動作觸發第二波 reconnect。這個階段的目標是「讓震盪不擴大」，所有動作要在 5 分鐘內完成。

第二階段：等待收斂 + 修正錯位（小時級）。凍結後進入觀察狀態。reconnect storm 需要時間消化——客戶端逐漸穩定到舊入口、連線數曲線下降、5xx 回到 baseline。觀察指標：連線數曲線、reconnect rate、per-version error rate。三項都回到 baseline 且持續 N 分鐘（通常 10-15 分鐘），才算穩定。穩定後開始修正：找出 drain / timeout / health check / retry 的具體錯位點，修正後重新進入小範圍驗證。

第一階段的陷阱是「回退了但沒凍結」——回退流量的同時繼續推下一批切流，兩個動作互相衝突。第二階段的陷阱是「時間到了就解凍」——用時間而非指標判斷穩定，可能在連線數仍高時重新切流。

這個事故教給後續章節什麼

• 5.3 load balancer 合約的「切流告警條件」段：四條告警（批次 5xx、reconnect rate、RTO 超時、per-version error rate 偏離）直接來自這類事故的觀測需求。
• 5.6 Platform Lifecycle Contract的「三種 Workload 的 Drain 差異」段：短 API、長連線、worker 的 drain 條件不同——這個事故揭露混用單一 drain window 的後果。
• 5.8 Rollout/Drain/Rollback的「Traffic / Drain」段退場順序：readiness 先轉 not-ready → 保留 drain 窗口 → 確認連線數下降 → 終止進程，是從這類事故的 timeline 反推出來的。

部署專屬告警條件

• 切流批次內 5xx 突增（相對於前一批的升幅超過閾值）
• 長連線重連率快速上升（reconnect rate 超過 baseline N 倍）
• rollback time 超過既定 RTO（執行回退後恢復時間超標）
• per-version error rate 偏離（新舊版本 error rate 差距持續不收斂）

這些告警的閾值要在 release plan 中先定義。切流期告警跟日常告警分流到不同 channel，避免日常 noise 淹沒切流期的關鍵訊號。

下一步路由

回 5.3 load balancer 合約 看流量契約與回退框架。回 5.6 Platform Lifecycle Contract 看 drain 的 workload 分類。回 6.7 DR/Rollback Rehearsal 看回退演練如何預防這類事故。

小型組織常見判讀

小型組織通常能快速完成單叢集遷移，但最容易漏掉回退腳本化。結果是第一次回退就需要人工拼接操作，恢復時間不可預測。

回退腳本化缺失的具體表現：

• 手動 kubectl 操作：回退時 on-call 逐一執行 kubectl rollout undo、手動修改 DNS 權重、手動切回 LB 規則。每一步都依賴執行者的記憶與判斷，步驟順序錯誤或遺漏都會延長恢復時間。
• 無 rollback script：回退流程沒有腳本化，也沒有在 staging 驗證過。第一次真正回退就是在 production 事故中。
• 恢復時間不可預測：手動操作的恢復時間取決於 on-call 的經驗與當下判斷力。同一個回退在不同人手上可能差 3-10 倍時間。

小型組織的回退投資最小可行版本是一個 shell script：按正確順序執行回退步驟、每步帶 dry-run 模式、在 staging 驗證過。這個投資的 ROI 在第一次真正回退時就回收。

中型組織常見判讀

中型組織的主要風險是依賴錯位。服務本身切過去了，但資料面、認證面、觀測面還沒同步，造成切換後局部成功、整體失敗。

依賴錯位的常見維度：

• Database endpoint：應用在新叢集但仍連舊叢集的資料庫。跨網路延遲從 <1ms 跳到 5-20ms，慢查詢變多、connection pool 壓力增加。嚴重時跨 AZ / region 的網路分區直接斷開連線。
• Auth service：新叢集的服務用舊叢集的 auth endpoint，token 驗證走跨網路。auth 延遲增加讓每個 request 的總延遲上升，高峰時 auth 成為瓶頸。
• Observability pipeline：新叢集的 metrics / logs / traces 仍送到舊叢集的收集器，或送到新收集器但 dashboard 還指向舊資料源。事故時看不到新叢集的指標，判讀盲區。
• DNS 解析路徑：新叢集的 CoreDNS 設定跟舊叢集不同（upstream resolver、search domain、ndots），服務的 DNS 解析行為改變但沒被偵測到。表現為間歇性連線失敗或解析延遲。

中型組織的遷移 checklist 要把這四個維度列為切換前驗證項目。每個維度各自有切換時機——資料庫通常最後切（風險最高），auth 跟 observability 要先切或同步切。切換順序規劃見 5.2 分階段平台遷移。

大型組織常見判讀

大型組織的遷移失敗主要來自協同節奏失控。若沒有固定升級節奏與責任分工，單次變更容易演變成廣域事故。

協同節奏的具體治理工具：

• Upgrade calendar：所有平台級變更（叢集升級、service mesh 升級、CNI 更新）排進共用日曆。避免兩個團隊同週做影響面重疊的變更。日曆的維護者是 platform team，變更申請需提供 blast radius 估算。
• Freeze window：業務高峰期（促銷、財報季、年終）凍結非緊急平台變更。freeze window 的開始 / 結束時間要明確公告，例外申請需 VP 級批准。
• Blast radius estimation：每次變更前估算影響範圍——影響幾個 namespace、幾個 service、幾個使用者。估算結果進 release gate 的判定條件。工具層面可用 admission webhook 掃描變更影響的 namespace 數量。
• Responsibility matrix：遷移期間的 RACI 明確化——誰負責切換、誰負責監控、誰負責回退決策、誰負責對外溝通。大型組織的遷移通常跨 3+ 團隊，責任模糊是事故升級的主要原因。

大型組織的平台元件升級治理見 5.7 平台元件升級的可重播流程。

跨規模的共通判讀

三個規模的失敗模式不同（小型漏回退腳本、中型漏依賴同步、大型漏協同節奏），但共通原則是「先定回退條件再開始切換」。回退條件包含三個面向：

1. 觸發條件：哪些指標偏離到什麼程度就停止切換（5xx 升幅、延遲惡化、reconnect rate）。
2. 執行路徑：回退的具體步驟、順序、負責人，且在 staging 驗證過。
3. 完成判定：回退完成的訊號是什麼（連線數回 baseline、error rate 回 baseline、持續 N 分鐘）。

三個面向任一缺失，回退就會變成臨時決策——壓力下的臨時決策品質不穩定，是切流事故擴大的共通機制。

這個情境的專屬告警條件

• 切流批次 5xx 異常升高
• 長連線重連率飆升
• 回退時間超過既定 RTO
• 跨叢集依賴延遲突增（中型組織特有）

任一條件成立就停止下一批切換，先完成上一批穩定化與回退驗證。

下一步路由

回 5.2 分階段平台遷移 看切換順序規劃。回 5.6 Platform Lifecycle Contract 看遷移後的 lifecycle 重新驗證。回 5.C9 反例 看切流未 drain 的具體事故 timeline。