Шчыра кажучы, Іван часта пасмейваўся з марных намаганняў калег з аддзела маніторынгу. Яны прыкладалі вялікія намаганні для рэалізацыі метрык, якія ім заказвала кіраўніцтва кампаніі. Яны былі настолькі занятыя, што болей нікому нічога не хацелі рабіць.
А кіраўніцтву ўсё было мала - яно ўвесь час заказвала ўсё новыя і новыя метрыкі, вельмі хутка перастаючы карыстацца тым, што былі зроблены раней.
Апошні час усё толькі і казалі пра LeadTime - час пастаўкі бізнесавых фіч. Метрыка паказала вар'яцкі лік - 200 дзён на пастаўку адной задачы. Як жа ўсё вохкалі, ахкалі і апраналі рукі да неба!
Праз некаторы час шум паступова заціх і ад кіраўніцтва паступіла замова на стварэнне яшчэ адной метрыкі.
Івану было зусім зразумела, што і новая метрыка таксама ціхенька памрэ ў цёмным кутку.
Сапраўды, разважаў Іван, веданне ліку зусім нікому ні пра што не гаворыць. 200 дзён ці 2 дні - няма ніякай розніцы, таму што па колькасці немагчыма вызначыць прычыну і зразумець, добра гэта ці дрэнна.
Гэта тыповая пастка метрык: здаецца, што новая метрыка раскажа сутнасць быцця і растлумачыць нейкі таемны сакрэт. Усё так на гэта спадзяюцца, але нічога чамусьці не адбываецца. Ды таму што сакрэт трэба шукаць зусім не ў метрыках!
Для Івана гэта быў пройдзены этап. Ён разумеў, што для вымярэнняў, а ўсе сакрэты трэба шукаць у , г.зн. у тым, што гэтую метрыку фармуе.
Для інтэрнэт-крамы аб'ектам уплыву будуць яго кліенты, якія прыносяць грошы, а для DevOps - каманды, якія ствараюць і раскочваюць дыстрыбутывы з выкарыстаннем канвеера.
Аднойчы, уладкаваўшыся ў холе ў зручным крэсле Іван вырашыў як след прадумаць як бы ён жадаў бачыць метрыкі DevOps з улікам таго, што аб'ектам уплыву з'яўляюцца каманды.
Мэта метрык DevOps
Зразумела, што ўсім жадаецца паменшыць час пастаўкі. 200 дзён - гэта, вядома, нікуды не падыходзіць.
Але як, вось у чым пытанне?
У кампаніі працуюць сотні каманд, а ў дзень праз DevOps-канвеер праходзяць тысячы дыстрыбутываў. Рэальны час пастаўкі будзе выглядаць як размеркаванне. У кожнай з каманд будзе свой уласны час і свае ўласныя асаблівасці. Як сярод гэтага месіва можна знайсці хоць нешта?
Адказ узнік сам сабой - трэба знайсці праблемныя каманды і разабрацца, што ў іх адбываецца і чаму так доўга, а ў "добрых" каманд навучыцца як усё рабіць хутка. А для гэтага патрабуецца вымераць час, праведзены камандамі на кожным са стэндаў DevOps:
«Мэтай сістэмы будзе адбор каманд па часе праходжання стэндаў, г.зн. у выніку мы павінны атрымаць спіс каманд з абраным часам, а не лічбу.
Калі мы даведаемся колькі часу сумарна патрачана на стэнд і колькі часу патрачана на прастоі паміж стэндамі, то зможам знайсці каманды, патэлефанаваць ім і больш падрабязна разабрацца ў прычынах і ліквідаваць іх », - падумаў Іван.
Як палічыць час пастаўкі для DevOps
Для падліку неабходна было паглыбіцца ў працэс DevOps і яго сутнасці.
У кампаніі выкарыстоўваецца абмежаваную колькасць сістэм, і інфармацыю можна атрымаць толькі з іх і больш ніадкуль.
Усе задачы ў кампаніі рэгістраваліся ў Jira. Калі задача бралася ў працу, для яе ствараўся бранч, а пасля рэалізацыі рабіўся коміт у BitBucket і Pull Request. Пры прыняцці PR (Pull Request) аўтаматычна ствараўся дыстрыбутыў і захоўваўся ў сховішчы Nexus.
Далей дыстрыбутыў раскочваўся на некалькіх стэндах з дапамогай Jenkins для праверкі правільнасці накаткі, аўтаматычнага і ручнога тэставання:
Іван распісаў з якіх сістэм якую інфармацыю можна ўзяць, каб пралічыць час на стэндах:
- З Nexus – Час стварэння дыстрыбутыва і назва тэчкі, у якой утрымоўваўся код каманды
- З Jenkins - Час старту, працягласць і вынік адпрацоўкі кожнай джобы, назва стэнда (у параметрах джобы), стэйджы (крокі джоба), спасылка на дыстрыбутыў у Nexus.
- Jira і BitBucket Іван вырашыў у канвеер не ўключаць, т.я. яны больш ставіліся да этапу распрацоўкі, а не да пракаткі гатовага дыстрыбутыва па стэндах.
На аснове наяўнай у распараджэнні інфармацыі прамалёўвалася такая схема:
Ведаючы колькі часу ствараецца дыстрыбутываў і колькі часу затрачваецца на кожны з іх, можна лёгка палічыць агульныя выдаткі на праходжанне ўсяго канвеера DevOps (поўны цыкл).
Вось якія DevOps-метрыкі атрымаліся ў Івана ў выніку:
- Колькасць створаных дыстрыбутываў
- Доля дыстрыбутываў, якія «зайшлі» на стэнд і «мінулых» стэнд
- Час, праведзены на стэндзе (цыкл стэнда)
- Поўны цыкл (сумарны час па ўсіх стэндах)
- Працягласць джобаў
- Просты паміж стэндамі
- Просты паміж запускамі джобаў на адным стэндзе
З аднаго боку, метрыкі вельмі добра характарызавалі канвеер DevOps з пункта гледжання часу, з іншай - лічыліся вельмі проста.
Задаволены добра зробленай працай Іван склаў прэзентацыю і пайшоў прадстаўляць яе кіраўніцтву.
Назад ён выходзіў хмурны і з апушчанымі рукамі.
— Гэта фіяска, браценік — усміхнуўся іранічны калега…
Працяг чытайце ў артыкуле «.
Крыніца: habr.com