Чынын айтсам, Иван мониторинг бөлүмүндөгү кесиптештеринин курулай аракетине көп күлчү. Алар компаниянын жетекчилиги аларга жетишүүгө буйруган көрсөткүчтөрдү ишке ашыруу үчүн көп күч-аракет жумшашты. Алар ушунчалык бош эмес болгондуктан, башка бирөөнүн эч нерсе кылышын каалашкан жок.
Бирок бул жетекчилик үчүн жетишсиз болгон - алар тынымсыз жаңы көрсөткүчтөргө буйрук берип, мурда жасалгандарды колдонууну тез эле токтотушкан.
Акыркы убакта баары LeadTime жөнүндө айтып жатышат - бизнес функцияларын жеткирүү убактысы. Метрика жинди санды көрсөттү - бир тапшырманы жеткирүү үчүн 200 күн. Баары кандай гана уктап, колдорун асманга көтөрүштү!
Бир нече убакыт өткөндөн кийин, ызы-чуу акырындык менен басылып, жетекчилик дагы бир метрика түзүү буйругун алды.
Иванга жаңы метрика караңгы бурчта акырын өлүп калаары толук түшүнүктүү болду.
Чын эле, деп ойлоду Иван, номерди билүү эч кимге эч нерсе айтпайт. 200 күн же 2 күн - эч кандай айырмасы жок, анткени саны менен себебин аныктоо жана анын жакшы же жаман экенин түшүнүү мүмкүн эмес.
Бул көрсөткүчтөрдүн типтүү тузагы: жаңы метрика бар болуунун маңызын айтып, кандайдыр бир жашыруун сырды түшүндүрөт окшойт. Ар ким ушундан көптү үмүттөнөт, бирок эмнегедир эч нерсе болбойт. Ооба, анткени сырды метрикадан таппашы керек!
Иван үчүн бул өткөн этап эле. Ал муну түшүндү өлчөө үчүн, жана бардык сырларды издөө керек , б.а. Бул метрика түзүлөт.
Интернет-дүкөн үчүн таасир этүүчү объект болуп акча алып келген кардарлары болот, ал эми DevOps үчүн бул түтүк аркылуу бөлүштүрүүнү түзүп, жайылткан командалар болот.
Күндөрдүн биринде залдагы ыңгайлуу креслодо отуруп, Иван таасирдин объектиси командалар экенин эске алып, DevOps метрикасын кантип көргүсү келгенин кылдаттык менен ойлонууну чечти.
DevOps метрикасынын максаты
Ар бир адам жеткирүү убактысын кыскартууну каалаары түшүнүктүү. 200 күн, албетте, жакшы эмес.
Бирок кантип, бул суроо?
Компанияда жүздөгөн командалар иштейт жана күн сайын миңдеген дистрибуциялар DevOps түтүгү аркылуу өтөт. Иш жүзүндө жеткирүү убактысы бөлүштүрүү катары пайда болот. Ар бир команданын өз убактысы жана өзүнүн өзгөчөлүктөрү болот. Бул баш аламандыктын арасынан кантип бир нерсе таба аласыз?
Жооп табигый түрдө пайда болду - биз көйгөйлүү командаларды таап, алар менен эмне болуп жатканын жана эмне үчүн бул мынчалык көпкө созулуп жатканын түшүнүшүбүз керек жана "жакшы" командалардан баарын кантип тез жасоону үйрөнүшүбүз керек. Бул үчүн сиз DevOps стенддеринин ар биринде командалар өткөргөн убакытты өлчөшүңүз керек:
«Системанын максаты командаларды трибуналардан өткөн убактысына жараша тандоо болот, б.а. Натыйжада, биз сан эмес, тандалган убакыт менен буйруктардын тизмесин алышыбыз керек.
Стендге жалпысынан канча убакыт кеткендигин жана стенддердин ортосундагы токтоп калууларга канча убакыт кеткенин билсек, биз бригадаларды таап, аларга телефон чалып, анын себептерин кененирээк тушунуп, жоюп кете алабыз, — деп ойлоду Иван. .
DevOps үчүн жеткирүү убактысын кантип эсептөө керек
Аны эсептөө үчүн DevOps процессине жана анын маңызына тереңдеп кириш керек болчу.
Компания чектелген сандагы системаларды колдонот жана маалыматты алардан гана алууга болот жана башка эч жерде болбойт.
Компаниядагы бардык тапшырмалар Жирада катталган. Тапшырма кабыл алынганда, ал үчүн бутак түзүлүп, ишке ашкандан кийин BitBucket жана Pull Request боюнча милдеттенме кабыл алынган. PR (Pull Request) кабыл алынганда, бөлүштүрүү автоматтык түрдө түзүлүп, Nexus репозиторийинде сакталган.
Андан кийин, жайылтуу, автоматтык жана кол менен тестирлөөнүн тууралыгын текшерүү үчүн Дженкинстин жардамы менен бир нече стенддерге жайылтылды:
Иван стенддердеги убакытты эсептөө үчүн кайсы системалардан кандай маалымат алынарын айтып берди:
- Nexus'тан - Бөлүштүрүү түзүү убактысы жана буйрук коду камтылган папканын аталышы
- Дженкинстен - Ар бир иштин башталышы, узактыгы жана натыйжасы, стенддин аты (жумуштун параметрлеринде), этаптары (жумуштун кадамдары), Nexus'та бөлүштүрүүгө шилтеме.
- Ivan, анткени, куур Jira жана BitBucket киргизүү үчүн эмес, чечти алар даяр бөлүштүрүүнү стенддерге жайылтууга эмес, иштеп чыгуу стадиясына көбүрөөк байланыштуу болгон.
Колдо болгон маалыматтардын негизинде төмөнкү диаграмма түзүлдү:
Бөлүштүрүүлөрдү түзүү үчүн канча убакыт талап кылынарын жана алардын ар бирине канча убакыт сарпталарын билип, сиз DevOps түтүгүн (толук цикл) өткөрүүнүн жалпы чыгымдарын оңой эсептей аласыз.
Бул жерде Иван аяктаган DevOps көрсөткүчтөрү:
- Түзүлгөн бөлүштүрүүнүн саны
- Стендге «келип» жана стендден «өткөн» бөлүштүрүүнүн үлүшү
- Стендде өткөргөн убакыт (стенд цикли)
- Толук цикл (бардык стенддер үчүн жалпы убакыт)
- Жумуштун узактыгы
- Трибуналардын ортосундагы токтоп калуу
- Ошол эле стендде ишке киргизилген жумуштун ортосундагы токтоп калуу
Бир жагынан алганда, көрсөткүчтөр DevOps түтүгүн убакыт жагынан абдан жакшы мүнөздөсө, экинчи жагынан, алар абдан жөнөкөй деп эсептелген.
Иштин жакшы аткарылышына канааттанган Иван презентация жасап, аны жетекчиликке көрсөтүү үчүн жөнөдү.
Ал капаланып, колун ылдый кылып кайтты.
"Бул фиаско, байке," ирониялуу кесиптеши жылмайып койду...
Кененирээк макалада окуңуз "«.
Source: www.habr.com