SRE: rynek

Oferta

otwarta oferta, która przeszła kontrolę jakości i wymienia co najmniej dwie technologie

Obserwowany kandydat

kandydat, którego stack zawiera tę technologię; agregat — żaden pojedynczy rekord nie opuszcza perymetru

Kandydat do dopasowania

jeszcze nie liczone

Okno

oferty otwarte w chwili tworzenia snapshotu

Junior SRE — rzadkość (typowe wejście: DevOps Middle / Backend Middle + zainteresowanie niezawodnością). Skok Junior → Middle — po rozwiązaniu pierwszego incydentu produkcyjnego + pierwszej konfiguracji SLO dla usługi. Middle → Senior — odpowiedzialność za SLO wielu usług + biegłość w dyżurach (odpowiedzialność za metryki Mean Time to Detect / Recovery) + programowanie automatyzacji na poziomie Backend Middle/Senior. Senior → Staff / Principal — strategia niezawodności całej organizacji + przywództwo w kulturze production engineering + mentoring techniczny. Ścieżka kariery: DevOps Middle (2-3 lata) → SRE Junior / Middle (1-2 lata) → Senior → albo Staff / Principal SRE, Engineering Manager (SRE), przejście do Backend Distributed Systems Senior, albo specjalizacja w Chaos Engineering lub Performance Engineering.

Pierwotne rozróżnienie Google (książka Site Reliability Engineering): DevOps — kultura / filozofia („zburzyć silosy między Dev a Ops”). SRE — konkretna implementacja filozofii DevOps przez określone praktyki: SLI / SLO / error budgets + redukcja toilu + automatyzacja przede wszystkim + 50% czasu na inżynierię vs pracę operacyjną + post-mortemy bez szukania winnych. SRE = „co się dzieje, gdy poprosisz inżyniera oprogramowania o zaprojektowanie zespołu operacyjnego”. Praktyczna rzeczywistość 2026: 70% pokrycia na poziomie stacku (obie role używają K8s + Terraform + Prometheus + Grafana). Różnice widoczne w firmach produktowych: 1) Głębia programowania — SRE pisze więcej własnych narzędzi w Go / Pythonie (logika autoskalowania, automatyzacja wdrożeń, algorytmy planowania pojemności). DevOps Engineer częściej konfiguruje istniejące narzędzia. 2) Dyscyplina SLI / SLO — SRE odpowiada za architekturę SLO (Pyrra / OpenSLO / Sloth), egzekwowanie polityki error budget, alerting dostrojony do tempa spalania SLO. DevOps często konfiguruje monitoring bez formalnych SLO. 3) Mistrzostwo dyżurów — SRE ma regularną rotację dyżurów (24×7 dla usług krytycznych), jest mocniejszy w dowodzeniu incydentami i prowadzeniu post-mortemów. DevOps Engineer zwykle dyżuruje tylko dla własnego produktu. 4) Zasada 50% inżynierii — polityka Google: SRE nie powinien spędzać >50% czasu na pracy operacyjnej, reszta to inżynieria automatyzacji. DevOps Engineer nie ma takiego zabezpieczenia. 5) Teoria systemów rozproszonych — rozmowy rekrutacyjne na SRE często obejmują twierdzenie CAP / algorytmy konsensusu / modele spójności / analizę trybów awarii. Rozmowy na DevOps — bardziej praktyczne narzędzia. W startupach to rozróżnienie często się zaciera (jedna osoba = zarówno DevOps, jak i SRE).

SLI (Service Level Indicator) — mierzalna metryka kondycji usługi (dostępność / opóźnienie / odsetek błędów / przepustowość). SLO (Service Level Objective) — docelowa wartość SLI (np. 99.9% dostępności w ciągu 30 dni). SLA (Service Level Agreement) — umowne zobowiązanie wobec klientów (zwykle słabsze niż SLO, np. 99.5% przy SLO 99.9%, by zachować margines bezpieczeństwa). Error budget = 100% − SLO. Jeśli SLO wynosi 99.9% w ciągu 30 dni → error budget = 0.1% = 43 minut przestoju/miesiąc. Gdy error budget szybko się spala → zamrożenie wdrożeń nowych funkcji, skupienie zespołu na pracach nad niezawodnością. Gdy error budget jest w dobrej kondycji → agresywne wydawanie funkcji. Praktyczne wdrożenie frameworku (12 kroków): 1) Zidentyfikuj krytyczne ścieżki użytkownika widoczne dla klienta (CUJ). 2) Wybierz SLI dla każdej CUJ (zwykle dostępność + opóźnienie dla usług synchronicznych, przepustowość + świeżość dla asynchronicznych). 3) Wybierz początkowy cel SLO (zasada: nieco poniżej obecnej wydajności). 4) Skonfiguruj pomiar SLI (Prometheus + Grafana lub usługa zarządzana). 5) Skonfiguruj alerty burn-rate (wiele okien: szybkie spalanie 1h przy tempie 14.4×, wolne spalanie 6h przy tempie 6× — formuła Google). 6) Wdróż SLO-as-code (Pyrra / OpenSLO / Sloth) z kontrolą wersji. 7) Udokumentuj politykę error budget (co się dzieje po wyczerpaniu — zamrożenie funkcji? przegląd incydentu?). 8) Kwartalny przegląd SLO (korekta celu na podstawie rzeczywistej wydajności + wpływu na klientów). 9) Śledzenie toilu + roadmapa jego redukcji (cel: <50% czasu na toil). 10) Kultura post-mortemów — bez szukania winnych, nacisk na działania naprawcze. 11) Integracja chaos engineeringu (Gremlin / Chaos Mesh — wcześniejsze testowanie SLO w warunkach awarii). 12) Dashboard zaufania klientów (publiczna strona statusu — Statuspage / Atlassian / Better Uptime).

Linux / systemy dogłębnie: procesy, namespaces, cgroups, sieci (TCP/IP, DNS, load balancing), debugowanie wydajności (strace / perf / eBPF). Stack observability: Prometheus + Grafana (dogłębnie PromQL), distributed tracing (Tempo / Jaeger / OpenTelemetry), logi (Loki / ELK), zarządzane APM (Datadog / Grafana Cloud / Honeycomb) — SRE „widzi” system przez metryki. Praktyka SLO: SLI / SLO / error budget (zob. osobne pytanie), alerty burn-rate, SLO-as-code. Reagowanie na incydenty + dyżury: PagerDuty / Opsgenie, runbooki, post-mortemy bez szukania winnych, ocena wagi incydentu. Kubernetes: eksploatacja produkcyjna (poziom CKA) — obciążenia, sieci, rozwiązywanie problemów. IaC + automatyzacja: Terraform / OpenTofu, Ansible; kluczowa umiejętność SRE to redukcja toilu (ręcznej powtarzalnej pracy) przez automatyzację, cel <50% czasu na toil. CI/CD: bezpieczne wdrożenia — canary, blue-green, progressive delivery, rollback. Programowanie: Python i / lub Go na poziomie pisania utrzymywalnych narzędzi automatyzacji, a nie „skryptów”. Systemy rozproszone: tryby awarii, retry / timeout / circuit breaker, idempotentność, spójność — fundament planowania pojemności i DR. Chaos engineering: Gremlin / Chaos Mesh — sprawdzanie niezawodności przed incydentem. Najważniejsze: SRE traktuje niezawodność jak produkt — mierzy ją (SLO), automatyzuje rutynę i systematycznie usuwa przyczyny incydentów zamiast gasić je ręcznie. Angielski jest obowiązkowy — literatura SRE (książka Google SRE) i społeczność są anglojęzyczne.

Tak, 41% ofert SRE to praca w pełni zdalna lub hybrydowa. Praca SRE — oparta na chmurze + dashboardy monitoringu. Outsourcerzy — prawie zawsze zdalnie. Rosyjskie firmy produktowe — hybrydowo lub zdalnie po okresie próbnym. Rosyjskie banki — hybrydowo/w biurze ze względu na zgodność z wymogami bezpieczeństwa. Międzynarodowe firmy technologiczne — praca w pełni zdalna to standard. Zastrzeżenie specyficzne dla SRE: rotacja dyżurów on-call — wymaga niezawodnego internetu + zasilania awaryjnego + cichego miejsca do reagowania na nocne awarie. Niektóre firmy wymagają audytu domowego biura przed ofertą zdalnej pracy SRE. Strefa czasowa — role SRE zwykle wymagają pokrywania się z główną strefą czasową zespołu (firmy z USA często chcą 4+ godzin pokrycia z PT/ET). Huby relokantów: Polska / Niemcy / Kanada / Serbia / Gruzja. Angielski do międzynarodowej pracy zdalnej w SRE — obowiązkowo (dowodzenie incydentem na Zoomie po angielsku pod presją).

Production Engineer (PE) — określenie Facebooka / Mety na SRE. Ta sama dyscyplina, niemal identyczne obowiązki — nacisk na niezawodność + automatyzację + dyżury + planowanie pojemności + systemy rozproszone. Różnica jest historycznie filozoficzna: Google SRE — „inżynier oprogramowania, który akurat zajmuje się operacjami”, Facebook PE — „inżynier osadzony w zespole produktowym dla niezawodności”. W praktyce 2026 — niemal całkowite pokrycie. Inne równoważne tytuły: Reliability Engineer (LinkedIn), Infrastructure Engineer (często pokrywa się z SRE), Production Operations Engineer (termin legacy). Jak czytać oferty pracy 2026: szukaj sygnałów w opisie stanowiska — jeśli wymienia „SLI/SLO”, „error budgets”, „redukcję toilu”, „50% czasu na inżynierię”, „post-mortemy bez szukania winnych”, „rotację dyżurów” — to rola w stylu SRE niezależnie od tytułu. Jeśli wymienia „konfigurację CI/CD”, „migrację do chmury”, „infrastructure as code”, ale BEZ wzmianek o SLO — to ogólny DevOps.

Roadmapa: 1) Solidna baza DevOps — opanowanie Linuksa + Docker + Kubernetes (CKA) + dogłębnie platforma chmurowa + IaC (Terraform). Bez tej bazy nie ma sensu iść w SRE. 2) Programowanie na poziomie Backend Middle — Go (standard w SRE — Kubernetes / Prometheus / większość narzędzi SRE w Go) lub dogłębnie Python (analiza danych + skrypty). Książki: „The Go Programming Language” Donovan / Kernighan, „Fluent Python” Ramalho. 3) Książka Google „Site Reliability Engineering” (darmowy PDF) — obowiązkowa lektura, przeczytaj dwa razy. 4) „The Site Reliability Workbook” Google — praktyczne uzupełnienie (studia przypadków + ćwiczenia). 5) Opanowanie SLI / SLO — skonfiguruj SLO-as-code (Sloth / Pyrra / OpenSLO) dla prawdziwej usługi, skonfiguruj alerty burn-rate (wielookienkowe: szybkie 1h 14.4×, wolne 6h 6×). 6) Teoria systemów rozproszonych — twierdzenie CAP, modele spójności (linearyzowalność / sekwencyjna / przyczynowa / ostateczna), konsensus (podstawy Paxos / Raft), analiza trybów awarii. Książki: „Designing Data-Intensive Applications” Martin Kleppmann (obowiązkowa lektura 2026), „Database Internals” Petrov. 7) Chaos engineering — Chaos Mesh / Gremlin / LitmusChaos. Skonfiguruj eksperymenty chaosu na własnym klastrze K8s. Książka: „Chaos Engineering” Nora Jones / Casey Rosenthal. 8) Opanowanie testów obciążeniowych — k6 (nowoczesny, oparty na JS, zyskuje) lub Gatling (DSL w Scali) lub Locust (Python). Skonfiguruj testy obciążeniowe zintegrowane z CI. 9) Dogłębne observability: zaawansowany Prometheus (opanowanie PromQL + recording rules + federacja), zaawansowana Grafana (szablony + alerty), Loki + Tempo + OpenTelemetry. Przypadek użycia: rozproszone śledzenie w mikroserwisach. 10) Szkolenie z reagowania na incydenty — podstawy dowodzenia incydentem, framework blameless post-mortems, komunikacja w trakcie incydentów. Zasoby: „Incident Response & Computer Forensics” Luttgens / Pepe / Mandia, szkolenie Google z zarządzania incydentami. 11) Projekt własny: wdróż aplikację rozproszoną na K8s z pełną konfiguracją SLO + eksperymentami chaosu + symulacją dyżurów on-call. Udokumentuj jako system gotowy na produkcję. Kursy RU: Slurm SRE, Otus „SRE”, Karpov.Courses SRE Track. Międzynarodowe (EN): „Database Reliability Engineering” Campbell / Majors, wystąpienia USENIX SREcon (za darmo na YouTube), Google Cloud SRE Certification Path. DevOps Middle + zainteresowanie → SRE Junior — 4-10 miesięcy (trzeba wzmocnić programowanie + teorię systemów rozproszonych).

701 active open SRE positions — premium segment of the DevOps direction. Geography: the US, India, the UK. The real market is broader thanks to a huge international remote segment. Time to close a Senior SRE role — 6-12 weeks (longer than general DevOps due to rare-skill requirements: programming + distributed systems + on-call mastery combination).

Senior SRE odpowiada za pełny cykl inżynierii niezawodności + przywództwo techniczne. Programowanie na poziomie Middle+ w backendzie: biegłość w Go (standard w automatyzacji SRE) lub dogłębny Python — na poziomie „potrafię napisać produkcyjną logikę autoskalowania / algorytmy planowania przepustowości / własne operatory K8s”. Dogłębna biegłość w Kubernetesie: skala produkcyjna (węzły), operatory (Kubebuilder / Operator SDK), własne CRD, wzorce multi-tenancy. Teoria systemów rozproszonych: dogłębne rozumienie twierdzenia CAP, modele spójności (linearizability / sequential / causal / eventual), algorytmy konsensusu (Paxos / Raft), taksonomia trybów awarii, wzorce obsługi partycji sieciowych. Biegłość w observability: zaawansowany Prometheus (biegłość w PromQL + recording rules + federacja + remote_write), zaawansowana Grafana (szablony + transformacje + alertowanie), biegłość w integracji Loki + Tempo + OpenTelemetry, distributed tracing przez mikroserwisy. Biegłość w architekturze SLI / SLO: SLO jako kod (Pyrra / OpenSLO / Sloth), projektowanie polityki budżetu błędów + automatyzacja jej egzekwowania, strojenie alertów burn-rate w wielu oknach (unikanie zmęczenia alertami). Biegłość w dowodzeniu incydentami: prowadzenie reagowania na incydenty pod presją, facylitacja post-mortemów bez szukania winnych, analiza czynników przyczyniających się (nie root cause — nowoczesne podejście), priorytetyzacja działań. Biegłość w chaos engineeringu: Chaos Mesh / Gremlin / LitmusChaos — projektowanie eksperymentów chaosu, facylitacja GameDay. Biegłość w planowaniu przepustowości: metodyka testów obciążeniowych (k6 / Gatling / Locust), modele prognozowania zasobów, analiza zapasu, obsługa szczytowego obciążenia. Inżynieria wydajności: optymalizacja oparta na profilowaniu (perf / bpftrace / flamegraphs), diagnostyka wycieków pamięci, strojenie GC, analiza wydajności sieci. Dogłębnie service mesh: Istio / Linkerd / Cilium — zarządzanie ruchem, polityki ponowień, circuit breakers, wstrzykiwanie błędów. Projektowanie systemów pod kątem niezawodności: projektowanie HA multi-region multi-AZ na tablicy, planowanie RPO / RTO, strategie DR, architektura komórkowa ograniczająca zasięg awarii. Kompetencje miękkie: pisanie ADR, komunikacja podczas incydentów (aktualizacje strony statusu + rozmowy z interesariuszami w kryzysie), dyscyplina dyżurów, współpraca między zespołami (Backend / DevOps / Platform / Security), mentoring SRE na poziomie Middle. Angielski dla Senior+ OBOWIĄZKOWO — SRE to intensywna praca między zespołami + społeczność jest anglojęzyczna (USENIX SREcon, publikacje).