# Czym są metryki DORA i jak mierzyć szybkość dostarczania

URL: https://upstreamapi.com/pl/journal/czym-sa-metryki-dora
Type: blog
Locale: pl
Published: 2026-10-03
Updated: 2026-10-03

---

> Metryki DORA to pięć narzędzi do pomiaru szybkości dostarczania i stabilności wdrożeń. Wiedz, co mierzyć i jak unikać pułapek, które czekają na zespoły optymalizujące liczby zamiast wartości.

## Czym są metryki DORA i jak mierzyć szybkość dostarczania

Metryki DORA to pięć miar wydajności dostarczania oprogramowania: lead time, deployment frequency, failed deployment recovery time, change fail rate i deployment rework rate. Pierwsze trzy opisują przepustowość, ostatnie dwie opisują niestabilność. Razem pokazują, jak szybko zmiany trafiają do produkcji i jak często te zmiany szkodzą. Używane dobrze wskazują na wąskie gardło. Używane źle stają się raport wydajności, w którym zespół uczy się grać.

## Skąd biorą się te liczby i dlaczego ta terminologia się przyjęła

Lider platformy siedzi na kwartalnym przegląd. CTO pyta jedno pytanie: czy szybciej wysyłamy niż rok temu i czy mniej psujemy? Bez wspólnego słownika odpowiedź to stos anekdot. Metryki DORA istnieją, aby zamienić anekdoty na cztery, pięć liczb, które można ściągnąć z systemów, które już uruchamiasz.

Nazwa pochodzi od DevOps Research and Assessment, programu badawczego, który spędził lata na ankietowaniu zespołów inżynierskich i korelacji ich praktyk dostarczania z wynikami organizacyjnymi. Jest teraz częścią Google Cloud, a ustalenia publikowane są co roku w programie badawczym DORA. Książka Accelerate spopularyzowała pierwotne cztery. Framework został od tego czasu zrewidowany i ta rewizja ma więcej znaczenia niż większość artykułów blogowych przyznaje.

Tu znika się punkt: metryki nigdy nie były przeznaczone jako tablica wyników. Wyszły z ustalenia statystycznego. Zespoły, które uzyskały dobre wyniki w szybkości, uzyskały również dobre wyniki w stabilności. Szybkość i bezpieczeństwo nie były kompromisem, pojawiały się razem. To stwierdzenie o korelacji między wieloma zespołami, a nie cel dla twojego.

## Pięć metryk wyjaśnionych jak pracujący inżynier SRE by je wyjaśnił

Aktualne definicje w oficjalnym przewodniku metryk DORA dzielą się na dwie grupy. Czytaj je z konkretnym serwisem na myśli, bo każda definicja rozpada się, jeśli zastosujesz ją do "całej firmy".

**Lead time.** Czas od commita do tego, że ten commit działa w produkcji. Nie od momentu otwarcia ticketa, nie od momentu zaakceptowania pull requesta. Od commita do prod. Jeśli twój pipeline trwa czterdzieści minut, a pociąg wydania odchodzi we czwartki, twój lead time jest zdominowany przez czwartek.

**Deployment frequency.** Jak często wysyłasz do produkcji. Możesz liczyć wdrożenia w ciągu okresu lub mierzyć lukę między nimi. Serwis, który wdraża jedenaście razy dziennie, i serwis wdrażający raz na miesiąc, to różne zwierzęta i uśrednianie ich ukrywa obie.

**Failed deployment recovery time.** Jak długo trwa odzyskanie, gdy wdrożenie powoduje problem, który wymaga interwencji. To się kiedyś nazywało mean time to restore, a zmiana nazwy jest celowa. Dotyczy tylko incydentów spowodowanych twoją zmianą, nie awarii dostawcy chmury we wtorek.

**Change fail rate.** Odsetek wdrożeń wymagających bezpośredniej interwencji później: rollback, hotfix, szybki forward fix. Dziesięć wdrożeń, dwa z nich przywrócone, odsetek niepowodzeń zmian to dwadzieścia procent.

**Deployment rework rate.** Odsetek wdrożeń, które są niezaplanowane, wyzwolone incydentem produkcyjnym zamiast pracą drogową. To najnowsze uzupełnienie i wychwytuje coś, co change fail rate pропaści: zespół, który nigdy się nie cofa, ale spędza połowę tygodnia wysyłając emergency patche.

![Stopwatch resting on a server rack panel, a picture of lead time](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/02c796-i1.webp)

## Przepustowość contra niestabilność: dlaczego nigdy nie czytasz jednej metryki samodzielnie

Pierwsze trzy metryki to przepustowość. Ostatnie dwie to niestabilność. Grupowanie to cały punkt.

Jeśli obserwujesz tylko przepustowość, będziesz celebrować zespół, który wdraża czterdzieści razy dziennie i cicho przywraca ćwierć z nich. Jeśli obserwujesz tylko niestabilność, nagrodzisz zespół wysyłający raz na miesiąc z nienaganny rekordem, bo nikt nic nie zmienia. Każda metryka ma tani sposób na poprawę, która pogarsza system.

Częstotliwość wdrożeń rośnie, gdy podzielisz wdrożenie na pięć pustych wdrożeń. Change fail rate spada, gdy przestajesz liczyć hotfixy jako niepowodzenia. Lead time kurczy się, gdy przedefiniujesz początek zegara. To prawo Goodharta robi to, co zawsze: gdy miara staje się celem, przestaje być dobrą miarą. Oficjalny przewodnik wymieniał to jako pierwsze ostrzeżenie, i to ten, który najbardziej kąsa.

Więc reguła pracy to pary. Czytaj lead time obok change fail rate. Czytaj deployment frequency obok rework rate. Ruch w jednym kierunku bez pasującego słowa w drugim to sygnał do bliższego przyjrzenia się, nie wygrana do ogłoszenia.

Benchmarki krążą w każdej talii sprzedawcy i są pułapką. Zgłoszony wzór z niedawnych raportów DORA jest konsekwentny w kształcie: najsilniejsza grupa zespołów wdraża na żądanie, z lead time poniżej dnia i odzyskuje się z nieudanego wdrożenia w poniżej godziny. Najwolniejsza grupa siedzi w zakresie tygodni do miesięcy na obu.

Te cyfry są przydatne do jednej rzeczy: kalibracji intuicji na temat tego, co jest możliwe. Są złą marką jako cele. Serwis płatniczy z obowiązkową bramką audytu nie będzie pasować do witryny marketingowej i nie powinien próbować. Oficjalne wytyczne jasno mówią, że powinieneś porównywać tylko podobne aplikacje lub serwisy, i że powinieneś dążyć do poprawy względem twojnego własnego punktu odniesienia, a nie konkurencji między zespołami.

Zacznij od swojej mediany. Zmierz ją przez miesiąc zanim ustalasz jakiś cel. Pierwsza liczba jest prawie zawsze żenująca i to jest w porządku. Punkt odniesienia, który cię żenuje, to punkt odniesienia, któremu naprawdę ufasz.

## Jak to zmierzyć bez budowania platformy danych

Większa część zespołów nadbudowuje to. Nie potrzebujesz magazynu. Potrzebujesz czterech znaczników czasu i jedną flagę.

Znaczniki czasu: commit scalony do gałęzi głównej, build zakończony, wdrożenie rozpoczęte w produkcji, wdrożenie zakończone. Flaga: czy wdrożenie zostało później przywrócone, hotfixed, lub następnie niezaplanowane wdrożenie w określonym oknie.

Tu jest minimalny szkic w TypeScript. Bierze listę rekordów wdrożenia i zwraca liczby, które mają znaczenie.

`type Deploy = {
  service: string;
  committedAt: Date;
  deployedAt: Date;
  failed: boolean;       // reverted, hotfixed, or manual intervention
  unplanned: boolean;    // triggered by an incident, not by roadmap work
  recoveredAt?: Date;    // set when failed is true
};

const median = (xs: number[]) => {
  const s = [...xs].sort((a, b) => a - b);
  return s.length ? s[Math.floor(s.length / 2)] : 0;
};

export function doraSummary(deploys: Deploy[], days: number) {
  const leadHours = deploys.map(
    d => (d.deployedAt.getTime() - d.committedAt.getTime()) / 36e5,
  );
  const failures = deploys.filter(d => d.failed);
  const recoveryMins = failures
    .filter(d => d.recoveredAt)
    .map(d => (d.recoveredAt!.getTime() - d.deployedAt.getTime()) / 6e4);

  return {
    leadTimeHoursP50: median(leadHours),
    deploysPerDay: deploys.length / days,
    changeFailRate: failures.length / Math.max(deploys.length, 1),
    recoveryMinutesP50: median(recoveryMins),
    reworkRate: deploys.filter(d => d.unplanned).length / Math.max(deploys.length, 1),
  };
}`Dwie decyzje w tym snipecie noszą wagę. Po pierwsze używa mediany, nie średniej. Jeden zły tydzień z trzydniowym odzyskiwaniem zniszczy średnią i powie ci nic o typowym wtorku. Po drugie, to liczy wszystko na serwis. Zagreguj do zespołu lub departamentu dopiero po sprawdzeniu serwisów pod spodem.

Trudna część to nie kod. Trudna część to flaga `failed`. Ktoś musi zdecydować, co liczy się jako niepowodzenie, zapisać to i stosować to w ten sam sposób za każdym razem. Jeśli twój narzędzie do śledzenia incydentów łączy incydenty z wdrożeniem, które je spowodowało, dostajesz to prawie za darmo. Jeśli nie, zacznij tam.

![Industrial breaker panel with one red lever pulled, a picture of a failed change](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/f8caad-i2.webp)

Pytanie narzędziowe pojawia się po pytaniu o dane. Już posiadasz większość surowych danych. Twój Git host ma czasy commitów. Twój CI ma build i deploy eventy. Twoje narzędzie do śledzenia incydentów ma niepowodzenia. Praca to łączenie ich na wspólnym identyfikatorze wdrożenia.

Platformy obserwacyjności są naturalnym miejscem do nałożenia znaczników wdrożenia na szybkość błędów i opóźnień, abyś mógł zobaczyć, które wdrożenie poprzedzało każdy skok.

Jeśli wolisz trzymać stos otwarty i auto-hostowany, warstwa dashboardu nad twoją własną bazą danych zdarzeń wdrożenia wykonuje tę samą pracę z niższym kosztem, więcej hydrauliki z twojej strony.

Jest też kategoria narzędzi, która czyta twoje repozytoria i historię dostarczania i powierzchni ryzyka, takie jak hotspoty, gdzie zmienność kodu i przeszłe defekty się skupiają. To nie zastąpi czterech znaczników czasu, ale wyjaśnia, dlaczego jeden serwis ma wysoką change fail rate, gdy jego sąsiedzi nie.

Ostrzeżenie na zakup czegokolwiek tutaj. Dashboard, który pokazuje liczby, to nie to samo co zespół, który na nich działać. Jeśli nikt nie odpowiada za schemat czasu odzyskiwania, zakup ładniejszego wykresu zmienia nic.

## Dźwignie, które rzeczywiście poruszają każdą liczbę

Metryki to diagnoza. Leczenie jest gdzie indziej i jest różne dla każdej.

Na lead time spójrz na czekanie, nie pracę. Wyciągnij tuzin ostatnich zmian i zaznacz, gdzie każda siedziała na biegu jałowym: czekając na recenzję, czekając na slot builda, czekając na okno wydania. W większości zespołów czas bezczynności przeważa czas kodowania wielokrotnie. Mniejsze pull requesty i oczekiwanie dotyczące poziomu usług przeglądu bijają każde strojenie pipeline'u.

Na deployment frequency dźwignia to rozmiar batcha. Mniejsze zmiany są łatwiejsze do przejrzenia, łatwiejsze do myślenia i łatwiejsze do przywrócenia. Development na pniu i feature flagi istnieją, aby pozwolić ci scal niezakończoną pracę bezpiecznie, co rozprzęga wdrażanie od wydawania.

Na change fail rate dźwignia to ile radius wybuchu możesz zobaczyć zanim to cała flota. Rollout, który eksponuje jeden procent ruchu, obserwuje szybkość błędów względem SLO, i zatrzymuje się na naruszeniu, zmienia to, co mogłoby być incydentem, w non-event. To luka między wdrożeniem, które się nie udało i zmianą, które się nie powiodły, że nikt poza zespołem nie zauważył.

Na czas odzyskiwania dźwignia to revert. Jeśli najszybsza naprawa to wycofanie, to czas odzyskiwania to jak szybko wykryjesz problem i jak szybko możesz nacisnąć guzik. Zautomatyzowanie reverta na naruszeniu progu obcina człowieka z pierwszych dziesięciu minut. O trzeciej nad ranem to ma większe znaczenie niż jakikolwiek runbook.

Na rework rate dźwignia to upstream. Wysoki numer oznacza, że incydenty generują wdrożenia. Sprawdź, które serwisy produkują emergency patche, i czytaj ich post-mortemy jako zbiór zamiast jeden po drugim.

## Co się zmienia, gdy AI pisze więcej twojego kodu

Nedawne badania DORA wskazują na coś nieprzyjemnego dla każdego sprzedającego asystenta kodowania. Asystenci przyspieszają zadania niskiego poziomu, ale zyski nie wyraźnie przeszły do lead time czy change fail rate. Więcej kodu napisanego na godzinę to nie to samo co więcej wartości dostarczonej na tydzień.

Jeśli cokolwiek, większa ilość wygenerowanych zmian naciska pressure na recenzję i na twój pipeline dostarczania. Większe batche szkodzą stabilności, a zdolność przeglądu nie skaluje się z szybkością pisania. Uważnie obserwuj swój change fail rate i rework rate w miesiące po tym, jak zespół przyjmie asystenta. Jeśli lead time spada, ale rework wspina się, nie się szybciej, przesunąłeś koszt.

![Notebook with hand-drawn trend charts for a team retrospective](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-10/30e093-i3.webp)

## Jak ich używać w retro bez łamania zespołu

Tu jest co działa w praktyce. Umieść trendy na ekranie za ostatni kwartał i zapytaj jedno pytanie: co tu się zmieniło i dlaczego? Nie pytaj kto. Cel to hipoteza o systemie, nie werdykt o osobie.

Trzy nawyki utrzymują liczby uczciwe.

Po pierwsze nigdy nie wkładaj ich do indywidualnych przeglądów wydajności. W momencie gdy miara przywiąże się do nazwy, ludzie optymalizują metrykę i twoje dane przestają opisywać rzeczywistość.

Po drugie, paruj każdą liczbę ze historią. Skok w czasie odzyskiwania to jeden incydent z nazwą i post-mortemem. Przeczytaj post-mortem zanim przeczytasz wykres.

Po trzecie zmień jedną rzecz na raz. Jeśli adoptujesz feature flagi, zmieniasz rozmiar pull requestów i automatyzujesz reverty w tym samym miesiącu, nigdy nie dowiesz się, która z nich ruszyła wskazówkę.

Pomiń slajd modelu dojrzałości, który sortuje twoją organizację w warstwy i wręcza trofeum. Warte wysiłku zamiast: jedna strona na serwis, aktualizowana miesięcznie, wymieniająca pięć liczb, poprzednią wartość miesiąca i jedno zdanie o tym, co się zmieniło.

Załóżmy, że miałeś dziewięćdziesiąt dni czystych danych na jednym serwisie i widziałeś change fail rate powoli wspinającą się podczas gdy deployment frequency pozostała płaska. Gdzie byś szukał najpierw: rozmiar zmian, jakość przeglądu, czy widoczność masz w rollout podczas gdy wciąż się mały? Twoja odpowiedź mówi więcej o twoim systemie dostarczania niż jakikolwiek benchmark.

## FAQ

### Jaka jest średnia wartość lead time dla dobrego zespołu?

Według raportów DORA, najlepsze zespoły osiągają lead time poniżej jednego dnia. Wiele zespołów stoi w zakresie dni do tygodni. Punkt to nie porównanie, ale pomiar własnego postępu i identyfikacja czekania zamiast pracy.

### Co powinno być mierzone jako failed deployment?

Failed deployment to wdrożenie, które wymaga rollback, hotfix lub szybkiej naprawy w drodze. Klucz to konsystentna definicja: jeśli twoje narzędzie do śledzenia incydentów łączy incydenty z wdrożeniami, możesz automatycznie określić to z dzienników.

### Czy mogę porównać metryki DORA między różnymi serwisami?

Nie bezpośrednio. Serwis płatniczy z wymaganymi auditami będzie miał inne liczby niż wewnętrzne narzędzie. Porównuj tylko podobne aplikacje lub używaj własnego serwisu jako baseline. To, co mierzy się to postęp, nie ranking.

### Jakie narzędzie powinniśmy wybrać do śledzenia metryk DORA?

Nie potrzebujesz specjalnego narzędzia. Cztery znaczniki czasu (commit, build finished, deployment started, deployment finished) plus flaga failed/unplanned wystarczą. Możesz zacząć od własnej bazy danych deployment eventów i dashboarda. Narzędzia jak Datadog czy Grafana pomagają w wizualizacji.

### Czy wysokie deployment frequency zawsze oznacza lepsze wyniki?

Nie. Wysoka deployment frequency bez niskego change fail rate oznacza, że wysyłasz więcej błędów. To prawo Goodharta: gdy miara staje się celem, przestaje być miarą. Czytaj zawsze deployment frequency obok change fail rate jako parę.

### Jak wpływ AI na metryki DORA?

Asystenci kodowania przyspieszają pisanie kodu, ale nie musi to zmienić lead time czy change fail rate. Może nawet zwiększyć rework rate, bo większa ilość kodu wymaga więcej przeglądu. Obserwuj swoje metryki uważnie przez trzy miesiące po wdrożeniu asystenta.

### Co zrobić, jeśli lead time jest długi, ale change fail rate niski?

Spójrz na czekanie, nie pracę. Zazwyczaj problem to bottleneck w recenzji, okno wydania, lub pipeline. Mniejsze pull requesty i wyraźne SLO dla czasu przeglądu zazwyczaj pomagają.

### Czy mogę używać metryk DORA do oceny indywidualnych inżynierów?

Nigdy. W momencie gdy miara przywiąże się do nazwy, zespół uczy się grać w metrykę zamiast poprawiać system. Metryki służą do diagnozowania systemu dostarczania, nie do oceny ludzi.