Administrator zamyka kolejny incydent o drugiej w nocy, a rano widzi ogłoszenie, w którym obok Linuxa pojawiają się Terraform, pipeline CI/CD i Kubernetes. Kuszące jest wpisanie w CV słowa „DevOps” bez zmiany sposobu pracy. Najczęstszy błąd na starcie to albo ukrywanie doświadczenia administracyjnego, albo kupowanie kursów z całej mapy narzędzi, zanim wiadomo, jakie zadania firma naprawdę chce oddać nowej osobie.
Z SysAdmina do DevOpsa: zmiana roli, nie porzucenie dotychczasowych kompetencji
DevOps nie jest jedną technologią ani stanowiskiem o stałym zakresie. W jednej firmie oznacza osobę, która utrzymuje pipeline i chmurę dla kilku zespołów produktowych. W innej to administrator, który dodatkowo automatyzuje wdrożenia i pilnuje środowiska. Wspólnym mianownikiem jest skrócenie drogi od zmiany w kodzie do działającego środowiska oraz odpowiedzialność za to, co dzieje się po wdrożeniu. [1]
Doświadczenie SysAdmina nie jest balastem, który trzeba „przekreślić” na rzecz modnych nazw. Linux, sieci, uprawnienia, backupy, monitoring, bezpieczeństwo i diagnozowanie awarii to dokładnie te obszary, na których wywracają się niedopracowane wdrożenia. Różnica polega na tym, że zamiast powtarzać te same czynności ręcznie, opisuje się je w kodzie, wersjonuje i uruchamia w powtarzalny sposób.
Na wejściu zwykle jest już myślenie operacyjne: co się stanie, gdy dysk się zapełni, usługa nie wstanie po restarcie albo ktoś straci dostęp do serwera. Tego nie zastąpi sam Dockerfile. Brakuje natomiast praktyki bliższej zespołowi developerskiemu: pracy z repozytorium, recenzji zmian, testów, pipeline’ów, chmury i podejścia Infrastructure as Code. Przejście z sysadmina do devops jest najkrótsze wtedy, gdy obecna wiedza staje się podstawą automatyzacji, a nie gdy próbuje się ją schować za listą narzędzi.
Zanim padnie decyzja o półrocznej nauce „wszystkiego”, warto rozróżnić trzy poziomy oczekiwań. Junior często dostaje utrzymanie istniejących pipeline’ów, poprawki w Ansible i proste zasoby w chmurze pod okiem bardziej doświadczonej osoby. Regular buduje ścieżki wdrożeń, dba o sekrety, obserwowalność i koszty. Senior projektuje platformę i standardy dla wielu zespołów. Aplikowanie od razu na poziom seniora tylko dlatego, że ktoś ma osiem lat administracji, zwykle kończy się rozmową, na której pytania dotyczą Git, stanu Terraforma i rollbacku, a nie uprawnień w sudo.
Oceń punkt startowy i wybierz realny kierunek rozwoju
Zidentyfikuj kompetencje, które można przenieść
Codzienne zadania administratora da się przełożyć na język bliższy DevOps, bez zmieniania faktów. Ręczne wdrożenie paczki na trzech serwerach to kandydat na playbook. Skrypt Bash zakładający konta i grupy to zalążek automatycznego provisioningu. Procedura odtwarzania backupu to materiał na test odzyskiwania, a nie tylko dokument w wiki. Monitoring, który dziś pokazuje zużycie CPU, jutro może alarmować o nieudanym wdrożeniu albo wzroście błędów 5xx. [3]
Konkretny punkt startu bywa skromny. Skrypt, który tworzy użytkownika, ustawia klucz SSH i dopisuje go do grupy, można przenieść do Ansible: te same kroki stają się zadaniami idempotentnymi, a parametry — zmiennymi. Następny krok to Python, gdy trzeba pobrać dane z API, wygenerować konfigurację albo sprawdzić stan wielu hostów. Nie chodzi o przepisanie całego działu IT w weekend, tylko o jedną powtarzalną czynność, którą da się uruchomić drugi raz z tym samym skutkiem.
Środowisko on-premise nie zamyka drogi do chmury. Kto rozumie routing, DNS, firewall, dyski i cykle życia maszyn, szybciej wyłapuje, że „usługa w chmurze” to nadal sieć, uprawnienia i trwałość danych — tylko z innym panelem i innym modelem rozliczania. Osoba, która nigdy nie widziała awarii dysku ani błędnej reguły firewalla, częściej traktuje chmurę jak zestaw ikon. Administrator ma tu przewagę, o ile nie zatrzyma się na ręcznej konsoli.
Nie ucz się wszystkiego naraz
Ogłoszenia mieszają nazwy ról. Junior DevOps bywa stanowiskiem dla osoby, która umie Dockera, podstawy CI i trochę chmury. Cloud Engineer albo Platform Engineer częściej buduje wspólną platformę dla zespołów. SRE kładzie nacisk na niezawodność, błędy budżetowe, incydenty i pomiary. Administrator z automatyzacją może zostać w firmie, w której nie ma jeszcze oddzielnego zespołu DevOps, i właśnie tam zdobyć pierwsze pipeline’y. DevOps w zespole produktowym siedzi bliżej developerów i odpowiada za ścieżkę konkretnej aplikacji, a nie za całą serwerownię.
Ścieżka powinna wynikać z tego, co już jest w rękach, a nie z najgłośniejszego narzędzia roku. Administrator Linux najpierw wzmacnia skrypty, Git, kontenery i konfigurację jako kod. Osoba z Windows i Active Directory sensowniej zaczyna od PowerShell, Azure i pipeline’ów, zamiast udawać, że nagle „przesiada się na czysty Linux enterprise”. Obie drogi prowadzą do podobnych kompetencji DevOps Engineer, ale inna jest kolejność i inny pierwszy projekt do portfolio. [4]
Praktyczny filtr: zebrać 15–20 aktualnych ofert z miast lub trybu pracy, który naprawdę wchodzi w grę, i wypisać wymagania powtarzające się co najmniej pięć razy. Reszta — egzotyczne narzędzia wymienione raz — schodzi na później. Z takiej listy powstaje mapa braków: na przykład Git i Docker są w prawie każdym ogłoszeniu, Kubernetes w połowie, a konkretny dostawca chmury zależy od rynku lokalnego. Plan nauki oparty na tej mapie jest odporniejszy niż lista z przypadkowego syllabusu. [5]
Cel tego etapu nie brzmi „znam cały rynek”. Cel brzmi: profil, który da się obronić na poziomie juniorskim albo regularnym w wybranym typie ofert. Jeśli większość ogłoszeń w okolicy wymaga Azure i YAML-owych pipeline’ów, a plan nauki przewiduje wyłącznie warsztaty z innej chmury, rozmowy będą pełne tłumaczeń zamiast przykładów.
Plan nauki krok po kroku: od automatyzacji do środowiska produkcyjnego
Etap 1 — skrypty, Git i podstawy pracy z kodem
Bash pozostaje narzędziem pierwszego kontaktu: pętle po hostach, sprawdzanie kodów wyjścia, proste wdrożenia plików konfiguracyjnych. Python wchodzi wtedy, gdy skrypt zaczyna się rozsypywać — przy wywołaniach API, parsowaniu JSON, obsłudze wyjątków albo budowie małego narzędzia operacyjnego. Nie trzeba od razu pisać frameworków. Wystarczy skrypt, który przyjmuje parametry, loguje błąd i nie kończy się cicho, gdy coś poszło nie tak.
Git jest tu językiem współpracy, nie dodatkiem. Branche, commity z czytelnym opisem, pull request i rozwiązanie konfliktu pokazują, że zmiana da się przejrzeć, a nie tylko „wgrać na serwer”. Plik README i sensowny .gitignore to minimum: repozytorium bez instrukcji uruchomienia wygląda jak zrzut katalogu domowego. Sekretów — haseł, kluczy, tokenów — nie commituje się „na chwilę”. Jeśli coś trafiło do historii, usunięcie pliku w kolejnym commicie nie wystarcza; trzeba założyć, że dane wyciekły, i rotować je.
Jakość na tym etapie oznacza czytelność, parametryzację i obsługę błędów. Skrypt z zahardkodowanym adresem IP i hasłem w środku nie staje się narzędziem DevOps tylko dlatego, że leży w Git. Lepszy sygnał na rozmowie: ten sam skrypt działa na dwóch środowiskach dzięki zmiennym, a nieudane polecenie przerywa wykonanie i zostawia ślad w logu.
Etap 2 — kontenery i powtarzalne środowiska
Docker rozwiązuje problem „u mnie działa”, ale tylko wtedy, gdy obraz jest opisany, a nie składany ręcznie na działającym kontenerze. Obraz, Dockerfile, wolumen na dane, sieć między usługami, zmienne środowiskowe i Docker Compose wystarczają, żeby postawić prostą aplikację z bazą. Na tym etapie nie trzeba klastra. Trzeba umieć powiedzieć, co jest w obrazie, co jest konfiguracją, a co danymi, których nie wolno zapisać w warstwie kontenera.
Dobry pierwszy projekt to konteneryzacja prostej aplikacji webowej razem z bazą i reverse proxy. Jedna komenda podnosi całość, druga ją gasi bez ręcznego sprzątania procesów. W README powinny być wymagania, porty i sposób sprawdzenia, że usługa żyje. Taki zestaw jest bliższy pracy niż kolekcja samouczków, w których każdy przykład żyje w osobnym katalogu i nie da się go połączyć.
Pułapki powtarzają się niezależnie od języka aplikacji. Hasła w obrazie zostają w warstwach i w historii budowania. Kontener uruchomiony jako root ułatwia życie na laboratorium i komplikuje je przy pierwszym audycie. Obraz ważący ponad gigabajt wydłuża pipeline i częściej kryje niepotrzebne narzędzia. Brak healthchecka sprawia, że proxy kieruje ruch do procesu, który jeszcze nie nasłuchuje. Każdą z tych rzeczy da się pokazać w repozytorium jako świadomą poprawkę, nie jako teorię.
Etap 3 — konfiguracja i infrastruktura jako kod
Ansible dobrze leży osobie, która dotychczas pisała checklisty wdrożeniowe. Różnica wobec instrukcji krok po kroku to idempotencja: drugie uruchomienie playbooka nie powinno dublować użytkowników, dopisywać tej samej linii w nieskończoność ani wywracać usługi, która już jest w oczekiwanym stanie. Role, zmienne i inventory porządkują to, co w skryptach Bash szybko staje się jednym plikiem na kilkaset linii.
Terraform albo inne narzędzie IaC służy do tworzenia zasobów, nie do konfigurowania każdego pliku w środku maszyny. Stan infrastruktury, moduły, zmienne i zdalny backend stanu to pojęcia, bez których laboratorium na własnym laptopie wygląda schludnie, a praca zespołowa się sypie. Dwie osoby uruchamiające ten sam kod bez wspólnego stanu łatwo utworzą zdublowane zasoby albo nadpiszą sobie nawzajem zmiany. Na start wystarczy jeden moduł, kilka zmiennych i jawny podział na środowisko testowe.
Kolejność ma znaczenie. Najpierw automatyzuje się zadanie znane z pracy administratora: konto, pakiet, konfiguracja usługi, reguła zapory, zadanie cron. Dopiero później zwiększa się skalę — więcej hostów, osobne środowiska, zasoby chmurowe. Osoba, która zaczyna od „całej platformy firmowej” w Terraformie, zwykle kończy z kodem, którego nie umie bezpiecznie zniszczyć ani odtworzyć.
Etap 4 — CI/CD, Kubernetes i obserwowalność
Pipeline CI/CD powinien mieć czytelną kolejność: budowanie, test albo walidacja, skanowanie zależności lub obrazu, publikacja artefaktu, wdrożenie i możliwość wycofania zmiany. Na poziomie nauki nie trzeba piętnastu etapów. Wystarczy, że merge do głównej gałęzi nie jest równoznaczny z ręcznym wgraniem plików. Rollback nie musi być rozbudowanym systemem — czasem to poprzedni tag obrazu i jawna procedura powrotu, opisana tak, żeby dało się ją wykonać pod presją.
Kubernetes ma sens po swobodnym Dockerze, nie zamiast niego. Deployment, Service, Ingress, ConfigMap, Secret, Namespace i podstawy Helm pokrywają większość pytań na pierwszej rozmowie. Warto umieć wyjaśnić, czemu sekret nie powinien leżeć w zwykłym manifeście w publicznym repozytorium i czym różni się restart poda od zmiany konfiguracji, która wymaga nowego rolloutu. Klaster lokalny albo środowisko zarządzane w najtańszym wariancie laboratoryjnym wystarcza, jeśli manifesty są własne, a nie skopiowane bez zrozumienia.
Obserwowalność zamyka pętlę. Metryki aplikacyjne i infrastrukturalne, logi z wdrożenia oraz alert, który da się powiązać z konkretną zmianą, są ważniejsze niż ściana wykresów. Prometheus i Grafana w podstawowym zestawie uczą zadawania pytań: czy usługa odpowiada, czy błędy wzrosły po wdrożeniu, czy kończy się miejsce. Dashboard bez progu i bez właściciela alertu jest dekoracją. Administrator, który wcześniej dyżurował przy incydentach, ma tu naturalną przewagę — o ile połączy sygnał z pipeline’em, a nie tylko z pojedynczym serwerem.
Dobrym uzupełnieniem tego tematu jest także poradnik: 10 cennych certyfikatów dla administratorów Linux.
Technologii nie trzeba opanowywać encyklopedycznie. Na rozmowie i w pracy liczy się umieć zbudować, wdrożyć, obserwować i poprawić działający system. Luka w jednym narzędziu boli mniej niż brak odpowiedzi na pytanie, co się stanie, gdy wdrożenie się nie powiedzie.
Zbuduj portfolio DevOps, które pokazuje sposób pracy
Jeden projekt end-to-end zamiast wielu niedokończonych laboratoriów
Rekruter szybciej oceni jeden spójny projekt niż osiem repozytoriów z przerwanych tutoriali. Sensowny rdzeń to prosta aplikacja webowa uruchamiana lokalnie w kontenerach, budowana przez pipeline, wdrażana do klastra Kubernetes i podpięta pod podstawowy monitoring. Nie musi mieć własnego modelu biznesowego. Musi mieć przepływ: zmiana w kodzie, build, publikacja obrazu, wdrożenie, sprawdzenie zdrowia, możliwość cofnięcia. [2]
Architektura może być skromna, byle jawna. Osobne repozytorium aplikacji i osobne na infrastrukturę albo wyraźnie wydzielone katalogi w jednym repozytorium. Pliki konfiguracyjne nie mieszają się z kodem aplikacji bez komentarza. Dokumentacja uruchomienia zakłada, że czyta ją ktoś inny: wymagane narzędzia, kolejność komend, oczekiwany adres, sposób sprzątania środowiska. Schemat przepływu — nawet prosty opis kroków — pokazuje, że autor rozumie granice między buildem a runtime.
Świadome kompromisy są mocniejszą opowieścią niż udawana skala. Środowisko lokalne zamiast płatnej chmury jest w porządku, jeśli w README jest napisane, co zostałoby inne na prawdziwym koncie: zdalny stan, sekrety w magazynie, ograniczenia sieciowe. Uproszczona baza i symulowane sekrety też są w porządku, pod warunkiem że w repozytorium nie ma prawdziwych haseł, tokenów ani danych osobowych. Kompromis bez opisu wygląda jak brak. Kompromis opisany wygląda jak decyzja.
Co powinno znaleźć się w repozytorium GitHub
README niesie więcej niż lista technologii w CV. Cel projektu, krótka architektura, wymagania, komendy uruchomienia, przepływ wdrożenia i narzędzia — to minimum, po którym da się ocenić, czy autor panuje nad całością. Długi wstęp marketingowy bez komend zwykle oznacza, że projekt nie wstaje u osoby z zewnątrz.
W środku powinny być własne pliki, nie tylko zrzuty z generatora: Dockerfile, docker-compose.yml, playbook Ansible albo równoważna automatyzacja konfiguracji, fragment Terraform jeśli jest chmura lub jej lokalny odpowiednik, manifesty Kubernetes i definicja pipeline. Każdy plik, którego nie da się wyjaśnić zdaniem „to robi X, bo Y”, lepiej uprościć. Na rozmowie i tak padnie pytanie o konkretną linię.
Osobna wartość to krótki opis problemów rozwiązanych po drodze. Poprawa uprawnień kontenera, błędna sieć między usługami, healthcheck, który kłamał, albo dodany rollback mówią więcej niż kolejna ikona w nagłówku profilu. Trzy takie notatki w README albo w historii commitów pokazują sposób myślenia operacyjnego — a to właśnie przenosi się z roli administratora.
Zanim link trafi do CV, projekt powinien spełniać prosty próg:
- kod i konfiguracja są wersjonowane w Git, a historia commitów da się przeczytać,
- wdrożenie nie wymaga ręcznej konfiguracji krok po kroku poza udokumentowanymi wyjątkami,
- pipeline wykonuje przynajmniej build oraz test lub walidację konfiguracji,
- dokumentacja pozwala innej osobie uruchomić projekt,
- w repozytorium nie ma prawdziwych sekretów ani danych z pracy etatowej.
Przejście nie kończy się na ostatnim commicie w portfolio. Oferta, na którą warto odpisać, to taka, w której większość wymagań da się powiązać z czymś, co już działa w repozytorium albo z incydentem, który naprawdę się diagnozowało. W CV nie trzeba listy dwudziestu narzędzi. Wystarczy pokazać, które ręczne zadanie z dotychczasowej pracy zostało zastąpione wersjonowanym procesem i jaki był tego skutek: krótszy deploy, mniej błędów po restarcie, możliwość cofnięcia zmiany bez zgadywania.
Na rozmowie liczy się opowieść o jednym systemie, nie encyklopedia haseł. Dobrze wypada opis awarii, w której sygnał z monitoringu dało się połączyć z konkretnym wdrożeniem, oraz decyzja, której świadomie nie podjęto — na przykład lokalny klaster zamiast płatnej chmury, z jasnym wyjaśnieniem, co musiałoby się zmienić w firmie. Luki w jednym narzędziu warto nazwać wprost i od razu pokazać, jak szybko da się je domknąć na znanym fundamencie: Linuxie, sieci i dyscyplinie operacyjnej.
Pierwsze miesiące w nowej roli nie polegają na przerabianiu całej platformy. Bezpieczniej zacząć od jednego powtarzalnego bólu zespołu: checklisty wdrożeniowej, która nadal żyje w wiki, alertu bez właściciela albo środowiska, które wstaje tylko u jednej osoby. Mały, domknięty kawałek automatyzacji buduje zaufanie szybciej niż wielki projekt, którego nikt nie umie bezpiecznie wycofać. SysAdmin, który przynosi do DevOps spokój przy incydencie i nawyk zostawiania śladu w logu, nie zaczyna od zera — zmienia tylko sposób, w jaki ta sama odpowiedzialność zostaje zapisana w kodzie.
Zmiana stanowiska rzadko zbiega się z dniem, w którym na umowie pojawia się nowy tytuł. Przez jakiś czas nadal będziesz osobą od serwerów, a jednocześnie tą, która zostawia po sobie proces możliwy do powtórzenia przez kogoś innego. Warto powiedzieć to zespołowi wprost: najpierw stabilność tego, co już działa, potem jedna zmiana, którą da się odwrócić w minutach, nie w dniach.
Jeśli obecna praca na to pozwala, ostatnie tygodnie przed odejściem albo przed formalnym przesunięciem stanowiska dobrze spożytkować na domknięcie procesu, który i tak należy do Ciebie. Nie jako kolejny eksponat, tylko jako nawyk: decyzja zapisana tak, żeby za kwartał nie trzeba było odtwarzać jej z pamięci. Wtedy przejście z administracji do DevOps zostaje ciągłością odpowiedzialności, a nie skokiem w obcy zestaw haseł.
Wewnątrz firmy albo na zewnątrz: dwa różne tempa
W piątek wieczorem pada ten sam serwer, co zwykle. W poniedziałek ktoś pyta, czy da się to „zrobić po devopsowemu”. Różnica nie leży w haśle, tylko w tym, czy masz prawo zmienić sposób pracy, zanim zmienisz stanowisko.
Przesunięcie w obecnej firmie bywa krótszą drogą, jeśli jest zespół, który wdraża zmiany, i ktoś, kto zgodzi się oddać jedną powtarzalną czynność. Nie chodzi o przejęcie całej platformy. Chodzi o umowę na mały zakres: checklista wdrożenia, która dziś żyje w wiki, środowisko, które wstaje tylko u jednej osoby, albo alert bez właściciela. Taki kawałek da się domknąć przy codziennych obowiązkach i pokazać jako proces, nie jako slajd.
Zmiana pracodawcy wymaga innego dowodu. Rekruter nie widzi dyżuru ani znajomości starej infrastruktury. Widzi repozytorium, opis problemu i to, czy potrafisz powiedzieć, co było ręczne, a co zostało zapisane w kodzie. Oferty z piętnastoma obowiązkowymi narzędziami warto czytać jak mapę, nie jak egzamin. Jeśli większość punktów da się powiązać z Linuksem, siecią, wdrożeniem i incydentem, luka w jednym produkcie nie przekreśla zgłoszenia. Jeśli ogłoszenie szuka osoby, która od pierwszego dnia projektuje platformę dla kilku zespołów, to inna rola niż pierwsze przejście z administracji.
W obu wariantach szkodzi ten sam błąd: obiecywanie platformy, zanim istnieje jeden odwracalny proces. Wewnątrz firmy płaci się za to zaufaniem zespołu. Na zewnątrz — rozmową, na której nie ma czego pokazać poza listą kursów.
Jak rozmawiać z programistami, nie oddając stabilności
Developer chce mergować częściej. Administrator pamięta noc, w której „drobna zmiana” wyłączyła logowanie. DevOps zaczyna się w miejscu, gdzie te dwa zdania da się pogodzić bez wygranej jednej strony.
Praktyczny most to wspólny język zmiany. Zamiast sporu o narzędzie lepiej ustalić trzy rzeczy: co jest artefaktem wdrożenia, kto może je wypuścić i jak wrócić do poprzedniej wersji, gdy healthcheck zacznie kłamać. Programista nie musi znać każdego playbooka. Musi wiedzieć, że konfiguracja nie żyje tylko na serwerze i że sekret nie należy do repozytorium. Administrator nie musi pisać funkcji aplikacji. Musi umieć powiedzieć, który sygnał po wdrożeniu oznacza regres, a który zwykły szum po restarcie.
Granica też powinna być nazwana wprost. Nie każda prośba o „szybki dostęp do produkcji” jest blokadą innowacji. Czasem to jedyna rzecz, która oddziela eksperyment od incydentu. Dobrze brzmi odmowa z alternatywą: środowisko testowe o zbliżonej konfiguracji, konto z węższymi uprawnieniami, pipeline zamiast ręcznego kopiowania plików. Gorzej brzmi samo „nie”, bez ścieżki, oraz samo „tak”, bez śladu w logu i bez możliwości cofnięcia.
Z tego układu wychodzi prosta zasada. DevOps nie polega na tym, że administrator zaczyna mówić jak programista. Polega na tym, że zmiana ma właściciela, historię i sposób powrotu — niezależnie od tego, kto w danym tygodniu naciska przycisk.
Tytuł na umowie może poczekać. Liczy się dzień, w którym ta sama awaria nie wymaga już odtwarzania kroków z pamięci, bo zostały w repozytorium, w pipeline i w alercie, który ma człowieka po drugiej stronie. Reszta narzędzi dojdzie przy kolejnym konkretnym bólu, nie przy kolejnej liście haseł.
Najczęściej zadawane pytania (FAQ)
Czy doświadczenie SysAdmina pomaga w pracy DevOps Engineera?
Tak. Znajomość Linuksa, sieci, uprawnień, backupów, monitoringu i diagnozowania awarii stanowi solidną podstawę do nauki automatyzacji, CI/CD, chmury i Infrastructure as Code.
Czy trzeba znać wszystkie narzędzia DevOps przed aplikowaniem?
Nie. Lepiej przeanalizować aktualne oferty i wybrać technologie, które powtarzają się najczęściej na interesującym rynku. Na początku warto skupić się na kilku podstawowych kompetencjach, takich jak Git, Docker, CI i wybrana chmura.
Od czego zacząć naukę po pracy administratora?
Dobrym początkiem są skrypty Bash lub Python, Git, kontenery oraz automatyzacja powtarzalnych czynności za pomocą Ansible. Następnie można przejść do Terraform i pozostałych elementów środowiska produkcyjnego.
Czy administrator on-premise może przejść do pracy z chmurą?
Tak. Wiedza o routingu, DNS, firewallach, dyskach i cyklu życia maszyn pomaga zrozumieć, że usługi chmurowe nadal opierają się na sieci, uprawnieniach i trwałości danych.
Jaki projekt warto umieścić w portfolio?
Praktycznym projektem może być prosta aplikacja webowa uruchamiana w kontenerach razem z bazą i reverse proxy. Warto dodać README, konfigurację środowisk oraz automatyzację, która pozwala powtarzalnie uruchomić całość.
Najważniejsze wnioski
- Przejście z SysAdmina do DevOps Engineera polega przede wszystkim na zmianie sposobu pracy, a nie na porzuceniu dotychczasowych kompetencji.
- Największą wartość mają automatyzacja, wersjonowanie konfiguracji, powtarzalność wdrożeń i umiejętność pracy z zespołem developerskim.
- Plan nauki warto oprzeć na analizie aktualnych ofert, zamiast próbować poznać wszystkie narzędzia jednocześnie.
- Podstawowa kolejność rozwoju może obejmować skrypty i Git, kontenery, Ansible oraz Terraform i Infrastructure as Code.
- Portfolio powinno pokazywać działający, opisany projekt, a nie wyłącznie listę ukończonych kursów.