Technologia i infrastruktura → Architektura chmury i SLA
Architektura w chmurze i SLA
1) Dlaczego SLA i jak zarządzać nimi
SLA (Service Level Agreement) - zewnętrzna obietnica dla biznesu/partnerów na temat dostępności, szybkości i poprawności usługi.
SLO (Service Level Objective) - wewnętrzne poziomy docelowe dla poleceń.
SLI (Service Level Indicator) - mierzalne wskaźniki, na podstawie których ocenia się SLO.
iGaming/fintech charakteryzuje sztywne okna szczytowe (turnieje, zakłady na żywo, okresy sprawozdawcze, dni „wynagrodzenia”), silna zależność od dostawców PSP/KYC i geografii. SLA powinny brać pod uwagę to zachowanie, a architektura powinna gwarantować nie tylko średnie, ale także percentyl.
2) Podstawowa terminologia
Dostępność - Odsetek udanych wniosków w przedziale.
Opóźnienie - P50/P95/P99 dla kluczowych operacji.
Błąd - dokładnie określić (5xx, timeout, błąd biznesowy?).
RTO (Recovery Time Objective) - ile czasu jest dozwolone na odzyskanie.
Cel punktu odzysku (RPO) - ile danych można utracić w przypadku katastrofy.
Budżet błędu - 1 - SLO, „rezerwa” na zmiany i incydenty.
3) Ramy architektury chmury dla SLA
3. 1 Multi-area (Multi-AZ)
Replikuj stan (DB, pamięć podręczna, kolejki) do co najmniej 2-3 AZ.
Zimne/ciepłe postoje, automatyczna awaria.
Lokalne balancery (L4/L7) z kontrolą zdrowotną per-AZ.
3. 2 Multiregion
Aktywa do aktywów: niski poziom RTO/RPO, trudniejsza spójność i koszt.
Aktywa-zobowiązania (gorące/ciepłe): tańsze, RTO bardziej, ale łatwiejsza kontrola danych.
Routing geograficzny (GeoDNS/Anycast), izolacja „blast radius”.
3. 3 Przechowywanie i dane
Bazy danych transakcyjnych: replikacja synchroniczna w regionie, asynchroniczna międzyregionalna.
Cache: repliki przekrojowe, tryb „local reads + async heat”.
Przechowywanie obiektów: wersioning, cykle życia, replikacja przekrojowa.
Kolejki/Przesyłanie strumieniowe: Klastry lustrzane/Strumienie wielobranżowe.
3. 4 Izolacja pętli
Rozdzielenie usług krytycznych (płatności/portfel) i „ciężkich” zadań analitycznych.
Limity stawek/kwoty między konturami, tak aby sprawozdania nie „zjadły” prod.
4) Wzory wysokiej dostępności
Izolacja grodziowa i basenowa - Izolacja połączeń i puli zasobów.
Wyłącznik + Timeouts - ochrona przed zamarznięciami integracji zewnętrznych.
Idempotencja - powtarzanie żądań bez podwójnych odpisów.
Graceful Degradation - po zdegradowaniu, wyłączyć niegodne funkcje (awatary, zaawansowane filtry).
Backpressure - sterowanie przepływem przychodzącym, nie zezwalaj na kolejki „do horyzontu”.
Wtrysk chaosu/awarii - planowane „niepowodzenia” w testowaniu hipotez wiarygodności.
5) Strategie DR (Recovery Disaster)
Wybór: płatności/portfel - minimum Hot Standby; zawartość/katalog - ciepło; Raporty - Kopia zapasowa i przywracanie za pomocą czystych okien.
6) O SLI/SLO: jak prawidłowo mierzyć
6. 1 SLI według poziomu
Klient SLI: end-to-end (w tym brama i dostawcy zewnętrzni).
Usługa SLI: „czyste” opóźnienia/błędy serwisowe.
Business SLI: CR (registratsiya → depozit), T2W (czas do portfela), wskaźnik spadku PSP.
6. 2 przykłady SLO
Dostępność rdzenia API: ≥ 99. 95% w ciągu 30 dni.
Opóźnienie wypłaty: P95 ≤ 350 ms, P99 ≤ 700 ms.
Dostawa haków PSP: ≥ 99. 9% przez 60 sekund (z retras).
Raporty dotyczące świeżości danych: ≤ 10 min opóźnienia w 95% czasu.
6. 3 Polityka budżetowa dotycząca błędów
50% budżetu - na zmiany (zwolnienia/eksperymenty), 50% - na incydenty.
Spalanie budżetu → funkcja frieze, tylko stabilizacja.
7) Wydajność i skalowanie
HPA/VPA z sygnałami zorientowanymi na SLO (nie tylko procesor, ale także kolejki/opóźnienia).
Predykcyjne skalowanie na podstawie harmonogramów i historycznych szczytów.
Ciepłe baseny/podgrzewanie połączeń do DB/PSP przed turniejami.
Buforowanie i krawędź - zmniejszyć RTT, zwłaszcza dla katalogów gier i aktywów statycznych.
8) Warstwa sieciowa i ruch globalny
Anycast/GeoDNS zminimalizować opóźnienia i zlokalizować awarie.
Polityka awaryjna: badania zdrowotne regionu, progi, „lepkość” z TTL.
mTLS/WAF/Rate Limit na krawędzi, ochrona przed ruchem bot.
Egress control do PSP/KYC poprzez listę zezwoleń i SLA-świadomy rekolekcje.
9) Dane i spójność
Wybierz poziom spójności: ścisłe (płatności) vs eventual (katalog/oceny).
CQRS do odładowywania odczytu i pionów poleceń krytycznych.
Skrzynka odbiorcza/skrzynka odbiorcza do „dokładnie raz” dostawy zdarzeń.
Migracje wolne od przestojów: rozszerzenie umowy o migrację, podwójne wejście podczas zmian MAJOR.
10) Obserwowalność w ramach SLA
Traces through gateway: korelacja 'trace _ id' z wersją partner/region/API.
SLO-deski rozdzielcze z szybkością spalania, „pogoda” według regionu i dostawcy.
Alerty przez objawy, nie przez objawy proxy (nie CPU, ale P99/błędy).
Syntetyka: kontrole zewnętrzne z krajów docelowych (TR, BR, UE...).
Audyt i sprawozdawczość: eksport SLI/SLO do portalu partnerskiego.
11) Bezpieczeństwo i zgodność
Segmentacja sieci i tajne zarządzanie (KMS/Vault).
Szyfrowanie podczas lotu/odpoczynku, tokenizacja PAN/PII.
Polityka dostępu do ról dla administratorów/operatorów.
Kłody niezmienne (WORM) i przechowywanie do audytu.
Regulacja: przechowywanie w regionie, raporty, sprawdzalność realizacji SLA.
12) FinOps: SLA jako kierowca kosztowy
Umieść ceny na odchyleniach SLO: ile jest + 0. 01% dostępności?
Profil okna szczytowe, nie napompować stałej mocy.
Prawy rozmiar i „miejsce, gdzie można” dla zadań w tle.
Kwoty i budżety na kontury, nie pozwalają na „wolną” degradację.
13) Badanie niezawodności
Sesje GameDay/Chaos: wyłączenie AZ/PSP, opóźnienia w kolejkach, przerwy BGP.
DR-drili: regularne szkolenie regionów zmieniających cele dla RTO.
Load & Moak: długie biegi z prawdziwymi profilami zakładów/turniejów.
Powtórki: biblioteka znanych plików i skryptów odtwarzania.
14) Strona procesu SLA
Katalog SLO: właściciel, formuła, mierniki, źródła, wpisy.
Zmiany za pośrednictwem RFC/ADR: ocena wpływu na budżet błędu.
Pośmiertne: poprawa architektury i ranbooków, dostosowanie SLO.
Komunikacja z partnerami: mailingi, strona stanu, planowana konserwacja.
15) Przykłady SLI/SLO/Report
15. 1 Wzory
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 Przykładowy podstawowy zestaw SLO API
Dostępność (30 dni): 99. 95%
Punkt końcowy P95 '/v2/payouts/create ': ≤ 350ms
5xx błędy (walcowanie 1 godzina): <0. 3%
Dostawa webhook ≤ 60 сей (P99): ≥ 99. 9%
RPO dla portfela: ≤ 60 s, RTO ≤ 5 min
15. 3 raport SLA (squeeze)
Zakończono: 99. 97% (99 SLO. 95%) +
Naruszenia: 2 odcinki na region BR z powodu czasu PSP (łącznie 8 minut).
Środki: dodany inteligentny routing kodami awaryjnymi, zwiększona pula połączeń z PSP-B.
16) Lista kontrolna wdrażania
1. Zdefiniowano krytyczne ścieżki użytkownika i odpowiednie SLIs.
2. SLO na 30/90 dni + polityka budżetu błędów.
3. Plan wielozadaniowy i DR z celami RTO/RPO, regularne wiertła.
4. Syntetyka z geoprzestrzennych desek rozdzielczych na region/na PSP.
5. Wzory stabilności: wyłącznik, ciśnienie wsteczne, idempotencja.
6. Polityka degradacji i flagi funkcji dla funkcji niepełnosprawnych.
7. FinOps: budżety konturowe, prognoza szczytu, ciepłe baseny.
8. Bezpieczeństwo: segmentacja, szyfrowanie, audyt.
9. Dokumentacja SLA dla partnerów, proces komunikacji.
10. Retrospektywy i zmiany SLO co 1-2 kwartały.
17) Anty-wzory
Obiecaj SLA bez wymiernych SLIs i przejrzystych technik liczenia.
Policz dostępność „przy wejściu do usługi”, ignorując bramę/dostawców.
Polegaj tylko na średnim opóźnieniu, ignorując ogony P99.
DR „na papierze”, brak prawdziwego szkolenia.
„Wieczne” zasoby bez ograniczeń: jeden raport sprowadza prod.
Mieszać żywność i ciężką analitykę w jednym klastrze/bazie danych.
18) Najważniejsze
Architektura chmury dla SLA to połączenie wzorców technicznych (wielopoziomowy/region, izolacja, dane odporne na uszkodzenia), procesów (SLO, budżet błędów, DR-wiertarki) i ekonomii (FinOp). Daj sobie prawo do przewidywanych awarii: tolerancja błędów testowych, pomiar przez percentyle, ograniczenie „wybuchowego promienia” i komunikować się otwarcie. Obietnice SLA stałyby się wtedy nie marketingiem, ale zarządzaną praktyką inżynierską.