SLI, SLO, SLA

Trzy litery, które rządzą produkcją

Niezawodność bez pomiaru to teatr. SRE zamienia niezawodność w liczbę, uzgodnioną z wyprzedzeniem, którą każdy może zweryfikować.

Wskaźnik Poziomu Usługi (SLI): pomiar zachowania usługi. Przykłady: opóźnienie żądań, współczynnik błędów, przepustowość, głębokość kolejki. SLI to coś, co można przedstawić na wykresie.

Cel Poziomu Usługi (SLO): docelowa wartość lub zakres dla SLI. Przykład: „99,9% żądań HTTP kończy się sukcesem w okresie 28 dni.” SLO to obietnica, którą składasz sobie i swoim użytkownikom dotycząca akceptowalnej jakości usługi.

Umowa Poziomu Usługi (SLA): zobowiązanie umowne, zwykle z karami finansowymi za naruszenie. Przykład: „Zwrócimy 10%, jeśli miesięczna dostępność spadnie poniżej 99,9%.” SLA to obietnica egzekwowana przez prawników.

Kluczowe rozróżnienie: Twoja SLA musi być zawsze luźniejsza niż SLO. Jeśli wewnętrznie celujesz w 99,9%, a kontraktowo ustalasz 99,9%, nie masz żadnego marginesu. Inżynierowie SRE zazwyczaj prowadzą SLO o jedną dziewiątkę bardziej rygorystycznie niż SLA: cel 99,95%, kontrakt 99,9%. Ta różnica absorbuje nieunikniony zły tydzień.

Budżety błędów: odwrotność SLO

Od celów niezawodności do decyzji inżynierskich

SLO definiuje cel niezawodności. Budżet błędów to to, co zostaje: ilość awarii, którą możesz „wydatkować”, zanim przekroczysz cel.

Jeśli Twoje SLO obiecuje 99,9 % sukcesów w ciągu 28 dni, Twój budżet błędów wynosi 0,1 % żądań, czyli około 40 minut całkowitego przestoju miesięcznie. Ten budżet możesz wydać dowolnie: na planowane wdrożenia, eksperymentalne funkcje, chaos engineering czy tolerowanie wadliwej zależności.

Budżety błędów zmieniają konflikt między dev a ops. Bez budżetu każda awaria prowadzi do sporu o to, kto wprowadził złą zmianę i jak zapobiec kolejnej. Z budżetem:

- Budżet pozostał: wdrażaj szybciej, podejmuj większe ryzyko, przeprowadzaj eksperymenty. Budżet za to płaci.

- Budżet wyczerpany: przestań wdrażać nowe funkcje, zamroź ryzykowne zmiany, skup się na pracy nad niezawodnością, aż budżet się odbuduje.

Dzięki temu niezawodność przestaje być emocjonalnym sporem, a staje się mierzalnym zasobem. Inżynierowie mogą świadomie wydawać budżet, tak jak każdy inny zasób produkcyjny.

Definiowanie Toilu

Co liczy się jako Toil

Nie każde zadanie operacyjne kwalifikuje się jako toil. SRE definiuje toil precyzyjnie: praca, która jest manualna, powtarzalna, automatyzowalna, taktyczna, pozbawiona trwałej wartości i skaluje się liniowo wraz ze wzrostem usługi.

Wszystkie sześć właściwości musi być spełnionych. Jednorazowa migracja danych jest manualna, ale nie powtarzalna: nie kwalifikuje się jako toil. Starszy inżynier projektujący nową architekturę usługi podejmuje decyzję taktyczną, ale dodaje trwałą wartość: nie kwalifikuje się jako toil.

Przykłady, które kwalifikują się jako toil:

- Ręczne restartowanie usługi po awarii spowodowanej wyciekiem pamięci

- Wklejanie fragmentów logów do kanału czatu podczas triage'u incydentu

- Wypełnianie formularza zgłoszenia w celu udostępnienia nowej bazy danych

- Ręczne uruchamianie kwartalnego raportu pojemności

- Zatwierdzanie rutynowych żądań wdrożeń pojedynczo

Zasada pięćdziesięciu procent ogranicza toil do połowy czasu inżyniera SRE. Powyżej 50 % zespół musi przekazać odpowiedzialność z powrotem do zespołu produktowego lub zatrudnić więcej inżynierów, ale cel pozostaje jasny: dążyć do zera toil, zastępując go systemami inżynieryjnymi, które wykonują tę samą pracę bez interwencji człowieka.

Automatyzacja nie tylko oszczędza czas. Usuwa całkowicie pewną klasę błędów ludzkich. Skrypt, który udostępnia bazę danych, nie pomija kroków po długiej zmianie.

Uzasadnienie audytu toil

Twój zespół śledzi, jak spędza swój czas. W ostatnim kwartale rozkład był następujący: 30 % wdrożeń, 25 % reagowania na incydenty, 20 % prac pojemnościowych, 15 % inżynierii funkcjonalności, 10 % jednorazowych żądań od zespołów produktowych.

Higiena dyżurów

Inżynierowie, nie pagery

Dyżur niesie ze sobą realny koszt. Sen jest przerywany, weekendy zakłócane, a stres wynikający z nieznanych problemów narasta. SRE traktuje dyżur jako ograniczony zasób, który musi pozostać zrównoważony, a nie jako heroiczne obciążenie spoczywające na tych, którym najbardziej zależy.

Zdrowe rotacje dyżurowe opierają się na kilku zasadach:

- Wynagradzany czas: godziny dyżuru przekładają się na czas wolny, dodatkowe wynagrodzenie lub porównywalne świadczenie. Darmowy dyżur wypala zespół.

- Rozsądna głębokość rotacji: zespół sześcioosobowy z dyżurem podstawowym i zapasowym oznacza, że każdy inżynier pełni dyżur raz na trzy tygodnie. Rotacje dwuosobowe niszczą kariery.

- Budżet na liczbę zgłoszeń: książka SRE Google sugeruje maksymalnie dwa zdarzenia powodujące powiadomienie na dwunastogodzinną zmianę. Powyżej tej liczby zespół musi poświęcić czas inżynieryjny na zmniejszenie liczby alertów, a nie tylko je znosić.

- Tylko alerty wymagające działania: każde powiadomienie musi wymagać interwencji człowieka. Jeśli alert miałby być ignorowany, zautomatyzowany lub powtarzał się podczas normalnej pracy, nie powinien istnieć. Zmęczenie alertami to defekt niezawodności.

- Przekazywanie dyżuru „za słońcem”: zespoły rozproszone globalnie przekazują zmiany na granicach stref czasowych, dzięki czemu nikt nie otrzymuje powiadomień o 3 nad ranem, chyba że system naprawdę nie może czekać do rana.

Blameless Postmortems

Jak awarie stają się ulepszeniami

Każdy poważny incydent ma swój postmortem: pisemną analizę tego, co się stało, dlaczego, co to naprawiło i jakie zmiany zapobiegają powtórzeniu. Postmortem to odpowiednik procentu składanego w SRE: każdy z nich dodaje trwałą niezawodność do systemu.

Blameless oznacza, że dokument przypisuje awarie systemom i procesom, nigdy osobom. Jeśli inżynier wykonał niewłaściwą komendę, postmortem pyta: dlaczego system pozwolił na tę komendę? Dlaczego żadne zabezpieczenie jej nie wychwyciło? Jaka zmiana w systemie, dokumentacji lub narzędziach zapobiegłaby popełnieniu tego samego błędu przez kolejnego inżyniera?

Blamelessness istnieje z jednego powodu: ludzie ukrywają błędy, gdy boją się kary. Ukryte błędy stają się kolejnym incydentem. Koszt kultury blameless jest niski w porównaniu z kosztem gromadzenia niewykrytych defektów.

Postmortemy zazwyczaj obejmują:

- Podsumowanie: jednoakapitowy opis incydentu i jego wpływu

- Oś czasu: rekonstrukcja minuta po minucie z sygnaturami czasowymi

- Analiza przyczyn źródłowych: czynniki techniczne i procesowe, które umożliwiły awarię

- Wykrycie: w jaki sposób zespół dowiedział się o incydencie i ile to zajęło czasu

- Rozwiązanie: działania podjęte w celu przywrócenia usługi

- Wnioski: co zadziałało, a co nie

- Zadania do wykonania: konkretne, przypisane, ograniczone czasowo zadania inżynieryjne

Zadania do wykonania znajdują się w trackerze. Są priorytetyzowane tak jak każda inna praca inżynieryjna. Postmortemy bez zadań do wykonania sprowadzają się do opowiadania historii. Praca nic nie zmienia.

Cztery Złote Sygnały

Co musi mierzyć każda usługa

Książka SRE Google proponuje cztery sygnały, które musi udostępniać każda usługa skierowana do użytkowników: opóźnienie, ruch, błędy i nasycenie. Razem opisują one stan usługi z perspektywy użytkownika. Monitorowanie z mniejszą liczbą sygnałów pozostawia martwe punkty; monitorowanie setek metryk przytłacza zespół zmęczeniem alertami.

Opóźnienie: jak długo trwają żądania. Śledź rozkłady, nie średnie. p50 (mediana) opisuje typowe doświadczenie. p99 opisuje najgorsze 1% użytkowników. Sama średnia ukrywa długie ogony: usługa z medianą 50 ms i p99 5 000 ms wygląda dobrze na średniej, ale psuje doświadczenie jednemu użytkownikowi na sto.

Ruch: zapotrzebowanie na usługę. Dla usługi webowej oznacza to żądania na sekundę. Dla usługi streamingowej – jednoczesne połączenia. Dla zadania wsadowego – przetworzone elementy na minutę. Ruch koreluje z decyzjami o pojemności i ujawnia anomalie obciążenia.

Błędy: wskaźnik nieudanych żądań. Liczą się zarówno jawne błędy (HTTP 500), jak i ukryte (HTTP 200 z uszkodzonymi danymi) oraz błędy polityki (odpowiedź zbyt wolna, by spełnić SLO). Rozróżnianie tych przypadków ma znaczenie: odpowiedź 200 z błędnym ładunkiem często szkodzi użytkownikom bardziej niż uczciwe 500.

Nasycenie: jak mocno obciążony jest system. Wykorzystanie CPU, głębokość kolejki, presja pamięci, zajętość puli połączeń. Nasycenie pozwala przewidywać przyszłe opóźnienia: system pracujący przy 95% CPU ma bardzo mało zapasu, zanim opóźnienia widoczne dla użytkownika gwałtownie wzrosną.

Większość alertów SRE wywodzi się z tych czterech sygnałów. Alertowanie oparte na objawach (alarm, gdy zauważą to użytkownicy) działa lepiej niż alertowanie oparte na przyczynach (alarm, gdy CPU przekracza 80%). Cztery złote sygnały opisują objawy.

Ścieżki kariery SRE

Gdzie umiejętności SRE się opłacają

Kariery SRE rozchodzą się w zależności od tego, która część dyscypliny najbardziej odpowiada inżynierowi:

Inżynier SRE infrastruktury: buduje platformy, na których działają inne zespoły. Kubernetes, service mesh, wewnętrzna chmura. Dużo inżynierii systemów, teorii systemów rozproszonych i projektowania platform. Bardzo dobrze płatna praca w dużych firmach, ponieważ praca skaluje się: jeden inżynier SRE infrastruktury wspiera setki inżynierów produktowych.

Wbudowany SRE: współpracuje z zespołem inżynierów produktowych, aby poprawić niezawodność konkretnej usługi. Połówka inżyniera, połówka coacha. Silne umiejętności komunikacyjne i przeglądu kodu są równie ważne jak głęboka wiedza techniczna. Często najlepsza ścieżka dla inżynierów, którzy lubią uczyć.

Narzędzia niezawodności: buduje stos obserwowalności: monitoring, alertowanie, dashboardy, narzędzia do post-mortem, platformy zarządzania incydentami. Dużo pracy frontendowej i inżynierii danych. Wyniki są wykorzystywane przez wszystkie inne zespoły.

Inżynieria produkcji: termin Facebooka/Mety na SRE skupionego na pojemności, wdrażaniu i zarządzaniu ruchem. Dużo pracy sieciowej i systemowej.

Certyfikaty techniczne warte posiadania: Google Cloud Professional Cloud Architect, AWS Solutions Architect Professional oraz certyfikaty CNCF (Kubernetes Administrator, Kubernetes Application Developer) świadczą o znajomości technologii cloud-native. Certyfikaty Linux Foundation potwierdzają głęboką wiedzę systemową. Żaden z nich nie zastępuje pracy nad portfolio, ale pomagają przejść przez sito rekruterów.

Podsumowanie

Co już wiesz

Site reliability engineering narodziło się w Google jako odpowiedź na problem skalowalności i rozwinęło się w dyscyplinę stosowaną obecnie w całej branży. Poznałeś:

- Przejście od ręcznych operacji do inżynierii niezawodności

- SLI, SLO, SLA oraz koncepcję budżetu błędów (inverse-SLO)

- Definicję toilu, zasadę 50% oraz redukcję toilu poprzez inżynierię

- Zrównoważone dyżury on-call oraz praktykę bezwinnych post-mortemów

- Cztery złote sygnały jako punkt wyjścia do monitorowania usług

- Ścieżki kariery SRE oraz certyfikaty otwierające drzwi do zawodu

Dwa pomysły mają największe znaczenie. Niezawodność to liczba, uzgodniona z wyprzedzeniem. A toil to defekt, nie opis stanowiska. Zachowaj te dwa założenia, a reszta SRE wynika naturalnie.

Polecane lektury: książka Google SRE (darmowa online: sre.google/books/), SRE Workbook z praktycznymi ćwiczeniami oraz teksty Charity Majors na temat observability. Lekcja geometry-of zagłębia się w wizualną strukturę leżącą u podstaw praktyki SRE: rozkłady opóźnień, stożki budżetu błędów, grafy zależności oraz układy dashboardów.