Czym jest site reliability engineering SRE? Poradnik

Czym jest site reliability engineering SRE? To podejście, w którym operacje traktuje się jak problem programistyczny: ustawiasz mierzalny cel niezawodności, liczysz, jak często go nie trzymasz, i pozwalasz tej liczbie zdecydować, czy wypuszczasz nowe funkcje, czy naprawiasz to, co się sypie. Termin wymyślił Google, ale idea działa w każdej skali. Dla dewelopera solo z jedną aplikacją i garstką użytkowników oznacza to tyle, że z góry ustalasz, ile przestoju jesteś gotów zaakceptować.

Problem w praktyce jest taki, że większość side projektów nie ma żadnej takiej liczby. Są „w porządku” do momentu, aż ktoś napisze do ciebie maila. Ten przewodnik wyjaśnia SRE prostym językiem, a potem zmniejsza je do wersji, którą jedna osoba jest w stanie utrzymać w weekend.

Czym tak naprawdę jest site reliability engineering?

Najkrótsza wersja pochodzi z książki o SRE od Google'a: SRE to to, co dostajesz, gdy poprosisz inżyniera oprogramowania o zaprojektowanie zespołu operacyjnego. Zamiast ludzi, którzy ręcznie restartują serwery, piszesz kod, który to robi, i mierzysz wyniki.

Za większością tego stoją trzy idee. Niezawodność to funkcja z celem, a nie poczucie. Powtarzalna praca ręczna (książka nazywa to toil) to błąd, który trzeba zautomatyzować. Awarie są wliczone w koszt, więc planujesz, jak się z nich uczyć, zamiast szukać winnych.

DevOps i SRE mocno się pokrywają. Praktyczna różnica jest taka: DevOps to kultura wspólnego wdrażania i utrzymywania kodu, a SRE daje konkretne narzędzia, żeby się o to kłócić liczbami. Do korzystania z liczb nie trzeba wybierać obozu.

W dużej firmie SRE dzieli czas między dyżury, reagowanie na incydenty, planowanie pojemności i automatyzację. Książka Google'a mówi, żeby ograniczyć pracę operacyjną do mniej więcej połowy czasu inżyniera, tak by reszta szła na rozwój. Ten limit jest ograniczeniem projektowym, a nie miłym dodatkiem.

Flagi funkcji dobrze pokazują to podejście. Flaga pozwala wyłączyć zły release w kilka sekund, bez ponownego wdrożenia, a to chroni budżet. Czy potrzebujesz do tego hostowanego narzędzia, zależy od liczby flag: zmienna środowiskowa wystarczy na pierwsze trzy.

SLI, SLO, SLA: trzy skróty, jedna idea

SLI (service level indicator) to coś, co mierzysz. Dla aplikacji webowej zwykle jest to odsetek udanych żądań albo odsetek odpowiedzi szybszych niż 300 ms. Wybierz jeden albo dwa wskaźniki, nie dwanaście.

SLO (service level objective) to cel, który stawiasz na tym pomiarze, na przykład „99,9% żądań kończy się sukcesem w ciągu 30 dni”. To cel wewnętrzny, obietnica składana samemu sobie.

SLA (service level agreement) to umowa z klientem, zwykle z zwrotem pieniędzy, jeśli cel nie zostanie spełniony. Jeśli nikt nie płaci ci za uptime, to nie masz jeszcze SLA i nie powinieneś przypadkiem napisać go w tekście cennika.

Error budget: to, co zmienia sposób pracy

Error budget to po prostu 100% minus twój SLO. Cel 99,9% w ciągu 30 dni zostawia około 43 minut dozwolonej awarii. To budżet, który możesz wydać na ryzykowne wdrożenia, migracje i eksperymenty.

Najważniejsza jest reguła dołączona do budżetu. Dopóki budżet jest, wypuszczasz zmiany. Kiedy się skończy, przestajesz dowozić funkcje i naprawiasz niezawodność, aż budżet się odbuduje. Rozdział książki o ryzyku opisuje to jako sposób na rozstrzygnięcie sporu między „szybciej” a „nie psuj” wspólną liczbą zamiast negocjacjami.

Jest tu też mocna uwaga, którą warto powtórzyć: 100% prawie nigdy nie jest właściwym celem. Użytkownicy na kiepskich sieciach komórkowych nie odróżnią 99,99% od 99,9%, a każda kolejna dziewiątka kosztuje wyraźnie więcej niż poprzednia. To nie jest cel idealny. To cel, z którym da się pracować.

W praktyce budżet jest najbardziej użyteczny przy decyzjach, które i tak podejmujesz. Migracja bazy, zmiana dostawcy płatności albo przepisanie kolejki to momenty, w których pytasz, czy stać cię na ryzyko. Jeśli zostało ci 20 minut budżetu w tym miesiącu, odkładasz migrację na przyszły tydzień. Jeśli zostało 40, robisz ją dziś po południu, z oknem serwisowym i planem wycofania. Nie potrzebujesz spotkania, żeby to ustalić, bo liczba już podjęła decyzję.

Jeśli chcesz konkretny przebieg wyboru wskaźników i napisania pierwszego celu, workbook SRE o wdrażaniu SLO to najbardziej praktyczny rozdział, a do tego krótki.

Czy SRE ma sens, gdy budujesz sam?

Trzy powody, żeby to zrobić, i jeden, żeby tego nie robić.

Powody: twój projekt prędzej czy później cię obudzi; zapisany cel powstrzymuje przed przeinżynierowaniem; a „prowadzę produkcję z SLO” dobrze wygląda, gdy ktoś decyduje, czy cię zatrudnić albo ci zaufać. Powód przeciw: jeśli projekt nie ma jeszcze użytkowników, ćwiczysz rozwiązywanie problemu, którego nie masz. Najpierw zbuduj, mierz, gdy ktoś na tym polega.

Więc pomiń pełny aparat. Nie płać za usługę pagera do projektu hobbystycznego, nie stawiaj Kubernetesa, żeby wyglądać poważnie, i nie pisz dziesięciostronicowego szablonu incydentu. Warto zrobić to nawet przy dziesięciu prawdziwych użytkownikach: health check, jeden SLO i jedno miejsce, w którym zaglądasz, kiedy coś padnie.

Konfiguracja na jeden wieczór dla side projektu

Minimum, które zwykle wytrzymuje też przy 10 000 użytkowników, zajmuje jeden wieczór. Testowane. Nieoptymalne. Robimy to mimo to, bo jest nudne, a nudne przetrwa.

Po pierwsze wybierz jeden SLI: odsetek żądań HTTP, które zwróciły coś innego niż 5xx. Po drugie ustaw SLO na 99,5% w ciągu 30 dni, czyli około 3,6 godziny budżetu. Zacznij luźno, zaostrzysz później. Po trzecie dodaj zewnętrzny uptime check, który uderza w prawdziwy endpoint zdrowia.

Endpoint zdrowia wart uwagi sprawdza rzeczy, które faktycznie się psują, a nie tylko to, czy proces żyje:

// GET /healthz
app.get("/healthz", async (req, res) => {
  try {
    await db.query("select 1");          // baza danych odpowiada
    await cache.ping();                  // cache odpowiada
    res.status(200).json({ ok: true });
  } catch (err) {
    res.status(503).json({ ok: false });
  }
});

Kod nie musi być elegancki. Ważne, żeby endpoint zwracał 503, gdy baza nie odpowiada, bo to właśnie ten sygnał uruchamia alert. Sprawdź to raz ręcznie, odłączając bazę lokalnie, zanim uwierzysz, że działa. Test, który nigdy nie widział awarii, daje fałszywe poczucie bezpieczeństwa.

Po czwarte wyślij alerty tam, gdzie je zobaczysz, czyli na push w telefonie, a nie do skrzynki. Po piąte prowadź zwykły plik tekstowy postmortems.md i po każdej awarii dopisz cztery linijki: co się stało, dlaczego, jak długo trwała i co się zmienia. Ten plik to najbardziej niedoceniane narzędzie niezawodności, jakie będziesz mieć.

Gdzie AI pomaga, a gdzie nie

Asystenci są przyzwoici w części „toil”: napiszą health check, Terraform dla monitora uptime, pierwszy szkic runbooka albo skrypt, który liczy odsetek 5xx z logów. Są słabi w ustalaniu SLO, bo to decyzja produktowa o tym, co użytkownicy tolerują.

Podczas incydentu bądź ostrożny. Asystent może zaproponować wiarygodnie brzmiącą poprawkę, którą zastosujesz na produkcji o drugiej w nocy bez czytania. Używaj go, żeby wyjaśnił stack trace albo napisał szkic postmortemu już po wszystkim, a decyzję o rollbacku zostaw człowiekowi, który jest przytomny.

Jedna praktyczna rada: zanim poprosisz asystenta o cokolwiek w konfiguracji monitoringu, zapisz w jednym zdaniu, co dokładnie ma zostać sprawdzone i co oznacza wynik. Model zwykle wygeneruje ładny kod, ale nie wie, czego ty oczekujesz od swojego systemu. Różnica między kodem, który działa, a kodem, który mierzy to, co trzeba, jest dokładnie tym, czym zajmuje się SRE. Kod z asystenta przeglądasz tak samo jak każdy inny, a test piszesz tak, żeby dało się go celowo zepsuć.

Bramki jakości kodu też wchodzą w ten obraz. Wiele awarii wynika ze zmiany, która w review wyglądała niewinnie. Analiza statyczna w CI nie da ci niezawodności, ale usuwa klasę głupich błędów, zanim zdążą kosztować budżet.

Alerty na burn rate i postmortem, który ktoś przeczyta

Częsty błąd początkujących to alarmowanie za każdym razem, gdy pojedyncze żądanie się nie uda. Po tygodniu wyciszysz kanał. Lepszy sygnał to burn rate: jak szybko zużywasz error budget w porównaniu z tempem, które wyczerpałoby go dokładnie na końcu okna.

Dla side projektu trzymaj to prosto. Wyślij push, jeśli odsetek błędów w ostatnich 10 minutach przekracza 5%, i podsumowanie mailem, jeśli tygodniowy wynik zmierza do niespełnienia SLO. Masz dwa poziomy: obudź się teraz albo spójrz w poniedziałek. Coś bardziej wymyślnego może poczekać, aż użytkownicy poskarżą się na pierwszy poziom.

Zanim ustawisz pierwszy alert, zrób listę tego, co zrobisz, gdy zadzwoni. Jeśli odpowiedź brzmi „nic, zobaczę jutro”, alert nie ma sensu, bo nie zmieni twojego zachowania. Dobry alert kończy się konkretnym krokiem: restartem workera, rollbackiem ostatniego wdrożenia albo wyłączeniem flagi. Jeśli takiego kroku nie ma, zostaw sygnał w tygodniowym podsumowaniu i nie budź się o trzeciej w nocy bez powodu.

Postmortem zrób krótki i bez winnych. Bez winnych nie znaczy, że nikt nie odpowiada. Znaczy, że pytasz, co w systemie pozwoliło na błąd, a nie kto go popełnił. Gdy jesteś jedyną osobą w zespole, ma to większe znaczenie, niż się wydaje, bo kusi, żeby tylko poczuć się źle i pominąć spisanie.

Wystarczą cztery nagłówki: co się stało, dlaczego, jak długo użytkownicy byli dotknięci i co się zmienia. Ostatni punkt powinien wskazywać działanie, które naprawdę wykonasz, z datą. „Uważać bardziej” to nie jest działanie. „Dodać sprawdzenie migracji na stagingu przed następnym release’em” już jest.

Po roku ten plik staje się mapą twoich słabych punktów. Reguła, którą z tego wyciągnąłem po trzech awariach z powodu tego samego wygasłego certyfikatu: jeśli ta sama przyczyna pojawia się dwa razy, automatyzujesz ją. Dodanie monitoringu odnowień zajęło jeden wieczór i od tamtej pory problem się nie powtórzył.

Czy SRE to dobra ścieżka dla dewelopera, który lubi budować?

Zależy, co lubisz. Role SRE pasują ludziom, którzy bardziej cenią systemy, tryby awarii i automatyzację niż wysyłanie interfejsów. Jeśli satysfakcję daje ci cichszy pager, to ci się spodoba. Jeśli chcesz patrzeć, jak użytkownicy klikają twoją nową funkcję, prawdopodobnie nie.

Wejście zwykle idzie przez pracę backendową albo infrastrukturalną: najpierw przejmujesz deploye i alerty jednej usługi, potem bierzesz na siebie więcej jej niezawodności. Umiejętności, które się przenoszą: podstawy Linuksa, sieci, jeden dostawca chmury, stos monitoringu i nawyk spisywania rzeczy. Side projekty są dobrym miejscem, żeby to wszystko ćwiczyć, bo jesteś całym zespołem.

Wybierz jedną rzecz, którą już uruchamiasz, nawet darmową aplikację na free tierze. Zapisz jej SLI, SLO i dokładne działanie, które podejmiesz, gdy budżet się skończy. Jeśli nie potrafisz powiedzieć, z czego byś zrezygnował, ta liczba jest tylko dekoracją. Który z twoich projektów zauważyłbyś jako niedostępny, zanim powiedziałby ci o tym użytkownik?