Ścieżki kariery w DevOps: od admina do SRE

Od admina „od wszystkiego” do świadomej ścieżki w DevOps

Scenka otwierająca – telefon o 3:00 w nocy

Telefon dzwoni o 3:07. „Produkcja nie działa, klienci nie mogą się zalogować, wejdź szybko na serwer”. Logujesz się z półprzymkniętymi oczami, restartujesz usługę, ręcznie czyścisz logi, modlisz się, żeby tym razem zadziałało. Rano nikt już o tym nie pamięta – poza tobą.

Ten sam człowiek kilka lat później odbiera powiadomienie z systemu alertów. Zamiast paniki – szybkie spojrzenie w dashboard. Automatyczny runbook już uruchomił procedurę naprawczą, a jeśli to nie pomoże, w dokumentacji jest dokładny opis kroków. Zespół zna SLO, wie, jaki ma error budget i co jest priorytetem. To nie magia, tylko przejście od roli klasycznego admina do inżyniera DevOps, a później do SRE.

Admin systemowy vs DevOps vs SRE – różne światy pracy

Administrator systemów zwykle odpowiada za to, aby serwery, systemy operacyjne i podstawowe usługi działały. Konfiguruje, instaluje, „dowozi” ręcznie lub pół-automatycznie. Myśli kategoriami hostów, backupów, praw dostępu. Często jego praca jest reaktywna: zgłoszenie – reakcja, awaria – naprawa, problem – obejście.

Inżynier DevOps przesuwa środek ciężkości z „klikania” na inżynierię procesów. Zajmuje się przepływem zmian od developera do produkcji: CI/CD, infrastrukturą jako kod, environmentami, automatyzacją provisioning’u. Jest mniej „od serwerów”, a bardziej „od platformy i procesu”. Myśli kategoriami pipeline’ów, artefaktów, środowisk, powtarzalności.

SRE (Site Reliability Engineer) patrzy na system jako całość: od kodu, przez infrastrukturę, po doświadczenie użytkownika. Interesuje go niezawodność, wydajność, stabilność i przewidywalność. Zamiast gaszenia pożarów, skupia się na eliminowaniu ich przyczyn i zmniejszaniu „toil” – powtarzalnej, ręcznej pracy. SRE to inżynier systemowy, który posługuje się kodem na równi z narzędziami infrastrukturalnymi.

Dlaczego admini uciekają od „gaszenia pożarów” w stronę DevOps/SRE

Model pracy klasycznego admina ma tendencję do wypalania: zgłoszenia, awarie, niekończące się „pilne” taski. Mało czasu na rozwój, dużo pracy w nocy i w weekendy, niewielki wpływ na decyzje architektoniczne. W dodatku część zadań admina jest coraz częściej automatyzowana lub przenoszona do chmury (managed services).

W DevOps i SRE korzyści są inne:

• Stabilność i przewidywalność – mniej przypadkowych awarii, więcej pracy nad systemami w zaplanowany sposób.
• Wpływ na produkt – DevOps/SRE uczestniczy w projektowaniu, a nie tylko „wdrażaniu, co inni wymyślili”.
• Wyższa wycena na rynku – kompetencje DevOps/SRE łączą infrastrukturę, programowanie i procesy, co jest dużo lepiej opłacane.
• Rozwój techniczny – kontakt z nowoczesnym stackiem: chmura, kontenery, automatyzacja, observability.

Najważniejszy jest jednak inny aspekt: zmiana z trybu „reaktywnego strażaka” na świadomego inżyniera, który projektuje procesy tak, żeby pożary zdarzały się coraz rzadziej.

Zmiana roli to przede wszystkim zmiana sposobu myślenia

Przejście z admina do DevOps/SRE nie zaczyna się od nauki konkretnego narzędzia, ale od zmiany podejścia:

• z „jak to szybko naprawić” na „jak to zaprojektować, żeby się nie psuło”,
• z „zaloguję się i poklikam” na „napiszę skrypt/playbook, żeby zrobić to zawsze tak samo”,
• z „moja działka to serwer” na „moją odpowiedzialnością jest cały przepływ zmian i niezawodność usługi”.

Nowa ścieżka kariery w DevOps polega na przejściu od ręcznego, incydentalnego działania do systematycznej inżynierii. Nazwa stanowiska jest wtórna – liczy się sposób pracy.

Kim naprawdę jest DevOps i SRE – rozróżnienie ról bez marketingowego szumu

DevOps: kultura, praktyki i stanowisko „człowieka od przepływu”

Słowo DevOps bywa nadużywane. Oznacza jednocześnie kulturę współpracy dev–ops, zestaw praktyk (CI/CD, automatyzacja, feedback loop) oraz konkretne stanowisko: „DevOps Engineer”. W małych firmach DevOps często jest „człowiekiem od wszystkiego, co między kodem a produkcją”.

Jeżeli spojrzeć na rolę inżyniera DevOps praktycznie, jego typowe obowiązki to:

• projektowanie, implementacja i utrzymanie pipeline’ów CI/CD,
• tworzenie i utrzymanie infrastruktury jako kod (Terraform, Ansible, CloudFormation, Pulumi itd.),
• konfiguracja i utrzymanie środowisk developerskich, testowych, stagingu i produkcji,
• integracja z zespołami developerskimi – doradztwo, jak budować aplikacje „pod deployment”,
• budowanie narzędzi i automatyzacji, które odciążają innych (np. self-service dla developerów).

DevOps jest więc inżynierem, który spina ze sobą świat programistów i operacji, często będąc właścicielem platformy, na której działają aplikacje.

Site Reliability Engineer – programista z obsesją na punkcie niezawodności

Site Reliability Engineer wyrósł z praktyk Google, które spisało swoje podejście do utrzymania dużych systemów. SRE to osoba, która łączy kompetencje developerskie, systemowe i operacyjne, ale z jednym głównym celem: utrzymać wysoką niezawodność usług przy jednoczesnym szybkim tempie zmian.

Kluczowe elementy pracy SRE to m.in.:

• definiowanie i monitorowanie SLO (Service Level Objectives) oraz pilnowanie error budget,
• projektowanie i wdrażanie mechanizmów automatycznego odzyskiwania po awariach,
• głęboka automatyzacja powtarzalnych zadań („toil”),
• analiza incydentów i prowadzenie post-mortemów bez szukania winnych, za to z realnymi usprawnieniami,
• projektowanie architektury pod niezawodność, skalowanie i odporność na błędy.

SRE częściej niż klasyczny DevOps pisze kod w głównym języku firmy (np. Go, Python, Java), tworząc narzędzia i biblioteki poprawiające niezawodność, a mniej koncentruje się na manualnej konfiguracji środowisk.

Różnice w profilu: DevOps vs SRE w praktyce

Choć zakres obowiązków bywa zbliżony, istnieją wyraźne różnice w profilu ról. Dobrze je widać, gdy zestawi się je obok siebie.

W wielu firmach role te się przenikają. W praktyce oznacza to, że ścieżka kariery DevOps bardzo często prowadzi naturalnie w stronę SRE, zwłaszcza gdy rośnie skala systemu i rośnie nacisk na niezawodność.

Gdzie występuje SRE, a gdzie „tylko” DevOps

Podział na DevOps i SRE nie jest wszędzie taki sam. Różne organizacje wprowadzają te role w różnym momencie rozwoju.

• Startupy i małe firmy produktowe – zwykle mają „DevOpsa od wszystkiego”, który łączy automatyzację, infrastrukturę i podstawowy monitoring. SRE pojawia się dopiero, gdy biznes urośnie, SLA stanie się krytyczne, a dostępność będzie miała realny wpływ na przychody.
• Średnie i duże firmy technologiczne – częściej rozdzielają role: osobny zespół platformowy (DevOps/Platform Engineering) i osobny zespół SRE, blisko produktów.
• Korporacje spoza IT (banki, telco, retail) – nazewnictwo bywa marketingowe: „DevOps” to czasem klasyczny admin z Ansible, „SRE” bywa po prostu nazwą zespołu utrzymania, ale bez metryk typu SLO czy error budget.

Rozsądniej więc patrzeć na zakres obowiązków i sposób pracy niż na sam tytuł. To one determinują, czy jesteś bardziej DevOps, czy już realnie pełnisz rolę SRE.

Punkt startu: klasyczny admin – co już masz, a czego brakuje

Atuty wyniesione z administrowania

Typowy administrator systemów startujący w kierunku DevOps/SRE ma już solidną bazę, która jest trudna do szybkiego nadrobienia przez czystych developerów. To m.in.:

• praktyczna znajomość systemów operacyjnych (Linux/Windows, usługi, uprawnienia),
• doświadczenie z sieciami (DNS, routing, firewalle, VPN, load balancery),
• kontakt z środowiskami produkcyjnymi – wie, jak wygląda realny ruch, backupy, odtwarzanie po awarii, migracje,
• umiejętność troubleshootingu pod presją czasu,
• zrozumienie, że „w teorii działa” ma małą wartość, jeśli coś nie działa dla użytkownika.

To są atuty, które w DevOps i SRE stanowią ogromny plus. W praktyce wielu świetnych SRE zaczynało właśnie jako admini lub inżynierowie sieci, bo mają we krwi myślenie o systemie jako całości.

Luki, które bolą przy próbie wejścia w DevOps

Ta sama ścieżka admina ma jednak wyraźne braki, które przy próbie wejścia w DevOps stają się widoczne. Najczęstsze z nich to:

• brak nawyku programowania na poziomie „produkcyjnym” – administrator zna podstawy Bash/PowerShell, ale nie pisze modułowych, testowalnych skryptów ani nie korzysta z dobrych praktyk developerskich,
• mała ekspozycja na Git, code review, pull requesty – praca odbywała się częściej przez ręczne zmiany niż przez repozytoria,
• brak praktyki w CI/CD – jeśli deployment odbywał się ręcznie lub pół-automatycznie, koncepcje pipeline’ów, artifactów czy promocji między środowiskami mogą być nowe,
• ograniczona styczność z testami automatycznymi i procesem wytwarzania oprogramowania jako takim.

Przy przejściu na DevOps i później na SRE trzeba więc dogonić świat developerski – nie po to, by pisać pełnoprawne aplikacje, ale żeby myśleć kodem i rozumieć cykl życia zmiany.

Od „klikacza” do inżyniera – zmiana sposobu pracy

Najistotniejsza transformacja admina w kierunku DevOps/SRE polega na zmianie podejścia:

• jeśli da się coś zrobić ręcznie – to znaczy, że da się to zautomatyzować,
• jeśli coś robisz więcej niż dwa razy – napisz skrypt lub playbook,
• jeśli problem się powtarza – szukaj przyczyny systemowej, a nie tylko „naprawiaj objawy”.

Admin nie zaczyna więc od zera. Ma już bazę, ale musi zbudować nad nią warstwę automatyzacji, programistycznych nawyków i zrozumienia procesu wytwarzania oprogramowania. To właśnie odróżnia ścieżkę kariery DevOps od tkwienia w roli „gościa od serwerów”.

Mapowanie ścieżki: z admina do inżyniera DevOps krok po kroku

Poziom 1 – Admin z elementami automatyzacji

Punkt startu to często rola „admina, który coraz więcej automatów robi sam”. Nie masz jeszcze tytułu DevOps Engineer, ale zaczynasz działać zgodnie z jego praktykami. Ten etap można świadomie zaprojektować.

Kluczowe elementy tego poziomu:

• Języki skryptowe – solidne podstawy Bash (Linux) lub PowerShell (Windows), a do tego wprowadzenie do Pythona jako bardziej uniwersalnego narzędzia.

Poziom 2 – Inżynier, który „myśli repozytorium”

W którymś momencie orientujesz się, że najwięcej czasu tracisz nie na samą konfigurację, ale na odtwarzanie tego, co zrobiłeś dwa tygodnie temu. Screeny i notatki w OneNote przestają wystarczać, bo reszta zespołu i tak nie wie, co się dzieje. To dobry moment, żeby przerzucić środek ciężkości na pracę „jako kod”.

Na tym poziomie głównym celem jest wejście w świat developerskich nawyków – nawet jeśli nadal głównie „utrzymujesz”:

• Git jako podstawowe narzędzie pracy – każdy skrypt, konfiguracja, playbook czy manifest trafia do repozytorium. Zaczynasz sensownie nazywać branche, robisz pull requesty, opisujesz commity.
• Przegląd kodu (code review) – prosisz innych o review swoich zmian i sam przeglądasz ich pracę. Dzięki temu uczysz się standardów, a nie tylko „jak to zrobić, żeby działało”.
• Struktura projektów – przestajesz wrzucać wszystko do jednego katalogu „scripts”; rozbijasz rzeczy na moduły, używasz wirtualnych środowisk (Python), katalogów roles w Ansible, trzymasz tajne dane poza repo.
• Dokumentacja blisko kodu – README, krótkie instrukcje uruchomienia, przykładowe komendy. Tak, żeby ktoś nowy w zespole mógł użyć twoich narzędzi bez dopytywania.

Różnica mentalna jest prosta: nie „zostawiasz po sobie setup zrobiony ręcznie”, tylko oddajesz zespołowi pakiet: kod + opis + historię zmian. To fundament, na którym później zbudujesz pipeline’y i automatyzację na większą skalę.

Poziom 3 – Infrastructure as Code i pierwsze poważne pipeline’y

Wyobraź sobie sytuację: dostajesz zadanie „postawić takie samo środowisko testowe jak produkcja, tylko mniejsze”. Jeśli pierwszą myślą jest: „OK, kliknę to samo w panelu”, to znaczy, że pora wskoczyć w IaC. Jeśli reagujesz: „Dobra, przekopiuję moduły Terraform i zmienię parametry”, jesteś na właściwej ścieżce.

Na tym etapie zaczyna się prawdziwy DevOps w sensie narzędziowym. Kluczowe elementy to:

• Infrastructure as Code – uczysz się jednego z popularnych narzędzi (Terraform, Pulumi, AWS CloudFormation, Azure Bicep). Najważniejsze nie jest samo narzędzie, tylko paradygmat:
  • stan środowiska opisany w kodzie,
  • zmiany wprowadzane przez merge do main/master,
  • przegląd zmian (plan, diff) przed „apply”.
• Konfiguracja jako kod – Ansible, Salt, Chef albo Puppet. Stare playbooki typu „10 zadań w jednym pliku” zaczynasz dzielić na role, zmienne środowiskowe, tagi. Coraz mniej logujesz się na serwer, coraz częściej ansible-playbook robi wszystko za ciebie.
• CI/CD na poważnie – konfigurujesz pierwsze pipeline’y:
  • lint dla skryptów i IaC (np. terraform fmt, ansible-lint),
  • automatyczne testy dla narzędzi, które piszesz (np. testy jednostkowe w Pythonie),
  • pipeline’y, które po merge do konkretnego brancha budują, testują i wdrażają zmiany na wybrane środowisko.
• Wersjonowanie środowisk – uczysz się myślenia: „ta wersja aplikacji + ta wersja bazy + ta wersja konfiguracji” tworzą konkretną całość, którą można odtworzyć.

To moment, kiedy przestajesz być „adminem z Ansible”, a zaczynasz przypominać inżyniera platformy. Twój wpływ nie ogranicza się już do jednej maszyny, ale do całego procesu tworzenia i odtwarzania środowisk.

Poziom 4 – Platform Engineering i praca produktowa

Wiele zespołów zatrzymuje się na etapie „mamy Ansible’a i Jenkinsa, więc jesteśmy DevOpsami”. Dopiero kolejny krok zmienia perspektywę: zaczynasz traktować swoją infrastrukturę i narzędzia jako produkt dla innych zespołów.

Na tym poziomie pojawia się kilka nowych akcentów:

• Platforma zamiast „serwera” – tworzysz wspólną platformę (np. Kubernetes + pipeline’y + monitoring), na której wiele zespołów może uruchamiać swoje aplikacje. Twoim „klientem” nie jest użytkownik końcowy, lecz developer, który ma szybko i przewidywalnie wrzucać zmiany na produkcję.
• Self-service – budujesz mechanizmy, dzięki którym zespoły same:
  • zakładają nowe środowiska (np. katalogi aplikacji, namespace’y w K8s),
  • konfigurują alerty,
  • odpalają pipeline’y,
  • zarządzają dostępami w ramach wytycznych bezpieczeństwa.
• Standaryzacja – zamiast 10 różnych sposobów deploymentu w 10 zespołach, tworzysz 2–3 standardowe ścieżki („z szablonu”):
  • np. standardowy template GitLab CI dla aplikacji w Pythonie,
  • gotowy helm chart lub kustomize dla typowej aplikacji webowej.
• Współpraca z developerami – jesteś na planningach, review i retrospektywach. Tłumaczysz, jakie ograniczenia ma infrastruktura i jakie wzorce działają dobrze przy danym obciążeniu.

Na tym etapie DevOps przestaje być „rolą od narzędzi”, a coraz bardziej przypomina rola produktowa – z odbiorcami, roadmapą, feedbackiem i priorytetami biznesowymi.

Poziom 5 – Od DevOps do SRE: niezawodność jako główny KPI

Przychodzi taki dzień, kiedy kolejna awaria produkcji przestaje być „słabym sprintem”, a zaczyna uderzać w konkretne kontrakty i SLA. Zmienia się rozmowa z „jak szybciej wdrażać” na „jak wdrażać szybko, nie psując dostępności”. To naturalny moment wejścia w obszar SRE.

Żeby z roli DevOps przejść w SRE, trzeba dołożyć kilka ważnych kompetencji i nawyków:

• Myślenie w SLO, a nie tylko w „zielonych dashboardach” – zamiast ogólnego „mamy monitoring”, definiujesz konkretne:
  • SLI (Service Level Indicators) – np. procent udanych requestów, latency poniżej progu, dostępność funkcjonalności,
  • SLO – cel, do którego dążysz (np. 99,9% udanych requestów w miesiącu),
  • error budget – akceptowalny margines błędów, który decyduje, czy możesz przyspieszyć, czy musisz zwolnić z wdrożeniami.
• Projektowanie pod awarie – nie zakładasz już, że „system będzie działał”, tylko że coś w końcu padnie. Wprowadzasz:
  • redundancję (multi-AZ, multi-region, aktywne–aktywne),
  • circuit breakery, time-outy, retry z backoffem,
  • mechanizmy graceful degradation – system działa w trybie „okrojonym”, ale nadal używalnym.
• Obserwowalność zamiast „logów gdzieś tam” – spinasz:
  • metryki (Prometheus),
  • logi (ELK, Loki, Splunk),
  • tracing (Jaeger, OpenTelemetry),

  tak, żeby dało się prześledzić całą ścieżkę requestu przez system i szybko znaleźć przyczynę problemu.

• Procesy incident managementu – on-call, rotacje, runbooki, eskalacje. Nie gasisz pożarów „jak popadnie”, tylko według ustalonych zasad, tak żeby każdy incydent kończył się konkretna nauką.
• Post-mortemy bez szukania winnego – po awarii organizujesz spotkanie, na którym:
  • opisujecie, co się stało (timeline),
  • szukacie przyczyn systemowych,
  • ustalacie poprawki techniczne i procesowe,
  • zapisujecie wnioski w bazie wiedzy.

SRE nie przestaje być DevOpsiakiem – raczej dodaje na wierzch warstwę odpowiedzialności za niezawodność. Twój główny wskaźnik sukcesu to już nie tylko „czas wdrożenia”, ale też „czas niedostępności” i „czas przywrócenia po awarii”.

Checklist: z admina do DevOps/SRE – kompetencje do odhaczenia

Dobrze działa prosta, szczera lista „mam / nie mam”, z którą możesz regularnie się konfrontować. Nie jako wyścig, ale jako mapa postępu.

Fundament systemowo-sieciowy (start admina):

• swobodne poruszanie się po Linux/Windows Server (usługi, logi, uprawnienia),
• zrozumienie podstaw TCP/IP, DNS, HTTP, load balancing, VPN,
• praktyka w backupach, odtwarzaniu, migracjach, podstawach bezpieczeństwa (SSH, certyfikaty, firewall).

Automatyzacja i skrypty (Poziom 1–2):

• codzienna praca w Bash/PowerShell,
• co najmniej jeden język „wyższego poziomu” (Python, Go) używany do realnych zadań,
• wszystkie skrypty trzymane w Git, z sensowną strukturą repo.

IaC i CI/CD (Poziom 3):

• znajomość narzędzia IaC i użycie go w przynajmniej jednym projekcie (od zera do działającego środowiska),
• konfiguracja pipeline’ów w Jenkinsie/GitLab CI/GitHub Actions (lint, testy, deploy),
• umiejętność rollout/rollback zmian z użyciem pipeline’u, a nie ręcznego „naprawiania na serwerze”.

Platforma i współpraca (Poziom 4):

• doświadczenie z konteneryzacją (Docker) i przynajmniej jednym orchestrator’em (Kubernetes, Nomad),
• budowa lub utrzymanie wspólnej platformy dla więcej niż jednego zespołu developerskiego,
• kontakt z developerami na poziomie planowania i przeglądu rozwiązań, a nie tylko reagowania na tickety.

Reliability i SRE (Poziom 5):

• zdefiniowane SLI/SLO dla przynajmniej jednej usługi,
• system alertowania oparty o objawy dla użytkownika, a nie tylko o metryki infrastruktury,
• udział w on-call, obsłudze incydentów i post-mortemach,
• konkretne zmiany w architekturze/infrastrukturze wprowadzone po incydentach (nie tylko „zwiększyliśmy CPU”).

Przegląd takiej listy raz na kilka miesięcy daje dużo więcej niż kolejny przeczytany artykuł. Od razu widać, czy robisz ruch w stronę DevOps/SRE, czy tylko zmieniłeś tytuł na LinkedIn.

Strategia nauki: jak dobierać projekty, żeby faktycznie rosnąć

Największy błąd, jaki popełnia wielu adminów, to poleganie wyłącznie na kursach. Na slajdach wszystko wygląda prosto, a później przychodzi realny projekt i okazuje się, że „to nie jest ten sam Terraform”. Różnicę robią projekty, w które się angażujesz w pracy i po godzinach.

Dobrym schematem jest podejście „małe kroki, ale realne problemy”:

• Automatyzuj istniejące zadania – zamiast pisać kolejny skrypt „do szuflady”, wybierz coś, co faktycznie robisz często (np. onboarding użytkownika, zakładanie środowiska testowego) i zrób to porządnie: repo, README, użycie w zespole.
• Wejdź w projekt deweloperski – poproś o dołączenie do małego serwisu, żeby przejąć za niego CI/CD, monitoring i deployment. Uczysz się w realnym kontekście, z realnymi bugami i presją czasu.
• Pobaw się w mini-SRE po godzinach – postaw własną aplikację (np. prosty blog, mały serwis API) w chmurze, dodaj monitoring, alerty, zrób test chaos engineering (wyłącz jeden komponent i sprawdź, co się dzieje). To bardzo otwiera oczy.
• Dokumentuj i dziel się – opisuj w Confluence, wewnętrznym wiki lub nawet w małym blogu firmowym, co zrobiłeś, jakie miałeś problemy i jak je rozwiązałeś. To wymusza uporządkowanie wiedzy.

DevOps i SRE to role głęboko praktyczne. Każdy sensowny krok naprzód wynika z przepracowanego problemu, a nie z dodatkowego slajdu w prezentacji.

Zmiana mentalna: z „bo tak się robiło” do „czy to ma sens w skali?”

Na koniec tej ścieżki coraz rzadziej zadajesz pytanie „jak to szybko naprawić”, a coraz częściej „czy to rozwiązanie przetrwa kolejne 10 razy, kiedy coś pójdzie nie tak”. To jest ten moment, w którym z administratora stajesz się inżynierem odpowiedzialnym za cały ekosystem.

Ścieżki awansu: indywidualny kontrybutor, lider techniczny, manager

Przychodzi dzień, kiedy nie chodzi już tylko o to, żeby „znać Kubernetesa lepiej”. Na spotkaniu rocznym słyszysz pytanie: „to co dalej z twoją rolą – bardziej leadership, czy wchodzisz głębiej w technikalia?”. I wtedy zaczyna się prawdziwe mapowanie kariery, a nie tylko lista technologii do poznania.

W DevOps/SRE masz zazwyczaj trzy główne kierunki rozwoju – każdy wymaga trochę innego zestawu umiejętności i nastawienia.

• Indywidualny kontrybutor (IC) – specjalista od głębokich tematów:
  • kopiesz głęboko w jeden–dwa obszary (np. Kubernetes i sieci, observability, security),
  • projektujesz i wdrażasz złożone rozwiązania, często jako „ostatnia deska ratunku” przy trudnych incydentach,
  • piszesz narzędzia i biblioteki, z których korzystają inni DevOpsi i developerzy.
• Lider techniczny (Tech Lead / Lead SRE) – odpowiedzialny za kierunek techniczny zespołu:
  • mniej sam klepiesz YAML-e, częściej podejmujesz decyzje „jak ma wyglądać platforma za rok”,
  • pomagasz innym w projektowaniu rozwiązań, robisz design review,
  • ustalasz standardy: jak piszemy pipeline’y, jak definiujemy SLO, jak robimy on-call.
• Manager (Engineering Manager / Head of SRE) – skupiony na ludziach i procesach:
  • dbasz o to, żeby zespół miał właściwe priorytety i zasoby,
  • prowadzisz rekrutacje, rozmowy rozwojowe, ustalasz budżety na sprzęt i szkolenia,
  • rozmawiasz z biznesem: tłumaczysz, dlaczego reliability to nie „fanaberia inżynierów”.

Żaden z tych kierunków nie jest „lepszy”. Jako SRE możesz zarabiać świetnie zarówno jako IC, jak i manager. Różnica jest w tym, co cię kręci na co dzień – rozkminianie pakietów w tcpdump, czy raczej układanie zespołu tak, żeby inni mogli błyszczeć.

Przejście z admina do DevOps w małej firmie vs w korpo

Admin w 50-osobowym software house’ie często ogarnia wszystko od kabli po VPN-y. W korpo jesteś „tym od Linuxów w drugim DC”. Obie ścieżki mogą prowadzić do DevOps/SRE, ale dynamika ruchu będzie inna.

W małej firmie droga bywa bardziej chaotyczna, ale za to szybciej dotykasz pełnego spektrum tematów:

• masz większą swobodę wprowadzania narzędzi („od jutra testujemy GitLab CI dla wszystkich projektów”),
• łatwiej dociągnąć się do całego lifecycle’u: od potrzeby biznesowej, po monitoring na produkcji,
• często formalnie nadal jesteś „adminem”, ale realnie robisz już DevOps/SRE.

W dużej organizacji szybciej trafisz na uporządkowane procesy, ale masz wąszy wycinek rzeczywistości:

• uczestniczysz w konkretnej części łańcucha (np. tylko CI/CD albo tylko observability),
• mocno wchodzi w grę compliance, change management, CAB – dużo dokumentacji i uzgodnień,
• łatwiej znaleźć mentora z konkretnej dziedziny, bo ekspertów jest po prostu więcej.

Sensowny krok z perspektywy kariery: z małej firmy „od wszystkiego” przejść po 2–3 latach do większej organizacji, żeby zobaczyć, jak wygląda skala i procesy. Albo odwrotnie – z korpo do mniejszej firmy, żeby wreszcie mieć wpływ na całość platformy.

Jak mówić o swojej ścieżce: portfolio, CV i rozmowy o pracę

Na rozmowie rekrutacyjnej admin po kilku latach często mówi: „w sumie robię wszystko po trochu”. Rekruter słyszy to już trzeci raz dzisiaj i szuka konkretu. Tu właśnie przydaje się świadoma narracja o swojej ścieżce DevOps/SRE.

Najprostsze narzędzie to mini-portfolio projektów, opisane językiem problem–rozwiązanie–efekt:

• Problem – np. „deploye na produkcję robiły się ręcznie po SSH, często w nocy, dużo błędów”,
• Rozwiązanie – „wdrożyłem GitLab CI z automatycznym buildem, testami i canary deployem na Kubernetesie”,
• Efekt – „czas wdrożenia skrócił się z godzin do minut, zniknęły typowe błędy kopiuj-wklej, wprowadziliśmy dzienne deploye”.

Takie historie możesz mieć opisane choćby w prostym dokumencie tekstowym albo w prywatnym repo. Ważne, by w rozmowie umieć je opowiedzieć własnymi słowami, a nie listą buzzwordów.

W CV zamiast ogólnego „utrzymanie serwerów Linux, konfiguracja Apache, backupy” lepiej sprawdza się podejście zadaniowe:

• „Zaprojektowałem i wdrożyłem pipeline CI/CD dla 15+ serwisów w GitLab CI (build, testy, deploy na Kubernetesie).”
• „Zastąpiłem ręczne konfiguracje serwerów kodem w Ansible (ok. 40 maszyn, rollout bez przestojów).”
• „Współtworzyłem proces on-call i incident managementu (runbooki, retrospektywy po incydentach).”

Rozmowy techniczne w DevOps/SRE często są oparte na scenariuszach, nie tylko na pytaniach z teorii. Dobrze mieć przygotowane 2–3 przykłady większych problemów, które rozwiązałeś – z detalami, co sprawdziłeś, co nie zadziałało i co poprawiłeś.

Najczęstsze ślepe uliczki na drodze z admina do SRE

Jeden z adminów, z którym pracowałem, robił genialne skrypty do automatyzacji. Po trzech latach okazało się, że poza nim nikt właściwie nie rozumie, co się tam dzieje, a sam utknął w roli „gościa od tego jednego krytycznego skryptu”. To dobry przykład, jak można zablokować sobie ścieżkę.

Na trasie admin → DevOps → SRE kilka pułapek pojawia się wyjątkowo często:

• Samotna wyspa automatyzacji – robisz rzeczy fajne technicznie, ale:
  • nikt poza tobą ich nie używa,
  • brakuje dokumentacji i przekazania wiedzy,
  • biznes nie widzi, co się poprawiło.

  Automatyzacja, której nie da się utrzymać bez jej autora, nie jest krokiem w stronę DevOps, tylko nowym pojedynczym punktem awarii.

• Kult narzędzia – „wszystko musi być w Kubernetesie”, „tylko Terraform ma sens”. W efekcie:
  • proste systemy dostają overengineering,
  • zespół frustruje się, bo „dla bloga” nagle trzeba poznać 10 nowych narzędzi,
  • trudno ci potem uzasadnić swoje decyzje architektoniczne.

  SRE to przede wszystkim rozsądek: dobrać najprostsze rozwiązanie, które spełni wymagania niezawodności i skali.

• Brak pracy z ludźmi – uciekasz w terminal i narzędzia, unikasz:
  • rozmów z developerami o wymaganiach,
  • wyjaśniania zespołowi, dlaczego zmieniasz proces deployu,
  • uczestnictwa w planningach i refinements.

  Bez tego trudno przejść wyżej niż poziom „admina od nowoczesnych narzędzi”.

• Gasisz pożary zamiast je analizować – lubisz akcję przy incydentach, ale:
  • po każdym outagu kończy się na „dorzuciliśmy CPU”,
  • nie ma post-mortemów ani listy działań naprawczych,
  • te same awarie wracają jak bumerang.

  SRE to przede wszystkim systemowe redukowanie przyszłych incydentów, a nie heroiczne naprawianie tych bieżących.

Unikanie tych ślepych uliczek często nie wymaga nowych technologii, tylko innych nawyków: dokumentowania, rozmawiania z ludźmi, myślenia długoterminowego.

Jak uczyć się narzędzi „przy okazji”, a nie „z listy buzzwordów”

Scenariusz bywa podobny: kupujesz kurs „Kubernetes od A do Z”, robisz moduły po kolei, a potem siadasz przed realnym klastrem i wszystko wygląda inaczej. To normalne – dlatego bardziej opłaca się uczyć narzędzi pod konkretny cel.

Praktyczne podejście do nauki narzędzi DevOps/SRE może wyglądać tak:

• Najpierw problem, potem narzędzie – zamiast „chcę się nauczyć Prometheusa”, zacznij od „chcę widzieć, czy moja aplikacja działa poprawnie w nocy”. Wtedy:
  • myślisz w kategoriach metryk, alertów, dashboardów,
  • Prometheus, Alertmanager i Grafana stają się tylko środkami do osiągnięcia celu.
• Minimalny działający wycinek – nie stawiaj od razu pełnego stacka „jak w dużej firmie”:
  • zacznij od jednego serwisu + Prometheus + prosty dashboard,
  • dodawaj kolejne elementy dopiero wtedy, gdy pojawia się realna potrzeba (np. alerty na Slacka).
• Reflektuj, co cię spowalniało – po mini-projekcie zapisz:
  • jakie pojęcia były niejasne (np. relabeling, service discovery),
  • co sprawiło najwięcej kłopotów (np. sieć w Kubernetesie, prawa w IAM),
  • czego chciałbyś uniknąć przy następnym podejściu.

  To naturalna lista tematów na dalszą naukę, zamiast przypadkowych tutoriali.

Narzędzie „wchodzi w krew” wtedy, gdy widzisz, jak pomaga realnym ludziom – developerom, supportowi, klientom. Samo „odhaczenie kursu” robi wrażenie tylko przez chwilę.

Budowanie sieci kontaktów w świecie DevOps/SRE

Pewien admin po latach zmiany po firmach zorientował się, że o kolejnych rolach dowiadywał się wyłącznie z ogłoszeń. Nie znał nikogo „z branży”, z kim mógłby pogadać o tym, jak wygląda SRE w innych organizacjach. To częsta sytuacja, gdy latami siedzisz w serwerowni lub w cichym rogu open space’u.

Sieć kontaktów w DevOps/SRE to nie tylko „networking” na konferencjach. Możesz zacząć bardzo nieformalnie:

• wewnętrzne community – jeśli firma ma gildie/chapters:
  • dołącz do grupy „Platform/DevOps/SRE”,
  • zaproponuj krótką prezentację o narzędziu, którego użyłeś (nawet 15 minut na wewnętrznym meet-upie),
  • zadaj pytania starszym kolegom zamiast odkrywać wszystko od zera.
• lokalne meetupy – nawet jeśli nie lubisz wystąpień:
  • posłuchasz, jak inne firmy podchodzą do CI/CD, on-call, SLO,
  • po prezentacji możesz podejść z jednym konkretnym pytaniem,
  • z czasem może z tego wyjść mentorship albo oferta pracy.
• online – Slack/Discord/fora – grupy typu „DevOps Polska”, „SRE”:
  • możesz anonimowo zapytać o rozwiązanie problemu z Terraformem,
  • zobaczysz, jakie narzędzia są faktycznie używane, a jakie tylko marketingowo nośne,
  • łatwiej wyłapać, jakie kompetencje są obecnie w cenie.

Relacje z innymi inżynierami często odblokowują kariery szybciej niż kolejny certyfikat. Ktoś podsunie ci projekt, ostrzeże przed pułapką albo pokaże, jak dana rola wygląda „od środka”.

Przejście na on-call: pierwsza linia SRE w praktyce

Moment wpisania się na listę on-call bywa stresujący. Telefon o 3:17 w nocy, serwis stoi, a ty jesteś „tym, kto ma zrobić pierwsze ruchy”. Ten etap mocno zmienia sposób patrzenia na systemy i na własną karierę.

Dobrze przygotowany on-call ma kilka cech, które zdecydowanie podnoszą jakość życia:

• Runbooki i playbooki – przed pierwszym dyżurem:
  • masz opisane typowe incydenty („brak miejsca na dysku”, „spadek sla_api_success_rate”),
  • krok po kroku: co sprawdzić, jak zdiagnozować, kiedy eskalować,
  • jasno spisane, które systemy są krytyczne, a które mogą poczekać do rana.
• Alerty oparte na objawach – nie dostajesz powiadomienia o każdym skoku CPU:
  • sygnały są powiązane z doświadczeniem użytkownika (np. wzrost błędów 5xx, spadek throughputu),
  • unikasz lawiny alertów, gdy padnie np. jeden komponent w łańcuchu,
  • lepiej wiesz, co naprawdę boli system i klientów.

Najczęściej zadawane pytania (FAQ)

Czym się różni admin systemowy od DevOpsa i SRE w praktyce?

Admin odbiera telefon o 3:00 w nocy, loguje się na serwer i „klika”, żeby przywrócić usługę. DevOps woli mieć pipeline, który wdraża zmiany jednym commitem, a SRE – system alertów, runbooki i automatyczne procedury naprawcze.

Administrator systemów skupia się głównie na serwerach, systemach operacyjnych i podstawowych usługach: konfiguruje, aktualizuje, reaguje na zgłoszenia i awarie. DevOps projektuje przepływ zmian (CI/CD, infrastruktura jako kod, automatyzacja provisioning’u), a SRE patrzy na całość usługi: niezawodność, SLO, error budget, eliminowanie „toil” i przyczyn awarii.

Najprościej: admin „utrzymuje serwery”, DevOps „buduje i automatyzuje platformę pod deployment”, a SRE „pilnuje niezawodności całego systemu”.

Jak przejść z roli admina na ścieżkę DevOps lub SRE?

Wielu adminów zaczyna od gaszenia pożarów, a dopiero po kilku latach odkrywa, że może projektować systemy tak, żeby tych pożarów było mniej. Ten moment „dość tego klikania” to zwykle najlepszy impuls, żeby wejść na ścieżkę DevOps/SRE.

Pierwszy krok to zmiana sposobu myślenia: zamiast „jak szybko naprawić” – „jak zaprojektować, żeby się nie psuło”; zamiast ręcznych działań – skrypty, playbooki i IaC; zamiast myślenia o pojedynczym serwerze – odpowiedzialność za cały przepływ zmian i niezawodność usługi. Technicznie warto wejść w CI/CD, kontenery, chmurę, Terraform/Ansible i podstawy monitoringu oraz alertingu.

Po zbudowaniu fundamentów DevOps naturalnym kolejnym etapem jest SRE: praca z SLO, incydentami, post‑mortemami i projektowaniem architektur pod niezawodność. Nazwa stanowiska mniej się liczy niż to, że przestajesz być „reaktywnym strażakiem”, a stajesz się inżynierem procesu i niezawodności.

DevOps czy SRE – którą ścieżkę kariery wybrać?

Jeśli lubisz projektować pipeline’y, automatyzować deployment i budować „platformę dla developerów”, bliżej ci do DevOpsa. Jeśli bardziej kręcą cię SLO, wykresy z Prometheusa, stabilność pod obciążeniem i analizy incydentów – kierunek SRE będzie naturalny.

DevOps częściej skupia się na przepływie zmian: CI/CD, IaC, środowiska, integracje. SRE ma za główny cel niezawodność usług: alerting, resiliency, autoscaling, chaos engineering. W wielu firmach zakres obowiązków się miesza, więc możesz zacząć jako DevOps i stopniowo przejść w stronę SRE, gdy skala systemu i oczekiwania biznesu rosną.

Dobra wskazówka: w małych firmach szybciej wejdziesz w DevOps „od wszystkiego”, w większych – łatwiej o wyspecjalizowaną rolę SRE z mocnym naciskiem na niezawodność.

Jakie umiejętności są kluczowe, żeby zostać DevOpsem?

Typowy dzień DevOpsa to mniej klikania po serwerach, a więcej pracy nad pipeline’ami i infrastrukturą jako kod. Zamiast ręcznie zakładać środowiska, buduje szablony, które robią to w powtarzalny sposób dla całego zespołu.

Kluczowe obszary to:

• CI/CD – np. Jenkins, GitLab CI, GitHub Actions i ogólny model pipeline’ów;
• infrastruktura jako kod – Terraform, Ansible, CloudFormation, Pulumi;
• kontenery i orkiestracja – Docker, Kubernetes;
• chmura publiczna – AWS, Azure, GCP (przynajmniej jedna dobrze);
• automatyzacja i scripting – Bash, Python, czasem Go.

Do tego dochodzi współpraca z developerami: rozumienie, jak budują aplikacje, jak wyglądają artefakty, testy, strategie deploymentu (blue‑green, canary). Im więcej rzeczy potrafisz zamienić w kod i pipeline, tym bliżej ci do dobrego DevOpsa.

Co robi SRE na co dzień i czym jego praca różni się od DevOpsa?

Gdy DevOps zastanawia się, jak szybciej i bezpieczniej dowieźć nowe wersje, SRE patrzy, czy tempo zmian nie rozwala niezawodności. Przykład z życia: DevOps buduje pipeline pod dziesięć deployów dziennie, a SRE ustala SLO i pilnuje, żeby liczba błędów przy tych deployach mieściła się w error budget.

Na co dzień SRE:

• definiuje i monitoruje SLO oraz zarządza error budget;
• projektuje mechanizmy automatycznego odzyskiwania po awariach;
• eliminuje „toil” – ręczne, powtarzalne zadania przez automatyzację;
• analizuje incydenty i prowadzi post‑mortemy bez „szukania winnego”, za to z realnymi usprawnieniami;
• współprojektuje architekturę pod niezawodność, skalowanie i odporność na błędy.

SRE częściej pisze kod w głównym języku firmy (np. Go, Python, Java) i tworzy narzędzia oraz biblioteki poprawiające reliability, podczas gdy DevOps jest bliżej narzędzi infrastrukturalnych i samego procesu deploymentu.

W jakich firmach szukać pracy jako DevOps, a gdzie pojawia się rola SRE?

W startupach i małych firmach produktowych bardzo często trafisz na ogłoszenia typu „DevOps od wszystkiego”: trochę chmury, trochę skryptów, trochę monitoringu. SRE zwykle pojawia się dopiero wtedy, gdy biznes rośnie, SLA robi się krytyczne, a każda godzina niedostępności zaczyna realnie kosztować.

W średnich i dużych firmach technologicznych role są częściej rozdzielone. Możesz spotkać zespoły platformowe (DevOps/Platform Engineering), które odpowiadają za narzędzia i platformę, oraz osobne zespoły SRE, które dbają o niezawodność konkretnych produktów lub domen. W korporacjach, które przeszły już kilka lat transformacji do chmury, model SRE jest niemal standardem przy dużych, krytycznych systemach.

Dobrym wskaźnikiem jest opis obowiązków w ofercie: jeśli dominuje CI/CD i IaC – to głównie DevOps; jeśli mocny nacisk pada na SLO, incident management, dostępność i wydajność – to już rola zbliżona do SRE, niezależnie od tytułu na wizytówce.

Czy automatyzacja i chmura „zabiją” klasycznych adminów?

Coraz więcej zadań, które kiedyś wykonywał admin (ręczne zakładanie serwerów, konfiguracja backupów, podstawowy monitoring), przejmują usługi zarządzane w chmurze. Tam, gdzie dawniej trzeba było pary rąk do każdej maszyny, dziś wystarcza kilka linii kodu w Terraformie.

Co warto zapamiętać

• Przeskok z roli klasycznego admina do DevOps/SRE to droga od nocnych „gaszeń pożarów” do zaprojektowanych procesów, gdzie większość awarii obsługują automaty i runbooki zamiast człowieka na telefonie.
• Administrator myśli głównie o serwerach i ręcznym utrzymaniu, DevOps o przepływie zmian (CI/CD, IaC, automatyzacja środowisk), a SRE o niezawodności całego systemu, od kodu po doświadczenie użytkownika.
• Praca reaktywnego admina sprzyja wypaleniu i traci na znaczeniu przez automatyzację oraz usługi chmurowe, podczas gdy kompetencje DevOps/SRE – łączące infrastrukturę, programowanie i procesy – są coraz lepiej wyceniane i dają większy wpływ na produkt.
• Kluczowa zmiana to przejście z trybu „jak szybko naprawić awarię” na „jak zaprojektować system, żeby awarii było coraz mniej”, czyli z klikania na skrypty, z myślenia o serwerze na myślenie o całym przepływie zmian i niezawodności usługi.
• DevOps to „człowiek od przepływu” między kodem a produkcją: buduje pipeline’y CI/CD, infrastrukturę jako kod, środowiska i narzędzia self-service, które przyspieszają pracę developerów i zmniejszają liczbę ręcznych zadań.
• SRE to inżynier nastawiony na niezawodność, który definiuje SLO i error budget, automatyzuje powtarzalną pracę („toil”), analizuje incydenty bez polowania na winnych i współprojektuje architekturę pod skalę oraz odporność na błędy.