CTO firmy SaaS zatrudniającej 300 osób dostaje przed rundą finansowania pytanie od zarządu: „Jak dojrzała jest nasza organizacja inżynierska?”. Lider platformy odpowiada, że firma ma CI/CD, działa na Kubernetesie i używa Terraforma. Szefowa QA mówi, że regresja przed każdym wydaniem nadal trwa cztery dni. Dyżurni mówią, że co czwarte wydanie wymaga hotfixa. Wszystkie trzy odpowiedzi są prawdziwe i żadna nie odpowiada na pytanie.
To właśnie problem, który rozwiązuje model dojrzałości DevOps. Lista narzędzi opisuje, co firma kupiła, a anegdoty — jej ostatni zły tydzień. Model dojrzałości opisuje, jak niezawodnie organizacja zamienia kod w wartość na produkcji, we wszystkich wymiarach, które mają znaczenie, a nie tylko w tym, za który odpowiada dany lider.
Poniżej przedstawiamy pięciopoziomowy model dojrzałości DevOps w siedmiu wymiarach, checklistę samooceny z 28 pytaniami i metodą punktacji przeliczoną na przykładzie, najnowsze benchmarki DORA i mapę przejścia między poziomami. Tekst jest przeznaczony dla CTO i liderów inżynierii, którzy potrzebują uczciwego punktu wyjścia, a nie prezentacji sprzedażowej dostawcy narzędzi.
Czym jest model dojrzałości DevOps i po co CTO?
Model dojrzałości DevOps to uporządkowany opis tego, jak rozwijają się praktyki dostarczania oprogramowania: od ręcznych i zależnych od konkretnych osób do zautomatyzowanych, mierzonych i stale doskonalonych. Robi dwie rzeczy, których nie zrobi lista narzędzi.
Po pierwsze, pokazuje luki w poszczególnych wymiarach. Organizacje rzadko dojrzewają równomiernie. Firma może wdrażać kilka razy dziennie i nie mieć żadnych automatycznych testów bezpieczeństwa albo utrzymywać dopracowaną platformę wewnętrzną, podczas gdy incydenty obsługuje ten, kto akurat jest online. Model dojrzałości wymusza ocenę każdego wymiaru tą samą miarą.
Po drugie, zamienia doskonalenie w sekwencję. Każdy poziom to zestaw zdolności, na których buduje następny. Ta kolejność ma znaczenie: częste wdrożenia bez testów automatycznych przyspieszają dostarczanie błędów, a wewnętrzna platforma deweloperska bez ustandaryzowanych pipeline’ów automatyzuje chaos.
Dla CTO ocena dojrzałości odpowiada na trzy praktyczne pytania:
- Gdzie naprawdę jesteśmy? Punkt wyjścia uzgodniony przez inżynierię, operacje, bezpieczeństwo i produkt, a nie najbardziej optymistyczny obraz jednej z tych grup.
- Co naprawić najpierw? Najsłabszy wymiar zwykle ogranicza cały system dostarczania i rzadko jest tym, któremu poświęca się najwięcej uwagi.
- W co inwestować i w jakiej kolejności? Budżety na rekrutację, narzędzia i szkolenia wynikają z luk, a nie z roadmap dostawców.
Warto też jasno powiedzieć, czym model dojrzałości nie jest. To nie certyfikat ani wynik do pokazania na slajdzie. Gdy poziom dojrzałości staje się celem, za który zespoły są nagradzane, przestaje cokolwiek mierzyć. Używaj go jako narzędzia diagnostycznego, powtarzanego co sześć–dwanaście miesięcy, i łącz z metrykami wyników, które trudno zmanipulować.
Jak model dojrzałości DevOps ma się do CMMI i DORA?
Większość modeli dojrzałości DevOps, w tym nasz, zapożycza pięciopoziomową strukturę z CMMI (Capability Maturity Model Integration), opracowanego pierwotnie w Software Engineering Institute na Carnegie Mellon University. CMMI definiuje pięć poziomów dojrzałości: Initial, Managed, Defined, Quantitatively Managed i Optimizing. W DevOps logika jest ta sama: najpierw sprawić, by praca była powtarzalna, potem ją ustandaryzować, następnie mierzyć, a na końcu systematycznie doskonalić.
Różnica leży w zakresie. CMMI opisuje dojrzałość procesów w ogólności, a model dojrzałości DevOps — konkretne zdolności techniczne i kulturowe, od których zależy, jak szybko i bezpiecznie oprogramowanie trafia na produkcję. Odzwierciedlają to nazwy naszych poziomów:
| Nasz poziom | Odpowiednik w CMMI | Krótki opis |
|---|---|---|
| 1. Doraźny | Initial | Ręczne dostarczanie zależne od ludzi |
| 2. Powtarzalny | Managed | Podstawowa automatyzacja w części zespołów |
| 3. Ustandaryzowany | Defined | Wspólne pipeline’y, wszystko jako kod |
| 4. Mierzony | Quantitatively Managed | Decyzje oparte na SLO i metrykach dostarczania |
| 5. Optymalizujący | Optimizing | Ciągłe eksperymenty, samoobsługa w skali |
DORA pełni inną rolę. DORA (DevOps Research and Assessment) to program badawczy prowadzony obecnie przez Google Cloud, który od ponad dekady bada specjalistów technologicznych. Jego wnioski spopularyzowała wydana w 2018 roku książka Accelerate Nicole Forsgren, Jeza Humble’a i Gene’a Kima, która wskazała 24 zdolności napędzające wydajność dostarczania oprogramowania. DORA mierzy wyniki — jak często wdrażasz i jak często wdrożenia się nie udają. Model dojrzałości ocenia zdolności — na przykład to, czy środowiska powstają z kodu.
Potrzebujesz obu. Zdolności bez wyników zamieniają się w odhaczanie pozycji: zespół może mieć każde narzędzie z listy i nadal wdrażać raz w miesiącu. Wyniki bez zdolności mówią, że coś jest nie tak, ale nie mówią, co zmienić. W naszym modelu metryki DORA są dowodem potwierdzającym poziom dojrzałości, a nie samym poziomem.
Jedna uwaga terminologiczna: w Unii Europejskiej skrót DORA oznacza też rozporządzenie Digital Operational Resilience Act, stosowane wobec podmiotów finansowych od 17 stycznia 2025 roku. To dwie różne rzeczy, choć dojrzała organizacja dostarczania znacznie łatwiej spełnia wymogi rozporządzenia dotyczące ryzyka ICT i raportowania incydentów.
Które metryki DORA pokazują, gdzie jesteś, i co zmieniło się w 2024 i 2025 roku?
Przez lata DORA stosowała „cztery klucze”: częstotliwość wdrożeń, czas realizacji zmiany, odsetek nieudanych zmian i czas przywrócenia usługi. Dwie zmiany od tamtej pory mają znaczenie dla każdego, kto dziś buduje system pomiarowy.
W 2023 roku czas przywrócenia usługi zdefiniowano na nowo jako czas przywrócenia po nieudanym wdrożeniu (failed deployment recovery time). Dawna definicja nie odróżniała awarii spowodowanych zmianą w oprogramowaniu od awarii z przyczyn zewnętrznych, takich jak awaria centrum danych. Nowa metryka mierzy wyłącznie powrót do działania po wdrożeniu, które się nie udało.
W 2024 roku DORA dodała piątą metrykę, odsetek wdrożeń naprawczych (deployment rework rate), i pogrupowała metryki w dwa czynniki:
- Przepustowość: czas realizacji zmiany (od commita do produkcji), częstotliwość wdrożeń i czas przywrócenia po nieudanym wdrożeniu.
- Niestabilność: odsetek nieudanych zmian (wdrożeń powodujących awarie na produkcji) i odsetek wdrożeń naprawczych (wdrożeń będących nieplanowaną pracą przy poprawianiu błędów).
Raport Accelerate State of DevOps 2024 podzielił respondentów na cztery klastry wydajności:
| Klaster (2024) | Udział respondentów | Czas realizacji zmiany | Częstotliwość wdrożeń | Odsetek nieudanych zmian | Czas przywrócenia |
|---|---|---|---|---|---|
| Elitarny | 19% | Poniżej dnia | Na żądanie | 5% | Poniżej godziny |
| Wysoki | 22% | Od dnia do tygodnia | Od codziennie do co tydzień | 20% | Poniżej dnia |
| Średni | 35% | Od tygodnia do miesiąca | Od co tydzień do co miesiąc | 10% | Poniżej dnia |
| Niski | 25% | Od 1 do 6 miesięcy | Od co miesiąc do co pół roku | 40% | Od tygodnia do miesiąca |
Dwa szczegóły są warte uwagi. Klaster wysoki skurczył się z 31% w 2023 roku do 22% w 2024 roku, a niski urósł z 17% do 25%. Po raz pierwszy klaster średni miał też niższy odsetek nieudanych zmian niż wysoki — przypomnienie, że szybkość i stabilność nie zawsze idą w parze.
Raport z 2025 roku, przemianowany na State of AI-assisted Software Development i oparty na odpowiedziach blisko 5000 specjalistów, poszedł dalej. Zastąpił cztery klastry siedmioma profilami zespołów — od „Foundational challenges” i „Legacy bottleneck” po „Pragmatic performers” i „Harmonious high-achievers” — łącząc metryki dostarczania z dobrostanem zespołu i wynikami produktu. Uzasadnienie autorów wprost dotyczy oceny dojrzałości: metryki dostarczania mówią, co się dzieje, ale nie mówią, dlaczego.
Jakie jest 5 poziomów dojrzałości DevOps?
Każdy poziom opisuje spójny stan całego systemu dostarczania. Większość organizacji jest na różnych poziomach w różnych wymiarach; poniższe opisy to typowy profil, gdy dany poziom zostanie osiągnięty we wszystkich wymiarach.
Poziom 1: doraźny. Wydania są wydarzeniami. Wdrożenia są ręczne lub półręczne, przygotowywane przez kilka osób, które wiedzą, jak to zrobić, i planowane poza godzinami pracy. Środowiska są konfigurowane ręcznie i różnią się między sobą. Testy są głównie manualne i odbywają się na końcu. O incydentach dowiadują się klienci. Wiedza jest w głowach ludzi, więc urlopy i odejścia są ryzykiem dla dostarczania.
Poziom 2: powtarzalny. Część zespołów ma automatyczny build i testy jednostkowe przy każdym commicie. Skrypty wdrożeniowe istnieją, ale każdy zespół ma własne. Część infrastruktury jest w systemie kontroli wersji. Są scentralizowane logi i podstawowe alerty dostępności. Dostarczanie działa, ale zależy od tego, którego zespołu dotyczy, a zmiany przekrojowe są powolne.
Poziom 3: ustandaryzowany. Większość zespołów korzysta ze wspólnego szablonu pipeline’u. Każde środowisko powstaje z kodu, a ręczne zmiany na produkcji są wyjątkiem. Automatyczne testy regresji blokują scalanie zmian. Skanowanie bezpieczeństwa działa w pipeline. Po poważnych incydentach odbywają się postmortemy bez szukania winnych. Wewnętrzny zespół platformowy oferuje samoobsługę dla najczęstszych zadań — „złotą ścieżkę”, na której właściwe działanie jest najłatwiejsze.
Poziom 4: mierzony. Decyzje opierają się na danych. Usługi mają cele poziomu usług (SLO) uzgodnione z właścicielami produktu, a alerty reagują na objawy odczuwalne przez użytkowników, a nie na metryki serwerów. Metryki DORA są zbierane automatycznie z pipeline’u i narzędzi do obsługi incydentów, a nie z ankiet. Platforma jest prowadzona jak produkt, z roadmapą i metrykami adopcji. Zespoły odpowiadają za swoje usługi od początku do końca.
Poziom 5: optymalizujący. Wdrożenie nie jest wydarzeniem — odbywa się na żądanie, z technikami stopniowego udostępniania, takimi jak wydania kanarkowe i flagi funkcji. Eksperymenty usprawniające są częścią planu każdego kwartału. Znane typy awarii są naprawiane automatycznie. Dowody zgodności powstają w pipeline na bieżąco, a nie są zbierane przed audytem. Organizacja uczy się na incydentach szybciej, niż tworzy nowe.
Poziom 5 nie jest celem dla każdej organizacji. Dla wielu firm solidny poziom 3 z pomiarami poziomu 4 w najbardziej krytycznych usługach to ekonomicznie rozsądny cel. Właściwy poziom zależy od tego, jak bardzo biznes zależy od szybkości i niezawodności zmian w oprogramowaniu.
Które siedem wymiarów warto ocenić?
Ocena dojrzałości jest tak dobra, jak jej wymiary. Za mało — i przeoczysz najsłabsze ogniwo; za dużo — i nikt jej nie dokończy. Stosujemy siedem wymiarów, z których każdy odpowiada obszarowi zdolności, który według badań DORA i naszych projektów często ogranicza dostarczanie:
- Kultura i współpraca — wspólna odpowiedzialność rozwoju i operacji, uczenie się na incydentach, stabilne priorytety. Badanie DORA z 2024 roku wykazało, że niestabilne priorytety organizacji istotnie obniżają produktywność i wyraźnie zwiększają wypalenie, a efekt ten utrzymuje się nawet przy silnym przywództwie i dobrej dokumentacji. Więcej o tej warstwie piszemy w przewodniku lidera po kulturze DevOps.
- CI/CD — droga kodu od commita do produkcji: automatyzacja buildów, standardy pipeline’ów, częstotliwość wdrożeń i wycofywanie zmian. Podstawy opisuje hasło pipeline CI/CD.
- Infrastruktura jako kod — czy środowiska da się odtworzyć z systemu kontroli wersji i czy są chronione przed rozjazdem konfiguracji. Zob. infrastruktura jako kod (IaC).
- Testy — testy automatyczne na właściwych poziomach, bramki jakości, dane testowe i niezawodność testów.
- Obserwowalność i reagowanie na incydenty — logi, metryki i ślady (traces), SLO, dyżury i postmortemy.
- Bezpieczeństwo (DevSecOps) — testy bezpieczeństwa, zarządzanie sekretami, łańcuch dostaw oprogramowania i zgodność wbudowane w proces dostarczania. Różnice między podejściami opisujemy w artykule DevOps czy DevSecOps.
- Platforma i doświadczenie deweloperów — samoobsługa środowisk i pipeline’ów, dokumentacja i to, jak duże obciążenie poznawcze system dostarczania nakłada na zespoły produktowe.
Platform engineering zasługuje na osobną uwagę. Według badań DORA z 2025 roku 90% organizacji deklaruje korzystanie z wewnętrznej platformy deweloperskiej, a 76% ma dedykowane zespoły platformowe. Raport z 2024 roku pokazał, że takie platformy zwiększają produktywność jednostek i wyniki organizacji, ale mogą też obniżać stabilność i przepustowość zmian, jeśli wdraża się je bez dbałości o niezależność deweloperów. Innymi słowy: posiadanie platformy nie jest poziomem dojrzałości — liczy się to, jak zespoły jej doświadczają. Szerzej opisujemy tę dyscyplinę w przewodniku po inżynierii platform.
Jak przeprowadzić samoocenę według checklisty?
Poniższa checklista zawiera 28 pytań tak/nie — po cztery na wymiar, po jednym dla każdego poziomu od 2 do 5. Poziom 1 jest domyślny i nie wymaga pytania. Odpowiadaj za organizację taką, jaka działa dziś, a nie taką, jaką opisuje prezentacja strategiczna. Jeśli odpowiedź brzmi „tak w części zespołów”, traktuj ją jako „nie”, chyba że dotyczy zespołów, które dostarczają większość zmian krytycznych dla biznesu.
| Wymiar | Poziom 2: powtarzalny | Poziom 3: ustandaryzowany | Poziom 4: mierzony | Poziom 5: optymalizujący |
|---|---|---|---|---|
| Kultura | Rozwój i operacje mają wspólny kanał i backlog problemów produkcyjnych | Po każdym poważnym incydencie jest postmortem bez szukania winnych, a działania są śledzone | Zespoły odpowiadają za usługi od początku do końca, z SLO uzgodnionymi z produktem | Eksperymenty usprawniające są planowane co kwartał i rozliczane |
| CI/CD | Każdy commit uruchamia automatyczny build i testy jednostkowe | Większość zespołów używa jednego standardowego pipeline’u; wdrożenia na produkcję są skryptowe | Krótko żyjące gałęzie; wdrożenia na produkcję co najmniej raz w tygodniu, z automatycznym wycofaniem | Wdrożenia na żądanie z wydaniami kanarkowymi lub flagami funkcji |
| Infrastruktura jako kod | Infrastruktura części środowisk jest w kontroli wersji | Wszystkie środowiska powstają z kodu; rozjazd konfiguracji jest wykrywany | Środowiska tymczasowe powstają automatycznie dla każdej zmiany | Policy as code sprawdza koszty i zgodność przy każdej zmianie infrastruktury |
| Testy | Testy jednostkowe krytycznych modułów działają w pipeline | Automatyczne testy regresji blokują każde scalenie | Niestabilne testy są śledzone i naprawiane; bramki jakości mają uzgodnione progi | Testy kontraktowe i eksperymenty odporności działają w sposób ciągły |
| Obserwowalność | Scentralizowane logi i podstawowe alerty dostępności | Powiązane logi, metryki i ślady; runbooki dla dyżurnych | Alerty oparte na SLO i objawach dla użytkowników; metryki DORA zbierane automatycznie | Znane typy awarii są naprawiane automatycznie; trendy incydentów zasilają roadmapę |
| Bezpieczeństwo | Skanowanie zależności działa; brak sekretów w repozytoriach | SAST i skanowanie zależności blokują pipeline powyżej ustalonych progów; menedżer sekretów w użyciu | Dla każdego buildu powstaje SBOM; skanowanie kontenerów i IaC | Pipeline generuje dowody pochodzenia artefaktów i ciągłej zgodności |
| Platforma | Wspólne skrypty i dokumentacja typowych zadań | Zespół platformowy oferuje samoobsługowe środowiska i pipeline’y | Platforma ma roadmapę, informację zwrotną od użytkowników i metryki adopcji | Nowa usługa trafia na produkcję przez samoobsługę, bez zgłoszeń |
Przeprowadź ocenę jako warsztat, a nie ankietę. Zaproś przedstawicieli każdej grupy, która dotyka dostarczania — zespołów produktowych, operacji lub SRE, QA, bezpieczeństwa i zespołu platformowego — i wymagaj dowodu dla każdego „tak”: definicji pipeline’u, dashboardu, dokumentu z postmortemu. Rozbieżności to najcenniejszy wynik. Gdy zespół platformowy odpowiada „tak”, a zespół produktowy „nie” na to samo pytanie, znalazłeś lukę między tym, co istnieje, a tym, czego się naprawdę używa.
Sprawdzony przebieg takiego warsztatu mieści się w jednym dniu roboczym. Pierwsza godzina to uzgodnienie zakresu: które strumienie wartości oceniamy i kto za nie odpowiada. Kolejne trzy–cztery godziny to przejście przez 28 pytań, wymiar po wymiarze, z dowodami pokazywanymi na ekranie. Ostatnia godzina to omówienie rozbieżności i wybór dwóch wymiarów do poprawy w najbliższym kwartale. Warsztat prowadzi osoba, która nie odpowiada za żaden z ocenianych obszarów — inaczej rozmowa szybko zamienia się w obronę własnych decyzji.
Zapisz nie tylko odpowiedzi, ale też uzasadnienia i dowody. Przy kolejnej ocenie, za pół roku lub rok, porównasz nie tylko wyniki, ale też to, czy zmieniły się fakty, na których się opierały. To chroni przed sytuacją, w której wynik rośnie tylko dlatego, że zmienili się oceniający albo ich interpretacja pytań.
Jeśli organizacja ma kilka niezależnych obszarów produktowych, przeprowadź ocenę osobno dla każdego z nich. Różnice między obszarami są często większe niż różnice między wymiarami w jednym obszarze — i wskazują, gdzie warto przenosić sprawdzone praktyki wewnątrz firmy, zamiast szukać ich na zewnątrz.
Jak policzyć wynik samooceny?
Punktacja opiera się na dwóch zasadach, które chronią uczciwość wyniku.
Zasada 1: poziomy są stopniowane. Liczysz tylko kolejne odpowiedzi „tak”, zaczynając od poziomu 2. „Tak” na poziomie 4 się nie liczy, jeśli na poziomie 3 jest „nie”. Wynik wymiaru to 1 plus liczba kolejnych odpowiedzi „tak”, więc mieści się w przedziale od 1 do 5. Ta zasada odzwierciedla praktykę: środowiska tymczasowe zbudowane na ręcznie skonfigurowanej produkcji to nie jest infrastruktura poziomu 4.
Zasada 2: najsłabsze ogniwo ogranicza całość. Poziom dojrzałości organizacji to średnia z siedmiu wymiarów, ale nie wyższa niż o jeden poziom powyżej najsłabszego wymiaru. System dostarczania jest tak szybki i bezpieczny, jak jego najwolniejsza część.
Oto przykład oparty na profilu, który często widzimy w rosnących firmach SaaS:
| Wymiar | Odpowiedzi (P2 / P3 / P4 / P5) | Wynik |
|---|---|---|
| Kultura | tak / tak / nie / nie | 3 |
| CI/CD | tak / tak / tak / nie | 4 |
| Infrastruktura jako kod | tak / nie / tak / nie | 2 |
| Testy | tak / nie / nie / nie | 2 |
| Obserwowalność | tak / tak / nie / nie | 3 |
| Bezpieczeństwo | tak / nie / nie / nie | 2 |
| Platforma | nie / nie / nie / nie | 1 |
Firma odpowiedziała „tak” na 11 z 28 pytań. Wyniki po zastosowaniu stopniowania dają łącznie 17 punktów, czyli średnio 2,43. Najsłabszy wymiar, platforma, ma wynik 1, co ogranicza poziom całości do 2. Organizacja jest na poziomie 2, mimo że jej CI/CD jest na poziomie 4.
Przykład pokazuje, dlaczego obie zasady są potrzebne. Bez stopniowania infrastruktura dostałaby wyższą ocenę dzięki środowiskom tymczasowym tworzonym na ręcznie zbudowanej produkcji. Bez ograniczenia firma raportowałaby średnią bliską 2,5 i pipeline poziomu 4, a zarząd usłyszałby „jesteśmy prawie na poziomie 3”. W rzeczywistości szybki pipeline dostarcza zmiany testowane głównie ręcznie i skanowane tylko pod kątem podatnych zależności, a każda nowa usługa wymaga zgłoszeń do trzech zespołów.
Priorytety wynikają wprost z wyniku: najpierw platforma (1 → 2), potem testy i bezpieczeństwo (2 → 3), bo pipeline poziomu 4 zasilający kontrole jakości i bezpieczeństwa poziomu 2 głównie przyspiesza dostarczanie błędów. To zgodne z tym, co raport DORA z 2024 roku napisał w kontekście AI: fundamenty, takie jak małe partie zmian i solidne testy, pozostają kluczowe.
Jak benchmarki DORA mają się do poziomów dojrzałości?
Poziomy dojrzałości opisują zdolności, klastry DORA — wyniki. Są ze sobą skorelowane, ale nie odpowiadają sobie dokładnie, a każde przyporządkowanie — także nasze poniżej — jest heurystyką, a nie wynikiem badań DORA. Używamy go do weryfikacji samooceny: jeśli zespół ocenia się na poziom 4, a wdraża raz w miesiącu przy 40% nieudanych zmian, samoocena jest błędna.
| Poziom dojrzałości | Typowy profil DORA (na podstawie klastrów z 2024 roku) | Sygnały zawyżonej oceny |
|---|---|---|
| 1. Doraźny | Niski: miesiące realizacji zmiany, wdrożenia raz w miesiącu lub rzadziej, przywrócenie w tygodniach | Wydania wymagają „weekendu wydaniowego” |
| 2. Powtarzalny | Niski do średniego: wdrożenia od co miesiąc do co tydzień | Każdy zespół wdraża inaczej; hotfixy omijają pipeline |
| 3. Ustandaryzowany | Średni do wysokiego: wdrożenia od co tydzień do codziennie | Pipeline jest standardowy, ale ręczne akceptacje trwają dniami |
| 4. Mierzony | Wysoki do elitarnego: realizacja zmiany poniżej tygodnia, przywrócenie w mniej niż dzień | Metryki DORA istnieją, ale pochodzą z ankiet, a nie z systemów |
| 5. Optymalizujący | Elitarny: wdrożenia na żądanie, realizacja zmiany poniżej dnia, przywrócenie w mniej niż godzinę | Szybkość jest wysoka, ale odsetek wdrożeń naprawczych rośnie |
Mierz metryki dla każdej usługi lub strumienia wartości, a nie jako średnią firmy. Średnia ukrywa dokładnie to, czego szukasz: usługę płatności wdrażaną raz na kwartał obok strony marketingowej wdrażanej co godzinę. Śledź też odsetek wdrożeń naprawczych obok odsetka nieudanych zmian. Zespół może utrzymywać niski odsetek nieudanych zmian, oznaczając pilne poprawki jako „pracę planowaną” — rework rate to ujawnia.
Uzasadnienie biznesowe tych metryk — jak krótszy czas realizacji i mniej nieudanych zmian przekładają się na przychody i koszty — opisujemy w artykule o biznesowej wartości DevOps i metrykach DORA.
Jak wygląda mapa przejścia z poziomu na poziom?
Każde przejście ma inny środek ciężkości. Próba stosowania praktyk poziomu 4 na poziomie 1 to jeden z najdroższych błędów transformacji DevOps.
Z poziomu 1 na 2: powtarzalność. Umieść cały kod i skrypty wdrożeniowe w kontroli wersji. Zautomatyzuj build i testy jednostkowe dla każdego commita w najbardziej krytycznych usługach. Scentralizuj logi i ustaw podstawowe alerty. Opisz, jak wygląda wydanie, a potem je oskryptuj. Celem jest usunięcie pojedynczych punktów awarii w postaci ludzi, a nie zakup platformy.
Z poziomu 2 na 3: standaryzacja. Stwórz jeden szablon pipeline’u, który obejmie większość usług, i spraw, by był najłatwiejszą opcją. Przenieś wszystkie środowiska do infrastruktury jako kod i zakończ ręczne zmiany na produkcji. Zbuduj automatyczny zestaw testów regresji blokujący scalanie. Dodaj do pipeline’u skanowanie zależności i statyczną analizę bezpieczeństwa. Wprowadź postmortemy bez szukania winnych. Zwykle na tym etapie mały zespół platformowy zaczyna się zwracać, bo standaryzacja to produkt, który ktoś musi prowadzić.
Z poziomu 3 na 4: pomiar i odpowiedzialność. Zdefiniuj z właścicielami produktu SLO dla usług widocznych dla użytkowników i alertuj na ich podstawie. Zbieraj metryki DORA automatycznie z kontroli wersji, pipeline’u i systemu incydentów. Przenieś odpowiedzialność tak, by zespoły utrzymywały to, co budują. Prowadź platformę jak produkt — z użytkownikami, roadmapą i metrykami adopcji. Generuj SBOM dla każdego buildu.
Z poziomu 4 na 5: optymalizacja. Wprowadź stopniowe udostępnianie z wydaniami kanarkowymi i flagami funkcji. Zautomatyzuj naprawę powtarzających się awarii. Prowadź eksperymenty odporności. Generuj dowody zgodności w pipeline. Planuj eksperymenty usprawniające co kwartał i mierz ich wpływ na metryki dostarczania i dobrostanu.
Ile to trwa? W naszych projektach podniesienie jednego wymiaru o jeden poziom zajmuje zwykle jeden do dwóch kwartałów skoncentrowanej pracy. Przejście całej organizacji na wyższy poziom trwa zazwyczaj rok lub dłużej, bo tempo wyznaczają najwolniejsze wymiary — często kultura, testy i bezpieczeństwo. Praktyczna zasada: pracuj jednocześnie nad najwyżej dwoma wymiarami, zaczynając od tego, który ogranicza Twój wynik.
Jakie błędy sprawiają, że ocena dojrzałości jest bezużyteczna?
Większość nieudanych ocen zawodzi w przewidywalny sposób:
- Ocena narzędzi zamiast praktyk. „Używamy Terraforma” to nie to samo co „wszystkie środowiska powstają z kodu”. Pytaj o dowody użycia, nie o licencje.
- Jedna grupa odpowiada za wszystkich. Zespół platformowy ocenia platformę, bezpieczeństwo ocenia bezpieczeństwo — i każdy wymiar wygląda na dojrzały od środka. Mieszaj perspektywy.
- Uśrednianie zespołów. Poziom 3 dla całej firmy może ukrywać jeden krytyczny zespół na poziomie 1. Oceniaj według strumieni wartości lub obszarów produktowych, a dopiero potem agreguj.
- Poziom jako cel. Gdy premie zależą od wyniku dojrzałości, wynik rośnie, a dostarczanie nie. Ocena ma być diagnostyczna.
- Pomijanie strony ludzkiej. Profile DORA z 2025 roku nie bez powodu łączą metryki dostarczania z wypaleniem i tarciem w zespole. Zespół, który wdraża codziennie i się wypala, nie jest dojrzały — zadłuża się u przyszłości.
- Jednorazowa ocena. Pojedyncza ocena to migawka. Wartość pojawia się przy powtarzaniu jej co sześć–dwanaście miesięcy z tymi samymi pytaniami i porównywaniu wyników.
Przydatny test: jeśli ocena nie przyniosła co najmniej jednego niewygodnego wniosku, prawdopodobnie nie była uczciwa.
Jak AI zmienia dojrzałość DevOps w 2026 roku?
Asystenci AI do programowania zmienili kontekst każdej oceny dojrzałości. Według raportu DORA z 2025 roku 90% respondentów używa AI w pracy, a ponad 80% uważa, że zwiększyło to ich produktywność, choć 30% deklaruje niewielkie zaufanie lub brak zaufania do kodu generowanego przez AI.
Główny wniosek tego raportu brzmi: AI działa jak wzmacniacz — powiększa istniejące mocne i słabe strony organizacji. Już raport z 2024 roku wykazał, że adopcja AI poprawia produktywność jednostek, poczucie flow i satysfakcję z pracy, ale negatywnie wpływa na przepustowość i stabilność dostarczania oprogramowania.
Dla modelu dojrzałości wniosek jest prosty. AI zwiększa liczbę zmian wchodzących do systemu dostarczania. Na poziomie 1 lub 2 oznacza to więcej nieprzetestowanego kodu trafiającego do ręcznych procesów wydawniczych, więcej poprawek i więcej incydentów. Od poziomu 3 wzwyż, gdzie testy automatyczne, skanowanie bezpieczeństwa i ustandaryzowane pipeline’y działają jak barierki, ten sam wzrost liczby zmian może przełożyć się na szybsze dostarczanie. Raport z 2025 roku wykazał też bezpośrednią korelację między wysoką jakością wewnętrznej platformy a zdolnością organizacji do wykorzystania wartości AI.
W praktyce rekomendujemy dodanie do warsztatu dwóch pytań, bez zmiany punktacji: Czy zmiany generowane przez AI przechodzą przez te same bramki jakości i bezpieczeństwa co każda inna zmiana? oraz Czy mierzymy wpływ narzędzi AI na odsetek wdrożeń naprawczych, a nie tylko na szybkość deweloperów? Jeśli obie odpowiedzi brzmią „nie”, mapa dojrzałości powinna stawiać testy i bezpieczeństwo przed dalszym wdrażaniem AI.
Kiedy warto sięgnąć po zewnętrznych inżynierów DevOps?
Większość luk w dojrzałości nie wynika z braku wiedzy o tym, jak powinno być. Wynika z braku przepustowości: ci sami inżynierowie, którzy powinni budować standardowy pipeline, są zajęci utrzymywaniem obecnego. Wsparcie zewnętrzne pomaga w trzech sytuacjach.
Gdy najsłabszy wymiar wymaga kompetencji, których nie masz. Platform engineering, obserwowalność i DevSecOps to specjalizacje. Rekrutacja doświadczonego inżyniera platformy może trwać miesiące, a mapa dojrzałości czeka. Doświadczeni inżynierowie DevOps dołączający do zespołu na czas transformacji mogą zbudować fundamenty i przekazać wiedzę.
Gdy przejście między poziomami wymaga skumulowanej pracy. Przejście z poziomu 2 na 3 oznacza dużo jednorazowego wysiłku: migrację środowisk do infrastruktury jako kod, budowę szablonu pipeline’u, wdrożenie zespołów. To obciążenie rośnie, a potem spada, więc naturalnie pasuje do augmentacji zespołu DevOps, a nie do stałych etatów.
Gdy potrzebujesz niezależnej oceny. Wewnętrzne oceny bywają hojne w obszarach, za które odpowiadają oceniający. Zewnętrzne spojrzenie, skalibrowane na wielu organizacjach, sprawia, że punkt wyjścia jest wiarygodny dla zarządu i zespołów.
Nasz przewodnik po DevOps staff augmentation opisuje, jak ułożyć taką współpracę, a artykuł o budowie DevOps Center of Excellence — jak utrzymać kompetencje w firmie po zakończeniu transformacji.
Najważniejsze wnioski:
- Dojrzałość to cecha całego systemu dostarczania, a nie narzędzia. Oceniaj siedem wymiarów tą samą miarą.
- Stosuj stopniowaną punktację i ograniczenie najsłabszym ogniwem. W naszym przykładzie pipeline poziomu 4 działał w organizacji poziomu 2.
- Potwierdzaj zdolności wynikami. Pięć metryk DORA — w tym dodany w 2024 roku odsetek wdrożeń naprawczych — pokazuje, czy samoocena jest realistyczna.
- Przechodź o jeden poziom naraz, po dwa wymiary jednocześnie, zaczynając od wymiaru, który ogranicza wynik.
- Traktuj AI jak wzmacniacz. Przyspiesza dojrzałe systemy dostarczania i obnaża słabe.
W ARDURA Consulting od ponad 10 lat wspieramy organizacje inżynierskie w Polsce, Europie, na Bliskim Wschodzie i w USA — również inżynierami DevOps, SRE i platform engineering pracującymi w zespołach klientów. Jeśli potrzebujesz niezależnej oceny dojrzałości albo inżynierów, którzy domkną lukę w Twoim najsłabszym wymiarze, porozmawiaj z naszym zespołem.