Sa totoo lang, madalas na natatawa si Ivan sa mga walang kwentang pagsisikap ng kanyang mga kasamahan mula sa departamento ng pagsubaybay. Gumawa sila ng mahusay na pagsisikap upang ipatupad ang mga sukatan na iniutos sa kanila ng pamamahala ng kumpanya na makamit. Masyado silang abala kaya ayaw nilang may gumawa ng kahit ano.
Ngunit hindi ito sapat para sa pamamahala - palagi silang nag-uutos ng parami nang parami ng mga bagong sukatan, napakabilis na huminto sa paggamit ng nagawa na noon.
Kamakailan lamang, pinag-uusapan ng lahat ang tungkol sa LeadTime - ang oras para sa paghahatid ng mga feature ng negosyo. Ang sukatan ay nagpakita ng isang nakakabaliw na numero - 200 araw upang maihatid ang isang gawain. Paanong lahat ay nag-oohe at nag-aah at nagtaas ng kanilang mga kamay sa langit!
Pagkalipas ng ilang oras, unti-unting humina ang ingay at nakatanggap ang management ng utos na gumawa ng isa pang sukatan.
Ito ay ganap na malinaw kay Ivan na ang bagong sukatan ay tahimik na mamamatay sa isang madilim na sulok.
Sa katunayan, naisip ni Ivan, ang pag-alam sa numero ay hindi nagsasabi sa sinuman ng anuman. 200 araw o 2 araw - walang pagkakaiba, dahil imposibleng matukoy ang dahilan sa pamamagitan ng numero at maunawaan kung ito ay mabuti o masama.
Ito ay isang tipikal na bitag ng mga sukatan: tila isang bagong sukatan ang magsasabi sa kakanyahan ng pag-iral at magpapaliwanag ng ilang lihim na lihim. Ang lahat ay umaasa nang labis para dito, ngunit sa ilang kadahilanan ay walang nangyayari. Oo, dahil ang sikreto ay hindi dapat matagpuan sa mga sukatan!
Para kay Ivan, ito ay isang naipasa na yugto. Naintindihan niya iyon para sa mga sukat, at ang lahat ng mga lihim ay dapat hanapin , ibig sabihin. ay nabuo ang panukat na ito.
Para sa isang online na tindahan, ang magiging object ng impluwensya ay ang mga kliyente nito na nagdadala ng pera, at para sa DevOps, ito ay ang mga team na gumagawa at naglalabas ng mga distribusyon gamit ang pipeline.
Isang araw, nakaupo sa isang komportableng upuan sa bulwagan, nagpasya si Ivan na maingat na pag-isipan kung paano niya gustong makita ang mga sukatan ng DevOps, na isinasaalang-alang ang katotohanan na ang object ng impluwensya ay mga koponan.
Layunin ng DevOps Sukatan
Malinaw na gusto ng lahat na bawasan ang oras ng paghahatid. Siyempre, hindi maganda ang 200 araw.
Ngunit paano, iyon ang tanong?
Ang kumpanya ay gumagamit ng daan-daang mga koponan, at libu-libong mga pamamahagi ang dumadaan sa pipeline ng DevOps araw-araw. Ang aktwal na oras ng paghahatid ay lilitaw bilang isang pamamahagi. Ang bawat koponan ay magkakaroon ng sarili nitong oras at sariling katangian. Paano ka makakahanap ng anuman sa gulo na ito?
Natural na lumitaw ang sagot - kailangan nating hanapin ang mga team na may problema at alamin kung ano ang nangyayari sa kanila at kung bakit ito nagtatagal, at matuto mula sa mga "mahusay" na koponan kung paano gawin ang lahat nang mabilis. At para magawa ito, kailangan mong sukatin ang oras na ginugol ng mga team sa bawat DevOps stand:
"Ang layunin ng sistema ay pumili ng mga koponan batay sa oras na dumaan sila sa mga stand, i.e. Bilang resulta, dapat tayong makakuha ng isang listahan ng mga command na may napiling oras, at hindi isang numero.
Kung malalaman natin kung gaano karaming oras ang ginugol sa stand sa kabuuan at kung gaano karaming oras ang ginugol sa downtime sa pagitan ng mga stand, mahahanap natin ang mga koponan, tawagan sila at maunawaan ang mga dahilan nang mas detalyado at alisin ang mga ito, "naisip ni Ivan.
Paano Kalkulahin ang Oras ng Paghahatid para sa DevOps
Upang kalkulahin ito, kinakailangan upang bungkalin ang proseso ng DevOps at ang kakanyahan nito.
Ang kumpanya ay gumagamit ng isang limitadong bilang ng mga sistema, at ang impormasyon ay maaari lamang makuha mula sa kanila at wala saanman.
Lahat ng gawain sa kumpanya ay nakarehistro sa Jira. Kapag ang isang gawain ay ginawa, isang sangay ang ginawa para dito, at pagkatapos ng pagpapatupad, isang commit ang ginawa sa BitBucket at Pull Request. Kapag tinanggap ang isang PR (Pull Request), ang isang pamamahagi ay awtomatikong ginawa at inimbak sa imbakan ng Nexus.
Susunod, inilunsad ang pamamahagi sa ilang stand gamit ang Jenkins upang suriin ang kawastuhan ng rollout, awtomatiko at manu-manong pagsubok:
Inilarawan ni Ivan mula sa aling mga sistema kung anong impormasyon ang maaaring kunin upang kalkulahin ang oras sa mga stand:
- Mula sa Nexus β Oras ng paggawa ng pamamahagi at pangalan ng folder na naglalaman ng command code
- Mula sa Jenkins β Oras ng pagsisimula, tagal at resulta ng bawat trabaho, pangalan ng stand (sa mga parameter ng trabaho), mga yugto (mga hakbang sa trabaho), link sa pamamahagi sa Nexus.
- Nagpasya si Ivan na huwag isama sina Jira at BitBucket sa pipeline, dahil... mas nauugnay sila sa yugto ng pag-unlad, at hindi sa paglulunsad ng natapos na pamamahagi sa mga stand.
Batay sa magagamit na impormasyon, ang sumusunod na diagram ay iginuhit:
Alam kung gaano katagal bago gumawa ng mga distribusyon at kung gaano karaming oras ang ginugugol sa bawat isa sa kanila, madali mong makalkula ang kabuuang mga gastos sa pagdaan sa buong pipeline ng DevOps (buong cycle).
Narito ang mga sukatan ng DevOps na natapos ni Ivan:
- Bilang ng mga pamamahagi na ginawa
- Bahagi ng mga pamamahagi na "dumating" sa stand at "nakapasa" sa stand
- Oras na ginugol sa stand (stand cycle)
- Buong cycle (kabuuang oras para sa lahat ng stand)
- Tagal ng trabaho
- Downtime sa pagitan ng stand
- Downtime sa pagitan ng mga paglulunsad ng trabaho sa parehong stand
Sa isang banda, ang mga sukatan ay nailalarawan nang mahusay ang pipeline ng DevOps sa mga tuntunin ng oras, sa kabilang banda, ang mga ito ay itinuturing na napakasimple.
Nasiyahan sa trabahong nagawa, gumawa si Ivan ng isang pagtatanghal at nagpunta upang ipakita ito sa pamamahala.
Bumalik siyang madilim at nakababa ang mga kamay.
"Ito ay isang kabiguan, bro," ngumiti ang ironic na kasamahan...
Magbasa pa sa artikulong "'.
Pinagmulan: www.habr.com