Як Іван метрыкі DevOps рабіў. Аб'ект уплыву

Мінуў тыдзень з таго часу, як Іван упершыню задумаўся над метрыкамі DevOps і зразумеў, што кіраваць з іх дапамогай трэба часам пастаўкі прадукта. (Time-To-Market).

Нават у выходныя ён думаў пра метрыкі: «Ну і што, што я вымераю час? Што яно мне дасць?

Сапраўды, што дасць веданне часу? Дапушчальны, пастаўка займае 5 дзён. І што далей? Гэта добра ці дрэнна? Нават калі гэта дрэнна, то трэба ж неяк змяншаць гэты час. Але як?
Гэтыя думкі не давалі яму спакою, але рашэнне не прыходзіла.

Іван разумеў, што падышоў да самай сутнасці. Незлічоныя графікі метрык, бачаныя ім да гэтага, даўно пераканалі яго, што стандартны падыход не спрацуе, і што калі проста пабудаваць графік (хай нават кагорты), толку ад яго будзе нуль.

Як жа быць?

Метрыка - гэта як звычайная драўляная лінейка. Вымярэнні, зробленыя з яе дапамогай, не скажуць прычыну, чаму вымяраны прадмет менавіта той даўжыні, якую яна паказаў. Лінейка проста пакажа яго памер, і не больш за. Яна не філасофскі камень, а проста драўляная дошка, якой вымяраюць.

"Пацук з нержавеючай сталі" яго любімага пісьменніка Гары Гарысана заўсёды казала: думка павінна дасягнуць дна мозгу і там адляжацца, таму безвынікова прамучыўшыся некалькі дзён Іван вырашыў заняцца іншай задачай…

Праз пару дзён, чытаючы артыкул пра інтэрнэт-крамы, Іван раптам зразумеў, што велічыня грошай, якую атрымлівае інтэрнэт-крама, залежыць ад таго, як паводзяць сябе наведвальніка сайта. Менавіта яны, наведвальнікі/кліенты, аддаюць краме свае грошы і з'яўляюцца іх крыніцай. На выніковую велічыню грашовых сродкаў, якія атрымліваюцца крамай, уплываюць змены ў паводзінах кліентаў, а ні нешта іншае.

Атрымлівалася, што для змены вымяранай велічыні трэба было ўплываць на тых, хто гэтае значэнне фармуе, г.зн. для змены колькасці грошай інтэрнэт-крамы трэба было ўплываць на паводзіны кліентаў гэтай крамы, а для змены часу пастаўкі ў DevOps трэба было ўплываць на каманды, якія гэты час "ствараюць", г.зн. выкарыстоўваюць DevOps у сваёй працы.

Іван зразумеў, што метрыкі DevOps павінны ўяўляць зусім не графікі. Яны павінны ўяўляць з сябе інструмент пошуку «выбітных» каманд, якія фарміруюць выніковы час пастаўкі.

Ніякая метрыка ніколі не пакажа прычыну, чаму тая ці іншая каманда доўга пастаўляла дыстрыбутыў, думаў Іван, бо ў рэальнасці прычын можа быць мільён і маленькі каляска, і яны цалкам могуць быць не тэхнічнымі, а арганізацыйнымі. Г.зн. максімум, што можна разлічваць атрымаць ад метрык - гэта паказ каманд і іх вынікаў, а затым усё роўна давядзецца ў гэтыя каманды ісці нагамі і высвятляць, што ў іх стрэслася.

З іншага боку, у кампаніі Івана існаваў стандарт, які абавязвае ўсе каманды правяраць зборкі на некалькіх стэндах. Каманда не магла перайсці на наступны стэнд да таго часу, пакуль не будзе пройдзены папярэдні. Атрымлівалася, што калі ўявіць працэс DevOps як паслядоўнасць праходжання стэндаў, то метрыкі маглі б паказваць час, які затрачваецца камандамі на гэтых стэндах. Ведаючы стэнд і час каманды, можна было больш канкрэтна размаўляць з ёй аб прычынах.

Не доўга думаючы Іван падняў тэлефонную трубку і набраў нумар чалавека, добра які разбіраецца ва вантробах DevOps:

- Дзяніс, падкажы, калі ласка, а ці можна неяк зразумець, што каманда прайшла той ці іншы стэнд?
- Вядома. Наш Jenkins адкідае сцяг, калі зборка паспяхова раскацілася (прайшла праверку) на стэндзе.
- Супер. А што такое сьцяг?
- Гэта звычайны тэкставы файлік тыпу "стэнд_OK" або "стэнд_FAIL", які кажа, што зборка прайшла ці не прайшла стэнд. Ну ты зразумеў, так?
- У прынцыпе так. Ён пішацца ў тую ж тэчку ў сховішчы, дзе ляжыць зборка?
- Так
- А што будзе, калі зборка не прайшла стэнд? Ці трэба будзе рабіць новую зборку?
- Ага
- Ну ок, дзякуй. І яшчэ пытанне: я правільна разумею, што ў якасці даты праходжання стэнда я змагу выкарыстоўваць дату стварэння сцяга?
- Абсалютны!
- Супер!

Натхнёны, Іван паклаў слухаўку і зразумеў, што ўсё ўстала на свае месцы. Ведаючы дату стварэння файла зборкі і даты стварэння сцягоў можна было з дакладнасць да секунды палічыць, колькі часу каманды марнуюць на кожны стэнд і зразумець дзе яны марнуюць больш за ўсё часу.

«Разумеючы, дзе сыходзіць больш за ўсё часу, мы кропкава знойдзем каманды, пойдзем да іх і пракапаем праблему». Іван усміхнуўся.

На заўтра ён паставіў сабе задачу накідаць архітэктуру сістэмы, якая прамалёўваецца.

Працяг будзе…

Крыніца: habr.com

Дадаць каментар