DevOps od podstaw — plan nauki na 2026 rok

DevOps to jedna z najszerszych ścieżek w IT. Bez planu łatwo utknąć między dziesiątkami narzędzi. Poniżej kolejność nauki DevOps od podstaw — co po czym, by zbudować realne kompetencje, a nie chaotyczną listę technologii.

Czym właściwie jest DevOps?

DevOps to nie pojedyncze narzędzie, lecz kultura i zestaw praktyk łączących development z operations: automatyzacja, ciągłe dostarczanie oprogramowania, niezawodność i współpraca zespołów. Narzędzia są środkiem, nie celem.

Plan nauki krok po kroku

Osiem etapów w kolejności, w której każdy opiera się na poprzednim. Przy każdym — co powinieneś umieć, zanim ruszysz dalej.

1. Linux i wiersz poleceń System plików, uprawnienia, procesy, podstawy sieci i Bash. Bez sprawnej pracy w terminalu reszta nie ma sensu — to absolutny fundament. Efekt: poruszasz się po serwerze bez interfejsu graficznego.
2. Git i kontrola wersji Repozytoria, branche, pull requesty, rozwiązywanie konfliktów. Git jest wszechobecny w pracy DevOps. Efekt: każdą zmianę konfiguracji trzymasz w repozytorium.
3. Kontenery — Docker Obrazy, kontenery, Dockerfile, sieci i wolumeny — brama do nowoczesnego wdrażania aplikacji. Różnice między Dockerem a Kubernetesem wyjaśniamy w artykule Docker vs Kubernetes. Efekt: aplikacja uruchamia się tak samo na każdej maszynie.
4. CI/CD — automatyzacja dostarczania Pipeline'y, które automatycznie budują, testują i wdrażają kod (np. GitLab CI, Jenkins, GitHub Actions). Serce praktyki DevOps. Efekt: każda zmiana w repozytorium przechodzi przez automatyczne testy.
5. Orkiestracja — Kubernetes Gdy kontenerów jest wiele: pody, deploymenty, serwisy, skalowanie. O karierze w tym obszarze pisaliśmy w artykule o karierze z Kubernetes. Efekt: aplikacja działa w klastrze i sama wraca po awarii.
6. Chmura Podstawowe usługi AWS, Azure lub GCP: maszyny, sieci, uprawnienia i koszty. Na start wystarczy jeden dostawca — dobry punkt wyjścia to AWS od podstaw. Efekt: wdrażasz aplikację poza własnym komputerem.
7. Infrastructure as Code Opisywanie infrastruktury kodem (Terraform) zamiast klikania w konsoli. To standard w nowoczesnych zespołach. Efekt: całe środowisko odtworzysz z kodu.
8. Monitoring i logowanie Obserwowalność systemów: metryki, logi, alerty (Prometheus, Grafana). Bez tego nie ma niezawodności. Efekt: o awarii dowiadujesz się z alertu, a nie od użytkownika.

Plan nauki DevOps na pierwsze 90 dni

Powyższa kolejność mówi, czego się uczyć. Ten plan porządkuje ją w czasie: trzy etapy po trzydzieści dni, a każdy kończy się czymś, co możesz komuś pokazać.

Dni 1–30: Linux, Git i podstawy sieci

Skup się na pracy w terminalu, systemie plików, uprawnieniach i procesach, na podstawach TCP/IP oraz na codziennej pracy z Gitem.

Rezultat: repozytorium z własnymi skryptami Bash oraz opisem konfiguracji środowiska.

Mini-projekt: skrypt Bash, który zakłada użytkownika, nadaje mu uprawnienia do katalogu i zapisuje log swojego działania — w repozytorium z README, które mówi, jak go uruchomić.

Przejdź dalej, gdy:

• zakładasz użytkowników i nadajesz uprawnienia bez szukania składni,
• z poleceń ps, ss i z logów odczytasz, co działa na maszynie i na jakim porcie,
• pracujesz na branchach i sam rozwiążesz konflikt w Gicie.

Dni 31–60: Docker i CI/CD

Naucz się budować obrazy, uruchamiać kontenery, pracować z Dockerfile i docker-compose oraz przygotuj prosty proces automatycznego budowania i testowania.

Rezultat: skonteneryzowana aplikacja oraz pipeline, który automatycznie ją buduje i testuje.

Mini-projekt: prosta aplikacja z bazą danych uruchamiana przez docker-compose oraz pipeline, który przy każdym pushu buduje obraz i uruchamia testy.

Przejdź dalej, gdy:

• piszesz Dockerfile od zera i wiesz, po co są warstwy obrazu,
• pipeline zatrzymuje zmianę, która psuje testy,
• znajdziesz przyczynę, gdy kontener nie chce się uruchomić.

Dni 61–90: Infrastructure as Code, orkiestracja i monitoring

Poznaj podstawy opisywania infrastruktury kodem, wdrażania aplikacji w klastrze oraz obserwowalności systemu.

Rezultat: środowisko wdrożone z kodu, aplikacja uruchomiona w klastrze oraz podstawowy dashboard i alert.

Mini-projekt: to samo środowisko opisane w Terraform, aplikacja wdrożona w klastrze (wystarczy lokalny), dashboard z jedną metryką i alert na wypadek awarii.

Po 90 dniach sprawdź, czy potrafisz:

• usunąć środowisko i odtworzyć je z kodu,
• wyjaśnić, co robią deployment i service w Kubernetesie,
• pokazać alert, który sam przetestowałeś, wyłączając aplikację.

To plan pierwszych 90 dni nauki, a nie obietnica gotowości do pracy po trzech miesiącach. Tempo zależy od wcześniejszego doświadczenia, liczby godzin praktyki i jakości informacji zwrotnej.

Chcesz przejść tę ścieżkę z prowadzącym i projektami praktycznymi? Sprawdź program kursu DevOps oraz dostępne opcje dofinansowania.

Ile to trwa i jak się nie zniechęcić?

Nie podajemy jednego terminu dojścia do poziomu juniora — zależy on od wcześniejszego doświadczenia i liczby godzin praktyki, a pierwsze 90 dni to fundament, nie meta. Klucz to kolejność i praktyka: każdy etap ćwicz na własnym labie, nie przeskakuj fundamentów. Najczęstszy błąd to rzucanie się na Kubernetesa bez znajomości Linuksa i Dockera.

Szersze wprowadzenie do samego kursu znajdziesz w przewodniku po kursie DevOps. Jeśli dopiero porównujesz oferty, zacznij od tekstu jaki kurs DevOps online wybrać.

Czego unikać na starcie?

• nauki Kubernetesa bez znajomości Linuksa i Dockera,
• zbierania narzędzi bez zrozumienia, jaki problem rozwiązują,
• pomijania praktyki — DevOps poznaje się przez własne laby.

Jaki lab wybrać na wspólny punkt odniesienia?

DevOps od podstaw najlepiej ćwiczyć na jednej małej aplikacji, którą uruchamiasz, wersjonujesz, pakujesz, wdrażasz i obserwujesz. Każdy etap powinien kończyć się działającym artefaktem i opisem sposobu naprawy błędu.

Wystarczy niewielka aplikacja zwracająca odpowiedź HTTP i zapisująca prosty log. W repozytorium trzymaj kod, README i plik z przykładową konfiguracją; prawdziwe hasła oraz tokeny pozostaw poza repozytorium. Najpierw uruchom aplikację lokalnie, sprawdź port i odpowiedź klientem HTTP. Następnie celowo zajmij port innym procesem: czy potrafisz znaleźć przyczynę przez ss, log i status procesu? Ta diagnoza ma większą wartość niż instalowanie kilku platform bez rozumienia podstaw.

Co zrobić przed Dockerem i pipeline'em?

Zapisz instrukcję uruchomienia na świeżej maszynie testowej, określ zależności i dodaj prosty test odpowiedzi. Zrób branch, zmień komunikat aplikacji, otwórz pull request i sprawdź konflikt dwóch zmian. Dopiero kiedy druga osoba umie powtórzyć ręczną procedurę, opisz obraz kontenera. Dockerfile powinien jasno mówić, jakie pliki trafiają do obrazu i jaki proces jest uruchamiany. Unikaj przechowywania sekretów w obrazie. Kontener nie rozwiązuje problemu, jeśli nie wiesz, dlaczego aplikacja nie startuje.

Jak zaprojektować małą automatyzację?

Pipeline może mieć osobne kroki: instalacja zależności, test oraz budowa obrazu po pozytywnym wyniku. Na początku nie uruchamiaj automatycznego wdrożenia na publiczne środowisko. Ustal, co ma się stać przy nieudanym teście i jak powrócisz do działającej wersji. Prowadź zapis wersji obrazu, zamiast używać wyłącznie niejednoznacznego latest. Kryterium ukończenia tego etapu: nowa zmiana przechodzi test i daje obraz, a wadliwa zmiana zatrzymuje pipeline bez ręcznej interwencji w serwer.

Kiedy dodać infrastrukturę jako kod i monitoring?

Dopiero gdy potrafisz odtworzyć usługę i rozumiesz jej zależności. Dla środowiska testowego opisz minimalne zasoby w kodzie, sprawdź plan zmian przed zastosowaniem i przewidź sposób usunięcia zasobów, by nie generować zbędnych kosztów. Monitoring zacznij od pytania użytkownika: czy usługa odpowiada i czy błędy są widoczne? Jedna użyteczna metryka i sensowny alert są lepsze niż pulpit pełen niewyjaśnionych wykresów. Nie zakładaj, że samo użycie Kubernetesa poprawi niezawodność.

Jak zdecydować o następnym kroku nauki?

Pokaż repozytorium komuś, kto nie uczestniczył w budowaniu labu. Czy uruchomi projekt według README, znajdzie przyczynę awarii i przywróci usługę? Zapisz brakujące umiejętności, a następnie porównaj je z programem aktywnego kursu DevOps. Ten materiał rozwija praktykę, natomiast poradnik wyboru kursu pomaga ocenić format nauki. Jeśli rozważasz dofinansowanie, sprawdź uprawnienia i aktualne zasady osobno; nie jest ono automatyczne.

Jak złożyć z tych ćwiczeń projekt do portfolio — z artefaktami i kryteriami sprawdzenia na trzech poziomach — opisaliśmy w tekście projekty DevOps do portfolio.

Pierwsza praca w DevOps

Na start często wchodzi się przez role pokrewne (administracja, support, junior DevOps) i stopniowo przejmuje zadania automatyzacji. Prowadzoną ścieżkę z projektami daje kurs DevOps; różnice narzędzi wyjaśnia Docker vs Kubernetes.

Jeśli jesteś administratorem systemów, zobacz skróconą wersję planu dla swojej sytuacji: jak przejść z administracji do DevOps.

Chcesz uczyć się z planem i mentorem? Sprawdź kurs DevOps, a koszt rozłożysz na raty lub sprawdzisz dofinansowanie.