行動和管理→事件預防

事件預防

1）為什麼需要它

對事件的最佳反應是他缺席。對於iGaming/fintech，每分鐘的停機時間都是利率/存款損失，提供商罰款，聲譽風險。系統預防降低了「改變失敗率」，穩定了SLO，並釋放了團隊的時間來發展而不是滅火。

• 最大限度地減少關鍵路徑（存款、投註、遊戲啟動、退出）上發生事件的可能性。
• 在擊中SLO和錢包之前攔截降級。
• 限制故障半徑（blast radius）並加快恢復速度。

2）預防基本原則

1.SLO-first和error budget：如果有可能擊倒SLO並燒毀預算，則不會發布更改。
2.深層防禦：保護層-從數據圖和偽圖到網絡策略和偽圖。
3.Failure設計：破折號，taymauts，帶有抖動的retrai，等效性，降級。
4.小型和反向變化：小增量+快速回滾（功能橫幅/金絲雀）。
5.通過設計觀察：每個關鍵步驟和鏈接的度量/邏輯/跟蹤。

3）風險和關鍵路徑圖

根據以下領域編寫「痛苦地圖」：薪水，Bets，遊戲，KYC，促銷活動，Jackpots，Content。

• 業務指標（轉換，GGR，平均支票）。
• 技術SLO （latency p95/p99, uptime, success rate）。
• 相關性（內部/外部），限制/配額。
• 「安全模式」行為（禁用/簡化）。
• 所有者的跑步簿。

4）Guardrails（防守障礙）

Taymauts和Breakers：呼叫服務的taymauts短於內部總和；當錯誤/潛伏期增加時，斷路器打開。
Bulkhead隔離：每個下遊的單獨連接/操作員池。
Rate limit&backpressure：防止雪崩和回火風暴。
Ficheflagi降解：「最小模式」-易於響應，緩存爬行動物，關閉重型幻燈片。
多供應商和操縱器：備用PSP/KYC，路線切換。
Configs驗證：安全更改幻燈片和極限的電路/直線/策略。

5）變更管理（變更管理）

預發布遊戲：測試，安全性，CDC（消費者驅動合同），電路兼容性。
加那利島發行+賽車：1％→ 10％→ 100％；p99/error rate/燃燒預算上升時自動停止。
Feature flags：瞬時回滾/切換行為而不丟棄。
發布日歷：避免提供者的高峰運動/錦標賽窗口和維護。
後處理檢查：自動處理，將「前/後」度量與閾值進行比較。

6）測試作為預防措施

單位/合同/集成：OpenAPI/AsyncAPI合同，CDC 與提供商/mock。
Load&stress：黃金時段的流量配置文件；連接極限/IOPS/配額測試。
Soak/long-haul：資源流失，地平線上的延遲/天增加。
混亂/遊戲日：經紀人/PSP/KYC下跌，地區破裂，「緩慢提供者」。
Disaster Recovery Drills：定期訓練區域切換和DB恢復。

7）降解的早期檢測

Capacity-alerts：頭部，隊列陣列，DB連接，緩存中的事件。
SLO-burn-rate：以危險的「燃燒」預算速度發出的信號。
適應性閾值：季節性/日常模式以減少假。
復合變量：「lag ↑+HPA at max+open circuit」 ⇒高風險。
Vendor health：每個提供商的配額/計時/錯誤+通話成本。

8）與外部供應商合作

OLA/SLA ↔ SLO：將安排與我們的目標聯系起來。
Failover Playbooks：PSP-X ⇆ PSP-Y路線，令牌緩存，grace存款模式。
三明治和合同：每次重大變化之前的測試流。
提供程序窗口：行車記錄上的註釋和自動超級規則。

9）數據、偽造和秘密

更改策略：兩對眼睛的代碼評論，方案驗證/JSON/YAML。
秘密：KMS/Secrets Manager，輪換，環境/角色劃分。
標誌/限制：通過具有審核和即時回滾的API進行更改。
遷移：「雙步」（expand → migrate → contract），總向後兼容性。

10）團隊培訓和準備

電話培訓：事件模擬，影子值班，集中運行手冊。
統一通信格式：狀態/變量/事件更新模式。
安全文化：無罪驗屍、機械原因和預防行動。

11）預防達什伯德（最低）

風險與準備：SLO/預算，按層排列，「最脆弱的聯系」。
Change Safety：加那利群島的百分比，回扣，「發布後」的變量，CTR賽車。
Vendor Panel：每個供應商的p95/error/配額/成本,供應商的劄幌響應時間。
混亂/DR準備：運動頻率，區域切換時間，恢復成功率。
Config/SecOps：旗幟/限制/秘密更改，異常。

12）預防性異常示例

ALERT SLOBurnRateHigh
IF slo_error_budget_burnrate{name="payments_api"} > 4 FOR 10m
LABELS {severity="critical", team="payments"}

ALERT PostDeployRegression
IF (api_p99_ms{service="bets"} > baseline_1d 1. 3) AND (release_window="canary")
FOR 10m
LABELS {severity="warning", team="bets"}

ALERT ProviderQuotaNearLimit
IF usage_quota_ratio{provider="psp_x"} > 0. 9 FOR 5m
LABELS {severity="warning", team="integrations"}

ALERT QueueLagAtRisk
IF (kafka_consumer_lag{topic="ledger"} > 5e6 AND rate(kafka_consumer_lag[5m]) > 5e4)
AND (hpa_desired == hpa_max)
FOR 10m
LABELS {severity="critical", team="streaming"}

13）預防支票清單（每日/高峰前）

• 當前高峰日歷（比賽，錦標賽，活動，提供商窗口）。
• 通過API/DB/緩存/隊列，HPA/VPA就緒性，緩存加熱的Headroom。
• 提供商的狀態（配額、限額、24小時降級）,配置了收發器。
• 金絲雀門包括在內，ficheflagi回扣可供業主使用。
• Alerta SLO/Capacity是活躍的，對計劃工作進行了補充。
• Runbook'和更新，電話確認，升級渠道工人。

14）反模式（避免什麼）

沒有金絲雀和旗幟的「大型夜間發行」。
通用流池到所有下遊（線頭塊）。
Retrai進行非偶然操作和瓶頸時間。
缺少Alertes滯後→按閾值鋸。
盲目相信供應商的SDK，而無需觀察和控制時間。
沒有stage/sandbox和CDC的「讓我們賣」。

15） KPI預防

Change Failure Rate（目標≤ 10-15%或目標）。
事件前檢測率：在退化階段避免的事件比例。

Mean Time Between Incidents (MTBI) и MTTR.

覆蓋保護：帶有旗幟/破折號/taymauts/金絲雀的關鍵路徑的百分比。
混亂/DR演習：演習的頻率和成功率。
Vendor readiness：到備用提供商的平均切換時間。

16）快速啟動（30天）

第一周：關鍵路徑圖，SLO和所有者；啟用SLO-burn-alerta和capacity-alerta。
第二周：金絲雀門+菲奇弗拉吉；基本混沌腳本（提供者/隊列）。
第3周：dashboard 「Change Safety」和「Vendor Panel」，傳說中的花花公子。
第4周：DR教學（部分），回顧和四分之一硬化計劃。

17）模板（片段）

canary_policy:
guardrails:
- metric: api_p99_ms threshold: 1. 3 baseline_1d window: 10m action: pause_and_rollback
- metric: error_rate threshold: 2 baseline_1d window: 5m action: pause max_step: 10%
step_interval: 15m required_annotations: [release_notes, feature_flags, runbook_link]

safe_mode:
payments:
- freeze_heavy_providers
- enable_cached_token_flow
- route_to_psp_y_if(psp_x_error_rate > 5%)
games:
- limit_broadcasts
- reduce_lobby_heavy_widgets bets:
- raise_risk_score_threshold
- cache_odds_snapshot

18) FAQ

Q： 如果資源不足,首先要實施什麼?

A：關鍵軌道上的SLO-burn-alerta，金絲雀門和ficheflagi回扣；然後是風險卡和提供商的收貨人。

問：如何理解預防「有效」？
答：改變失敗率下降，避免的事件比例上升，MTTR下降，警報噪音下降，「夜間」分頁數量減少。

問：是否需要定期的混沌演習？
A：是的。如果沒有訓練，feilover和DR幾乎總是比紙上看起來更長，更痛苦。