SRE (Site Reliability Engineering) to podejście, w którym do utrzymywania działających systemów zatrudniasz inżynierów oprogramowania i każesz im traktować niezawodność jak problem programistyczny, a nie jak nocne dyżury z gaśnicą. Zamiast ręcznie restartować serwery, piszesz kod, który robi to za Ciebie — i mierzysz, czy w ogóle trzeba. Dyscyplina narodziła się w Google około 2003 roku (jej ojcem jest Ben Treynor Sloss), a książka Site Reliability Engineering z 2016 spopularyzowała ją na cały świat.
Sedno SRE to liczby zamiast emocji. Definiujesz SLI (Service Level Indicator) — konkretną metrykę, np. odsetek żądań HTTP zakończonych kodem 2xx albo czas odpowiedzi poniżej 300 ms. Na jej podstawie ustalasz SLO (Service Level Objective), czyli cel typu „99,9% żądań w miesiącu kończy się sukcesem”. To, czego nie dowieziesz do 100%, jest Twoim error budgetem — budżetem błędów. Przy SLO 99,9% masz około 43 minut dozwolonej niedostępności miesięcznie. Dopóki budżet się nie wyczerpał, zespół może śmiało wdrażać nowe funkcje. Gdy się skończy — wdrożenia stop, wszyscy gaszą pożary i poprawiają stabilność.
Jak to wygląda w praktyce
Załóżmy, że pilnujesz API sklepu. Wystawiasz metryki z aplikacji, zbiera je Prometheus, a alerty liczysz na podstawie tempa wypalania error budgetu (tzw. burn rate). Reguła w PromQL może wyglądać tak:
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.001
Jeśli udział błędów 5xx przekracza próg, Alertmanager budzi dyżurnego (on-call) przez PagerDuty. Po incydencie piszesz postmortem — i tu kluczowa zasada SRE: jest blameless, czyli szukasz wadliwego procesu, a nie winnego człowieka. Inny filar to toil: powtarzalna, ręczna robota bez wartości dodanej. SRE dąży, by automatyzacja zjadała toil, a nie ludzi.
Częste nieporozumienia
SRE to nie „DevOps z lepszą nazwą” ani „admin, który czasem napisze skrypt”. Najczęstszy błąd początkujących: cel 100% dostępności. To pułapka — 100% jest niewykonalne i niepotrzebne, bo użytkownik i tak nie odróżni 99,99% od ideału, a próba domknięcia ostatnich ułamków procenta kosztuje fortunę. Drugi błąd to mylenie SLO z SLA (Service Level Agreement) — SLA to umowa prawna z karami dla klienta, SLO to wewnętrzny cel, zwykle ostrzejszy. Trzeci grzech: mnożenie alertów, które nic nie znaczą, aż dyżurny przestaje na nie reagować.
Pojęcia powiązane: DevOps, SLA, SLO, SLI, error budget, observability, monitoring, Prometheus, Kubernetes, postmortem, toil, on-call, incident response.