待寫章節

• Health check endpoint 設計（什麼算健康、什麼算不健康、check 的深度）
• Liveness vs Readiness（活著 vs 準備好接流量 — Kubernetes 的兩種 probe）
• systemd watchdog + 自動重啟（WatchdogSec + Restart=on-failure）
• Process supervisor 的選型（systemd / supervisord / Docker restart policy）
• Graceful shutdown（收到 SIGTERM 後的清理流程）

跨分類引用

• → monitoring 模組四 Dashboard DevOps：DevOps dashboard 的服務狀態卡依賴 health check
• → backend 部署平台：部署平台的 health check 整合

概念位置

Readiness 是 application 與平台之間的流量合約。Application 啟動成功只代表 process 存活；readiness 代表必要設定、連線、migration 狀態、背景初始化、cache warmup 或依賴檢查已達到接流量條件。 可先對照 Redelivery Loop。

可觀察訊號

系統需要 readiness 合約的訊號是部署或擴容期間出現短暫錯誤。常見情境包括 pod 剛啟動就接流量、service discovery 尚未更新、cache 還在 warming、資料庫連線池尚未建立、背景 worker 尚未完成初始化。

接近真實網路服務的例子

Kubernetes rolling update 建立新 pod 後，若 readiness 太早通過，新 pod 可能在還沒載入設定時接到 checkout request。正確的 readiness 會等必要依賴可用、設定載入完成、核心路由可處理後再開放流量。

設計責任

Readiness endpoint 要反映接流量所需的最小條件，並且控制下游短暫波動對流量調度的影響。設計時要分清 readiness、liveness 與深度依賴檢查，讓平台能做穩定調度。

概念位置

Readiness / Health Check 位在 rollout、load balancer 與 runtime platform 之間，是流量切換前的核心 gate。

可觀察訊號

• 部署後健康檢查綠燈但請求仍大量失敗。
• 新版啟動中就提早接到流量。
• rollout 失敗時缺少可觀測放行條件。

接近真實服務的例子

Kubernetes liveness 通過只代表 process 存活；readiness 通過才代表連線池、依賴服務與必要資料都已準備完成。

設計責任

Readiness / Health Check 要定義檢查內容、容錯窗口與失敗處理，讓 rollout decision 有可信訊號。