Mierz system dostarczania

Zacznij od potrzebnej decyzji

Zespół chce ustalić, czy AI poprawia dostarczanie. Liczenie wygenerowanych linii odpowiada na inne pytanie. Określ przydatny wynik i warunki jakości przed wyborem miary.

Dla fikcyjnej usługi eksportu celem jest niezawodne dostarczanie zaakceptowanych zmian przy mniejszym łącznym nakładzie. Zapisuj przygotowanie, implementację, przegląd, poprawki i oczekiwanie. Uwzględnij zmiany nieudane i porzucone.

Użyj jednej usługi z jasnymi granicami. Połączenie eksperymentalnej strony i krytycznej usługi płatniczej może dać liczbę, która nie wyjaśnia żadnej z nich. Opisz kontekst przed porównaniem okresów lub zespołów.

Używaj aktualnych definicji

Obecny model dostarczania DORA obejmuje pięć miar. Dotyczą wyników dostarczania, nie wartości każdej funkcji ani wkładu jednostki. Definicje miar DORA.

Dashboard może używać innej definicji. Przeczytaj ją przed interpretacją wyniku. Aktualna dokumentacja wdrożeń Taiga opisuje cztery raportowane miary wyliczane z zapisów wdrożeń dostawcy. Miara przywrócenia korzysta z kolejnego udanego wdrożenia. Nie jest pełnym rejestrem każdego incydentu produkcyjnego. Definicje Taiga.

Sprawdź fikcyjną sekwencję zmian

Załóżmy, że usługa ma dwanaście wdrożeń w miesiącu. Osiem dostarcza planowane zmiany. Cztery naprawiają problemy wcześniejszych wydań. Liczba wynosi dwanaście, ale skład ma znaczenie.

W kolejnym miesiącu zespół wykonuje dziesięć wdrożeń: dziewięć planowanych zmian i jedną naprawę. Mniej wdrożeń może oznaczać więcej przydatnej pracy. Liczby ilustrują interpretację; nie są benchmarkiem wydajności.

Sprawdź też rozkład. Długie oczekiwanie na jeden przegląd może zniknąć w średniej. Pomiar przywrócenia po pojedynczej awarii jest słabym dowodem przyszłej niezawodności. Podawaj liczbę obserwacji i istotne wyjątki.

Łącz przepływ z konsekwencjami

Sygnały usługi pozwalają sprawdzić, czy zmiany dostarczania wpływają na użytkowników. Szybszy pipeline nie wystarcza, jeśli eksport częściej zawodzi. Użyj odpowiedniego SLO lub innej jasno zdefiniowanej miary wyniku. Zalecenia dotyczące SLO.

Nakład na przegląd i poprawki pomaga wyjaśnić wynik. Jeśli AI skraca implementację, ale tworzy duże diffy, ograniczeniem może stać się przegląd. Jeśli uzyskanie środowiska trwa dni, szybsze kodowanie może niewiele skrócić czas dostarczenia.

Wybierz jedno usprawnienie odpowiadające zaobserwowanemu ograniczeniu. Na przykład zapewnij wspierane środowisko testowe lub zmniejsz rozmiar zmiany. Określ uzupełniającą miarę jakości, która wykryje pozorne przyspieszenie wynikające ze słabszych kontroli.

Zachowaj użyteczność pomiaru

Unikaj rankingów osób na podstawie liczby PR lub wygenerowanego kodu. Takie miary mogą nagradzać sztuczny podział pracy, unikanie trudnego utrzymania lub przenoszenie przeglądu na kolegów.

Przejrzyj wynik z osobami odpowiedzialnymi za całą usługę. Zapisz zmiany narzędzia, rodzaju pracy, zespołu i środowiska. Porównanie przed i po traktuj jako dowód z ograniczeniami, nie automatyczne potwierdzenie przyczynowości.

Celem jest lepsza kolejna decyzja. Mały wiarygodny pomiar prowadzący do zweryfikowanej poprawy jest bardziej przydatny niż duży dashboard bez uzgodnionego znaczenia.

Ćwicz na dziesięciu zmianach

Ten osobny fikcyjny zbiór obejmuje dziesięć planowanych zmian. Wszystkie godziny są w UTC w podanym dniu. Puste pole poprawki oznacza brak zapisanej poprawki w tym zbiorze.

Porównaj czas od gotowego kodu do rozpoczęcia przeglądu, a następnie od akceptacji do wydania. Wskaż najdłuższe widoczne oczekiwanie. Zbadaj przyczynę przed uznaniem go za zbędne. Te znaczniki czasu nie mierzą aktywnego nakładu ani początku incydentu. Samo wydanie poprawki nie określa failed deployment recovery time.

Pobierz fikcyjny zbiór danych (CSV)