健康檢查機制

1）為什麼

健康檢查是防止級聯故障的第一個障礙：它們正確地將節點從旋轉中移出，防止回火風暴，簡化退化並加快恢復，同時保持SLO並降低MTTR。

2）基本檢查類型

Liveness是「活著」的過程（沒有死鎖/泄漏/恐慌）。錯誤→恢復實例。
Readiness-該服務能夠通過目標SLO（提升池、高速緩存、正常依賴資源）來服務流量。此錯誤→從平衡中排除,但不重啟。
Startup-該服務已準備就緒，可以過渡到liveness/readiness（長引導程序，遷移，warmup）。防止過早重啟。
深度健康（域特異性）：業務不變性（利率通過端到端,存款從活動的PSP授權）。用於降級信號，但不用於立即重新啟動。
外部/合成：外部活動ping （API路徑,前腳本,PSP/KYC）-測量用戶可用性。

3）樣品設計： 一般規則

1.廉價的生活：不適合外部依賴；檢查事件循環，heap/FD，看門狗。
2.通過SLO進行準備：檢查維護所需的本地資源（DB池、高速緩存、限制）。外部依賴關系-通過非鎖定「can-serve？」信號。
3.Latency-budget：每個樣本都有自己的SLA（例如≤100 -200 ms）；超過時-「degraded」，但不是5xx on liveness。
4.Backoff＆Jitter：采樣間隔5-15秒，超時1-2秒，具有指數誤差延遲，以避免同步風暴。
5.滯後：N成功的/錯誤的響應以改變狀態（例如，「successThreshold=2」，「failureThreshold=3」）。
6.轉化：「/healthz」，「/readyz」，「/startupz」的端點穩定；「/health/……」之下的深層檢查，並帶有命名的檢查。
7.沒有秘密和PII：答案只是狀態和短代碼。

8.Explainability： JSON附有子檢查列表：「{」status「：」degraded「, checks」： ［{「name」：「db」, ok「： true」, latencyMs「：18}{」name「：」psp。eu","ok":false,"reason":"timeout"}]}`.

4）按層進行深度檢查的示例

4.1 DB/緩存/存儲

DB：對讀副本和池檢查進行簡短的「SELECT 1」事務處理；latency/replic-lag閾值。
緩存：「GET」/「SET」測試密鑰+命中率後衛（低命中→警告）。
對象存儲：現有對象的HEAD（無下載）。

4.2個隊列/流媒體

經紀人：本地分區內ping-topic publish+consume；consumer-lag閾值。
DLQ：窗口後面的死信中沒有消息激增。

4.3外部提供商（PSP/KYC/AML）

PSP：輕量級auth-probe（非金錢），合同/證書/配額驗證；如果沒有安全樣本-使用代理指標（銀行/GEO 5-10分鐘授權成功）。
KYC/AML：健康API和SLA隊列；降解-切換到備用流/提供程序。

4.4個API/前端

合成：EU/LATAM/APAC中的交易路徑（登錄→存款啟動→「沙子」費率）。
RUM信號：JS/HTTP和LCP/TTFB誤差比例是「外部」觸發器。

5）與平臺集成

5.1 Kubernetes / Cloud

「startupProbe」保護引導程序（遷移/緩存扭曲）。
「livenessProbe」是極簡主義的；「readinessProbe」考慮了池/緩存/本地隊列。

Параметры: `initialDelaySeconds`, `periodSeconds`, `timeoutSeconds`, `failureThreshold`, `successThreshold`.

PodDisruptionBudget和maxUnavailable，考慮到準備就緒。
HPA/KEDA：按隊列/SLI縮放；準備就緒會影響路由。

5.2 平衡器/網關/mesh

L7級健康路線（HTTP 200/429/503 semantics）。
Outlier檢測（envoy/mesh）：從池中取出錯誤率/後置註釋。
電路斷路器：同時查詢/依賴連接限制，與健康信號集成。

5.3自動滑行和退化

Readiness=FALSE →流量被刪除,但pod還活著（可能曬黑）。
Deep-degrade （PSP） → graceful模式的特征標記（例如,暫時隱藏付款方法,啟用待機室）。

6）超時和休假政策

超時<SLO預算：同步依賴性的「timeout=min（⅓ p99，1-2s）」。
相等性：retrais強制性；使用idempotency-keys。
指數backoff+jitter：防止同步軸效應。
Retray預算：caps per-request/tenant，保護「retry-storms」。

7）狀態信號與警報

綠色/黃色/紅色：服務行列上的摘要狀態。
SLO上的燒傷率差：快速（1小時）和緩慢（6-24小時）。
Correlation-hints：關於發行/幻燈片/計劃工作的標記。
Auto-actions：在「紅色」深度檢查中,啟用後退提供程序,提高軌道采樣。

8） iGaming的智能策略

薪資準備就緒：投註服務的可用性考慮到PSP 路由器的狀態和銀行/GEO的限制。
Odds/Lines publishing： Publischer 的就緒性取決於按線路來源和分發到緩存/edge的時間順序的摘要。
Tournament spikes：更激進的outlier檢測和等待室的臨時策略。

9）反模式

進入DB/PSP的Liveness →在外部問題上大規模重啟。
單個「通用」健康端口，不分開startup/readiness/liveness。
強硬的超時沒有後衛/噴氣機→暴風雨。
缺乏滯後→阻塞路由。
觸發重啟的深度檢查（其目標是診斷和路由，不重新啟動）。
在健康殘局中隱藏5xx（掩蓋真實狀態）。

10）接口模板

/startupz → `200 OK {"uptimeSec":..., "version":"..."}`

檢查：init腳本，遷移完成，密鑰和configs加載。

/healthz (liveness) → `200 OK {"heapOk":true,"fdOk":true,"eventLoop":"ok"}`

檢查：事件周期，過程資源，沒有恐慌/國旗。

/readyz (readiness) →

`200 OK/503 {"canServe":true,"db":{"ok":true,"latencyMs":12},"cache":{"ok":true},"queue":{"ok":true,"lag":0},"localQuota":{"ok":true}}`

/health/payments (deep) →

`200/206/503 {"psp.eu":{"ok":false,"reason":"timeout"}, "psp.alt":{"ok":true}, "routerMode":"failover"}`

11）健康循環質量指標（KPI/KRI）

從「NotReady」到「Ready」（warmup-SLO）的發布時間。
「flapping」 readiness per服務的頻率。
錯誤重新安排的pod （root-cause-外部依賴）的百分比。
MTTR事件，其中健康機制發揮了作用（之前/之後）。
不涉及呼叫的自動失誤/功能分類的比例。
合成vs RUM（假陽性/失誤）的準確性。

12）實施路線圖（4-8周）

奈德。1-2：關鍵路徑清單；分離起點/liveness/準備；引入JSON反應與下檢查和滯後。
奈德。3-4：添加深度檢查：DB/緩存/經紀人；2-3 GEO中用於登錄的合成/存款/投註；在/mesh網關中啟用outlier檢測。
奈德。5–6: payment-aware readiness и PSP-fallback;前面的服務室；通過拉格/隊列進行自動滑行；按燃燒率計算。
奈德。7-8： chaos days（禁用PSP/DB復制副本）,backoff/jitter檢查；超時，PDB；KPI報告和調整。

13）文物

健康規格（按服務）：檢查清單、時間預算、滯後、紅色狀態活動。

Runbooks： "Readiness=FALSE：我們做什麼？"，"PSP-fallback：步驟和返回標準。"

路由政策：無處檢測規則，電路斷路器，觸發閾值。
合成劇本：劇本和地理，SLO合成，時間表。
Release Gate：紅色深度檢查關鍵依賴項的發布塊。

結果

精心設計的健康檢查回路是一個分層的信號系統：易於生存以實現過程的可行性，可滿足交通需求的就緒能力，可安全啟動的啟動以及用於托管降解和路由的特定於域的深度檢查。結合自動緩解，斷路器，合成和SLO評分，它降低了級聯故障的風險，減少了MTTR，並穩定了iGaming平臺的業務關鍵路徑。