技术和基础设施→云架构和SLA
云架构和SLA
1）为什么SLA以及如何管理它们
SLA（服务级别协议）是企业/合作伙伴对服务的可用性，速度和正确性的外部承诺。
SLO（服务级别目标）是团队的内部目标级别。
SLI（服务级别指标）是评估SLO的可测量指标。
iGaming/fintech的特点是硬顶窗口（比赛，轻量级投注，报告期，"薪水"日），严重依赖PSP/KYC提供商和地理位置。SLA必须考虑这种行为，而体系结构不仅要提供中等程度的保证，还要提供安全保障。
2）基本术语
可用性（Availability）-每个间隔成功查询的比例。
潜伏期是关键操作的P50/P95/P99。
错误-准确确定（5xxx、timaut、业务错误?）。
RTO（恢复时间目标）-允许恢复多长时间。
RPO （Recovery Point Objective）-事故中可能会丢失多少数据。
错误预算-1 − SLO，更改和事件的"股票"。
3） SLA下的云架构框架
3.1多区域（Multi-AZ）
状态复制（DB、缓存、队列）至少2-3 AZ。
寒冷/温暖standbai，自动失速。
带有per-AZ健康支票的本地平衡器（L4/L7）。
3.2多区域
资产资产：低RTO/RPO,更难一致性和价值。
资产passive （hot/warm）：更便宜,RTO更大,但更容易控制数据。
地理漫游（GeoDNS/Anycast），"爆炸无线电"隔离。
3.3存储和数据
事务性数据库：区域内同步复制,异步区域间复制。
缓存：跨区域复制副本,"本地读取+async warmup"模式。
对象存储：转换、生命周期、跨区域复制。
队列/流媒体：镜像群集/多区域流。
3.4轮廓隔离
分离关键服务（payments/wallet）和"繁重"的分析任务。
速率限制/quotas在轮廓之间，以免报告被prod"吃掉"。
4）高可用性模式
Bulkhead&Pool Isolation-隔离连接和资源池。
电路Breaker+Timeouts-防止外部集成的依赖性。
Idempotency-在没有双重注销的情况下重复查询。
Graceful Degradation-降解时,我们禁用非滋润性菲奇（化身、扩展过滤器）。
Backpressure-控制传入的线程,不要允许队列"到达地平线"。
Chaos/Failure Injection是用于验证可靠性假设的计划"失败"。
5） DR战略（灾难恢复）
选择：付款/钱包-最低限度Hot Standby；内容/目录-Warm；报告-带有清晰窗口的Backup&Restore。
6）Pro SLI/SLO： 如何正确测量
6.1 SLI按级别
客户端SLI：端到端（包括网关和外部提供商）。
服务SLI："干净"的潜在性/服务错误。
业务SLI：CR（registratsiya→depozit），T2W（时间到钱包），PSP-decline rate。
6.2 SLO示例
Core API可用性：≥ 99。在30天内达到95%。
付费启动的潜伏期：P95 ≤ 350毫秒，P99 ≤ 700毫秒。
PSP webhooks交付：≥ 99。9％在60秒内（带后台）。
Data Freshness报告：95%的时间≤ 10分钟。
6.3 Error Budget Policy
50%的预算用于更改（发布/实验）,50%用于事件。
预算烧毁→带状菲奇，只有稳定。
7）性能和扩展
具有SLO定向信号的HPA/VPA（不仅是CPU，而且是队列/潜伏期）。
基于时间表和历史高峰的预测滑板。
比赛开始前，Warm pools/预热连接到 DB/PSP。
缓存和边缘-减少RTT，特别是对于游戏目录和静态asset。
8）网络层与全局流量
Anycast/GeoDNS可最大程度地减少潜伏期和事故本地化。
Failover政策：该地区的健康样本，阈值，TTL的"稳定"。
mTLS/WAF/Rate Limit在边缘，防止机器人流量。
通过allow-list和SLA-aware retras对PSP/KYC进行电子控制。
9）数据和一致性
选择一致性级别：严格（付款）vs eventual（目录/评级）。
CQRS用于卸载关键命令的读取和垂直。
Outbox/Inbox for"正好有一天"交付事件。
无市区迁移：expand-migrate-countract，MAJOR更改期间的双重记录。
10）SLA下的观察力（观察力）
通过网关的跟踪："trace_id" 与合作伙伴/区域/API版本的相关性。
具有burn-rate的SLO-dashbords，按地区和提供商划分的"天气"。
Alerts的症状而不是代理症状（不是CPU，而是P99/错误）。
合成：来自目标国家（TR，BR，EU……）的外部检查。
审核和报告：将SLI/SLO导出到合作伙伴门户。
11）安全和合规性
网络分割和秘密管理（KMS/Vault）。
飞行/静止加密，PAN/PII令牌化。
海军上将/操作员角色访问策略。
用于审核的逻辑不可变（WORM）和重构。
监管：存储在该地区,报告,可证明执行SLA。
12） FinOps： SLA作为价值驱动程序
将SLO偏差定价： 多少+0。01%的可用性?
剖析峰值窗口,不要膨胀恒定功率。
右对齐和背景任务的"位置"。
轮廓配额和预算，不要允许"免费"降级。
13）可靠性测试
GameDay/Chaos会话：AZ/PSP关闭，队列延迟，BGP断裂。
DR-drili：定期训练RTO目标的区域切换。
Load＆Soak：具有真实投注/锦标赛特征的长跑。
重播事件：已知伪造和播放脚本库。
14） SLA流程方面
SLO目录：所有者，公式，度量，来源，变量。
通过RFC/ADR进行更改：评估对错误预算的影响。
后验者：改善建筑和书籍，调整SLO。
与合作伙伴的通信：邮件、状态页面、计划维护。
15） SLI/SLO/报告示例
15.1个公式
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15.2 Core API的SLO集示例
可用性（30天）： 99天。95%
P95 endpointa '/v2/payouts/create'： ≤ 350毫秒
错误5xx（滚动1小时）： <0。3%
Webhook delivery ≤ 60 сек (P99): ≥ 99.9%
钱包RPO： ≤ 60秒，RTO ≤ 5分钟
15.3 SLA报告（挤压）
已执行： 99。97% (SLO 99.95%) +
违规行为：由于PSP定时器（总计8分钟），在BR地区发生了2集。
措施：通过故障代码添加智能路由，增加了PSP-B连接的战池。
16）实施支票
1.定义了关键用户路径和相应的SLI。
2.30/90天的SLO+错误预算政策。
3.带有RTO/RPO目标的多区域性和DR计划，定期演习。
4.来自地理目标的Synthetics，per-region/per-PSP dashbords。
5.可持续性模式： 电路断路器,背板,idempotency.
6.降级策略和可禁用幻灯片的特征。
7.FinOps：轮廓预算，高峰预测，战争池。
8.安全性：分段、加密、审核。
9.合作伙伴的SLA文档,通信过程。
10.每1-2季度回顾和修订SLO。
17）反模式
承诺没有SLI可测量和透明计数技术的SLA。
通过忽略网关/提供商来计算"服务入口处"的可用性。
仅依靠平均潜伏期，而忽略了P99的尾巴。
DR"通过纸面"，缺乏真正的培训。
无限制的"永恒"资源：一份报告证明。
在单个群集/DB中混合prod和重分析。
18）结果
SLA之下的云体系结构是技术模式（multi-AZ/区域，绝缘，容错数据），过程（SLO，错误预算，DR-dryl）和经济学（FinOps）的组合。给自己预报故障的权利：测试容错能力，测量笔触，限制"爆炸半径"，并公开沟通。然后，SLA的承诺将不再是营销，而是由工程实践驱动。