Site Reliability Engineer (SRE) to inżynier łączący kompetencje inżynierii oprogramowania z odpowiedzialnością za niezawodność systemów produkcyjnych — koncepcję spopularyzował Google, stosując do operacji IT podejście inżynierskie zamiast wyłącznie administracyjnego. Kluczowe umiejętności obejmują automatyzację infrastruktury, obserwowalność systemów, zarządzanie budżetem błędów oraz udział w dyżurach on-call. Rola wymaga też programowania (Python, Go) i biegłości w narzędziach takich jak Terraform czy Kubernetes.
Na skróty
Czego dowiesz się z artykułu:
- Jakie umiejętności techniczne musi mieć Site Reliability Engineer
- Tabela narzędzi i technologii używanych w codziennej pracy SRE
- Plan budowania kompetencji SRE krok po kroku
- Najczęstsze błędy przy wchodzeniu w rolę SRE
Dla kogo ten artykuł:
- Administratorzy systemów i inżynierowie DevOps rozważający specjalizację w niezawodności
- Deweloperzy zainteresowani przejściem w stronę operacji na systemach produkcyjnych
- Liderzy zespołów planujący rozwój kompetencji SRE w organizacji
Czas czytania: 7 minut
Umiejętności Site Reliability Engineer — czego się nauczyć
Rdzeniem pracy SRE jest łączenie dwóch światów — inżynierii oprogramowania i operacji produkcyjnych — dlatego umiejętności dzielą się na trzy warstwy: fundamenty inżynierskie (programowanie, systemy operacyjne, sieci), praktyki niezawodnościowe (wskaźniki SLI/SLO, budżety błędów, zarządzanie incydentami) oraz narzędzia operacyjne (automatyzacja infrastruktury, obserwowalność, chmura). Zdobywanie tych umiejętności w izolacji, bez zrozumienia, jak łączą się w codziennej pracy na produkcji, prowadzi do wiedzy teoretycznej, która nie przekłada się na realną gotowość do dyżuru.
Praktyki opisane w książce Google poświęconej SRE — budżety błędów jako narzędzie decyzyjne pomiędzy tempem wdrożeń a stabilnością oraz blameless postmortem jako sposób na uczenie się z awarii bez szukania winnych — są dziś standardem, którego oczekuje się od kandydatów na starszych stanowiskach SRE, niezależnie od konkretnego stosu technologicznego firmy.
Umiejętności techniczne i narzędzia
| Obszar | Kluczowe narzędzia i technologie | Poziom wymagany |
|---|---|---|
| Programowanie i skrypty | Python, Go, Bash | must-have |
| Konteneryzacja i orkiestracja | Docker, Kubernetes | must-have |
| Infrastructure as Code | Terraform, Ansible | must-have |
| Obserwowalność (metryki, logi, trace’y) | Prometheus, Grafana, OpenTelemetry | must-have |
| Chmura publiczna | AWS, Azure, GCP (jedna platforma dogłębnie) | nice-to-have |
| Zarządzanie incydentami | PagerDuty, runbooki, postmortemy | must-have |
Plan budowania kompetencji SRE krok po kroku
- Ugruntuj fundamenty administracji systemami Linux i sieci — zrozumienie procesów, pamięci, warstwy sieciowej i systemu plików jest bazą, bez której narzędzia wyższego poziomu pozostają czarną skrzynką.
- Naucz się jednego języka skryptowego do automatyzacji — Python lub Go pozwalają pisać narzędzia diagnostyczne, automatyzować powtarzalne zadania operacyjne i rozumieć kod aplikacji, które utrzymujesz.
- Opanuj konteneryzację i podstawy Kubernetesa — od uruchomienia pojedynczego kontenera po zrozumienie, jak Kubernetes planuje obciążenie, skaluje repliki i reaguje na awarię węzła.
- Wdroż się w Infrastructure as Code — Terraform pozwala traktować infrastrukturę jako wersjonowany kod, co jest warunkiem powtarzalnych, bezpiecznych zmian na produkcji.
- Zbuduj kompetencję obserwowalności — naucz się projektować metryki, alerty oparte na SLO (a nie na surowych progach) i czytać rozproszone trace’y w systemach mikroserwisowych.
- Weź udział w symulowanym lub realnym dyżurze on-call — teoria SLI/SLO i budżetów błędów nabiera sensu dopiero w kontakcie z realnym incydentem i presją czasu.
Najczęstsze błędy przy wchodzeniu w rolę SRE
Najczęstszym błędem jest traktowanie SRE jako wyłącznie zestawu narzędzi do opanowania, bez zrozumienia leżącej u podstaw filozofii — budżetu błędów jako wspólnego języka między zespołem produktowym a operacyjnym. Kandydat, który potrafi skonfigurować Prometheusa, ale nie rozumie, po co mierzy się SLI i jak przekłada się to na decyzję „wdrażamy dziś czy czekamy”, nie jest gotowy na starsze stanowisko SRE, nawet jeśli zna wszystkie narzędzia z tabeli powyżej.
Drugim błędem jest unikanie dyżurów on-call na wczesnym etapie kariery — nauka reagowania na incydent pod presją czasu, komunikacji ze stakeholderami w trakcie awarii i prowadzenia rzetelnego postmortemu to umiejętności, których nie da się przyswoić wyłącznie z dokumentacji czy kursu wideo.
Trzecim, rzadziej dostrzeganym błędem jest pogoń za certyfikatami chmurowymi kosztem fundamentów sieciowych i systemowych — certyfikat AWS czy Azure potwierdza znajomość konkretnej platformy, ale nie zastępuje zrozumienia, dlaczego system się zawiesza, gdy limit deskryptorów plików zostaje wyczerpany, albo jak DNS wpływa na czas propagacji zmian.
Przeczytaj również
- Umiejętności Inżynier DevOps: co musisz umieć — porównanie kompetencji DevOps i SRE, przydatne przy wyborze ścieżki kariery
- Observability vs monitoring — praktyczny przewodnik SRE — pogłębienie tematu obserwowalności z tabeli powyżej
Rozwiń kompetencje
Temat tego artykułu jest powiązany ze szkoleniami Podstawy inżynierii niezawodności (SRE) oraz Obserwowalność systemów i inżynieria niezawodności. Sprawdź program i zapisz się, aby rozwinąć kompetencje pod okiem ekspertów EITT.
Najczęściej zadawane pytania
Czy trzeba umieć programować, żeby zostać Site Reliability Engineer?
Tak, choć nie na poziomie fullstack developera. Niezbędna jest znajomość języka skryptowego (Python lub Go) do automatyzacji, pisania narzędzi diagnostycznych i rozumienia kodu aplikacji, którą się utrzymuje na produkcji.
Jaka jest różnica między SRE a DevOps Engineer?
DevOps to podejście kulturowe i zestaw praktyk łączących development z operacjami, skupione na automatyzacji i CI/CD. SRE to konkretna rola inżynierska stosująca zasady inżynierii oprogramowania do operacji, z naciskiem na mierzalne SLI/SLO, budżety błędów i formalny proces postmortemu po każdym istotnym incydencie.
Od czego zacząć naukę SRE, jeśli pracuję jako administrator systemów?
Najlepszym punktem startu jest pogłębienie znajomości Linuksa i sieci, a następnie nauka jednego języka skryptowego oraz konteneryzacji. Kolejny krok to Infrastructure as Code i podstawy obserwowalności — dopiero na tej bazie sensowne staje się wejście w tematykę SLI/SLO i budżetów błędów.
Czy certyfikaty chmurowe są niezbędne w pracy SRE?
Nie są niezbędne, ale bywają przydatne jako potwierdzenie znajomości konkretnej platformy przy rekrutacji. Ważniejsze od samego certyfikatu jest rozumienie fundamentów — sieci, systemów operacyjnych i mechanizmów awarii — których certyfikat chmurowy sam w sobie nie gwarantuje.