Monitorowanie SLA i SLO

1) Warunki i role

SLA - zewnętrzny obowiązek umowny wobec klienta (klauzule kary, kredyty).
SLO (Service Level Objective) - docelowy poziom usług wewnętrznych, który wspiera realizację SLA.
SLI (Service Level Indicator) - mierzony wskaźnik, na podstawie którego oceniane są SLO/SLA.
Budżet błędu - dopuszczalny procent „niedostępności/błędów” w okresie: 'Budżet = 1 − SLO'.
Zakres: mierzony oczami użytkownika (end-to-end). W mikroserwicach, zarówno na poziomie komponentu, jak i na poziomie ścieżki końcowej.

2) Wybór SLI: co dokładnie zmierzyć

Kryterium jest korelacja z doświadczeniem użytkownika i wartością biznesową.

• Dostępność: procent udanych wniosków. „SLI = udane/wszystkie”.
• Opóźnienie: odsetek wniosków jest szybszy niż próg T. „SLI = P (opóźnienie ≤ T)”.
• Jakość: odsetek poprawnych odpowiedzi (bez 5xx/funkcje. błędy).
• Aktualizacja danych - Opóźnienie replikacji/ETL ≤ X minut.
• Wydajność procesu biznesowego: udział udanych płatności/rejestracji.

Anty-wzorce: liczyć tylko 200 jako „sukces”, ignorując błędy biznesowe; pomiar w sieci testowej zamiast w sieci użytkownika.

3) Formuły i okna obserwacyjne

• „Dostępność = (OK_requests/ All_requests) × 100%”.

• "P95 ≤ T" → jest lepiej sformułowane jako udział: "SLI =% wniosków ≤ T'.
• Przykład: „99% zapytań wyszukiwania ≤ 300 ms w 28 dni”.
• Okno przesuwne: 28 lub 30 dni (równowaga wrażliwości i stabilności). W przypadku incydentów - dodatkowe okna: 1 h, 6 h, 24 h.

4) Budżet błędu i kontrola wskaźnika zmian

Obliczenie: na 'SLO = 99. 9% 'budżet =' 0. 1% 'błędów/niedostępności na okres.

• Budżet> 50%: wydania i plany eksperymentów.
• Budżet 10-50%: tylko zwolnienia niskiego ryzyka, zaostrzenie kanarów.
• Budżet <10%: zamrożenie zwolnienia, przyczyna korzenia, poprawa niezawodności.
• Połączenie z progresywnymi wydaniami: kanarkowe/feature-flag „jeść” budżet w dawkach, z auto-rollback pod degradacją.

5) Politycy ostrzegający: od progów do stopy spalania

Dlaczego "daupal SLO - podnieść alarm': za późno. Potrzebuję proaktywności.

• 'BR = (zaobserwowany błąd w krótkim oknie/dozwolony błąd w tym oknie)'.
• Jeśli 'BR> 1' - budżet jest zużywany szybciej niż normalnie.

• Szybki alarm (hałas jest wrażliwy, katastrofy): okno 5-10 minut, próg BR 14-20 ×.
• Powolny alarm (połowy pełzające degradacja): okno 1-6 godzin, próg BR 2-4 ×.
• Warunki łączenia: szybkie lub powolne - przywoływanie dyżurów.
• Poziomy: pager dla SLO użytkowników, bilety/powiadomienia o szarej degradacji wewnętrznych SLIs.

6) Obserwowalność i źródła prawdy

Kłody - diagnoza przyczyn.
Metryka - SLIs liczbowe (sukces/błąd, procentyle opóźnienia, frakcje, liczniki).
Szlaki - przez ścieżki, lokalizacja „gorących” segmentów.
Syntetyka - próbki aktywne z obwodu (świadomy regionu).
Wydarzenia rzeczywiste - RUM/telemetria klienta, metryki biznesowe (konwersja, udane płatności).

Wymagania: pojedynczy obraz w deskach rozdzielczych wydań i incydentów, adnotacje „wersja/kanaryjska/flaga”.

7) Projekt SLO: szablon krok po kroku

1. Opisz ścieżkę krytyczną (na przykład „depozyt kartą”).
2. Zdefiniuj SLI: sukces/błąd, próg opóźnienia, kompletność.
3. Uzgodnij SLO: 28-dniowy cel + wyjątki (zaplanowane okna).
4. Link do SLA: obowiązek prawny Faktyczne SLO.
5. Przypisz właściciela usługi, RACI i kanał alarmowy.
6. Zdefiniuj zasady ostrzegania (dwurzędowe BR) i automatyczne rolki.
7. Wdrożenie sprawozdawczości: tygodniowe przeglądy budżetu, przeglądy po incydencie.
8. Przegląd SLO co kwartał (zmiana obciążenia/architektury).

8) Przykłady SLO (szablony)

• Dostępność: '≥ 99. 95% "(28d, z wyłączeniem ogłoszonych okien ≤ 30 min/miesiąc).
• Opóźnienie: '≥ 99%' odpowiedzi '≤ 400 ms'.
• Sukces działalności gospodarczej: '≥ 98. 5% "udanych zezwoleń (filtry nadużyć są brane pod uwagę).

• Opóźnienie: „≥ 99%” wniosków „≤ 300 ms”.
• Znaczenie pamięci podręcznej: '≤ 5 min' opóźnienie 99% czasu.

• Dostawa: '≥ 99. 9% 'dla' ≤ 60 s' (koniec-koniec, z przekładkami).
• Strata: '≤ 0. Wiadomości 01% (włączona idempotencja/deduplikacja).

9) Wielobranżowy i wielopoziomowy

SLO "by cohort': kraj, dostawca płatności, segment VIP, urządzenie.
Lokalne SLO na krawędzi: metryki od punktów najbliższych użytkownikowi (krawędź/PoP).
Agregacja: Całkowity SLO nie powinien ukrywać awarii w ważnych kohortach.
Dostawcy przełączania: automatyczne trasy awaryjne na poziomie bramy SLO.

10) Deski rozdzielcze i sprawozdawczość

Płyta rozdzielcza: wersja, kanaryjska (% ruchu), SLI (sukces/opóźnienie), BR, adnotacje flagi.
Deska rozdzielcza: budżet spalania w dzień, najlepsze incydenty, MTTR, kohorty problemowe.
Sprawozdania tygodniowe: bilans budżetowy, tendencje w zakresie BR, zadłużenie techniczne (wąskie gardła), plan poprawy.

11) Procesy: incydenty, RCA i ulepszenia

Zarządzanie incydentami: alert → ocena BR → skala kanarów/flag → rollback/fix.
RCA (przyczyna główna): fakty/linie czasowe/hipotezy/korekty/kontrola efektu przez SLI.
Wyciągnięte wnioski: pozaparciowe pośmiertne, obowiązkowe pozycje działania z właścicielami i terminy.
Zamknięcie pętli: zmiany w testach, flag funkcji, limitów, buforów, przekładek, kwot.

12) Zgodność i audyt

SLO/SLI jako artefakty kontrolne (policy-as-code, logi niezmienne).
Link do wymagań (na przykład dostępność transakcji płatniczych).
Dowody: minuty alarmowe, raporty budżetowe, dzienniki wydawania/wycofywania.

13) Częste błędy i jak ich uniknąć

“99. 99% lub śmierć": nieosiągalne cele → stały alarm-hałas. Wybierz realistyczne SLO.
Średnie globalne ukryć lokalnych dips → wprowadzić kohorty.
Metryki nie e2e: wysokie SLO podczas rzeczywistej degradacji na kliencie → dodać RUM/syntetyki.
Wpisy na jednym progu → przełączyć na dwu-okienne spalanie szybkości.
Nie ma linku do zmian → wydania nie są zaznaczone, nie ma auto-rollback.

14) Lista kontrolna mini implementacji

• Opisano ścieżki krytyczne i ich SLI/SLO.
• Ustawione jest okno monitorowania i wykluczenia.
• Dwa-okienne alerty BR (szybkie i powolne) są konfigurowane.
• Deski rozdzielcze wydań i operacji z adnotacjami wersji/flag.
• Polityka budżetowa dotycząca błędów wpływa na publikacje.
• Regularne przeglądy budżetu i krajowe organy regulacyjne po incydencie.
• Właściciele dokumentacji i karty wyników.

15) Przykład obliczeń (dane szczegółowe)

Dostępność API SLO: 99. 9% w ciągu 28 dni → budżet = 0. 1%.
Przez 7 dni zgromadzone 0. 06% błędów → wykorzystał 60% tygodniowego budżetu.
W krótkim oknie 15 minut obserwuje się 2% błędów. Ważne w tym oknie jest '0. 1% × (15 min/40320 min) 0 000037%`.
Szybkość spalania jest równa 1 (dziesiątki ×) → wyzwalany jest szybki pager, kanarka wraca do 1%, flaga funkcji degrade-payments-UX włącza się, rozpoczyna się RCA.

16) Sedno sprawy

Monitorowanie SLA/SLO to nie tylko numery w sprawozdaniu, ale mechanizm zarządzania ryzykiem zmian i jakości usług. Poprawne SLIs, realistyczne SLO, zarządzanie budżetem błędów, alerty dwupoziomowe i obserwowalność e2e przekształcają metryki w rozwiązania robocze: wartość uwalniania szybciej i utrzymują przewidywalność doświadczenia użytkownika.