行动和管理→事件预防

事件预防

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几乎总是比纸上看起来更长，更痛苦。