技術和基礎設施→雲架構和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的承諾將不再是營銷，而是由工程實踐驅動。