Skalujesz zdolności DevOps? Poznaj nasze usługi Staff Augmentation.
Zobacz też: Stawki DevOps developera w Polsce 2026: przewodnik rekrutacyjny
Prawie każdy przewodnik po budowie zespołu DevOps kończy się tą samą drabinką: najpierw starszy Platform Engineer, po kilku miesiącach drugi, potem SRE, potem DevSecOps, na końcu Cloud Architect. Kolejność jest ułożona według dojrzałości organizacji i wygląda logicznie: najpierw fundament, potem niezawodność, potem bezpieczeństwo, na końcu strategia.
Ta drabinka ma dwa założenia, z których żadne nie obowiązuje w polskiej firmie w 2026 roku. Pierwsze: że o momencie zatrudnienia decyduje wewnętrzna gotowość organizacji. Drugie: że wielkość zespołu wynika ze stosunku inżynierów infrastruktury do deweloperów.
Teza tego przewodnika brzmi tak i można się z nią spierać w obie strony: kolejność rekrutacji w DevOps rozstrzyga dziś kalendarz regulacyjny, a nie dojrzałość zespołu — a rozmiar zespołu SRE rozstrzyga arytmetyka dyżuru zderzona z formą kontraktu, a nie stosunek jednego inżyniera na ośmiu do piętnastu deweloperów. Kontrargument jest poważny: budowanie zespołu pod terminy regulacyjne prowadzi do zatrudniania ludzi do wypełniania tabelek zamiast do rozwiązywania problemów inżynierskich, a organizacja bez fundamentu platformowego i tak nie wdroży kontroli bezpieczeństwa, bo nie ma ich gdzie wpiąć. To prawda i dlatego teza nie mówi „zatrudniaj DevSecOps zamiast Platform Engineera”. Mówi, że data obowiązku jest ograniczeniem twardym, a dojrzałość ograniczeniem miękkim — i że plan, który układa kolejność wyłącznie według drugiego, regularnie odkrywa pierwsze na trzy miesiące przed terminem, gdy rekrutacja seniora trwa dłużej.
Dlaczego „zespół DevOps” jest złą nazwą i co proponuje Team Topologies?
DevOps to zestaw praktyk, nie stanowisko — to zdanie powtarza się we wstępie do każdego artykułu na ten temat, po czym artykuł opisuje, jak zbudować zespół DevOps. Warto zatrzymać się przy tej sprzeczności, bo ma konsekwencje organizacyjne.
Matthew Skelton i Manuel Pais w „Team Topologies” (2019) opisali utrwalony zespół DevOps pośredniczący między developmentem a operacjami jako antywzorzec: taki zespół odtwarza dokładnie ten podział odpowiedzialności, który DevOps miał znieść, tylko pod nową nazwą. Zamiast tego proponują cztery typy zespołów i trzy tryby interakcji między nimi.
Zespół strumienia wartości (stream-aligned) odpowiada za wycinek produktu od pomysłu do produkcji. To domyślny typ zespołu; wszystkie pozostałe istnieją po to, żeby ten działał sprawniej.
Zespół platformowy dostarcza wewnętrzną platformę w trybie usługi, żeby zespoły strumienia mogły wdrażać samodzielnie. Kryterium sukcesu zespołu platformowego nie jest liczba zbudowanych narzędzi, tylko to, czy zespoły produktowe używają ich dobrowolnie.
Zespół wspierający (enabling) pomaga zespołowi produktowemu nabyć brakującą kompetencję i wychodzi. Ten typ jest w polskich organizacjach najrzadziej stosowany i najbardziej niedoceniany — a to on rozwiązuje problem, dla którego zwykle sadza się inżyniera platformy „na stałe” w zespole produktowym, po czym po pół roku okazuje się, że zespół produktowy nadal nie umie wdrażać samodzielnie.
Zespół podsystemu złożonego zajmuje się fragmentem wymagającym specjalistycznej wiedzy, której nie da się rozproszyć.
Praktyczna wartość tego modelu w rozmowie rekrutacyjnej jest konkretna: ograniczeniem rozmiaru zespołu nie jest liczba zadań, tylko obciążenie poznawcze — ile systemów, technologii i domen jeden zespół jest w stanie utrzymywać w głowie. Zespół platformowy odpowiedzialny za pipeline, Kubernetes, sieć, bazy danych, monitoring, sekrety i koszty chmury jednocześnie nie jest zbyt mały; jest przeciążony poznawczo i żadne dodatkowe zatrudnienie tego nie naprawi, dopóki zakres nie zostanie podzielony.
Jakie są cztery podstawowe specjalizacje i czego realnie wymagają?
Platform Engineer
Buduje wewnętrzną platformę deweloperską: narzędzia, przepływy i abstrakcje, których zespoły produktowe używają do budowania, testowania i wdrażania.
Obowiązki: projektowanie pipeline’ów wymagających minimalnej konfiguracji po stronie zespołu; samoobsługowy provisioning zasobów; złote ścieżki dla typowych zadań (nowa usługa, baza danych, monitoring); infrastruktura jako kod dla wszystkich środowisk; platforma orkiestracji kontenerów.
Kompetencje: infrastruktura jako kod na poziomie projektowym (Terraform lub OpenTofu, Pulumi, Crossplane); Kubernetes na poziomie produkcyjnym; systemy CI/CD w trybie projektowania, nie tylko używania (GitHub Actions, GitLab CI, Argo CD, Flux); co najmniej jeden język do narzędzi (Go, Python, TypeScript); głęboka znajomość jednej chmury; sieci — DNS, równoważenie obciążenia, service mesh, reguły zapory. Coraz częściej dochodzi portal deweloperski jako produkt (Backstage i pochodne).
Site Reliability Engineer
Odpowiada za to, żeby systemy produkcyjne były niezawodne i żeby praca operacyjna nie rosła liniowo z liczbą usług.
Obowiązki: definiowanie i egzekwowanie celów poziomu usług oraz budżetów błędów; monitoring, alertowanie i reagowanie na incydenty; przeglądy poincydentalne prowadzące do zmian systemowych; automatyzacja pracy powtarzalnej; planowanie pojemności. Pełniejszy opis roli i ram SLI/SLO znajduje się w naszym przewodniku po Site Reliability Engineering.
Kompetencje: realne umiejętności programistyczne, nie skryptowe — SRE pisze kod produkcyjny; obserwowalność (Prometheus, Grafana, rozproszone trasowanie, agregacja logów, komercyjne platformy APM); zarządzanie incydentami i komunikacja pod presją; inżynieria wydajności; wiedza o systemach na poziomie jądra, sieci i pamięci masowej. Przy wyborze samego stosu obserwowalności warto zestawić koszty — robimy to w porównaniu narzędzi APM.
Kluczowa zasada z książki zespołu Google o SRE, która jest jednocześnie najczęściej ignorowana: praca operacyjna SRE nie powinna przekraczać połowy jego czasu. Powyżej tego progu rola przestaje być inżynierską i staje się dyżurką, a zespół traci ludzi, którzy przyszli budować.
Cloud Architect
Projektuje strategię infrastruktury: jakie usługi, jaka struktura kont i sieci, jak zarządzać kosztem i bezpieczeństwem na poziomie architektonicznym.
Obowiązki: architektura dla nowych systemów i migracji; standardy nazewnictwa, tagowania, struktury kont i polityk dostępu; wybór między usługą zarządzaną a samodzielnie utrzymywaną; optymalizacja wydatków (instancje rezerwowane i spot, dopasowanie rozmiarów, alokacja kosztów) — szerzej w naszym przewodniku po strategii FinOps; architektura bezpieczeństwa i zgodności.
Kompetencje: poziom architekta w co najmniej jednej chmurze z realnym doświadczeniem wdrożeniowym; wzorce architektoniczne i świadomość, kiedy który jest właściwy; bezpieczeństwo (zarządzanie tożsamością, szyfrowanie, segmentacja, ramy zgodności); modelowanie kosztów; doświadczenie migracyjne.
DevSecOps Engineer
Integruje bezpieczeństwo w całym łańcuchu dostarczania, zamiast doklejać je na końcu.
Obowiązki: skanowanie w pipeline (analiza statyczna i dynamiczna, analiza składu oprogramowania, skanowanie obrazów); zarządzanie sekretami i rotacją; kontrole bezpieczeństwa infrastruktury (polityki sieciowe, bezpieczeństwo podów, ochrona w czasie działania); zarządzanie podatnościami i koordynacja łatania; polityki możliwe do stosowania bez nadmiernego tarcia. Kontekst konfiguracji sekretów opisuje nasz przewodnik po zarządzaniu sekretami w CI/CD.
Kompetencje: bezpieczeństwo aplikacji (OWASP, bezpieczne wzorce, ocena podatności); bezpieczeństwo kontenerów i Kubernetes; narzędzia (Trivy, Falco, Snyk, SonarQube, magazyny sekretów); ramy zgodności; a od 2026 roku coraz częściej także wykaz składników oprogramowania (SBOM) w formatach CycloneDX lub SPDX oraz podpisywanie artefaktów — bo to są wymagania, które rozporządzenie o cyberodporności przenosi z dobrej praktyki do obowiązku.
Dlaczego stosunek 1 : 8-15 deweloperów nie odpowiada na pytanie o rozmiar zespołu?
Ten wskaźnik krąży od lat i ma jedną zaletę: pozwala szybko oszacować budżet. Ma też trzy wady, przez które nie nadaje się do zaplanowania konkretnego zespołu.
Nie uwzględnia zakresu. Zespół platformowy obsługujący jedną chmurę, jeden język i dwadzieścia podobnych usług to zupełnie inne obciążenie niż zespół obsługujący trzy chmury, środowisko hybrydowe z systemem zastanym i sześć różnych stosów technologicznych. Liczba deweloperów w obu przypadkach może być identyczna.
Nie uwzględnia dyżuru. To jest najpoważniejszy błąd. Wskaźnik liczy zdolność do wykonywania pracy w godzinach roboczych. Zdolność do reagowania poza nimi rządzi się zupełnie inną arytmetyką, opisaną w następnej sekcji, i to ona zwykle wyznacza minimalny rozmiar zespołu.
Nie uwzględnia dojrzałości platformy. Dojrzała platforma z działającą samoobsługą wymaga mniej ludzi na dewelopera niż platforma w budowie — ale w trakcie budowy wymaga ich więcej niż w stanie docelowym. Planowanie zatrudnienia według wskaźnika docelowego gwarantuje niedobór w fazie, w której niedobór najbardziej boli.
Użyteczniejsze pytanie brzmi: ile odrębnych domen technicznych musi utrzymywać ten zespół i czy da się je zmieścić w obciążeniu poznawczym zespołu tej wielkości. Jeśli odpowiedź brzmi „nie”, właściwym ruchem jest zawężenie zakresu — przez usługi zarządzane, przez wycofanie technologii, przez podział zespołu — a nie kolejny etat.
Ile osób naprawdę potrzeba, żeby utrzymać dyżur 24/7?
Tu arytmetyka jest twarda i dobrze opisana. Punktem odniesienia jest praktyka opisana w książce o Site Reliability Engineering zespołu Google: żeby utrzymać całodobowy dyżur w jednej lokalizacji, potrzeba około ośmiu inżynierów; przy dwóch lokalizacjach w różnych strefach czasowych wystarcza po około sześciu na lokalizację — druga opcja jest tańsza w ludziach, bo nikt nie pełni dyżuru nocnego.
Zestawmy to z tym, co polskie organizacje realnie planują. Etap drugi klasycznej drabinki zakłada jednego SRE. Etap trzeci — dwóch do trzech. Przy rotacji czteroosobowej każdy pełni dyżur co drugi tydzień. Przy trzyosobowej — co trzeci tydzień, ale z pełnym pokryciem nocy i weekendów. To nie jest napięty harmonogram. To jest rozłożony w czasie plan odejść, i tak też się kończy: pierwsza osoba odchodzi po kilkunastu miesiącach, pozostałym rotacja skraca się do co drugiego tygodnia, druga osoba odchodzi szybciej.
Warto do tego dołożyć drugą zasadę z tej samej praktyki: dyżurny nie powinien obsługiwać więcej niż mniej więcej dwóch incydentów na zmianę. Powyżej tego progu nie ma czasu na rzetelną analizę, więc incydenty są tylko gaszone, przyczyny nie znikają i liczba incydentów rośnie. To jest pętla dodatniego sprzężenia, którą widać w każdym zespole utrzymującym dyżur zbyt małą liczbą osób.
Z tego wynikają trzy uczciwe opcje dla organizacji, której nie stać na ośmioosobową rotację, i jedna nieuczciwa.
Zawęź zakres dyżuru. Nie wszystko musi być objęte reagowaniem całodobowym. Wypisz usługi, dla których nocna awaria naprawdę wymaga natychmiastowej reakcji, i obejmij dyżurem tylko je. W większości organizacji ta lista jest o połowę krótsza, niż zakładano.
Kup zarządzaną usługę. Baza danych, kolejka, magazyn obiektów, klaster Kubernetes w wariancie zarządzanym — każda z tych decyzji zdejmuje z rotacji klasę incydentów. To jest wprost wymiana pieniędzy na etaty i przy polskich stawkach seniorskich zwykle wychodzi korzystnie.
Zrezygnuj świadomie z reagowania całodobowego i zapisz to w umowie o poziomie usług. Deklarowanie dostępności, której nie da się obsłużyć posiadaną rotacją, jest gorsze niż zadeklarowanie niższej.
Opcja nieuczciwa to utrzymywanie czteroosobowej rotacji z założeniem, że „jakoś się ułoży”. Nie ułoży się i koszt tej decyzji zapłacisz w rekrutacji, nie w budżecie operacyjnym.
Ile tygodni dyżuru rocznie przypada na osobę przy danej obsadzie?
Rachunek jest prosty i warto go pokazać na spotkaniu planującym zatrudnienie, bo zmienia rozmowę szybciej niż jakikolwiek argument jakościowy. Zakładamy tygodniowe zmiany, 52 tygodnie w roku i realną dostępność pomniejszoną o urlopy oraz nieobecności — przyjmijmy ostrożnie sześć tygodni niedostępności na osobę rocznie.
| Osób w rotacji | Tygodnie dyżuru rocznie na osobę | Co ile tygodni wypada dyżur | Ocena |
|---|---|---|---|
| 3 | ok. 17 | co 3. tydzień | Nie do utrzymania |
| 4 | ok. 13 | co 4. tydzień | Nie do utrzymania przy pełnym pokryciu nocy |
| 6 | ok. 9 | co 6. tydzień | Możliwe przy dwóch lokalizacjach lub zawężonym zakresie |
| 8 | ok. 6,5 | co 8. tydzień | Punkt odniesienia dla jednej lokalizacji |
| 12 | ok. 4,5 | co 12. tydzień | Komfortowe, uzasadnione przy dużej liczbie usług |
Do tego dołóż drugi wymiar, który tabela pomija, a który realnie decyduje o odejściach: liczbę wezwań na zmianę. Sześcioosobowa rotacja przy dwóch wezwaniach nocnych na tydzień jest znośna; czteroosobowa przy tej samej liczbie wezwań oznacza, że każdy jest budzony mniej więcej raz na dwa tygodnie przez cały rok. Dlatego zanim dołożysz etat, sprawdź, ile wezwań poza godzinami było w ostatnim kwartale i jaki ich odsetek okazał się fałszywym alarmem — redukcja fałszywych alarmów bywa tańsza niż dwa dodatkowe etaty i daje ten sam efekt na zdrowie rotacji.
Dlaczego w Polsce o dyżurze rozstrzyga forma kontraktu?
To jest miejsce, w którym anglojęzyczne przewodniki po budowie zespołów DevOps przestają być użyteczne, bo opisują amerykański model zatrudnienia.
W polskim zespole infrastrukturalnym część specjalistów pracuje na umowę o pracę, a znacząca część — zwłaszcza na poziomie seniorskim — na kontrakcie B2B. To rozróżnienie zmienia dyżur w dwóch przeciwnych kierunkach jednocześnie.
Przy umowie o pracę dyżur jest instytucją uregulowaną. Kodeks pracy przewiduje w art. 151⁵ dyżur jako pozostawanie w gotowości do wykonywania pracy poza normalnymi godzinami. Czasu dyżuru, w którym pracownik nie wykonywał pracy, nie wlicza się do czasu pracy — ale dyżur nie może naruszać prawa do odpoczynku: art. 132 Kodeksu pracy gwarantuje co najmniej 11 godzin nieprzerwanego odpoczynku dobowego, a art. 133 co najmniej 35 godzin odpoczynku tygodniowego. Praktyczna konsekwencja jest bardzo konkretna: wezwanie o trzeciej w nocy przerywa odpoczynek dobowy, więc pracownikowi trzeba zapewnić odpoczynek równoważny, co realnie oznacza późniejsze rozpoczęcie pracy albo dzień wolny. Grafik dyżurów, który tego nie przewiduje, jest grafikiem niewykonalnym zgodnie z prawem, niezależnie od dobrej woli stron.
Przy kontrakcie B2B Kodeks pracy nie ma zastosowania i dyżur jest wyłącznie tym, co napisano w umowie. Jeśli umowa nie zawiera klauzuli o gotowości poza godzinami, jej wynagrodzenia i zasad wezwania, to formalnie nie masz rotacji, tylko dobrą wolę kontrahenta. Działa to do pierwszego konfliktu albo do pierwszego lepszego kontraktu na rynku.
Do tego dochodzi ograniczenie, o którym łatwo zapomnieć przy projektowaniu twardego reżimu dyżurowego dla współpracowników na B2B. Kodeks pracy w art. 22 wiąże kwalifikację stosunku prawnego z jego rzeczywistą treścią — z podporządkowaniem, wykonywaniem pracy pod kierownictwem oraz w miejscu i czasie wyznaczonym przez zatrudniającego — i wyklucza zastępowanie umowy o pracę umową cywilnoprawną tam, gdzie te cechy występują. Grafik dyżurów narzucający konkretnej osobie godziny gotowości, połączony z podporządkowaniem operacyjnym i rozliczaniem z indywidualnych wskaźników, przesuwa relację w tę stronę.
Praktyczny wniosek dla planującego zespół: zanim policzysz, ilu ludzi potrzebujesz do rotacji, ustal, na jakich umowach będą pracować, bo to determinuje, jaki grafik jest w ogóle dopuszczalny. Dla zespołu mieszanego typowe rozwiązanie to jawna klauzula dyżurowa z odrębnym wynagrodzeniem w kontraktach B2B oraz grafik uwzględniający odpoczynek równoważny dla osób na etacie — i akceptacja, że te dwie grupy nie są w rotacji wymienne jeden do jednego.
Dlaczego kolejność rekrutacji rozstrzyga kalendarz regulacyjny?
Klasyczna drabinka umieszcza DevSecOps na czwartym miejscu, około dziewiątego do dwunastego miesiąca budowy zespołu, z uzasadnieniem, że bezpieczeństwo potrzebuje platformy, w którą się wepnie. Uzasadnienie jest sensowne. Problem polega na tym, że w Europie od 2025 roku obowiązki nie czekają na Twoją platformę.
17 stycznia 2025 — rozporządzenie (UE) 2022/2554 (DORA) jest stosowane wobec podmiotów finansowych i, przez wymogi dotyczące ryzyka stron trzecich, obejmuje umownie ich dostawców ICT. Wymaga zarządzania ryzykiem ICT, klasyfikacji i zgłaszania poważnych incydentów, programu testowania odporności cyfrowej oraz rejestru umów z dostawcami. Odpowiedzialność spoczywa na organie zarządzającym.
17 października 2024 — upłynął termin transpozycji dyrektywy NIS2 (2022/2555). W Polsce realizuje ją nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, której proces legislacyjny przeciągnął się poza ten termin. Dla organizacji objętych zakresem oznacza to obowiązki w zakresie zarządzania ryzykiem, zgłaszania incydentów w reżimie kilkustopniowym oraz odpowiedzialność kierownictwa.
11 września 2026 i 11 grudnia 2027 — dwie daty z rozporządzenia (UE) 2024/2847 o cyberodporności (CRA). Pierwsza to początek obowiązków zgłoszeniowych dotyczących aktywnie wykorzystywanych podatności; druga to pełne stosowanie, obejmujące wymagania dotyczące obsługi podatności przez cały okres wsparcia oraz dokumentowania składników oprogramowania. Dotyczy producentów produktów z elementami cyfrowymi — a więc także polskich firm wytwarzających oprogramowanie sprzedawane na rynku europejskim.
2 sierpnia 2026 — data, od której stosuje się główny pakiet obowiązków dla systemów wysokiego ryzyka z rozporządzenia (UE) 2024/1689 o sztucznej inteligencji. Jeśli produkt zawiera komponent, który mieści się w tej kategorii, wymogi dotyczące zarządzania ryzykiem, rejestrowania zdarzeń i nadzoru trafiają wprost w warstwę platformową.
Te daty są twarde i nie negocjuje się ich stanem zespołu. Rekrutacja seniora w obszarze bezpieczeństwa infrastruktury na polskim rynku zajmuje realnie od dwóch do czterech miesięcy, wdrożenie kolejne dwa. Organizacja, która zauważy obowiązek na kwartał przed terminem, ma do wyboru kontraktora dostępnego natychmiast albo obsunięcie.
Reguła praktyczna: cofnij każdą datę obowiązku o sześć do dziewięciu miesięcy i w tym punkcie umieść odpowiednie zatrudnienie w planie — niezależnie od tego, na którym szczeblu drabinki dojrzałości jest wtedy zespół.
Jak wygląda ewolucja zespołu na kolejnych etapach?
Etap 1: pierwsze zatrudnienie infrastrukturalne (1-2 osoby, 5-20 deweloperów)
Deweloperzy wdrażają własny kod, ale złożoność przerosła to, czym zarządzają generaliści.
Zatrudnij: jednego starszego DevOps/Platform Engineera. Ta osoba ustawia fundament: pipeline, infrastrukturę jako kod dla wszystkich środowisk, podstawowy monitoring, środowisko deweloperskie odzwierciedlające produkcję, kontrolę kosztów chmury.
Czego nie zakładaj: że ta osoba obsłuży dyżur. Jedna osoba to nie jest rotacja.
Etap 2: początek specjalizacji (3-5 osób, 20-50 deweloperów)
Wiele usług produkcyjnych, częstsze incydenty, jedna osoba nie wystarcza.
| Rola | Liczba | Skupienie |
|---|---|---|
| Platform Engineer | 2 | Pipeline, infrastruktura, doświadczenie deweloperskie |
| SRE | 1 | Monitoring, reagowanie na incydenty, pierwsze SLO |
| DevSecOps lub Platform Engineer z kompetencją bezpieczeństwa | 0,5-1 | Skanowanie, sekrety, podstawy zgodności |
Kamień milowy: oddzielenie budowniczego od operatora. Ograniczenie: przy takiej obsadzie dyżur całodobowy jeszcze nie jest wykonalny — zawęź zakres albo kup usługi zarządzane.
Etap 3: zespół platformowy (6-12 osób, 50-150 deweloperów)
Produktywność zespołów produktowych zależy od jakości platformy.
| Rola | Liczba | Skupienie |
|---|---|---|
| Platform Engineer | 3-5 | Samoobsługa, złote ścieżki, portal deweloperski |
| SRE | 2-3 | Niezawodność, incydenty, budżety błędów |
| Cloud Architect | 1 | Strategia, koszty, zgodność architektoniczna |
| DevSecOps | 1-2 | Pipeline bezpieczeństwa, podatności, SBOM |
Kamień milowy: platforma staje się produktem, a zespoły produktowe jej użytkownikami. Ograniczenie: dopiero przy górnej granicy tego przedziału rotacja dyżurowa zaczyna być zdrowa — i to pod warunkiem, że obejmuje więcej osób niż sam podzespół SRE.
Etap 4: dojrzała organizacja (15-30+ osób, 150+ deweloperów)
| Podzespół | Wielkość | Skupienie |
|---|---|---|
| Platform Engineering | 6-10 | Platforma samoobsługowa, doświadczenie deweloperskie |
| SRE | 4-6 | Niezawodność, incydenty, planowanie pojemności |
| Cloud Architecture | 2-3 | Nadzór architektoniczny, koszty, wiele chmur |
| DevSecOps | 3-5 | Inżynieria bezpieczeństwa, zgodność, modelowanie zagrożeń |
Kamień milowy: każdy podzespół ma własną mapę drogową, metryki i rotację dyżurową.
W jakiej kolejności rekrutować i jak zmienia ją reżim regulacyjny?
Kolejność bazowa, gdy żaden twardy termin nie obowiązuje, pozostaje sensowna: starszy Platform Engineer, drugi Platform Engineer, SRE, DevSecOps, Cloud Architect. Poniższa tabela pokazuje, co ją modyfikuje.
| Sygnał w organizacji | Rola do zatrudnienia | Kiedy najpóźniej | Dlaczego |
|---|---|---|---|
| Ręczne wdrożenia, brak infrastruktury jako kodu | Starszy Platform Engineer | Natychmiast | Bez fundamentu każda kolejna kompetencja pracuje ręcznie |
| Rosnąca liczba usług, powtarzające się incydenty | SRE | Zanim rotacja spadnie poniżej sensownej | Niezawodność wymaga praktyki systemowej, nie gaszenia |
| Obowiązki z DORA (podmiot finansowy lub jego dostawca) | DevSecOps + kompetencja zgodności | Przed datą obowiązku, z zapasem 6-9 miesięcy | Wymogi obejmują zarządzanie ryzykiem, testy i rejestr dostawców |
| Zakres NIS2 / krajowego systemu cyberbezpieczeństwa | DevSecOps | Przed wejściem obowiązków krajowych | Zgłaszanie incydentów wymaga procesu i narzędzi, nie deklaracji |
| Produkt z elementami cyfrowymi na rynek UE (CRA) | DevSecOps ze specjalizacją w łańcuchu dostaw | 6-9 miesięcy przed 11.09.2026 | Obsługa podatności i SBOM to praca platformowa, nie dokumentacyjna |
| Komponent AI wysokiego ryzyka | Kompetencja zgodności + platforma rejestrowania zdarzeń | Przed 02.08.2026 | Wymogi dotyczą warstwy operacyjnej, nie tylko modelu |
| Rosnące rachunki chmurowe, decyzje architektoniczne bez właściciela | Cloud Architect | Gdy koszt chmury przekracza koszt zespołu platformowego | Koszt i ryzyko architektoniczne rosną nieliniowo |
| Rotacja dyżurowa poniżej sześciu osób przy pełnym pokryciu | Kolejny SRE albo zawężenie zakresu dyżuru | Zanim odejdzie pierwsza osoba | Poniżej progu rotacja rozpada się sama |
Ile kosztuje zespół DevOps w złotówkach?
Poniższe kwoty opierają się na stawkach polskiego rynku dla kontraktów B2B: junior 10-15 tys. zł, mid 15-22 tys. zł, senior 22-35 tys. zł, architekt 30-45 tys. zł netto miesięcznie, z narzutem 15-20% dla Warszawy względem regionów. Pełne widełki i ich rozbicie znajdziesz w przewodniku po stawkach DevOps developera.
| Etap | Obsada | Koszt miesięczny (netto, B2B) | Co za to dostajesz |
|---|---|---|---|
| 1 | 1 senior | 22-35 tys. zł | Fundament: pipeline, IaC, podstawowy monitoring |
| 2 | 2 senior + 1 mid + 0,5 etatu bezpieczeństwa | 75-115 tys. zł | Rozdzielenie budowy od utrzymania, dyżur o zawężonym zakresie |
| 3 | 6-9 osób, w tym architekt | 160-260 tys. zł | Platforma jako produkt, sensowna rotacja przy górnej granicy |
| 4 | 15-24 osoby w czterech podzespołach | 400-700 tys. zł | Pełne pokrycie, wiele inicjatyw równolegle |
| Rotacja 24/7 sama w sobie | 8 seniorów | 176-280 tys. zł | Sam warunek dyżuru, niezależnie od reszty zakresu |
Ostatni wiersz jest najważniejszy w tej tabeli, bo pokazuje, dlaczego zawężenie zakresu dyżuru albo zakup usług zarządzanych jest decyzją finansową, a nie techniczną. Różnica między dyżurem obejmującym dwanaście usług a dyżurem obejmującym trzy usługi krytyczne bywa różnicą między etapem 2 a etapem 3 w kosztach.
Jak licencje zmieniły rachunek Cloud Architekta?
Warto dopisać do opisu tej roli obszar, którego trzy lata temu w niej nie było, a który dziś regularnie decyduje o budżecie.
W sierpniu 2023 roku HashiCorp zmienił licencję swoich flagowych produktów — w tym Terraform i Vault — z licencji otwartej na Business Source License. W odpowiedzi społeczność utworzyła forki rozwijane pod skrzydłami Linux Foundation: OpenTofu jako alternatywę dla Terraform i OpenBao jako alternatywę dla Vault. W 2025 roku HashiCorp został przejęty przez IBM, co dla klientów oznacza zmianę w modelu wsparcia i cenniku.
Dla polskiej organizacji ma to trzy praktyczne konsekwencje, którymi zarządza Cloud Architect, a nie dział zakupów.
Ryzyko licencyjne stało się elementem wyboru narzędzia. Pytanie „czy ta licencja pozwoli nam robić to, co planujemy robić za trzy lata” trafiło do kryteriów wyboru na stałe.
Migracja między forkiem a oryginałem jest wykonalna, ale nie darmowa. Kompatybilność na poziomie plików konfiguracyjnych bywa wysoka, ale narzędzia towarzyszące, rejestry modułów i integracje wymagają pracy. To jest projekt tygodni, nie dni.
Ekspozycja na jednego dostawcę w warstwie narzędziowej ma teraz taką samą wagę co ekspozycja w warstwie chmurowej. To argument, który dobrze łączy się z decyzjami opisanymi w naszym przewodniku po trendach DevOps oraz z rachunkiem kosztów obserwowalności.
Jak zmierzyć, czy zespół platformowy faktycznie działa?
Trzy grupy wskaźników, w kolejności od najłatwiejszych do najbardziej wymownych.
Cztery wskaźniki dostarczania spopularyzowane przez program badawczy DORA i książkę „Accelerate” (Forsgren, Humble, Kim, 2018): częstotliwość wdrożeń, czas od commita do produkcji, odsetek wdrożeń kończących się awarią i czas przywrócenia usługi po nieudanym wdrożeniu. Mają publiczną metodykę i coroczny pomiar na dużej próbie, więc nadają się do porównania z zewnętrznym punktem odniesienia lepiej niż wskaźniki wymyślone wewnętrznie.
Adopcja platformy. Odsetek zespołów produktowych korzystających ze złotych ścieżek dobrowolnie, czas od pomysłu do działającej usługi na produkcji dla nowego serwisu, liczba zgłoszeń do zespołu platformowego na jeden zespół produktowy w miesiącu. Ostatni wskaźnik jest najbardziej diagnostyczny: rosnąca liczba zgłoszeń oznacza, że platforma nie jest samoobsługowa, tylko przemianowana.
Zdrowie dyżuru. Liczba wezwań poza godzinami na osobę na miesiąc, odsetek wezwań poza godzinami zakończonych bez działania (fałszywe alarmy), udział pracy operacyjnej w czasie SRE. Ten ostatni odnosi się wprost do zasady połowy czasu — i jest jedynym wskaźnikiem z tej listy, który przewiduje odejścia z wyprzedzeniem.
Jakich błędów najczęściej unikać?
Planowanie rotacji dyżurowej poniżej progu. Cztery osoby nie utrzymają całodobowego dyżuru. Ta pozycja jest pierwsza, bo jej konsekwencje są najbardziej kosztowne i najtrudniejsze do odwrócenia.
Zatrudnianie SRE zanim jest co uniezawodniać. SRE potrzebuje systemów produkcyjnych z realnymi oczekiwaniami dostępności. Zatrudniony za wcześnie zrobi pracę Platform Engineera i odejdzie.
Odkładanie kompetencji bezpieczeństwa do etapu czwartego. W organizacji objętej DORA, NIS2 albo CRA data obowiązku jest twarda, a rekrutacja plus wdrożenie to od czterech do sześciu miesięcy.
Traktowanie zespołu platformowego jako działu zgłoszeń. Jeśli liczba zgłoszeń rośnie proporcjonalnie do liczby zespołów produktowych, nie zbudowałeś platformy, tylko przeniosłeś wąskie gardło.
Projektowanie grafiku dyżurów bez sprawdzenia formy zatrudnienia. Grafik naruszający odpoczynek dobowy osób na etacie jest niewykonalny, a grafik narzucany osobom na B2B bez klauzuli umownej jest nieegzekwowalny.
Utrwalanie zespołu wspierającego. Zespół wspierający ma przekazać kompetencję i wyjść. Jeśli został na stałe, to jest to centralizacja z dodatkowym krokiem.
Zatrudnianie Cloud Architekta bez umocowania decyzyjnego. Architekt bez prawa do rozstrzygnięcia produkuje dokumenty, wokół których organizacja buduje obejścia.
Jak ARDURA Consulting buduje zespoły DevOps?
Budowa zespołu DevOps przy jednoczesnym utrzymywaniu produkcji to sytuacja bez wyjścia: potrzebujesz zespołu, żeby zbudować platformę, i platformy, żeby być produktywnym — a jeśli w tle biegnie termin regulacyjny, brakuje Ci przede wszystkim czasu. ARDURA Consulting przełamuje ten impas.
- 500+ starszych specjalistów, w tym Platform Engineerów, SRE, Cloud Architektów i inżynierów DevSecOps — dostępnych w 2 tygodnie, co bywa jedyną odpowiedzią na termin, którego nie da się przesunąć
- 40% oszczędności kosztowych względem stałego zatrudnienia, z elastycznością zwiększenia obsady na czas budowy platformy i redukcji, gdy przejmują ją pracownicy stali
- 99% retencji klientów — inżynierowie, którzy przekazują wiedzę i wychodzą, zamiast budować uzależnienie od dostawcy
- 211+ zrealizowanych projektów — zespoły, które doprowadziły organizacje DevOps od zera do dojrzałości i wiedzą, które wzorce działają na którym etapie
Jeśli planujesz pierwsze zatrudnienie infrastrukturalne, próbujesz domknąć rotację dyżurową albo masz przed sobą termin z NIS2, DORA lub CRA i policzyłeś, że rekrutacja nie zdąży — skontaktuj się z nami, żeby omówić zakres wsparcia. Jeśli punktem wyjścia jest platforma kontenerowa, warto zacząć od naszej checklisty wdrożenia Kubernetesa.