Od skryptów do platform: jak mądrze przekwalifikować się na DevOpsa w rok

Skąd startujesz: kim jest „skryptujący” specjalista i co już masz

Typowe punkty wyjścia – admin, QA, support, developer

Większość osób, które myślą o przejściu „od skryptów do platform”, nie zaczyna od zera. Najczęściej punkt wyjścia to jedna z czterech ról: admin systemowy, QA automatyzujący, developer lub osoba z technicznego supportu. Każdy z tych profili ma swoją specyfikę i swój zestaw przewag przy starcie w DevOps.

Admin systemowy zwykle dobrze zna Linuxa, podstawy sieci, narzędzia monitorujące i jakieś skrypty w Bashu czy PowerShellu. Ma obycie z logami i awariami, rozumie, co to jest uptime, ma kontakt z serwerami, maszynami wirtualnymi, czasem trochę z chmurą. Dla niego DevOps to bardziej przejście od „ręcznego administrowania” do „automatyzowania i projektowania platformy”.

QA automatyzujący często umie programować (Java, Python, JavaScript), zna narzędzia CI, bo uruchamia testy na pipeline’ach, ma kontakt z Dockerem, potrafi analizować logi aplikacyjne. Jego słabszą stroną bywają sieci i infrastruktura, ale za to rozumie cykl wytwarzania oprogramowania, umie pisać kod i jest blisko developerów.

Developer zna dobrze co najmniej jeden język programowania, rozumie git-flow, ma kontakt z CI/CD i często wie, jak wygląda aplikacja „od środka”. Zwykle natomiast ma mniejsze obycie z systemem operacyjnym od strony admina, nie czuje się pewnie w sieciach, balansowaniu ruchu, bezpieczeństwie czy monitoringu infrastruktury. To trzeba będzie nadgonić.

Support techniczny często ma najmniej formalnego „devopsowego” doświadczenia, za to bywa bardzo blisko użytkownika i produkcji. Zna realne problemy, umie diagnozować zgłoszenia, czytać logi, ogarnia podstawy narzędzi, z których korzystają klienci. Często potrafi trochę skryptować (SQL, Bash, PowerShell), ale brakuje mu szerszego spojrzenia na architekturę i automatykę.

Każdy z tych punktów startu nadaje się do wejścia w DevOps lub Platform Engineering w rok – pod warunkiem, że nazwiesz wprost swoje mocne i słabe strony i nie będziesz próbować na raz być „full stack dev + senior admin + ekspert od Kubernetesa”. Startujesz z konkretnym bagażem umiejętności, który da się świadomie rozbudować.

Twoje aktualne umiejętności vs. oczekiwania wobec DevOpsa

Rola DevOpsa czy Platform Engineera kojarzy się z długą listą technologii: Docker, Kubernetes, Terraform, AWS, Azure, GitLab CI, Prometheus, Grafana, Helm, Ansible, Vault, ArgoCD i tak dalej. Na papierze wygląda to jak kilka ścieżek kariery naraz. W praktyce, na poziomie junior/regular, rekruterzy szukają kogoś, kto potrafi w miarę stabilnie połączyć kilka obszarów: Linux, automatyzacja, CI/CD, podstawy chmury, komunikacja z zespołem.

Jeżeli już teraz:

• piszesz proste skrypty (Bash, Python, PowerShell),
• pracujesz na Linuxie choćby „od święta”,
• widziałeś CI (Jenkins, GitLab CI, GitHub Actions, Azure DevOps) chociaż jako użytkownik,
• rozumiesz podstawowe pojęcia sieciowe (IP, DNS, porty, HTTP),
• umiesz używać Gita w zespole (branch, commit, merge, pull request),

to twoja baza jest bliżej realnych oczekiwań wobec DevOps juniora, niż się zwykle wydaje. Problem nie leży w tym, że brakuje ci wszystkiego, tylko że te kompetencje są rozrzucone i nieskalibrowane. Roczny plan ma je poukładać i rozszerzyć tam, gdzie dziś masz największe luki.

Różnica między „klepaniem skryptów” a oczekiwanym profilem DevOpsa polega na przejściu z trybu reagowania na bieżący problem do trybu projektowania powtarzalnych, bezpiecznych procesów i platform. To wymaga trochę innego myślenia: nie „jak napisać skrypt do restartowania usługi”, tylko „jak zbudować proces, który sam wykryje problem, spróbuje restartu, zgłosi alert i zapisze kontekst w logach”.

Mini audyt umiejętności – jak uczciwie określić punkt startu

Żeby ułożyć sensowny plan przekwalifikowania na DevOpsa w rok, potrzebujesz krótkiego, brutalnie szczerego audytu. Nie chodzi o to, żeby się dobić, tylko żeby nie przepalać czasu na rzeczy, które już umiesz lub na tematy, które i tak są ci niepotrzebne na tym etapie.

Przykładowa, prosta checklista do zaznaczenia „umiem / kojarzę / nie mam pojęcia”:

• Linux: praca z terminalem (cd, ls, grep, tail, less), uprawnienia, procesy (ps, top, kill), systemd (systemctl), logi (journalctl, /var/log), ssh.
• Sieci: model klient–serwer, IP vs DNS, port, różnica TCP/UDP, podstawy HTTP (statusy, nagłówki), ping, traceroute, curl.
• Git: commit, branch, merge, rebase, pull request, prosty workflow zespołowy.
• Skrypty: napisałeś kiedyś skrypt, którego używa ktoś poza tobą (lub ty sam regularnie).
• CI/CD: wiesz, jak uruchomić testy lub build w jakimkolwiek narzędziu CI.
• Chmura: uruchomiłeś choć jedną maszynę wirtualną w AWS/Azure/GCP/innym.
• Kontenery: zbudowałeś i uruchomiłeś własny obraz Dockera (a nie tylko „docker run gotowy obraz”).

Odpowiedź „kojarzę” nie jest porażką – po prostu oznacza, że w pierwszych 3–4 miesiącach to tam powinna pójść część twojej energii. Gdy w kilku wierszach masz same „nie mam pojęcia”, to sygnał, że trzeba zacząć jeszcze bardziej od fundamentów i być może rozciągnąć głębię nauki na dłużej niż rok, ale wciąż warto celować w pierwszą rolę DevOps/Platform po około 12 miesiącach.

Przy tym audycie często pojawia się obawa: „Nie jestem full stackiem, czy w ogóle mam szansę?”. DevOps to z definicji praca na styku kompetencji, ale na poziomie juniora wystarczy, że masz przynajmniej jeden obszar, w którym już się dobrze poruszasz (np. Linux albo programowanie), a pozostałe ogarniesz do poziomu „praktyczne minimum”. Nikt nie oczekuje, że w rok zamienisz się w architekta Kubernetes na 500 węzłach.

Czym tak naprawdę jest DevOps i gdzie tu miejsce dla ciebie

DevOps, SRE, Platform Engineer – podobieństwa i różnice

Duża część zamieszania wokół przekwalifikowania na DevOpsa bierze się z tego, że nazwy ról i zakresy obowiązków są niejednolite. W jednej firmie DevOps to tak naprawdę admin z Dockerem, w innej – inżynier od CI/CD, a w kolejnej – platform engineer, który projektuje całą infrastrukturę pod dziesiątki zespołów.

Warto rozróżnić trzy mocno powiązane pojęcia:

• DevOps – w teorii to kultura współpracy developmentu i operacji, zestaw praktyk (CI/CD, automatyzacja, monitoring, feedback). W ogłoszeniach o pracę funkcjonuje jako rola „ktoś, kto ogarnia infrastrukturę pod development” z naciskiem na automatyzację, pipeline’y i chmurę.
• SRE (Site Reliability Engineer) – rola wywodząca się z Google. Bardziej skupiona na niezawodności systemów (SLO/SLA, error budget, automatyzacja on-call, monitoring, incident management). Zwykle mocno techniczna, ale mocno procesowa.
• Platform Engineer – osoba odpowiedzialna za budowę i utrzymanie platformy (najczęściej w chmurze lub na Kubernetesie), na której pracują zespoły deweloperskie. Dostarcza gotowe „klocki” (pipeline’y, szablony, środowiska, narzędzia), żeby developerzy nie musieli za każdym razem wymyślać koła na nowo.

Różnice między tymi rolami dobrze widać, gdy zestawi się typowe zadania na co dzień:

W praktyce ogłoszenie „DevOps Engineer” może mieć zakres bardzo zbliżony do SRE albo Platform Engineer. Dlatego przy planowaniu rocznej ścieżki przekwalifikowania bardziej opłaca się myśleć w kategoriach kompetencji, a nie etykiet. Celem jest zdobycie takiego zestawu umiejętności, który pozwoli ci wejść w jedną z tych ról na poziomie junior/regular i dalej się specjalizować.

DevOps w małej firmie vs w korpo – inne realia

Ścieżka nauki DevOps w rok powinna uwzględniać to, w jakim typie firmy chcesz wylądować. Inne są oczekiwania w piętnastoosobowym startupie, gdzie DevOps to trochę „człowiek od wszystkiego”, a inne w dużej korporacji, gdzie dział platformy ma kilkanaście osób, a każdy ma swoją niszę.

W małej firmie często będziesz:

• dotykać wielu obszarów – od konfiguracji serwera po przygotowanie pipeline’u i monitoringu,
• pracować z ograniczonym budżetem, więc częściej korzystać z open source i sprytnych obejść,
• mieć duży wpływ na wybór technologii, ale też większą odpowiedzialność za „gaszenie pożarów”,
• pracować bliżej biznesu i użytkowników końcowych.

W dużej organizacji zwykle:

• będziesz działać w węższym zakresie (np. tylko CI/CD, tylko Kubernetes, tylko monitoring),
• nauczysz się standardów, procedur, pracy z change managementem i bezpieczeństwem,
• masz dostęp do większej ilości narzędzi i budżetu (komercyjne platformy, szkolenia),
• częściej spotkasz dojrzałe procesy DevOps/SRE i większe skale systemów.

Na etapie nauki możesz świadomie ustawić akcenty. Jeśli celujesz w małą firmę, przyda ci się bardziej „szeroki” zestaw: podstawy chmury, CI/CD, kontenery, monitoring, trochę zabezpieczeń. Jeśli myślisz o korpo, nacisk warto położyć np. na jedną chmurę (AWS/Azure/GCP) i jeden obszar (np. CI/CD lub Kubernetes) trochę głębiej, bo tam rekruterzy bardziej lubią zobaczyć specjalistę niż „generalistę od wszystkiego”.

Co realnie da się opanować w rok przy pracy na etat

Realny plan nauki DevOps w rok przy pracy na pełen etat zakłada 8–10 godzin tygodniowo (czasem 12–15, jeśli masz okres sprintu, a potem przerwę). W takim tempie i przy rozsądnym podejściu „nie wszystko naraz” da się:

• zbudować solidne fundamenty z Linuxa i sieci (jeśli ich brakuje),
• opanować Gita na poziomie pracy zespołowej i nauczyć się wersjonować infrastrukturę i konfigurację,
• poznać Docker na tyle, żeby samodzielnie konteneryzować proste aplikacje i debugować problemy,
• zbudować kilka sensownych pipeline’ów CI/CD (build, test, deploy),
• nauczyć się podstaw jednej chmury (najlepiej tej, która pojawia się w ogłoszeniach, które cię interesują),
• wejść w Infrastructure as Code (Terraform lub alternatywa) na poziomie małych projektów,
• uruchomić podstawowy monitoring i logowanie,
• zbudować portfolio DevOps – 2–3 projekty, które możesz omówić na rozmowie rekrutacyjnej.

Nie da się natomiast w rok, przy pracy na pełen etat, stać się jednocześnie ekspertem od trzech chmur, trzech systemów CI/CD, Kubernetes na produkcję i zaawansowanego bezpieczeństwa. Jeżeli próbujesz wcisnąć to wszystko, skończysz z setką kursów i mętnym obrazem całości. Znacznie rozsądniej jest obrać „rdzeń” na start: automatyzacja + CI/CD + podstawy chmury, potem dobudowywać Kubernetes, IaC i monitoring.

LinkedIn lubi przesadzać z wymaganiami. Ogłoszenia z listą 25 technologii warto czytać filtrując: na poziomie junior/regular rekruter zwykle będzie zadowolony, jeśli zobaczy 5–8 pozycji ogarniętych realnie, nie tylko z kursu, a resztę jako „mile widziane, otwarty na naukę”.

Fundamenty techniczne przed startem – co musisz mieć „od ręki”

Linux i sieci – baza, bez której trudno ruszyć

Co konkretnie ogarnąć w Linuxie

Przy Linuxie łatwo się zgubić: dystrybucje, setki komend, konfiguracje. Na start nie chodzi o to, żeby umieć administrować 50 serwerami w trzech data center, tylko swobodnie poruszać się po jednym systemie i rozumieć, co się dzieje pod spodem.

Jako „praktyczne minimum” na pierwszy rok celuj w to, żeby:

• poruszać się po systemie z terminala (praca z katalogami, plikami, uprawnieniami),
• umieć przejrzeć logi i znaleźć w nich konkretne wpisy (journalctl, /var/log, grep),
• rozumieć procesy i umieć nimi zarządzać (ps, top, htop, kill, systemctl),
• zainstalować i skonfigurować podstawowe pakiety (apt, yum, dnf),
• edytować pliki konfiguracyjne w edytorze tekstowym (nano wystarczy na start, potem możesz dojść do vim),
• ogarniać użytkowników i grupy (dodanie usera, zmiana hasła, sudo),
• rozumieć podstawową strukturę systemu plików i typowe ścieżki.

Dobrą metodą jest postawić sobie jedną wirtualkę (np. Ubuntu Server) i używać jej jak „piachu treningowego”. Raz na kilka dni zrób tam coś małego: postaw Nginx, doinstaluj Git, zmień hostname, podejrzyj logi po restarcie. Z czasem to przestaje być „czarna magia”, a zaczyna być zwykłą codziennością.

Sieci dla DevOpsa – bez wzorów z CCIE

Sieci to kolejny temat, który potrafi przestraszyć. Na poziomie DevOps/Platform wcale nie jest potrzebna wiedza z pogranicza certyfikacji sieciowych. Znacznie bardziej liczy się praktyczne rozumienie tego, jak ruch płynie między serwisami i gdzie może się wysypać.

Na swoim poziomie skup się na tym, żeby:

• rozumieć podstawy: IP, porty, TCP/UDP, DNS,
• umieć sprawdzić, czy serwis odpowiada (curl, ping, traceroute, telnet/nc),
• kojarzyć, jak działa NAT i dlaczego aplikacja lokalnie działa, a w chmurze nie może się dogadać,
• znać różnicę między load balancerem, reverse proxy i zwykłym serwerem WWW,
• rozumieć pojęcia VPC/Virtual Network, subnet, security group/firewall – choćby na poziomie diagramu.

Przykład bardzo życiowy: aplikacja działa w Dockerze, ale nie dochodzi do bazy. Umiejętność sprawdzenia DNS-a kontenera, połączenia się po porcie i podejrzenia logów bazy rozwiązuje 80% tego typu problemów bez wołania „prawdziwego admina”.

Programowanie i skrypty – ile trzeba umieć, zanim ruszysz dalej

Jeśli już programujesz w Pythonie, JavaScripcie czy Bashu – jesteś do przodu. Jeśli bardziej „klikasz w narzędziach”, a kodu piszesz mało, nie oznacza to zamkniętej drogi do DevOpsa. Potrzebujesz po prostu poziomu, który pozwoli ci:

• napisać prosty skrypt automatyzujący powtarzalne zadanie (np. czyszczenie logów, backup, wywołanie API),
• rozumieć strukturę aplikacji, którą konteneryzujesz czy wdrażasz,
• przeczytać i drobnie zmodyfikować istniejący kod (np. dodać zmienną środowiskową, logowanie, konfigurację).

Dobrym kompromisem na początek jest tandem: Bash + jeden język ogólnego przeznaczenia (najczęściej Python lub JavaScript/TypeScript). Bash przyda się do małych skryptów, „sklejania” narzędzi i pipeline’ów. Drugi język pozwoli tworzyć trochę bardziej rozbudowane narzędzia czy lambdy/funkcje w chmurze.

Git i praca z repozytorium – nie tylko „git commit -m test”

Git jest w DevOpsie wszędzie: kod aplikacji, konfiguracje, manifesty Kubernetes, definicje infrastruktury. Jeśli do tej pory korzystałeś z Gita „od święta”, wygospodaruj kilka wieczorów na dojście do poziomu, w którym:

• swobodnie tworzysz brancha, mergujesz go i rozwiązujesz proste konflikty,
• rozumiesz różnicę między git merge, git rebase, git reset,
• potrafisz zrevertować nieudany commit czy pull request,
• umiesz korzystać z pull requestów / merge requestów i code review.

W praktyce wygląda to np. tak: pracujesz nad definicją pipeline’u w YAML, otwierasz PR, pipeline sam się uruchamia, widzisz, że coś padło, poprawiasz i dopiero po zielonym buildzie mergujesz. Tego typu workflow będziesz powtarzać setki razy.

Roczny plan przekwalifikowania – podział na kwartały i akcenty

Przy planowaniu roku łatwo popaść w skrajności: albo ambitna lista 40 technologii, albo totalny chaos „uczę się tego, co akurat wyświetli się na YouTubie”. Zdecydowanie lepiej podejść do tego jak do projektu – z etapami, akcentami i marginesem na życie, które po drodze na pewno się odezwie.

Załóżmy, że:

• pracujesz na pełen etat,
• masz przeciętnie 8–10 godzin tygodniowo na naukę,
• startujesz z poziomu: umiesz programować lub całkiem nieźle ogarniasz systemy, ale DevOps robisz dotąd „przy okazji”.

Przykładowy podział roku może wyglądać tak:

1. Q1 – Automatyzacja, Git, Docker, pierwsze pipeline’y
   Celem jest wskoczenie w praktyczne narzędzia i zobaczenie, jak wygląda „przepływ” od kodu do działającej aplikacji.
2. Q2 – Chmura + Infrastructure as Code
   Wybierasz jednego dostawcę (AWS/Azure/GCP) i jedno narzędzie IaC (najczęściej Terraform). Budujesz pierwsze sensowne środowiska.
3. Q3 – Kubernetes (lub alternatywa) + monitoring i logi
   Wchodzisz w orkiestrację kontenerów i obserwowalność – nie na poziomie „guru”, ale tak, żeby umieć uruchomić i zdiagnozować mikroserwis.
4. Q4 – Uporządkowanie, portfolio, przygotowanie do rekrutacji
   Zamiast dodawać kolejną technologię, integrujesz to, co masz: tworzysz 2–3 projekty „end-to-end”, ćwiczysz rozmowy i zadania praktyczne.

Ten plan można przesuwać zależnie od punktu startu. Jeśli masz już doświadczenie z chmurą, przyspieszysz Q2. Jeśli Linux to dla ciebie nowość – część Q1 poświęcisz na fundamenty systemowe i skrypty.

Jak mierzyć postęp, żeby nie utknąć

Dobrze działa podejście „mini-projektów” zamiast samego przerabiania kursów. Na każdy kwartał ustaw sobie 1–2 konkretne rezultaty, które da się pokazać komuś z zewnątrz, np.:

• Q1: repozytorium z prostą aplikacją i pipeline’em CI/CD (np. GitHub Actions) budującym obraz Dockera i wrzucającym go do rejestru,
• Q2: mała infrastruktura w chmurze zdefiniowana w Terraformie (VPC, instancja, baza, S3/Blob Storage),
• Q3: klaster Kubernetes (managed lub lokalny) z wdrożoną aplikacją, monitoringiem (Prometheus/Grafana) i logami,
• Q4: publiczne portfolio na GitHubie + opisany case study na blogu/LinkedInie.

Jeśli na koniec kwartału te mini-projekty „żyją” i coś realnie robią, bardzo łatwo zobaczysz, że robisz postęp – nawet jak chwilami masz wrażenie, że wciąż tylko „gasisz drobne pożary” z nauką narzędzi.

Pierwszy kwartał: zwinne ogarnięcie automatyzacji i praktycznych narzędzi

Cel Q1: od lokalnego skryptu do działającego pipeline’u

Na starcie pierwszego kwartału możesz czuć presję: „Muszę ogarnąć wszystko naraz – Dockera, chmurę, Kubernetes”. Pokusa jest duża, bo kursy są na wyciągnięcie ręki. Lepiej jednak zacząć od krótszej pętli: kod → repozytorium → build → test → artefakt (obraz Dockera) → proste środowisko.

Jeżeli ustawisz sobie na Q1 taką właśnie pętlę, po trzech miesiącach będziesz umieć:

• konteneryzować prostą aplikację,
• zbudować obraz Dockera i wrzucić go do rejestru,
• skonfigurować podstawowy pipeline CI/CD,
• zautomatyzować kilka powtarzalnych kroków skryptami.

Docker na serio, nie tylko „docker run”

Większość osób ma pierwszy kontakt z Dockerem na poziomie „docker run postgres” albo „docker run nginx i coś wyświetla w przeglądarce”. To dobry początek, ale przekwalifikowanie na DevOpsa wymaga wejścia poziom głębiej.

Na Q1 postaw sobie takie mikrocele:

• napisać własny Dockerfile dla prostej aplikacji (np. API w Pythonie, front w React, mały serwis w Go),
• zrozumieć warstwy obrazu (layer cache) i świadomie je układać (najpierw zależności, potem kod),
• korzystać z .dockerignore,
• uruchamiać kilka kontenerów razem – przy pomocy docker-compose lub prostego pliku Compose v2,
• debugować podstawowe problemy: brak zależności, błędne ścieżki, problemy z siecią w kontenerze.

Dobry przykład: bierzesz swoją obecną „skryptową” robotę (np. ETL, mały serwis pomocniczy), pakujesz ją w obraz Dockera, dodajesz healthcheck, lokalnie odpalasz z bazą i jakąś prostą usługą towarzyszącą (np. Redis). Od razu widzisz sens – to nie jest abstrakcyjny „Hello World”, tylko coś z twojej codzienności.

CI/CD – pierwszy działający pipeline

Pipeline CI/CD nie musi być od razu arcydziełem inżynierii. Najważniejsze, żeby się wykonał od początku do końca i robił coś pożytecznego. Narzędzie wybierz takie, które najczęściej widzisz w ogłoszeniach, które cię interesują (GitHub Actions, GitLab CI, Azure DevOps, Jenkins).

Na początek pipeline powinien:

1. uruchamiać się na każde push lub pull request na główną gałąź,
2. budować aplikację (np. npm test, mvn test, pytest),
3. budować obraz Dockera z twoim Dockerfile,
4. wypychać ten obraz do rejestru (Docker Hub, GitHub Container Registry, GitLab Registry),
5. opcjonalnie: automatycznie odpalać deployment na prostym środowisku (np. testowy serwer VM).

Jeśli nigdy tego nie robiłeś, początek może wyglądać na „pisałem 20 linijek YAML i nie wiem, czemu to nie działa”. To normalne. Dobrym podejściem jest zaczęcie od gotowego przykładu z dokumentacji, a dopiero potem modyfikowanie go pod siebie – zamiast pisać od zera i frustrować się przez tydzień.

Automatyzacja zadań – Bash, Makefile i małe narzędzia

DevOps bez automatyzacji kończy jako „klikacz w panelu”, tylko w innej zakładce. Pierwszy kwartał to dobry moment, żeby każdy powtarzalny krok, który wykonujesz ręcznie, spróbować zamknąć w:

• prostym skrypcie Bash (lub PowerShell, jeśli siedzisz głównie w Windowsie),
• Makefile – świetny do standaryzowania komend typu make test, make build, make deploy,
• małym narzędziu w twoim języku (np. Python CLI).

Przykład: zamiast za każdym razem ręcznie pisać długą komendę Dockera, robisz:

make run
make test
make build-image

Nagle wszystko staje się powtarzalne, a ty przestajesz tracić czas na szukanie w historii terminala „tej jednej komendy sprzed tygodnia”.

Środowisko lokalne jak mini-platforma

Na koniec Q1 dobrze jest, jeśli twój laptop czy domowy komputer zaczyna przypominać małą platformę, a nie tylko „maszynę do VS Code’a”. To oznacza, że:

• masz zainstalowane i skonfigurowane podstawowe narzędzia: Git, Docker, narzędzie CI (jeśli to runner lokalny), klient CLI wybranej chmury,
• potrafisz w kilka minut uruchomić lokalnie swój projekt z zależnościami (np. docker-compose up zamiast godzinnego klejenia usług),
• masz uporządkowaną strukturę katalogów z projektami (np. oddzielnie „sandbox”, oddzielnie „portfolio”).

To małe rzeczy, ale robią ogromną różnicę psychologiczną. Zamiast „uczestnika kursu”, zaczynasz czuć się jak ktoś, kto ma własne środowisko, projekty i rytm pracy.

Jak rozłożyć Q1 tygodniami (propozycja)

Przykładowy plan na 12 tygodni Q1

Układ tygodni nie musi być idealny – życie i tak zrobi swoje. Lepiej mieć ramę, którą w razie czego skorygujesz, niż zaczynać każdy weekend od pytania „to co ja mam dziś robić?”.

Tygodnie 1–2: uporządkowanie warsztatu i pierwsze kontenery

Na początek zadbaj o fundamenty, żeby później nie blokować się na drobiazgach typu brakujący git czy zły klucz SSH.

• Skonfiguruj środowisko:
  • aktualny system (Linux/macOS/Windows z WSL2),
  • Git + wygodny GUI lub plugin w edytorze,
  • Docker Desktop albo Docker na Linuksie,
  • konto na GitHubie/GitLabie + skonfigurowane klucze SSH.
• Przećwicz podstawy Gita „na sucho”:
  • tworzenie repo,
  • gałąź, commit, merge, pull request / merge request,
  • rozwiązywanie prostego konfliktu.
• Weź prostą aplikację (może być nawet „TODO list” z tutoriala) i:
  • napisz pierwszy Dockerfile,
  • zbuduj obraz i uruchom go lokalnie,
  • udokumentuj to w README.md – po kilku tygodniach sam sobie podziękujesz.

Na tym etapie wiele osób ma z tyłu głowy myśl: „Przecież to banał, wszyscy to umieją”. W praktyce na rekrutacjach często wychodzi, że kandydaci nie są w stanie szybko ogarnąć konfliktu w Gicie albo stworzyć sensownego Dockerfile od zera. To dobry moment, żeby wyrobić sobie spokojny, powtarzalny rytuał pracy z repozytorium.

Tygodnie 3–4: docker-compose i mini-środowisko lokalne

Kiedy pojedynczy kontener przestaje robić wrażenie, czas podłączyć drugą usługę. Dopiero wtedy zaczyna być podobnie do tego, co później zobaczysz w środowiskach firmowych.

• Dodaj bazę danych w kontenerze (PostgreSQL, MySQL, MongoDB – cokolwiek pasuje do twojej aplikacji).
• Stwórz plik docker-compose.yml, który:
  • uruchamia aplikację i bazę,
  • ustawia sieć między nimi,
  • konfiguruje zmienne środowiskowe (hasła, adresy).
• Dołóż prostą usługę pomocniczą, np.:
  • Redis do cache,
  • MailHog do testowania e-maili,
  • narzędzie typu pgAdmin.
• Spisz kilka najczęściej używanych komend (w Makefile albo w README): make up, make down, make logs.

To nie musi być produkcyjne arcydzieło. Chodzi o to, żeby jednym poleceniem stawiać lokalne „mini-środowisko” z więcej niż jedną usługą. Jeśli coś nie działa – nie omijaj tego. Debugowanie teraz, w bezpiecznych warunkach, oszczędzi stresu przy pierwszym prawdziwym incydencie.

Tygodnie 5–6: pierwszy pipeline CI

Masz już kod w repo i działające kontenery lokalnie. Teraz pora, żeby to wszystko robiło się samo, gdy wysyłasz zmianę na serwer Gita.

• Wybierz narzędzie CI:
  • GitHub Actions – jeśli korzystasz z GitHuba,
  • GitLab CI – jeśli siedzisz na GitLabie,
  • inne (Jenkins, Azure DevOps), jeśli widzisz je często w ofertach, które przeglądasz.
• Skonfiguruj prosty pipeline:
  • uruchamiany na push do main/master i na pull request,
  • instalujący zależności i odpalający testy jednostkowe,
  • z widocznym statusem (zielony/czerwony) przy każdym commicie.
• Dodaj raport z testów / artefakt:
  • proste wyniki testów w logach,
  • opcjonalnie zapisanie zbudowanej aplikacji (np. paczki .jar czy artifactu frontendu).

Na tym etapie nie przejmuj się jeszcze deploymentem. Skup się na tym, żeby testy faktycznie się odpalały, a pipeline był przewidywalny. Kiedy pierwszy raz zobaczysz „na czerwono” test, który lokalnie przypadkiem pominąłeś, poczujesz, dlaczego CI jest tak istotne.

Tygodnie 7–8: kontenery w pipeline + rejestr obrazów

Kolejny krok to połączenie CI z Dockerem. Chcesz, żeby każdy commit budował obraz, który potem można łatwo wdrożyć.

• Załóż konto w rejestrze obrazów:
  • Docker Hub,
  • GitHub Container Registry,
  • GitLab Container Registry.
• Skonfiguruj w pipeline:
  • budowanie obrazu Dockera z twojego Dockerfile,
  • tagowanie obrazu (np. app:commit-sha, app:latest),
  • wypychanie go do rejestru z użyciem sekretów (token/hasło w ustawieniach CI).
• Sprawdź, czy możesz:
  • pobrać zbudowany obraz lokalnie (docker pull),
  • uruchomić go w swoim docker-compose zamiast budować loklanie.

To moment, w którym twoje repo zaczyna być „żywe”: commit → pipeline → świeży obraz w rejestrze. Nawet jeśli jeszcze nigdzie nie deployujesz, taki sam schemat zobaczysz później w dużych projektach.

Tygodnie 9–10: prosty deployment na serwer testowy

Gdy masz już „fabrykę” obrazów, grzechem byłoby nie spróbować wrzucić czegoś na działający serwer. Nie potrzebujesz od razu chmury za tysiące – wystarczy tania maszyna wirtualna lub nawet stary komputer w domu.

• Przygotuj środowisko docelowe:
  • małą VM (AWS Free Tier, Azure, GCP, OVH, Hetzner – cokolwiek ogarniasz),
  • zainstaluj na niej Dockera i docker-compose,
  • skonfiguruj dostęp SSH (klucze, nie hasło).
• Dodaj etap deploy w pipeline:
  • po zbudowaniu i wypchnięciu obrazu,
  • pipeline łączy się na serwer (np. przez SSH),
  • ściąga aktualny obraz i robi docker-compose pull + docker-compose up -d.
• Na koniec sprawdź, czy aplikacja działa z publicznego adresu IP lub domeny (może być tymczasowa).

Może się wydawać, że to „za wcześnie” na deployment, przecież nie masz jeszcze chmury, Kubernetesa, zaawansowanego monitoringu. Lepiej jednak jak najszybciej zobaczyć pełen przepływ – od commita po działającą aplikację, nawet jeśli środowisko jest bardzo proste.

Tygodnie 11–12: porządki, dokumentacja i automatyzacja drobiazgów

Końcówka kwartału to dobry moment, żeby zwolnić, odsapnąć i jednocześnie domknąć kilka tematów, które w trakcie mogły zostać „na później”.

• Przejrzyj repozytorium:
  • usuń niepotrzebne pliki,
  • dodaj sensowne .gitignore,
  • zadbaj o jasne README (jak uruchomić projekt lokalnie i na serwerze).
• Stwórz lub dopracuj Makefile:
  • make test,
  • make build,
  • make push-image,
  • make deploy – jeśli deployment jest skryptem.
• Spisz krótką retrospekcję:
  • co już działa od początku do końca,
  • co cię najbardziej spowalniało,
  • co chcesz poprawić w następnym kwartale (np. lepsze testy, logowanie, struktura repo).

To też dobry czas, żeby pochwalić się pierwszym efektem: link do repo + króciutki opis pipeline’u i deploymentu na LinkedInie czy wśród znajomych z branży. Zaskakująco często taka „mała aktualizacja” prowadzi potem do ciekawych rozmów, ofert staży czy wspólnych projektów.

Jak łączyć naukę z etatem, żeby nie spłonąć po dwóch miesiącach

Największym wrogiem rocznego planu jest nie brak talentu, tylko wypalenie po zbyt mocnym starcie. Łatwo rzucić się na naukę po 20 godzin tygodniowo, a potem po trzech tygodniach odpuścić wszystko.

Praktyczniej podejść do Q1 jak do treningu: lepiej robić mniejsze, regularne „serie”, niż jedną długą sesję raz na dwa tygodnie.

• Ustal stałe „okna” nauki – np. wtorek i czwartek 19–21, sobota 10–12. Traktuj je jak spotkanie z klientem, którego nie odwołujesz bez ważnego powodu.
• Oddziel naukę „konsumpcyjną” od praktycznej:
  • w tygodniu – krótkie sesje praktyczne (kod, pipeline, docker-compose),
  • w drodze do pracy – film/artykuł, ale zawsze z notatką, co z tego przetestujesz później.
• Planuj tydzień zadaniami, nie „czasem przed ekranem”:
  • np. „do soboty: pipeline z testami i buildem obrazu przechodzi na zielono”, zamiast „3h nauki CI/CD”.
• Wlicz margines na życie – zostaw jeden „wolny” wieczór tygodniowo, który w razie nagłej sytuacji może przejąć któraś z sesji nauki.

Jeśli tydzień totalnie ci się posypie – nie nadrabiaj wszystkiego jednym dwunastogodzinnym maratonem. Wróć do krótkich, regularnych sesji, a przy planowaniu kolejnego tygodnia delikatnie obetnij liczbę zadań. Stałość przez rok jest ważniejsza niż idealny Q1.

Typowe przeszkody w Q1 i jak przez nie przejść

Q1 ma specyficzny zestaw „pułapek”, które pojawiają się niemal u każdego. Lepiej założyć, że one przyjdą, niż potem mieć do siebie pretensje.

„Gubię się w narzędziach i skrótach”

CI, CD, YAML, registry, runner, jobs, stages – po kilku dniach głowa może parować. Zamiast próbować ogarnąć wszystko naraz, wydziel mini-słownik.

• Załóż prosty plik notes.md w repo lub Notion/Obsidian.
• Dodawaj do niego:
  • nazwę pojęcia (np. „runner”),
  • zdanie lub dwa własnymi słowami („maszyna, która realnie wykonuje kroki z pipeline’u”),
  • link do dokumentacji lub tutoriala, który był pomocny.
• Przed startem każdej sesji nauki przejrzyj szybko ostatnie wpisy. To buduje pamięć lepiej niż scrollowanie Stack Overflow za każdym razem od zera.

„Czuję, że tylko przepisuję tutoriale”

To normalne na początku, ale dobrze jak najszybciej wprowadzić małe modyfikacje, które zmuszą cię do myślenia.

• Zrób tutorial dokładnie jak w instrukcji – ale tylko raz.
• Potem:
  • zmień nazwę projektu,
  • zmień wersję języka/obrazu bazowego,
  • dodaj prosty krok do pipeline’u (np. dodatkowy test lub lint).
• Jeśli coś się wywali – rozwiąż problem, zanim zajrzysz w gotowe rozwiązanie.

Taka „mała modyfikacja” sprawia, że naprawdę uczysz się narzędzia, a nie tylko odtwarzasz komendy.

„Boje się, że robię coś źle, nie tak jak w korporacji”

To obawa wielu osób z mniejszym doświadczeniem w dużych zespołach. Jest spora różnica między jednoosobowym projektem a platformą dla setek devów, ale fundamenty są zaskakująco podobne.

Zamiast próbować przewidzieć każdy „enterprise’owy” scenariusz, skup się na uniwersalnych praktykach:

• pipeline zawsze:
  • buduje projekt od zera,
  • odpala testy,
  • tworzy powtarzalny artefakt (obraz/plik instalacyjny).
• konfiguracja nie jest zaszyta w kodzie – korzystasz z:
  • zmiennych środowiskowych,
  • plików .env (ale nie commitujesz haseł),
  • sekretów w systemie CI.

Najczęściej zadawane pytania (FAQ)

Czy da się realnie przekwalifikować na DevOpsa w rok?

Jest to możliwe, jeśli startujesz z jednego z typowych punktów: admin, QA automatyzujący, developer albo techniczny support. Masz już wtedy część umiejętności: skrypty, kontakt z Linuxem, CI/CD, logami czy sieciami. Ten rok nie jest więc nauką „od zera”, tylko uporządkowaniem i pogłębieniem tego, co już znasz.

Kluczowe jest dobre rozpoznanie własnych braków i konsekwentna praca nad nimi. Zamiast próbować w rok zostać „full stackiem od wszystkiego”, lepiej zbudować solidne minimum: Linux, automatyzacja, podstawy chmury, CI/CD i umiejętność dogadania się z zespołem.

Jakie minimum umiejętności trzeba mieć, żeby zacząć drogę do DevOpsa?

Na start przydaje się kilka bazowych rzeczy, często już je masz, tylko nie nazywasz ich „devopsowo”:

• proste skrypty w Bashu, Pythonie albo PowerShellu,
• choćby okazjonalna praca w terminalu na Linuxie,
• kontakt z CI (Jenkins, GitLab CI, GitHub Actions, Azure DevOps) – nawet jako użytkownik,
• podstawowe pojęcia sieciowe: IP, DNS, port, HTTP,
• praktyczne używanie Gita w zespole (branch, commit, merge, pull request).

Jeśli większość z tego „kojarzysz” lub już robisz, jesteś bliżej realnych oczekiwań wobec DevOps juniora, niż się wydaje. Dalej chodzi o ułożenie tego w spójny zestaw i dołożenie brakujących klocków.

Jak zrobić audyt swoich umiejętności przed przekwalifikowaniem na DevOpsa?

Najprościej przygotować krótką checklistę i przy każdym punkcie zaznaczyć uczciwie: „umiem”, „kojarzę”, „nie mam pojęcia”. Możesz zacząć od obszarów: Linux (komendy, logi, procesy), sieci (IP, DNS, HTTP), Git, skrypty, CI/CD, chmura, kontenery.

Jeśli widzisz dużo „kojarzę”, to dobry znak – wystarczy tam pogłębić wiedzę w pierwszych miesiącach. Gdy w jakimś bloku masz same „nie mam pojęcia” (np. chmura + kontenery), sensowne może być lekkie wydłużenie planu w głąb, ale nadal z celem pierwszej roli DevOps/Platform po około roku.

Czy muszę znać Kubernetes, żeby zostać juniorem DevOps?

Na poziomie junior/regular Kubernetes zwykle nie jest obowiązkowy na „senior level”. Często wystarczy, że rozumiesz podstawy kontenerów (Docker), potrafisz zbudować i uruchomić własny obraz oraz ogarniasz CI/CD i podstawy chmury. Kubernetes pojawia się później jako naturalne rozwinięcie tych fundamentów.

Jeśli Kubernetes cię stresuje, potraktuj go jako kolejny krok po opanowaniu Linuxa, automatyzacji i kontenerów. Bez tych fundamentów nawet intensywny kurs K8s niewiele da, bo zabraknie kontekstu.

Czym różni się DevOps od SRE i Platform Engineera?

DevOps w ogłoszeniach to zazwyczaj ktoś, kto „ogarnia infrastrukturę pod development”: CI/CD, automatyzację, provisioning środowisk, podstawy chmury i kontenery. Celem jest szybsze, powtarzalne dostarczanie aplikacji.

SRE mocniej skupia się na niezawodności: monitoringu, alertach, SLO/SLA, analizie incydentów i automatyzacji reakcji. Platform Engineer projektuje i utrzymuje platformę (często opartą o chmurę i Kubernetes), na której pracują zespoły deweloperskie – tworzy szablony pipeline’ów, standardowe środowiska, narzędzia podnoszące komfort pracy developerów.

Czy bez doświadczenia jako admin mam szansę zostać DevOpsem?

Tak, typowa ścieżka wiedzie też z QA automatyzującego, developmentu czy technicznego supportu. QA i developerzy wnoszą silne programowanie i obycie z CI/CD, support – dobre zrozumienie produkcji, użytkowników i logów. Braki w administrowaniu systemami i sieciach da się uzupełnić w trakcie rocznego planu.

Ważne, żebyś jasno nazwał to, w czym jesteś już mocny (np. pisanie testów automatycznych, debugowanie problemów klientów, praca z Git-em) i oparł na tym plan. Łatwiej dobudować sieci i Linuxa do programisty, niż próbować jednocześnie nauczyć się wszystkiego od zera.

Na czym polega różnica między „klepaniem skryptów” a pracą DevOpsa?

„Klepanie skryptów” to zwykle reagowanie na pojedynczy problem: jest awaria, piszesz skrypt do restartu usługi i tyle. DevOps myśli bardziej procesem i platformą: projektuje rozwiązanie, które samo wykryje problem, spróbuje naprawy, wyśle alert, zapisze kontekst w logach i da się łatwo powtórzyć w innych projektach.

Chodzi więc nie tylko o umiejętność pisania skryptu, ale o projektowanie powtarzalnych, bezpiecznych mechanizmów, które działają w całym zespole czy firmie. To przesunięcie z „gaszenia pożarów” na budowanie systemu, który pożary ogranicza i pomaga szybciej je ogarniać.

Najważniejsze wnioski

• Start z DevOps nie oznacza zaczynania od zera – admin, QA, developer czy support mają już realne atuty (Linux, skrypty, CI, logi, kontakt z produkcją), które można świadomie rozwinąć zamiast wszystkiego uczyć się od początku.
• Na poziomie junior/regular nie jest potrzebna encyklopedyczna znajomość całego stosu (Docker, Kubernetes, Terraform itd.); liczy się stabilne ogarnięcie kilku fundamentów: Linux, automatyzacja, CI/CD, podstawy chmury i praca zespołowa.
• Twoje obecne umiejętności są często bliżej rynku niż się wydaje – jeśli potrafisz skryptować, używać Gita, rozumiesz podstawowe pojęcia sieciowe i choć raz pracowałeś z CI lub chmurą, to masz sensowną bazę na DevOps juniora.
• Kluczowa zmiana to przejście od „gaszenia pożarów skryptem” do projektowania procesów i platform: automatyczne wykrywanie problemu, próba naprawy, alert, sensowne logowanie – nie tylko pojedynczy restart usługi.
• Mini audyt umiejętności (Linux, sieci, Git, skrypty, CI/CD, chmura, kontenery) pozwala ustalić, co już masz „ogarnięte”, co tylko „kojarzysz”, a gdzie jest czarna dziura – dzięki temu roczny plan nauki nie przepala czasu.
• Odpowiedzi „kojarzę” lub „nie mam pojęcia” nie przekreślają szans na DevOps w rok – oznaczają jedynie, że w pierwszych miesiącach trzeba mocniej przycisnąć fundamenty, a w razie większych braków pogodzić się z tym, że w niektórych tematach zejdziesz trochę płycej.