image 與建置責任

image 的責任是固定依賴、執行入口與檔案結構，讓同一版本在不同環境行為一致。建置流程要回答三件事：基底映像是否可維護、建置產物是否可追溯、敏感資訊是否被隔離。

映像層數、套件來源、編譯參數都會影響啟動時間與安全邊界。部署策略在後面才有效，前提是 runtime 產物本身可預測。

基底映像選擇

基底映像（base image）決定 image 的安全維護基線與啟動時體積。選擇的核心取捨是體積 / 啟動速度與除錯便利性：

• 語言官方映像（python:3.12、node:20）：套件齊全、除錯方便，但體積大（通常 800MB+）、攻擊面廣。適合開發環境與 CI。
• slim / alpine 變體（python:3.12-slim、node:20-alpine）：體積壓到 100-200MB、啟動快、攻擊面小。代價是缺少除錯工具（strace、curl、dig），生產事故時 exec 進容器排查會受限。Alpine 用 musl libc 而非 glibc，某些 C extension 需要額外處理。
• distroless（gcr.io/distroless/base）：只包含 runtime 必要檔案，無 shell、無套件管理器。攻擊面最小，但除錯只能靠 ephemeral debug container 或外部觀測。適合安全要求高且觀測基礎建設完備的生產環境。
• 自建基底：組織統一維護的基底映像，可以固定安全基線、預裝觀測 agent、統一 timezone / locale。代價是基底維護本身是持續工作，版本更新節奏要有明確 owner。

選完基底後要確認兩件事：upstream 的更新節奏是否可追蹤（CVE 修補從上游到自家 image 的時間），以及團隊是否有能力在基底更新後快速重建並驗證所有服務 image。

建置可重現性

同一份 source code 在不同時間建置出不同 image，會讓 rollback 的假設失效——「回退到上一版」回退的是哪一版，取決於當時 build 環境的狀態。

可重現建置的關鍵實踐：

1. 鎖定依賴版本：go.sum、package-lock.json、poetry.lock 要進 git。依賴解析在建置時不從 registry 重新 resolve。
2. Multi-stage build：把建置環境（compiler、dev dependencies）和執行環境分開。最終 image 只包含 runtime 必要檔案，體積小且攻擊面收窄。
3. 避免 image 中殘留敏感資訊：build arg、環境變數、中間層都可能殘留 secret。secret 不進 Dockerfile，用 runtime mount 或 secret manager 注入。
4. image 標記策略：latest tag 不可重現——同一個 tag 指向的 image 會隨時間改變。用 git commit SHA 或語意版本號標記，讓每個 tag 指向唯一 image。

對應 5.C3 Orbitera managed K8s migration：揭露「跨平台遷移本質是能力遷移」。遷移到新平台時，CI/CD pipeline 可能換了 runner 環境、換了 registry——建置可重現性的前提是依賴鎖定與 multi-stage build 本身不依賴特定 CI 環境。

entrypoint 與啟動行為

entrypoint/command 的責任是定義容器如何啟動與退出。啟動流程應顯式處理初始化步驟、配置載入、依賴檢查與失敗退出。退出流程應處理信號中斷、在途請求收斂與資源釋放。

若啟動行為隱藏在 shell script 且無可觀測訊號，部署平台很難判斷 readiness 與失敗原因。

PID 1 與信號處理

容器內 PID 1 有特殊語意：它是 init process，負責接收平台送來的 SIGTERM / SIGINT 並轉發給子進程。PID 1 的問題出在三種情境：

Shell 作為 PID 1：ENTRYPOINT ["sh", "-c", "java -jar app.jar"] 讓 sh 成為 PID 1。SIGTERM 送到 sh、sh 預設不轉發、java 進程收不到信號、等到 terminationGracePeriodSeconds 到期後被 SIGKILL 強殺。修法是用 exec 或直接用 exec form：ENTRYPOINT ["java", "-jar", "app.jar"]。

多進程容器：一個容器跑多個進程時，PID 1 要負責信號轉發與子進程回收（zombie reaping）。如果 PID 1 不做 wait()，結束的子進程會變成 zombie。解法是用 tini 或 dumb-init 作為輕量 init，或在 Kubernetes 設 shareProcessNamespace: true 讓 kubelet 處理。

啟動腳本的信號遮蔽：entrypoint script 在初始化階段（下載 config、等依賴就緒）捕捉 SIGTERM 做清理，但如果清理邏輯卡住，整個 shutdown 會被阻塞。啟動腳本的 trap handler 要有 timeout，避免把 graceful shutdown 變成 ungraceful hang。

啟動時間對部署策略的影響

啟動時間直接影響 rollout 的最短觀察窗。一個啟動需 60 秒的服務，rollout 每批至少要等 60 秒 + 觀察窗口才能確認新版本穩定。啟動時間的組成與壓縮策略見 5.6 Platform Lifecycle Contract。

image 體積也影響啟動時間——image pull 在冷啟動（節點上沒有這個 image 的快取）時占啟動時間的顯著比例。1GB image 在 100Mbps 網路下需要 ~80 秒 pull。壓縮 image 體積同時改善啟動速度與節省 registry 頻寬。

resource limit

CPU/memory Resource Limit 隔離資源競爭並保護叢集穩態。限制過低會導致頻繁節流與重啟，過高會壓縮同節點容量並放大鄰近工作負載風險。

限制設計要依服務流量型態與 GC/執行時特性調整，並與 autoscaling、rollout 批次策略一起評估。

CPU request 與 limit 的設定策略

CPU 限制有兩個參數：request（排程保證）與 limit（硬上限）。兩者的關係決定服務在負載變動下的行為：

• request = limit（guaranteed QoS）：CPU 用量穩定可預測，不會被 throttle 也不會超用。代價是無法在閒時借用節點剩餘 CPU。適合延遲敏感的 API 服務。
• request < limit（burstable QoS）：平時用 request 保證的份額，高峰時可用到 limit。代價是當節點 CPU 競爭激烈時，所有 burstable pod 同時被 throttle，延遲會一起劣化。適合批次處理或對延遲要求不高的服務。
• 不設 limit（只設 request）：服務可用到節點全部剩餘 CPU。Kubernetes 社群近年傾向這個做法——CPU throttle 常比 CPU contention 更難排查。代價是需要良好的觀測來偵測 noisy neighbor。

Memory limit 與 OOM 的判讀

memory limit 是硬邊界——超過就 OOM kill，不走 graceful shutdown。OOM kill 的判讀分兩種情境：

真正的 memory leak：記憶體使用量隨時間單調上升，GC 無法回收。修法在程式碼層。memory limit 只是延後問題爆發，不是解法。

memory limit 設太低：服務在高峰流量下的正常記憶體使用超過 limit。常見於 JVM 服務——JVM heap + metaspace + native memory + thread stack 的總和超出 container memory limit。設 limit 時要用「峰值實際使用 + headroom」而非「平均使用」。

GC-based runtime（JVM、.NET、Go）要注意 container-aware memory 設定。早期 JVM 不認 cgroup memory limit，會按宿主機記憶體計算 heap 大小，導致 heap 配置超過 container limit。現代 JVM（Java 10+）預設啟用 container awareness（-XX:+UseContainerSupport），Go runtime 1.19+ 支援 GOMEMLIMIT。

資源設定與 autoscaling 的協同

resource request 同時決定 HPA（Horizontal Pod Autoscaler）的觸發基線。request 設太高時，CPU utilization % 會偏低，HPA 不會觸發擴容，導致服務在真正需要擴容前已經出現延遲。request 設太低時，utilization % 容易衝高，HPA 頻繁擴容，造成 pod 數量抖動。

穩定做法是先在 staging 環境跑負載測試確認服務的實際資源消耗曲線，再以 p90 負載的 CPU / memory 使用作為 request 基線。

runtime config

環境差異要顯式化才能追蹤——Runtime Config 承擔這個責任。配置來源、版本、更新節奏都應可追蹤。高風險設定需配合 Config Rollout 策略，避免同批大規模變更。

runtime 配置與映像版本要保留相容窗口，讓部署與回退可分步進行。

配置注入方式與取捨

配置注入容器有三條路徑，各自有不同的版本追蹤與更新語意：

環境變數最簡單但更新需要 restart。ConfigMap mount 可以動態更新但應用要能偵測檔案變化並 reload。外部 config store（Consul KV、AWS AppConfig、Feature Flag service）最靈活但引入了額外依賴。

設定變更跟 image 變更走不同路徑時，要確保兩者的版本可以交叉相容。版本 v2 的 image 搭版本 A 的 config 能跑、版本 v1 的 image 搭版本 B 的 config 也能跑——rollback image 但 config 沒回退、或 rollback config 但 image 沒回退的情境下、服務不應崩潰。這個相容窗口的設計責任見 5.7 Config Boundary。

遷移期的 Runtime 穩定性

對應 5.C5 Miro managed EKS 遷移：揭露「平台託管化的價值在讓團隊把心力從底層維護轉到交付效率與可靠性策略」。遷移到 managed 平台後，runtime 層面的變化包含 container runtime 版本（containerd vs Docker shim）、node OS、storage driver、network plugin。這些變化可能改變 image pull 速度、filesystem 行為、DNS 解析路徑。

遷移前後的 runtime 驗證應包含：

1. image pull 時間比較：新 registry / 新 node 的 pull 速度是否在 startup timeout 內。
2. filesystem 行為：log 寫入路徑、tmp 目錄、volume mount 行為在新 runtime 下是否一致。
3. DNS 解析：新叢集的 CoreDNS / node-local DNS 設定是否影響服務的依賴連線建立速度。
4. resource 行為：新 node type 的 CPU 架構（x86 vs ARM）、memory page size 是否影響服務性能特性。

判讀訊號

常見誤區

Container 常被簡化成「打包完就好」的步驟，結果是部署風險被後移到 rollout 階段。runtime 產物穩定性不足時，後續 probe、canary、rollback 都只能被動補救。

把資源限制設成平台預設值，也常造成高峰期不穩。限制應反映服務真實耗用模式，不應只追求表面資源利用率。

把 latest tag 當成版本標記，會讓 rollback 指向無法預測的 image。image tag 在 registry 上是 mutable——同一個 tag 可以被覆蓋指向新 image。用 immutable tag（commit SHA、content digest）才能保證 rollback 的確定性。

把所有配置都用環境變數注入，會讓設定變更跟 image 部署綁在一起。需要動態更新的設定（feature flag、rate limit 閾值）應該用 ConfigMap mount 或外部 config store，讓設定變更不需要 pod restart。

案例回寫

runtime 穩定性可用 5.C1 Tradeshift：self-managed K8s -> EKS 回寫。先看遷移期內啟動行為與資源限制如何影響切流，再對照本章檢查 image、entrypoint、limit 與 config 相容窗口。這個案例主要支撐的是「執行環境可重現性」判讀——遷移到新叢集時，image 不變但 runtime 環境變了（node OS、container runtime 版本、network plugin），runtime 穩定性的前提是 image 本身不依賴特定宿主環境的行為。

5.C5 Miro managed EKS 遷移 從另一個角度支撐：managed 平台接管 runtime 基礎設施後，container runtime 版本升級由平台控制，團隊要能驗證自家 image 在新 runtime 版本下行為一致。

若同版容器在不同節點出現分歧行為，先追建置來源與 runtime config 版本鏈，確認是依賴漂移還是環境漂移，再把關鍵證據收斂到 4.20 Observability Evidence Package。不直接支撐 service discovery TTL 或 queue replay 邏輯；若根因在定位鏈路或重播流程，應轉到 5.4 或 3.4。

跨模組路由

1. 與 5.2 的交接：部署批次與探針策略回到 Kubernetes 部署策略。
2. 與 5.3 的交接：流量進出與連線收斂回到 load balancer 合約。
3. 與 5.6 的交接：startup / readiness / drain 的生命週期定義回到 Platform Lifecycle Contract。
4. 與 4.20 的交接：啟動與資源證據回到 Observability Evidence Package。
5. 與 6.8 的交接：放行與回退條件回到 Release Gate。
6. 與 7.3 的交接：image 安全基線與攻擊面回到 7.3 入口治理與伺服器防護。

下一步路由

要把 runtime 行為接到部署收斂，接著讀 5.2 Kubernetes 部署策略。要看切流與退場條件，接著讀 5.3 load balancer 合約。要看 runtime 層的生命週期如何被平台表達，接著讀 5.6 Platform Lifecycle Contract。

deployment、replica 與 rollout

Deployment 的責任是宣告目標狀態：期望副本數、版本、更新策略。rollout 的責任是把現況收斂到目標狀態，並在過程中維持可服務能力。這兩者分開理解後，才能在異常時判斷是目標設定問題，還是收斂過程問題。

rolling update 常用來降低單次切換風險。rolling update 的判讀重點是批次大小與節奏：每批新增多少新副本、每批回收多少舊副本、每批觀察多長時間。這些參數以服務容量曲線與回退時間目標校準、名稱本身只是工具標籤、不是判讀條件。

probe 對齊服務生命週期

probe 要對齊服務生命週期，不同 probe 有不同責任：

1. startup probe：確認服務啟動完成，避免慢啟動服務被過早重啟。
2. readiness probe：確認服務可安全接流量。
3. liveness probe：確認服務仍可維持基本運作，必要時觸發重建。

probe 設計若只回傳固定成功，rollout 期間會出現「容器在線但服務未就緒」的流量抖動。穩定做法是讓 readiness 反映依賴就緒條件，例如資料庫連線池、必要配置、關鍵背景任務狀態。

Startup probe 設計注意事項

startup probe 跟 initialDelaySeconds 解決同一個問題（避免慢啟動服務被 liveness 殺掉），但機制不同。initialDelaySeconds 是 liveness / readiness probe 的延遲啟動——在等待期間 probe 完全不跑，無法觀測啟動進度。startup probe 在啟動期間持續探測，一旦成功就交棒給 liveness / readiness，啟動失敗時能更快偵測到。

startup probe 的總容忍時間 = failureThreshold × periodSeconds。例如 failureThreshold: 30, periodSeconds: 10 給服務 300 秒啟動窗口。設計時先量測服務在最差情境下的啟動時間（冷啟動 + image pull + 依賴連線建立），再加 20-30% headroom 作為總容忍時間。

Readiness probe 的深度選擇

readiness probe 的檢查深度決定它能攔截多少「可啟動但不可服務」的狀態。三個常見層級：

1. Port check（TCP probe）：確認進程在監聽。最淺，無法偵測依賴未就緒。適合依賴簡單、啟動快的服務。
2. Dependency check（HTTP endpoint 檢查必要依賴）：確認資料庫連線池、cache 連線可用。涵蓋多數「啟動完但依賴不通」的場景。常用做法是在 /ready endpoint 內驗證必要依賴的連線狀態。
3. Deep health（業務路徑驗證）：執行一次簡化的業務查詢確認端到端通路。最深但代價最高——probe 本身消耗資源，且可能被下游延遲拖慢導致 readiness 抖動。

依賴分類（必要 / 可降級 / 觀測）的判讀框架見 5.6 Readiness 設計的核心取捨。

config rollout 與版本相容

Config Rollout 需要和應用版本一起治理。設定先行、版本後行，或版本先行、設定後行，都要保留相容窗口。相容窗口存在時，才有漸進 rollout 與快速回退空間。

跨版本配置遷移要先定義停止條件：錯誤率上升、延遲尖峰、關鍵路徑失敗或下游壓力超標。停止條件明確後，部署決策才能一致。

N-1 相容與 Feature Flag Gating

版本相容窗口的操作基線是 N-1 相容：版本 N 的程式碼可以處理版本 N-1 的設定，反之亦然。這讓 rollback 從「版本 + config 必須同時回退」降級成「版本先回退、config 稍後再處理」，回退操作的原子性要求降低。

N-1 相容的實作通常搭配 feature flag gating：新功能在程式碼中預設關閉，先部署程式碼（版本 N 上線但新功能 off），確認版本穩定後再開啟 feature flag。這讓版本部署跟功能啟用分成兩個獨立決策，rollback 時只需關 flag 而不必回退版本。

N-1 相容窗口的壽命要有明確終點。長期維護雙版本相容會累積技術債——舊欄位不能刪、舊路徑不能移除。穩定做法是在 rollout 完成 + 觀測確認穩定後設定移除 deadline，把 N-1 相容視為暫時性保護而非永久設計。設定注入方式與版本追蹤見 5.1 配置注入方式與取捨。

Autoscaling 與部署策略協同

autoscaling 在部署期間扮演容量緩衝角色。部署批次若超過服務可承受變動幅度，autoscaling 會被動補償並延長收斂時間。穩定做法是讓 rollout 節奏與容量策略同時設計：先保證服務穩態，再提高切換速度。

長連線服務或有大量背景任務的 workload，通常需要比 stateless API 更保守的 rollout 策略，並額外搭配 drain 與 reconnect 設計。

擴縮策略的演進需要版本化跟可回放。對應 5.C6 Airbnb K8s 叢集擴縮演進：揭露「擴縮策略版本化跟可回放」「不同 workload 區分擴縮政策」「容量治理跟事故指標綁定」三個方向。以下基於通用工程知識展開。

可重複套用的做法：

1. 擴縮策略進 IaC：HPA / VPA / Karpenter / Cluster Autoscaler 的配置都進 git、變更走 release flow、避免手動調整在事故後被遺忘。IaC + 自動化的 ownership 邊界見 [5.7 control plane boundary](/backend/05-deployment-platform/traffic-config-control-plane-boundary/)。
2. workload 分群擴縮：stateless API、長連線服務、batch job、background worker 對擴縮的需求不同。把不同 workload 用不同 namespace + 不同 autoscaler policy 隔離，避免一套規則套全部。
3. 擴縮事件接事故指標：HPA 觸發、scale-up 延遲、scale-down 過快、cluster autoscaler 加 node 失敗，都該在事故 timeline 上可見。回到 4.13 service topology 的擴縮事件 vs 事故區分。

分階段平台遷移

平台遷移的本質是流量跟依賴的分段切換。遷移期內新舊叢集同時存在，rollout 策略要把跨叢集流量切換納入批次節奏、視為連續多批決策。本段聚焦流量 / 依賴切換時序；遷移期的團隊職責邊界重訂見 5.7 Managed 平台跟團隊職責邊界。

對應 5.C1 Tradeshift：self-managed K8s → EKS：揭露「零停機遷移要把切換做成分段策略」「難點通常在跨叢集服務依賴跟流量切換、不在 Kubernetes API 本身」。對應 5.C4 Mobileye workloads 遷移：揭露「分批遷移 workload、保留觀測對照」「明確切換 / 回退條件」「新平台先驗證容量跟恢復節奏」。以下基於通用工程知識展開。

可重複套用的分階段做法：

1. 新叢集 + 共通配置基線：先在新叢集上建立跟舊叢集對等的配置基線（namespace、ResourceQuota、NetworkPolicy、Ingress class、storage class），讓 workload 可以無縫部署。
2. 小流量先導服務：選擇影響面小、依賴單純的服務作為先導，先在新叢集跑完整 deployment cycle（rollout、drain、rollback 驗證）、累積信心後再擴大。
3. 可控流量分批切換：用 DNS 加權、service mesh 流量切分或 LB 規則把流量分批從舊叢集導到新叢集。每批切換後驗證 SLI 偏差、再進下一批。
4. 每批保留回退路徑：舊叢集服務不立即下線，保留作為回退目標。回退條件先驗證（rollback script、流量切回 DNS / LB 規則），再開始下一批切換。

延伸 5.C1 揭露的「跨叢集服務依賴是難點」、5.C10 中型組織判讀「服務本身切過去了、但資料面、認證面、觀測面還沒同步」也指向同類問題。跨叢集遷移最容易出的事故是「服務切過去了、依賴沒切過去」。Database、cache、message queue、observability pipeline、auth service 的切換時機要分別規劃，避免應用層在新叢集但仍跨網路打舊叢集的依賴，造成隱性 latency 或單點失效。規模差異下的同類問題見 5.C10 對照。

大規模 K8s 的設計取捨

K8s 在不同規模下的設計取捨會明顯分歧。小規模叢集追求簡單跟低運維成本，大規模叢集追求隔離跟自動化治理。同一套部署策略放到不同規模會在某個量級開始失效。

對應 9.C12 Riot Games：246 個 EKS cluster：揭露架構決策從 multi-tenant cluster 改成 single-tenant per game、Karpenter + Terraform 的 cluster 級自動化、35ms 延遲門檻 + Local Zones / Outposts 區域部署（case 中「35ms 反推 region 部署」屬作者判讀層、本章引用此推論）。對應 9.C34 GCP 130,000-node GKE cluster：揭露 control plane 極限取決於 storage backend（GCP 用 Spanner 替代 etcd）、AI workload 跟 web workload 容量規劃差異。對應 9.C33 Maersk + Bosch AKS：揭露 Maersk 工程訴求引語「focus on things that makes the most business impact」、傳統產業上 K8s 動機是治理一致性（作者判讀）、適合 single-cluster-multi-namespace。

可重複套用的取捨判讀：

1. single-tenant per workload vs single-cluster multi-namespace：高隔離需求（每個 workload 失效不能影響其他）、高延遲敏感度（需 region cluster）→ 多 cluster；治理一致性訴求（統一 release flow、合規邊界）→ 單一 cluster 多 namespace。
2. Cluster 容量極限取決於 control plane：data plane（worker nodes）擴容容易、control plane（API server、etcd / storage）擴容難、瓶頸通常在 control plane。etcd 撐 5K-10K node 後吃力、需要替換 storage backend（Spanner / PostgreSQL / 自家 KV）才能撐萬級節點（見 9.C34）。control plane 的 ownership 邊界由 5.7 control plane boundary 處理。
3. Multi-cluster 治理需要 IaC + 自動化：Terraform / Crossplane / Cluster API + Karpenter / Cluster Autoscaler 是基本工具。手動管理超過數十個 cluster 不可行。
4. AI workload 跟 web workload 容量規劃完全不同：AI workload 短時間爆量創建 Pods（萬級 / 秒）、preempt 頻繁；web workload 節點生命週期長、變動緩。把 web 經驗套到 AI workload 容量規劃會嚴重低估壓力。

關鍵判讀是「先決定 cluster 是隔離單位還是治理單位」。Riot Games 把 cluster 當隔離單位（246 個獨立 cluster），Maersk / Bosch 把 cluster 當治理單位（單 cluster 多 namespace）。同一個工具兩種用法、決定整體運維模型。

對應 5.C2 Condé Nast：EKS 平台整併與標準化：揭露多叢集整併到單一控制面的場景、跟 Maersk-Bosch 同屬「治理一致性」取捨方向（治理單位優先於隔離單位）。Condé Nast 的整併路徑是「盤點既有叢集差異 → 建立統一平台基線 → 藍綠或漸進切換業務流量」、對應前面「分階段平台遷移」段的批次節奏。

判讀訊號

常見誤區

把 Kubernetes 部署看成 YAML 套版，會忽略服務語意差異。相同 deployment 參數在不同服務上，可能代表完全不同風險。

把 probe 當成健康檢查 URL，會讓服務在邊界條件下過早接流量。probe 的工程價值在於反映服務真實可用條件。

把 cluster scale-up 想成「加 node 就好」也是常見誤判。當 cluster 規模超過 control plane 預設邊界，etcd / API server 會先撐不住，加 node 反而加重 control plane 負擔。

案例回寫

部署切換語意可用 5.C9 反例 做回寫。先看事件中的失敗是在 rollout 批次、probe 判斷、還是 drain 時序，再對照本章的 rollout 節奏與停止條件。

這個案例主要支撐的是「部署批次與切換時序」判讀，不直接支撐資料庫交易切分或 consumer 冪等；若問題落在提交一致性或重播補償，應轉到 1.3 或 3.4。

若版本已切換但錯誤率延遲上升，先回到 probe 與 config 相容窗口，再把證據欄位接到 4.20 Observability Evidence Package 與 8.19 Incident Decision Log。

跨模組路由

Kubernetes 部署策略要和觀測、驗證、事故流程同時對齊。

1. 與 5.6 的交接：startup / readiness / liveness / drain 的生命週期定義回到 Platform Lifecycle Contract。
2. 與 5.1 的交接：image、entrypoint、resource limit 的 runtime 層回到 container 與 runtime。
3. 與 5.3 的交接：流量承接與退出落在 load balancer 合約。
4. 與 5.4 的交接：endpoint 註冊與摘除回到 service discovery。
5. 與 5.7 的交接：control plane 跟 data plane 邊界落在 Traffic、Config 與 Control Plane Boundary。
6. 與 4.20 的交接：版本切換證據進入 Observability Evidence Package。
7. 與 6.8 的交接：放行與停損條件進入 Release Gate。
8. 與 8.19 的交接：部署中止與回退判斷進入 Incident Decision Log。

下一步路由

要把部署與流量切換一起治理，接著讀 5.3 load balancer 合約。要看切換失敗與回退判讀，接著讀 5.C9 反例。要看大規模 K8s 容量設計，接著讀 9.C12 Riot Games 跟 9.C34 GCP 130K-node。

contract 組成

Load Balancer Contract 可以拆成四個部分：

1. routing contract：哪些路徑導向哪些服務，如何處理權重與版本。
2. health contract：哪些訊號代表可接流量，何時摘除節點。
3. connection contract：長短連線的 idle timeout、keepalive、重試規則。
4. drain contract：版本切換時如何讓 in-flight request 安全收斂。

這四個部分共同定義 rollout 的穩定性。服務端 readiness 與平台端健康檢查要對位，否則會出現「服務已啟動但尚未可服務」的切換抖動。

draining 與 shutdown

draining 的責任是讓舊實例在下線前完成現有請求。drain 視窗的 workload 分類詳見 5.6 Platform Lifecycle Contract，本段聚焦 LB 如何配合 drain：短請求 API 的 drain 視窗可較短；長連線、串流或 websocket 場景需要更長窗口與明確 reconnect 策略。

部署流程中，LB 摘流量、服務停止接新請求、服務完成在途請求、實例退出，這四步要有固定順序。順序穩定後，rollback 才能在同一套機制下運作。

timeout 與 sticky session

idle timeout 是連線資源與使用者體驗的平衡點。timeout 太短會增加重連與錯誤，太長會占用連線與資源。設定時依請求型態與峰值流量校準、按 SLI 訊號迭代閾值。

Timeout 層級串聯

一條請求路徑上的 timeout 分佈在多個層級，每層各自有預設值。全路徑的 timeout 設計原則是由外到內遞減：外層（離使用者近）的 timeout 要大於內層（離資料源近），否則外層先放棄，內層還在處理一個已經沒人等的請求。

這張表的每一層 timeout 都要比它的下一層大。如果 LB timeout 30 秒但 application 設了 60 秒，LB 會在 30 秒回 504 給使用者，但 application 仍然持有連線等 DB 回應——佔用連線資源卻無法交付結果。

timeout 設計的常見失誤是只調 LB 層：團隊看到使用者回報 timeout，直接把 LB timeout 從 30 秒調到 120 秒。結果是慢請求佔用 LB 連線更久、連線池被慢請求填滿、其他正常請求也開始排隊 timeout。穩定做法是先在 application 或 DB 層找出延遲根因，而非放大外層 timeout 來「等更久」。

sticky session 適合需要短期會話一致性的場景，但它會提高特定節點負載不均與失效轉移成本。採用 sticky policy 前要先定義會話狀態落點與失效時的回復路徑。

LB + CDN 連線生命週期協調

當 LB 上游有 CDN 時、兩層的 timeout / retry 行為要對齊、否則會出現「使用者已經 timeout 但 origin 還在處理」這類雙層不一致：

• CDN edge timeout 通常比 origin LB timeout 短（5-30 秒）— edge 認定 origin 慢就放棄。若 origin LB timeout 是 60 秒、edge 在 30 秒已放棄回 504、origin 還在處理一個沒人在意的 request。應對齊兩邊的 timeout 上限。
• CDN retry policy 在 edge miss 後若拿不到 origin response、預設不會重試（避免雙倍 origin 流量）— LB 端的 idle timeout 設計要假設「只有一次機會」、不依賴上游重試
• 長連線（WebSocket、SSE、gRPC）通常繞過 CDN — 直接連到 origin LB。這些連線的 idle timeout 跟一般 HTTP 不同、要單獨配置
• Edge cache HIT 時 LB 完全沒收到 request — 容量規劃時要把 cache hit ratio 算進 origin RPS、不是用使用者 RPS 直接 size LB

詳見 5.9 邊緣分發與靜態資源 的 origin protection 段。

切流失敗的回退判讀

切流失敗的回退判讀第一步是先分辨「平台問題」跟「流量生命週期問題」、再決定回退手法。平台問題用重啟服務恢復、流量生命週期問題用凍結切換並等待震盪收斂。回退手法錯位會把事故推進第二階段。

切流失敗的本質是 connection lifecycle 跟切換時序錯位、平台元件本身往往是健康的。對應 5.C9 反例：平台切流未先 Draining：揭露切流失敗常因 connection lifecycle 管理錯位、重啟動作會放大震盪。以下基於通用工程知識展開回退節奏。

回退節奏有兩個時序階段、性質不同。

第一階段：先讓震盪不擴大。發現切流失敗的第一動作是凍結 rollout（不再擴大切換範圍）跟恢復舊入口權重（把 LB 規則 / DNS 加權 / service mesh 流量切回舊版本主導）。新版本不立即關閉、保留作為對照證據。這個階段的目標是穩定當前狀態、為後續分析爭取時間、所有動作要在分鐘級內完成。

第二階段：再讓系統可恢復。震盪不擴大後、進入「等待 + 修正」狀態。長連線跟 reconnect 風暴需要時間消化、盲目重啟新版本實例會把重連集中在新一輪實例上、造成 thundering herd。觀察連線數、reconnect rate、5xx 趨勢回到 baseline 是進入修正階段的訊號。修正動作聚焦於 drain window、idle timeout、health check、client retry 之間的節奏錯位、找出後修正、重新進入小範圍驗證。這個階段的時間尺度通常是小時級、不能用第一階段的緊急節奏對待。

兩階段時序不能合併。把第一階段（凍結 + 切回）跟第二階段（等待 + 修正）並列執行、會在連線尚未穩定時嘗試修正、造成第二次震盪。

回退時最常見的誤判是「LB 顯示新節點 healthy = 服務可服務」。LB 的健康判斷通常是定期 health check 通過，跟「該節點能承受重連潮」是不同問題。事故中要把這兩個訊號分開看：節點層健康（health check pass）、連線層健康（reconnect rate、長連線錯誤率、tail latency）。

切流告警條件

對應 5.C9 反例 的「部署專屬告警條件」段：揭露切流期告警的三個核心訊號（批次內 5xx 突增、長連線重連率快速上升、rollback time 超過既定 RTO）。本段在 case 三條基礎上補第 4 條（per-version error rate 偏離）與操作建議。

切流期告警的核心責任是對應切流批次節奏、跟日常閾值分離。日常閾值在切流期會被切換本身的短暫波動觸發、變成 alert noise；切流期需要更嚴格的「批次內偏差」訊號。

可操作的切流期告警條件：

• 批次內 5xx 異常升高：當前批次相對於前一批的 5xx 升幅超過閾值、停止下一批。
• 長連線重連率飆升：reconnect rate 超過 baseline N 倍、暗示 drain / timeout 錯位。
• 回退時間超過 RTO：執行回退後恢復時間超過既定 RTO、升級為事故等級。
• per-version error rate 偏離：新舊版本 error rate 差距超過閾值、不收斂（屬本章補強、case 未明示）。

這些告警的閾值要在 release plan 中先定義、進事故時直接套用、避免臨時拍定。把切流告警跟一般日常告警分流到不同 channel，避免事故團隊在切流期被日常 noise 淹沒。

判讀訊號

「回退後 reconnect 風暴持續」是切流事故中最容易誤判的訊號。判讀順序：先看是否「凍結切換」已執行（rollout 是否真的停了）、再看「舊入口權重」是否回到主導比例（DNS / LB 規則是否切回）、最後看連線數曲線是否進入下降。三項都做完仍見風暴持續、才考慮新版本實例層級的問題（image / config / runtime 漂移）、而非反向重啟新版本。解凍切換的條件是「連線數曲線回到 baseline + reconnect rate 低於閾值連續 N 分鐘」、不是「等夠久了就解凍」的時間導向。

常見誤區

把 load balancer 當成「只做轉發」的元件，會忽略它在部署與事故中的決策角色。LB 設定定義了流量切換節奏、回退可行性與故障擴散速度。

Health check 跟 readiness 的混淆會在切換時暴露隱性風險。health contract 要反映服務真實 readiness — 含依賴連線池、必要 config、關鍵背景任務狀態 — 而非停在單一探針成功訊號。

把「LB 顯示節點 healthy」當作「服務可承受流量」的訊號，也是事故中的常見誤判。健康檢查通過跟承受重連潮是不同層級的訊號。

案例回寫

流量契約可用 5.C9 反例 回寫。先看事件中的摘流量順序、drain 視窗與連線重建節奏，再回到本章判讀 connection contract 與 drain contract 是否對齊。

這個案例主要支撐的是「連線生命週期與摘流量順序」判讀，不直接支撐 container build 可重現性；若根因在映像與 runtime 漂移，應回到 5.1。

當回退後錯誤率仍高或重連風暴延續，通常表示 timeout 與 sticky policy 仍在放大舊連線狀態。先重建連線生命週期時序，再把回退判斷同步到 8.19 Incident Decision Log。

跨模組路由

load balancer contract 是部署平台與操作控制面的匯流點。

1. 與 5.6 的交接：drain 的生命週期定義與 workload 分類回到 Platform Lifecycle Contract。
2. 與 04 的交接：版本切換訊號與錯誤率證據進入 Observability Evidence Package。
3. 與 06 的交接：canary 放行與回退條件進入 Release Gate。
4. 與 07 的交接：入口治理與管理面保護進入 7.3 入口治理與伺服器防護。
5. 與 08 的交接：切換與回退判斷記錄到 Incident Decision Log。
6. 與 5.9 邊緣分發 的交接：CDN 是 origin LB 的上游、edge miss 後流量進 origin LB、timeout / retry 設定要協調。

下一步路由

要把 LB 合約放進整體部署流程，接著讀 5.2 Kubernetes 部署策略 與 5.C9 反例。要把部署切換接到事故流程，接著讀 8.19 Incident Decision Log。

DNS 與 registry

service discovery 常見兩種路徑：DNS 查詢與 service registry。DNS 提供簡化解析路徑，適合標準服務發現；registry 提供更細節的實例狀態與元資料，適合複雜路由與多租戶治理。

選擇重點是變更頻率與一致性需求。實例變動頻繁或跨區路由複雜時，registry 能提供更細控制；穩定內網服務可優先 DNS 路徑降低操作成本。

DNS-based Discovery 的運作與限制

Kubernetes Service 的 ClusterIP 模式是最常見的 DNS-based discovery：kube-dns / CoreDNS 回覆一個虛擬 IP，kube-proxy 用 iptables / IPVS 做 L4 負載均衡到實際 pod IP。Headless Service（clusterIP: None）則直接回傳所有 pod IP 的 A record，讓客戶端自行選擇目標。

DNS-based discovery 的限制來自 DNS 本身的語意：

1. TTL 與快取：DNS 回應帶 TTL，客戶端和中間 resolver 會快取。當 pod 被摘除但 DNS 快取尚未過期，客戶端仍會嘗試連到已不存在的 IP。Kubernetes CoreDNS 的 Service TTL 預設 30 秒，但客戶端語言 runtime 可能有自己的 DNS cache（JVM networkaddress.cache.ttl 預設 30 秒、有些版本預設 -1 代表永不過期）。
2. 無健康資訊：DNS A record 不帶健康狀態。回覆的 IP 可能對應已經 not-ready 但尚未被 endpoint controller 移除的 pod。這個時間窗口取決於 kubelet sync 頻率與 endpoint controller 的反應速度。
3. 無權重 / 元資料：DNS 不原生支援流量權重、版本標記、區域偏好。需要這些能力時要靠 service mesh 或 client-side load balancing。

DNS 路徑的工程價值在於零侵入——任何能解析 DNS 的程式碼都自動取得 discovery 能力，不需要額外 SDK 或 sidecar。缺點是控制粒度只到 IP 層，無法表達更豐富的路由語意。

Registry-based Discovery 的運作模式

Service registry（Consul、etcd、Eureka、Nacos）維護 key-value store，每個 service instance 主動註冊自己的地址、metadata 與健康狀態。Client 透過 registry API 或 local agent 取得可用 instance 清單。

Registry 的工程價值在於提供 DNS 無法表達的元資料：instance 的版本、區域、權重、標籤都可以作為路由條件。代價是所有 service 都需要 registry 連線邏輯（SDK 或 sidecar），且 registry 本身成為基礎設施依賴——registry 不可用時，新 instance 無法註冊、現有 instance 無法被發現。

Registry 跟 DNS 不互斥。常見做法是 registry 作為 source of truth，再用 DNS interface 對外提供查詢（Consul DNS Interface、CoreDNS 的 etcd plugin）。這讓簡單場景走 DNS、複雜路由走 registry API、兩者共用同一份 instance 清單。

選擇判讀框架

endpoint discovery

Internal Endpoint discovery 的責任是維持可連線目標集合。這包含註冊、健康檢查、摘除、重建後回註冊。服務端 readiness 與 discovery 健康判斷要對齊，否則會出現不可服務實例仍被路由的情況。

endpoint 變更需要可追溯訊號，讓事故期間能快速判讀是路由失真、註冊延遲，還是下游本身不可用。

註冊時序與 Readiness 對齊

endpoint 的註冊時機是 discovery 穩定性的關鍵變數。註冊太早（服務尚未 ready 就被加入可用集合）會導致客戶端打到未就緒實例；註冊太晚（服務已 ready 但尚未被 discovery 看到）會導致容量不足。

Kubernetes 的做法是把 endpoint 跟 readinessProbe 綁定：readiness pass 才把 pod IP 加入 Endpoints 物件。這個設計讓 readiness 定義直接決定 discovery 行為。但 readiness probe 的判斷到 Endpoints 更新之間仍有延遲（endpoint controller sync 週期 + kube-proxy rules 更新），這個延遲窗口內的行為要理解：

• Pod 剛從 not-ready 變 ready：endpoint controller 需要同步周期把 pod IP 加入 Endpoints → kube-proxy 更新 iptables / IPVS → 流量才會到。期間該 pod 不接流量但已可服務。
• Pod 從 ready 變 not-ready：同樣有延遲。期間客戶端仍可能打到已 not-ready 的 pod。drain 設計要覆蓋這段窗口。

摘除節奏與 Drain 的配合

endpoint 摘除不是瞬時的。從 pod 標記 not-ready 到所有 client 停止向它送流量，中間經過多個同步步驟。這段時間內，被摘除的 pod 仍會收到流量。

穩定做法是在 preStop hook 加入短暫等待（通常 5-15 秒），讓 endpoint 更新有時間傳播到所有 kube-proxy / envoy，然後再開始 graceful shutdown。這段 preStop 等待是 5.6 Platform Lifecycle Contract 中 drain 總窗口（短 API 通常 5-30 秒）的 endpoint 傳播子區間，drain 總窗口還要覆蓋 preStop 之後的在途請求收斂時間。

跨叢集 Discovery 的挑戰

對應 5.C1 Tradeshift self-managed K8s → EKS：揭露「遷移難點通常在跨叢集服務依賴與流量切換、不在 Kubernetes API 本身」。跨叢集 discovery 是遷移期的核心難題——服務 A 在新叢集、服務 B 在舊叢集，A 要能找到 B。

跨叢集 discovery 的常見做法：

1. 外部 DNS + 加權路由：兩個叢集的 service 都註冊到外部 DNS（Route 53、Cloud DNS），用權重控制流量比例。簡單但粒度粗，只能整體切、不能 per-service 切。
2. Service mesh federation：Istio multi-cluster、Linkerd multi-cluster 把跨叢集 endpoint 統一管理。粒度細、可以 per-service 切流量，但引入 mesh 的複雜度。
3. Application-level routing：應用自己管理多叢集 endpoint（通常透過 config 或 feature flag），切換時改 config。最靈活但最手動，適合遷移期的過渡方案。

遷移期最危險的狀態是「服務切過去了、discovery 沒切過去」——新叢集的服務 A 仍透過舊 discovery 找舊叢集的 B，跨網路延遲從微秒級跳到毫秒級，或在網路分區時完全斷開。discovery 切換要跟服務切換同批規劃。

failure fallback

fallback 在 discovery 層的責任是縮小定位失敗影響。常見策略包含本地快取最後可用集合、區域優先回退、受控重試與短暫降級。

fallback 設計要明確停止條件。長期依賴過期 endpoint 快取會造成隱性錯誤累積，事故期反而更難收斂。

Fallback 的三層防線

discovery 故障的 fallback 可分三層，每層有不同的代價與風險：

第一層：本地 endpoint 快取。Client 維持最後一次成功查詢的 endpoint 清單。discovery 服務不可用時，繼續用快取 endpoint。風險是快取中的 endpoint 可能已經下線或不健康。有效期要設上限——超過 N 分鐘的快取視為不可信，進入第二層。

第二層：區域降級。本區域的 endpoint 全部不可用時，降級到其他區域的 endpoint。代價是跨區延遲增加。風險是其他區域也可能因為同源故障而不可用。降級時要觀測跨區延遲是否在 SLO 內，超出則進第三層。

第三層：服務降級。discovery 完全失效時，服務本身降級——返回快取回應、靜態頁面、或明確的錯誤訊息。這一層的設計責任落在應用的 fallback 策略，discovery 只負責提供「目前無可用 endpoint」的訊號。

三層防線的共同原則是每一層都有明確的進入條件和退出條件。進入 fallback 不是終點——要持續嘗試恢復正常路徑，fallback 狀態持續時間要被觀測和告警。

判讀訊號

常見誤區

Service discovery 跟 DNS 設定的混淆，會讓註冊時序、健康判斷與摘除節奏的缺口在平時被忽略。這類缺口在平時不明顯，通常在切版、擴縮容或區域異常時集中爆發。

把 fallback 命中率視為穩定指標也容易誤判。fallback 長期偏高代表主路徑問題被遮蔽，應回頭檢查 endpoint 新鮮度與註冊健康，而不是只放寬重試。

把 DNS TTL 設成 0 試圖取得即時一致性，會大幅增加 DNS 查詢量。DNS 的設計前提是快取——TTL 0 在高流量服務下會讓 DNS server 成為瓶頸。穩定做法是設合理 TTL（5-30 秒）搭配 client-side 主動刷新。

把 JVM 的 DNS cache 當成 OS 的 DNS TTL——JVM networkaddress.cache.ttl 的預設值在不同版本不同（有些版本是 30 秒、有些是永不過期）。容器化部署時要顯式設定，避免 pod IP 變了但 JVM 還在打舊 IP。

定位邊界

service discovery 專注「找到可用實例」。當問題進入設定分發、版本切換、策略開關，責任轉到 Config Rollout 與部署策略章節。邊界分明能避免故障排查時把不同控制面混為一談。

discovery 跟 load balancing 的邊界：discovery 回答「有哪些 endpoint 可用」，load balancing 回答「在可用 endpoint 中選哪一個」。DNS round-robin 把兩者混在一起，registry-based 方案通常把兩者分開，讓 LB 策略（round-robin、least-connection、consistent hash）在 discovery 結果之上獨立運作。

案例回寫

發現與定位鏈路可用 5.C3 Orbitera：managed K8s migration 回寫。先看遷移期間實例註冊、摘除與 DNS/registry 同步節奏，再對照本章判讀 endpoint 新鮮度與 fallback 壽命是否合理。

5.C1 Tradeshift self-managed K8s → EKS 從跨叢集角度支撐：揭露遷移期的 discovery 挑戰——「難點在跨叢集服務依賴與流量切換」。遷移期 discovery 要處理新舊叢集的 endpoint 共存、切換時序、回退路徑。

這些案例主要支撐「定位集合新鮮度」與「跨叢集 discovery 同步」判讀。不直接支撐 LB 連線 timeout 或 runtime 建置一致性；若問題在連線生命週期或映像漂移，應轉到 5.3 或 5.1。

遇到「查詢成功但連線失敗率高」時，應拆成註冊時序、TTL 與快取刷新三條線同步驗證，避免把定位問題誤判成下游異常，再把證據分流到 8.18 Incident Intake & Evidence Triage。

跨模組路由

1. 與 5.2 的交接：實例註冊與可用判定回到 Kubernetes 部署策略。
2. 與 5.3 的交接：路由目標與流量合約回到 load balancer 合約。
3. 與 5.6 的交接：endpoint 註冊時序與 readiness 的對齊回到 Platform Lifecycle Contract。
4. 與 5.7 的交接：discovery 與 control plane boundary 的分責回到 Traffic、Config 與 Control Plane Boundary。
5. 與 4.13 的交接：依賴拓樸與發現信號回到 Service Topology 與 Dependency Map。
6. 與 8.18 的交接：定位故障的證據分流回到 Incident Intake & Evidence Triage。

下一步路由

要把發現機制放進流量契約，接著讀 5.3 load balancer 合約。要看部署切換如何影響可用集合，接著讀 5.2 Kubernetes 部署策略。要看 discovery 在 control plane 邊界中的定位，接著讀 5.7 Traffic、Config 與 Control Plane Boundary。

服務環節問題地圖

平台弱點盤點的第一層是把服務環節跟攻擊面對齊。同一個服務交付路徑上、入口、生命週期、設定、交付節奏各自有不同失分模式。

入口暴露面

入口暴露面的主要弱點判讀是「實際可達範圍是否超過設計意圖」。容器化、service mesh、ingress controller 升級、新增 LoadBalancer 都可能無意中把內部服務暴露到公網。入口清單跟責任鏈先對齊、能避免發版本就改變了攻擊面。升級流程跟回退窗口設計見 5.7 平台元件升級的可重播流程。

入口暴露面的盤點要區分三類入口，各自有不同的失分模式：

1. 設計意圖內的入口（Ingress / LoadBalancer Service / API Gateway）：這些入口有明確 owner、有 WAF / TLS 保護。弱點在於設定漂移——port 範圍擴大、路由規則放寬、wildcard host 引入。盤點方式是定期比對實際 Ingress 規則與設計意圖。
2. 隱性入口（NodePort、hostNetwork pod、debug endpoint、metrics endpoint）：這些入口在設計時不被視為外部可達，但在特定網路拓樸下可能從外部存取。NodePort 預設 range 30000-32767 在某些雲端 security group 設定下可能對外開放。metrics endpoint（/metrics、/debug/pprof）常不帶認證、暴露服務內部狀態。
3. 暫態入口（kubectl port-forward、臨時 LoadBalancer、tunnel 測試）：開發或除錯時臨時打開的入口，使用後忘記關閉。這類入口沒有 WAF、沒有 TLS、沒有 audit log，是攻擊面中最難盤點的部分。

Tunnel 形態的入口（cloudflared、Tailscale Funnel）有獨立的弱點盤點框架，見 5.10 Outbound Tunnel 入口 的認證疊法段。

生命週期訊號

生命週期訊號的弱點聚焦於脆弱窗口期被利用：readiness 過早通過、shutdown 階段仍在處理 in-flight request、drain 視窗內接收新請求，都會把短暫的脆弱窗口拉長。

脆弱窗口的判讀要跟 5.6 Platform Lifecycle Contract 的生命週期狀態對齊：

• startup → readiness 窗口：服務正在初始化、依賴尚未驗證、安全中介軟體（WAF sidecar、auth proxy）可能還沒就緒。此時如果 readiness 過早通過讓流量進來，請求可能繞過安全層直接打到後端。
• readiness → drain 窗口：正常服務狀態，弱點集中在 readiness 條件太鬆——只檢查 port 可達但 auth middleware 沒初始化。
• drain → shutdown 窗口：服務正在收斂，此時安全元件（rate limiter、WAF）可能已停止更新規則但仍在處理請求。攻擊者若在 drain 窗口送入惡意請求，安全元件可能無法正常攔截。

設定與密鑰下發

設定與密鑰下發是最容易被忽略的維度。Image 沒變但 config / secret 變了、權限因 RBAC 漂移擴張、feature flag 在 production 偷偷開啟未經 review 的新行為。這些變更不走 release gate 的話，攻擊者有大量低噪音入口可以利用。

設定變更的弱點盤點要分兩個方向：

顯式設定變更（ConfigMap、Secret、feature flag 更新）：變更本身是可追蹤的，弱點在於 review 機制是否涵蓋高風險設定。payment endpoint、auth provider URL、rate limit 閾值、CORS 允許來源——這些設定的變更影響跟程式碼變更等量，應走同等 review 流程。設定變更的 review 與 rollout 策略見 5.7 Config Boundary。

隱式設定漂移（RBAC 逐步放寬、network policy 例外累積、service account 權限擴張）：這類變更是多次小修改累積的結果，單次變更看起來合理但累積後超出安全邊界。盤點方式是定期用 policy-as-code（OPA/Gatekeeper、Kyverno）掃描 cluster 內的 RBAC binding、network policy、pod security 設定，跟 baseline 比對偏移程度。

交付切換節奏

交付切換節奏的弱點判讀是「在不穩定窗口期、系統是否還有防禦能力」。Canary / rollout / rollback 期間 5xx 升高、connection 重建、auth 短暫失敗，會掩蓋同期間的攻擊訊號。沒有先定停損條件就推交付速度、是把切換期變成攻擊期的常見做法。

交付窗口期的防禦能力退化有兩個機制：

訊號淹沒：rollout 本身產生的短暫錯誤（5xx spike、reconnect、auth retry）跟攻擊訊號長得一樣。事故團隊在切流期把所有異常歸因於部署變更，攻擊者剛好利用這個注意力盲區。對策是把切流期 alert 跟安全 alert 分流到不同 channel，安全訊號走獨立通道、由 security on-call 獨立判讀。

防禦元件版本不一致：canary 期間新舊版本同時在線，WAF 規則、rate limit 設定、auth middleware 版本可能不同。攻擊者可以針對舊版本的已知弱點送流量，利用 canary 期間的路由特性讓流量到達舊版本。對策是把安全元件的更新跟應用版本解耦——WAF 規則、rate limit 是平台層設定，應在所有版本一致生效。

案例對照表（情境 → 判讀 → 注意事項 → 路由章節）

「外網可達入口在發版後增加」是平台變更弱點盤點的頭號議題。Ingress class 換、Service type 改、LB 規則重組都可能讓原本內部服務獲得外部 IP。把入口盤點放進 release pre-check、能讓這類變更在合併前被擋下。

「readiness 通過但實際流量錯誤率上升」揭露 readiness probe 設計失誤的弱點面向。Probe 只回 200 OK 不代表服務可承受真實流量、攻擊者剛好可以在這個窗口送高頻 request 看是否壓垮服務。Readiness 反映依賴就緒條件而非單一探針成功、能縮短這個窗口。

「設定異動與異常事件同時出現」是 config rollout 的弱點風險。Config 變更後出現異常事件、可能是設定本身的問題、也可能是攻擊者剛好利用了設定窗口。Config 審查跟責任追蹤同步維護、能讓事後復盤分辨兩者。

「切流期間入侵告警被淹沒」是新加入的議題。切流產生大量短暫 5xx、reconnect、auth retry、可能淹沒真正的攻擊訊號。把切流期 alert 跟一般 alert 分流、攻擊訊號走獨立通道、能避免攻擊在切流窗口下被忽略。

平台遷移期的攻擊面變動

對應 5.C1 / 5.C4 / 5.C5 揭露的遷移分段切換流程、本段從弱點盤點角度補充其攻擊面變動風險（case 庫未直接揭露此角度、屬通用工程經驗）。遷移期的職責邊界重訂見 5.7 Managed 平台跟團隊職責邊界、弱點盤點跟治理視角合用才完整。

平台遷移（self-managed → managed、單 cluster → 多 cluster、舊版本 → 新版本）會短期擴大攻擊面、然後逐步收斂。遷移期顯式管理攻擊面變化、避免雙軌期變成攻擊面雙倍期。

可重複套用的弱點判讀：

1. 盤點雙軌期入口：舊平台跟新平台的入口清單分別列出、確認新平台不繼承舊平台已知漏洞、舊平台的廢棄入口確實關閉。
2. identity / credential 重新對位：service account、API token、TLS cert 在新平台是否走新的 rotation flow、舊平台的 credential 是否在切換完成後撤除。
3. observability 對應更新：新平台的 audit log、access log、security event 是否進入同一個 SIEM / 告警通道、避免遷移期內攻擊訊號掉到觀測缺口。
4. 回退路徑的攻擊面評估：回退到舊平台時、舊平台是否仍處於最新 patch 狀態、回退本身會不會把已修補的漏洞重新引入。

遷移計畫要把資安 review 列為 gate 之一、讓遷移期攻擊面變動進入可見治理流程。沒有這道 gate、遷移期容易被當成純技術項目處理、漏掉攻擊面的隱性擴大。

到實作前的最後一層

弱點盤點在概念層回答的是平台風險判讀與交接節奏。當討論進入 Kubernetes 欄位、LB 規則、系統服務參數或腳本配置時，就代表已進入實作層。

實作層的防護驗證跟概念層分工：實作層看具體 YAML / config / rule 是否符合 hardening baseline、概念層看交付路徑跟責任鏈是否完整。兩者都做才能讓平台變更的攻擊面在 release 前可見。

進實作層後接 07 資料保護模組 的具體 hardening 章節、跟 7.3 入口治理與伺服器防護 對齊入口分級。

Lifecycle Contract

Lifecycle contract 定義平台如何啟動、檢查、接流量、停止與回收服務實例。它包含 runtime、startup、readiness、liveness、shutdown 與 drain。

這些狀態分開後，部署事故才能定位是啟動、接流量、退場還是平台判讀問題。

runtime 與 startup 決定服務能否形成可運行實例。readiness 與 liveness 決定平台何時導入流量與何時重建實例。shutdown 與 drain 決定版本退場時是否能保護在途工作。這些狀態都屬於生命週期合約，卻對應不同的事故處理路徑。

Startup 與 Readiness

startup 的責任是確認服務初始化完成。readiness 的責任是確認服務可承接實際流量。啟動完成不代表依賴已就緒，也不代表背景任務、config、secret 或 connection pool 都可用。

慢啟動服務需要 startup gate，避免 liveness 在初始化期間反覆重啟。依賴敏感服務需要 readiness gate，避免尚未連上資料庫、cache 或 queue 時就接收請求。

啟動時間的組成與壓縮

服務啟動時間的長短決定 rollout 節奏的下限。啟動時間由四段組成，每段有不同壓縮策略：

1. runtime 初始化：語言 VM、GC 初始化、class loading（JVM warmup 可達 10-30 秒）。壓縮手段是 ahead-of-time compilation（GraalVM native image、Go 靜態編譯啟動速度快）或 CDS（Class Data Sharing）。
2. 依賴建立：資料庫連線池、cache 連線、queue consumer 註冊。壓縮手段是 lazy initialization（按需建立）或 connection pool pre-warming（啟動時建好但不阻擋 readiness）。
3. 資料預載：config 同步、feature flag 初始拉取、本地快取預熱。壓縮手段是區分必要載入與非必要載入——必要的阻擋 readiness，非必要的平行載入。
4. 就緒驗證：自我健康檢查、依賴可達性驗證。壓縮手段是平行驗證多個依賴，避免串行等待。

啟動時間超過平台預設 startup timeout 時，先拆成這四段分析瓶頸，再決定調大 timeout 還是壓縮啟動流程。盲目調大 timeout 會掩蓋啟動退化問題，讓單次 rollout 的最短觀察窗拉長。

Readiness 設計的核心取捨

readiness 太鬆（只檢查 HTTP port 是否可達）會讓尚未就緒的實例接到流量。readiness 太緊（檢查所有下游可達性）會讓非自身問題的下游故障觸發連鎖 not-ready，放大故障面。

取捨的判讀框架是「這個依賴不可用時，服務是否仍能提供有意義的回應」：

• 必要依賴：資料庫、auth service——不可用時服務完全無法處理請求。這類依賴的可達性應納入 readiness 條件。
• 可降級依賴：推薦引擎、非關鍵 cache——不可用時服務可回傳降級結果。這類依賴不應納入 readiness，改用 circuit breaker 或 fallback 處理。
• 觀測依賴：metrics collector、log shipper——不可用不影響業務流量。這類依賴進 readiness 是常見誤判，會讓觀測基礎設施故障擊倒整個服務。

對應 5.C3 Orbitera managed K8s migration：揭露「跨平台遷移本質是能力遷移、部署 / 觀測 / 恢復與團隊流程都需要同步重建」。遷移到新平台時，舊平台的 readiness 條件不能直接搬——新平台的依賴可達路徑、DNS 解析速度、secret 注入方式可能改變，readiness 條件要重新驗證。

Liveness 與 Restart

liveness 的責任是偵測無法自我恢復的狀態。短暫下游故障適合交給 readiness、circuit breaker 或 fallback 處理，否則平台會用重啟放大故障。

liveness 太敏感會造成 restart loop；liveness 太寬鬆會讓壞實例長期留在線上。設計時要先定義哪些錯誤可由服務內部恢復，哪些才需要平台重建。

Liveness 適合偵測的失敗模式

liveness 的工程價值在於捕捉服務自己無法修復的狀態。把 liveness 當成通用健康檢查是過度使用，會讓正常的瞬態故障觸發不必要的重建。

適合 liveness 偵測的狀態：

• deadlock：所有 worker thread 被卡住，無法處理新請求也無法回傳錯誤。liveness endpoint 設在獨立 goroutine / thread 上，如果 worker pool 卡住但 liveness goroutine 能回應，問題在業務邏輯而非 deadlock。
• memory leak 導致的 OOM 前兆：記憶體使用率持續上升不回落，GC 已無法回收。此時主動回報 unhealthy 讓平台在 OOM kill 前重建，比被動等 OOM 更可控——OOM kill 不走 graceful shutdown，在途請求直接中斷。
• essential background task 永久停止：必要的定期任務（如 license renewal、session cleanup）超過預期間隔仍未執行。這類失敗靜默發生，只有 liveness 主動偵測能發現。

不適合 liveness 偵測的狀態：下游資料庫短暫不可用、外部 API timeout、cache miss 率升高。這些由 readiness 或 circuit breaker 處理——用 liveness 重建不會修好下游，只會用重啟放大問題。

Restart 的代價量化

每次 liveness 觸發的重啟會產生四類代價：

1. 在途請求中斷：被重啟的實例正在處理的請求直接失敗。
2. 連線重建成本：資料庫連線池、cache 連線、queue consumer 重新建立。
3. 啟動期間的容量缺口：重啟到 readiness 通過之間，整體服務容量降低。
4. thundering herd 風險：多實例同時被 liveness 判定失敗並重啟時，同時重建連線、同時搶資源、下游壓力瞬間放大。

對應 5.C7 Airbnb Istio 升級治理：揭露「基礎平台元件升級若缺乏分批治理、會形成全域風險放大器」。以下基於通用工程知識展開：Istio 等 service mesh 升級期間的 sidecar 重啟可觸發大量服務的 liveness 暫時失敗，若 liveness 太敏感會放大成全域 restart storm。升級期的 liveness 閾值應比穩態更寬鬆，或在升級批次中暫時加大 liveness failure threshold。

Shutdown 與 Drain

shutdown 的責任是讓服務停止接新工作並完成資源釋放。draining 的責任是讓平台在移除實例前，讓 in-flight request、長連線或背景工作有時間收束。

短 request API、長連線服務與 background worker 的 drain 條件不同。短 API 主要看在途請求歸零；長連線看 reconnect 節奏；worker 看已領取工作能否完成或重新排隊。tunnel 入口的 startup / readiness / drain 對齊見 5.10 Outbound Tunnel 入口。

三種 Workload 的 Drain 差異

不同 workload 類型的 drain 完成條件與時間尺度完全不同，用同一套 drain 設定覆蓋所有 workload 會在至少一類服務上出事。

短 request API（HTTP REST、gRPC unary）：drain 窗口通常在 5-30 秒。核心條件是在途請求數歸零。風險點是 load balancer 的 deregistration delay——LB 可能在服務已標記 not-ready 後仍送幾秒流量（取決於 health check interval 與 deregistration delay），所以服務端 drain 窗口要覆蓋這段延遲。endpoint 摘除的傳播窗口與 preStop 等待策略見 5.4 摘除節奏與 Drain 的配合。

長連線服務（WebSocket、gRPC streaming、SSE）：drain 窗口通常在 30 秒到數分鐘。核心條件是現有連線收斂且 reconnect 波形穩定。風險點是客戶端 reconnect 策略——服務端 drain 完成不代表客戶端已連上新實例。若客戶端沒有 backoff 或 reconnect 目標選擇邏輯，會形成 reconnect storm。drain 設計要跟客戶端 reconnect 策略一起規劃。

Background worker（queue consumer、定時任務、batch job）：drain 窗口取決於單一工作的最長執行時間。核心條件是已領取的工作完成處理或安全重新排隊。風險點是不可中斷工作——某些 job 做到一半無法重試（例如外部 API 呼叫已發出但回應尚未確認），drain 時序要覆蓋這類 job 的最長完成時間，否則 job 被中斷後產生不一致狀態。

對應 5.C9 反例：平台切流未先 Draining：揭露「切流失敗常在 connection lifecycle 管理」「drain / idle timeout / health check / client retry 沒有同一節奏」。反例中的事故擴大機制正是不同 workload 類型的 drain 條件被忽略——短 API 的 drain 完成了，長連線的 reconnect 仍在震盪，worker 的 job 被中斷重試造成重複處理。

Shutdown 信號的傳遞路徑

platform 到 application 的 shutdown 信號傳遞有多個可能斷點。信號從平台送到容器 PID 1、PID 1 轉發到應用進程——PID 1 的信號處理語意與常見陷阱見 5.1 PID 1 與信號處理。本段聚焦 lifecycle 層的時序問題：

• preStop hook 與 SIGTERM 時序：Kubernetes 先執行 preStop hook、再送 SIGTERM。preStop hook 可用來等 LB 摘流量（sleep 幾秒讓 endpoint 從可用集合移除），讓 SIGTERM 到達時在途流量已經減少。
• terminationGracePeriodSeconds：平台等待的最長時間。超過後 SIGKILL 強制結束，不走 graceful shutdown。這個值要覆蓋 preStop + drain + 資源釋放的總時間。

shutdown 信號傳遞的驗證方式是在 staging 環境觸發 pod delete，觀察應用 log 中是否出現 shutdown handler 的紀錄。沒看到 shutdown log 代表信號沒傳到、要先修傳遞路徑再談 drain 設計。

不同 Workload 的 Lifecycle 特性對照

生命週期合約的參數設定要依 workload 類型調整。以下是三類常見 workload 的特性差異。

這張表是選型前判準的操作化：先確認服務屬於哪類 workload，再套用對應的 lifecycle 參數基線。混合 workload（例如同時提供 HTTP API 和 WebSocket）要取各層的嚴格值——drain 窗口取最長的、readiness 取最嚴格的。

平台如何表達 Lifecycle 差異

不同部署平台表達生命週期合約的能力不同。選型時要問的是「這個平台能不能分別設定 startup、readiness、liveness 與 drain」。

Kubernetes 在 lifecycle 表達力上最完整，但參數最多也最容易配錯。systemd 靠 sd_notify 協議明確宣告 readiness，在單機部署場景下反而比 K8s 的 probe 直接。Docker 和 ECS 不分離 readiness 與 liveness，需要在應用層自行實作降級邏輯。

選平台不只看功能清單，要看它表達 lifecycle 差異的粒度是否覆蓋服務需求。若服務需要分離 startup 和 readiness 但平台只有一個 health check，這個差距要在應用層補——代價是複雜度從平台設定轉移到程式碼。

遷移期的 Lifecycle 重新驗證

對應 5.C6 Airbnb Kubernetes 叢集擴縮演進：揭露「擴縮策略版本化與可回放」「不同 workload 區分擴縮政策」。以下基於通用工程知識展開：叢集演進過程中，lifecycle 參數的假設會改變——workload 從穩態變成高波動、從單一類型變成混合類型、從小規模變成大規模。lifecycle contract 的參數不是設一次就好，要隨叢集演進重新驗證。

對應 5.C10 對照：規模差異下的平台遷移：揭露「小型組織最容易漏掉回退腳本化」「中型組織依賴錯位、服務切過去但資料面 / 認證面 / 觀測面沒同步」。lifecycle contract 在遷移後的完整性驗證不只看 probe 設定——secret 注入時序、資料庫連線池的 endpoint 是否切到新叢集、observability pipeline 的 readiness 是否對齊，都是 lifecycle 合約的一部分。

遷移後的 lifecycle 驗證清單：

1. startup 時序重測：新平台的 image pull 時間、secret mount 時間、DNS 解析路徑可能不同，原本的 startup timeout 可能不夠。
2. readiness 依賴路徑檢查：readiness 檢查的依賴是否仍可達（新叢集到舊資料庫的 latency 是否增加、跨叢集 service discovery 是否對齊、DNS TTL 與快取行為是否改變）。
3. drain 行為驗證：在新平台觸發 pod delete、觀察 drain 完成時間與在途請求處理是否符合預期。
4. 信號傳遞驗證：在新平台觸發 shutdown、確認 SIGTERM 到達應用進程並觸發 graceful shutdown handler。

選型前判準

部署平台選型前要先回答：

1. 服務啟動需要多久，哪些依賴是 readiness 條件。
2. 服務失敗時應由自己恢復，還是由平台重建。
3. 服務停止時有哪些 in-flight request、connection 或 job。
4. 平台是否能表達 startup、readiness、liveness 與 drain 的差異。

這些問題決定後續要比較 Kubernetes probe、systemd restart policy、load balancer health check 或 service mesh drain 能力。

判讀訊號

常見誤區

把所有 probe 設成同一個 /health endpoint，會讓 startup、readiness 與 liveness 的語意混在一起。三種 probe 回答不同問題：startup 問「初始化完了嗎」、readiness 問「可以接流量嗎」、liveness 問「還活著嗎」。同一個 endpoint 無法同時回答三個問題，因為初始化完成不代表依賴就緒，依賴暫時不可達不代表服務本身壞了。

把 drain 窗口設成固定值不分 workload 類型，會在某一類服務上出事。5 秒對短 API 足夠、對長連線不夠、對 batch job 遠遠不夠。drain 窗口要依服務實際 workload 設定，不是用平台預設值。

把 liveness 失敗當成「服務壞了」而不問代價，會忽略重啟本身的連鎖效應。每次重啟都有在途請求中斷、連線重建、容量缺口的代價——特別是多實例同時被判定 liveness 失敗時，代價會被放大。

案例回寫

lifecycle contract 的完整性可用多個案例交叉驗證。5.C3 Orbitera managed K8s migration 揭露遷移後 readiness 依賴路徑改變的風險。5.C9 反例 揭露不同 workload 的 drain 條件被忽略造成的事故擴大。5.C7 Airbnb Istio 升級治理 揭露基礎平台元件升級缺乏分批治理會形成全域風險放大器。5.C10 對照 揭露不同規模下 lifecycle 驗證的缺口模式。

這些案例共同支撐的判讀是「lifecycle contract 的每個狀態都有不同的失敗模式，混在一起處理會在事故時無法定位」。流量切換或連線生命週期問題路由到 5.3 load balancer 合約。runtime 產物穩定性問題路由到 5.1 container 與 runtime。

跨模組路由

lifecycle contract 是部署模組的概念基底，後續章節都會引用本篇的狀態分類。

1. 與 5.1 的交接：runtime 與 entrypoint 定義 startup 行為回到 container 與 runtime。
2. 與 5.2 的交接：probe 設定與 rollout 節奏回到 Kubernetes 部署策略。
3. 與 5.3 的交接：drain 與流量退場回到 load balancer 合約。
4. 與 5.10 的交接：tunnel 入口的 readiness 與 drain 對齊回到 Outbound Tunnel 入口。
5. 與 4.20 的交接：lifecycle 事件的證據收集回到 Observability Evidence Package。
6. 與 6.8 的交接：lifecycle 狀態作為 release gate 判定條件回到 Release Gate。

下一步路由

要看 Kubernetes 如何承接這組生命週期，接著讀 5.2 Kubernetes 部署策略。要看流量退場如何和 LB 對齊，接著讀 5.3 load balancer 合約。要看不同平台的 lifecycle 表達力比較，接著讀 vendors/。

Traffic Boundary

Traffic boundary 的責任是決定 request 如何進入服務、如何分流、如何回退。它包含 load balancer、routing rule、health check、sticky session、timeout 與 drain。

流量切換要能回答三個問題：哪一批 request 會到新版本、失敗時如何停止擴批、舊版本是否仍能承接回退流量。這三個答案明確後，canary 才能從比例設定變成可回退策略。

Traffic boundary 的判讀重點是 customer impact 如何被分批限制。小比例 canary、區域切流、tenant 切流與 route rule 都是不同切換單位；切換單位越清楚，rollback window 越容易被驗證。

切換單位的選擇

切換單位決定故障的 blast radius 與回退的精準度。常見切換單位各有不同操作特性：

比例切換最簡單但 blast radius 不可控——5% 的流量中可能包含大客戶的關鍵路徑。租戶切換精準度最高但操作複雜度也最高——需要在 routing 層維護租戶到版本的映射。穩定做法是從比例切換開始，遇到需要精準控制 impact 時再升級到租戶或路由規則切換。

Config Boundary

設定如何下發、如何生效、如何回退——Config boundary 回答這三個問題。config rollout 和應用版本不一定同步，因此要保留相容窗口。

高風險設定包含 payment provider endpoint、feature flag、rate limit、routing rule、timeout 與 fallback policy。這些設定變更可能不需要新 image，卻能改變 production 行為，因此要進 release gate。

Config 變更的風險分級

設定變更的風險不一致——有些設定改了只影響 log level，有些設定改了直接影響付款路徑。分級後才能對不同風險的設定套用對應的 review 與 rollout 強度。

風險分級的判讀依據是「這個設定改錯時、使用者會看到什麼」。改錯 payment endpoint 會讓付款打到錯誤目標；改錯 rate limit 可能讓合法流量被擋；改錯 log level 最多是 log 太吵或太安靜。設定的注入方式與版本追蹤見 5.1 配置注入方式與取捨。

Secret Boundary

Credential、token、certificate 與 machine identity 需要可輪替、可稽核、可回退——Secret boundary 管理這組生命週期。Secret 變更同時影響平台、應用與外部依賴，應使用比普通 config 更嚴格的 evidence 與 rollback window。

Secret rollout 要回答版本相容、雙軌驗證、舊 secret 撤除時間與失敗回退。這裡要接到 7.27 Credential Rotation with Scoped Evidence。

Secret Rollout 的雙軌驗證

Secret 輪替跟應用版本部署有本質差異：rollback secret 不是「換回舊版本」那麼單純——舊 secret 可能已經被撤銷、過期、或在外部系統中標記為失效。Secret rollout 的安全做法是雙軌驗證：

1. 新 secret 先加入、舊 secret 暫不移除：應用先驗證能用新 secret 正常運作。
2. 觀測窗口確認新 secret 穩定：auth 成功率、API 呼叫成功率、certificate handshake 成功率都在 baseline 內。
3. 確認後移除舊 secret：舊 secret 的撤除要有明確時間點，而且要在撤除前確認沒有服務還在用舊 secret。

這個流程的風險點是第 3 步：撤除舊 secret 後發現某個遺漏的服務或 job 還在用、導致該服務認證失敗。盤點覆蓋率的做法是在觀測窗口內搜尋 audit log，確認所有 secret 使用都已切到新版本。

Service Discovery Boundary

Service discovery 的責任是維持可用 endpoint 集合。它回答服務應該連到哪些實例；業務設定與版本正確性則分別交給 config boundary 與 rollout gate。Discovery 的 DNS / registry 運作模式與註冊時序見 5.4 Service Discovery。

Discovery 失準常見於 rollout、擴縮容與區域故障。判讀時要拆成註冊時序、健康判斷、DNS/registry 新鮮度與 fallback 存活時間。

Control Plane Boundary

設定、策略、部署與路由規則的管理落在 management plane。Control plane 變更會影響大量服務，因此需要更嚴格的 evidence、gate 與 decision log。

Control plane 事故常見於規則推送、routing 誤配、secret 下發失敗與 registry 異常。這類事故要先保留 decision timeline，避免事後只看到資料面錯誤率。

Control Plane 變更的 Blast Radius 控制

Control plane 變更的 blast radius 跟 data plane 變更不同——一條 routing rule 推送錯誤可能同時影響所有服務的流量。控制 blast radius 的做法：

1. 分批推送：規則變更先推到 staging / canary namespace、驗證後再推到 production。推送結果的觀測應包含受影響服務的 error rate 與 latency。
2. approval gate：高影響變更（network policy、admission webhook、RBAC binding）需要多人 review。變更的 blast radius 估算（影響多少 namespace / service）應在 review 時可見。
3. decision log：所有 control plane 變更記入 8.23 Control Plane Decision Log，包含時間、操作者、受影響範圍、預期效果與回退條件。事故時對照 decision log 跟 data plane 症狀的時間序列，可以快速判斷因果。

平台元件升級的可重播流程

平台基礎元件升級是 control plane 風險最高的場景。Service mesh、ingress controller、CNI、API server 這類元件影響面廣、單次升級可能形成全域風險放大器。

對應 5.C7 Airbnb Istio 升級治理：揭露 1 個判讀（基礎平台元件升級缺乏分批治理會形成全域風險放大器）+ 3 條策略（分批升級 + 回退窗口、升級驗證標準固定化、升級事件接入 incident command 節奏）。以下基於通用工程知識展開、「升級事件進 timeline」是從 case「接入 incident command」策略進一步推到具體操作。

可重複套用的升級流程：

1. 分批升級單位：先在開發 / staging 叢集驗證、再選低流量 production 叢集 / namespace 作為先導、之後分批擴大。分批單位可以是叢集、namespace、region、tenant，依風險面選擇。
2. 回退窗口跟驗證標準同時設：每批升級前定義「驗證通過」的具體訊號（SLI 維持、特定 metric 不偏移、無新告警），跟「回退窗口」（多久內可以回退）。沒有驗證標準的分批等於連續高風險動作。
3. 升級流程紀錄到 incident-style 文件：升級期間的決策、觀察、停止點都用 incident decision log 格式紀錄。下次升級可重播、不依賴執行者個人經驗。
4. 升級事件進 timeline：升級本身產生的短暫錯誤、reconnect、配置同步延遲，要在事故 timeline 上可見、避免被誤判成事故。

平台元件升級的核心治理價值是把「一次性高風險作業」變成「可重複的低風險作業」。第一次升級用流程，第二次升級用同樣流程，第三次升級流程已經穩定到可以委派、不再需要資深工程師親自執行。

Managed 平台跟團隊職責邊界

平台託管化（self-managed → managed）改變維運責任跟團隊精力的分配。本段聚焦團隊職責邊界；流量跟依賴的分段切換流程見 5.2 分階段平台遷移、紅隊視角的攻擊面變動見 5.5 平台遷移期的攻擊面變動、三者組合才完整。

Platform team 從「維持 Kubernetes 跑起來」轉向「定義 release flow、observability convention、cost governance」。managed 平台採用後第一個治理動作是顯式重新定義職責邊界、讓 platform team 從 cluster ops 轉到 release flow / observability convention / cost governance。重新定義缺位、組織轉型紅利容易被誤判為純技術升級。

對應 5.C5 Miro Managed EKS 遷移：揭露 1 個判讀（平台託管化的價值在讓團隊把心力從底層維護轉到交付效率與可靠性策略）+ 3 條策略（先定義遷移後的平台責任邊界、自動化流程取代手動平台操作、incident 跟 release policy 接回平台治理）。對應 9.C33 Maersk + Bosch Azure AKS：揭露 Maersk 工程訴求引語「focus on things that makes the most business impact」、傳統產業 K8s 動機是治理一致性 + 釋放工程資源到業務功能（後者屬作者判讀）。以下基於通用工程知識展開。

managed 平台採用後的職責邊界重訂可以分四層：

1. Cluster 層：control plane 上游接管（API server、etcd、scheduler、controller-manager）、platform team 從 cluster ops 退到 cluster policy。CIS benchmark、network policy、admission controller 配置仍是 platform 責任。
2. Cluster-internal 層：CNI、ingress controller、service mesh、cluster DNS、storage CSI 通常仍由 platform team own。這層是 managed 服務沒覆蓋的 grey zone、需要明確 ownership。
3. Application 層：deployment、service、HPA、PDB 由 service team own、platform 提供 convention 跟 review process。
4. 跨層議題：cost governance、observability convention、release flow、incident response 是 platform / service / SRE / finance 跨層協作、需要 operating model 明確化。

managed 採用後 day-1 治理項目有兩件事：明確界定 grey zone ownership（避免「以為 managed 服務什麼都管了」的心智模型）、把 platform team 心力從 cluster ops 轉到組織轉型紅利（release flow、observability convention、cost governance）。把重新定義職責當 day-2 議題、會錯失組織轉型紅利。

選型前判準

平台選型前要先回答：

1. 哪些變更屬於 traffic，哪些屬於 config，哪些屬於 secret。
2. 每種變更是否能分批、暫停與回退。
3. Discovery 失準時是否有可控 fallback。
4. Control plane 變更是否有 audit、owner 與 blast radius 限制。
5. 基礎元件升級是否有可重播流程跟回退窗口。
6. Managed 平台採用後團隊職責邊界是否重新定義。

這些答案決定後續要比較 load balancer、service mesh、secret manager、service registry 或 deployment controller 的能力。

實體服務討論承接點

實體平台文章要承接本篇的 traffic、config 與 control plane boundary。ELB、nginx、Envoy、service mesh、Consul、Kubernetes controller、secret manager 或 Terraform 的比較，要先分清它們是在資料面接流量、在控制面改規則，還是在設定面下發狀態。

若主問題是流量切換，後續文章要比較 routing rule、weight、health check、drain 與 rollback。若主問題是設定與 secret，後續文章要比較 rollout、audit、rotation 與相容窗口。若主問題是 control plane 風險，後續文章要比較 blast radius、approval、observability 與 incident decision log。

下一步路由

要把流量邊界接到實際 LB 合約，接著讀 5.3 load balancer 合約。要把 control plane 決策寫入事故流程，接著讀 8.23 Control Plane Decision Log and Write-back。

本篇以 5.2 Kubernetes 部署策略 與 5.3 load balancer 合約 為前置知識——rollout 批次、probe 對齊、drain contract 等概念在該兩篇定義，本篇直接操作化。lifecycle 狀態的完整定義見 5.6 Platform Lifecycle Contract。

服務路徑與切換責任

這條路徑是 client -> load balancer -> checkout-api -> payment provider/order db/order event。部署期間新舊版本會同時承接流量，核心風險在流量生命週期是否可收斂，image 替換本身反而是最可預測的部分。

切換責任分三層：

1. 版本可啟動：container/runtime/config 可用。
2. 版本可接流量：readiness 與依賴狀態對齊。
3. 版本可退場：drain 與在途請求可收束。

Preflight：先驗證可服務基線

Preflight 的責任是把「可啟動」與「可服務」拆開驗證。最小檢查包含：

1. image 與 runtime config 版本對齊。
2. secret 已注入且權限正確。
3. startup/readiness probe 能反映真實依賴狀態。
4. load balancer contract 參數與服務期望一致。
5. service discovery 註冊與摘除路徑可用。

Preflight 失敗時不進 canary。先把失敗收斂在控制面，避免切流後才發現版本不可服務。

Preflight 自動化

手動 preflight 在低頻部署時可行，部署頻率上升後會成為瓶頸或被跳過。穩定做法是把 preflight 檢查嵌入 CI/CD pipeline 的 pre-deploy stage：

1. image 與 config 版本對齊檢查：pipeline 比對即將部署的 image tag 與 ConfigMap / Secret 版本是否在相容矩陣內。版本矩陣可維護在 git（如 deploy/compat-matrix.yaml），CI 自動比對。
2. infra drift detection：部署前用 IaC 工具（Terraform plan、Crossplane drift check）掃描目標環境的實際狀態是否跟宣告狀態一致。drift 存在時暫停部署——在已漂移的環境上部署新版本，會把漂移與版本變更的影響混在一起，事故時無法分辨根因。
3. probe 語意驗證：在 staging 環境對新版本觸發 startup → readiness → liveness 全流程，確認 probe 回應與依賴就緒條件吻合。這步抓的是 probe 設定退化（如 readiness endpoint 被改成永遠回 200）。
4. rollback 可行性驗證：確認舊版本 image 仍在 registry 且可拉取、舊版本 config 仍相容。rollback 能力在 preflight 階段驗證，比事故時才發現「舊版拉不到」代價低得多。

Preflight 自動化的產出是一份 go/no-go 報告，進入 6.8 Release Gate 作為放行依據。pipeline 中的 preflight stage 失敗應阻擋部署而非產生警告——可忽略的 preflight 等於沒有 preflight。

Canary Batch 與 Stop Condition

小流量先驗證新版本行為，再決定是否擴批——Canary 回答的是「這個版本值不值得擴大」。

canary 判讀要維持 per-version 視角。只看整體服務平均值會掩蓋新版本局部退化。

Traffic / Drain：把退場變成可驗證流程

Drain 的責任是讓舊版本在下線前完成在途請求，不讓 rollout 把短暫切換放大成用戶錯誤。

退場順序：

1. 舊實例 readiness 先轉 not-ready 停接新流量。
2. 保留 drain 窗口完成 in-flight request。
3. 確認連線數下降到門檻後再終止進程。
4. 驗證無異常 reconnect 尖峰再進下一批。

Drain 條件的完整 workload 分類回到 5.6 Platform Lifecycle Contract，本段以 checkout service 為例：短 API 的 draining 窗口可短，長輪詢與 webhook callback 要更保守。

Rollback Compatibility

舊版本回來時仍可運作，是 rollback 能成立的前提——回退如果變成第二次故障，就失去了回退的工程價值。

要先驗證四個相容面：

1. config 相容：新設定不會讓舊版啟動失敗。
2. schema 相容：資料結構仍可被舊版讀取。
3. cache key 相容：舊版可讀新快取或有 fallback。
4. event schema 相容：舊版 consumer 不會因新事件欄位崩潰。

若這四項未完成，所謂 rollback 只會停在「版本回切」，無法恢復服務正確性。

Evidence Package

每一批切換要可被判讀、可被追責、可被回放——部署 evidence 支撐這三個條件。

這份 evidence 要對齊 4.20 Observability Evidence Package。

Release Gate

Release gate 的責任是決定下一批切換與是否凍結 rollout，不是報告「目前看起來正常」。

這組欄位要對齊 6.8 Release Gate。

Incident Decision Log

freeze rollout、rollback version、隔離 region、延長 drain 都屬事故決策，需寫入 8.19 Incident Decision Log。涉及流量規則 / control plane 設定推送的決策、見 5.7 跟 8.23 Control Plane Decision Log。

 1incident_decision:
 2  timestamp: 2026-05-11T15:06:00Z
 3  decision: "freeze rollout at 25% and rollback one region"
 4  context: "new version timeout to payment provider increased in ap-northeast"
 5  evidence:
 6    - query: checkout_error_rate_by_version_region
 7    - query: payment_timeout_ratio_by_region
 8  owner: release-incident-commander
 9  expected_effect: "contain customer impact and restore baseline success rate"
10  rollback_condition: "timeout ratio does not recover after rollback batch completes"

Case Write-back 與邊界

這篇回寫對齊 5.C9 反例、5.C1 Tradeshift 與 5.C3 Orbitera：前者看切換失序，後兩者看遷移路徑與回退策略。preflight / canary / drain 各階段的生命週期定義回到 5.6 Platform Lifecycle Contract。

這篇不處理 schema migration 本身、cache stampede 或 queue replay。若核心風險在資料正式狀態、快取回源或事件恢復，路由到 1.7 Schema Migration Rollout 證據、2.9 Cache Migration 與 Stampede Rollback 或 3.8 Queue Consumer Retry 與 Replay Handoff。

三層快取的責任分工

CDN、應用層快取與資料層快取串成一條快取分層。每一層各有自己的 freshness 模型、失效路徑與失敗代價，需要各自設計策略。

讀者實作時要先判斷需求屬於哪一層。把使用者頭像、商品圖片、活動 banner 放邊緣層；把熱門商品價格、會員等級放應用層；DB 自身的 buffer pool 留給資料庫引擎管理。混用會造成失效路徑互相覆蓋，事故時難以判斷快取漂移來自哪一層。

Origin Protection 的設計責任

CDN 在規模成長路徑上承擔 origin protection。當 KOL 引流或熱門活動同秒帶入大量請求時，沒有邊緣層遮蔽，origin 的應用伺服器、API gateway 與資料庫會被同步擊穿。邊緣層的責任是讓 origin 流量曲線跟使用者請求曲線解耦。

origin protection 的核心策略包含三個方向：

1. cache hit ratio 優化：把高頻、可共用的內容做成可快取資源（含正確的 cache-control header、ETag 跟 vary 設計）。命中率每提升 10 個百分點，origin 流量幾乎等比例下降。
2. 回源行為控制：edge 沒命中時用 Cache Stampede 保護機制（origin shield 是 CDN 內部多一層中央節點集中回源、coalescing / request collapsing 把同時打進來的 N 個請求合併成一次 origin 呼叫）、避免擊穿。
3. failure fallback：origin 不健康時、edge 可以回傳舊版本（stale-while-revalidate / stale-if-error）、避免使用者直接看到 5xx。代價是 Stale Data 風險暫時提高、需要在 freshness budget 內。

Origin shield 跟 request coalescing 常被混為一談，兩者解決的問題不同。Origin shield 在 CDN 內部插入一層中央節點——全球 edge POP 的 cache miss 先集中到 shield 節點，shield 再向 origin 回源；它解決的是「N 個 edge POP 同時 miss 變成 N 次 origin 請求」的扇出放大。Request coalescing（也叫 request collapsing）在單一節點內把同時到達的多個相同請求合併成一次 origin 呼叫；它解決的是「同一個 edge POP 在同一毫秒收到 1000 個相同請求」的並發放大。兩者是不同層級的保護——shield 跨節點收斂、coalescing 單節點收斂——可以同時啟用形成兩層防線。

這三項決定了「能不能撐住高峰」。三項做齊才能形成保護網；缺項時邊緣層僅能發揮降低延遲的效果。

Cacheable vs Non-Cacheable 的判讀

CDN 適合承接的資源有明確判讀條件：對所有使用者一致、且可容忍短暫舊版。符合這兩個條件的資源放邊緣層收益最高，不符合的留在應用層或 origin 處理。

這張表覆蓋傳統靜態 / 動態二分情境。邊緣層演化出來的中間態超出表格範圍 — 包含 API responses with short TTL（GET、idempotent）、SSR / SSG 混合頁、signed URL / per-user 私有 asset（CloudFront / Cloudflare 可帶簽章對特定 user 快取）、i18n / 地理變體用 Vary header 處理跨 locale 共用、以及 edge personalization / edge compute（Cloudflare Workers、Lambda@Edge、Akamai EdgeWorkers）。進入這層要評估 edge compute 成本與 cache key 設計複雜度、不是簡單套表決定。

判讀後仍要再對齊 freshness：商品價格在限時活動期間每 5 分鐘改一次，10 分鐘 TTL 就會出現超賣或顯示差價。這類情境要把價格放應用層快取、頁面結構放 CDN，整頁邊緣化會超出 freshness budget。

Purge 與 Invalidation 的操作模型

CDN 的 Cache Invalidation 跟應用層的失效路徑不一樣：應用層 purge 在自家 cluster 內可控，CDN purge 要等全球節點同步。傳統 origin-pull CDN 的全球 purge 需要數秒到數十秒；現代 push-based CDN（Cloudflare、Fastly 等）的 instant purge 在 150ms 級別、語意接近同步、但這條能力依 vendor 而異、要事前驗證。

操作上的三種策略各有適用場景：

• TTL 自然過期：適合內容變動慢、不需要立即生效的資源。優點是不依賴 purge API，缺點是無法應對緊急下架。搭配 stale-while-revalidate 後可以兼顧低 origin 壓力與最終新鮮度、是現代 default 而非「弱版本」。
• 顯式 purge：適合內容變動時要立刻生效的場景（價格更新、文章下架、合規移除）。要把 purge 列入發布流程，事故期能在分鐘內收回錯誤內容。
• 版本化路徑：適合 JS/CSS 等可永久快取的資源。檔名含 hash（app.a3f1b2.js），新版本上線時直接換路徑、舊版本自然失效。這是命中率最高的策略，因為可以設定 max-age=31536000, immutable。

這三種策略以 origin pull 模型為主、是基底但不窮盡。現代 CDN 還有兩種重要策略需要展開。

Tag-based Purge 的操作模型

Tag-based / surrogate-key purge（Fastly surrogate key、Cloudflare cache tag、Akamai cache tag）是大型內容系統的事實標準。它解決的核心問題是「一個業務事件需要同時失效多個 URL」——商品下架要同時 purge 商品頁、商品圖、搜尋結果頁中含該商品的快取。

操作流程分三步：

1. 打 tag：origin 在 response header 中標記 tag（如 Surrogate-Key: product-123 category-electronics）。CDN 存快取時同時建立 tag → URL 的反向索引。
2. 按 tag purge：業務系統發出 PURGE tag=product-123 API 呼叫，CDN 用反向索引找出所有帶這個 tag 的快取項目並失效。一次 API 呼叫可能失效數百個 URL。
3. 回源補快取：被 purge 的 URL 下一次被請求時回源、重新快取。搭配 stale-while-revalidate 可以讓第一個回源請求不阻塞使用者。

Tag-based purge 跟顯式 purge（按 URL purge）的本質差異在於「失效單位是業務實體、不是 URL」。按 URL purge 要在業務端維護「一個商品對應哪些 URL」的映射，tag purge 把這個映射交給 CDN 的反向索引。代價是 tag 設計要跟業務模型對齊——tag 太粗（一個 tag 覆蓋太多資源）會過度 purge，tag 太細會退化成按 URL purge。

Push-based instant purge（Cloudflare、Fastly 規格 <150ms 全球同步）讓全球 purge 從「分鐘級」變成「準同步」。選擇策略時要按 vendor 能力跟資源更新模式組合。

選錯策略的代價會在事故時放大。把限時優惠的價格用「TTL 自然過期」策略佈在 CDN、活動結束後仍有客人看到舊價格繼續下單、客服與退款成本會壓回業務端。

判讀訊號

常見誤區

CDN 跟「加速工具」的混淆，會讓 origin protection 跟一致性責任被忽略。多數團隊上線後第一次撞牆，是 KOL 引流或活動高峰把 origin 直接打掛，事後才發現 CDN 只覆蓋了靜態 asset、HTML 與 API 都直接打回 origin。

把 purge 當成同步操作也容易出事。緊急下架觸發 purge 後立刻通知公關「已下線」，但全球節點還沒收斂，仍有區域看到原內容。這類風險要把「purge 已完成」當成可觀測訊號處理，不是 API 回 200 就視為完成。

把 CDN 當成應用層快取替代品則是另一個極端。商品價格、會員等級這類「跟使用者狀態相關」的資料放邊緣層，會在用戶切帳號、優惠變更時暴露其他人的資料或舊狀態，是 Stale Read 的擴大版。

定位邊界

CDN 專注「靜態與半靜態內容的網路層分發」。當問題進入動態 API 的延遲、跨服務一致性、寫入路徑保護，責任分別交給 5.3 load balancer 合約、02 cache aside 與 03 message queue 模組。

跟 07 入口治理 的交接：CDN 同時是公網入口，需要承接 WAF、bot mitigation、TLS termination 等資安責任。邊緣層的安全設定不可遺漏，否則 origin 被繞過直接攻擊。

案例回寫

邊緣分發策略可用以下案例回寫：

• 9.C13 Hotstar：1800 萬同時觀眾的 IPL 直播 — 極端峰值靠多 CDN + origin shield 把 origin 流量壓在容量範圍內。Hotstar 的具體做法是把 hot content（live stream segment）跟 warm content（VOD）分配到不同 CDN provider、利用「edge cache miss 時不是同時打 origin」這條 cache stampede 防禦機制讓 origin 流量曲線跟使用者請求曲線解耦。對照本章「origin protection」段三大策略落地。
• 9.C18 Zoom：COVID 30 倍突發 — 30 倍突發中，登入頁、會議連結頁這類靜態資源由邊緣層吸收絕大部分讀取流量，API 叢集只面對真實的會議建立 / 結束請求。對照本章「Cacheable vs Non-Cacheable 判讀」段：登入頁屬未登入者一致、適合邊緣化；會議內互動屬寫入 API、保持在 origin。
• 2.C7 Cloudflare Cache Reserve 與 Tiered Storage — Cloudflare 在 CDN 內部再分一層 Cache Reserve（持久層）、把 warm 內容從 origin 卸下、避免 edge LRU 淘汰後又回到 origin。對照本章「三層快取」段：邊緣層內部本身也能有 hot / warm 分層、是同一概念的遞迴應用。

三個案例依規模從外向內展開：Hotstar 是極端峰值下 origin protection 防禦的天花板測試、Zoom 是把非交易流量（登入 / 連結頁）分流降低 API 叢集壓力的標準應用、Cloudflare Cache Reserve 則展示 CDN vendor 自身把 hot / warm 內容再分層的內部架構。讀者可串著讀理解規模光譜、也可以挑一條深入。

跨模組路由

1. 與 02 cache aside 的交接：應用層快取與邊緣層的失效路徑要對齊，避免兩層 stale 同時發生。
2. 與 5.3 load balancer 合約 的交接：edge miss 後流量進到 origin LB，超時與重試設定要協調。
3. 與 7.3 入口治理 的交接：CDN 是公網入口，WAF、TLS 與 bot mitigation 在邊緣層落地。
4. 與 9.6 容量規劃 的交接：cache hit ratio 是 origin 容量規劃的核心輸入，命中率假設失準會直接撞牆。

下一步路由

規模成長路線下一站 → 03 模組訊息佇列：邊緣層擋住讀流量後、寫流量與事務鏈的下一塊是非同步化。

其他延伸方向：

• 邊緣失效跟應用層失效串成 invalidation pipeline → 2.2 cache aside 與失效策略
• 高峰活動把 CDN 跟排隊機制組合成保護網 → 9.11 高峰事件準備
• Origin 端的入口流量合約 → 5.3 load balancer 合約

適用判斷

選 outbound tunnel 的前提是「要被外部觸及、但不想暴露公網入口」。典型場景：手機遠端操作自有主機、家庭網路內的服務對外、開發環境臨時對外驗證。服務本身值不值得自建、見 0.21 交付形態選型 的個人自架工具段;這裡只處理「入口形態選了 tunnel 之後」的部署合約。

cloudflared（綁 Cloudflare 邊緣與網域）、Tailscale（綁私有網路 / Funnel 對外）、Boundary 各有定位差異，但入口生命週期的判讀框架相同。

tunnel contract 組成

tunnel 入口合約跟 load balancer contract 對照、差異集中在連線方向與就緒語意：

1. connection contract：本機進程主動對邊緣建立並維持反向隧道、無入站 port;隧道斷線的重連策略決定外部可達性的恢復速度。
2. readiness contract：對外可達 = 隧道已建立 且 後端服務已可服務。兩個條件任一不成立、外部請求就拿到 502 / 連線中斷。
3. ordering contract：啟動順序是後端服務先就緒、tunnel 再宣告 ready;關閉順序相反、tunnel 先收斂停止帶入新流量、後端再退出。
4. auth contract：tunnel 只負責把流量帶回來、本身不是認證。隧道網址是位址、不是密碼 — 任何拿到網址的人都可達後端、所以認證必須疊在 tunnel 之後（見下）。

生命週期與 readiness 對齊

tunnel 入口的就緒判讀比 LB 多一層。LB 的 health check 打後端 instance、通過代表可接流量;tunnel 場景下、「後端 health check 通過」不等於「外部可達」 — 還要隧道本身連上邊緣。readiness 要同時涵蓋兩者、否則會出現「服務自己覺得健康、外面卻連不進來」的盲區。

啟動順序錯位的後果具體：tunnel 比後端早 ready、邊緣開始導流量進來、後端還沒起、外部看到一批 502。所以 startup 階段 tunnel 的 ready 訊號要 gate 在後端 readiness 之後。關閉時序則相反、先讓 tunnel 停止帶入新連線、給在途請求收斂窗口、後端再 graceful shutdown;這層責任跟 5.6 Platform Lifecycle Contract 的 startup / readiness / drain 一致、只是 drain 的對象從 LB 摘流量換成 tunnel 收斂。

穩態維持與重連策略

隧道建立後進入穩態：tunnel 進程與邊緣之間維持長連線，邊緣用心跳（keepalive）偵測連線是否存活。心跳間隔與超時由供應商決定（cloudflared 預設每 5 秒心跳、連續失敗觸發重連；Tailscale 由 WireGuard 層的 persistent keepalive 維持 NAT 映射）。穩態下不需要額外操作，但要理解一個語意：邊緣側判定「連線已斷」到本機進程偵測到斷線之間有延遲，這段時間外部請求會 timeout 而非立即拿到錯誤。

連線中斷後 tunnel 進程自動重連，重連策略的關鍵是 backoff：首次斷線立即重試、連續失敗拉長間隔、避免在邊緣側故障時打滿重連請求。重連成功後 readiness 要重新驗證——隧道恢復不等於後端仍然健康，特別是斷線期間後端可能已經被別的事件影響。

隧道多連線與冗餘

cloudflared 預設對每個 tunnel 建立 4 條連線到不同邊緣節點（Cloudflare 在不同 data center 的 edge server）。單條連線斷線時，流量自動切到其餘連線，外部使用者感受不到中斷。4 條連線全部斷開才會觸發完全不可達。

Tailscale 的冗餘模型不同：WireGuard tunnel 是點對點連線，沒有多邊緣節點分散。Tailscale 的高可用靠 DERP relay server 做中繼——直連失敗時退到 relay，延遲增加但可達性維持。

這個差異在穩定性預期上很重要：cloudflared 的可達性依賴 Cloudflare 邊緣網路的多點冗餘，Tailscale 的可達性依賴直連品質與 DERP 中繼。選擇時要問「我的網路環境是否穩定到不需要多連線冗餘」。

故障模式：network 層與 application 層的分離

tunnel 斷線跟 LB health check 失敗是不同層的故障。LB health check 失敗多半是 application 層（後端掛了、依賴不通）；tunnel 斷線常是 network 層（邊緣連線中斷、本機外連受阻、供應商側問題）、而後端服務本身完全健康。事故判讀要先分清這兩層：後端 log 一切正常、但外部全部連不進來、第一個要看的是 tunnel 進程的連線狀態、不是後端。

這也改變監控訊號的設計。LB 場景看後端 5xx 與 latency 就能覆蓋多數入口問題；tunnel 場景要額外監控隧道本身的連線狀態與重連次數——隧道靜默斷掉時、後端指標一片祥和、唯一的訊號在 tunnel 進程那邊。

故障分類與判讀順序

tunnel 環境下的故障可按層級分類，判讀順序從外到內：

判讀順序的重點是「先確認 tunnel 層是否正常、再往內看」。如果跳過 tunnel 層直接排查後端，會在後端 log 一切正常的情況下浪費時間。

認證必須疊在 tunnel 之後

tunnel 把後端的可達性開到了外部、但它不認證。隧道網址可能從瀏覽器紀錄、分享連結、Referer 外洩、不該被當成安全機制。所以 tunnel 之後必須疊認證閘道、且預設拒絕 — 未通過認證的流量不該觸及後端。

常見的疊法是邊緣與本機各一層：邊緣層（cloudflared 配 Cloudflare Access service token、Tailscale 配 ACL）讓未授權流量在邊緣就被擋、根本到不了本機;本機層（反向代理驗共享密鑰 / basic auth）作為邊緣萬一失效的縱深。入口威脅建模見 7.3 入口治理與伺服器防護;單人自用工具的裝置綁定認證見 7.2 單人裝置認證模型。

判讀訊號

常見誤區

把 tunnel 網址當密碼、是最常見也最危險的誤判。網址不好猜不代表是祕密、它會從各種地方外洩、認證要靠 tunnel 之後的閘道、不是靠網址難猜。

把「後端健康」當成「外部可達」、忽略隧道本身是獨立的失效點。tunnel 場景的可達性是後端健康與隧道連線的交集、監控要覆蓋兩者。

把 tunnel 當「永久掛著」的常駐入口、放大暴露窗。自用場景常更適合用時起、用完關 — 暴露窗壓到最小;要常駐時、認證閘道與監控的投資等級要隨之上調。

把 tunnel 供應商視為零停機、不設本機降級預案。tunnel 依賴外部供應商的邊緣網路與協調伺服器，供應商事故期間本機服務完全健康但外部無法觸及。有降級需求的場景要準備替代入口路徑（如臨時開 port + 反向代理），或接受供應商 SLA 決定自身可用性。

跨模組路由

1. 與 5.6 Platform Lifecycle Contract 的交接：tunnel 的 startup / readiness / drain 對齊生命週期合約、只是 drain 對象換成隧道收斂。
2. 與 7.3 入口治理與伺服器防護 的交接：tunnel 作為對外入口的威脅建模與認證疊法。
3. 與 7.6 秘密管理與機器憑證治理 的交接：tunnel 憑證與認證閘道密鑰的保管與輪替。
4. 與 4 觀測 的交接：隧道連線狀態與重連次數要進監控、否則 network 層故障無訊號。

下一步路由

要把 tunnel 入口放進整體生命週期、接著讀 5.6 Platform Lifecycle Contract。要把 tunnel 之後的認證做紮實、接著讀 7.3 入口治理與伺服器防護 與 7.2 身分與授權邊界。判斷服務是否屬於個人自架工具形態、回 0.21 交付形態選型。