Метрика на DevOps - каде да добиете податоци за пресметки

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

Но, тоа не беше доволно за раководството - тие постојано нарачуваа се повеќе и повеќе нови метрики, многу брзо престанувајќи да го користат она што беше направено претходно.

Во последно време сите зборуваат за LeadTime - време за испорака на деловни функции. Метриката покажа луда бројка - 200 дена за да се испорача една задача. Како сите удираа и аеа и ги кренаа рацете кон небото!

По некое време, бучавата постепено се смири и раководството доби наредба да создаде друга метрика.

На Иван му беше сосема јасно дека новата метрика исто толку тивко ќе умре во темен агол.

Навистина, помисли Иван, знаејќи дека бројот воопшто не кажува никому ништо. 200 дена или 2 дена - нема разлика, бидејќи е невозможно да се одреди причината по број и да се разбере дали е добра или лоша.

Ова е типична стапица на метрика: се чини дека новата метрика ќе ја каже суштината на постоењето и ќе објасни некоја тајна тајна. Сите се надеваат толку многу на ова, но поради некоја причина ништо не се случува. Да, затоа што тајната не треба да се најде во метрика!

За Иван ова беше помината фаза. Тој го сфати тоа метриката е само обичен дрвен линијар за мерења, и мора да се бараат сите тајни објект на влијание, т.е. е дека оваа метрика е формирана.

За онлајн продавницата, предмет на влијание ќе бидат нејзините клиенти кои внесуваат пари, а за DevOps, тоа ќе бидат тимовите кои создаваат и развиваат дистрибуции со помош на гасоводот.

Еден ден, седнувајќи на удобно столче во салата, Иван реши внимателно да размисли како сака да ја види метриката на DevOps, земајќи го предвид фактот дека предмет на влијание се тимовите.

Цел на метрика на DevOps

Јасно е дека секој сака да го намали времето за испорака. 200 дена, се разбира, не се добри.

Но како, тоа е прашањето?

Компанијата вработува стотици тимови, а илјадници дистрибуции поминуваат низ гасоводот DevOps секој ден. Вистинското време на испорака ќе се појави како дистрибуција. Секој тим ќе има свое време и свои карактеристики. Како можете да најдете нешто меѓу овој хаос?

Одговорот се појави природно - треба да ги најдеме проблематичните тимови и да откриеме што се случува со нив и зошто трае толку долго, и да научиме од „добрите“ тимови како да сториме сè брзо. И за да го направите ова, треба да го измерите времето поминато од тимовите на секоја од штандовите на DevOps:

„Целта на системот ќе биде да се изберат тимови врз основа на времето кога поминуваат на трибините, т.е. Како резултат на тоа, треба да добиеме листа на команди со избраното време, а не бројка.

Ако дознаеме колку време е поминато вкупно на трибината и колку време е потрошено за одмор помеѓу трибините, можеме да ги најдеме екипите, да ги повикаме и подетално да ги разбереме причините и да ги елиминираме“, помисли Иван.

Како да се пресмета времето на испорака за DevOps

За да се пресмета, беше неопходно да се навлезе во процесот DevOps и неговата суштина.

Компанијата користи ограничен број системи, а информации може да се добијат само од нив и никаде на друго место.

Сите задачи во компанијата беа регистрирани во Жира. Кога беше преземена задача, беше креирана гранка за неа, а по имплементацијата, беше направено обврзување на BitBucket и Pull Request. Кога беше прифатено ПР (Барање за повлекување), дистрибуцијата беше автоматски креирана и складирана во складиштето на Nexus.

Следно, дистрибуцијата беше спроведена на неколку штандови користејќи Џенкинс за да се провери исправноста на пуштањето, автоматското и рачното тестирање:

Иван опиша од кои системи какви информации може да се земат за да се пресмета времето на трибините:

• Од Nexus – Време на создавање на дистрибуција и име на папката што го содржи командниот код
• Од Џенкинс – Почетно време, времетраење и резултат на секоја работа, име на штандот (во параметрите на работата), фази (чекори на работа), врска до дистрибуцијата во Nexus.
• Иван реши да не ги вклучи Џира и БитБакет во нафтоводот, бидејќи ... тие беа повеќе поврзани со фазата на развој, а не со исфрлање на готовата дистрибуција на трибините.

Врз основа на достапните информации, нацртан е следниот дијаграм:

Знаејќи колку време е потребно за да се создадат дистрибуции и колку време е потрошено на секоја од нив, можете лесно да ги пресметате вкупните трошоци за поминување низ целиот гасовод DevOps (целосен циклус).

Еве ги метриките на DevOps со кои Иван заврши:

• Број на создадени дистрибуции
• Удел на дистрибуции што „дојдоа“ на штандот и „поминаа“ на штандот
• Време поминато на штандот (циклус на штандот)
• Целосен циклус (вкупно време за сите трибини)
• Времетраење на работата
• Застој помеѓу трибините
• Застој помеѓу отпочнувањето на работните места на истиот штанд

Од една страна, метриката го карактеризираше гасоводот DevOps многу добро во однос на времето, од друга страна, тие се сметаа за многу едноставни.

Задоволен од добро завршената работа, Иван направи презентација и отиде да ја презентира пред раководството.

Се врати мрачен и со спуштени раце.

„Ова е фијаско, брат“, се насмевна ироничното колега...

Прочитајте повеќе во статијата “Колку брзите резултати му помогнаа на Иван".

Извор: www.habr.com