PSP-X latency & loss
（部分： 技術和基礎設施）
簡短摘要
Chaos Engineering是一種用於生產的科學方法：您提出穩定性假設，以受控的方式破壞環境，並證明保留用戶價值（SLO/業務指標）。對於iGaming來說，這些是支付檢查（PSP），遊戲初始化，引線隊列，多區域和峰值負載-在延遲，故障和「暴風雨」的情況下-在實時用戶發生之前。
1）混沌工程原理
1.從steady-state到假設。定義規範：可用性,p95/p99, TTW,付款轉換。
2.小爆炸無線電。實驗首先在1-5％的流量/1-2 poda/一個區域進行。
3.可觀察性首先。度量/logi/traces+實驗註釋。
4.Guardrails и abort.用於自動停止的剛性SLO/Business KPI閾值。
5.可重復性和自動化。實驗作為代碼（IaC/GitOps），遊戲日計劃。
6.Blameless文化。實驗不是尋找罪魁禍首，而是尋找弱點。
2）Steady-state和成功指標
TexSLI：p95/p99 API，error-rate，aturation（CPU/IO），queue lag（withdrawals/deposits），latency提供商。
商業SLI：「attempt→success」轉換，TTW p 95，「遊戲開始」成功，PSP失敗的代碼比例。
3）實驗類（我們打破了）
網絡：latency/jitter/packet loss/blackhole，DNS故障，MTU異常。
Ресурсы: CPU throttle, memory pressure/OOM, disk IOPS/space, file-descriptor exhaustion.
流程和站點：kill/evict pod, node failure, zone/region failover。
依賴性：PSP計時器/錯誤,遊戲提供商不可用,CDN/緩存降級。
隊列/流媒體：Kafka lag的崛起，消費者的停頓，政黨/領導者的破裂。
數據/數據庫：復制延遲、索引退化、只讀模式。
版本/ficheflags：遷移錯誤，錯誤的configs，kill-switch。
Front/RUM：LCP/INP的下降，客戶在高峰期的崩潰。
數據/ML：老化菲奇，增加後坐力模型，下降tokens/s，質量退化。
4）過程： 從假設到改進
1.提出假設（特定SLO/業務 KPI+預期防禦行為）。
2.設計實驗：故障類型，持續時間，爆炸射線，guardrails/abort。
3.準備可觀察性：「釋放/實驗比較」，註釋。
4.在IM/TL控制下運行,通知電話/業務（如果受到影響）。
5.測量結果：SLO，p95/p99，TTW，轉換，瀉湖，retrai。
6.形成動作項目：極限，定時器，帶噴射器的回放，解開噴射，PDB/HPA/KEDA，回滾流。
7.自動化（包含在game-day/CI基礎架構驗證的reg軟件包中）。
5）Guardrails和停車標準
如果：- 激活了SLO快速燃燒（例如14 × 1小時預算），
- 付款轉換↓超過0。3個百分點，
- TTW p95>連續3分鐘10-15分鐘，
- error-rate > 1.5%，在兩個窗口中增長。
- 通訊：預先批準的通道/狀態模板，ChatOps中的「紅色按鈕」（'/experiment abort'）。
6）實驗示例（Kubernetes/雲）
6.1個網絡延遲到PSP（金絲雀丟失）
目的：驗證轉發/轉發/路由。
註射：+200 ms RTT和3% packet loss僅用於「payments-api」 → 「pspX」。
yaml apiVersion: chaos/v1 kind: NetworkChaos metadata: { name: psp-latency-canary }
spec:
selector: { labelSelectors: { app: payments-api, track: canary } }
direction: to target:
selector: { namespace: prod, ipBlocks: ["10. 23. 0. 0/16"]} # addresses pspX egress action: delay delay:
latency: "200ms"
jitter: "50ms"
correlation: "0. 5"
loss:
loss: "3"
correlation: "0. 3"
duration: "10m"
mode: one # minimum blast radius預期：p95'/deposit' <250 ms，error-rate <1％，轉換≥基線− 0。3個項目；如果惡化-PSP路由自動切換。
6.2節點故障和PDB
目的：測試PDB/反親和力/HPA。
註射：帶有「games-api」 poda的單個紙幣的drain/terminate。
預期：無可用性損失，峰值p99不超越SLO，自動緩存器到達復制品，PDB防止「雙重打擊」。
6.3 Kafka lag и KEDA
目標：在累積信息時可持續撤出。
註射：冷凍消費者5-10分鐘，然後打開。
等待：KEDA縮放鍛煉者，TTW p95在抽水後保持≤ 3分鐘，沒有重復（等效性，鑰匙）。
6.遊戲提供商4個DNS故障
目標：後退/緩存/後退。
註射： "providerA域的NXDOMAIN/時間輸出。example`.
期望： 在UI中快速倒退「providerB」-降級模式和狀態橫幅；「game init success」 ≥ 99。5%.
6.5只閱讀DB
目的：記錄丟失的行為。
註射：將只讀副本切換到10-15分鐘。
等待：代碼正確處理錯誤,關鍵路由受到限制,隊列保持應用程序,沒有損失/雙重註銷。
7）自動化和GitOps
實驗作為代碼：將腳本/參數/guardrails存儲在Git,通過PR咆哮。
遊戲日計劃：時間表，所有者，度量，簡易條款，通訊支票單。
Grafana中的註釋：實驗的開始/結束，config，最終的SLO。
8）混亂期間的觀察力
Exemplars：從p95/p99到特定的「trace_id」。
Логи: поля `experiment_id`, `fault_type`, `retry_attempt`, `degrade_mode=true`.
預告片：外部呼叫標記為'fault。injected=true'，可見retrai/taymauts。
Dashbords：「SLO卡」，版本/實驗compare，Payments/Game init/Queues。
9） iGaming特性： 首先檢查什麼
1.付款和TTW：PSP計時器，倒退路線，等效性。
2.遊戲初始化：工作室不可用/速度慢，CDN故障。
3.引線/獎金隊列：成長，重新處理。
4.多區域：區域/ROR故障，領導者變更，DB復制。
5.高峰：自動滑冰，極限，電路斷路，緩存加熱。
6.RG/Compliance：失敗時的拼寫正確性，遙測中沒有PII。
10）風險管理（政府）
日歷和窗口：在高峰錦標賽之外進行實驗，與企業保持一致。
Роли: Experiment Lead, Observer (SRE), Business Rep;熱線上的IM。
數據策略：文物中沒有PII；用於審核的WORM存儲。
法律界限：在未經同意的情況下排除違反SLA的情景。
11）遊戲日： 腳本模板
12）典型發現和行動
過於激進的撤退→一陣請求→增加時間限制/擠壓/限制。
沒有outlier ejection →「有毒」實例破壞p99 →打開采樣。
脆弱的遷移→僅閱讀就打破了→ expand→migrate→contract+ficheflagi的流動。
錯誤的HPA信號→遲到→切換到RPS/lag度量。
版本共享緩存→回滾會破壞數據→驗證密鑰。
13）混沌實踐成熟度清單
1.描述了Steady-state和SLO，準備好了行車記錄儀。
2.Git中的代碼實驗，評論/審核。
3.Guardrails/abort自動化（Alertmanager/ChatOps）。
4.可觀察性：exemplars，trace/log correlation，註釋。
5.遊戲日為季度，腳本涵蓋付款/遊戲/隊列/多區域。
6.實驗後的動作項目包括在沖刺計劃中；執行控制。
7.Retrais/Taymauts/circuit-breaker在config-repo中的閾值策略。
8.符合證券/PII政策，沒有敏感數據的文物。
9.通過SLO（rollback/scale/reroute）進行自動還原測試。
10.過程度量標準：未通過abort的百分比,練習中的MTTR,減少班級事件。
14）反模式
沒有SLO/guardrails/可觀察性的「我們都在銷售中」。
沒有假設和可測量的目標的實驗。
第一次發射時的大爆炸無線電。
沒有定時器/噴射器的retrai →級聯容錯。
混亂而不是預防：治療癥狀，忽略根源原因。
運動後缺乏RCA/動作項目。
在高峰時段進行實驗，而沒有與業務保持一致。
結果
混沌工程是可持續性的有條不紊的證明：您預先復制實際故障，測量對SLO和業務指標的影響，並加強體系結構-從撤退和電路斷路器到多區域編排和自動重塑。在常規的遊戲日和guardrails紀律中，即使在最熱的時期，iGaming平臺也可以保留p95/p99，轉換和TTW。