Jak przejść z administracji systemów do DevOps — co się przenosi, a co udowodnić

Administrator systemów ma już sporą część fundamentu DevOps: zna Linuksa, sieci, usługi i awarie na produkcji. Brakuje zwykle dowodów na trzy rzeczy — powtarzalną automatyzację w kodzie, pipeline CI/CD oraz infrastrukturę opisaną jako kod, najczęściej w chmurze. Ten tekst pokazuje, co się przenosi, jak ocenić lukę i jak w małym projekcie udowodnić brakujące umiejętności bez cudzej infrastruktury.

Co z doświadczenia administratora przenosi się do DevOps?

Większość tego, co robisz na co dzień, jest wartościowa — trzeba tylko nazwać to językiem nowej roli.

Różnica nie leży w tym, co wiesz, tylko jak pracujesz. Administrator często zmienia serwer ręcznie i zapisuje to w głowie lub w notatce. W DevOps każda zmiana ma być zapisana w repozytorium, sprawdzona automatycznie i możliwa do powtórzenia na innej maszynie.

Jak ocenić lukę: CI/CD, infrastruktura jako kod, chmura i monitoring?

Zamiast czytać długie listy wymagań, sprawdź siebie na czterech obszarach. Przy każdym zadaj sobie to samo pytanie: „czy potrafię to pokazać komuś, kto nie widział mojego serwera?”.

• Git i praca zespołowa. Czy trzymasz skrypty i konfiguracje w repozytorium, z historią zmian i opisem?
• CI/CD. Czy potrafisz skonfigurować pipeline, który po zmianie sam buduje, testuje i wdraża?
• Infrastruktura jako kod. Czy środowisko da się odtworzyć z plików (Terraform, Ansible), a nie z pamięci?
• Chmura i obserwowalność. Czy wiesz, jak uruchomić usługę w chmurze, ograniczyć uprawnienia i zbierać metryki oraz logi?

Dwa przykładowe ogłoszenia na stanowiska junior w DevOps, które przejrzeliśmy w październiku 2026 r., wymieniały: w pierwszym Azure, Terraform, Python, CI/CD, Dockera, Gita i Kubernetesa; w drugim Pythona, Ansible, CI/CD, Gita, Helma, Kubernetesa i Linuksa. To tylko dwa przykłady, a nie opis rynku ani dowód, że takie oferty są dostępne dziś — ale widać w nich część wspólnych wymagań: Pythona, CI/CD, Gita i Kubernetesa. Różnią się pozostałe: pierwsze ogłoszenie wymienia Azure i Terraform, czyli chmurę i infrastrukturę jako kod, a drugie Ansible, Helma i Linuksa, bez wskazania chmury. Nie wyciągaj stąd wniosków o całym rynku. Przed złożeniem CV zawsze czytaj aktualne ogłoszenia.

Jakie dwa ćwiczenia pokażą automatyzację i bezpieczeństwo bez cudzej infrastruktury?

Nie potrzebujesz dostępu do firmowych serwerów ani drogiej chmury. Wystarczą dwie maszyny wirtualne albo kontenery na własnym komputerze.

Ćwiczenie 1: konfiguracja serwera jako kod

Weź czystą maszynę wirtualną z Linuksem. Napisz playbook Ansible (lub skrypt), który instaluje i konfiguruje serwer WWW, tworzy użytkownika bez uprawnień administratora, zamyka niepotrzebne porty i wdraża prostą stronę. Uruchom go dwa razy — za drugim razem nic nie powinno się zmienić. Następnie zniszcz maszynę i odtwórz ją z playbooka. To najprostszy dowód, że rozumiesz idempotentność i że środowisko nie jest „ręcznie zbudowane”.

Ćwiczenie 2: pipeline z testem i skanem

Załóż repozytorium z małą aplikacją i Dockerfile. Skonfiguruj pipeline, który na każdy push buduje obraz, uruchamia test i zatrzymuje się, gdy test nie przechodzi. Dodaj prosty krok sprawdzający, czy w repozytorium nie ma haseł lub kluczy, a sekrety przekaż przez zmienne środowiskowe. Celowo zepsuj test i pokaż w historii, że pipeline to wychwycił.

Oba ćwiczenia robisz wyłącznie na własnych zasobach. Nie testuj ani nie konfiguruj cudzych serwerów bez pisemnej zgody ich właściciela.

Jak zapisać wynik w repozytorium, żeby ktoś go sprawdził?

Rekruter lub prowadzący nie zapyta Cię o to, co zrobiłeś, tylko otworzy repozytorium. Dlatego ułóż mini-projekt w kolejności, w której łatwo go odtworzyć. Poniższe kroki możesz potraktować jako listę kontrolną.

1. Wybierz jedną małą aplikację. Prosty serwis HTTP z jednym endpointem i bazą wystarczy; w projekcie DevOps ocenia się proces, nie złożoność aplikacji.
2. Zapisz konfigurację serwera w Ansible lub skrypcie. Kod ma doprowadzić czystą maszynę do działającego stanu bez ręcznych poprawek.
3. Dodaj Dockerfile i uruchomienie lokalne. Instrukcja w README powinna działać na czystej maszynie jednym poleceniem.
4. Skonfiguruj pipeline CI. Każdy push buduje obraz i uruchamia test, a nieudany test zatrzymuje zmianę.
5. Opisz środowisko jako kod. Użyj Terraform lub podobnego narzędzia i opisz, jak je zniszczyć i odtworzyć oraz ile kosztuje.
6. Dodaj monitoring i jeden alert. Metryki aplikacji i prosta reguła alertu, sprawdzona przez zatrzymanie usługi.
7. Dopisz notatkę o bezpieczeństwie i runbook. Uprawnienia, sekrety i kroki działania, gdy alert się odpali.

Ogólne zasady czytelnego repozytorium i trzy poziomy projektów opisaliśmy w tekście projekty DevOps do portfolio. Tutaj ważne jest coś innego: jako administrator masz przewagę, bo potrafisz opisać dlaczego wybrałeś taką konfigurację. Zapisz to w README — to odróżnia projekt przeklikany z poradnika od projektu własnego.

Od czego zacząć, jeśli luka jest duża?

Nie ucz się wszystkiego naraz. Kolejność, która sprawdza się osobom z doświadczeniem administracyjnym: najpierw Git i automatyzacja (skrypty, Ansible), potem kontenery, następnie CI/CD, a na końcu chmura z Terraform i monitoring. Kubernetes dochodzi dopiero wtedy, gdy kontenery i pipeline nie sprawiają trudności. Pełny, ogólny plan nauki — niezależnie od Twojego doświadczenia — znajdziesz w artykule DevOps od podstaw — plan nauki; ten tekst skraca go do tego, co dotyczy administratora.

Po czym poznać kurs odpowiedni dla pracującego specjalisty?

Pracujący administrator ma inne potrzeby niż osoba zaczynająca od zera. Sprawdź, czy kurs:

• pozwala pominąć lub szybko przejść to, co już umiesz, i skupić się na lukach,
• ma zajęcia w godzinach, które da się pogodzić z pracą, oraz dostęp do nagrań,
• zawiera ćwiczenia, w których sam piszesz kod infrastruktury i pipeline’y, a nie tylko oglądasz,
• daje informację zwrotną o Twoim projekcie,

Przykład z naszej strony: program kursu DevOps obejmuje systemy operacyjne, sieci i wirtualizację, narzędzia Unix, Gita, Basha, serwery WWW i bazy danych, zarządzanie konfiguracją, Dockera, Pythona, ciągłą integrację, AWS, infrastrukturę jako kod z Terraform, Kubernetesa oraz monitorowanie i logowanie, a na końcu konsultacje projektu dyplomowego. Po ukończeniu dostajesz certyfikat LearnIT. Jeśli większość pierwszych modułów już znasz, porównaj je ze swoją oceną luki, a nie z nazwą kursu. Jak wybierać między kursami DevOps ogólnie, opisuje tekst wybór kursu DevOps.

Macierz: umiejętność, którą masz, dowód i to, czego się nauczyć

Szczegóły wynagrodzeń na stanowiskach DevOps sprawdzisz na stronie zarobki DevOps; w tym tekście nie podajemy liczb, bo zależą od firmy, regionu i doświadczenia.

Lista kontrolna mini-projektu

• Czysta maszyna dochodzi do działającego stanu z kodu, bez ręcznych poprawek.
• Pipeline zatrzymuje zmianę, która psuje test.
• W repozytorium i w historii nie ma haseł ani kluczy.
• README pozwala komuś innemu uruchomić projekt.
• Koszt i sposób wyłączenia środowiska są opisane.
• Jest runbook z krokami na wypadek alertu.

Jak opowiedzieć o doświadczeniu administratora w CV i na rozmowie?

Zamiast listy zadań zapisz efekty i skalę: ile serwerów lub usług utrzymywałeś, co zautomatyzowałeś, ile czasu skróciłeś, co udało się wykryć szybciej. Jeśli nie masz liczb, opisz sytuację: jaki był problem, co zrobiłeś, co zmieniło się potem. Następnie dodaj link do repozytorium z mini-projektem. Rozmowa o DevOps często zaczyna się od pytania „opowiedz o ostatniej awarii” — dobrze opisany incydent z wnioskami pokazuje więcej niż nazwy narzędzi.

Unikaj dopisywania narzędzi, których nie użyłeś. Pytanie kontrolne „pokaż, jak to skonfigurowałeś” pojawia się szybko, a uczciwe „znam to z ćwiczeń, w produkcji jeszcze nie” jest bezpieczniejsze niż przesada.

Czy DevOps to programista?

Nie w klasycznym sensie. DevOps nie buduje funkcji aplikacji dla użytkowników, ale pisze kod, który buduje, testuje, wdraża i monitoruje aplikacje: skrypty, pliki konfiguracyjne i definicje pipeline’ów. Przydają się podstawy programowania, głównie w Pythonie i Bashu, oraz nawyk pracy z repozytorium i recenzją zmian. Dla administratora to naturalny krok, bo część skryptów już piszesz — teraz muszą być wersjonowane, testowane i powtarzalne.

Co z pracą na co dzień po przejściu?

Zmiana roli nie oznacza porzucenia kompetencji administracyjnych. Wiele zespołów potrzebuje osób, które rozumieją system od środka i potrafią zautomatyzować jego utrzymanie. Praca zwykle przesuwa się od ręcznych zmian na serwerach do utrzymania szablonów, pipeline’ów i środowisk, z większym naciskiem na współpracę z programistami. Zakres zależy od firmy, więc podczas rozmowy zapytaj, kto odpowiada za wdrożenia, kto za monitoring i jak wygląda dyżur.

Chcesz sprawdzić, które moduły programu DevOps odpowiadają Twojej luce? Sprawdź program kursu DevOps i zestaw go z własnym doświadczeniem. Jeśli ważny jest budżet, zajrzyj do warunków dofinansowania.