CV DevOps Engineer: jak opisać CI/CD, IaC i chmurę pod ofertę

Typowa oferta DevOps wygląda jak spis treści katalogu narzędzi: Terraform, Kubernetes, GitHub Actions, AWS, Prometheus, Helm, ArgoCD, Ansible, do tego „chmura” i „automatyzacja” jako słowa-wytrychy. Rekruter techniczny czyta to i robi w głowie checklistę. Potem otwiera twoje CV, w którym pod stanowiskiem stoi „Backend Developer” albo „Administrator systemów”, a niżej taka sama ściana logotypów. Tylko że z tej ściany nie widać, czy ty te narzędzia kiedyś dotknąłeś, czy postawiłeś na nich produkcję, która nie pada po deployu.

Bo na stanowisku DevOps nie chodzi o to, ile narzędzi znasz. Chodzi o to, czy bierzesz odpowiedzialność za pipeline od commita do produkcji i za to, żeby on stał. Lista technologii tego nie pokaże, bo każdy kandydat ma identyczną. Pokaże to dopiero opis, w którym widać skalę infrastruktury, efekt twoich zmian i to, że ktoś budził cię o trzeciej w nocy, a ty wiedziałeś, gdzie patrzeć.

Poniżej masz, co wyeksponować nad fold, jak opisać projekt DevOps przez wpływ na czas deployu, MTTR i koszty, i jak ująć on-call, żeby nie brzmiał jak „byłem pod telefonem”.

Co wyeksponować nad fold: chmura, IaC, CI/CD

„Nad fold” to ta część CV, którą rekruter widzi bez przewijania. Pod ofertę DevOps ma tam być widać trzy rzeczy: w jakiej chmurze pracujesz, czym opisujesz infrastrukturę i jak wygląda twój pipeline. To rdzeń roli, reszta jest wsparciem.

Ułóż umiejętności w kolejności istotności dla oferty, nie alfabetycznie:

• Rdzeń: chmura (AWS, GCP albo Azure, ta z oferty na pierwszym miejscu), IaC (Terraform, czasem Pulumi), orkiestracja (Kubernetes, Helm), CI/CD (GitHub Actions, GitLab CI, Jenkins).
• Realne wsparcie: monitoring i observability (Prometheus, Grafana, Loki), konteneryzacja (Docker), konfiguracja (Ansible), GitOps (ArgoCD, Flux).
• Reszta: języki skryptowe, bazy, sieci, niżej i mniejszą wagą.

Jeśli oferta wymienia konkretne narzędzie, którego realnie używasz na produkcji, ma być widoczne od razu, nie zakopane między dwudziestą a trzydziestą pozycją. Rekruter skanuje pod kątem zgodności z ogłoszeniem, nie kompletności twojej kariery.

Jak opisać projekt DevOps efektem, nie zadaniem

To jest miejsce, gdzie większość CV DevOps się wykłada. Ludzie wypisują, co robili („zarządzałem pipeline CI/CD”, „utrzymywałem klaster Kubernetes”), a to są obowiązki, nie dokonania. Nie widać ani skali, ani tego, czy po twojej robocie cokolwiek działało lepiej. Pokaż zmianę i jej efekt, mierzony tym, co w DevOps się liczy: czas deployu, MTTR, koszty chmury, niezawodność.

Słaby zapis, który czyta się jak zakres obowiązków:

Konfigurowałem pipeline CI/CD w GitHub Actions i zajmowałem się infrastrukturą w AWS przy użyciu Terraform.

Ten sam fakt, ustawiony pod ofertę DevOps:

Przepisałem pipeline CI/CD w GitHub Actions z monolitycznego skryptu na zrównoleglone joby, skracając czas deployu z 22 do 6 minut przy 40 wdrożeniach dziennie. Przeniosłem infrastrukturę 30 mikroserwisów na Terraform, co skróciło stawianie środowiska z dwóch dni ręcznej pracy do 15 minut i wyeliminowało dryf konfiguracji między stagingiem a produkcją.

Druga wersja opisuje dokładnie to samo, co robiłeś, ale pokazuje punkt wyjścia, zmianę i efekt w liczbach. Widać skalę (30 mikroserwisów, 40 deployów dziennie), zmianę (zrównoleglenie, migracja na IaC) i wpływ (czas deployu, koniec z dryfem). Tego rekruter szuka, bo to odróżnia kogoś, kto klikał w gotowe pipeline'y, od kogoś, kto je projektował.

Mocne akcenty pod DevOps i ich konkrety: czas deployu (z X do Y minut), MTTR (jak szybko wstaje usługa po awarii), koszty (ile zeszło z rachunku za chmurę po optymalizacji), niezawodność (uptime, liczba incydentów po zmianie), skala (ile serwisów, węzłów, RPS, ile środowisk).

On-call i niezawodność: jak to ująć, żeby coś znaczyło

On-call w CV najczęściej brzmi jak „byłem pod telefonem”, co nic nie waży. Rekruter pod DevOps nie szuka kogoś, kto odbierał alerty. Szuka kogoś, kto po incydencie zostawiał system w lepszym stanie, niż go zastał. Dlatego on-call opisuj przez to, co z niego wyszło, nie przez sam fakt dyżuru.

Zamiast „pełniłem dyżury on-call” napisz, ilu usług dotyczyły i jak duży był ruch, a potem pokaż konkret: skróciłeś MTTR z 45 do 12 minut, bo dopisałeś runbooki i poukładałeś alerty w Prometheusie tak, żeby nie szumiały. Albo: po serii nocnych incydentów dodałeś auto-scaling i health-checki, które zbiły liczbę budzików z ośmiu na miesiąc do jednego. Niezawodność pokazuj liczbami: uptime, liczba incydentów przed i po, czas reakcji. To jest dowód odpowiedzialności za produkcję, a nie deklaracja.

Słowa kluczowe z ofert DevOps

Oferty DevOps powtarzają konkretny zestaw zwrotów: terraform, kubernetes (k8s), github actions albo gitlab ci, docker, prometheus, grafana, aws albo gcp, helm, ansible, ci/cd, gitops, observability, infrastructure as code. To są twoje słowa kluczowe. Wyciągnij must-have z konkretnej oferty i sprawdź, które masz pokryte realnym przykładem z projektu, a których lepiej nie wpisywać, bo zweryfikują je na pierwszej rozmowie technicznej. Jak czytać ogłoszenie pod tym kątem, rozkładamy w jak wyciągnąć słowa kluczowe z oferty IT.

Jeden projekt zwykle daje materiał na kilka odcieni tej samej roli: backend z elementami DevOps, platform engineer, czysty SRE. To ten sam projekt, inny pierwszy plan, bez przepisywania historii. Mechanikę pokazujemy w jeden projekt, cztery role.

Częste błędy

• Ściana narzędzi bez kontekstu. Trzydzieści logotypów wrzuconych obok siebie nie mówi, czy stawiałeś na nich produkcję, czy przeszedłeś tutorial. Rekruter nie wie, w czym jesteś naprawdę dobry. Zostaw rdzeń, resztę podaj niżej i pokaż użycie w projektach.
• Brak skali infrastruktury. „Zarządzałem klastrem Kubernetes” bez liczb jest puste. Trzy węzły dla wewnętrznego narzędzia to inna liga niż 200 węzłów obsługujących produkcję. Dopisz, ile serwisów, węzłów, ruchu, środowisk.
• Opis zadań zamiast wpływu na niezawodność i koszt. „Utrzymywałem CI/CD” to obowiązek. Rekruter chce wiedzieć, co z tego wyszło: szybszy deploy, niższy MTTR, mniejszy rachunek za chmurę, mniej incydentów. Bez efektu opis jest tylko listą czynności.

Jak złożyć CV DevOps pod ofertę w ZłóżCV

Pod ofertę DevOps ZłóżCV bierze z twojej bazy projekty, w których realnie budowałeś pipeline, infrastrukturę i monitoring, układa stack pod wymagania ogłoszenia i przepisuje opisy tak, żeby było widać skalę, efekt i odpowiedzialność, a nie samą listę narzędzi. Wklejasz link do oferty, dostajesz dopasowane CV w PDF. Złóż CV pod ofertę DevOps, dwa pierwsze za darmo, bez karty. Zanim zaczniesz, warto przeczytać jak dopasować CV do oferty.

Najczęstsze pytania

Idę w DevOps z roli backend developera albo admina, jak to pokazać? Nie zmieniaj tytułu na wyrost. Zostaw realne stanowisko, a w opisach wyciągnij na pierwszy plan to, co już robiłeś po stronie DevOps: pisanie pipeline'ów, konteneryzację, automatyzację, IaC, dyżury. Wiarygodne „budowałem infrastrukturę” bije puste „DevOps Engineer” w polu stanowiska.

Ile narzędzi wpisać do sekcji umiejętności? Tyle, ile realnie używasz, ułożone według istotności dla oferty. Rdzeń (chmura, IaC, k8s, CI/CD) na górze i widoczny, reszta niżej. Lista 40 pozycji nie robi wrażenia, tylko rozmywa to, w czym jesteś mocny.

Nie mam doświadczenia z Kubernetes, a oferta go wymaga, co wtedy? Nie dopisuj go, bo to się weryfikuje na rozmowie technicznej w pięć minut. Pokaż za to pokrewne kompetencje, które masz: Docker, orkiestrację, którą znasz, automatyzację deploymentu. Jeśli k8s jest twardym must-have, a ty go nie dotykałeś, to po prostu nie jest oferta pod ciebie.

Jak pokazać efekt, gdy pracowałem przy cudzej infrastrukturze i nie wszystko zależało ode mnie? Opisz swój wycinek konkretnie. Nawet jeśli nie projektowałeś całości, mogłeś skrócić jeden pipeline, dodać alerty, zoptymalizować jeden serwis. Pokaż tę zmianę z liczbą zamiast przypisywać sobie cały system. Konkretny mały wpływ jest wiarygodniejszy niż ogólnik o całej platformie.