Път 04Урок 10 / 10

Измервайте системата за доставка

Съчетайте потока на доставка, нестабилността, резултатите на услугата и усилието. Използвайте изрични определения при оценка на ефекта на AI.

Практическо ниво10 минПрегледано

Публикувано от Как пишем

Проверете разбирането сиЧестотата на внедряване нараства след въвеждане на AI, а непланираните внедрявания за поправки също нарастват. Какво трябва да заключите?Направете упражнението
Честотата на внедряване нараства след въвеждане на AI, а непланираните внедрявания за поправки също нарастват. Какво трябва да заключите?

Какво ще научите

  • Разграничете ефективността на доставката от дейността по генериране на код.
  • Тълкувайте показател според определенията на събитията и обхвата му.
  • Използвайте измерванията за избор на подобрение, а не за класиране на хора.

Започнете с решението, което трябва да вземете

Екип иска да знае дали AI подобрява доставката. Броенето на генерирани редове отговаря на друг въпрос. Определете полезния резултат и условията за качество, преди да изберете показател.

За измислена услуга за експорт желаният резултат е надеждна доставка на приети промени с по-малко общо усилие. Записвайте подготовката, реализацията, прегледа, поправките и изчакването. Включвайте неуспешни и изоставени промени.

Използвайте една услуга с ясна граница. Комбиниране на експериментален сайт и критична платежна услуга може да даде число, което не обяснява нито една от тях. Опишете контекста, преди да сравнявате периоди или екипи.

Използвайте текущи определения

Текущият модел на DORA за доставка съдържа пет показателя. Обхватът им е ефективността на доставката, а не стойността на всяка функционалност или приносът на отделен човек. Определения на показателите на DORA.

ПоказателФокус на измерването
Време за доставка на промянаОт commit до продукционна среда
Честота на внедряванеЧестота на внедряванията в продукционна среда
Време за възстановяване след неуспешно внедряванеВъзстановяване след неуспешно внедряване
Дял на неуспешните промениВнедрявания, изискващи незабавна намеса
Дял на внедряванията за преработкаНепланирани внедрявания, причинени от продукционни инциденти

Табло може да използва друго определение. Прочетете го, преди да тълкувате резултата. Текущата документация на Taiga за внедряване описва четири отчитани показателя, извлечени от записи за внедряване на доставчика. Нейният показател за възстановяване използва последващо успешно внедряване. Това не е пълен запис на всеки продукционен инцидент. Определения на Taiga.

Прегледайте измислена последователност от промени

Да предположим, че услуга има дванадесет внедрявания за месец. Осем доставят планирани промени. Четири поправят проблеми от по-ранни версии. Броят е дванадесет, но съставът има значение.

През следващия месец екипът прави десет внедрявания: девет планирани промени и една поправка. По-малко внедрявания могат да съществуват заедно с повече полезна работа. Тези числа илюстрират тълкуване; не са еталон за ефективност.

Прегледайте и разпределението. Едно дълго изчакване за преглед може да изчезне в средна стойност. Измерване на възстановяване от един неуспех е слабо доказателство за бъдеща надеждност. Отчитайте броя наблюдения и съществените изключения.

Свържете потока с последствията

Използвайте сигнали от услугата, за да проверите дали промените в доставката влияят на потребителите. По-бърз pipeline не е достатъчен, ако експортите се провалят по-често. Използвайте подходяща SLO или друг ясно определен показател за резултат. Указания за SLO.

Усилието за преглед и преработката помагат да обясните резултата. Ако AI съкращава реализацията, но създава големи diff-ове, прегледът може да стане ограничението. Ако получаването на среди отнема дни, по-бързото програмиране може слабо да повлияе на изминалото време за доставка.

Изберете едно подобрение, което адресира наблюдаваното ограничение. Например осигурете поддържана тестова среда или намалете размера на промяна. Определете балансиращ показател за качество, за да може екипът да открива привидно ускорение, причинено от по-слаби проверки.

Пазете измерването полезно

Избягвайте класиране на хора по брой PR-и или генериран код. Тези показатели могат да възнаграждават изкуствено разделяне на работа, избягване на трудна поддръжка или прехвърляне на усилието за преглед към колеги.

Прегледайте резултата с хората, отговорни за цялата услуга. Запишете какво се е променило в инструмента, състава на работата, екипа и средата. Третирайте сравнение преди и след като доказателство с ограничения, а не автоматично доказателство за причинност.

Целта е по-добро следващо решение. Малко, достоверно измерване, което води до проверено подобрение, е по-полезно от голямо табло без договорено значение.

Упражнете се с десет промени

Този отделен измислен набор данни записва десет планирани промени. Всички часове са UTC на показаната дата. Празно поле за поправка означава, че в този набор не е записана поправка.

Промяна / датаНачало на работаКодът е готовНачало на прегледПриетаПуснатаПоправена
C01 · 2026-09-1408:0008:4509:1509:3010:00—
C02 · 2026-09-1409:0009:3012:0012:2013:00—
C03 · 2026-09-1508:0009:0009:1509:4010:0015:00
C04 · 2026-09-1510:0010:3010:4511:0011:15—
C05 · 2026-09-1608:0009:0013:0013:3014:00—
C06 · 2026-09-1610:0011:0011:3012:0012:15—
C07 · 2026-09-1708:0008:3009:0009:2009:30—
C08 · 2026-09-1710:0010:4511:0011:3014:30—
C09 · 2026-09-1808:0008:3009:0009:3010:00—
C10 · 2026-09-1809:0009:3010:0010:3011:0014:00

Сравнете времето от готов код до начало на преглед, после от приемане до пускане. Определете най-дългото видимо изчакване. Проучете причината му, преди да го наречете избежимо. Тези часове не измерват активно усилие и не определят кога е започнал инцидент. Само пускане на поправка не може да установи времето за възстановяване след неуспешно внедряване.

Изтеглете измисления набор данни (CSV)

Проверете времената за изчакване

Проверете тълкуването си: C05 чака четири часа за преглед. C08 чака три часа след приемането преди пускане. Наборът не обяснява тези изчаквания. Попитайте за капацитет, работно време, политика за пускане и зависимости.

Направете упражнението

Използвайте набора от десет промени в този урок. Определете внедряване, неуспешна промяна и събитие на възстановяване. Намерете най-дългото видимо изчакване и посочете какво би установило причината му. Предложете подобрение и показател, който би разкрил по-лошо качество.

Изтеглете работния лист (Markdown)
Проверете разбирането си ↑

Продължете ученето

Източници и допълнително четене

Свързани материали от Taiga

← Предишен урок: Вземайте решение за пускане с доказателства