SLO, SLA ve güvenilirlik izleme

(Bölüm: Teknoloji ve Altyapı)

Kısa Özet

SLO bir iç kalite hedefidir, SLA müşteriye harici bir taahhüttür, SLI kaliteyi nasıl ölçtüğümüzdür. IGaming'de, anahtar SLI'lar: API ve ödeme kullanılabilirliği, kritik rotaların p95/p99 gecikmesi, Time-to-Wallet (TTW), ödeme dönüştürme, oyun başlatma ve kuyruk metrikleri. Güvenilirlik yönetimi, bir hata bütçesi, çok yanmalı uyarılar, net sürüm kapıları ve ek açıklamalara sahip görsel panolar etrafında oluşturulmuştur.

1) Şartlar ve farklılıklar

SLI (Hizmet Seviyesi Göstergesi) - ölçülen gösterge (örn. zaman penceresi başına başarılı isteklerin oranı).
SLO (Hizmet Seviyesi Hedefi) - hedef SLI değeri (örn. "kullanılabilirlik 99. 30 günde %9").
SLA (Hizmet Seviyesi Sözleşmesi) - tazminat ile sözleşme/sorumluluk; Gerçek SLO'lara dayanır, ancak yasal hükümler ve planlı bakım pencereleri içerir.

Kural: Önce SLI/SLO'yu içeride stabilize edin ve ancak SLA'yı dışarıda sabitleyin.

2) iGaming için SLI çerçevesi

TexSLO

Kullanılabilirlik: başarılı 2xx/3xx/tüm istekler.
Gecikme: Anahtar yollarla p95/p99 ('/para yatırma ','/bahis','/oyun/init ').
Hatalar: 5xx paylaşım/zaman aşımları.
Doygunluk/Kuyruklar: gecikmiş ödeme/işlem kuyrukları.

Business SLI

Ödeme dönüşümü: 'Başarı/girişim'.
TTW p95: Para çekme talebinden kayda kadar geçen süre.
Oyun başlangıç başarısı: oyun oturumları, sağlayıcı başlatma.
KYC/AML akış başarısı.

3) Hata bütçesi: nasıl sayılır

Hata Bütçesi = 1 − SLO.
Örnek: Kullanılabilirlik 99 SLO. %9/30d ⇒ hata bütçesi = 0. Zamanın %1'i 30 günlük bir pencerede 43 dakika 12 saniye ≈.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

SLO sürgülü bir pencerede (30/7/1 gün) sayılır ve panolarda görülebilir.

• Bütçenin hızlı "yanması" - serbest bırakır, kanaryayı durdururuz, istikrar üzerinde çalışıyoruz.
• Bütçe stoğu - daha sık değişikliklere izin verir (kontrollü).

4) Anahtar akışları için SLO örnekleri

• Kullanılabilirlik ≥ 99. %9/30d
• Gecikme süresi p95'/depozito '≤ 250 ms/ 30д
• Ödeme dönüşümü ≥ taban çizgisi − 0. %3/24 saat
• TTW p95 (çıkış) ≤ 3 dakika/24 saat

• Oyun init başarı ≥ 99. %5/ 7д p95 oyun init ≤ 600 ms/ 7д

• İş başarısı ≥ %99/7e, lag <5 dakika (tepe pencereleri ayrı ayrı).

5) Ölçüm: formüller ve PromQL (fikirler)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) Yazma hızı uyarıları (çoklu pencere)

Fikir: mevcut bütçe tüketim oranını izin verilenle karşılaştırıyoruz.

• Hızlı yakma: 1 saat içinde 14 bütçe × - 5-15 dakika içinde sayfa.
• Yavaş yanma: 24 saat içinde 6 bütçe × - bilet, sebep analizi.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) Panolar "SLO-kart've işletim sistemi

• Hizmet kartları: Kullanılabilirlik, p95, Hata oranı, Yazma oranı, Hata Bütçesi dengesi.
• Filtreler: 'env', 'bölge', 'kiracı', 'sürüm'.
• Sürüm ek açıklamaları: Git SHA, türü (kanarya/mavi-yeşil), geçiş zamanı.

• Stabil vs kanarya karşılaştırması.
• PSP/oyun sağlayıcıları tarafından bölüm.
• Örnekler (trace_id) ve ilgili günlüklere gidin.
• Kuyruk gecikmesi ve doygunluk (USE metrikleri).

8) SLO süreçleri: kapılar, donma, yükselmeler

CD'deki Kapılar: Kanarya promosyonuna yalnızca bir SLO proxy'si (kullanılabilirlik, p95, conv) gerçekleştirirken izin verilir.
Freeze: hızlı yakma veya sıfır bütçe dengesi ile - iyileşene kadar sürümleri durdurun.
Eskalasyon: SEV-matris (SEV1 ödemeler/depozitolar, SEV2 oyunları, SEV3 kazma).
RCA: Ücret olmadan analiz, test/limit/phicheflags güncellenmesi.

9) Veri/ML-SLO (önericiler/LLM için)

Gecikme: p95 yanıt modeli ≤ 300 ms (veya belirteçler/s ≥ N).
Kaliteli proxy: Geçerli yanıtların oranı/düşük toksisite, yararlı payı.
Tazelik: Özelliklerin/verilerin yaşı ≤ X saat.
1k etkinlik başına maliyet: Bütçede harcama.
SLO kapıları model sürümlerine entegre edilmiştir (A/B/kanarya sunumu).

10) SLO'ya dayalı SLA tasarımı

SLA'ların temeli olarak muhafazakar SLO'ları seçin.
İstisnaları tanımlayın (planlanan faaliyetler, dış bağımlı sağlayıcılar, olay prosedürleri).
İhlal seviyelerine (kredi/indirim), raporlama ve doğrulama mekanizmalarına göre ofset girin.

11) Sık hatalar ve anti-desenler

SLO yoktur, sadece "çalışma süresi %100" gerçekçi değildir, riskleri ortadan kaldırır ve gizler.
Burn-rate yerine'her metrik "için uyarılar - alert-fatg ve yok say.
SLO için metriklerde/günlüklerde PII karıştırma - uyumluluk riskleri.
Kardinalite patlar: Etiket olarak 'user _ id/session _ id'.
Sürüm ek açıklamalarının olmaması - bozulmayı değişimle ilişkilendirmek zordur.
Opak hata bütçesi - ekip ne zaman "risk alabileceğinizi" anlamıyor.
SLO işe bağlı değildir - teknik metrikler'yeşil ", gelir" kırmızı'dır.

12) Uygulama kontrol listesi

1. Temel SLI'ları onaylayın (Kullanılabilirlik, p95/p99, Hata oranı, TTW, Dönüştürme).
2. SLO'yu 30/7/1 günlük pencerelerde ayarlayın ve Hata Bütçesini sayın.
3. Kayıt kuralları ve yanma oranı uyarıları ekleyin (hızlı/yavaş).
4. Sürüm ek açıklamaları ve kanarya/kararlı karşılaştırmalar ile bir SLO haritası oluşturun.
5. Kapıları CD'ye ekleyin: SLO-ok olmadan - promosyon olmadan.
6. Dondurma prosedürlerini ve bir yükseltme SEV matrisini girin.
7. SLO'ları iş metriklerine (conv, TTW) ve ödeme yollarına bağlayın.
8. Data/ML için gecikme/kalite/tazelik-SLO'yu tanımlayın.
9. Düzenli RCA'lar ve SLO/eşik revizyonları (üç ayda bir).
10. Belge SLA'ları yalnızca SLO sabitlendikten sonra.

13) "Hazır" hedeflere örnekler (başlangıç olarak)

API genel: Kullanılabilirlik 99. %9/30d; P95 ≤ 250 ms/30d; Hata oranı ≤ 0. %3/30d

Ödemeler: Dönüşüm ≥ taban − 0. %3/24 saat; TTW p95 ≤ 3 dakika/24 saat

Oyunlar init: Başarı ≥ 99. %5/7d; P95 ≤ 600 ms/7e

Backoffice işleri: Başarı ≥ %99/ 7д; lag ≤ 5 dakika/7d

LLM/Reco: belirteçler/s ≥ N, toksisite viol. ≤ 0. %5/7d, tazelik ≤ 6 saat.

Özet

SLO/SLA yaklaşımı, güvenilirliği "dünden daha iyi'den ölçülebilir bir disipline dönüştürür: şeffaf SLI'ler, anlaşılabilir bir hata bütçesi, yanma hızı uyarıları, anlaşılabilir panolar ve sürümlerde yerleşik kalite kapıları. Bu kontur, iGaming platformuna öngörülebilir bir p95/p99, istikrarlı ödemeler ve TTW verir; bu, en sıcak saatlerde daha iyi gelir ve daha az olay anlamına gelir.