2019 இல் ஒரு ஐடி நிறுவனம் வெற்றிபெற என்ன செய்ய வேண்டும்? மாநாடுகள் மற்றும் சந்திப்புகளில் விரிவுரையாளர்கள் சாதாரண மக்களுக்கு எப்போதும் புரியாத உரத்த வார்த்தைகளை அதிகம் கூறுகிறார்கள். வரிசைப்படுத்தல் நேரம், மைக்ரோ சர்வீஸ்கள், மோனோலித்தை கைவிடுதல், டெவொப்ஸ் மாற்றம் மற்றும் பலவற்றிற்கான போராட்டம். நாம் வாய்மொழி அழகை நிராகரித்து, நேரடியாகவும் ரஷ்ய மொழியிலும் பேசினால், அது ஒரு எளிய ஆய்வறிக்கைக்கு வரும்: உயர்தர தயாரிப்பை உருவாக்கி, அணிக்கு ஆறுதலுடன் செய்யுங்கள்.
பிந்தையது விமர்சன ரீதியாக முக்கியமானது. வணிகம் இறுதியாக ஒரு வசதியான வளர்ச்சி செயல்முறை உற்பத்தித்திறனை அதிகரிக்கிறது என்ற முடிவுக்கு வந்துள்ளது, மேலும் எல்லாவற்றையும் பிழைத்திருத்தம் செய்து ஒரு கடிகாரம் போல் செயல்பட்டால், அது சிக்கலான சூழ்நிலைகளில் சூழ்ச்சிக்கு சில இடங்களை வழங்குகிறது. ஒரு காலத்தில், இந்த சூழ்ச்சிக்காக, ஒரு குறிப்பிட்ட புத்திசாலி நபர் காப்புப்பிரதிகளுடன் வந்தார், ஆனால் தொழில் வளர்ச்சியடைந்து வருகிறது, மேலும் நாங்கள் DevOps பொறியாளர்களிடம் வந்தோம் - வளர்ச்சிக்கும் வெளிப்புற உள்கட்டமைப்புக்கும் இடையிலான தொடர்பு செயல்முறையை போதுமானதாக மாற்றும் நபர்கள் மற்றும் ஷாமனிசத்துடன் தொடர்புடையது அல்ல.
இந்த முழு “மாடுலர்” கதையும் அற்புதமானது, ஆனால்... சில நிர்வாகிகள் திடீரென DevOps என அழைக்கப்பட்டனர், மேலும் DevOps இன்ஜினியர்களே குறைந்தபட்சம் டெலிபதி மற்றும் தெளிவுத்திறன் திறன்களைக் கொண்டிருக்க வேண்டும்.
உள்கட்டமைப்பை வழங்குவதில் உள்ள நவீன சிக்கல்களைப் பற்றி பேசுவதற்கு முன், இந்த வார்த்தையின் அர்த்தம் என்ன என்பதை வரையறுப்போம். தற்போதைய தருணத்தில், இந்த கருத்தின் இருமையை நாம் அடையும் வகையில் நிலைமை உருவாகியுள்ளது: உள்கட்டமைப்பு நிபந்தனையுடன் வெளிப்புறமாகவும் நிபந்தனைக்குட்பட்ட உட்புறமாகவும் இருக்கலாம்.
வெளிப்புற உள்கட்டமைப்பு மூலம், குழு உருவாக்கும் சேவை அல்லது தயாரிப்பின் செயல்பாட்டை உறுதி செய்யும் அனைத்தையும் நாங்கள் குறிக்கிறோம். இவை பயன்பாடு அல்லது இணையதள சேவையகங்கள், ஹோஸ்டிங் மற்றும் தயாரிப்பின் செயல்பாட்டை உறுதி செய்யும் பிற சேவைகள்.
உள் உள்கட்டமைப்பு என்பது மேம்பாட்டுக் குழு மற்றும் பிற ஊழியர்களால் பயன்படுத்தப்படும் சேவைகள் மற்றும் உபகரணங்களை உள்ளடக்கியது, அவர்களில் பொதுவாக பலர் உள்ளனர். இவை குறியீடு சேமிப்பக அமைப்புகளின் உள் சேவையகங்கள், உள்நாட்டில் பயன்படுத்தப்பட்ட பணி மேலாளர் மற்றும் கார்ப்பரேட் இன்ட்ராநெட்டில் உள்ள அனைத்தும், அனைத்தும், அனைத்தும்.
ஒரு நிறுவனத்தில் கணினி நிர்வாகி என்ன செய்கிறார்? இந்த கார்ப்பரேட் இன்ட்ராநெட்டை நிர்வகிப்பதற்கான பணிக்கு கூடுதலாக, அலுவலக உபகரணங்களின் செயல்பாட்டை உறுதி செய்வதற்கான பொருளாதார கவலைகளின் சுமையை இது அடிக்கடி சுமக்கிறது. ஒரு புதிய சிஸ்டம் யூனிட் அல்லது ஸ்பேர் லேப்டாப்பை பின் அறையில் இருந்து விரைவாக இழுத்து, புதிய கீபோர்டைக் கொடுத்து, அலுவலகங்கள் வழியாக நான்கு கால்களிலும் வலம் வந்து, ஈதர்நெட் கேபிளை நீட்டிக் கொண்டு வருபவர் அதே ஆள்தான் நிர்வாகி. நிர்வாகி ஒரு உள்ளூர் உரிமையாளர் மற்றும் உள் மற்றும் வெளிப்புற சேவையகங்களின் ஆட்சியாளர், ஆனால் ஒரு வணிக நிர்வாகி. ஆம், சில நிர்வாகிகள் வன்பொருள் இல்லாமல் கணினி விமானத்தில் மட்டுமே வேலை செய்ய முடியும். அவர்கள் "உள்கட்டமைப்பு அமைப்பு நிர்வாகிகள்" என்ற தனி துணைப்பிரிவாகப் பிரிக்கப்பட வேண்டும். சிலர் பிரத்தியேகமாக அலுவலக உபகரணங்களுக்கு சேவை செய்வதில் நிபுணத்துவம் பெற்றவர்கள்; அதிர்ஷ்டவசமாக, நிறுவனத்தில் நூற்றுக்கும் மேற்பட்டவர்கள் இருந்தால், வேலை ஒருபோதும் முடிவடையாது. ஆனால் அவர்கள் இருவரும் டெவொப்கள் அல்ல.
DevOps யார்? டெவொப்ஸ் என்பது வெளிப்புற உள்கட்டமைப்புடன் மென்பொருள் மேம்பாட்டின் தொடர்பு பற்றி பேசும் தோழர்களே. இன்னும் துல்லியமாக, ftp இல் புதுப்பிப்புகளை பதிவேற்றிய நிர்வாகிகளை விட நவீன டெவொப்கள் மிகவும் ஆழமான வளர்ச்சி மற்றும் வரிசைப்படுத்தல் செயல்முறைகளில் ஈடுபட்டுள்ளன. டெவொப்ஸ் இன்ஜினியரின் முக்கிய பணிகளில் ஒன்று, மேம்பாட்டுக் குழுக்கள் மற்றும் தயாரிப்பு உள்கட்டமைப்பு ஆகியவற்றுக்கு இடையேயான தொடர்புகளின் வசதியான மற்றும் திறம்பட கட்டமைக்கப்பட்ட செயல்முறையை உறுதி செய்வதாகும். ரோல்பேக் மற்றும் வரிசைப்படுத்தல் அமைப்புகளைப் பயன்படுத்துவதற்கு இந்த நபர்கள்தான் பொறுப்பு; டெவலப்பர்களிடமிருந்து சில சுமைகளை எடுத்துக்கொண்டு, அவர்களின் மிக முக்கியமான பணியில் முடிந்தவரை கவனம் செலுத்துபவர்கள் இவர்கள்தான். அதே நேரத்தில், டெவொப்ஸ் ஒருபோதும் புதிய கேபிளை இயக்காது அல்லது பின் அறையில் இருந்து புதிய லேப்டாப்பை வழங்காது (c) KO
என்ன பிடிப்பு?
"DevOps யார்?" என்ற கேள்விக்கு துறையில் உள்ள தொழிலாளர்களில் பாதி பேர் "சரி, சுருக்கமாக, இவர் தான் நிர்வாகி ..." மற்றும் உரையில் மேலும் ஏதாவது பதிலளிக்கத் தொடங்குகிறார்கள். ஆம், ஒரு காலத்தில், டெவொப்ஸ் இன்ஜினியரின் தொழில், சேவைப் பராமரிப்பின் அடிப்படையில் மிகவும் திறமையான நிர்வாகிகளிடமிருந்து வெளிவந்து கொண்டிருந்தபோது, அவர்களுக்கு இடையேயான வேறுபாடுகள் அனைவருக்கும் தெளிவாகத் தெரியவில்லை. ஆனால் இப்போது, குழுவில் உள்ள டெவொப்ஸ் மற்றும் அட்மினின் செயல்பாடுகள் முற்றிலும் வேறுபட்டதாக இருக்கும்போது, அவற்றை ஒருவருக்கொருவர் குழப்புவது அல்லது சமன் செய்வது கூட ஏற்றுக்கொள்ள முடியாதது.
ஆனால் வணிகத்திற்கு இது என்ன அர்த்தம்?
பணியமர்த்தல், அது பற்றியது.
நீங்கள் “கணினி நிர்வாகி”க்கான காலியிடத்தைத் திறக்கிறீர்கள், மேலும் அங்கு பட்டியலிடப்பட்டுள்ள தேவைகள் “மேம்பாடு மற்றும் வாடிக்கையாளர்களுடனான தொடர்பு”, “CI/CD டெலிவரி சிஸ்டம்”, “நிறுவனத்தின் சேவையகங்கள் மற்றும் உபகரணங்களைப் பராமரித்தல்”, “உள் அமைப்புகளின் நிர்வாகம்” மற்றும் பல. அன்று; முதலாளி முட்டாள்தனமாக பேசுகிறார் என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள். கேட்ச் என்னவென்றால், “கணினி நிர்வாகி” என்பதற்குப் பதிலாக காலியிடத்தின் தலைப்பு “DevOps இன்ஜினியர்” என்று இருக்க வேண்டும், மேலும் இந்த தலைப்பு மாற்றப்பட்டால், எல்லாம் சரியான இடத்தில் விழும்.
இருப்பினும், அத்தகைய காலியிடத்தைப் படிக்கும்போது ஒருவருக்கு என்ன அபிப்ராயம் ஏற்படுகிறது? நிறுவனம் ஒரு மல்டி-மெஷின் ஆபரேட்டரைத் தேடுகிறது, அவர் பதிப்புக் கட்டுப்பாடு மற்றும் கண்காணிப்பு அமைப்பு இரண்டையும் பயன்படுத்துவார் மற்றும் ட்விஸ்டரை தனது பற்களால் அழுத்துவார்...
ஆனால் தொழிலாளர் சந்தையில் போதைப் பழக்கத்தின் அளவை அதிகரிக்காமல் இருக்க, காலியிடங்களை அவற்றின் சரியான பெயர்களால் அழைப்பது போதுமானது மற்றும் ஒரு DevOps பொறியாளர் மற்றும் கணினி நிர்வாகி இரண்டு வெவ்வேறு நிறுவனங்கள் என்பதை தெளிவாக புரிந்துகொள்வது போதுமானது. ஆனால் ஒரு வேட்பாளருக்கு சாத்தியமான பரந்த அளவிலான தேவைகளின் பட்டியலை வழங்க சில முதலாளிகளின் அடக்கமுடியாத விருப்பம், "கிளாசிக்" அமைப்பு நிர்வாகிகள் தங்களைச் சுற்றி என்ன நடக்கிறது என்பதைப் புரிந்துகொள்வதை நிறுத்துகிறது. என்ன, தொழில் மாறுகிறது மற்றும் அவர்கள் காலத்திற்குப் பின்னால் இருக்கிறார்களா?
இல்லை இல்லை மேலும் ஒரு முறை இல்லை. நிறுவனத்தின் உள் சேவையகங்களை நிர்வகிக்கும் அல்லது L2/L3 ஆதரவு நிலைகளை ஆக்கிரமித்து மற்ற ஊழியர்களுக்கு உதவும் உள்கட்டமைப்பு நிர்வாகிகள் வெளியேறவில்லை, போகப் போவதில்லை.
இந்த நிபுணர்கள் DevOps பொறியாளர்களாக மாற முடியுமா? நிச்சயமாக அவர்களால் முடியும். உண்மையில், இது ஒரு தொடர்புடைய சூழலாகும், இது கணினி நிர்வாக திறன்கள் தேவைப்படுகிறது, ஆனால் இது தவிர, கண்காணிப்பு, விநியோக அமைப்புகள் மற்றும் பொதுவாக, மேம்பாடு மற்றும் சோதனைக் குழுவுடன் நெருக்கமான தொடர்பு சேர்க்கப்படுகிறது.
மற்றொரு DevOps சிக்கல்
உண்மையில், எல்லாமே பணியமர்த்தல் மற்றும் நிர்வாகிகள் மற்றும் டெவொப்களுக்கு இடையே நிலையான குழப்பம் ஆகியவற்றுடன் மட்டுப்படுத்தப்படவில்லை. ஒரு கட்டத்தில், வணிகம் புதுப்பிப்புகளை வழங்குவதில் சிக்கலை எதிர்கொண்டது மற்றும் இறுதி உள்கட்டமைப்புடன் மேம்பாட்டுக் குழுவின் தொடர்பு.
சில மாநாட்டின் மேடையில் பளபளப்பான கண்களுடன் ஒரு மாமா எழுந்து நின்று, “நாங்கள் இதைச் செய்கிறோம், அதை டெவொப்ஸ் என்று அழைக்கிறோம். இவர்கள் உங்கள் எல்லாப் பிரச்சினைகளையும் தீர்த்து வைப்பார்கள்” - மேலும் DevOps நடைமுறைகளைச் செயல்படுத்திய பிறகு நிறுவனத்தில் வாழ்க்கை எவ்வளவு நன்றாக இருக்கிறது என்பதைச் சொல்லத் தொடங்கினார்.
இருப்பினும், எல்லாவற்றையும் சரியாகச் செய்ய DevOps பொறியாளரை நியமிப்பது போதாது. நிறுவனம் ஒரு முழுமையான DevOps மாற்றத்திற்கு உட்பட வேண்டும், அதாவது, எங்கள் DevOps இன் பங்கு மற்றும் திறன்கள் தயாரிப்பு மேம்பாடு மற்றும் சோதனைக் குழுவின் பக்கத்திலும் தெளிவாக புரிந்து கொள்ளப்பட வேண்டும். இந்த தலைப்பில் சில இடங்களில் நடக்கும் அனைத்து மிருகத்தனங்களையும் முழுமையாக விளக்கும் ஒரு "அற்புதமான" கதை எங்களிடம் உள்ளது.
சூழ்நிலை. டெவொப்ஸ் ஒரு பதிப்பு ரோல்பேக் சிஸ்டத்தை அது எவ்வாறு வேலை செய்யும் என்பதை ஆராயாமல் பயன்படுத்த வேண்டும். பயனர்கள் அமைப்பில் முதல் பெயர், கடைசி பெயர் மற்றும் கடவுச்சொல்லுக்கான தனி புலங்கள் உள்ளன என்று வைத்துக்கொள்வோம். தயாரிப்பின் புதிய பதிப்பு வெளிவருகிறது, ஆனால் டெவலப்பர்களுக்கு, "ரோல்பேக்" என்பது எல்லாவற்றையும் சரிசெய்யும் ஒரு மந்திரக்கோலை மட்டுமே, அது எப்படி வேலை செய்கிறது என்பது கூட அவர்களுக்குத் தெரியாது. எனவே, எடுத்துக்காட்டாக, அடுத்த இணைப்பில், டெவலப்பர்கள் முதல் மற்றும் கடைசி பெயர் புலங்களை இணைத்து, அதை உற்பத்தியில் உருட்டினார்கள், ஆனால் சில காரணங்களால் பதிப்பு மெதுவாக உள்ளது. என்ன நடக்கிறது? மேனேஜ்மென்ட் டெவொப்ஸுக்கு வந்து “சுவிட்சை இழு!” என்று கூறுகிறது, அதாவது முந்தைய பதிப்பிற்கு திரும்பும்படி கேட்கிறது. டெவொப்ஸ் என்ன செய்கிறது? இது முந்தைய பதிப்பிற்குத் திரும்புகிறது, ஆனால் டெவலப்பர்கள் இந்த ரோல்பேக் எவ்வாறு செய்யப்பட்டது என்பதைக் கண்டுபிடிக்க விரும்பாததால், தரவுத்தளமும் மீண்டும் உருட்டப்பட வேண்டும் என்று யாரும் டெவொப்ஸ் குழுவிடம் கூறவில்லை. இதன் விளைவாக, எல்லாம் எங்களுக்கு செயலிழக்கிறது, மேலும் மெதுவான வலைத்தளத்திற்கு பதிலாக, பயனர்கள் "500" பிழையைப் பார்க்கிறார்கள், ஏனெனில் பழைய பதிப்பு புதிய தரவுத்தளத்தின் புலங்களுடன் வேலை செய்யாது. டெவொப்ஸுக்கு இது பற்றி தெரியாது. டெவலப்பர்கள் அமைதியாக இருக்கிறார்கள். நிர்வாகம் தங்கள் நரம்புகளையும் பணத்தையும் இழக்கத் தொடங்குகிறது மற்றும் காப்புப்பிரதிகளை நினைவில் கொள்கிறது, "குறைந்தபட்சம் ஏதாவது வேலை செய்யும்" என்று அவர்களிடமிருந்து பின்வாங்க முன்வருகிறது. இதன் விளைவாக, பயனர்கள் தங்கள் எல்லா தரவையும் ஒரு குறிப்பிட்ட காலத்திற்கு இழக்கிறார்கள்.
நட்ஸ், நிச்சயமாக, டெவொப்ஸுக்குச் செல்கிறது, இது "சரியான ரோல்பேக் சிஸ்டத்தை உருவாக்கவில்லை", மேலும் இந்தக் கதையில் உள்ள மூஸ் டெவலப்பர்கள் என்று யாரும் கவலைப்படுவதில்லை.
முடிவு எளிதானது: DevOps க்கு ஒரு சாதாரண அணுகுமுறை இல்லாமல், அது சிறிதளவு பயனில்லை.
நினைவில் கொள்ள வேண்டிய முக்கிய விஷயம்: ஒரு DevOps பொறியாளர் ஒரு மந்திரவாதி அல்ல, மேலும் தரமான தகவல்தொடர்புகள் மற்றும் வளர்ச்சியுடன் இருவழி தொடர்பு இல்லாமல், அவர் தனது பணிகளைச் சமாளிக்க மாட்டார். Devs அவர்களின் "சிக்கல்களில்" தனியாக இருக்க முடியாது அல்லது "டெவலப்பர்களுடன் தலையிட வேண்டாம், அவர்களின் வேலை குறியீடாகும்" என்ற கட்டளையை வழங்க முடியாது, பின்னர் ஒரு முக்கியமான தருணத்தில் எல்லாம் செயல்படும் என்று நம்புகிறேன். அது எப்படி வேலை செய்யாது.
முக்கியமாக, DevOps என்பது மேலாண்மைக்கும் தொழில்நுட்பத்திற்கும் இடையிலான எல்லையில் உள்ள ஒரு திறமையாகும். மேலும், இந்த காக்டெய்லில் நிர்வாகத்தை விட அதிக தொழில்நுட்பம் இருக்க வேண்டும் என்பது வெளிப்படையானது அல்ல. நீங்கள் உண்மையிலேயே வேகமான மற்றும் திறமையான மேம்பாட்டு செயல்முறைகளை உருவாக்க விரும்பினால், உங்கள் டெவொப்ஸ் குழுவை நீங்கள் நம்ப வேண்டும். அவருக்கு சரியான கருவிகள் தெரியும், அவர் இதே போன்ற திட்டங்களை செயல்படுத்தியுள்ளார், அதை எப்படி செய்வது என்று அவருக்குத் தெரியும். அவருக்கு உதவுங்கள், அவரது ஆலோசனையைக் கேளுங்கள், அவரை ஒருவித தன்னாட்சி அலகுக்குள் தனிமைப்படுத்த முயற்சிக்காதீர்கள். நிர்வாகிகள் சொந்தமாக வேலை செய்ய முடிந்தால், இந்த விஷயத்தில் devops பயனற்றது; இந்த உதவியை நீங்களே ஏற்க விரும்பவில்லை என்றால், அவர்களால் உங்களுக்கு உதவ முடியாது.
கடைசியாக ஒன்று: உள்கட்டமைப்பு நிர்வாகிகளை புண்படுத்துவதை நிறுத்துங்கள். அவர்கள் தங்கள் சொந்த, மிக முக்கியமான வேலை முன்னணியில் உள்ளனர். ஆம், ஒரு நிர்வாகி DevOps இன்ஜினியராக முடியும், ஆனால் இது அந்த நபரின் வேண்டுகோளின் பேரில் நடக்க வேண்டும், அழுத்தத்தின் கீழ் அல்ல. ஒரு சிஸ்டம் அட்மினிஸ்ட்ரேட்டர் ஒரு சிஸ்டம் அட்மினிஸ்ட்ரேட்டராக இருக்க விரும்புவதில் தவறில்லை - இது அவருடைய தனித் தொழில் மற்றும் அவரது உரிமை. நீங்கள் ஒரு தொழில்முறை மாற்றத்திற்கு உட்படுத்த விரும்பினால், நீங்கள் தொழில்நுட்ப திறன்களை மட்டுமல்ல, மேலாண்மை திறன்களையும் உருவாக்க வேண்டும் என்பதை நீங்கள் ஒருபோதும் மறந்துவிடக் கூடாது. பெரும்பாலும், இந்த மக்கள் அனைவரையும் ஒன்றிணைத்து ஒரே மொழியில் தொடர்பு கொள்ள கற்றுக்கொடுப்பது ஒரு தலைவராக உங்கள் கையில் இருக்கும்.
ஆதாரம்: www.habr.com