Merajte systém dodávania

Začnite rozhodnutím, ktoré potrebujete urobiť

Tím chce vedieť, či AI zlepšuje dodávanie. Počítanie vygenerovaných riadkov odpovedá na inú otázku. Pred výberom metriky definujte užitočný výsledok a podmienky kvality.

Pri fiktívnej exportnej službe je požadovaným výsledkom spoľahlivé dodávanie prijatých zmien s menším celkovým úsilím. Zaznamenávajte prípravu, implementáciu, kontrolu, opravy a čakanie. Zahrňte aj zmeny, ktoré zlyhali alebo boli zrušené.

Použite jednu službu s jasnou hranicou. Spojenie experimentálneho webu a kritickej platobnej služby môže vytvoriť číslo, ktoré nevysvetľuje ani jednu. Pred porovnávaním období alebo tímov opíšte kontext.

Používajte aktuálne definície

Aktuálny model dodávania DORA obsahuje päť metrík. Ich rozsahom je výkonnosť dodávania, nie hodnota každej funkcie ani príspevok jednotlivca. Definície metrík DORA.

Dashboard môže používať inú definíciu. Prečítajte si ju pred výkladom výsledku. Aktuálna dokumentácia nasadení Taiga opisuje štyri vykazované metriky odvodené zo záznamov nasadení poskytovateľa. Jej metrika obnovy používa nasledujúce úspešné nasadenie. Nie je to úplný záznam každého produkčného incidentu. Definície Taiga.

Preskúmajte fiktívnu postupnosť zmien

Predstavte si, že služba za mesiac vykoná dvanásť nasadení. Osem dodá plánované zmeny. Štyri opravia problémy skorších vydaní. Počet je dvanásť, ale záleží na jeho zložení.

V ďalšom mesiaci tím vykoná desať nasadení: deväť plánovaných zmien a jednu opravu. Menej nasadení môže súčasne znamenať viac užitočnej práce. Tieto čísla ilustrujú výklad; nie sú výkonnostným štandardom.

Preskúmajte aj rozdelenie hodnôt. Jedno dlhé čakanie na kontrolu sa môže skryť v priemere. Metrika obnovy z jediného zlyhania je slabým dôkazom budúcej spoľahlivosti. Uvádzajte počet pozorovaní a podstatné výnimky.

Spájajte tok s dôsledkami

Signálmi služby overte, či zmeny dodávania ovplyvňujú používateľov. Rýchlejšia pipeline nestačí, ak exporty zlyhávajú častejšie. Použite vhodné SLO alebo inú jasne definovanú metriku výsledku. Odporúčania pre SLO.

Náročnosť kontroly a opakované opravy pomáhajú vysvetliť výsledok. Ak AI skráti čas implementácie, ale vytvorí veľké diffy, kontrola sa môže stať obmedzením. Ak získanie prostredí trvá dni, rýchlejšie programovanie môže mať malý účinok na celkový čas dodávania.

Vyberte jedno zlepšenie, ktoré rieši pozorované obmedzenie. Napríklad poskytnite podporované testovacie prostredie alebo zmenšite zmenu. Definujte doplnkovú metriku kvality, aby tím odhalil zdanlivé zrýchlenie spôsobené slabšími kontrolami.

Udržujte meranie užitočné

Vyhnite sa rebríčkom jednotlivcov podľa počtu PR alebo vygenerovaného kódu. Tieto metriky môžu odmeňovať umelé delenie práce, vyhýbanie sa náročnej údržbe alebo presúvanie práce pri kontrole na kolegov.

Výsledok preskúmajte s ľuďmi zodpovednými za celú službu. Zaznamenajte zmeny nástroja, skladby práce, tímu a prostredia. Porovnanie pred zmenou a po nej berte ako dôkaz s obmedzeniami, nie ako automatický dôkaz príčiny.

Cieľom je lepšie ďalšie rozhodnutie. Malé, dôveryhodné meranie vedúce k overenému zlepšeniu je užitočnejšie než veľký dashboard bez dohodnutého významu.

Precvičte si meranie na desiatich zmenách

Tento samostatný fiktívny súbor údajov zaznamenáva desať plánovaných zmien. Všetky časy sú v UTC v uvedený deň. Prázdne pole opravy znamená, že v tomto súbore údajov nebola zaznamenaná oprava.

Porovnajte čas od dokončenia kódu po začiatok kontroly a potom od prijatia po vydanie. Určte najdlhšie viditeľné čakanie. Pred označením za zbytočné preskúmajte jeho príčinu. Tieto časové údaje nemerajú aktívnu prácu ani neurčujú začiatok incidentu. Samotné opravné vydanie nemôže preukázať čas obnovy po neúspešnom nasadení.

Stiahnite si fiktívny súbor údajov (CSV)