Co to jest site reliability engineering? Wyjaśnienie SRE

Co to jest site reliability engineering? To sposób prowadzenia systemów produkcyjnych za pomocą inżynierii oprogramowania zamiast ręcznych operacji. Zespół SRE ustala liczbowy cel niezawodności, mierzy go i automatyzuje powtarzalną pracę, dzięki której usługi działają. Gdy co miesiąc o trzeciej w nocy odzywa się ten sam alert o zapełnionym dysku, to właśnie problem, który SRE ma usunąć.

Google ukuł ten termin około 2003 roku. Dziś idea jest stosowana daleko poza Google, od 20-osobowych startupów po banki. Różni się skala, a nie podstawowa mechanika.

Czym zajmuje się inżynier niezawodności?

Ben Treynor Sloss, który zakładał zespół SRE w Google, ujął to prosto w pierwszym rozdziale książki Google SRE: SRE to to, co powstaje, gdy poprosi się inżyniera oprogramowania o zaprojektowanie zespołu operacyjnego. Praca operacyjna jest wykonywana kodem.

Typowy tydzień obejmuje cztery rzeczy. Definiuje się, co znaczy „działa” dla danej usługi. Buduje się monitoring, który pokaże, kiedy tak nie jest. Reaguje się, gdy coś się psuje, i pisze poprawkę, żeby następna osoba nie dostała alertu z tego samego powodu.

Dwa przykłady pokazują to konkretnie. Zespół, który co czwartek wdraża ręcznie, buduje potok z automatycznym wycofywaniem zmian. Zespół, który co noc restartuje przeciekającą usługę, w końcu znajduje wyciek. W obu przypadkach powtarzalna czynność staje się jednorazowym projektem, i o to właśnie chodzi.

Czwarta część to ta, którą zespoły najczęściej pomijają. Inżynier SRE, który jedynie reaguje na incydenty, jest administratorem z nowym tytułem. Część inżynierska to to, co odróżnia tę rolę.

Czym SRE różni się od DevOps?

DevOps to kultura: programiści i operatorzy wspólnie odpowiadają za to, co trafia na produkcję i jak tam działa. Mówi, że mur między zespołami jest problemem. Nie mówi jednak, ile przestojów jest dopuszczalnych ani kiedy przestać wdrażać.

SRE dostarcza liczb. Oferuje cele poziomu usług (SLO), budżety błędów i limit ręcznej pracy. Google przedstawia SRE jako jeden konkretny sposób wdrażania idei DevOps.

Nie warto spierać się o to, które podejście jest „lepsze”. Zespół z ośmiu osób i tak zapożyczy coś z obu. Ważniejsze pytanie brzmi, czy zespół potrafi w jednym zdaniu powiedzieć, jak niezawodna musi być dana usługa.

Czym są SLI, SLO i SLA i dlaczego mają znaczenie?

Trzy skróty niosą większość ciężaru w SRE, a ludzie ciągle je mylą.

• SLI (wskaźnik poziomu usługi): pomiar. Na przykład odsetek żądań HTTP, które zwracają odpowiedź inną niż 5xx w czasie poniżej 300 ms.

• SLO (cel poziomu usługi): wartość docelowa dla tego pomiaru. Na przykład 99,9% żądań w ruchomym oknie 28 dni.

• SLA (umowa poziomu usługi): kontrakt z konsekwencjami, zwykle zwrotami, gdy cel nie zostanie spełniony. SLA powinno być luźniejsze niż SLO.

Powód, dla którego warto się tym zajmować, jest prosty. Stwierdzenie „strona ma być szybka i niezawodna” nie da się przetestować. Cel w rodzaju „99,9% żądań do koszyka kończy się sukcesem w czasie poniżej 500 ms” da się sprawdzić i daje sposób na rozstrzyganie sporów.

Zacznij od dwóch lub trzech SLI na usługę. Więcej nikt nie zapamięta.

W praktyce dobry test jest prosty. Zapytaj zespół, czy klient zauważyłby, gdyby dany wskaźnik spadł o połowę. Jeśli odpowiedź brzmi „nie”, to prawdopodobnie mierzysz coś wewnętrznego, co wygląda ładnie na wykresie, ale nie mówi nic o doświadczeniu osób korzystających z produktu.

Wybieraj SLI, które odczuwają użytkownicy. Użycie CPU jest przyczyną, a nie objawem. Nieudane płatności, wolne ładowanie stron i nieaktualne dane to rzeczy, które klient faktycznie zauważa.

Jak działają budżety błędów?

Budżet błędów to niesprawność, na którą pozwala SLO. Jest to po prostu 1 minus SLO. Cel dostępności 99,9% zostawia 0,1%, czyli około 43 minut przestoju w 30-dniowym miesiącu.

Oto mała wersja w kodzie, bo sama arytmetyka jest całą ideą:

slo = 0.999
window_minutes = 30 * 24 * 60          # 43,200
budget = (1 - slo) * window_minutes    # 43.2 minuty
spent = 31                              # minuty złej usługi do tej pory
print(f"{budget - spent:.1f} minuty pozostało")  # 12.2 minuty pozostało

Dopóki budżet jest w zapasie, zespół wdraża szybko. Gdy się wyczerpie, nowe funkcje są wstrzymywane, a praca przechodzi na niezawodność. Przykład polityki budżetu błędów w SRE Workbook pokazuje, jak zespół spisuje taką zasadę.

Dobrze działający budżet ma jeszcze jedną zaletę: porządkuje rozmowę. Zamiast pytać, kto zawinił, zespół pyta, ile budżetu zostało i co z tym zrobić. To zmienia ton spotkań po incydentach.

Chodzi nie o karanie. Budżet zastępuje stary spór, w którym programiści chcą wdrażać, a operatorzy stabilności, wspólną liczbą, którą obie strony mogą odczytać. Działa tylko wtedy, gdy kierownictwo z góry zgadza się uszanować wstrzymanie. Polityka, którą co kwartał się nadpisuje, jest tylko dekoracją.

Dlaczego istnieje zasada 50% pracy operacyjnej?

Toil to ręczna, powtarzalna praca, która rośnie wraz z usługą i nic po sobie nie zostawia. Ręczny restart zablokowanego workera to toil. Napisanie health checka, który restartuje go automatycznie, to już inżynieria.

Organizacja SRE w Google dąży do tego, aby toil nie przekraczał 50% czasu każdego inżyniera, jak opisano w rozdziale o eliminowaniu toilu. Reszta idzie na projekty, które ograniczają przyszły toil, albo na nowe funkcje. Uzasadnienie jest bezpośrednie: toil rozrasta się do 100% czasu wszystkich, jeśli nikt go nie powstrzyma.

Traktuj 50% jako sufit, a nie cel. Zdrowy zespół przy dojrzałej usłudze mieści się wyraźnie poniżej tej granicy. Jeśli przez cały kwartał jest powyżej, to nie prowadzi SRE, tylko kolejkę operacyjną.

Ta praca zwykle nie wygląda spektakularnie. Ręczne przepisywanie konfiguracji, ponowne uruchamianie usług po nocnej aktualizacji czy ręczne sprawdzanie, czy kolejka się opróżniła, to typowe przykłady. Każda z tych czynności z osobna wydaje się drobna, ale razem zjadają czas, który mógłby pójść na poprawę systemu.

Prosty sposób na start: przez dwa tygodnie oznaczaj każde zgłoszenie i każdy alert jako toil albo projekt. Następnie uszereguj toil według godzin. Trzy najwyżej pozycje tworzą backlog automatyzacji.

Co zmieniają postmortemy bez winnych?

Gdy coś się psuje, postmortem pyta, jak system pozwolił człowiekowi popełnić ten błąd, a nie kto go popełnił. Obwinianie uczy ludzi ukrywania informacji. Przegląd bez winnych uczy ich, żeby je zapisywać.

Dobry postmortem jest krótki i ma cztery części: oś czasu, czynniki przyczynowe, to, co poszło dobrze, oraz działania naprawcze z właścicielami i terminami. Działania bez właściciela są życzeniami.

Większość wartości bierze się z realizacji. Otwarte działania warto przeglądać co miesiąc. Jeśli ta sama przyczyna pojawi się dwa razy w ciągu sześciu miesięcy, pierwszy postmortem się nie udał, bez względu na to, co zawierał dokument.

Jakich narzędzi zespół SRE potrzebuje najpierw?

Niewielu. Zacznij od sygnałów, a dopiero potem dodawaj dyżury i automatyzację.

1. Metryki i dashboardy. Tyle, by wyliczyć SLI. Grafana i Prometheus to popularna para open source, a Datadog i New Relic to wersja hostowana.

2. Alerting powiązany z SLO. Alarmuj, gdy budżet szybko się zużywa, a nie gdy jeden host skacze. Mniej alertów, lepszych alertów.

3. Flagi funkcji i stopniowe wdrażanie. Większość awarii następuje po zmianie, więc najtańszym zyskiem na niezawodności jest możliwość cofnięcia zmian. LaunchDarkly i Statsig pokrywają tę potrzebę.

4. Pisana instrukcja (runbook) dla każdego alertu. Jeśli alert nie ma runbooka, trzeba go napisać albo usunąć alert.

Narzędzia nie zastąpią decyzji. Najpierw trzeba wiedzieć, co ma być mierzone i kto reaguje na alert, a dopiero potem wybrać produkt. Ten porządek wydaje się oczywisty, ale w praktyce bywa odwrotny, bo zakup jest prostszym krokiem niż ustalenie celów.

Kupuj lub buduj w tej kolejności. Zespoły, które zaczynają od zakupu narzędzia bez SLO, kończą z ładnymi dashboardami, które nic konkretnego nie mierzą.

Gdzie w SRE mieści się czytanie nieznanego kodu?

Tej części nikt nie wpisuje do opisu stanowiska. Podczas incydentu inżynier SRE często musi zrozumieć usługę, której nie napisał, w repozytorium, którego nie otwierał od miesięcy. Pytanie rzadko jest abstrakcyjne. Brzmi zwykle: „gdzie leży ta pętla ponawiania i co robi przy przekroczeniu czasu?”

Ten schemat zna każdy: grep, blame, a potem wiadomość do osoby, która ostatnio dotykała pliku. W repozytorium z 80 tys. linii to działa. Przy dwunastu usługach należących do sześciu zespołów pochłania to pierwsze 20 minut incydentu, a te minuty liczą się do budżetu błędów.

Ten wątek ma praktyczną wagę dla zespołów, które utrzymują wiele usług naraz. Każda minuta spędzona na szukaniu, gdzie coś jest zaimplementowane, to minuta, w której usługa pozostaje niesprawna albo w której osoba dyżurna nie podejmuje decyzji. Dlatego sprawne poruszanie się po kodzie jest częścią niezawodności, a nie tylko wygodą programisty.

Tu narzędzie do wyszukiwania kodu, które odpowiada na pytania o własne repozytorium, zarabia na swoje miejsce. Na przykład: gdzie usługa ustawia timeouty i od których wywołań te timeouty zależą. Nie naprawi awarii. Skraca czas czytania przed podjęciem działania, a ten czas da się zmierzyć.

Czy SRE to przesada dla Twojego zespołu i jak zacząć?

Dedykowany zespół SRE można pominąć, jeśli jest jedna usługa, kilku inżynierów i użytkownicy, którzy znoszą sporadyczną złą godzinę. Zespół nie jest wtedy potrzebny. Potrzebne są SLO, sensowny alert i ktoś, kto odpowiada za dyżur.

Warto rozważyć SRE, gdy spełniony jest któryś z warunków: awarie kosztują realne pieniądze, dyżury wyczerpują ludzi albo programiści są spowalniani przez doraźne prośby operacyjne. Wiele firm zaczyna od tego, że jeden lub dwóch inżynierów pracuje częściowo jako SRE, i sprawdza, jak to działa.

Częsty błąd to przemianowanie zespołu operacyjnego na „SRE" bez zmiany sposobu pracy. Jeśli zespół nadal zajmuje się zgłoszeniami i ręcznymi wdrożeniami i nie ma budżetu błędów, zmienił się tytuł, a nic poza tym.

Jak zacząć w przyszłym tygodniu

Nie trzeba reorganizacji. Wybierz jedną usługę widoczną dla użytkowników, która najbardziej boli, i zrób pięć rzeczy.

1. Zapisz jedno SLI i jedno SLO dla tej usługi. Niech będą proste.

2. Policz budżet błędów i umieść go na dashboardzie, który widzi cały zespół.

3. Śledź toil przez dwa tygodnie i wybierz najwyżej pozycję do automatyzacji.

4. Przeprowadź postmortem bez winnych po następnym incydencie, z przypisanymi działaniami.

5. Ustal na piśmie, co się dzieje, gdy budżet dojdzie do zera.

Jeśli za miesiąc zespół mniej spiera się o to, czy wdrażać, a bardziej o to, co pokazują liczby, to znaczy, że działa. Jeśli budżet nigdy się nie rusza, bo SLO jest zbyt luźne, trzeba je zaostrzyć.