Site Reliability Engineering (SRE) to dyscyplina inżynierska zajmująca się projektowaniem, utrzymaniem i ciągłym doskonaleniem niezawodności systemów informatycznych — najczęściej rozproszonych i działających w skali produkcyjnej. Podejście narodziło się w Google w pierwszej dekadzie XXI wieku jako odpowiedź na ograniczenia klasycznego modelu „dev kontra ops” i zostało spopularyzowane przez serię publikacji wydanych przez tę firmę. W uproszczeniu SRE polega na traktowaniu operacji jak problemu inżynierii oprogramowania: zamiast ręcznie reagować na incydenty, buduje się mechanizmy, dane i automatyzacje, które sprawiają, że systemy są przewidywalnie niezawodne.
Codzienna praca zespołów SRE koncentruje się wokół kilku obszarów. Pierwszym są SLI, SLO i error budget — czyli mierzalne wskaźniki jakości usługi (Service Level Indicators), uzgodnione cele (Service Level Objectives) oraz „budżet błędów”, który określa, ile niedostępności lub błędów organizacja jest gotowa zaakceptować w danym okresie. Error budget bywa narzędziem decyzyjnym: jeśli jest wyczerpany, priorytetem staje się stabilizacja zamiast wdrażania nowych funkcji.
Drugim obszarem jest monitoring i observability — zbieranie metryk, logów i tracingu w sposób, który pozwala nie tylko wykryć incydent, ale też zrozumieć jego przyczynę. Trzecim — obsługa on-call i zarządzanie incydentami, w tym procedury eskalacji, runbooki, post-mortemy bez wskazywania winnych (blameless post-mortems) oraz analiza przyczyn źródłowych.
Kolejny filar to redukcja toil — czyli automatyzacja powtarzalnej, manualnej pracy operacyjnej. SRE klasycznie poświęca część czasu na pisanie kodu, narzędzi i platform, które eliminują rutynowe zadania. Do tego dochodzą capacity planning, testy chaos engineering, weryfikacja gotowości produkcyjnej nowych usług (production readiness review) oraz współpraca z zespołami deweloperskimi nad architekturą odporną na awarie.
SRE jest blisko spokrewnione z DevOps — można powiedzieć, że stanowi jego konkretną, mierzalną implementację. DevOps definiuje kulturę i cele, SRE dostarcza praktyk i wskaźników.
Podejście SRE upowszechniło się szeroko w firmach prowadzących usługi cyfrowe na większą skalę. Najczęściej spotyka się je w branżach, w których dostępność systemów ma bezpośrednie przełożenie na przychód lub reputację: e-commerce, fintech i bankowość, telekomunikacja, SaaS, streaming, gaming, sektor mediowy oraz duże platformy logistyczne. W mniejszych organizacjach role SRE bywają łączone z DevOps lub platform engineering, w większych funkcjonują jako wyspecjalizowane zespoły. Wraz z migracją do chmury i konteneryzacji (Kubernetes, architektury mikroserwisowe) zapotrzebowanie na kompetencje SRE stało się trwałym elementem rynku.
Popyt na inżynierów SRE jest stabilnie wysoki — zarówno w Polsce, jak i na rynkach zachodnich. Specjalizacja ta jest postrzegana jako jedna z bardziej wymagających w obszarze infrastruktury i operacji, ponieważ łączy programowanie, znajomość systemów rozproszonych, sieci, baz danych i bezpieczeństwa. Konkurencja o doświadczonych kandydatów (poziom mid i senior) jest wyraźna, a podaż wąska — częściowo dlatego, że do SRE rzadko trafia się bezpośrednio po studiach. Juniorów na tych stanowiskach jest stosunkowo niewielu, a procesy rekrutacyjne bywają wieloetapowe i techniczne.
Osoba rozważająca ścieżkę SRE powinna liczyć się z tym, że jest to rola hybrydowa — wymagająca zarówno umiejętności programistycznych (najczęściej Python, Go, czasem Bash i języki używane w danej organizacji), jak i solidnej wiedzy o systemach operacyjnych Linux, sieciach, konteneryzacji, orkiestracji (Kubernetes), narzędziach observability (np. Prometheus, Grafana, OpenTelemetry) oraz chmurach publicznych. Wejście najczęściej odbywa się z pozycji administratora systemów, inżyniera DevOps, programisty backendowego lub inżyniera platformy. Warto rozumieć koncepcje takie jak SLO/SLI, kolejki, spójność danych, mechanizmy retry i backoff, a także potrafić prowadzić post-mortemy. Perspektywy rozwoju są dobre: ścieżka prowadzi w stronę senior/staff SRE, architekta niezawodności, kierownika zespołu SRE lub platform engineering. Trzeba jednak akceptować dyżury on-call i odpowiedzialność za systemy produkcyjne — to nie jest praca wyłącznie projektowa.
Firma zatrudniająca SRE powinna mieć świadomość, że sama nazwa stanowiska nie wystarczy — kluczowe jest, czy organizacja jest gotowa wdrożyć praktyki, które stoją za tym podejściem: mierzenie SLO, prowadzenie blameless post-mortemów, przeznaczanie części czasu inżynierów na automatyzację i ograniczanie toil, a także respektowanie error budget w decyzjach produktowych. Bez tego rekrutowani specjaliści szybko stają się „dyżurnymi gaszącymi pożary” i odchodzą. W procesie rekrutacji warto weryfikować zarówno umiejętności kodowania, jak i myślenie systemowe oraz doświadczenie w analizie incydentów. Dostępność dobrych kandydatów na rynku jest ograniczona, dlatego realnymi czynnikami decydującymi są: dojrzałość praktyk inżynierskich w firmie, jakość systemów, model on-call (rotacja, wynagrodzenie za dyżury) oraz przestrzeń na pracę nad usprawnieniami, a nie wyłącznie nad utrzymaniem.