Měřte systém dodávky

Začněte rozhodnutím, které potřebujete udělat

Tým chce vědět, zda AI zlepšuje dodávku. Počítání vygenerovaných řádků odpovídá na jinou otázku. Před výběrem metriky definujte užitečný výsledek a podmínky kvality.

U fiktivní služby exportu je požadovaným výsledkem spolehlivá dodávka přijatých změn s menším celkovým úsilím. Zaznamenejte přípravu, implementaci, kontrolu, opravy a čekání. Zahrňte změny, které selhaly nebo byly opuštěny.

Použijte jednu službu s jasnou hranicí. Spojení experimentálního webu s kritickou platební službou může vytvořit číslo, které nevysvětluje ani jednu. Před porovnáním období nebo týmů popište kontext.

Používejte aktuální definice

Současný model dodávky DORA obsahuje pět metrik. Jejich rozsahem je výkonnost dodávky, nikoli hodnota každé funkce nebo přínos jednotlivce. Definice metrik DORA.

Přehled může používat jinou definici. Před výkladem výsledku si ji přečtěte. Současná dokumentace nasazování Taigy popisuje čtyři vykazované metriky odvozené ze záznamů nasazení poskytovatele. Její metrika obnovy používá následné úspěšné nasazení. Nejde o úplný záznam každého produkčního incidentu. Definice Taigy.

Prozkoumejte fiktivní posloupnost změn

Předpokládejme, že služba za měsíc provede dvanáct nasazení. Osm dodá plánované změny. Čtyři opravují problémy předchozích vydání. Počet je dvanáct, ale záleží na složení.

Další měsíc tým provede deset nasazení: devět plánovaných změn a jednu opravu. Méně nasazení může doprovázet více užitečné práce. Čísla ilustrují výklad; nejsou výkonnostním benchmarkem.

Prozkoumejte také rozdělení. Jedno dlouhé čekání na kontrolu může zmizet v průměru. Měření obnovy z jediného selhání je slabým důkazem budoucí spolehlivosti. Uvádějte počet pozorování a významné výjimky.

Propojte tok s následky

Pomocí signálů služby ověřte, zda změny dodávky ovlivňují uživatele. Rychlejší pipeline nestačí, pokud exporty selhávají častěji. Použijte vhodné SLO nebo jinou jasně definovanou míru výsledku. Pokyny k SLO.

Úsilí na kontrolu a přepracování pomáhají vysvětlit výsledek. Pokud AI zkrátí implementaci, ale vytváří velké diffy, může být omezením kontrola. Pokud získání prostředí trvá dny, rychlejší programování může mít na celkovou dobu dodání malý vliv.

Vyberte jedno zlepšení, které řeší pozorované omezení. Například nabídněte podporované testovací prostředí nebo zmenšete změnu. Definujte vyvažující metriku kvality, aby tým odhalil zdánlivé zrychlení způsobené slabšími kontrolami.

Udržujte měření užitečné

Nevytvářejte pořadí jednotlivců podle počtu PR nebo vygenerovaného kódu. Tyto míry mohou odměňovat umělé dělení práce, vyhýbání se obtížné údržbě nebo přesouvání kontrolní práce na kolegy.

Výsledek proberte s lidmi odpovědnými za celou službu. Zaznamenejte změny nástroje, skladby práce, týmu a prostředí. Porovnání před a po berte jako důkaz s omezeními, nikoli automatický důkaz příčinné souvislosti.

Účelem je lepší další rozhodnutí. Malé důvěryhodné měření vedoucí k ověřenému zlepšení je užitečnější než rozsáhlý přehled bez dohodnutého významu.

Procvičte si deset změn

Tato samostatná fiktivní datová sada zaznamenává deset plánovaných změn. Všechny časy jsou UTC v uvedený den. Prázdné pole opravy znamená, že v této sadě nebyla oprava zaznamenána.

Porovnejte dobu od připraveného kódu do začátku kontroly a potom od přijetí do vydání. Určete nejdelší viditelné čekání. Než je označíte za zbytečné, prozkoumejte příčinu. Tyto časové údaje neměří aktivní úsilí ani neurčují začátek incidentu. Samotné opravné vydání nemůže prokázat dobu obnovy po neúspěšném nasazení.

Stáhnout fiktivní datovou sadu (CSV)