Blog JSystems - uwalniamy wiedzę!
Blog JSystems - uwalniamy wiedzę!
SRE, czyli Site Reliability Engineering (inżynieria niezawodności usług), to jedno z tych pojęć, które brzmią jak nowy tytuł dla starego administratora, a w rzeczywistości oznaczają zupełnie inny sposób myślenia o utrzymaniu oprogramowania. W tym przewodniku wyjaśnimy po kolei, czym SRE naprawdę jest, na czym polega jego słynna matematyka niezawodności (wskaźniki SLI, cele SLO i budżet błędów) i jakich narzędzi używa na co dzień. Wszystkie zrzuty pochodzą z prawdziwego, działającego monitoringu, a nie z prezentacji.
SRE to podejście do utrzymania oprogramowania, w którym niezawodność traktuje się jak problem inżynierski, a nie jak dyżur przy gaszeniu pożarów. Zamiast reagować na awarie ręcznie, inżynier SRE mierzy niezawodność liczbami, ustala dla niej konkretne cele i pisze oprogramowanie, które te cele pomaga utrzymać. Podejście narodziło się w Google około 2003 roku, gdy zespół pod kierunkiem Bena Traynora dostał zadanie utrzymania rosnących lawinowo usług i zamiast zatrudniać armię administratorów, potraktował utrzymanie tak, jak potraktowałby je programista: przez automatyzację, pomiar i jasno zdefiniowane cele.
Warto od razu rozprawić się z trzema nieporozumieniami. SRE nie jest nowym słowem na administratora: klasyczny administrator pilnuje serwerów, a inżynier SRE pilnuje obietnicy złożonej użytkownikowi (że usługa będzie działać z określoną niezawodnością) i większość czasu spędza na pisaniu automatyzacji, a nie na klikaniu w panelach. SRE nie jest wyłącznie zestawem narzędzi: Prometheus i Grafana są tu środkiem, a nie celem. I wreszcie SRE nie jest luksusem tylko dla gigantów: nawet mały zespół zyskuje, gdy zamiast kłócić się „czy wdrażać", zaczyna rozmawiać liczbami o tym, na ile awarii może sobie pozwolić.
Najkrótsza definicja krąży po branży jako zdanie zaczerpnięte z języka programowania: „class SRE implements interface DevOps", czyli SRE jest konkretną realizacją idei DevOps. DevOps mówi, co osiągnąć (zburzyć mur między tworzeniem a utrzymaniem, automatyzować, mierzyć), a SRE dokłada do tego twarde reguły: jak dokładnie mierzyć niezawodność, ile awarii jest dopuszczalnych i co się dzieje, gdy ten limit zostanie przekroczony. Poniżej trzy pokrewne podejścia, które łatwo pomylić.
To rozróżnienie ma praktyczny skutek. W dojrzałym zespole SRE obowiązuje zasada, że inżynier dyżurny nie może spędzać więcej niż połowy czasu na pracy ręcznej i gaszeniu pożarów. Druga połowa jest zarezerwowana na inżynierię: pisanie automatyzacji, poprawianie systemów i usuwanie źródeł awarii. Gdy praca ręczna zaczyna zjadać ten limit, jest to sygnał alarmowy, a nie powód do zatrudnienia kolejnej osoby do klikania. Do tej pracy ręcznej, nazywanej toil, wrócimy w osobnej sekcji.
Serce SRE to zamiana mglistego „usługa ma działać dobrze" na liczby, którymi da się zarządzać. Służą do tego trzy skróty, które łatwo pomylić, choć znaczą coś zupełnie innego. Ułóżmy je w kolejności, w jakiej powstają: najpierw mierzymy, potem stawiamy cel, a na końcu z celu wynika budżet na awarie.
Rozłóżmy to na części. SLI (ang. Service Level Indicator, wskaźnik poziomu usługi) to konkretna liczba mierzona wprost z zachowania systemu. Najczęściej są to dostępność (jaki procent zapytań zakończył się poprawnie) oraz opóźnienie (ang. latency, czyli jak szybko przychodzi odpowiedź). Dobry wskaźnik SLI patrzy oczami użytkownika, a nie serwera: nie interesuje nas, że procesor ma 30% obciążenia, tylko czy klient dostał odpowiedź i czy dostał ją szybko.
SLO (ang. Service Level Objective, cel poziomu usługi) to obietnica postawiona na wskaźniku: „utrzymamy co najmniej 99,9% udanych zapytań w miesiącu". SLA (ang. Service Level Agreement, umowa o poziomie usługi) to z kolei zapis w umowie z klientem, z karami finansowymi za jego złamanie. Kluczowa reguła SRE brzmi: SLO ustawiamy zawsze ostrzej niż SLA. Jeśli klientowi obiecujemy w umowie 99,5%, wewnętrznie celujemy na przykład w 99,9%, żeby mieć zapas, zanim zaczną się kary. Wskaźnik SLI mierzy się najczęściej w PromQL, języku zapytań Prometheusa. Poniżej realny wskaźnik dostępności: udział udanych zapytań (bez kodów błędu serwera 5xx) w całym ruchu.
# SLI dostępności: udział udanych zapytań (bez błędów 5xx) w całym ruchu
sum(rate(http_requests_total{job="sklep-api",code!~"5.."}[30d]))
/
sum(rate(http_requests_total{job="sklep-api"}[30d]))
# Wynik 0,999 oznacza 99,9% udanych zapytań w ostatnich 30 dniachTak zapisany wskaźnik SLI jest zwykłym zapytaniem PromQL, które w każdej chwili możesz uruchomić na żywych danych. Oto realne zapytanie tego typu wykonane na działającym Prometheusie: funkcja rate liczy tempo przyrostu licznika zapytań, a wynik to gotowa liczba, z której robi się wskaźnik niezawodności.
Skoro budżet błędów to „wszystko, czego brakuje celowi do stu procent", warto zobaczyć, jak mało to bywa. Poniższa tabela pokazuje, ile niedostępności miesięcznie mieści się w kolejnych poziomach, popularnie nazywanych „dziewiątkami" (bo 99,9% to trzy dziewiątki, a 99,99% cztery). Widać w niej, dlaczego każda kolejna dziewiątka jest dramatycznie droższa od poprzedniej.
| Cel SLO (dostępność) | Budżet błędów miesięcznie | Ile to realnie |
|---|---|---|
| 99% (dwie dziewiątki) | 7 godzin 18 minut | |
| 99,9% (trzy dziewiątki) | 43 minuty 12 sekund | |
| 99,95% | 21 minut 36 sekund | |
| 99,99% (cztery dziewiątki) | 4 minuty 19 sekund | |
| 99,999% (pięć dziewiątek) | 26 sekund |
Ta tabela to najważniejsza intuicja w całym SRE. Wysoka niezawodność kosztuje, i to nieliniowo. Bank rozliczeń międzynarodowych będzie celował w cztery lub pięć dziewiątek, ale wewnętrzny panel raportowy z nadmiarowym celem 99,99% to zwykle wyrzucanie pieniędzy. Dobór celu SLO jest więc decyzją biznesową: ile niezawodności naprawdę potrzebuje ta konkretna usługa i ile jesteśmy gotowi za nią zapłacić.
Chcesz zbudować monitoring, z którego liczy się realne wskaźniki SLI i cele SLO? Szkolenie Monitoring i Observability: Grafana, Prometheus, Loki, Zabbix ma terminy gwarantowane.
Budżet błędów to nie tylko liczba na wykresie. To narzędzie zarządcze, które rozwiązuje najstarszy konflikt w IT. Programiści chcą wdrażać zmiany często, bo z tego są rozliczani. Utrzymanie chce wdrażać rzadko, bo każda zmiana to ryzyko awarii. Przez lata ten spór rozstrzygało się siłą przekonywania albo hierarchią. SRE rozstrzyga go liczbą.
Mechanizm jest prosty. Jeśli usługa mieści się w budżecie błędów (awarii było mniej, niż wolno), zespół produktowy dostaje zielone światło: wdrażaj śmiało, eksperymentuj, ryzykuj. Jeśli budżet się wyczerpał (awarii było za dużo), wchodzi w życie tak zwana polityka budżetu błędów (ang. error budget policy): nowe funkcje czekają, a cały zespół, łącznie z programistami, przełącza się na poprawę niezawodności, aż budżet znów urośnie. Nikt nikogo nie przekonuje. Decyzję podejmuje wskaźnik.
Awarii było mniej, niż pozwala SLO. Margines na ryzyko nietknięty.
Awarii było za dużo, cel SLO zagrożony. Włącza się polityka budżetu błędów.
Piękno tego rozwiązania polega na tym, że wyrównuje ono interesy. Programistom zaczyna zależeć na niezawodności, bo to ona daje im swobodę szybkiego wdrażania. Utrzymanie przestaje blokować zmiany „na wszelki wypadek", bo ma obiektywny licznik, który sam powie, kiedy zwolnić. To dokładnie ta sama wspólna odpowiedzialność, o której mówi kultura DevOps, tyle że SRE nadaje jej twardą, mierzalną formę.
Skoro inżynier SRE ma poświęcać połowę czasu na inżynierię, to co go od niej odciąga? Odpowiedź brzmi: toil. To angielskie słowo (znojna, jałowa harówka) w SRE ma bardzo precyzyjne znaczenie. Toil to praca, która jest ręczna, powtarzalna, możliwa do zautomatyzowania, pozbawiona trwałej wartości i rosnąca liniowo wraz z wielkością usługi. Ręczny restart usługi po awarii, kopiowanie tych samych poleceń, klikanie w panelu, żeby dodać dziesiąty identyczny serwer, to wszystko toil.
Walka z toil to główny powód, dla którego SRE tak mocno opiera się na automatyzacji z rodziny DevOps. Zamiast ręcznie konfigurować dziesiąty serwer, opisuje się go raz w infrastrukturze jako kodzie (Terraform i Ansible), a zamiast ręcznie restartować aplikację, powierza się to systemowi, który sam pilnuje zadanego stanu. Do tego drugiego wrócimy przy Kubernetesie, bo jego samonaprawa to podręcznikowy przykład zamiany toil na automatyzację.
Automatyzacja, która wycina pracę jałową, to Terraform i Ansible w praktyce. Szkolenie Automatyzacja zadań z Ansible ma terminy gwarantowane.
SRE nie ma własnego, osobnego zestawu narzędzi. Korzysta z tego samego stosu monitoringu i automatyzacji co DevOps, tylko ustawia go pod konkretny cel: pilnowanie obietnicy złożonej użytkownikowi. Poniższa mapa porządkuje te narzędzia według zadania, a potem przejdziemy przez najważniejsze z nich na prawdziwych zrzutach.
Prometheus to baza danych szeregów czasowych, czyli liczb zmieniających się w czasie. Zanim cokolwiek zmierzymy, sprawdzamy, czy Prometheus w ogóle ma z czego zbierać dane, na liście celów (ang. targets). Każdy cel to źródło metryk: aplikacja, serwer albo eksporter (mały program udostępniający metryki systemu).
Metryki odpytuje się językiem PromQL. Wskaźnik SLI dostępności pokazaliśmy już wyżej, ale drugim najważniejszym wskaźnikiem jest opóźnienie: jaki procent zapytań mieści się w akceptowalnym czasie odpowiedzi. Poniżej zapytanie, które liczy udział zapytań szybszych niż 300 milisekund, czyli klasyczny wskaźnik SLI opóźnienia.
# SLI opóźnienia: udział zapytań szybszych niż 300 ms (histogram opóźnień)
sum(rate(http_request_duration_seconds_bucket{job="sklep-api",le="0.3"}[5m]))
/
sum(rate(http_request_duration_seconds_count{job="sklep-api"}[5m]))Sam Prometheus rysuje też proste wykresy, dzięki którym od razu widać, kiedy wskaźnik zaczął spadać i czy sam wrócił do normy. To pierwszy rzut oka przy każdym podejrzeniu problemu.
Grafana to narzędzie do wizualizacji danych, któremu poświęciliśmy osobny przewodnik po Grafanie dla początkujących. W kontekście SRE jej najważniejsza funkcja to progi (ang. thresholds): kolorowe strefy na wykresie, które wprost pokazują, kiedy wskaźnik wchodzi w obszar zagrożenia. Ustawiony na wysokości celu SLO próg zamienia zwykły wykres w tablicę wyników niezawodności.
Wykres, na który nikt nie patrzy o trzeciej w nocy, jest bezużyteczny. Dlatego reguły alertów w Prometheusie pilnują wskaźników automatycznie, a gdy warunek jest spełniony przez zadany czas, przekazują alert do Alertmanagera, który wysyła powiadomienie. Reguły definiuje się w pliku, a Prometheus pokazuje ich stan na osobnej stronie.
Kluczowa zasada SRE brzmi: alarmuj o objawach, nie o przyczynach. Zamiast budzić dyżurnego, gdy procesor skoczy do 90% (co samo w sobie może być nieszkodliwe), budzi się go dopiero, gdy cierpi na tym użytkownik, na przykład gdy rośnie odsetek błędów albo opóźnienie. Najlepszym wzorcem alertu jest tak zwane wielookienne tempo wypalania (ang. multi-window burn rate): alarm odzywa się, gdy budżet błędów znika za szybko, i to potwierdzone w dwóch oknach czasowych naraz, żeby uniknąć fałszywych alarmów.
# Alert: budżet błędów wypala się zbyt szybko (objaw, nie przyczyna)
- alert: SzybkieWypalanieBudzetu
expr: |
slo:blad5m{job="sklep-api"} > (14.4 * 0.001)
and
slo:blad1h{job="sklep-api"} > (14.4 * 0.001)
for: 2m
labels: { severity: page } # page = wezwij dyżurnego
annotations:
summary: "Usługa zjada budżet błędów 14x szybciej niż wolno"Liczba 14,4 nie jest przypadkowa: to tempo, przy którym w godzinę zniknęłoby 2% miesięcznego budżetu błędów. Taki alert łapie poważne awarie w kilka minut, a jednocześnie nie budzi nikogo z powodu drobnego, przejściowego skoku. Gdy warunek się utrzyma, alert staje się aktywny, co widać w interfejsie:
Alertmanager odbiera taki alert i zamienia go w powiadomienie na właściwym kanale. To on decyduje, czy alert pójdzie na e-mail całego zespołu, czy jako pilne wezwanie (ang. page) obudzi dyżurnego telefonem. Poniżej Alertmanager z aktywnym alertem gotowym do wysłania.
Właśnie tak wygląda dyżur (ang. on-call): wyznaczona osoba przez ustalony czas (najczęściej tydzień) jest gotowa zareagować na pilne alerty. SRE traktuje dyżur poważnie: liczba nocnych wezwań jest mierzona, a jeśli rośnie, to sygnał, że system trzeba naprawić u źródła, a nie przyzwyczajać ludzi do niewyspania. Dobry dyżur to taki, na którym telefon milczy, bo automatyzacja i solidne systemy załatwiają sprawę same.
Reguły alertów, Alertmanager i pulpity SLO najlepiej poznać na żywej infrastrukturze. Szkolenie Monitoring i Observability: Grafana, Prometheus, Loki, Zabbix ma terminy gwarantowane.
Obserwowalność (ang. observability), czyli zdolność zrozumienia, co dzieje się w systemie na podstawie danych, które on o sobie udostępnia, stoi na trzech nogach. Pierwszą są metryki z Prometheusa. Drugą są logi, które centralizuje Loki albo starszy, wciąż popularny stos ELK (Elasticsearch, Logstash, Kibana). Trzecią są ślady zapytań (ang. distributed tracing): zapis drogi pojedynczego żądania przez wszystkie usługi, dzięki któremu widać, na którym etapie zapytanie utknęło. Narzędzia takie jak Jaeger, Tempo czy standard OpenTelemetry odpowiadają właśnie na pytanie „w którym z dziesięciu mikroserwisów zapytanie straciło trzy sekundy".
Dla SRE ta trójka działa jak ścieżka diagnozy podczas awarii. Metryka i alert mówią, że rośnie odsetek błędów. Log pokazuje treść błędu i której usługi dotyczy. Ślad pokazuje, gdzie dokładnie w łańcuchu wywołań pojawiło się opóźnienie albo błąd. Bez tej trójki analiza incydentu jest zgadywaniem, a z nią staje się czytaniem faktów. Jeśli chcesz zobaczyć obserwowalność na konkretnym przykładzie bazy danych, pokazaliśmy ją na monitorowaniu PostgreSQL zarówno przez rozszerzenie pg_stat_monitor, jak i przez Percona Monitoring and Management.
Kubernetes to system do orkiestracji kontenerów, w którym nie mówisz „uruchom ten kontener", tylko opisujesz stan docelowy („chcę trzy działające kopie"), a klaster sam do niego dąży i sam go pilnuje. Różnice między samym Dockerem a Kubernetesem rozłożyliśmy w osobnym tekście o tym, czym różni się Kubernetes od Dockera. Z punktu widzenia SRE najważniejsza jest samonaprawa: gdy któraś kopia padnie, Kubernetes natychmiast uruchamia nową, żeby utrzymać zadaną liczbę, bez budzenia kogokolwiek.
To dlatego SRE tak chętnie sięga po Kubernetes i podobne platformy. Każda awaria, którą system potrafi naprawić sam, to jedno wezwanie mniej w nocy i jeden kawałek toil mniej. Zamiast pisać instrukcję „gdy usługa padnie, zaloguj się i zrestartuj", opisuje się stan docelowy raz, a egzekwuje go maszyna. Tę samą zasadę, samodzielnego przełączania na zapasowy węzeł po awarii, stosuje się też na poziomie baz danych, na przykład w PostgreSQL o wysokiej dostępności z Patroni (automatyczny failover, czyli natychmiastowe przełączenie na węzeł zapasowy) oraz w replikacji z gorącą rezerwą, gdzie kopia bazy stoi gotowa do przejęcia ruchu.
Samonaprawę i skalowanie na realnym klastrze najlepiej przećwiczyć w praktyce. Szkolenie Kubernetes: orkiestracja kontenerów ma terminy gwarantowane.
Inżynieria chaosu (ang. chaos engineering) to praktyka, w której niezawodności nie zakłada się, tylko testuje. Narzędzia takie jak Chaos Mesh czy LitmusChaos wstrzykują kontrolowane awarie: wyłączają losową kopię aplikacji, dodają opóźnienie sieci, symulują zapełnienie dysku. Jeśli system jest naprawdę odporny, użytkownik niczego nie zauważy, bo samonaprawa i nadmiarowość zadziałają. Jeśli nie, dowiadujemy się o tym w bezpiecznych warunkach, w środku dnia, z zespołem przy klawiaturach, a nie o trzeciej w nocy podczas prawdziwego skoku ruchu. To bezpośrednie przedłużenie myślenia SRE: lepiej wywołać awarię samemu i się z niej nauczyć, niż czekać, aż wywoła ją przypadek.
Mimo najlepszej automatyzacji awarie się zdarzają. Różnica polega na tym, jak zespół na nie reaguje. SRE ma na to uporządkowany proces, nazywany zarządzaniem incydentami. Nie chodzi w nim o heroiczne gaszenie pożaru przez jedną osobę, tylko o powtarzalną ścieżkę od wykrycia do wyciągnięcia wniosków. Prześledźmy tę drogę.
Zwróć uwagę na kolejność dwóch ostatnich etapów przed wnioskami. Najpierw złagodzenie (ang. mitigation), czyli szybkie przywrócenie działania usługi, choćby prowizoryczne, na przykład przez cofnięcie ostatniego wdrożenia. Dopiero potem naprawa źródła (ang. root cause), spokojnie, bez presji. Podczas awarii celem numer jeden jest, żeby użytkownik znów mógł korzystać z usługi, a nie żeby od razu zrozumieć wszystko do końca. Czas od wykrycia do złagodzenia mierzy się jako MTTR (ang. Mean Time To Recovery, średni czas powrotu do sprawności) i jest to jeden z czterech wskaźników DORA, po których poznaje się dojrzały zespół.
Najważniejszym elementem jest jednak ostatni: postmortem bez obwiniania (ang. blameless postmortem). Po każdym poważnym incydencie zespół spisuje, co się stało, dlaczego i co zrobić, żeby się nie powtórzyło. Kluczowe słowo to „bez obwiniania": celem nie jest znalezienie winnego, tylko słabego miejsca w systemie. Założenie SRE brzmi, że jeśli jeden człowiek jednym kliknięciem mógł położyć produkcję, to problemem jest system, który na to pozwolił, a nie ten człowiek. Taka kultura sprawia, że ludzie zgłaszają błędy zamiast je ukrywać, a to jest warunek jakiejkolwiek poprawy.
SRE nie jest sztuką dla sztuki. Jego celem jest niezawodność, która wprost przekłada się na pieniądze: każda minuta niedostępności sklepu to utracona sprzedaż, a każda głośna awaria to nadszarpnięte zaufanie. Jednocześnie SRE nie goni za niezawodnością za wszelką cenę, bo wie, że kolejne dziewiątki kosztują nieproporcjonalnie dużo. Zamiast tego dobiera cel świadomie i pilnuje go liczbami.
SRE nie jest punktem startowym kariery, tylko warstwą, która nadbudowuje się nad solidnymi podstawami. Nie da się sensownie ustawiać celów SLO dla systemu, którego się nie rozumie. Sensowna kolejność wygląda tak:
Najlepiej uczyć się na własnym laboratorium. Pełny klaster Kubernetes uruchomisz lokalnie w minutę, a stos Prometheus i Grafana postawisz w kilka poleceń, po czym możesz sam wywoływać awarie i patrzeć, jak reaguje monitoring. Ponieważ SRE wyrasta wprost z DevOps, jego droga nauki mocno się z nią pokrywa. Kompletną, rozpisaną na fazy ścieżkę wraz z realnymi widełkami zarobków opisaliśmy w osobnym przewodniku o tym, jak zostać inżynierem DevOps od zera.
SRE to nie nowa nazwa dla administratora ani zestaw modnych narzędzi, tylko sposób myślenia, w którym niezawodność jest problemem inżynierskim, mierzonym liczbami i pilnowanym przez automatyzację. Jego rdzeń to prosta, ale potężna matematyka: SLI mierzy, co dzieje się z usługą, SLO stawia na tym cel, a budżet błędów zamienia różnicę między nimi w narzędzie zarządcze, które kończy odwieczny spór o tempo wdrożeń. Wokół tego rdzenia SRE tnie toil, buduje obserwowalność z metryk, logów i śladów, alarmuje o objawach, a nie przyczynach, i po każdej awarii pisze postmortem bez obwiniania. Narzędzia, których używa, Prometheus, Grafana, Alertmanager, Loki czy Kubernetes, to w większości ten sam stos co w DevOps, ustawiony pod jedno pytanie: czy dotrzymujemy obietnicy złożonej użytkownikowi. To właśnie jest SRE i do tego on służy.
Komentarze (0)
Brak komentarzy...