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。