Ausalt öeldes naeris Ivan sageli oma kolleegide asjatute pingutuste üle järelevalveosakonnast. Nad tegid suuri jõupingutusi, et rakendada mõõdikuid, mida ettevõtte juhtkond neil saavutada käskis. Nad olid nii hõivatud, et ei tahtnud, et keegi teine midagi teeks.
Kuid juhtkonna jaoks ei piisanud kõigest - nad tellisid pidevalt uusi ja uusi mõõdikuid, lõpetades väga kiiresti varem tehtu kasutamise.
Viimasel ajal on kõik rääkinud LeadTime’ist – ärifunktsioonide tarnimise ajast. Mõõdik näitas pöörast numbrit – 200 päeva ühe ülesande täitmiseks. Kuidas kõik ohh ja aaah ja tõstsid käed taeva poole!
Mõne aja pärast müra vaibus ja juhtkond sai käsu luua uus mõõdik.
Ivanile oli täiesti selge, et uus mõõdik sureb sama vaikselt pimedas nurgas.
Tõepoolest, mõtles Ivan, et numbri teadmine ei ütle kellelegi midagi. 200 päeva või 2 päeva - vahet pole, sest numbri järgi on võimatu põhjust kindlaks teha ja aru saada, kas see on hea või halb.
See on tüüpiline mõõdikute lõks: tundub, et uus mõõdik räägib eksistentsi olemuse ja selgitab mõne salajase saladuse. Kõik loodavad sellele nii väga, aga millegipärast ei juhtu midagi. Jah, sest saladust ei tohiks leida meetrikast!
Ivani jaoks oli see läbitud etapp. Ta sai sellest aru mõõtude jaoks ja kõik saladused tuleb sisse otsida , st. on see, et see mõõdik on moodustatud.
Veebipoe jaoks on mõjuobjektiks selle kliendid, kes toovad raha sisse, ja DevOpsi jaoks on meeskonnad, kes loovad ja levitavad distributsioone torujuhtme abil.
Ühel päeval, istudes esikus mugavale toolile, otsustas Ivan hoolikalt läbi mõelda, kuidas ta soovib DevOpsi mõõdikuid näha, võttes arvesse asjaolu, et mõjuobjektiks on meeskonnad.
DevOpsi mõõdikute eesmärk
On selge, et kõik tahavad tarneaega lühendada. 200 päeva pole muidugi hea.
Aga kuidas, see on küsimus?
Ettevõttes töötab sadu meeskondi ja tuhanded distributsioonid läbivad DevOpsi torujuhtme iga päev. Tegelik tarneaeg kuvatakse jaotusena. Igal meeskonnal on oma aeg ja oma omadused. Kuidas sa selle jama hulgast midagi leiad?
Vastus tekkis loomulikult – peame leidma probleemsed meeskonnad ja aru saama, mis nendega toimub ja miks see nii kaua aega võtab, ning õppima “headelt” meeskondadelt, kuidas kõike kiiresti teha. Ja selleks peate mõõtma aega, mille meeskonnad veedavad igal DevOpsi stendil:
«Süsteemi eesmärk saab olema võistkondade valimine tribüünidelt läbimise aja järgi, s.o. Selle tulemusena peaksime saama käsuloendi valitud ajaga, mitte numbriga.
Kui saame teada, kui palju aega kulus kokku tribüünil ja kui palju aega kulus tribüüni vahel seisakutele, saame meeskonnad üles otsida, neile helistada ja põhjustest täpsemalt aru saada ning need kõrvaldada,” arvas Ivan.
Kuidas arvutada DevOpsi tarneaega
Selle arvutamiseks oli vaja süveneda DevOps protsessi ja selle olemusse.
Ettevõte kasutab piiratud arvu süsteeme ning infot saab ainult nendest ja mitte kusagilt mujalt.
Kõik ülesanded ettevõttes registreeriti Jiras. Ülesande pealevõtmisel loodi selle jaoks haru ja peale juurutamist tehti commit BitBucket ja Pull Request. Kui PR (tõmbetaotlus) võeti vastu, loodi distributsioon automaatselt ja salvestati Nexuse hoidlasse.
Järgmisena viidi levitamine välja mitmele stendile, kasutades Jenkinsi, et kontrollida levitamise õigsust, automaatset ja käsitsi testimist:
Ivan kirjeldas, millistest süsteemidest millist infot saab stendidel aja arvutamiseks võtta:
- Nexusest – levitamise loomise aeg ja käsukoodi sisaldava kausta nimi
- Jenkinsilt – iga töö algusaeg, kestus ja tulemus, stendi nimi (töö parameetrites), etapid (tööetapid), Nexuse levitamise link.
- Ivan otsustas Jirat ja BitBucketit mitte lisada, sest need olid rohkem seotud arendusetapiga, mitte valmisjaotuse stendidele rullimisega.
Olemasoleva teabe põhjal koostati järgmine diagramm:
Teades, kui kaua distributsioonide loomine aega võtab ja kui palju aega igale neist kulub, saate hõlpsalt arvutada kogu DevOpsi konveieri (täistsükkel) läbimise kogukulud.
Siin on DevOpsi mõõdikud, mille Ivan lõpetas:
- Loodud distributsioonide arv
- Stendile “tulnud” ja stendilt “läbinud” väljamaksete osakaal
- Stendil veedetud aeg (statiivtsükkel)
- Täistsükkel (kõikide stendide koguaeg)
- Töö kestus
- Seisakud seisakute vahel
- Seisakud töö käivitamise vahel samal stendil
Ühest küljest iseloomustasid mõõdikud DevOps torujuhtme ajaliselt väga hästi, teisalt peeti neid väga lihtsaks.
Olles hästi tehtud tööga rahul, tegi Ivan ettekande ja läks seda juhtkonnale esitlema.
Ta tuli tagasi sünge ja käed maas.
"See on fiasko, vennas," naeratas irooniline kolleeg...
Loe lähemalt artiklist "'.
Allikas: www.habr.com