Шынымды айтсам, Иван мониторинг бөліміндегі әріптестерінің бос әрекетіне жиі күлетін. Олар компания басшылығы қол жеткізуді бұйырған көрсеткіштерді жүзеге асыру үшін көп күш жұмсады. Олардың қолдары босамайтыны сонша, олар ешкімнің ештеңе істегісі келмеді.
Бірақ менеджмент үшін бәрі жеткіліксіз болды - олар үнемі жаңа көрсеткіштерге тапсырыс беріп, бұрын жасалғандарды пайдалануды тез тоқтатты.
Соңғы уақытта барлығы LeadTime - бизнес мүмкіндіктерін жеткізу уақыты туралы айтып жүр. Метрика ақылсыз санды көрсетті - бір тапсырманы жеткізуге 200 күн. Барлығы қалай қобалжып, қолдарын аспанға көтерді!
Біраз уақыттан кейін шу бірте-бірте басылып, басшылық басқа метрика жасау туралы бұйрық алды.
Иванға жаңа метриканың қараңғы бұрышта тыныш өлетіні анық болды.
Шынында да, нөмірді білу ешкімге ештеңе айтпайды деп ойлады Иван. 200 күн немесе 2 күн - ешқандай айырмашылық жоқ, себебі сан арқылы себебін анықтау және оның жақсы немесе жаман екенін түсіну мүмкін емес.
Бұл метриканың әдеттегі тұзағы: жаңа метрика болмыстың мәнін айтып, қандай да бір құпия құпияны түсіндіретін сияқты. Барлығы бұған көп үміт артады, бірақ қандай да бір себептермен ештеңе болмайды. Иә, өйткені құпияны метрикадан таппау керек!
Иван үшін бұл өткен кезең болды. Ол мұны түсінді өлшемдер үшін және барлық құпияларды іздеу керек , яғни. бұл метрика қалыптасады.
Интернет-дүкен үшін әсер ету объектісі ақша әкелетін оның клиенттері болады, ал DevOps үшін құбыр желісі арқылы дистрибутивтерді жасайтын және шығаратын командалар болады.
Бір күні залдағы ыңғайлы креслоға отырып, Иван әсер ету объектісі командалар екенін ескере отырып, DevOps метрикасын қалай көргісі келетінін мұқият ойластыруды шешті.
DevOps метрикасының мақсаты
Әр адам жеткізу уақытын қысқартқысы келетіні анық. 200 күн, әрине, жақсы емес.
Бірақ қалай, бұл сұрақ?
Компанияда жүздеген командалар жұмыс істейді және күн сайын мыңдаған дистрибуциялар DevOps құбыры арқылы өтеді. Нақты жеткізу уақыты тарату ретінде көрсетіледі. Әр команданың өз уақыты мен өзіндік ерекшеліктері болады. Осы бейберекеттің арасынан бірдеңені қалай табуға болады?
Жауап табиғи түрде пайда болды - біз проблемалық командаларды тауып, олармен не болып жатқанын және неге бұл ұзаққа созылып жатқанын анықтауымыз керек және «жақсы» командалардан бәрін қалай тез орындау керектігін үйренуіміз керек. Мұны істеу үшін сіз DevOps стендтерінің әрқайсысында командалардың өткізген уақытын өлшеуіңіз керек:
«Жүйенің мақсаты командаларды стендтерден өту уақытына қарай таңдау болады, яғни. Нәтижесінде біз сан емес, таңдалған уақыты бар командалар тізімін алуымыз керек.
Стендке жалпы қанша уақыт кеткенін және стендтер арасындағы бос тұруға қанша уақыт кеткенін анықтасақ, біз командаларды тауып, оларға қоңырау шалып, себептерін толығырақ түсініп, оларды жоя аламыз», - деп ойлады Иван.
DevOps үшін жеткізу уақытын қалай есептеу керек
Оны есептеу үшін DevOps процесіне және оның мәніне тереңірек үңілу қажет болды.
Компания жүйелердің шектеулі санын пайдаланады және ақпаратты тек олардан алуға болады және басқа еш жерде болмайды.
Компаниядағы барлық тапсырмалар Jira-да тіркелген. Тапсырма қабылданған кезде, ол үшін филиал құрылды және орындағаннан кейін BitBucket және Pull Request-ке міндеттеме жасалды. PR (Pull Request) қабылданған кезде тарату автоматты түрде жасалып, Nexus репозиторийінде сақталды.
Содан кейін тарату, автоматты және қолмен тестілеудің дұрыстығын тексеру үшін Дженкинс көмегімен бірнеше стендтерде таратылды:
Иван стендтердегі уақытты есептеу үшін қандай жүйелерден қандай ақпаратты алуға болатынын сипаттады:
- Nexus жүйесінен – Таратуды жасау уақыты және пәрмен коды бар қалта атауы
- Дженкинс - әр тапсырманың басталу уақыты, ұзақтығы және нәтижесі, стенд атауы (жұмыс параметрлерінде), кезеңдері (тапсырма қадамдары), Nexus жүйесіндегі таратуға сілтеме.
- Иван Jira мен BitBucket-ті құбырға қоспауды шешті, өйткені олар дайын таратуды стендтерге шығаруға емес, әзірлеу кезеңіне көбірек қатысты болды.
Қолда бар мәліметтерге сүйене отырып, келесі диаграмма сызылған:
Таратуларды жасауға қанша уақыт кететінін және олардың әрқайсысына қанша уақыт жұмсалатынын біле отырып, сіз DevOps құбырын (толық цикл) өтудің жалпы шығындарын оңай есептей аласыз.
Міне, Иван жасаған DevOps көрсеткіштері:
- Жасалған таратулар саны
- Стендке «келіп» және стендтен «өткен» үлестіру үлесі
- Стендте жұмсалған уақыт (стенд циклі)
- Толық цикл (барлық стендтер үшін жалпы уақыт)
- Жұмыс ұзақтығы
- Трибуналар арасындағы үзіліс
- Бір стендте жұмысты бастау арасындағы үзіліс
Бір жағынан, метрика уақыт бойынша DevOps құбырын өте жақсы сипаттады, екінші жағынан, олар өте қарапайым деп саналды.
Жақсы атқарылған жұмысқа риза болған Иван презентация жасап, оны басшылыққа ұсынуға кетті.
Ол мұңайып, қолдарын төмен түсіріп оралды.
«Бұл фиаско, ағайын», - деп күлді ирониялық әріптес...
Толығырақ мақалада оқыңыз ««.
Ақпарат көзі: www.habr.com