Per ser sincer, Ivan es va riure sovint dels esforços inútils dels seus col·legues del departament de seguiment. Van fer grans esforços per implementar les mètriques que la direcció de l'empresa els va ordenar assolir. Estaven tan ocupats que no volien que ningú més fes res.
Però no n'hi havia prou per a la direcció: constantment ordenaven més i més mètriques noves, deixant molt ràpidament d'utilitzar el que s'havia fet anteriorment.
Darrerament, tothom ha estat parlant de LeadTime: el moment de lliurament de funcions empresarials. La mètrica mostrava un nombre boig: 200 dies per lliurar una tasca. Com tothom va uidar i aah i va aixecar les mans al cel!
Després d'un temps, el soroll es va reduir gradualment i la direcció va rebre l'ordre de crear una altra mètrica.
L'Ivan tenia completament clar que la nova mètrica moriria en un racó fosc.
De fet, va pensar l'Ivan, saber que el número no diu res a ningú. 200 dies o 2 dies: no hi ha cap diferència, perquè és impossible determinar el motiu pel nombre i entendre si és bo o dolent.
Aquesta és una típica trampa de mètriques: sembla que una nova mètrica dirà l'essència de l'existència i explicarà algun secret secret. Tothom espera molt en això, però per alguna raó no passa res. Sí, perquè el secret no s'ha de trobar en mètriques!
Per a l'Ivan, aquesta era una etapa superada. Ell ho va entendre per a les mesures, i s'han de buscar tots els secrets , és a dir és que es forma aquesta mètrica.
Per a una botiga en línia, l'objecte d'influència seran els seus clients que aportin diners, i per a DevOps, seran els equips que creïn i desenvolupin distribucions mitjançant un pipeline.
Un dia, assegut en una còmoda cadira al vestíbul, l'Ivan va decidir pensar detingudament com volia veure les mètriques de DevOps, tenint en compte el fet que l'objecte d'influència són els equips.
Propòsit de les mètriques DevOps
Està clar que tothom vol reduir el temps de lliurament. 200 dies, per descomptat, no són bo.
Però com, aquesta és la pregunta?
L'empresa dóna feina a centenars d'equips i milers de distribucions passen pel canal de DevOps cada dia. El termini de lliurament real apareixerà com a distribució. Cada equip tindrà el seu temps i les seves característiques. Com pots trobar alguna cosa entre aquest embolic?
La resposta va sorgir de manera natural: hem de trobar els equips problemàtics i esbrinar què els passa i per què triga tant, i aprendre dels "bons" equips a fer-ho tot ràpidament. I per fer-ho, cal mesurar el temps que passen els equips a cadascun dels estands de DevOps:
“La finalitat del sistema serà seleccionar equips en funció del temps que passen per les grades, és a dir. Com a resultat, hauríem d'obtenir una llista d'ordres amb l'hora seleccionada, i no un número.
Si descobrim quant de temps s'ha passat a la grada en total i quant de temps s'ha dedicat a les hores d'inactivitat entre graderies, podem trobar els equips, trucar-los i entendre'n els motius amb més detall i eliminar-los”, va pensar l'Ivan.
Com calcular el temps de lliurament de DevOps
Per calcular-ho, calia aprofundir en el procés DevOps i la seva essència.
L'empresa utilitza un nombre limitat de sistemes, i només es pot obtenir informació d'ells i enlloc més.
Totes les tasques de l'empresa es van registrar a Jira. Quan s'executava una tasca, es creava una branca per a ella i, després de la implementació, es feia una confirmació a BitBucket i Pull Request. Quan s'acceptava una PR (Pull Request), es creava i s'emmagatzemava automàticament una distribució al repositori de Nexus.
A continuació, la distribució es va desplegar en diversos estands mitjançant Jenkins per comprovar la correcció del llançament, les proves automàtiques i manuals:
Ivan va descriure de quins sistemes quina informació es pot extreure per calcular el temps a les grades:
- Des de Nexus: hora de creació de la distribució i nom de la carpeta que contenia el codi de comanda
- Des de Jenkins: hora d'inici, durada i resultat de cada treball, nom de l'estand (en els paràmetres del treball), etapes (passos del treball), enllaç a la distribució a Nexus.
- L'Ivan va decidir no incloure Jira i BitBucket al pipeline, perquè... estaven més relacionats amb l'etapa de desenvolupament, i no amb el desplegament de la distribució acabada en estands.
A partir de la informació disponible, es va dibuixar el següent diagrama:
Sabent quant de temps es triga a crear distribucions i quant de temps es dedica a cadascuna d'elles, podeu calcular fàcilment els costos totals de passar per tot el pipeline DevOps (cicle complet).
Aquestes són les mètriques de DevOps amb les quals va acabar Ivan:
- Nombre de distribucions creades
- Quota de distribucions que "han arribat" a l'estand i han "passat" l'estand
- Temps passat a l'estand (cicle d'estand)
- Cicle complet (temps total per a tots els estands)
- Durada del treball
- Temps d'inactivitat entre estands
- Temps d'inactivitat entre llançaments de treball al mateix estand
D'una banda, les mètriques caracteritzaven molt bé el pipeline DevOps en termes de temps, d'altra banda, es consideraven molt simples.
Satisfet amb la feina ben feta, Ivan va fer una presentació i va anar a presentar-la a la direcció.
Va tornar trist i amb les mans baixes.
"Això és un fiasco, germà", va somriure el company irònic...
Llegeix més a l'article "».
Font: www.habr.com