Logrocon வழங்கும் DevOpsForum 2019 இல் நான் சமீபத்தில் கலந்துகொண்டேன். இந்த மாநாட்டில், பங்கேற்பாளர்கள் வணிகம் மற்றும் மேம்பாடு மற்றும் தகவல் தொழில்நுட்ப சேவை நிபுணர்களிடையே பயனுள்ள தொடர்புக்கான தீர்வுகள் மற்றும் புதிய கருவிகளைக் கண்டறிய முயன்றனர்.
மாநாடு வெற்றிகரமாக இருந்தது: உண்மையில் நிறைய பயனுள்ள அறிக்கைகள், சுவாரஸ்யமான விளக்கக்காட்சி வடிவங்கள் மற்றும் பேச்சாளர்களுடன் நிறைய தொடர்புகள் இருந்தன. பெரிய மாநாடுகளில் பேசுபவர்கள் சமீபகாலமாக குற்றவாளிகளாக இருந்த எதையும் யாரும் எனக்கு விற்க முயற்சிக்காதது மிகவும் முக்கியமானது.
Raiffeisenbank, Alfastrakhovanie, Mango Telecom இன் ஆட்டோமேஷனைச் செயல்படுத்துவதில் அனுபவம் மற்றும் பிற விவரங்களை வெட்டுக்குக் கீழ் உள்ள உரைகளில் இருந்து ஒரு பகுதி.
என் பெயர் யானா, நான் ஒரு சோதனையாளராக வேலை செய்கிறேன், நான் ஆட்டோமேஷனை செய்கிறேன், அதே போல் DevOps செய்கிறேன், மேலும் மாநாடுகள் மற்றும் சந்திப்புகளுக்கு செல்வதை நான் விரும்புகிறேன். கடந்த இரண்டு ஆண்டுகளாக, நான் ஓலெக் புனினின் மாநாடுகள் (ஹைலோட்++, டீம்லீட் கான்ஃப்), ஜக் நிகழ்வுகள் (ஹைசன்பக், ஜேபாயிண்ட்), டெஸ்ட்கான் மாஸ்கோ, டெவொப்ஸ் ப்ரோ மாஸ்கோ, பிக் டேட்டா மாஸ்கோ ஆகியவற்றுக்குச் சென்றிருக்கிறேன்.
முதலில், மாநாட்டு நிகழ்ச்சிக்கு நான் கவனம் செலுத்துகிறேன். அறிக்கை எதைப் பற்றியது என்பதை நான் குறைவாகப் பார்க்கிறேன், மேலும் பேச்சாளரைப் பார்க்கிறேன். அறிக்கை மிகவும் தொழில்நுட்பமாகவும் சுவாரஸ்யமாகவும் மாறினாலும், உங்கள் நிறுவனத்தில் உள்ள அறிக்கையில் இருந்து சில சிறந்த நடைமுறைகளை நீங்கள் பயன்படுத்த முடியும் என்பது உண்மையல்ல. பின்னர் உங்களுக்கு ஒரு ஸ்பீக்கர் தேவை.
Raiffeisenbank இல் குழாயின் முடிவில் விளக்கு
பொதுவாக, எனக்கு விருப்பமான பேச்சாளர்களை நான் வேட்டையாடுவேன். DevOpsForum 2019 இல், Raiffeisenbank இன் பேச்சாளர் Mikhail Bizhan, என் ஆர்வத்தை ஈர்த்தார். அவரது உரையின் போது, அவர்கள் எப்படி படிப்படியாக தங்கள் அணிகளை DevOps இல் இணைத்துக் கொள்கிறார்கள், அவர்களுக்கு அது ஏன் தேவைப்படுகிறது மற்றும் DevOps மாற்றத்தின் யோசனையை வணிகத்திற்கு எவ்வாறு விற்பனை செய்வது என்பது பற்றி அவர் பேசினார். சரி, பொதுவாக, குழாயின் முடிவில் ஒளியைப் பார்ப்பது எப்படி என்பதைப் பற்றி பேசினேன்.
Mikhail Bizhan, Raiffeisenbank இல் ஆட்டோமேஷன் இயக்குனர்
இப்போது அவர்கள் நிறுவனத்தில் "DevOps" இல்லை. அதாவது, அவர் வேலை செய்கிறார், ஆனால் எல்லா அணிகளிலும் இல்லை. DevOps ஐ செயல்படுத்தும் போது, குறிப்பிட்ட பொறியாளர்கள் மற்றும் தயாரிப்பின் தேவை மற்றும் இந்த தயாரிப்பு கட்டமைக்கப்பட்ட தளத்தின் முதிர்ச்சி ஆகியவற்றின் அடிப்படையில் அணிகளின் தயார்நிலையை அவர்கள் நம்பியுள்ளனர். DevOps ஏன் தேவை என்பதை வணிகத்திற்கு எவ்வாறு விளக்குவது என்று மிஷா கூறினார்.
வங்கிப் பிரிவில் பல வளர்ச்சி இயக்கிகள் உள்ளன: சேவைகளின் விலை மற்றும் வாடிக்கையாளர் தளத்தின் விரிவாக்கம். சேவைகளின் விலையை அதிகரிப்பது ஒரு நல்ல இயக்கி அல்ல, ஆனால் வாடிக்கையாளர் தளத்தை வளர்ப்பது இதற்கு நேர்மாறானது. போட்டியாளர்கள் ஒரு புறநிலையான குளிர்ச்சியான தயாரிப்பை வெளியிட்டால், அனைத்து வாடிக்கையாளர்களும் அங்கு செல்கின்றனர், பின்னர் காலப்போக்கில் சந்தை நிலைகள் வெளியேறும். எனவே, சந்தையில் புதிய தயாரிப்புகளை அறிமுகப்படுத்துதல் மற்றும் அவற்றின் அறிமுகத்தின் வேகம் ஆகியவை வங்கிகள் கவனம் செலுத்தும் முக்கிய விஷயம். இதற்குத்தான் DevOps உள்ளது, வணிகங்கள் இதைப் புரிந்துகொள்கின்றன.
அடுத்த முக்கிய குறிப்பு: DevOps எப்போதும் சந்தைக்கான நேரத்தை குறைக்காது. DevOps தனியாக வேலை செய்ய முடியாது, இது ஒரு தயாரிப்பை உருவாக்கி சந்தைக்கு கொண்டு வரும் செயல்முறையின் ஒரு பகுதியாகும். ஆனால் குறியீட்டிற்கு முன் உள்ள அனைத்தும் DevOps உடன் நேரடியாக தொடர்புடையது அல்ல. அதாவது, சந்தைப்படுத்துபவர்கள் பல ஆண்டுகளாக சந்தையைப் படிக்கலாம் மற்றும் போட்டியாளர்களைப் பிடிக்க தங்கள் முழு வாழ்க்கையையும் செலவிடலாம். வாடிக்கையாளருக்கு என்ன தேவை என்பதை விரைவாகப் புரிந்துகொள்வது மற்றும் இந்த அல்லது அந்த அம்சத்தை செயல்படுத்த திட்டமிடுவது அவசியம் - பெரும்பாலும் DevOps வேலை செய்வதற்கும் நிறுவனம் அதன் இலக்கை அடையவும் இது போதாது. எனவே, முதலில், DevOps ஐ எவ்வாறு பயன்படுத்துவது என்பதைக் கற்றுக்கொள்வது அவசியம் என்று Raiffeisenbank வணிகத்துடன் ஒப்புக்கொண்டது. ஆட்டோமேஷனுக்கான ஆட்டோமேஷன் புதிய வாடிக்கையாளர்களுக்கான போராட்டத்தில் அதிகம் உதவாது.
பொதுவாக, DevOps செயல்படுத்தப்பட வேண்டும் என்று மிஷா நம்புகிறார், ஆனால் புத்திசாலித்தனமாக. மாற்றத்தின் தொடக்கத்தில் அணியின் உற்பத்தித்திறன் குறையும், அது குறைந்த பணம் சம்பாதிக்கும், ஆனால் அது நியாயப்படுத்தப்படும் என்பதற்கு நாம் தயாராக இருக்க வேண்டும்.
மேங்கோ டெலிகாமில் சோதனையின் ஆட்டோமேஷன்
ஒரு சோதனையாளராக எனக்கு மற்றொரு சுவாரஸ்யமான அறிக்கையை மேங்கோ டெலிகாமில் இருந்து எகோர் மஸ்லோவ் வழங்கினார். விளக்கக்காட்சி "ஒரு SCRUM குழுவில் முழு சோதனை சுழற்சியின் ஆட்டோமேஷன்" என்று அழைக்கப்பட்டது. DevOps குறிப்பாக SCRUM க்காக உருவாக்கப்பட்டது என்று எகோர் நம்புகிறார், ஆனால் அதே நேரத்தில், DevOps ஐ ஒரு SCRUM குழுவில் அறிமுகப்படுத்துவது மிகவும் சிக்கலானது. SCRUM குழு எப்போதும் எங்காவது இயங்குவதால் இது நிகழ்கிறது, புதுமைகளால் திசைதிருப்பப்படுவதற்கும் செயல்முறையை மீண்டும் உருவாக்குவதற்கும் நேரம் இல்லை. குழுவில் (சோதனை குழு, மேம்பாட்டுக் குழு மற்றும் பல) துணை அணிகளைப் பிரிப்பதை SCRUM உள்ளடக்கவில்லை என்ற உண்மையிலும் சிக்கல் உள்ளது. சரி, தவிர, ஏற்கனவே உள்ள செயல்முறையை தானியக்கமாக்க, ஆவணங்கள் தேவை, மற்றும் SCRUM இல், பெரும்பாலும் எந்த ஆவணமும் முழுமையாக இல்லை - "ஒருவித எழுத்தை விட தயாரிப்பு முக்கியமானது."
SCRUM க்கு மாறிய பிறகு, டெவலப்பர்களுடன் சோதனையாளர்கள் எவ்வாறு அம்சங்களைச் சோதிப்பது என்பது குறித்து ஆலோசனை செய்யத் தொடங்கினர். படிப்படியாக, செயல்பாட்டின் அளவு அதிகரித்தது, ஆவணங்கள் எதுவும் இல்லை, மேலும் அவை சோதனைகளால் மூடப்படாத செயல்பாட்டில் நிறைய பிழைகளைப் பிடிக்கத் தொடங்கின, பொதுவாக யார், எப்போது சோதித்தார்கள் என்பது தெளிவாகத் தெரியவில்லை. சுருக்கமாக - குழப்பம் மற்றும் ஊசலாட்டம். சோதனை ஆட்டோமேஷனுக்கு மாற முடிவு செய்தோம். ஆனால் அதிலும் முழு தோல்விதான் ஏற்பட்டது. அவர்கள் அவுட்சோர்ஸ் செய்யப்பட்ட ஆட்டோமேஷன் நிபுணர்களை பணியமர்த்தினார்கள், அவர்கள் வீட்டு சோதனையாளர்களுக்கு தெரியாத ஒரு அடுக்கில் எழுதினர். ஆட்டோடெஸ்ட்களுக்கான கட்டமைப்பு நிச்சயமாக வேலை செய்தது, ஆனால் அவுட்சோர்ஸர்கள் வெளியேறிய பிறகு, அது இரண்டு வாரங்கள் நீடித்தது. அடுத்ததாக ஆட்டோடெஸ்டிங் எண் இரண்டை அறிமுகப்படுத்தும் முயற்சி இருந்தது. SCRUM இன் கட்டமைப்பிற்குள், உங்கள் சொந்தமாக (சரியான திசையன்: உள்நாட்டில் நிபுணத்துவத்தை உருவாக்குதல்), மற்றும் செயல்பாட்டில் ஆவணங்களை உருவாக்குதல் ஆகியவற்றிற்குள் எல்லாவற்றையும் உருவாக்க வேண்டும் என்ற உண்மையுடன் இது தொடங்கியது. ஆட்டோமேஷனுக்கான ஸ்டாக் தயாரிப்பின் அடுக்கிற்கு சமமாக இருக்க வேண்டும் (இங்கே நான் அதைச் சேர்க்கிறேன், உங்கள் ஜாவாஸ்கிரிப்ட் திட்டத்தை வேறு எதையும் கொண்டு சோதிக்க வேண்டாம்). ஸ்பிரிண்டின் முடிவில், முழுக் குழுவுடன் (உதவியாக) ஆட்டோடெஸ்ட் எவ்வாறு செயல்படுகிறது என்பதை டெமோ செய்தார்கள். இதனால், ஆட்டோமேஷன் செயல்பாட்டில் அனைத்து குழு உறுப்பினர்களின் ஈடுபாடும் அதிகரித்தது, அத்துடன் தன்னியக்க சோதனைகளில் நம்பிக்கை மற்றும் இந்த தன்னியக்க சோதனை நிச்சயமாக பயன்படுத்தப்படும் (மற்றும் தொடர்ச்சியான தோல்விகள் காரணமாக ஒரு மாதத்தில் கருத்து தெரிவிக்கப்படாது).
DevOpsForum 2019 இல் ஒரு திறந்த மைக்ரோஃபோன் இருந்தது - இது நீண்ட காலமாக அறியப்பட்ட மற்றும் என் கருத்துப்படி, பேச்சுகளின் பயனுள்ள வடிவம். நீங்கள் இப்படிச் சுற்றித் திரிகிறீர்கள், அறிக்கைகளைக் கேளுங்கள், பின்னர் மாநாட்டில் ஒரு குறிப்பிட்ட தலைப்பு அல்லது சிக்கலைப் பற்றி விவாதிப்பது மதிப்புக்குரியது என்று முடிவு செய்யுங்கள், சிக்கலைத் தீர்ப்பதில் பொருத்தமான அனுபவத்தைப் பகிர்ந்து கொள்ளுங்கள்.
அமைப்பாளர்கள் குறுகிய அறிக்கைகளை வெளியிட்டதையும் கவனித்தேன். ஒவ்வொரு அறிக்கையும் 10 நிமிடங்களுக்கு மேல் நீடிக்காது, அதைத் தொடர்ந்து கேள்விகள். இந்த வழியில் நீங்கள் ஒரே நேரத்தில் பல தலைப்புகளை உள்ளடக்கி, உங்களுக்கு விருப்பமான பேச்சாளர்களிடம் கேள்விகளைக் கேட்கலாம்.
விளக்கக்காட்சிகளுக்கு இடையில், நான் மாநாட்டு கூட்டாளர்களின் சாவடிகளில் சுற்றித் திரிந்தேன் மற்றும் நிறைய விஷயங்களைத் திருடினேன்/வெற்றி பெற்றேன். ஓ, நான் கையேட்டை விரும்புகிறேன்!
Alfastrakhovanie இல் டெவலப்மெண்ட் இயக்குனருடன் வட்ட மேசை மற்றும் DevOps சிக்கல்கள்
எனக்கு DevOpsForum 2019 கேக்கில் ஐசிங் ஆனது DevOps நிபுணர்களுடனான ஒரு மணிநேர முழு அமர்வு. நான்கு அமர்வு பங்கேற்பாளர்கள் DevOps ஐ வெவ்வேறு கோணங்களில் பார்க்க அழைக்கப்பட்டனர்: அன்டன் இசானின் (Alfastrakhovanie, டெவலப்மெண்ட் இயக்குனர்), Nailya Zamashkina (Fintech Lab, இயக்க இயக்குனர்), Oleg Egorkin (Rostelecom, Agile coach) மற்றும் Anton Martyanov (சுயாதீன நிபுணர், DevOps ஐப் பார்த்தார். வணிகக் கண்ணோட்டத்தில்).
நிபுணர்கள் மக்களுக்கு நெருக்கமாக அமர்ந்தனர், பின்னர் விஷயங்கள் நடக்கத் தொடங்கின: ஒரு மணிநேரம் முழுவதும், பார்வையாளர்களிடமிருந்து பங்கேற்பாளர்கள் தங்கள் கேள்விகளைக் கேட்டார்கள், நிபுணர்கள் ராப் எடுத்தனர். சில நேரங்களில் உண்மையான விவாதங்கள் இருந்தன. கேள்விகள் மிகவும் வித்தியாசமாக இருந்தன, எடுத்துக்காட்டாக: DevOps இன்ஜினியர்கள் தேவைப்படுகிறார்களா, ஏன் அவர்களை கணினி நிர்வாகிகளாகப் பயிற்றுவிக்க முடியாது, அனைவருக்கும் DevOps வழங்கப்பட வேண்டுமா, அதன் மதிப்பு என்ன, மற்றும் பல.
பின்னர், நான் அன்டன் இசானினுடன் தனிப்பட்ட முறையில் பேசினேன். DevOps கலாச்சாரத்தை ஒவ்வொரு வீட்டிற்கும் கொண்டு வர வேண்டியதன் அவசியத்தை நாங்கள் விவாதித்தோம் மற்றும் DevOps மாற்றத்தின் இருண்ட பக்கத்தை வெளிப்படுத்தினோம்.
அனைவரும் ஒன்றிணைந்து, தயாரிப்பு மற்றும் வணிகம் மற்றும் குழு ஆகிய இரண்டிற்கும் DevOps தேவை என்று முடிவு செய்ததாக கற்பனை செய்துகொள்வோம். அதை செயல்படுத்த செல்லலாம். எல்லாம் பலனளித்தது. மூச்சை வெளியேற்றினோம். டெவொப்ஸ் எங்களை வாடிக்கையாளருடன் நெருக்கமாக்கியுள்ளது, இப்போது அவருடைய எல்லா விருப்பங்களையும் விரைவாக நிறைவேற்ற முடியும். இதன் விளைவாக, எங்களிடம் கடுமையான கட்டுப்பாடுகள் மற்றும் தேவைகள் கொண்ட ஒரு பெரிய Ops துறை உள்ளது, மேலும் அது தயாரிப்பில் உள்ள குறைபாடுகளை தொடர்ந்து கண்டறிந்து கோரிக்கைகளை உருவாக்குகிறது. மேலும், வாடிக்கையாளர் எதிர்பாராதவிதமாக பச்சை நிறத்திற்கு பதிலாக மஞ்சள் நிற பொத்தானை வண்ணமயமாக்க விரும்பினாலும், அனைத்து குறைபாடுகளுக்கும் "அவசர" நிலை ஒதுக்கப்படும். திட்டம் வளர்ந்து வருகிறது, வெளியீடுகளின் எண்ணிக்கை அதிகரித்து வருகிறது, அதன்படி, வாடிக்கையாளர்களின் புதிய செயல்பாட்டின் குறைபாடுகள் மற்றும் தவறான புரிதல்களின் எண்ணிக்கை. குறைபாடுகளைப் புகாரளிக்க Ops மேலும் 10 பேரை பணியமர்த்துகிறது, மேலும் மேம்பாடு அவர்களை மூடுவதற்கு மேலும் 15 பேரை பணியமர்த்துகிறது. புதிய அம்சங்களை அறிமுகப்படுத்துவதற்குப் பதிலாக, குழு முடிவில்லாத SD களுடன் செயல்படுகிறது, அதே நேரத்தில் பயனருக்கு செயல்பாட்டையும் ஆதரவையும் விளக்குகிறது. இதன் விளைவாக, Ops மற்றும் மேம்பாடு இரண்டும் வேலை செய்கின்றன, ஆனால் கிளையண்ட் மற்றும் வணிகம் மகிழ்ச்சியடையவில்லை: புதிய அம்சங்கள் சிக்கித் தவிக்கின்றன. DevOps இருப்பதாகத் தெரிகிறது, ஆனால் அது இருப்பதாகத் தெரியவில்லை.
DevOps ஐ செயல்படுத்த வேண்டியதன் அவசியத்தைப் பற்றி, இது நேரடியாக வணிகத்தின் அளவைப் பொறுத்தது என்று அன்டன் தெளிவாகக் கூறினார். வருடத்திற்கு ஒரு வாடிக்கையாளருக்கு சேவை செய்வது நிறுவனத்திற்கு பில்லியன்களை ஈட்டினால், DevOps தேவைப்படாது (இந்த கிளையண்டிற்கு நீங்கள் தொடர்ந்து புதிய மாற்றங்களைச் செய்ய வேண்டிய அவசியமில்லை). எல்லாம் சாக்லேட்டில் மூடப்பட்டிருக்கும். ஆனால் வணிகம் வளர்ந்து அதிக வாடிக்கையாளர்கள் தோன்றினால், நீங்கள் இணங்க வேண்டும். ஒரு விதியாக, ஆரம்பத்தில் நிறுவனத்தில் கூல் ஓப்ஸ் இல்லை. முதலில் நாங்கள் தயாரிப்பை வெட்டுகிறோம், அதன்பிறகுதான் தயாரிப்பு வேலை செய்ய, சேவையகங்களில் ஒரு கண் வைத்திருக்க வேண்டும் மற்றும் விநியோகங்களை கண்காணிக்க வேண்டும் என்பதை நாங்கள் புரிந்துகொள்கிறோம். அப்போதுதான் Ops வருகிறது. ஓப்ஸ், ஒரு தனிப் பிரிவாக, வளர்ச்சிக்கு தடைகளை உருவாக்கத் தொடங்கும் மற்றும் அனைத்து விநியோகங்களும் நிறுத்தத் தொடங்கும் என்பதை புரிந்து கொள்ள வேண்டும். அதாவது, இந்த விஷயத்தில், DevOps கலாச்சாரம் ஏற்கனவே பொருத்தமானது, ஆனால் அதன் இருண்ட பக்கத்தை நாம் மறந்துவிடக் கூடாது.
ஆதாரம்: www.habr.com