概念位置

Probe 位在 platform 與 application 之間，讓調度系統知道 instance 是否可接流量、是否仍存活，或是否仍在啟動中。 可先對照 Producer。

可觀察訊號

系統需要 probe 的訊號是啟動、擴容、故障、健康檢查與回收流程需要自動化判斷。沒有 probe，平台只能用硬編碼規則猜測服務狀態。

接近真實網路服務的例子

Kubernetes 會用 probe 決定 instance 是否加入流量池。Readiness probe 檢查能否接流量；liveness probe 檢查 process 是否卡死；startup probe 則可保護啟動較慢的服務。

設計責任

設計時要讓 probe 簡單、快速、穩定，並且只反映它自己的責任範圍。Probe 不應該做昂貴查詢或深度業務判斷，否則平台訊號會不穩定。

概念位置

Startup probe 位在 container 啟動與 readiness / liveness 之間。startup probe 成功前，liveness 和 readiness 不會啟動。startup probe 一旦成功就永久停用，由 liveness 和 readiness 接手。可先對照 Graceful Shutdown。

可觀察訊號

系統需要 startup probe 的訊號是「服務啟動時間超過 liveness 的預設容忍窗口」。典型場景：JVM 服務 warmup 需 30-60 秒、依賴多的服務需要等資料庫連線池和 cache 連線建立。沒有 startup probe 時，liveness 會在初始化期間把健康的服務判定為壞掉，觸發 restart loop。

設計責任

startup probe 的總容忍時間 = failureThreshold × periodSeconds。設計時先量測服務在最差情境下的啟動時間（冷啟動 + image pull + 依賴連線），再加 headroom。startup probe 跟 initialDelaySeconds 解決同一個問題，但 startup probe 在啟動期間持續探測（能偵測啟動失敗），initialDelaySeconds 是盲等（無法觀測啟動進度）。