Мерите систем испоруке

Почните од одлуке коју треба да донесете

Тим жели да зна да ли AI побољшава испоруку. Бројање генерисаних линија одговара на друго питање. Дефинишите користан исход и услове квалитета пре избора метрике.

За измишљен сервис извоза жељени исход је поуздана испорука прихваћених промена уз мање укупног рада. Бележите припрему, имплементацију, преглед, исправке и чекање. Укључите промене које нису успеле или су напуштене.

Користите један сервис са јасном границом. Обједињавање експерименталног веб-сајта и критичног сервиса плаћања може да произведе број који не објашњава ниједан. Опишите контекст пре поређења периода или тимова.

Користите актуелне дефиниције

Актуелни DORA модел испоруке садржи пет метрика. Њихов обухват је успешност испоруке, а не вредност сваке функције или допринос појединца. DORA дефиниције метрика.

Контролна табла може да користи другу дефиницију. Прочитајте је пре тумачења резултата. Актуелна Taiga документација о постављањима описује четири приказане метрике изведене из евиденције постављања код добављача. Њена мера опоравка користи наредно успешно постављање. То није потпуна евиденција свих инцидената у продукцији. Taiga дефиниције.

Испитајте измишљен низ промена

Претпоставимо да сервис има дванаест постављања у месецу. Осам испоручује планиране промене. Четири поправљају проблеме из ранијих издања. Број је дванаест, али састав је важан.

Следећег месеца тим има десет постављања: девет планираних промена и једну поправку. Мање постављања може да прати више корисног рада. Ови бројеви илуструју тумачење; нису референтне вредности успешности.

Испитајте и расподелу. Једно дуго чекање на преглед може да се изгуби у просеку. Мера опоравка из једног отказа слаб је доказ будуће поузданости. Прикажите број посматрања и значајне изузетке.

Повежите ток са последицама

Користите сигнале сервиса да проверите да ли промене испоруке утичу на кориснике. Бржи pipeline није довољан ако извоз чешће отказује. Користите одговарајући SLO или другу јасно дефинисану меру исхода. SLO смернице.

Рад на прегледу и поновљени рад помажу да се објасни резултат. Ако AI скрати имплементацију, али производи велике diff-ове, преглед може да постане ограничење. Ако се окружења чекају данима, брже писање кода може мало да утиче на укупно протекло време испоруке.

Изаберите једно побољшање које решава уочено ограничење. На пример, обезбедите подржано тестно окружење или смањите величину промене. Дефинишите пратећу метрику квалитета како би тим открио привидно убрзање настало због слабијих провера.

Нека мерење остане корисно

Избегавајте рангирање појединаца према броју PR-ова или генерисаном коду. Те мере могу да награде вештачко уситњавање посла, избегавање тешког одржавања или пребацивање рада на прегледу колегама.

Прегледајте резултат са људима одговорним за цео сервис. Забележите шта се променило у алату, саставу посла, тиму и окружењу. Поређење пре и после посматрајте као доказ са ограничењима, а не као аутоматски доказ узрочности.

Сврха је боља следећа одлука. Мало, поуздано мерење које води до провереног побољшања корисније је од велике контролне табле без договореног значења.

Вежбајте са десет промена

Овај засебан измишљени скуп података бележи десет планираних промена. Сва времена су у UTC за приказани датум. Празно поље исправке значи да у овом скупу података исправка није забележена.

Упоредите време од спремности кода до почетка прегледа, затим од прихватања до објављивања. Утврдите најдуже видљиво чекање. Испитајте узрок пре него што кажете да је могло да се избегне. Ове временске ознаке не мере активан рад и не откривају почетак инцидента. Само објављивање исправке не може да утврди време опоравка после неуспелог постављања.

Преузмите измишљени скуп података (CSV)