ரஷ்யாவில் DevOps நிலை 2020

ஒரு பொருளின் நிலையை எவ்வாறு புரிந்துகொள்வது?

பல்வேறு தகவல் மூலங்களிலிருந்து உருவாக்கப்பட்ட உங்கள் கருத்தை நீங்கள் நம்பலாம், எடுத்துக்காட்டாக, வலைத்தளங்கள் அல்லது அனுபவத்தில் உள்ள வெளியீடுகள். நீங்கள் சக ஊழியர்கள், அறிமுகமானவர்களிடம் கேட்கலாம். மாநாடுகளின் தலைப்புகளைப் பார்ப்பது மற்றொரு விருப்பம்: நிரல் குழு தொழில்துறையின் செயலில் உள்ள பிரதிநிதிகள், எனவே பொருத்தமான தலைப்புகளைத் தேர்ந்தெடுப்பதில் நாங்கள் அவர்களை நம்புகிறோம். ஒரு தனி பகுதி ஆராய்ச்சி மற்றும் அறிக்கைகள். ஆனால் ஒரு பிரச்சனை இருக்கிறது. DevOps இன் நிலை குறித்த ஆராய்ச்சி உலகில் ஆண்டுதோறும் நடத்தப்படுகிறது, வெளிநாட்டு நிறுவனங்களால் அறிக்கைகள் வெளியிடப்படுகின்றன, மேலும் ரஷ்ய DevOps பற்றி எந்த தகவலும் இல்லை.

ஆனால் அத்தகைய ஆய்வு நடத்தப்பட்ட நாள் வந்துவிட்டது, இன்று நாம் முடிவுகளைப் பற்றி பேசுவோம். ரஷ்யாவில் DevOps இன் நிலை நிறுவனங்கள் கூட்டாக ஆய்வு செய்யப்பட்டது "எக்ஸ்பிரஸ் 42"மேலும்"ஒன்டிகோ". எக்ஸ்பிரஸ் 42 தொழில்நுட்ப நிறுவனங்களுக்கு DevOps நடைமுறைகள் மற்றும் கருவிகளை செயல்படுத்தவும் மேம்படுத்தவும் உதவுகிறது மற்றும் ரஷ்யாவில் DevOps பற்றி முதலில் பேசியவர்களில் ஒருவர். ஆய்வின் ஆசிரியர்கள், இகோர் குரோச்ச்கின் மற்றும் விட்டலி கபரோவ், எக்ஸ்பிரஸ் 42 இல் பகுப்பாய்வு மற்றும் ஆலோசனையில் ஈடுபட்டுள்ளனர், அதே நேரத்தில் வெவ்வேறு நிறுவனங்களில் செயல்பாடு மற்றும் அனுபவத்தின் தொழில்நுட்ப பின்னணியைக் கொண்டுள்ளனர். 8 ஆண்டுகளாக, சகாக்கள் டஜன் கணக்கான நிறுவனங்கள் மற்றும் திட்டங்களை - ஸ்டார்ட்அப்கள் முதல் நிறுவனங்கள் வரை - வெவ்வேறு சிக்கல்களுடன், வெவ்வேறு கலாச்சார மற்றும் பொறியியல் முதிர்ச்சியுடன் பார்த்துள்ளனர்.

தங்கள் அறிக்கையில், இகோர் மற்றும் விட்டலி ஆராய்ச்சியின் செயல்பாட்டில் என்ன சிக்கல்கள் இருந்தன, அவற்றை எவ்வாறு தீர்த்தார்கள், அதே போல் DevOps ஆராய்ச்சி எவ்வாறு கொள்கையளவில் நடத்தப்படுகிறது மற்றும் எக்ஸ்பிரஸ் 42 அதன் சொந்தமாக நடத்த முடிவு செய்தது. அவர்களின் அறிக்கையை பார்க்கலாம் இங்கே.

DevOps ஆராய்ச்சி

உரையாடலை இகோர் குரோச்ச்கின் தொடங்கினார்.

DevOps மாநாடுகளில் பார்வையாளர்களிடம், “இந்த ஆண்டுக்கான DevOps நிலை அறிக்கையைப் படித்தீர்களா?” என்று நாங்கள் தொடர்ந்து கேட்கிறோம். சிலர் கைகளை உயர்த்துகிறார்கள், மூன்றில் ஒரு பகுதியினர் மட்டுமே அவற்றைப் படிப்பதாக எங்கள் ஆய்வு காட்டுகிறது. இதுபோன்ற அறிக்கைகளை நீங்கள் பார்த்ததில்லை என்றால், அவை அனைத்தும் மிகவும் ஒத்தவை என்று இப்போதே சொல்லலாம். பெரும்பாலும் இதுபோன்ற சொற்றொடர்கள் உள்ளன: "கடந்த ஆண்டுடன் ஒப்பிடும்போது ..."

இங்கே எங்களுக்கு முதல் சிக்கல் உள்ளது, அதன் பிறகு மேலும் இரண்டு:

1. கடந்த ஆண்டிற்கான தரவு எங்களிடம் இல்லை. ரஷ்யாவில் DevOps இன் நிலை யாருக்கும் ஆர்வமில்லை;
2. முறை. கருதுகோள்களை எவ்வாறு சோதிப்பது, கேள்விகளை எவ்வாறு உருவாக்குவது, எவ்வாறு பகுப்பாய்வு செய்வது, முடிவுகளை ஒப்பிடுவது, இணைப்புகளைக் கண்டறிவது என்பது தெளிவாகத் தெரியவில்லை;
3. சொற்களஞ்சியம். அனைத்து அறிக்கைகளும் ஆங்கிலத்தில் உள்ளன, மொழிபெயர்ப்பு தேவை, ஒரு பொதுவான DevOps கட்டமைப்பு இன்னும் கண்டுபிடிக்கப்படவில்லை, மேலும் ஒவ்வொருவரும் தங்களுக்கு சொந்தமானதைக் கொண்டு வருகிறார்கள்.

DevOps நிலை பகுப்பாய்வு உலகம் முழுவதும் எவ்வாறு செய்யப்பட்டுள்ளது என்பதைப் பார்ப்போம்.

வரலாற்று பின்னணி

DevOps ஆராய்ச்சி 2011 முதல் நடத்தப்பட்டது. உள்ளமைவு மேலாண்மை அமைப்புகளின் உருவாக்குநரான பப்பட், முதலில் அவற்றை நடத்தினார். அந்த நேரத்தில், குறியீட்டு வடிவில் உள்கட்டமைப்பை விவரிப்பதற்கான முக்கிய கருவிகளில் ஒன்றாகும். 2013 வரை, இந்த ஆய்வுகள் மூடப்பட்ட ஆய்வுகள் மற்றும் பொது அறிக்கைகள் இல்லை.

2013 இல், DevOps இல் உள்ள அனைத்து முக்கிய புத்தகங்களின் வெளியீட்டாளரான IT Revolution தோன்றியது. பப்பட் உடன் சேர்ந்து, அவர்கள் முதல் ஸ்டேட் ஆஃப் டெவொப்ஸ் வெளியீட்டைத் தயாரித்தனர், அங்கு 4 முக்கிய அளவீடுகள் முதல் முறையாகத் தோன்றின. அடுத்த ஆண்டு, தொழில் நடைமுறைகள் மற்றும் கருவிகள் குறித்த வழக்கமான தொழில்நுட்ப ரேடார்களுக்கு பெயர் பெற்ற ஆலோசனை நிறுவனமான ThoughtWorks ஈடுபட்டது. மேலும் 2015 ஆம் ஆண்டில், முறையுடன் ஒரு பிரிவு சேர்க்கப்பட்டது, மேலும் அவை எவ்வாறு பகுப்பாய்வைச் செய்கின்றன என்பது தெளிவாகியது.

2016 ஆம் ஆண்டில், ஆய்வின் ஆசிரியர்கள், தங்கள் சொந்த நிறுவனமான DORA (DevOps ஆராய்ச்சி மற்றும் மதிப்பீடு) உருவாக்கி, ஒரு வருடாந்திர அறிக்கையை வெளியிட்டனர். அடுத்த ஆண்டு, DORA மற்றும் பப்பட் ஆகியவை தங்கள் கடைசி கூட்டு அறிக்கையை வெளியிட்டன.

பின்னர் சுவாரஸ்யமான ஒன்று தொடங்கியது:

2018 ஆம் ஆண்டில், நிறுவனங்கள் பிரிந்து இரண்டு சுயாதீன அறிக்கைகள் வெளியிடப்பட்டன: ஒன்று பப்பட், இரண்டாவது கூகுளுடன் இணைந்து டோரா. முக்கிய அளவீடுகள், செயல்திறன் விவரக்குறிப்புகள் மற்றும் முக்கிய அளவீடுகள் மற்றும் நிறுவன அளவிலான செயல்திறனை பாதிக்கும் பொறியியல் நடைமுறைகள் ஆகியவற்றுடன் DORA அதன் வழிமுறைகளை தொடர்ந்து பயன்படுத்துகிறது. பப்பட் அதன் சொந்த அணுகுமுறையை செயல்முறை மற்றும் DevOps இன் பரிணாமத்தின் விளக்கத்துடன் வழங்கியது. ஆனால் கதை வேரூன்றவில்லை, 2019 ஆம் ஆண்டில் பப்பட் இந்த முறையை கைவிட்டு, அறிக்கைகளின் புதிய பதிப்பை வெளியிட்டது, இது முக்கிய நடைமுறைகள் மற்றும் அவர்களின் பார்வையில் DevOps ஐ எவ்வாறு பாதிக்கிறது என்பதை பட்டியலிட்டது. பின்னர் மற்றொரு நிகழ்வு நடந்தது: கூகிள் டோராவை வாங்கியது, மேலும் அவர்கள் ஒன்றாக மற்றொரு அறிக்கையை வெளியிட்டனர். நீங்கள் அவரைப் பார்த்திருக்கலாம்.

இந்த ஆண்டு, விஷயங்கள் சிக்கலாகிவிட்டன. பப்பட் அதன் சொந்த கணக்கெடுப்பைத் தொடங்கியுள்ளது. அவர்கள் எங்களை விட ஒரு வாரம் முன்னதாகவே செய்தார்கள், அது ஏற்கனவே முடிந்துவிட்டது. அதில் பங்கேற்று அவர்கள் எந்தெந்த தலைப்புகளில் ஆர்வமாக உள்ளனர் என்று பார்த்தோம். இப்போது பப்பட் அதன் பகுப்பாய்வு செய்து அறிக்கையை வெளியிட தயாராகி வருகிறது.

ஆனால் டோரா மற்றும் கூகுளிடம் இருந்து இன்னும் எந்த அறிவிப்பும் வரவில்லை. மே மாதம், பொதுவாக கணக்கெடுப்பு தொடங்கிய போது, ​​டோராவின் நிறுவனர்களில் ஒருவரான நிக்கோல் ஃபோர்ஸ்கிரென் வேறு நிறுவனத்திற்கு மாறியதாக தகவல் வந்தது. எனவே, இந்த ஆண்டு டோராவிடமிருந்து எந்த ஆராய்ச்சியும் அறிக்கையும் இருக்காது என்று நாங்கள் கருதினோம்.

ரஷ்யாவில் விஷயங்கள் எப்படி இருக்கின்றன?

நாங்கள் DevOps ஆராய்ச்சி செய்யவில்லை. நாங்கள் மாநாடுகளில் பேசினோம், மற்றவர்களின் கண்டுபிடிப்புகளை மறுபரிசீலனை செய்தோம், மேலும் Raiffeisenbank 2019 ஆம் ஆண்டிற்கான "DevOps மாநிலத்தை" மொழிபெயர்த்துள்ளது (Habré இல் அவர்களின் அறிவிப்பை நீங்கள் காணலாம்), அவர்களுக்கு நன்றி. மற்றும் அது அனைத்து.

எனவே, DORA முறைகள் மற்றும் கண்டுபிடிப்புகளைப் பயன்படுத்தி நாங்கள் ரஷ்யாவில் எங்கள் சொந்த ஆராய்ச்சியை மேற்கொண்டோம். எங்கள் ஆராய்ச்சிக்காக Raiffeisenbank இன் சக ஊழியர்களின் அறிக்கையைப் பயன்படுத்தினோம், இதில் சொற்கள் மற்றும் மொழிபெயர்ப்பின் ஒத்திசைவு உட்பட. மற்றும் தொழில் தொடர்பான கேள்விகள் DORA அறிக்கைகள் மற்றும் இந்த ஆண்டு பப்பட் கேள்வித்தாளில் இருந்து எடுக்கப்பட்டது.

ஆராய்ச்சி செயல்முறை

அறிக்கை இறுதிப் பகுதி மட்டுமே. முழு ஆராய்ச்சி செயல்முறையும் நான்கு முக்கிய படிகளைக் கொண்டுள்ளது:

தயாரிப்பு கட்டத்தில், நாங்கள் தொழில் வல்லுநர்களை நேர்காணல் செய்து கருதுகோள்களின் பட்டியலைத் தயாரித்தோம். அவற்றின் அடிப்படையில், வினாக்கள் தொகுக்கப்பட்டு ஆகஸ்ட் மாதம் முழுவதும் கணக்கெடுப்பு தொடங்கப்பட்டது. பின்னர் நாங்கள் ஆய்வு செய்து அறிக்கையை தயார் செய்தோம். DORA க்கு, இந்த செயல்முறை 6 மாதங்கள் ஆகும். நாங்கள் 3 மாதங்களுக்குள் சந்தித்தோம், இப்போது எங்களுக்கு போதுமான நேரம் இல்லை என்பதை நாங்கள் புரிந்துகொள்கிறோம்: பகுப்பாய்வு செய்வதன் மூலம் மட்டுமே நீங்கள் என்ன கேள்விகளைக் கேட்க வேண்டும் என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள்.

பங்கேற்பாளர்கள்

அனைத்து வெளிநாட்டு அறிக்கைகளும் பங்கேற்பாளர்களின் உருவப்படத்துடன் தொடங்குகின்றன, மேலும் அவர்களில் பெரும்பாலோர் ரஷ்யாவைச் சேர்ந்தவர்கள் அல்ல. ரஷ்ய பதிலளித்தவர்களின் சதவீதம் ஆண்டுதோறும் 5 முதல் 1% வரை மாறுபடும், மேலும் இது எந்த முடிவுகளையும் எடுக்க அனுமதிக்காது.

விரைவான DevOps 2019 அறிக்கையின் வரைபடம்:

எங்கள் ஆய்வில், நாங்கள் 889 பேரை நேர்காணல் செய்ய முடிந்தது - இது மிகவும் அதிகம் (DORA வாக்கெடுப்பு அதன் அறிக்கைகளில் ஆண்டுதோறும் ஆயிரம் பேர்) மற்றும் இங்கே நாங்கள் இலக்கை அடைந்துள்ளோம்:

உண்மை, எங்கள் பங்கேற்பாளர்கள் அனைவரும் முடிவை எட்டவில்லை: நிறைவு சதவீதம் பாதியை விட சற்று குறைவாக இருந்தது. ஆனால் இது ஒரு பிரதிநிதி மாதிரியைப் பெறுவதற்கும் பகுப்பாய்வு செய்வதற்கும் போதுமானதாக இருந்தது. DORA அதன் அறிக்கைகளில் நிரப்பு சதவீதங்களை வெளியிடவில்லை, எனவே இங்கு எந்த ஒப்பீடும் இல்லை.

தொழில்கள் மற்றும் பதவிகள்

எங்கள் பதிலளித்தவர்கள் ஒரு டஜன் தொழில்களை பிரதிநிதித்துவப்படுத்துகின்றனர். தகவல் தொழில்நுட்பத்தில் பாதி வேலை. இதைத் தொடர்ந்து நிதிச் சேவைகள், வர்த்தகம், தொலைத்தொடர்பு மற்றும் பிற. பதவிகளில் வல்லுநர்கள் (டெவலப்பர், சோதனையாளர், செயல்பாட்டு பொறியாளர்) மற்றும் மேலாண்மை ஊழியர்கள் (அணிகளின் தலைவர்கள், குழுக்கள், பகுதிகள், இயக்குநர்கள்):

இரண்டில் ஒருவர் நடுத்தர நிறுவனத்தில் வேலை செய்கிறார். ஒவ்வொரு மூன்றாவது நபரும் பெரிய நிறுவனங்களில் வேலை செய்கிறார்கள். பெரும்பாலானவர்கள் 9 பேர் கொண்ட குழுக்களில் வேலை செய்கிறார்கள். தனித்தனியாக, முக்கிய செயல்பாடுகளைப் பற்றி நாங்கள் கேட்டோம், பெரும்பான்மையானவை எப்படியாவது செயல்பாட்டுடன் தொடர்புடையவை, மேலும் சுமார் 40% வளர்ச்சியில் ஈடுபட்டுள்ளன:

எனவே பல்வேறு தொழில்கள், நிறுவனங்கள், குழுக்களின் பிரதிநிதிகளின் ஒப்பீடு மற்றும் பகுப்பாய்வுக்கான தகவல்களை நாங்கள் சேகரித்தோம். எனது சகா விட்டலி கபரோவ் பகுப்பாய்வு பற்றி கூறுவார்.

பகுப்பாய்வு மற்றும் ஒப்பீடு

விட்டலி கபரோவ்: எங்கள் ஆய்வை முடித்து, கேள்வித்தாள்களை நிரப்பி, எங்கள் கருதுகோள்களை மேலும் பகுப்பாய்வு செய்வதற்கும் சோதனை செய்வதற்கும் தரவை வழங்கிய அனைத்து பங்கேற்பாளர்களுக்கும் நன்றி. எங்கள் வாடிக்கையாளர்கள் மற்றும் வாடிக்கையாளர்களுக்கு நன்றி, தொழில்துறை கவலைகளை அடையாளம் காணவும், எங்கள் ஆராய்ச்சியில் நாங்கள் சோதித்த கருதுகோள்களை உருவாக்கவும் உதவிய அனுபவச் செல்வம் எங்களிடம் உள்ளது.

துரதிர்ஷ்டவசமாக, நீங்கள் ஒருபுறம் கேள்விகளின் பட்டியலையும் மறுபுறம் தரவையும் எடுக்க முடியாது, எப்படியாவது அவற்றை ஒப்பிட்டு, சொல்லுங்கள்: “ஆம், எல்லாம் அப்படித்தான் செயல்படுகிறது, நாங்கள் சரியாக இருந்தோம்” மற்றும் கலைந்து செல்லுங்கள். இல்லை, நாம் தவறாக நினைக்கவில்லை என்பதையும், எங்கள் முடிவுகள் நம்பகமானவை என்பதையும் உறுதிப்படுத்த, முறை மற்றும் புள்ளிவிவர முறைகள் தேவை. இந்த தரவுகளின் அடிப்படையில் எங்கள் அடுத்த வேலையை உருவாக்கலாம்:

முக்கிய அளவீடுகள்

நாங்கள் DORA முறையை அடிப்படையாக எடுத்துக் கொண்டோம், அதை அவர்கள் “Accelerate State of DevOps” புத்தகத்தில் விரிவாக விவரித்துள்ளனர். முக்கிய அளவீடுகள் ரஷ்ய சந்தைக்கு பொருத்தமானதா என்பதை நாங்கள் சோதித்தோம், "ரஷ்யாவில் உள்ள தொழில் வெளிநாட்டுத் தொழிலுடன் எவ்வாறு ஒத்துப்போகிறது?" என்ற கேள்விக்கு பதிலளிக்க DORA பயன்படுத்தும் அதே வழியில் அவற்றைப் பயன்படுத்த முடியுமா?

முக்கிய அளவீடுகள்:

1. வரிசைப்படுத்தல் அதிர்வெண். பயன்பாட்டின் புதிய பதிப்பு எவ்வளவு அடிக்கடி உற்பத்தி சூழலில் பயன்படுத்தப்படுகிறது (திட்டமிடப்பட்ட மாற்றங்கள், ஹாட்ஃபிக்ஸ்கள் மற்றும் சம்பவ பதில்களைத் தவிர்த்து)?
2. டெலிவரி நேரம். ஒரு மாற்றத்தைச் செய்வதற்கும் (செயல்பாட்டைக் குறியீடாக எழுதுவதற்கும்) உற்பத்திச் சூழலுக்கு மாற்றத்தைப் பயன்படுத்துவதற்கும் இடையிலான சராசரி நேரம் என்ன?
3. மீட்பு நேரம். ஒரு சம்பவம், சேவைச் சிதைவு அல்லது பயன்பாட்டுப் பயனர்களைப் பாதிக்கும் பிழையைக் கண்டறிந்த பிறகு, ஒரு பயன்பாட்டை உற்பத்திச் சூழலுக்கு மீட்டமைக்க சராசரியாக எவ்வளவு நேரம் ஆகும்?
4. தோல்வியுற்ற மாற்றங்கள். உற்பத்திச் சூழலில் எத்தனை சதவீத வரிசைப்படுத்தல்கள் பயன்பாட்டுச் சிதைவு அல்லது சம்பவங்களுக்கு இட்டுச் செல்கின்றன மற்றும் அதற்குத் தீர்வு தேவை (மாற்றங்களைத் திரும்பப் பெறுதல், ஹாட்ஃபிக்ஸ் அல்லது பேட்ச் உருவாக்கம்)?

டோரா தனது ஆராய்ச்சியில் இந்த அளவீடுகளுக்கும் நிறுவன செயல்திறனுக்கும் இடையே ஒரு தொடர்பைக் கண்டறிந்துள்ளது. நாங்கள் அதை எங்கள் ஆய்விலும் சோதிக்கிறோம்.

ஆனால் நான்கு முக்கிய அளவீடுகள் எதையாவது பாதிக்கக்கூடும் என்பதை உறுதிப்படுத்த, நீங்கள் புரிந்து கொள்ள வேண்டும் - அவை எப்படியாவது ஒருவருக்கொருவர் தொடர்புடையதா? DORA ஒரு எச்சரிக்கையுடன் உறுதிமொழியாக பதிலளித்தது: தோல்வியுற்ற மாற்றங்கள் (தோல்வி விகிதத்தை மாற்றுதல்) மற்றும் மற்ற மூன்று அளவீடுகளுக்கு இடையிலான உறவு சற்று பலவீனமாக உள்ளது. அதே படத்தைப் பற்றி எங்களுக்கு கிடைத்தது. டெலிவரி நேரம், வரிசைப்படுத்தல் அதிர்வெண் மற்றும் மீட்பு நேரம் ஆகியவை ஒன்றோடொன்று தொடர்புடையதாக இருந்தால் (இந்த தொடர்பை நாங்கள் பியர்சன் தொடர்பு மற்றும் சாடாக் அளவுகோல் மூலம் நிறுவினோம்), தோல்வியுற்ற மாற்றங்களுடன் அத்தகைய வலுவான தொடர்பு எதுவும் இல்லை.

கொள்கையளவில், பதிலளிப்பவர்களில் பெரும்பாலோர் தயாரிப்பில் சிறிய எண்ணிக்கையிலான சம்பவங்களைக் கொண்டுள்ளனர் என்று பதிலளிக்கின்றனர். தோல்வியுற்ற மாற்றங்களின் அடிப்படையில் பதிலளிப்பவர்களின் குழுக்களுக்கு இடையே இன்னும் குறிப்பிடத்தக்க வேறுபாடு உள்ளது என்பதை பின்னர் பார்ப்போம் என்றாலும், இந்த மெட்ரிக்கை இந்த பிரிவுக்கு இன்னும் பயன்படுத்த முடியாது.

(எங்கள் சில வாடிக்கையாளர்களுடனான பகுப்பாய்வு மற்றும் தகவல்தொடர்புகளின் போது இது மாறியது) ஒரு சம்பவமாகக் கருதப்படுவதைக் கருத்தில் கொள்வதில் ஒரு சிறிய வித்தியாசம் இருப்பதை நாங்கள் இதற்குக் காரணம் கூறுகிறோம். தொழில்நுட்ப சாளரத்தின் போது எங்கள் சேவையின் செயல்திறனை மீட்டெடுக்க முடிந்தால், இது ஒரு சம்பவமாக கருத முடியுமா? அநேகமாக இல்லை, நாங்கள் எல்லாவற்றையும் சரிசெய்ததால், நாங்கள் பெரியவர்கள். ஒரு சாதாரண, பழக்கமான முறையில் நமது விண்ணப்பத்தை 10 முறை மறுசீரமைக்க வேண்டியிருந்தால் அதை ஒரு சம்பவமாக கருதலாமா? இல்லை போலும். எனவே, மற்ற அளவீடுகளுடன் தோல்வியுற்ற மாற்றங்களின் உறவு பற்றிய கேள்வி திறந்தே உள்ளது. அதை மேலும் செம்மைப்படுத்துவோம்.

இங்கு முக்கியமானது, டெலிவரி நேரம், மீட்பு நேரங்கள் மற்றும் வரிசைப்படுத்தல் அதிர்வெண் ஆகியவற்றுக்கு இடையே குறிப்பிடத்தக்க தொடர்பைக் கண்டறிந்துள்ளோம். எனவே, பதிலளித்தவர்களை மேலும் செயல்திறன் குழுக்களாகப் பிரிக்க இந்த மூன்று அளவீடுகளையும் எடுத்தோம்.

கிராமுக்கு எவ்வளவு தொந்தரவு?

நாங்கள் படிநிலை கிளஸ்டர் பகுப்பாய்வைப் பயன்படுத்தினோம்:

• நாங்கள் ஒரு n-பரிமாண இடைவெளியில் பதிலளிப்பவர்களை விநியோகிக்கிறோம், அங்கு ஒவ்வொரு பதிலளிப்பவரின் ஒருங்கிணைப்பு கேள்விகளுக்கான பதில்களாகும்.
• ஒவ்வொரு பதிலளிப்பவரும் ஒரு சிறிய தொகுப்பாக அறிவிக்கப்பட்டுள்ளனர்.
• ஒன்றுக்கொன்று நெருங்கிய இரண்டு கொத்துக்களையும் ஒரு பெரிய கிளஸ்டராக இணைக்கிறோம்.
• அடுத்த ஜோடி கொத்துக்களைக் கண்டுபிடித்து அவற்றை ஒரு பெரிய கிளஸ்டராக இணைக்கிறோம்.

இப்படித்தான் எங்கள் பதிலளிப்பவர்கள் அனைவரையும் நமக்குத் தேவையான கிளஸ்டர்களின் எண்ணிக்கையில் தொகுக்கிறோம். ஒரு டென்ட்ரோகிராம் (கொத்துகளுக்கு இடையிலான இணைப்புகளின் மரம்) உதவியுடன், இரண்டு அண்டை கொத்துக்களுக்கு இடையிலான தூரத்தைக் காண்கிறோம். இந்த கொத்துக்களுக்கு இடையே ஒரு குறிப்பிட்ட தூர வரம்பை நிர்ணயித்து, "இந்த இரண்டு குழுக்களும் ஒருவருக்கொருவர் மிகவும் வித்தியாசமாக இருக்கின்றன, ஏனெனில் அவற்றுக்கிடையேயான தூரம் மிகப்பெரியது."

ஆனால் இங்கே ஒரு மறைக்கப்பட்ட சிக்கல் உள்ளது: கிளஸ்டர்களின் எண்ணிக்கையில் எங்களுக்கு எந்த கட்டுப்பாடுகளும் இல்லை - நாம் 2, 3, 4, 10 கிளஸ்டர்களைப் பெறலாம். முதல் யோசனை என்னவென்றால் - டோராவைப் போல எங்கள் பதிலளித்த அனைவரையும் ஏன் 4 குழுக்களாகப் பிரிக்கக்கூடாது. ஆனால் இந்த குழுக்களுக்கு இடையிலான வேறுபாடுகள் முக்கியமற்றவை என்பதை நாங்கள் கண்டறிந்தோம், மேலும் பதிலளிப்பவர் உண்மையில் அவரது குழுவைச் சேர்ந்தவர் என்பதை நாங்கள் உறுதியாக நம்ப முடியாது, அண்டைக்கு அல்ல. ரஷ்ய சந்தையை இன்னும் நான்கு குழுக்களாக பிரிக்க முடியாது. எனவே, புள்ளிவிவர ரீதியாக குறிப்பிடத்தக்க வேறுபாடு உள்ள மூன்று சுயவிவரங்களில் நாங்கள் குடியேறினோம்:

அடுத்து, சுயவிவரத்தை க்ளஸ்டர்கள் மூலம் தீர்மானித்தோம்: ஒவ்வொரு குழுவிற்கும் ஒவ்வொரு மெட்ரிக்கிற்கான சராசரியை எடுத்து செயல்திறன் சுயவிவரங்களின் அட்டவணையை தொகுத்தோம். உண்மையில், ஒவ்வொரு குழுவிலும் சராசரி பங்கேற்பாளரின் செயல்திறன் சுயவிவரங்களைப் பெற்றுள்ளோம். நாங்கள் மூன்று செயல்திறன் சுயவிவரங்களை அடையாளம் கண்டுள்ளோம்: குறைந்த, நடுத்தர, உயர்:

செயல்திறன் சுயவிவரத்தை தீர்மானிக்க 4 முக்கிய அளவீடுகள் பொருத்தமானவை என்ற எங்கள் கருதுகோளை இங்கே நாங்கள் உறுதிப்படுத்தினோம், மேலும் அவை மேற்கத்திய மற்றும் ரஷ்ய சந்தைகளில் வேலை செய்கின்றன. குழுக்களிடையே வேறுபாடு உள்ளது மற்றும் அது புள்ளியியல் ரீதியாக குறிப்பிடத்தக்கது. இந்த அளவுருவின் மூலம் நாங்கள் முதலில் பதிலளிப்பவர்களைப் பிரிக்காவிட்டாலும், சராசரியின் அடிப்படையில் தோல்வியுற்ற மாற்றங்களின் அளவீட்டின் அடிப்படையில் செயல்திறன் சுயவிவரங்களுக்கு இடையே குறிப்பிடத்தக்க வேறுபாடு உள்ளது என்பதை நான் வலியுறுத்துகிறேன்.

பின்னர் கேள்வி எழுகிறது: இதையெல்லாம் எவ்வாறு பயன்படுத்துவது?

எப்படி பயன்படுத்துவது

நாங்கள் எந்த அணியையும், 4 முக்கிய அளவீடுகளையும் எடுத்து அதை அட்டவணையில் பயன்படுத்தினால், 85% வழக்குகளில் முழுமையான போட்டியைப் பெற மாட்டோம் - இது ஒரு சராசரி பங்கேற்பாளர் மட்டுமே, உண்மையில் என்ன இல்லை. நாங்கள் அனைவரும் (மற்றும் ஒவ்வொரு அணியும்) சற்று வித்தியாசமாக இருக்கிறோம்.

நாங்கள் சரிபார்த்தோம்: நாங்கள் பதிலளித்தவர்களையும் DORA செயல்திறன் சுயவிவரத்தையும் எடுத்து, இந்த அல்லது அந்த சுயவிவரத்திற்கு எத்தனை பதிலளித்தவர்கள் பொருந்துகிறார்கள் என்பதைப் பார்த்தோம். பதிலளித்தவர்களில் 16% பேர் மட்டுமே சுயவிவரங்களில் ஒன்றில் நிச்சயமாக விழுந்துள்ளனர் என்பதைக் கண்டறிந்தோம். மீதமுள்ள அனைத்தும் இடையில் எங்காவது சிதறிக்கிடக்கின்றன:

இதன் பொருள் செயல்திறன் சுயவிவரம் வரையறுக்கப்பட்ட நோக்கத்தைக் கொண்டுள்ளது. முதல் தோராயத்தில் நீங்கள் எங்கு இருக்கிறீர்கள் என்பதைப் புரிந்துகொள்ள, இந்த அட்டவணையைப் பயன்படுத்தலாம்: "ஓ, நாங்கள் நடுத்தர அல்லது உயர்நிலைக்கு நெருக்கமாக இருப்பதாகத் தெரிகிறது!" அடுத்து எங்கு செல்ல வேண்டும் என்பதை நீங்கள் புரிந்து கொண்டால், இது போதுமானதாக இருக்கலாம். ஆனால் உங்கள் இலக்கு நிலையானது, தொடர்ச்சியான முன்னேற்றம், மற்றும் எங்கு உருவாக்குவது மற்றும் என்ன செய்வது என்பதை நீங்கள் இன்னும் சரியாக அறிய விரும்பினால், கூடுதல் நிதி தேவை. நாங்கள் அவற்றை கால்குலேட்டர்கள் என்று அழைத்தோம்:

• டோரா கால்குலேட்டர்
• கால்குலேட்டர் எக்ஸ்பிரஸ் 42* (வளர்ச்சியில் உள்ளது)
• சொந்த வளர்ச்சி (உங்கள் சொந்த உள் கால்குலேட்டரை உருவாக்கலாம்).

அவை எதற்கு தேவை? புரிந்துகொள்வதற்கு:

• எங்கள் நிறுவனத்தில் உள்ள குழு எங்கள் தரத்திற்கு ஏற்ப உள்ளதா?
• இல்லையென்றால், எங்கள் நிறுவனத்திற்கு இருக்கும் நிபுணத்துவத்தின் கட்டமைப்பிற்குள் நாம் அதற்கு உதவ முடியுமா?
• அப்படியானால், நாம் இன்னும் சிறப்பாக செய்ய முடியுமா?

நிறுவனத்திற்குள் புள்ளிவிவரங்களைச் சேகரிக்க நீங்கள் அவற்றைப் பயன்படுத்தலாம்:

• எங்களிடம் என்ன அணிகள் உள்ளன?
• அணிகளை சுயவிவரங்களாகப் பிரிக்கவும்;
• பார்க்கவும்: ஓ, இந்த கட்டளைகள் குறைவாக செயல்படுகின்றன (அவை சிறிதும் வெளியே இழுக்காது), ஆனால் இவை அருமையாக உள்ளன: அவை ஒவ்வொரு நாளும் வரிசைப்படுத்தப்படுகின்றன, பிழைகள் இல்லாமல், அவை ஒரு மணி நேரத்திற்கும் குறைவான நேரத்தைக் கொண்டுள்ளன.

எங்கள் நிறுவனத்தில் இன்னும் சமமாக இல்லாத அந்த அணிகளுக்கு தேவையான நிபுணத்துவம் மற்றும் கருவிகள் உள்ளன என்பதை நீங்கள் கண்டறியலாம்.

அல்லது, நிறுவனத்திற்குள் நீங்கள் நன்றாக உணர்கிறீர்கள், பலரை விட நீங்கள் சிறந்தவர் என்பதை நீங்கள் புரிந்து கொண்டால், நீங்கள் கொஞ்சம் அகலமாகத் தோன்றலாம். இது வெறும் ரஷ்யத் தொழில்: நம்மைத் துரிதப்படுத்த ரஷ்யத் தொழிலில் தேவையான நிபுணத்துவத்தைப் பெற முடியுமா? எக்ஸ்பிரஸ் 42 கால்குலேட்டர் இங்கே உதவும் (இது வளர்ச்சியில் உள்ளது). நீங்கள் ரஷ்ய சந்தையை விட அதிகமாக இருந்தால், பாருங்கள் டோரா கால்குலேட்டர் மற்றும் உலக சந்தைக்கு.

நன்றாக. நீங்கள் டோரா கால்குலேட்டரில் எலிட் குழுவில் இருந்தால், நீங்கள் என்ன செய்ய வேண்டும்? இங்கு நல்ல தீர்வு இல்லை. நீங்கள் தொழில்துறையில் முன்னணியில் இருப்பீர்கள், மேலும் முடுக்கம் மற்றும் நம்பகத்தன்மை உள் R&D மற்றும் அதிக வளங்களை செலவழிப்பதன் மூலம் சாத்தியமாகும்.

இனிமை - ஒப்பீட்டிற்குச் செல்வோம்.

ஒப்பீடு

நாங்கள் ஆரம்பத்தில் ரஷ்ய தொழில்துறையை மேற்கத்திய தொழில்துறையுடன் ஒப்பிட விரும்பினோம். நாம் நேரடியாக ஒப்பிட்டுப் பார்த்தால், எங்களிடம் குறைவான சுயவிவரங்கள் இருப்பதைக் காண்கிறோம், மேலும் அவை ஒன்றுடன் ஒன்று கலக்கப்படுகின்றன, எல்லைகள் இன்னும் கொஞ்சம் மங்கலாகின்றன:

எங்கள் எலைட் கலைஞர்கள் உயர் கலைஞர்களிடையே மறைக்கப்பட்டுள்ளனர், ஆனால் அவர்கள் இருக்கிறார்கள் - இவர்கள் உயரடுக்கு, யூனிகார்ன்கள் குறிப்பிடத்தக்க உயரங்களை எட்டியுள்ளனர். ரஷ்யாவில், எலைட் சுயவிவரத்திற்கும் உயர் சுயவிவரத்திற்கும் இடையிலான வேறுபாடு இன்னும் போதுமானதாக இல்லை. பொறியியல் கலாச்சாரத்தின் அதிகரிப்பு, பொறியியல் நடைமுறைகளை செயல்படுத்தும் தரம் மற்றும் நிறுவனங்களுக்குள் நிபுணத்துவம் ஆகியவற்றின் காரணமாக எதிர்காலத்தில் இந்த பிரிப்பு ஏற்படும் என்று நாங்கள் நினைக்கிறோம்.

ரஷ்ய தொழில்துறைக்குள் நாம் நேரடி ஒப்பீட்டிற்குச் சென்றால், உயர் சுயவிவர அணிகள் எல்லா வகையிலும் சிறப்பாக இருப்பதைக் காணலாம். இந்த அளவீடுகளுக்கும் நிறுவன செயல்திறனுக்கும் இடையே ஒரு தொடர்பு உள்ளது என்ற எங்கள் கருதுகோளை நாங்கள் உறுதிப்படுத்தினோம்: உயர்நிலை குழுக்கள் இலக்குகளை அடைவது மட்டுமல்லாமல், அவற்றை மீறுவதற்கும் அதிக வாய்ப்புள்ளது.
உயர்நிலை அணிகளாக மாறுவோம், அதோடு நின்றுவிடாதீர்கள்:

ஆனால் இந்த ஆண்டு சிறப்பு வாய்ந்தது, மேலும் ஒரு தொற்றுநோய்களில் நிறுவனங்கள் எவ்வாறு செயல்படுகின்றன என்பதைச் சரிபார்க்க நாங்கள் முடிவு செய்தோம்: உயர் சுயவிவரக் குழுக்கள் தொழில்துறை சராசரியை விட மிகச் சிறப்பாகச் செயல்படுகின்றன மற்றும் சிறப்பாக உணர்கின்றன:

• புதிய தயாரிப்புகளை வெளியிடுவதற்கான வாய்ப்பு 1,5-2 மடங்கு அதிகம்,
• பயன்பாட்டு உள்கட்டமைப்பின் நம்பகத்தன்மை மற்றும் / அல்லது செயல்திறனை மேம்படுத்த 2 மடங்கு அதிக வாய்ப்பு உள்ளது.

அதாவது, அவர்கள் ஏற்கனவே இருந்த திறன்கள் விரைவாக உருவாக்கவும், புதிய தயாரிப்புகளைத் தொடங்கவும், ஏற்கனவே உள்ள தயாரிப்புகளை மாற்றவும், அதன் மூலம் புதிய சந்தைகளையும் புதிய பயனர்களையும் வெல்வதற்கு உதவியது:

எங்கள் அணிகளுக்கு வேறு என்ன உதவியது?

பொறியியல் நடைமுறைகள்

நாங்கள் சோதித்த ஒவ்வொரு நடைமுறையிலும் குறிப்பிடத்தக்க கண்டுபிடிப்புகள் பற்றி நான் உங்களுக்கு கூறுவேன். ஒருவேளை வேறு ஏதாவது அணிகளுக்கு உதவியிருக்கலாம், ஆனால் நாங்கள் DevOps பற்றி பேசுகிறோம். DevOps இல், வெவ்வேறு சுயவிவரங்களின் குழுக்களிடையே வித்தியாசத்தைக் காண்கிறோம்.

ஒரு சேவையாக இயங்குதளம்

பிளாட்ஃபார்ம் வயதுக்கும் குழு சுயவிவரத்திற்கும் இடையே குறிப்பிடத்தக்க தொடர்பை நாங்கள் கண்டறியவில்லை: குறைந்த அணிகள் மற்றும் உயர் அணிகள் இரண்டிற்கும் ஒரே நேரத்தில் இயங்குதளங்கள் தோன்றின. ஆனால் பிந்தையவற்றுக்கு, நிரல் குறியீடு மூலம் கட்டுப்படுத்துவதற்கு சராசரியாக அதிக சேவைகள் மற்றும் அதிக நிரலாக்க இடைமுகங்களை இயங்குதளம் வழங்குகிறது. மேலும் பிளாட்ஃபார்ம் அணிகள் தங்கள் டெவலப்பர்கள் மற்றும் குழுக்களுக்கு பிளாட்ஃபார்மைப் பயன்படுத்தவும், அவர்களின் பிரச்சனைகள் மற்றும் பிளாட்ஃபார்ம் தொடர்பான சம்பவங்களை அடிக்கடி தீர்க்கவும், மற்ற அணிகளுக்கு கல்வி கற்பிக்கவும் உதவும்.

குறியீடாக உள்கட்டமைப்பு

இங்கே எல்லாம் மிகவும் நிலையானது. உள்கட்டமைப்புக் குறியீட்டின் வேலையை தானியக்கமாக்குவதற்கும், உள்கட்டமைப்பு களஞ்சியத்தில் எவ்வளவு தகவல் சேமிக்கப்படுகிறது என்பதற்கும் இடையே ஒரு தொடர்பைக் கண்டறிந்துள்ளோம். உயர் சுயவிவர கட்டளைகள் களஞ்சியங்களில் கூடுதல் தகவல்களைச் சேமிக்கின்றன: இது உள்கட்டமைப்பு உள்ளமைவு, CI / CD பைப்லைன், சுற்றுச்சூழல் அமைப்புகள் மற்றும் உருவாக்க அளவுருக்கள். அவை இந்தத் தகவலை அடிக்கடி சேமித்து வைக்கின்றன, உள்கட்டமைப்புக் குறியீட்டுடன் சிறப்பாகச் செயல்படுகின்றன, மேலும் உள்கட்டமைப்புக் குறியீட்டுடன் பணிபுரிவதற்கான கூடுதல் செயல்முறைகள் மற்றும் பணிகளை தானியக்கமாக்குகின்றன.

சுவாரஸ்யமாக, உள்கட்டமைப்பு சோதனைகளில் குறிப்பிடத்தக்க வேறுபாட்டை நாங்கள் காணவில்லை. பொதுவாக உயர்நிலைக் குழுக்கள் அதிக சோதனைத் தன்னியக்கத்தைக் கொண்டிருப்பதே இதற்குக் காரணம். உள்கட்டமைப்பு சோதனைகளால் அவர்கள் தனித்தனியாக திசைதிருப்பப்படக்கூடாது, மாறாக அவர்கள் பயன்பாடுகளைச் சரிபார்க்கும் சோதனைகள், அவர்களுக்கு நன்றி, அவர்கள் ஏற்கனவே என்ன, எங்கு உடைந்தார்கள் என்பதைப் பார்க்கிறார்கள்.

ஒருங்கிணைப்பு மற்றும் விநியோகம்

மிகவும் சலிப்பூட்டும் பிரிவு, ஏனென்றால் உங்களிடம் அதிக ஆட்டோமேஷன் இருந்தால், குறியீட்டுடன் நீங்கள் சிறப்பாகச் செயல்படுகிறீர்கள், சிறந்த முடிவுகளைப் பெறுவதற்கான வாய்ப்புகள் அதிகம்.

கட்டிடக்கலை

மைக்ரோ சர்வீஸ்கள் செயல்திறனை எவ்வாறு பாதிக்கின்றன என்பதைப் பார்க்க விரும்பினோம். உண்மையில், மைக்ரோ சர்வீஸின் பயன்பாடு செயல்திறன் குறிகாட்டிகளின் அதிகரிப்புடன் தொடர்புபடுத்தப்படவில்லை என்பதால், அவர்கள் அவ்வாறு செய்யவில்லை. உயர் சுயவிவர கட்டளைகள் மற்றும் குறைந்த சுயவிவர கட்டளைகள் இரண்டிற்கும் மைக்ரோ சர்வீஸ்கள் பயன்படுத்தப்படுகின்றன.

ஆனால் குறிப்பிடத்தக்க விஷயம் என்னவென்றால், உயர்-அணிகளுக்கு, மைக்ரோ சர்வீஸ் கட்டமைப்பிற்கு மாறுவது அவர்கள் தங்கள் சேவைகளை சுயாதீனமாக மேம்படுத்தவும், வெளிவரவும் அனுமதிக்கிறது. டெவலப்பர்கள் குழுவிற்கு வெளியே யாருக்காகவும் காத்திருக்காமல், தன்னாட்சி முறையில் செயல்பட கட்டிடக்கலை அனுமதித்தால், இது வேகத்தை அதிகரிப்பதற்கான முக்கியத் திறனாகும். இந்த வழக்கில், மைக்ரோ சர்வீஸ் உதவுகிறது. மற்றும் அவற்றின் செயல்படுத்தல் ஒரு பெரிய பாத்திரத்தை வகிக்காது.

இதையெல்லாம் எப்படி கண்டுபிடித்தோம்?

டோரா முறையை முழுமையாகப் பிரதிபலிக்கும் லட்சியத் திட்டம் எங்களிடம் இருந்தது, ஆனால் அதற்கான ஆதாரங்கள் இல்லை. DORA நிறைய ஸ்பான்சர்ஷிப்பைப் பயன்படுத்தினால், அவர்களின் ஆராய்ச்சி அரை வருடம் ஆகும் என்றால், நாங்கள் எங்கள் ஆராய்ச்சியை குறுகிய காலத்தில் செய்தோம். DORA போன்று DevOps மாதிரியை உருவாக்க விரும்பினோம், எதிர்காலத்தில் அதைச் செய்வோம். இதுவரை நாம் வெப்ப வரைபடங்களுக்கு மட்டுப்படுத்தப்பட்டுள்ளோம்:

ஒவ்வொரு சுயவிவரத்திலும் உள்ள குழுக்கள் முழுவதும் பொறியியல் நடைமுறைகளின் விநியோகத்தைப் பார்த்தோம். இதைப் பற்றி நீங்கள் எங்களிடம் மேலும் படிக்கலாம் அறிக்கை.

ஒரு மாற்றத்திற்காக, சிக்கலான புள்ளிவிவரங்களிலிருந்து எளிமையானவற்றுக்கு மாறுவோம்.

நாம் வேறு என்ன கண்டுபிடித்தோம்?

கருவிகள்

பெரும்பாலான கட்டளைகள் லினக்ஸ் குடும்பத்தின் OS ஆல் பயன்படுத்தப்படுவதை நாங்கள் கவனிக்கிறோம். ஆனால் விண்டோஸ் இன்னும் போக்கில் உள்ளது - எங்கள் பதிலளித்தவர்களில் குறைந்தது கால் பகுதியினர் அதன் பதிப்புகளில் ஒன்று அல்லது மற்றொரு பயன்பாட்டைக் குறிப்பிட்டுள்ளனர். சந்தைக்கு இந்தத் தேவை இருப்பதாகத் தெரிகிறது. எனவே, நீங்கள் இந்த திறன்களை வளர்த்துக் கொள்ளலாம் மற்றும் மாநாடுகளில் விளக்கக்காட்சிகளை செய்யலாம்.

ஆர்கெஸ்ட்ரேட்டர்களில், இது யாருக்கும் ரகசியம் அல்ல, குபெர்னெட்ஸ் முன்னணியில் உள்ளார் (52%). அடுத்த வரிசையில் உள்ள ஆர்கெஸ்ட்ரேட்டர் டோக்கர் ஸ்வார்ம் (சுமார் 12%). மிகவும் பிரபலமான CI அமைப்புகள் Jenkins மற்றும் GitLab ஆகும். மிகவும் பிரபலமான கட்டமைப்பு மேலாண்மை அமைப்பு அன்சிபிள் ஆகும், அதைத் தொடர்ந்து எங்கள் அன்பான ஷெல் உள்ளது.

அமேசான் தற்போது முன்னணி கிளவுட் ஹோஸ்டிங் வழங்குநராக உள்ளது. ரஷ்ய மேகங்களின் பங்கு படிப்படியாக அதிகரித்து வருகிறது. அடுத்த ஆண்டு ரஷ்ய கிளவுட் வழங்குநர்கள் எப்படி உணருவார்கள், அவர்களின் சந்தைப் பங்கு அதிகரிக்குமா என்பதைப் பார்ப்பது சுவாரஸ்யமாக இருக்கும். அவை, அவை பயன்படுத்தப்படலாம், அது நல்லது:

நான் இகோருக்கு தரையை அனுப்புகிறேன், அவர் இன்னும் சில புள்ளிவிவரங்களைத் தருவார்.

நடைமுறைகளைப் பரப்புதல்

இகோர் குரோச்ச்கின்: தனித்தனியாக, நிறுவனத்தில் கருதப்படும் பொறியியல் நடைமுறைகள் எவ்வாறு விநியோகிக்கப்படுகின்றன என்பதைக் குறிக்க நாங்கள் பதிலளித்தவர்களிடம் கேட்டோம். பெரும்பாலான நிறுவனங்களில், ஒரு கலவையான அணுகுமுறை உள்ளது, இது வேறுபட்ட வடிவங்களைக் கொண்டுள்ளது, மேலும் பைலட் திட்டங்கள் மிகவும் பிரபலமாக உள்ளன. சுயவிவரங்களுக்கு இடையில் ஒரு சிறிய வித்தியாசத்தையும் நாங்கள் கண்டோம். உயர் சுயவிவரத்தின் பிரதிநிதிகள் பெரும்பாலும் "கீழே இருந்து முன்முயற்சி" முறையைப் பயன்படுத்துகின்றனர், நிபுணர்களின் சிறிய குழுக்கள் பணி செயல்முறைகள், கருவிகள் மற்றும் வெற்றிகரமான நடைமுறைகளை மற்ற குழுக்களுடன் மாற்றும் போது. மீடியத்தில், இது சமூகங்கள் மற்றும் சிறந்த மையங்களை உருவாக்குவதன் மூலம் முழு நிறுவனத்தையும் பாதிக்கும் ஒரு டாப்-டவுன் முயற்சியாகும்:

சுறுசுறுப்பான மற்றும் டெவொப்ஸ்

அஜில் மற்றும் டெவொப்ஸ் இடையேயான தொடர்பின் கேள்வி பெரும்பாலும் தொழில்துறையில் விவாதிக்கப்படுகிறது. இந்தச் சிக்கல் 2019/2020க்கான சுறுசுறுப்பான அறிக்கையிலும் எழுப்பப்பட்டுள்ளது, எனவே நிறுவனங்களில் Agile மற்றும் DevOps செயல்பாடுகள் எவ்வாறு இணைக்கப்பட்டுள்ளன என்பதை ஒப்பிட்டுப் பார்க்க முடிவு செய்தோம். அஜில் இல்லாத DevOps அரிதானது என்பதைக் கண்டறிந்தோம். பதிலளித்தவர்களில் பாதி பேருக்கு, அஜிலின் பரவல் மிகவும் முன்னதாகவே தொடங்கியது, மேலும் சுமார் 20% பேர் ஒரே நேரத்தில் தொடங்குவதைக் கவனித்தனர், மேலும் குறைந்த சுயவிவரத்தின் அறிகுறிகளில் ஒன்று அஜில் மற்றும் டெவொப்ஸ் நடைமுறைகள் இல்லாதது ஆகும்:

கட்டளை இடவியல்

கடந்த ஆண்டு இறுதியில், புத்தகம் "குழு இடவியல்”, இது கட்டளை இடவியல்களை விவரிப்பதற்கான ஒரு கட்டமைப்பை முன்மொழிகிறது. ரஷ்ய நிறுவனங்களுக்கு இது பொருந்துமா என்பது எங்களுக்கு சுவாரஸ்யமானது. நாங்கள் கேள்வியைக் கேட்டோம்: "நீங்கள் என்ன வடிவங்களைக் காண்கிறீர்கள்?".

பதிலளித்தவர்களில் பாதியில் உள்கட்டமைப்பு குழுக்கள் காணப்படுகின்றன, மேலும் மேம்பாடு, சோதனை மற்றும் செயல்பாட்டிற்கான தனி குழுக்கள். தனி DevOps குழுக்கள் 45% என்று குறிப்பிட்டுள்ளன, அவற்றில் உயர் பிரதிநிதிகள் மிகவும் பொதுவானவர்கள். அடுத்து க்ராஸ்-ஃபங்க்ஸ்னல் டீம்கள் வருகின்றன, இவை ஹையில் மிகவும் பொதுவானவை. தனித்தனி SRE கட்டளைகள் உயர், நடுத்தர சுயவிவரங்களில் தோன்றும் மற்றும் குறைந்த சுயவிவரத்தில் அரிதாகவே காணப்படுகின்றன:

DevQaOps விகிதம்

ஸ்கைங் இயங்குதளக் குழுவின் குழுத் தலைவரிடமிருந்து இந்த கேள்வியை ஃபேஸ்புக்கில் பார்த்தோம் - நிறுவனங்களில் டெவலப்பர்கள், சோதனையாளர்கள் மற்றும் நிர்வாகிகளின் விகிதத்தில் அவர் ஆர்வமாக இருந்தார். நாங்கள் அதைக் கேட்டு, சுயவிவரங்களின் அடிப்படையில் பதில்களைப் பார்த்தோம்: உயர்நிலைப் பிரதிநிதிகள் ஒவ்வொரு டெவலப்பருக்கும் குறைவான சோதனை மற்றும் செயல்பாட்டுப் பொறியாளர்களைக் கொண்டுள்ளனர்:

2021 ஆண்டு திட்டம்

அடுத்த ஆண்டுக்கான திட்டங்களில், பதிலளித்தவர்கள் பின்வரும் செயல்பாடுகளைக் குறிப்பிட்டனர்:

DevOps லைவ் 2020 மாநாட்டின் சந்திப்பை இங்கே காணலாம். நாங்கள் திட்டத்தை கவனமாக மதிப்பாய்வு செய்தோம்:

• ஒரு பொருளாக உள்கட்டமைப்பு
• DevOps மாற்றம்
• DevOps நடைமுறைகளின் விநியோகம்
• DevSecOps
• கேஸ் கிளப்புகள் மற்றும் விவாதங்கள்

ஆனால் எங்கள் விளக்கக்காட்சியின் நேரம் அனைத்து தலைப்புகளையும் உள்ளடக்குவதற்கு போதுமானதாக இல்லை. திரைக்குப் பின்னால் விட்டு:

• பிளாட்ஃபார்ம் ஒரு சேவையாகவும் தயாரிப்பாகவும்;
• குறியீடு, சூழல்கள் மற்றும் மேகங்கள் என உள்கட்டமைப்பு;
• தொடர்ச்சியான ஒருங்கிணைப்பு மற்றும் விநியோகம்;
• கட்டிடக்கலை;
• DevSecOps வடிவங்கள்;
• தளம் மற்றும் குறுக்கு-செயல்பாட்டு அணிகள்.

அறிக்கை எங்களிடம் ஒரு பெரிய, 50 பக்கங்கள் கிடைத்துள்ளன, அதை நீங்கள் இன்னும் விரிவாகப் பார்க்கலாம்.

சுருக்கமாக

மேம்பாடு, சோதனை மற்றும் செயல்பாடுகளுக்கான புதிய அணுகுமுறைகளை பரிசோதிக்க எங்கள் ஆராய்ச்சியும் அறிக்கையும் உங்களைத் தூண்டும் என்று நம்புகிறோம், மேலும் நீங்கள் வழிசெலுத்தவும், ஆய்வில் உள்ள மற்ற பங்கேற்பாளர்களுடன் உங்களை ஒப்பிட்டுப் பார்க்கவும், உங்கள் சொந்த அணுகுமுறைகளை நீங்கள் மேம்படுத்தக்கூடிய பகுதிகளை அடையாளம் காணவும் உதவும்.

ரஷ்யாவில் DevOps மாநிலத்தின் முதல் ஆய்வின் முடிவுகள்:

• முக்கிய அளவீடுகள். முக்கிய அளவீடுகள் (டெலிவரி நேரம், வரிசைப்படுத்தல் அதிர்வெண், மீட்பு நேரம் மற்றும் மாற்றத் தோல்விகள்) மேம்பாடு, சோதனை மற்றும் செயல்பாட்டு செயல்முறைகளின் செயல்திறனைப் பகுப்பாய்வு செய்வதற்கு ஏற்றது என்பதைக் கண்டறிந்துள்ளோம்.
• சுயவிவரங்கள் உயர், நடுத்தர, குறைந்த. சேகரிக்கப்பட்ட தரவுகளின் அடிப்படையில், அளவீடுகள், நடைமுறைகள், செயல்முறைகள் மற்றும் கருவிகள் ஆகியவற்றின் அடிப்படையில் தனித்துவமான அம்சங்களுடன் உயர், நடுத்தர, குறைந்த புள்ளியியல் ரீதியாக வேறுபட்ட குழுக்களை நாம் வேறுபடுத்தி அறியலாம். உயர் சுயவிவரத்தின் பிரதிநிதிகள் குறைந்ததை விட சிறந்த முடிவுகளைக் காட்டுகின்றனர். அவர்கள் தங்கள் இலக்குகளை அடைய மற்றும் மீறுவதற்கான வாய்ப்புகள் அதிகம்.
• குறிகாட்டிகள், தொற்றுநோய் மற்றும் 2021க்கான திட்டங்கள். இந்த ஆண்டு ஒரு சிறப்பு காட்டி நிறுவனங்கள் தொற்றுநோயை எவ்வாறு சமாளித்தன என்பதுதான். உயர் பிரதிநிதிகள் சிறப்பாக செயல்பட்டனர், அனுபவம் அதிகரித்த பயனர் ஈடுபாடு மற்றும் வெற்றிக்கான முக்கிய காரணங்கள் திறமையான வளர்ச்சி செயல்முறைகள் மற்றும் வலுவான பொறியியல் கலாச்சாரம்.
• DevOps நடைமுறைகள், கருவிகள் மற்றும் அவற்றின் மேம்பாடு. அடுத்த ஆண்டுக்கான நிறுவனங்களின் முக்கிய திட்டங்களில் DevOps நடைமுறைகள் மற்றும் கருவிகளின் வளர்ச்சி, DevSecOps நடைமுறைகளின் அறிமுகம் மற்றும் நிறுவன கட்டமைப்பில் மாற்றங்கள் ஆகியவை அடங்கும். மற்றும் DevOps நடைமுறைகளை திறம்பட செயல்படுத்துதல் மற்றும் மேம்படுத்துதல் ஆகியவை பைலட் திட்டங்கள், சமூகங்கள் மற்றும் சிறந்த மையங்களின் உருவாக்கம், நிறுவனத்தின் மேல் மற்றும் கீழ் மட்டங்களில் உள்ள முயற்சிகள் ஆகியவற்றின் உதவியுடன் மேற்கொள்ளப்படுகிறது.

உங்கள் கருத்து, கதைகள், கருத்துகளைக் கேட்க விரும்புகிறோம். ஆய்வில் பங்கேற்ற அனைவருக்கும் நன்றி தெரிவித்துக் கொள்கிறோம், அடுத்த ஆண்டு உங்கள் பங்கேற்பை எதிர்நோக்குகிறோம்.

ஆதாரம்: www.habr.com