உண்மையைச் சொல்வதானால், கண்காணிப்புத் துறையைச் சேர்ந்த தனது சக ஊழியர்களின் வீண் முயற்சிகளைப் பார்த்து இவன் அடிக்கடி சிரித்தான். நிறுவனத்தின் நிர்வாகம் தங்களுக்குக் கட்டளையிட்ட அளவீடுகளை செயல்படுத்த அவர்கள் பெரும் முயற்சிகளை மேற்கொண்டனர். வேறு யாரும் எதுவும் செய்ய வேண்டாம் என்று அவர்கள் மிகவும் பிஸியாக இருந்தனர்.
ஆனால் நிர்வாகத்திற்கு இது போதுமானதாக இல்லை - அவர்கள் தொடர்ந்து மேலும் மேலும் புதிய அளவீடுகளை ஆர்டர் செய்தனர், முன்பு செய்ததைப் பயன்படுத்துவதை மிக விரைவாக நிறுத்தினர்.
சமீபத்தில், எல்லோரும் LeadTime பற்றி பேசுகிறார்கள் - வணிக அம்சங்களை வழங்குவதற்கான நேரம். மெட்ரிக் ஒரு பைத்தியம் எண்ணைக் காட்டியது - ஒரு பணியை வழங்க 200 நாட்கள். எல்லோரும் எப்படி ஓஹோ, ஆஹோ மற்றும் வானத்தை நோக்கி தங்கள் கைகளை உயர்த்தினார்கள்!
சிறிது நேரம் கழித்து, சத்தம் படிப்படியாக குறைந்து, மற்றொரு மெட்ரிக்கை உருவாக்க நிர்வாகம் உத்தரவு பெற்றது.
புதிய மெட்ரிக் ஒரு இருண்ட மூலையில் அமைதியாக இறந்துவிடும் என்பது இவனுக்கு முற்றிலும் தெளிவாக இருந்தது.
உண்மையில், இவன் நினைத்தான், எண்ணைத் தெரிந்துகொள்வது யாரிடமும் எதுவும் சொல்லாது. 200 நாட்கள் அல்லது 2 நாட்கள் - எந்த வித்தியாசமும் இல்லை, ஏனென்றால் எண்ணின் மூலம் காரணத்தை தீர்மானிக்க முடியாது மற்றும் அது நல்லதா அல்லது கெட்டதா என்பதைப் புரிந்து கொள்ள முடியாது.
இது அளவீடுகளின் பொதுவான பொறி: ஒரு புதிய மெட்ரிக் இருப்பின் சாராம்சத்தைச் சொல்லும் மற்றும் சில ரகசிய ரகசியங்களை விளக்கும் என்று தெரிகிறது. எல்லோரும் இதை மிகவும் நம்புகிறார்கள், ஆனால் சில காரணங்களால் எதுவும் நடக்கவில்லை. ஆம், ஏனென்றால் ரகசியத்தை அளவீடுகளில் காணக்கூடாது!
இவனுக்கு இது ஒரு கடந்த நிலை. என்று புரிந்து கொண்டார் அளவீடுகளுக்கு, மற்றும் அனைத்து ரகசியங்களும் தேடப்பட வேண்டும் , அதாவது இந்த அளவீடு உருவாகிறது.
ஒரு ஆன்லைன் ஸ்டோருக்கு, செல்வாக்கின் பொருள் பணத்தை கொண்டு வரும் அதன் வாடிக்கையாளர்களாக இருக்கும், மேலும் DevOps ஐப் பொறுத்தவரை, இது குழாய்களைப் பயன்படுத்தி விநியோகங்களை உருவாக்கி வெளியிடும் குழுக்களாக இருக்கும்.
ஒரு நாள், ஹாலில் ஒரு வசதியான நாற்காலியில் உட்கார்ந்து, இவான் டெவொப்ஸ் அளவீடுகளை எவ்வாறு பார்க்க விரும்பினார் என்பதை கவனமாக சிந்திக்க முடிவு செய்தார், செல்வாக்கின் பொருள் அணிகள் என்ற உண்மையை கணக்கில் எடுத்துக்கொண்டார்.
DevOps அளவீடுகளின் நோக்கம்
எல்லோரும் டெலிவரி நேரத்தை குறைக்க விரும்புகிறார்கள் என்பது தெளிவாகிறது. 200 நாட்கள், நிச்சயமாக, நல்லதல்ல.
ஆனால் எப்படி, அது கேள்வி?
நிறுவனம் நூற்றுக்கணக்கான குழுக்களைப் பயன்படுத்துகிறது, மேலும் ஆயிரக்கணக்கான விநியோகங்கள் ஒவ்வொரு நாளும் DevOps குழாய் வழியாக செல்கின்றன. உண்மையான விநியோக நேரம் ஒரு விநியோகமாகத் தோன்றும். ஒவ்வொரு அணிக்கும் அதன் சொந்த நேரம் மற்றும் அதன் சொந்த பண்புகள் இருக்கும். இந்தக் குழப்பத்தில் எதையாவது எப்படிக் கண்டுபிடிப்பது?
பதில் இயற்கையாகவே எழுந்தது - பிரச்சனைக் குழுக்களைக் கண்டுபிடித்து அவர்களுடன் என்ன நடக்கிறது, ஏன் இவ்வளவு நேரம் எடுக்கிறது என்பதைக் கண்டுபிடித்து, எல்லாவற்றையும் விரைவாகச் செய்வது எப்படி என்பதை "நல்ல" குழுக்களிடமிருந்து கற்றுக்கொள்ள வேண்டும். இதைச் செய்ய, ஒவ்வொரு DevOps ஸ்டாண்டிலும் அணிகள் செலவழித்த நேரத்தை நீங்கள் அளவிட வேண்டும்:
"இந்த அமைப்பின் நோக்கம் அணிகளை அவர்கள் ஸ்டாண்டுகளை கடந்து செல்லும் நேரத்தின் அடிப்படையில் தேர்ந்தெடுப்பதாகும், அதாவது. இதன் விளைவாக, தேர்ந்தெடுக்கப்பட்ட நேரத்துடன் கட்டளைகளின் பட்டியலைப் பெற வேண்டும், எண் அல்ல.
மொத்தத்தில் ஸ்டாண்டில் எவ்வளவு நேரம் செலவழிக்கப்பட்டது, ஸ்டாண்டுகளுக்கு இடையில் எவ்வளவு நேரம் செலவழிக்கப்பட்டது என்பதைக் கண்டுபிடித்தால், அணிகளைக் கண்டுபிடித்து, அவர்களை அழைத்து, காரணங்களை இன்னும் விரிவாகப் புரிந்துகொண்டு அவற்றை அகற்றலாம், ”என்று இவன் நினைத்தான்.
DevOps க்கான டெலிவரி நேரத்தை எவ்வாறு கணக்கிடுவது
அதைக் கணக்கிட, DevOps செயல்முறை மற்றும் அதன் சாரத்தை ஆராய வேண்டியது அவசியம்.
நிறுவனம் ஒரு குறிப்பிட்ட எண்ணிக்கையிலான அமைப்புகளைப் பயன்படுத்துகிறது, மேலும் தகவல்களை அவர்களிடமிருந்து மட்டுமே பெற முடியும், வேறு எங்கும் இல்லை.
நிறுவனத்தில் உள்ள அனைத்து பணிகளும் ஜிராவில் பதிவு செய்யப்பட்டன. ஒரு பணி எடுக்கப்பட்டதும், அதற்கென ஒரு கிளை உருவாக்கப்பட்டது, செயல்படுத்தப்பட்ட பிறகு, பிட்பக்கெட் மற்றும் புல் கோரிக்கைக்கு உறுதியளிக்கப்பட்டது. ஒரு PR (இழுக்கும் கோரிக்கை) ஏற்றுக்கொள்ளப்பட்டதும், ஒரு விநியோகம் தானாகவே உருவாக்கப்பட்டு Nexus களஞ்சியத்தில் சேமிக்கப்படும்.
அடுத்து, ரோல்அவுட், தானியங்கி மற்றும் கையேடு சோதனையின் சரியான தன்மையை சரிபார்க்க ஜென்கின்ஸ் பயன்படுத்தி பல ஸ்டாண்டுகளில் விநியோகம் செய்யப்பட்டது:
ஸ்டாண்டில் நேரத்தைக் கணக்கிட எந்தெந்த அமைப்புகளில் இருந்து என்ன தகவல்களை எடுக்கலாம் என்பதை இவான் விவரித்தார்:
- Nexus இலிருந்து - விநியோக உருவாக்கும் நேரம் மற்றும் கட்டளைக் குறியீட்டைக் கொண்ட கோப்புறையின் பெயர்
- ஜென்கின்ஸ் - ஒவ்வொரு வேலையின் தொடக்க நேரம், கால அளவு மற்றும் முடிவு, நிலைப் பெயர் (வேலை அளவுருக்களில்), நிலைகள் (வேலைப் படிகள்), Nexus இல் விநியோகத்திற்கான இணைப்பு.
- பைப்லைனில் ஜிராவையும் பிட்பக்கெட்டையும் சேர்க்க வேண்டாம் என்று இவன் முடிவு செய்தான், ஏனென்றால்... அவை வளர்ச்சி நிலையுடன் தொடர்புடையவை, மேலும் முடிக்கப்பட்ட விநியோகத்தை ஸ்டாண்டுகளில் வெளியிடுவதற்கு அல்ல.
கிடைக்கக்கூடிய தகவல்களின் அடிப்படையில், பின்வரும் வரைபடம் வரையப்பட்டது:
விநியோகங்களை உருவாக்க எவ்வளவு நேரம் ஆகும் மற்றும் அவை ஒவ்வொன்றிற்கும் எவ்வளவு நேரம் செலவிடப்படுகிறது என்பதை அறிந்து, முழு DevOps பைப்லைன் (முழு சுழற்சி) வழியாகச் செல்வதற்கான மொத்த செலவுகளை நீங்கள் எளிதாகக் கணக்கிடலாம்.
இவன் முடித்த DevOps அளவீடுகள் இதோ:
- உருவாக்கப்பட்ட விநியோகங்களின் எண்ணிக்கை
- ஸ்டாண்டிற்கு "வந்த" மற்றும் ஸ்டாண்டை "கடந்த" விநியோகங்களின் பங்கு
- ஸ்டாண்டில் செலவழித்த நேரம் (ஸ்டாண்ட் சுழற்சி)
- முழு சுழற்சி (அனைத்து ஸ்டாண்டுகளுக்கும் மொத்த நேரம்)
- வேலை காலம்
- ஸ்டாண்டுகளுக்கு இடையில் வேலையில்லா நேரம்
- அதே நிலைப்பாட்டில் வேலை தொடங்குவதற்கு இடையில் வேலையில்லா நேரம்
ஒருபுறம், அளவீடுகள் DevOps பைப்லைனை நேரத்தின் அடிப்படையில் சிறப்பாக வகைப்படுத்தின, மறுபுறம், அவை மிகவும் எளிமையானதாகக் கருதப்பட்டன.
நல்ல வேலையில் திருப்தி அடைந்த இவன் ஒரு பிரசன்டேஷன் செய்து நிர்வாகத்திடம் கொடுக்கச் சென்றான்.
அவர் இருளாகவும் கைகளை கீழுமாக கொண்டு திரும்பி வந்தார்.
"இது ஒரு படுதோல்வி, அண்ணா," முரண்பாடான சக ஊழியர் சிரித்தார் ...
கட்டுரையில் மேலும் வாசிக்க "".
ஆதாரம்: www.habr.com