DevOps இன் வரையறை மிகவும் சிக்கலானது, எனவே ஒவ்வொரு முறையும் அதைப் பற்றிய விவாதத்தை மீண்டும் தொடங்க வேண்டும். ஹப்ரேயில் மட்டும் இந்த தலைப்பில் ஆயிரம் வெளியீடுகள் உள்ளன. ஆனால் நீங்கள் இதைப் படிக்கிறீர்கள் என்றால், DevOps என்றால் என்னவென்று உங்களுக்குத் தெரிந்திருக்கலாம். ஏனென்றால் நான் இல்லை. வணக்கம் என் பெயர் அலெக்சாண்டர் டிடோவ் (@), நாங்கள் DevOps பற்றி பேசுவோம், மேலும் எனது அனுபவத்தை பகிர்ந்து கொள்கிறேன்.
எனது கதையை எவ்வாறு பயனுள்ளதாக்குவது என்பது பற்றி நான் நீண்ட காலமாக யோசித்து வருகிறேன், எனவே இங்கே நிறைய கேள்விகள் இருக்கும் - நான் என்னிடம் கேட்பது மற்றும் எங்கள் நிறுவனத்தின் வாடிக்கையாளர்களிடம் நான் கேட்பது. இந்தக் கேள்விகளுக்குப் பதிலளிப்பதன் மூலம், புரிதல் சிறப்பாக இருக்கும். எனது பார்வையில் DevOps ஏன் தேவைப்படுகிறது, அது என்ன, மீண்டும், எனது பார்வையில் இருந்து, மற்றும் எனது பார்வையில் நீங்கள் மீண்டும் DevOps நோக்கி நகர்கிறீர்கள் என்பதை எப்படி புரிந்துகொள்வது என்பதை நான் உங்களுக்கு கூறுவேன். கடைசி புள்ளி கேள்விகள் மூலம் இருக்கும். அவற்றுக்கு நீங்களே பதிலளிப்பதன் மூலம், உங்கள் நிறுவனம் DevOps நோக்கி நகர்கிறதா அல்லது ஏதேனும் சிக்கல்கள் உள்ளதா என்பதை நீங்கள் புரிந்து கொள்ளலாம்.
ஒரு காலத்தில் நான் இணைப்புகள் மற்றும் கையகப்படுத்துதல்களின் அலைகளை சவாரி செய்து கொண்டிருந்தேன். முதலில், நான் Qik என்ற சிறிய தொடக்கத்தில் வேலை செய்தேன், அதை ஸ்கைப் என்ற சற்றே பெரிய நிறுவனம் வாங்கியது, அதை மைக்ரோசாப்ட் என்ற சற்றே பெரிய நிறுவனம் வாங்கியது. அந்த நேரத்தில், வெவ்வேறு அளவு நிறுவனங்களில் DevOps யோசனை எவ்வாறு மாறுகிறது என்பதைப் பார்க்க ஆரம்பித்தேன். அதன் பிறகு, DevOps ஐ சந்தைக் கண்ணோட்டத்தில் பார்ப்பதில் எனக்கு ஆர்வம் ஏற்பட்டது, நானும் எனது சகாக்களும் எக்ஸ்பிரஸ் 42 என்ற நிறுவனத்தை நிறுவினோம். 6 ஆண்டுகளாக நாங்கள் சந்தையின் அலைகளை நகர்த்தி வருகிறோம்.
மற்றவற்றுடன், நான் DevOps மாஸ்கோ சமூகத்தின் அமைப்பாளர்களில் ஒருவராகவும், DevOps-Days 2017 இன் அமைப்பாளராகவும் இருக்கிறேன், ஆனால் நான் 2018 ஐ ஏற்பாடு செய்யவில்லை. எக்ஸ்பிரஸ் 42 பல நிறுவனங்களுடன் இணைந்து செயல்படுகிறது. நாங்கள் அங்கு DevOps வளர்க்கிறோம், அது எப்படி நடக்கிறது என்பதைப் பார்க்கிறோம், முடிவுகளை எடுக்கிறோம், பகுப்பாய்வு செய்கிறோம், எங்கள் முடிவுகளை அனைவருக்கும் கூறுகிறோம், மேலும் DevOps நடைமுறைகளில் மக்களுக்குப் பயிற்சி அளிக்கிறோம். பொதுவாக, இந்த விஷயத்தில் எங்கள் அனுபவத்தையும் நிபுணத்துவத்தையும் அதிகரிக்க எங்களால் முடிந்த அனைத்தையும் செய்து வருகிறோம்.
ஏன் DevOps
எல்லோரையும் எப்போதும் வேட்டையாடும் முதல் கேள்வி - ஏன்? டெவொப்ஸ் என்பது ஆட்டோமேஷன் அல்லது ஒவ்வொரு நிறுவனமும் ஏற்கனவே இருந்ததைப் போன்றது என்று பலர் நினைக்கிறார்கள்.
— எங்களிடம் தொடர்ச்சியான ஒருங்கிணைப்பு இருந்தது - இதன் பொருள் எங்களிடம் ஏற்கனவே DevOps இருந்தது, மேலும் இந்த விஷயங்கள் ஏன் தேவை? அவர்கள் வெளிநாட்டில் வேடிக்கை பார்க்கிறார்கள், ஆனால் அவர்கள் எங்களை வேலை செய்ய விடாமல் தடுக்கிறார்கள்!
சமூகம் மற்றும் வழிமுறையின் 9 ஆண்டுகால வளர்ச்சியில், இது இன்னும் மினுமினுப்பை சந்தைப்படுத்தவில்லை என்பது ஏற்கனவே தெளிவாகிவிட்டது, ஆனால் அது ஏன் தேவைப்படுகிறது என்பது இன்னும் தெளிவாகத் தெரியவில்லை. எந்தவொரு கருவி மற்றும் செயல்முறையைப் போலவே, DevOps குறிப்பிட்ட இலக்குகளைக் கொண்டுள்ளது, அது இறுதியில் அடையும்.
இதற்கெல்லாம் காரணம் உலகம் மாறிக்கொண்டே இருக்கிறது. எண்டர்பிரைஸ் அணுகுமுறையில் இருந்து விலகி, நிறுவனங்கள் நேராக ஒரு கனவை நோக்கி நகரும் போது, எங்கள் செயின்ட் பீட்டர்ஸ்பர்க் கிளாசிக் பாடியது போல், ஒரு குறிப்பிட்ட உத்தியின்படி புள்ளி A முதல் புள்ளி B வரை, ஒரு குறிப்பிட்ட கட்டமைப்பைக் கொண்டு கட்டப்பட்டது.
கொள்கையளவில், ஐடியில் உள்ள அனைத்தும் இந்த அணுகுமுறையின்படி கட்டமைக்கப்பட வேண்டும். இங்கே IT செயல்முறைகளை தானியக்கமாக்க பிரத்தியேகமாக பயன்படுத்தப்படுகிறது.
ஆட்டோமேஷன் அடிக்கடி மாறாது, ஏனென்றால் ஒரு நிறுவனம் நன்கு மிதித்த பாதையில் இறங்கும்போது, மாற்றுவதற்கு என்ன இருக்கிறது? இது வேலை செய்கிறது - அதைத் தொடாதே. இப்போது உலகில் அணுகுமுறைகள் மாறி வருகின்றன, மேலும் அஜில் என்று அழைக்கப்படும் ஒரு முடிவு புள்ளி B உடனடியாகத் தெரியவில்லை என்று கூறுகிறது.
ஒரு நிறுவனம் சந்தை வழியாகச் செல்லும்போது, வாடிக்கையாளருடன் பணிபுரியும் போது, அது தொடர்ந்து சந்தையை ஆராய்ந்து இறுதிப் புள்ளி B ஐ மாற்றுகிறது. மேலும், நிறுவனம் தனது திசையை அடிக்கடி மாற்றினால், இறுதியில் அது மிகவும் வெற்றிகரமானது, ஏனெனில் அது அதிக சந்தையைத் தேர்ந்தெடுக்கிறது. முக்கிய இடங்கள்.
நான் சமீபத்தில் கற்றுக்கொண்ட ஒரு சுவாரஸ்யமான நிறுவனத்தால் இந்த மூலோபாயம் நிரூபிக்கப்பட்டுள்ளது. ஒன் பாக்ஸ் ஷேவ் என்பது ஒரு பெட்டியில் ரேஸர்கள் மற்றும் ஷேவிங் ஆக்சஸரீஸ்களுக்கான சந்தா டெலிவரி சேவையாகும். வெவ்வேறு வாடிக்கையாளர்களுக்கு தங்கள் "பெட்டியை" எவ்வாறு தனிப்பயனாக்குவது என்பது அவர்களுக்குத் தெரியும். இது ஒரு குறிப்பிட்ட மென்பொருளால் செய்யப்படுகிறது, பின்னர் பொருட்களை உற்பத்தி செய்யும் கொரிய தொழிற்சாலைக்கு ஆர்டரை அனுப்புகிறது.
இந்த தயாரிப்பை யுனிலீவர் $1 பில்லியனுக்கு வாங்கியது. இது இப்போது ஜில்லட்டுடன் போட்டியிடுகிறது மற்றும் அமெரிக்க சந்தையில் நுகர்வோரின் கணிசமான பங்கைப் பறித்துள்ளது. ஒரு பெட்டி ஷேவ் கூறுகிறது:
- 4 கத்திகள்? நீங்கள் தீவிரமாக இருக்கிறீர்களா? உங்களுக்கு இது ஏன் தேவை - இது ஷேவின் தரத்தை மேம்படுத்தாது. பிரத்யேகமாக தேர்ந்தெடுக்கப்பட்ட க்ரீம், வாசனை திரவியம் மற்றும் இரண்டு பிளேடுகளுடன் கூடிய உயர்தர ரேஸர் ஆகியவை அந்த முட்டாள் 4 ஜில்லட் பிளேடுகளை விட அதிக பிரச்சனைகளை தீர்க்கும்! விரைவில் 10க்கு வருவோம்?
இப்படித்தான் உலகம் மாறுகிறது. யூனிலீவர், தங்களிடம் குளிர்ச்சியான தகவல் தொழில்நுட்ப அமைப்பு இருப்பதாகக் கூறுகிறது, அது உங்களை இதைச் செய்ய அனுமதிக்கிறது. இறுதியில் அது ஒரு கருத்தாகத் தெரிகிறது சந்தைக்கு நேரம், இது பற்றி ஏற்கனவே யாரும் பேசவில்லை.
நாம் எவ்வளவு அடிக்கடி பயன்படுத்துகிறோம் என்பதில் டைம்-டு-மார்க்கெட் புள்ளி. நீங்கள் அடிக்கடி வரிசைப்படுத்தலாம், ஆனால் வெளியீட்டு சுழற்சிகள் நீண்டதாக இருக்கும். மூன்று மாத வெளியீட்டு சுழற்சிகள் ஒன்றையொன்று மிகைப்படுத்தி, அவற்றை ஒரு வாரத்திற்கு மாற்றினால், நிறுவனம் வாரத்திற்கு ஒரு முறை வரிசைப்படுத்துவது போல் தெரிகிறது. யோசனையிலிருந்து இறுதிச் செயலாக்கம் வரை 3 மாதங்கள் ஆகும்.
டைம்-டு-மார்க்கெட் என்பது யோசனையிலிருந்து இறுதிச் செயலாக்கம் வரையிலான நேரத்தைக் குறைப்பதாகும்.
இந்த வழக்கில், மென்பொருள் சந்தையுடன் தொடர்பு கொள்கிறது. ஒன் பாக்ஸ் ஷேவ் இணையதளம் கிளையண்டுடன் இப்படித்தான் தொடர்பு கொள்கிறது. அவர்களிடம் விற்பனையாளர்கள் இல்லை - பார்வையாளர்கள் கிளிக் செய்து விருப்பங்களை விட்டுச் செல்லும் இணையதளம். அதன்படி, புதிதாக ஏதாவது தொடர்ந்து தளத்தில் இடுகையிடப்பட்டு விருப்பத்திற்கு ஏற்ப புதுப்பிக்கப்பட வேண்டும். உதாரணமாக, தென் கொரியாவில் அவர்கள் ரஷ்யாவை விட வித்தியாசமாக ஷேவ் செய்கிறார்கள், மேலும் அவர்கள் பைன் வாசனையை விரும்புவதில்லை, எடுத்துக்காட்டாக, கேரட் மற்றும் வெண்ணிலாவின் வாசனையை விரும்புகிறார்கள்.
தளத்தின் உள்ளடக்கத்தை விரைவாக மாற்றுவது அவசியம் என்பதால், மென்பொருள் மேம்பாடு பெரிதும் மாறுகிறது. மென்பொருள் மூலம் வாடிக்கையாளர் என்ன விரும்புகிறார் என்பதை நாம் கண்டுபிடிக்க வேண்டும். முன்னதாக, இதை சில ரவுண்டானா வழிகள் மூலம் கற்றுக்கொண்டோம், எடுத்துக்காட்டாக, வணிக மேலாண்மை மூலம். பின்னர் நாங்கள் அதை வடிவமைத்தோம், தேவைகளை ஐடி அமைப்பில் வைத்தோம், எல்லாம் அருமையாக இருந்தது. இப்போது இது வேறுபட்டது - பொறியாளர்கள் உட்பட செயல்பாட்டில் ஈடுபட்டுள்ள அனைவராலும் மென்பொருள் வடிவமைக்கப்பட்டுள்ளது, ஏனெனில் தொழில்நுட்ப விவரக்குறிப்புகள் மூலம் சந்தை எவ்வாறு செயல்படுகிறது என்பதை அவர்கள் கற்றுக்கொள்கிறார்கள் மற்றும் வணிகத்துடன் தங்கள் நுண்ணறிவுகளைப் பகிர்ந்து கொள்கிறார்கள்.
எடுத்துக்காட்டாக, Qik இல், மக்கள் தொடர்புப் பட்டியலை சர்வரில் பதிவேற்றுவதை மிகவும் விரும்புகிறார்கள் என்பதை நாங்கள் திடீரென்று அறிந்தோம், மேலும் அவர்கள் எங்களுக்கு ஒரு விண்ணப்பத்தை வழங்கினர். ஆரம்பத்தில் நாங்கள் அதைப் பற்றி சிந்திக்கவில்லை. ஒரு கிளாசிக் நிறுவனத்தில், இது ஒரு பிழை என்று எல்லோரும் முடிவு செய்திருப்பார்கள், ஏனெனில் இது சிறப்பாக செயல்பட வேண்டும் என்று ஸ்பெக் கூறவில்லை மற்றும் பொதுவாக முழங்காலில் செயல்படுத்தப்படுகிறது, அவர்கள் அம்சத்தை அணைத்துவிட்டு, "இது யாருக்கும் தேவையில்லை, மிக முக்கியமான விஷயம் என்னவென்றால், முக்கிய செயல்பாடு செயல்படுகிறது." . மேலும் தொழில்நுட்ப நிறுவனம் இதை ஒரு வாய்ப்பாகக் கருதி இதற்கு ஏற்ப மென்பொருளை மாற்றத் தொடங்குகிறது.
1968 ஆம் ஆண்டில், மெல்வின் கான்வே என்ற தொலைநோக்கு நபர் பின்வரும் யோசனையை வகுத்தார்.
அமைப்பை உருவாக்கும் நிறுவனம், அந்த நிறுவனத்தின் தகவல் தொடர்பு கட்டமைப்பை பிரதிபலிக்கும் வடிவமைப்பால் கட்டுப்படுத்தப்படுகிறது.
இன்னும் விரிவாக, வேறு வகையான அமைப்புகளை உருவாக்க, நீங்கள் வேறு வகையான நிறுவனத்திற்குள் ஒரு தகவல்தொடர்பு கட்டமைப்பையும் கொண்டிருக்க வேண்டும். உங்கள் தகவல்தொடர்பு அமைப்பு உயர்-படிநிலையாக இருந்தால், இது மிக உயர்ந்த நேர-சந்தை காட்டி வழங்கக்கூடிய அமைப்புகளை உருவாக்க உங்களை அனுமதிக்காது.
படி முடியும் . DevOps கலாச்சாரம் அல்லது தத்துவத்தைப் புரிந்துகொள்வது முக்கியம் DevOps இல் அடிப்படையில் மாறும் ஒரே விஷயம் அணிகளுக்கிடையேயான தகவல்தொடர்பு கட்டமைப்பாகும்.
ஒரு செயல்முறைக் கண்ணோட்டத்தில், DevOps க்கு முன், அனைத்து நிலைகளும்: பகுப்பாய்வு, மேம்பாடு, சோதனை, செயல்பாடு, நேரியல்.
DevOps விஷயத்தில், இந்த செயல்முறைகள் அனைத்தும் ஒரே நேரத்தில் நிகழ்கின்றன.
நேரத்தைச் சந்தைப்படுத்துவதுதான் அதைச் செய்யக்கூடிய ஒரே வழி. பழைய செயல்பாட்டில் பணிபுரிந்தவர்களுக்கு, இது ஓரளவு அண்டமாகத் தெரிகிறது, பொதுவாக அப்படித்தான்.
உங்களுக்கு ஏன் DevOps தேவை?
டிஜிட்டல் தயாரிப்பு மேம்பாட்டிற்காக. உங்கள் நிறுவனத்தில் டிஜிட்டல் தயாரிப்பு இல்லை என்றால், DevOps தேவையில்லை - இது மிகவும் முக்கியமானது.
DevOps தொடர்ச்சியான மென்பொருள் உற்பத்தியின் வேக வரம்புகளை மீறுகிறது. அதில் அனைத்து செயல்முறைகளும் ஒரே நேரத்தில் நிகழ்கின்றன.
சிரமம் அதிகரிக்கிறது. DevOps சுவிசேஷகர்கள் உங்களுக்கு மென்பொருளை வெளியிடுவதை எளிதாக்கும் என்று கூறும்போது, இது முட்டாள்தனம்.
DevOps மூலம், விஷயங்கள் மிகவும் சிக்கலானதாக இருக்கும்.
Avito ஸ்டாண்டில் நடந்த மாநாட்டில், ஒரு டோக்கர் கொள்கலனை வரிசைப்படுத்துவது எப்படி இருந்தது என்பதை நீங்கள் காணலாம் - இது ஒரு நம்பத்தகாத பணி. சிக்கலானது தடைசெய்யப்படுகிறது; நீங்கள் ஒரே நேரத்தில் பல பந்துகளை ஏமாற்ற வேண்டும்.
DevOps நிறுவனத்தில் செயல்முறை மற்றும் அமைப்பை முற்றிலும் மாற்றுகிறது — இன்னும் துல்லியமாக, மாற்றுவது DevOps அல்ல, ஆனால் டிஜிட்டல் தயாரிப்பு. DevOps க்கு வர, நீங்கள் இன்னும் இந்த செயல்முறையை முழுமையாக மாற்ற வேண்டும்.
ஒரு நிபுணருக்கான கேள்விகள்
உன்னிடம் என்ன இருக்கிறது? ஒரு நிறுவனத்தில் பணிபுரியும் போது மற்றும் ஒரு நிபுணராக வளரும்போது உங்களை நீங்களே கேட்டுக்கொள்ளக்கூடிய கேள்விகள்.
டிஜிட்டல் தயாரிப்பை உருவாக்குவதற்கான உத்தி உங்களிடம் உள்ளதா? இருந்தால், அது ஏற்கனவே நல்லது. இதன் பொருள் உங்கள் நிறுவனம் DevOps நோக்கி நகர்கிறது.
உங்கள் நிறுவனம் ஏற்கனவே டிஜிட்டல் தயாரிப்பை உருவாக்குகிறதா? DevOps பார்வையில் இருந்து, நீங்கள் மற்றொரு நிலைக்கு உயர்ந்து மேலும் சுவாரஸ்யமாக விஷயங்களைச் செய்யலாம் என்பதே இதன் பொருள். இந்தக் கண்ணோட்டத்தில்தான் நான் பேசுகிறேன்.
டிஜிட்டல் தயாரிப்புகளின் சந்தையில் உங்கள் நிறுவனம் முன்னணியில் உள்ளதா? Spotify, Yandex, Uber ஆகியவை இப்போது தொழில்நுட்ப முன்னேற்றத்தின் உச்சத்தில் இருக்கும் நிறுவனங்கள்.
இந்தக் கேள்விகளை நீங்களே கேட்டுக்கொள்ளுங்கள், எல்லா பதில்களும் இல்லை என்றால், இந்த நிறுவனத்தில் நீங்கள் DevOps செய்யக்கூடாது. DevOps இன் தலைப்பு உங்களுக்கு மிகவும் சுவாரசியமாக இருந்தால், ஒருவேளை... நீங்கள் வேறு நிறுவனத்திற்கு மாற வேண்டுமா? உங்கள் நிறுவனம் DevOps க்கு செல்ல விரும்பினால், எல்லா கேள்விகளுக்கும் "இல்லை" என்று பதிலளித்திருந்தால், அது எப்போதும் மாறாத அழகான காண்டாமிருகம் போன்றது.
அமைப்பு
நான் சொன்னது போல், கான்வேயின் சட்டத்தின்படி, ஒரு நிறுவனத்தின் அமைப்பு மாறுகிறது. நிறுவனக் கண்ணோட்டத்தில் டெவொப்ஸ் நிறுவனத்திற்குள் ஊடுருவுவதைத் தடுப்பதன் மூலம் தொடங்குவேன்.
"கிணறுகள்" பிரச்சனை
"Silo" என்ற ஆங்கில வார்த்தை இங்கு ரஷ்ய மொழியில் "well" என்று மொழிபெயர்க்கப்பட்டுள்ளது. இந்தப் பிரச்சனையின் நோக்கம் அதுதான் அணிகளுக்கு இடையே தகவல் பரிமாற்றம் இல்லை. வழிசெலுத்துவதற்கு பொதுவான வரைபடத்தை உருவாக்காமல், ஒவ்வொரு குழுவும் அதன் நிபுணத்துவத்தை ஆழமாக தோண்டி எடுக்கிறது.
சில வழிகளில் இது மாஸ்கோவிற்கு வந்த ஒரு நபரை நினைவூட்டுகிறது, மேலும் மெட்ரோ வரைபடத்தை எவ்வாறு வழிநடத்துவது என்று தெரியவில்லை. மஸ்கோவியர்கள் பொதுவாக தங்கள் பகுதியை நன்கு அறிவார்கள், மேலும் மாஸ்கோ முழுவதும் அவர்கள் மெட்ரோ வரைபடத்தைப் பயன்படுத்தி செல்லலாம். நீங்கள் முதல் முறையாக மாஸ்கோவிற்கு வரும்போது, இந்த திறமை உங்களிடம் இல்லை, மேலும் நீங்கள் திசைதிருப்பப்படுகிறீர்கள்.
DevOps இந்த திசைதிருப்பல் மற்றும் பொதுவான தொடர்பு வரைபடத்தை உருவாக்க அனைத்து துறைகளும் இணைந்து செயல்பட பரிந்துரைக்கிறது.
இதற்கு இரண்டு காரணிகள் தடையாக உள்ளன.
கார்ப்பரேட் மேலாண்மை அமைப்பின் விளைவு. இது தனி படிநிலை "கிணறுகளில்" கட்டப்பட்டுள்ளது. எடுத்துக்காட்டாக, இந்த அமைப்பை ஆதரிக்கும் நிறுவனங்களில் சில KPIகள் உள்ளன. மறுபுறம், ஒரு நபரின் மூளை தனது நிபுணத்துவத்தின் எல்லைகளைத் தாண்டி முழு அமைப்பையும் வழிநடத்துவது கடினம். இது சங்கடமாக இருக்கிறது. நீங்கள் பாங்காக் விமான நிலையத்தில் இருக்கிறீர்கள் என்று கற்பனை செய்து பாருங்கள் - உங்கள் வழியை விரைவாகக் கண்டுபிடிக்க முடியாது. DevOps வழிசெலுத்துவது கடினம், அதனால்தான் நீங்கள் அங்கு செல்ல வழிகாட்டியைக் கண்டுபிடிக்க வேண்டும் என்று மக்கள் கூறுகிறார்கள்.
ஆனால் மிக முக்கியமான விஷயம் என்னவென்றால், DevOps இன் உணர்வால் ஈர்க்கப்பட்ட ஒரு பொறியாளருக்கு "கிணறுகள்" பற்றிய பிரச்சனை, Fowler மற்றும் பிற புத்தகங்களைப் படித்தது, உண்மையில் வெளிப்படுத்தப்படுகிறது. "கிணறுகள்" உங்களை "வெளிப்படையான" விஷயங்களைச் செய்ய அனுமதிக்காது. DevOps மாஸ்கோவிற்குப் பிறகு நாங்கள் அடிக்கடி ஒன்றுகூடுவோம், ஒருவருக்கொருவர் பேசுகிறோம், மக்கள் புகார் செய்கிறார்கள்:
- நாங்கள் CI ஐத் தொடங்க விரும்பினோம், ஆனால் நிர்வாகத்திற்கு அது தேவையில்லை என்று மாறியது.
இது துல்லியமாக நடக்கிறது என்பதால் CI и தொடர்ச்சியான விநியோக செயல்முறை பல தேர்வுகளின் எல்லையில் உள்ளன. நிறுவன மட்டத்தில் "கிணறுகள்" பிரச்சனையை சமாளிக்காமல், நீங்கள் என்ன செய்தாலும், எவ்வளவு சோகமாக இருந்தாலும், நீங்கள் முன்னேற முடியாது.
நிறுவனத்தில் செயல்பாட்டில் உள்ள ஒவ்வொரு பங்கேற்பாளரும்: பின்தளம் மற்றும் முன்னோடி டெவலப்பர்கள், சோதனை, டிபிஏ, செயல்பாடு, நெட்வொர்க், தங்கள் சொந்த திசையில் தோண்டி எடுக்கிறார்கள், மேலாளரைத் தவிர வேறு யாருக்கும் பொதுவான வரைபடம் இல்லை, அவர் எப்படியாவது அவர்களைக் கண்காணித்து "பிரிவு" ஐப் பயன்படுத்தி நிர்வகிக்கிறார். மற்றும் வெற்றி” முறை.
மக்கள் சில நட்சத்திரங்கள் அல்லது கொடிகளுக்காக போராடுகிறார்கள், ஒவ்வொருவரும் தங்கள் நிபுணத்துவத்தை தோண்டி எடுக்கிறார்கள்.
இதன் விளைவாக, இவை அனைத்தையும் ஒன்றாக இணைத்து ஒரு பொதுவான குழாய் அமைப்பதற்கான பணி எழும் போது, மேலும் நட்சத்திரங்கள் மற்றும் கொடிகளுக்காக இனி போராட வேண்டிய அவசியமில்லை, கேள்வி எழுகிறது - எப்படியும் என்ன செய்வது? நாங்கள் எப்படியாவது ஒரு உடன்படிக்கைக்கு வர வேண்டும், ஆனால் பள்ளியில் இதை எப்படி செய்வது என்று யாரும் எங்களுக்குக் கற்பிக்கவில்லை. நாங்கள் பள்ளியிலிருந்து கற்பிக்கப்படுகிறோம்: எட்டாம் வகுப்பு - ஆஹா! - ஏழாம் வகுப்போடு ஒப்பிடும்போது! இங்கேயும் அப்படித்தான்.
உங்கள் நிறுவனத்திலும் அப்படியா?
இதைச் சரிபார்க்க, பின்வரும் கேள்விகளை நீங்களே கேட்டுக்கொள்ளலாம்.
குழுக்கள் பொதுவான கருவிகளைப் பயன்படுத்துகின்றனவா மற்றும் அந்த பொதுவான கருவிகளில் மாற்றங்களுக்கு பங்களிக்கின்றனவா?
அணிகள் எத்தனை முறை மறுசீரமைக்கப்படுகின்றன - ஒரு குழுவிலிருந்து சில நிபுணர்கள் மற்றொரு அணிக்கு மாறுகிறார்கள்? DevOps சூழலில் இது சாதாரணமாகிறது, ஏனென்றால் சில நேரங்களில் ஒரு நபர் நிபுணத்துவத்தின் மற்றொரு பகுதி என்ன செய்கிறார் என்பதைப் புரிந்து கொள்ள முடியாது. அவர் வேறொரு துறைக்குச் செல்கிறார், இரண்டு வாரங்கள் அங்கு பணிபுரிந்து, இந்தத் துறையுடன் நோக்குநிலை மற்றும் தொடர்பு பற்றிய வரைபடத்தை உருவாக்குகிறார்.
மாற்றக் குழுவை அமைத்து விஷயங்களை மாற்ற முடியுமா? அல்லது அதற்கு மிக உயர்ந்த நிர்வாகம் மற்றும் வழிகாட்டுதலின் வலுவான கரம் தேவையா? கொஞ்சம் அறியப்படாத வங்கி ஆர்டர்கள் மூலம் கருவிகளை எவ்வாறு செயல்படுத்துகிறது என்பதை நான் சமீபத்தில் பேஸ்புக்கில் எழுதினேன்: நாங்கள் ஒரு ஆர்டரை எழுதுகிறோம், அதை ஒரு வருடத்திற்கு செயல்படுத்துகிறோம், என்ன நடக்கிறது என்று பார்க்கிறோம். இது, நிச்சயமாக, நீண்ட மற்றும் சோகமானது.
நிறுவனத்தின் சாதனைகளைக் கருத்தில் கொள்ளாமல் மேலாளர்கள் தனிப்பட்ட சாதனைகளைப் பெறுவது எவ்வளவு முக்கியம்?
இந்தக் கேள்விகளுக்கு நீங்களே பதில் சொன்னால், உங்கள் நிறுவனத்தில் இதுபோன்ற பிரச்னை உள்ளதா என்பது தெளிவாகத் தெரியும்.
குறியீடாக உள்கட்டமைப்பு
இந்தச் சிக்கல் கடந்துவிட்ட பிறகு, முதல் முக்கியமான நடைமுறை, இது இல்லாமல் DevOps இல் மேலும் முன்னேறுவது கடினம் உள்கட்டமைப்பு குறியீடாக.
பெரும்பாலும், உள்கட்டமைப்பு குறியீடாக பின்வருமாறு உணரப்படுகிறது:
— பாஷில் எல்லாவற்றையும் தானியக்கமாக்குவோம், ஸ்கிரிப்ட்களால் நம்மை மறைத்துக்கொள்வோம், இதனால் நிர்வாகிகளுக்கு குறைவான கைமுறை வேலைகள் இருக்கும்!
ஆனால் அது உண்மையல்ல.
உள்கட்டமைப்பு என்பது குறியீடாக நீங்கள் பணிபுரியும் IT அமைப்பை அதன் நிலையை தொடர்ந்து புரிந்து கொள்வதற்காக குறியீட்டின் வடிவத்தில் விவரிக்கிறீர்கள்.
மற்ற குழுக்களுடன் சேர்ந்து, அனைவரும் புரிந்துகொள்ளக்கூடிய மற்றும் வழிசெலுத்த மற்றும் செல்லக்கூடிய குறியீட்டு வடிவத்தில் வரைபடத்தை உருவாக்குகிறீர்கள். செஃப், அன்சிபிள், சால்ட் அல்லது குபெர்னெட்ஸில் YAML கோப்புகளைப் பயன்படுத்துவது - இது என்ன செய்யப்படுகிறது என்பது முக்கியமல்ல.
மாநாட்டில், 2GIS இன் சக ஊழியர் ஒருவர் குபெர்னெட்டஸுக்கு தங்கள் சொந்த உள் விஷயத்தை எவ்வாறு உருவாக்கினார் என்று கூறினார், இது தனிப்பட்ட அமைப்புகளின் கட்டமைப்பை விவரிக்கிறது. 500 அமைப்புகளை விவரிக்க, இந்த விளக்கத்தை உருவாக்கும் ஒரு தனி கருவி தேவைப்பட்டது. இந்த விளக்கம் இருக்கும் போது, ஒவ்வொருவரும் ஒருவரையொருவர் சரிபார்க்கலாம், மாற்றங்களைக் கண்காணிக்கலாம், அதை எவ்வாறு மாற்றுவது மற்றும் மேம்படுத்துவது, என்ன விடுபட்டுள்ளது.
ஒப்புக்கொள்கிறேன், தனிப்பட்ட பாஷ் ஸ்கிரிப்டுகள் பொதுவாக இந்த புரிதலை வழங்காது. நான் பணிபுரிந்த நிறுவனங்களில் ஒன்றில், "எழுதுவதற்கு மட்டும்" ஸ்கிரிப்ட் என்று ஒரு பெயர் கூட இருந்தது - ஸ்கிரிப்ட் எழுதப்படும் போது, ஆனால் அதை இனி படிக்க முடியாது. இது உங்களுக்கும் தெரிந்திருக்கும் என்று நினைக்கிறேன்.
உள்கட்டமைப்பு என்பது குறியீடு உள்கட்டமைப்பின் தற்போதைய நிலையை விவரிக்கும் குறியீடு. பல தயாரிப்பு, உள்கட்டமைப்பு மற்றும் சேவைக் குழுக்கள் இந்தக் குறியீட்டில் ஒன்றாகச் செயல்படுகின்றன, மிக முக்கியமாக, இந்தக் குறியீடு உண்மையில் எவ்வாறு செயல்படுகிறது என்பதை அவர்கள் அனைவரும் புரிந்து கொள்ள வேண்டும்.
குறியீடு சிறந்த குறியீடு நடைமுறைகளின்படி பராமரிக்கப்படுகிறது: கூட்டு மேம்பாடு, குறியீடு மதிப்பாய்வு, XP- நிரலாக்கம், சோதனை, கோரிக்கைகளை இழுத்தல், குறியீடு உள்கட்டமைப்புகளுக்கான CI - இவை அனைத்தும் பொருத்தமானவை மற்றும் பயன்படுத்தப்படலாம்.
குறியீடு அனைத்து பொறியாளர்களுக்கும் பொதுவான மொழியாகிறது.
குறியீட்டில் உள்கட்டமைப்பை மாற்றுவதற்கு அதிக நேரம் எடுக்காது. ஆம், உள்கட்டமைப்பு குறியீடு தொழில்நுட்பக் கடனையும் கொண்டிருக்கலாம். வழக்கமாக அணிகள் "உள்கட்டமைப்பைக் குறியீடாக" செயல்படுத்தத் தொடங்கிய ஒன்றரை ஆண்டுகளுக்குப் பிறகு ஸ்கிரிப்ட்கள் அல்லது அன்சிபிள் போன்ற வடிவங்களில் அதைச் சந்திப்பார்கள், அதை அவர்கள் ஸ்பாகெட்டி குறியீடு போல எழுதுகிறார்கள், மேலும் அவர்கள் பாஷ் ஸ்கிரிப்ட்களையும் கலவையில் வீசுகிறார்கள்!
முக்கியமான: நீங்கள் இன்னும் இதை முயற்சிக்கவில்லை என்றால், அதை நினைவில் கொள்ளுங்கள் அன்சிபிள் என்பது பேஷ் அல்ல! ஆவணங்களை கவனமாகப் படியுங்கள், அதைப் பற்றி அவர்கள் என்ன எழுதுகிறார்கள் என்பதைப் படிக்கவும்.
உள்கட்டமைப்பு என்பது, உள்கட்டமைப்புக் குறியீட்டை தனி அடுக்குகளாகப் பிரிப்பதாகும்.
எங்கள் நிறுவனத்தில், நாங்கள் 3 அடிப்படை அடுக்குகளை வேறுபடுத்துகிறோம், அவை மிகவும் தெளிவான மற்றும் எளிமையானவை, ஆனால் அவற்றில் அதிகமானவை இருக்கலாம். உங்கள் உள்கட்டமைப்பு குறியீட்டைப் பார்த்து, உங்களுக்கு இந்த நிலை இருக்கிறதா இல்லையா என்று சொல்லலாம். அடுக்குகள் எதுவும் ஹைலைட் செய்யப்படவில்லை என்றால், நீங்கள் சிறிது நேரம் எடுத்து சிறிது மறுசீரமைக்க வேண்டும்.
அடிப்படை அடுக்கு - OS, காப்புப்பிரதிகள் மற்றும் பிற குறைந்த-நிலை விஷயங்கள் இப்படித்தான் கட்டமைக்கப்படுகின்றன, எடுத்துக்காட்டாக, குபெர்னெட்ஸ் அடிப்படை மட்டத்தில் எவ்வாறு பயன்படுத்தப்படுகிறது.
சேவை நிலை - இவை டெவலப்பருக்கு நீங்கள் வழங்கும் சேவைகள்: ஒரு சேவையாக உள்நுழைதல், ஒரு சேவையாக கண்காணிப்பு, ஒரு சேவையாக தரவுத்தளம், ஒரு சேவையாக பேலன்சர், ஒரு சேவையாக வரிசை, ஒரு சேவையாக தொடர்ச்சியான டெலிவரி - தனிப்பட்ட குழுக்கள் வழங்கும் சேவைகளின் தொகுப்பு வளர்ச்சிக்கு வழங்க முடியும். இவை அனைத்தும் உங்கள் உள்ளமைவு மேலாண்மை அமைப்பில் தனித்தனி தொகுதிகளில் விவரிக்கப்பட வேண்டும்.
பயன்பாடுகள் செய்யப்படும் அடுக்கு முந்தைய இரண்டு அடுக்குகளின் மேல் அவை எவ்வாறு விரிவடையும் என்பதை விவரிக்கிறது.
சோதனை கேள்விகள்
உங்கள் நிறுவனத்திற்கு பொதுவான உள்கட்டமைப்பு களஞ்சியம் உள்ளதா? உங்கள் உள்கட்டமைப்பில் தொழில்நுட்பக் கடனை நிர்வகிக்கிறீர்களா? உள்கட்டமைப்புக் களஞ்சியத்தில் வளர்ச்சி நடைமுறைகளைப் பயன்படுத்துகிறீர்களா? உங்கள் உள்கட்டமைப்பு அடுக்குகளாக வெட்டப்பட்டுள்ளதா? அடிப்படை-சேவை-APP வரைபடத்தை நீங்கள் சரிபார்க்கலாம். மாற்றம் செய்வது எவ்வளவு கடினம்?
மாற்றங்களைச் செய்ய ஒன்றரை நாட்கள் ஆகும் என்பதை நீங்கள் உணர்ந்திருந்தால், உங்களுக்கு தொழில்நுட்பக் கடன் உள்ளது மற்றும் அதனுடன் வேலை செய்ய வேண்டும் என்று அர்த்தம். உங்கள் உள்கட்டமைப்புக் குறியீட்டில் தொழில்நுட்பக் கடன் சுமையால் நீங்கள் தடுமாறினீர்கள். சில CCTL ஐ மாற்ற, நீங்கள் உள்கட்டமைப்பு குறியீட்டின் பாதியை மீண்டும் எழுத வேண்டியிருக்கும் போது இதுபோன்ற பல கதைகளை நான் நினைவில் வைத்திருக்கிறேன், ஏனென்றால் படைப்பாற்றல் மற்றும் எல்லாவற்றையும் தானியங்குபடுத்துவதற்கான ஆசை எல்லாம் எல்லா இடங்களிலும் அரிக்கப்பட்டு, அனைத்து கைப்பிடிகளும் அகற்றப்பட்டன, மேலும் மறுசீரமைப்பு செய்வது அவசியம்.
தொடர்ச்சியான விநியோகம்
பற்று மற்றும் கடன் ஒப்பிடுவோம். முதலில் உள்கட்டமைப்பின் விளக்கம் வருகிறது, இது மிகவும் அடிப்படையானது. நீங்கள் எல்லாவற்றையும் விரிவாக விவரிக்க வேண்டியதில்லை, ஆனால் சில அடிப்படை விளக்கம் தேவை, எனவே நீங்கள் அதைக் கொண்டு வேலை செய்யலாம். இல்லையெனில், தொடர்ச்சியான டெலிவரிக்கு அடுத்து என்ன செய்வது என்பது தெளிவாகத் தெரியவில்லை. நீங்கள் DevOps க்கு வரும்போது இந்த நடைமுறைகள் அனைத்தும் ஒரே நேரத்தில் வெளிப்படும், ஆனால் உங்களிடம் என்ன இருக்கிறது மற்றும் அதை எவ்வாறு நிர்வகிப்பது என்பதைப் புரிந்துகொள்வதில் இது தொடங்குகிறது. இது துல்லியமாக உள்கட்டமைப்பை குறியீடாக நடைமுறைப்படுத்துகிறது.
உங்களிடம் அது உள்ளது மற்றும் அதை எவ்வாறு நிர்வகிப்பது என்பது தெளிவாகத் தெரிந்தவுடன், டெவலப்பர் குறியீட்டை எவ்வளவு விரைவாக உற்பத்திக்கு அனுப்புவது என்பதை நீங்கள் கண்டுபிடிக்கத் தொடங்குவீர்கள். நான் டெவலப்பருடன் சேர்ந்து சொல்கிறேன் - “கிணறுகள்” சிக்கலைப் பற்றி நாங்கள் நினைவில் கொள்கிறோம், அதாவது, இதைக் கொண்டு வருவது தனிப்பட்ட நபர்கள் அல்ல, ஆனால் ஒரு குழு.
நாம் உடன் இருக்கும் போது வான்யா எவ்டுகோவிச் முதல் புத்தகம் பார்த்தேன் ஜெஸ் ஹம்பிள் மற்றும் ஆசிரியர்கள் குழுக்கள் "தொடர்ச்சியான விநியோகம்", 2009 இல் வெளியிடப்பட்டது, அதன் தலைப்பை ரஷ்ய மொழியில் எவ்வாறு மொழிபெயர்ப்பது என்று நாங்கள் நீண்ட நேரம் யோசித்தோம். அவர்கள் அதை "தொடர்ந்து வழங்குதல்" என்று மொழிபெயர்க்க விரும்பினர், ஆனால், துரதிர்ஷ்டவசமாக, அது "தொடர்ச்சியான விநியோகம்" என்று மொழிபெயர்க்கப்பட்டது. எங்கள் பெயரில் ஏதோ ரஷ்ய மொழி இருப்பதாக எனக்குத் தோன்றுகிறது, அழுத்தத்துடன்.
தொடர்ந்து வழங்கும் பொருள்
தயாரிப்பு களஞ்சியத்தில் உள்ள குறியீட்டை எப்போதும் உற்பத்திக்கு பதிவிறக்கம் செய்யலாம். அவர் சோர்வடையாமல் இருக்கலாம், ஆனால் அவர் எப்போதும் அதற்கு தயாராக இருக்கிறார். அதன்படி, நீங்கள் எப்போதும் உங்கள் வால் எலும்பின் கீழ் சில கவலைகளை விளக்குவதற்கு கடினமான உணர்வோடு குறியீட்டை எழுதுவீர்கள். நீங்கள் உள்கட்டமைப்பு குறியீட்டை வெளியிடும்போது இது அடிக்கடி தோன்றும். சில கவலைகளின் இந்த உணர்வு இருக்க வேண்டும் - இது மூளை செயல்முறைகளைத் தூண்டுகிறது, இது குறியீட்டை சற்று வித்தியாசமாக எழுத அனுமதிக்கிறது. இது வளர்ச்சியில் உள்ள விதிகளில் பதிவு செய்யப்பட வேண்டும்.
தொடர்ந்து வழங்க, உள்கட்டமைப்பு தளம் முழுவதும் இயங்கும் ஒரு கலைப்பொருள் வடிவம் உங்களுக்குத் தேவை. ஒரு உள்கட்டமைப்பு தளத்தில் வெவ்வேறு வடிவங்களின் "வாழ்க்கை கழிவுகளை" நீங்கள் எறிந்தால், அது ஒருங்கிணைக்கப்படுகிறது, அதை பராமரிப்பது கடினம், மற்றும் தொழில்நுட்ப கடன் பிரச்சனை எழுகிறது. கலைப்பொருளின் வடிவம் சீரமைக்கப்பட வேண்டும் - இதுவும் ஒரு கூட்டுப் பணியாகும்: நாம் அனைவரும் ஒன்றிணைந்து, மூளையைத் துரத்த வேண்டும் மற்றும் இந்த வடிவமைப்பைக் கொண்டு வர வேண்டும்.
டெலிவரி பைப்லைன் வழியாக நகரும் போது, கலைப்பொருள் தொடர்ந்து மேம்படுத்தப்பட்டு, உற்பத்தி சூழலுக்கு ஏற்றவாறு மாறுகிறது. ஒரு கலைப்பொருள் பைப்லைனுடன் நகரும் போது, அதற்கு சிரமமான சில விஷயங்களை அது தொடர்ந்து எதிர்கொள்கிறது, அவை நீங்கள் தயாரிப்பில் வைக்கும் கலைப்பொருளை சந்திக்கும். கிளாசிக்கல் மேம்பாட்டில் இது ரோல்அவுட் செய்யும் ஒரு கணினி நிர்வாகியால் செய்யப்படுகிறது என்றால், DevOps செயல்பாட்டில் இது எல்லா நேரத்திலும் நடக்கும்: இங்கே அவர்கள் அதை சில சோதனைகள் மூலம் சோதித்தனர், இங்கே அவர்கள் அதை ஒரு குபெர்னெட்ஸ் கிளஸ்டரில் வீசினர், இது அதிகமாகவோ அல்லது குறைவாகவோ ஒத்திருக்கிறது. உற்பத்திக்கு, திடீரென்று அவர்கள் சுமை சோதனையைத் தொடங்கினர்.
இது பேக்-மேன் விளையாட்டை ஓரளவு நினைவூட்டுகிறது - கலைப்பொருள் ஒருவித கதை வழியாக செல்கிறது. அதே நேரத்தில், குறியீடு உண்மையில் கதை வழியாக செல்கிறதா மற்றும் அது எப்படியாவது உங்கள் தயாரிப்புடன் தொடர்புடையதா என்பதைக் கட்டுப்படுத்துவது முக்கியம். தயாரிப்பில் இருந்து வரும் கதைகளை தொடர்ச்சியான டெலிவரி செயல்முறைக்கு இழுக்கலாம்: ஏதாவது விழுந்தால் இப்படித்தான் இருந்தது, இப்போது இந்தக் காட்சியை கணினியில் நிரல் செய்வோம். ஒவ்வொரு முறையும் குறியீடு இந்த சூழ்நிலையிலும் செல்லும், அடுத்த முறை இந்த சிக்கலை நீங்கள் சந்திக்க மாட்டீர்கள். உங்கள் வாடிக்கையாளரை அடைவதற்கு முன்பே அதைப் பற்றி அறிந்து கொள்வீர்கள்.
வெவ்வேறு வரிசைப்படுத்தல் உத்திகள். எடுத்துக்காட்டாக, வெவ்வேறு கிளையண்டுகளில் குறியீட்டை வித்தியாசமாகச் சோதிக்க, குறியீடு எவ்வாறு செயல்படுகிறது என்பதைப் பற்றிய தகவலைப் பெற, மேலும் 100 மில்லியன் பயனர்களுக்கு இது வெளியிடப்பட்டதை விட மிகவும் முன்னதாகவே AB சோதனை அல்லது கேனரி வரிசைப்படுத்தல்களைப் பயன்படுத்துகிறீர்கள்.
"தொடர்ந்து வழங்குதல்" இது போல் தெரிகிறது.
டெலிவரி செயல்முறை Dev, CI, Test, PreProd, Prod ஒரு தனி சூழல் அல்ல, இவை உங்கள் கலைப்பொருள் கடந்து செல்லும் தீயில்லாத தொகைகளைக் கொண்ட நிலைகள் அல்லது நிலையங்கள்.
அடிப்படை சேவை APP என விவரிக்கப்படும் உள்கட்டமைப்பு குறியீடு உங்களிடம் இருந்தால், அது உதவுகிறது அனைத்து ஸ்கிரிப்ட்களையும் மறந்துவிடாதீர்கள், மற்றும் அவற்றை இந்தக் கலைப்பொருளுக்கான குறியீடாக எழுதவும், கலைப்பொருளை ஊக்குவிக்க நீங்கள் செல்லும்போது அதை மாற்றவும்.
சுய சோதனை கேள்விகள்
95% வழக்குகளில் அம்ச விளக்கத்திலிருந்து தயாரிப்பில் வெளியிடுவதற்கான நேரம் ஒரு வாரத்திற்கும் குறைவாக உள்ளதா? குழாயின் ஒவ்வொரு கட்டத்திலும் கலைப்பொருளின் தரம் மேம்படுகிறதா? அது கடந்து செல்லும் கதை இருக்கிறதா? நீங்கள் வெவ்வேறு வரிசைப்படுத்தல் உத்திகளைப் பயன்படுத்துகிறீர்களா?
எல்லா பதில்களும் ஆம் எனில், நீங்கள் நம்பமுடியாத அளவிற்கு குளிர்ச்சியாக இருக்கிறீர்கள்! கருத்துகளில் உங்கள் பதில்களை எழுதுங்கள் - நான் மகிழ்ச்சியடைவேன்).
கருத்து
இது எல்லாவற்றிலும் மிகவும் கடினமான நடைமுறையாகும். DevOpsConf மாநாட்டில், Infobip இன் ஒரு சக ஊழியர், அதைப் பற்றி பேசுகையில், அவரது வார்த்தைகளில் கொஞ்சம் குழப்பமடைந்தார், ஏனென்றால் நீங்கள் எல்லாவற்றையும் கண்காணிக்க வேண்டும் என்பதில் இது மிகவும் சிக்கலான நடைமுறை!
உதாரணமாக, நீண்ட காலத்திற்கு முன்பு, நான் Qik இல் பணிபுரிந்தபோது, எல்லாவற்றையும் கண்காணிக்க வேண்டும் என்பதை நாங்கள் உணர்ந்தோம். நாங்கள் இதைச் செய்தோம், இப்போது எங்களிடம் 150 உருப்படிகள் Zabbix இல் உள்ளன, அவை தொடர்ந்து கண்காணிக்கப்படுகின்றன. இது பயமாக இருந்தது, தொழில்நுட்ப இயக்குனர் தனது கோவிலில் விரலைத் திருப்பினார்:
- நண்பர்களே, நீங்கள் ஏன் சர்வரை ஏதோ தெளிவில்லாமல் கற்பழிக்கிறீர்கள்?
ஆனால் இது உண்மையில் மிகவும் அருமையான உத்தி என்பதை காட்டும் ஒரு சம்பவம் நடந்தது.
சேவைகளில் ஒன்று தொடர்ந்து செயலிழக்கத் தொடங்கியது. ஆரம்பத்தில், அது செயலிழக்கவில்லை, இது சுவாரஸ்யமானது, குறியீடு அங்கு சேர்க்கப்படவில்லை, ஏனெனில் இது ஒரு அடிப்படை தரகர், இது நடைமுறையில் எந்த வணிக செயல்பாடும் இல்லை - இது தனிப்பட்ட சேவைகளுக்கு இடையில் செய்திகளை அனுப்பியது. சேவை 4 மாதங்களுக்கு மாறவில்லை, திடீரென்று அது "பிரிவு தவறு" பிழையுடன் செயலிழக்கத் தொடங்கியது.
நாங்கள் அதிர்ச்சியடைந்தோம், Zabbix இல் எங்கள் விளக்கப்படங்களைத் திறந்தோம், மேலும் ஒன்றரை வாரங்களுக்கு முன்பு, இந்த தரகர் பயன்படுத்தும் API சேவையில் கோரிக்கைகளின் நடத்தை பெரிதும் மாறியது. அடுத்து ஒரு குறிப்பிட்ட வகை செய்திகளை அனுப்பும் அதிர்வெண் மாறியிருப்பதைப் பார்த்தோம். இவர்கள் ஆண்ட்ராய்டு க்ளையன்ட்கள் என்று பிறகு தெரிந்து கொண்டோம். நங்கள் கேட்டோம்:
- நண்பர்களே, ஒன்றரை வாரத்திற்கு முன்பு உங்களுக்கு என்ன நடந்தது?
பதிலுக்கு, அவர்கள் UI ஐ எவ்வாறு மறுவடிவமைப்பு செய்தார்கள் என்பது பற்றிய ஒரு சுவாரஸ்யமான கதையை நாங்கள் கேட்டோம். HTTP நூலகத்தை மாற்றியதாக யாரும் உடனடியாகச் சொல்ல வாய்ப்பில்லை. ஆண்ட்ராய்டு வாடிக்கையாளர்களுக்கு, இது குளியலறையில் சோப்பை மாற்றுவது போன்றது - அவர்களுக்கு நினைவில் இல்லை. இதன் விளைவாக, 40 நிமிட உரையாடலுக்குப் பிறகு, அவர்கள் HTTP நூலகத்தை மாற்றியதைக் கண்டறிந்தோம், மேலும் அதன் இயல்பு நேரங்கள் மாறிவிட்டன. இது ஏபிஐ சர்வரில் போக்குவரத்து நடத்தை மாறுவதற்கு வழிவகுத்தது, இது தரகருக்குள் பந்தயத்தை ஏற்படுத்தும் சூழ்நிலைக்கு வழிவகுத்தது, மேலும் அது செயலிழக்கத் தொடங்கியது.
ஆழ்ந்த கண்காணிப்பு இல்லாமல், இதைத் திறப்பது பொதுவாக சாத்தியமற்றது. நிறுவனத்தில் இன்னும் "கிணறுகள்" பிரச்சனை இருந்தால், எல்லோரும் ஒருவருக்கொருவர் பணத்தை வீசும்போது, இது பல ஆண்டுகளாக வாழலாம். சிக்கலைத் தீர்ப்பது சாத்தியமற்றது என்பதால் நீங்கள் சேவையகத்தை மறுதொடக்கம் செய்யுங்கள். உங்களிடம் உள்ள அனைத்து நிகழ்வுகளையும் கண்காணிக்கவும், கண்காணிக்கவும், கண்காணிக்கவும், கண்காணிப்பை சோதனையாகப் பயன்படுத்தவும் - குறியீட்டை எழுதவும், அதை எவ்வாறு கண்காணிப்பது என்பதை உடனடியாகக் குறிப்பிடவும், குறியீட்டு வடிவத்திலும் (எங்களிடம் ஏற்கனவே உள்கட்டமைப்பைக் குறியீடாக வைத்திருக்கிறோம்), எப்படி எல்லாம் தெளிவாகிறது. உள்ளங்கையில். இத்தகைய சிக்கலான பிரச்சனைகள் கூட எளிதில் கண்காணிக்கப்படும்.
டெலிவரி செயல்முறையின் ஒவ்வொரு கட்டத்திலும் கலைப்பொருளுக்கு என்ன நடக்கிறது என்பது பற்றிய அனைத்து தகவல்களையும் சேகரிக்கவும் - உற்பத்தியில் இல்லை.
கண்காணிப்பை CI இல் பதிவேற்றவும், சில அடிப்படை விஷயங்கள் ஏற்கனவே அங்கு தெரியும். பின்னர் நீங்கள் அவற்றை சோதனை, ப்ரெட்ப்ராட் மற்றும் சுமை சோதனையில் பார்ப்பீர்கள். எல்லா நிலைகளிலும் தகவல்களைச் சேகரிக்கவும், அளவீடுகள், புள்ளிவிவரங்கள் மட்டுமல்ல, பதிவுகள்: பயன்பாடு எவ்வாறு வெளிவந்தது, முரண்பாடுகள் - எல்லாவற்றையும் சேகரிக்கவும்.
இல்லையெனில், அதைக் கண்டுபிடிப்பது கடினம். DevOps மிகவும் சிக்கலானது என்று நான் ஏற்கனவே கூறியுள்ளேன். இந்த சிக்கலைச் சமாளிக்க, நீங்கள் சாதாரண பகுப்பாய்வுகளைக் கொண்டிருக்க வேண்டும்.
சுய கட்டுப்பாட்டிற்கான கேள்விகள்
உங்களின் கண்காணிப்பு மற்றும் பதிவு செய்வது உங்களுக்கான மேம்பாட்டுக் கருவியா? குறியீட்டை எழுதும் போது, நீங்கள் உட்பட உங்கள் டெவலப்பர்கள், அதை எவ்வாறு கண்காணிப்பது என்று சிந்திக்கிறார்களா?
வாடிக்கையாளர்களிடமிருந்து பிரச்சனைகளைப் பற்றி நீங்கள் கேட்கிறீர்களா? கண்காணிப்பு மற்றும் பதிவு செய்வதிலிருந்து வாடிக்கையாளரை நீங்கள் நன்றாகப் புரிந்துகொள்கிறீர்களா? கண்காணிப்பு மற்றும் பதிவு செய்வதிலிருந்து நீங்கள் கணினியை நன்கு புரிந்துகொள்கிறீர்களா? சிஸ்டத்தில் ட்ரெண்ட் வளர்ந்து வருவதைப் பார்த்து, இன்னும் 3 வாரங்களில் எல்லாம் செத்துப்போகும் என்று புரிந்து கொண்டதால் சிஸ்டத்தை மாற்றுகிறீர்களா?
இந்த மூன்று கூறுகளை நீங்கள் பெற்றவுடன், உங்கள் நிறுவனத்தில் எந்த வகையான உள்கட்டமைப்பு தளம் உள்ளது என்பதை நீங்கள் சிந்திக்கலாம்.
உள்கட்டமைப்பு தளம்
ஒவ்வொரு நிறுவனமும் வைத்திருக்கும் வேறுபட்ட கருவிகளின் தொகுப்பு என்பது முக்கியமல்ல.
ஒரு உள்கட்டமைப்பு தளத்தின் முக்கிய அம்சம் என்னவென்றால், அனைத்து குழுக்களும் இந்த கருவிகளைப் பயன்படுத்துகின்றன மற்றும் அவற்றை ஒன்றாக உருவாக்குகின்றன.
உள்கட்டமைப்பு தளத்தின் தனிப்பட்ட பகுதிகளின் வளர்ச்சிக்கு பொறுப்பான தனி குழுக்கள் உள்ளன என்பது தெளிவாகிறது. ஆனால் அதே நேரத்தில், ஒவ்வொரு பொறியாளரும் உள்கட்டமைப்பு தளத்தின் மேம்பாடு, செயல்திறன் மற்றும் ஊக்குவிப்புக்கான பொறுப்பை ஏற்கிறார்கள். உள் மட்டத்தில் இது ஒரு பொதுவான கருவியாக மாறும்.
அனைத்து அணிகளும் உள்கட்டமைப்பு தளத்தை உருவாக்கி, அதை தங்கள் சொந்த IDE ஆகக் கவனமாகக் கருதுகின்றன. உங்கள் IDE இல் நீங்கள் வெவ்வேறு செருகுநிரல்களை நிறுவி எல்லாவற்றையும் நன்றாகவும் வேகமாகவும் செய்து, ஹாட்ஸ்கிகளை உள்ளமைக்கிறீர்கள். நீங்கள் சப்லைம், ஆட்டம் அல்லது விஷுவல் ஸ்டுடியோ குறியீட்டைத் திறக்கும்போது, குறியீட்டுப் பிழைகள் கொட்டுகின்றன, மேலும் வேலை செய்வது சாத்தியமில்லை என்பதை நீங்கள் உணர்ந்தால், நீங்கள் உடனடியாக சோகமாக உணர்கிறீர்கள், மேலும் உங்கள் IDE ஐ சரிசெய்ய ஓடுகிறீர்கள்.
உங்கள் உள்கட்டமைப்பு தளத்தை அதே வழியில் நடத்துங்கள். அதில் ஏதோ தவறு இருப்பதாக நீங்கள் புரிந்து கொண்டால், அதை நீங்களே சரிசெய்ய முடியாவிட்டால் கோரிக்கை விடுங்கள். சிம்பிளான ஏதாச்சும் இருந்தால் நீங்களே எடிட் பண்ணுங்க, புல் ரிக்வெஸ்ட் அனுப்புங்க, தோழர்களே பரிசீலித்து சேர்ப்பார்கள். டெவலப்பரின் தலையில் உள்ள பொறியியல் கருவிகளுக்கு இது சற்று வித்தியாசமான அணுகுமுறையாகும்.
உள்கட்டமைப்பு தளமானது, தரத்தில் தொடர்ச்சியான முன்னேற்றத்துடன் கலைப்பொருளை வளர்ச்சியிலிருந்து வாடிக்கையாளருக்கு மாற்றுவதை உறுதி செய்கிறது.. தயாரிப்பில் உள்ள குறியீட்டில் நடக்கும் கதைகளின் தொகுப்புடன் IP திட்டமிடப்பட்டுள்ளது. வளர்ச்சியின் பல ஆண்டுகளில், இந்தக் கதைகள் நிறைய உள்ளன, அவற்றில் சில தனித்துவமானவை மற்றும் உங்களுடன் மட்டுமே தொடர்புடையவை - அவற்றை கூகிள் செய்ய முடியாது.
இந்த கட்டத்தில், உள்கட்டமைப்பு தளம் உங்கள் போட்டி நன்மையாக மாறும், ஏனெனில் அதில் போட்டியாளரின் கருவியில் இல்லாத ஏதோ ஒன்று கட்டமைக்கப்பட்டுள்ளது. உங்கள் ஐபி எவ்வளவு ஆழமாக இருக்கிறதோ, அந்த அளவுக்குச் சந்தைக்கு நேரத்தின் அடிப்படையில் உங்கள் போட்டித்தன்மை அதிகமாகும். இங்கே தோன்றும் விற்பனையாளர் பூட்டு பிரச்சனை: நீங்கள் வேறொருவரின் தளத்தை எடுத்துக் கொள்ளலாம், ஆனால் வேறொருவரின் அனுபவத்தைப் பயன்படுத்தி, அது உங்களுக்கு எவ்வளவு பொருத்தமானது என்பதை நீங்கள் புரிந்து கொள்ள மாட்டீர்கள். ஆம், ஒவ்வொரு நிறுவனமும் Amazon போன்ற தளத்தை உருவாக்க முடியாது. இது கடினமான வரியாகும், இதில் நிறுவனத்தின் அனுபவம் சந்தையில் அதன் நிலைக்கு பொருத்தமானது, மேலும் நீங்கள் அங்கு விற்பனையாளர் பூட்டைப் பயன்படுத்த முடியாது. இதுவும் சிந்திக்க வேண்டியது அவசியம்.
திட்டம்
இது DevOps நிறுவனத்தில் அனைத்து நடைமுறைகளையும் செயல்முறைகளையும் அமைக்க உதவும் உள்கட்டமைப்பு தளத்தின் அடிப்படை வரைபடமாகும்.
இதில் என்ன இருக்கிறது என்று பார்ப்போம்.
வள ஆர்கெஸ்ட்ரேஷன் அமைப்பு, இது CPU, நினைவகம், பயன்பாடுகள் மற்றும் பிற சேவைகளுக்கு வட்டு வழங்குகிறது. இதற்க்கு மேல் - குறைந்த அளவிலான சேவைகள்: கண்காணிப்பு, பதிவு செய்தல், CI/CD இயந்திரம், கலைப்பொருள் சேமிப்பு, உள்கட்டமைப்பு அமைப்புக் குறியீடாக.
உயர் மட்ட சேவைகள்: ஒரு சேவையாக தரவுத்தளம், சேவையாக வரிசைகள், ஒரு சேவையாக ஏற்ற சமநிலை, ஒரு சேவையாக படத்தை மறுஅளவிடுதல், ஒரு சேவையாக பெரிய தரவு தொழிற்சாலை. இதற்க்கு மேல் - உங்கள் வாடிக்கையாளருக்கு தொடர்ந்து மாற்றியமைக்கப்பட்ட குறியீட்டை வழங்கும் பைப்லைன்.
வாடிக்கையாளருக்கு உங்கள் மென்பொருள் எவ்வாறு செயல்படுகிறது என்பதைப் பற்றிய தகவலைப் பெறுவீர்கள், அதை மாற்றவும், இந்தக் குறியீட்டை மீண்டும் வழங்கவும், தகவலைப் பெறவும் - மேலும் உள்கட்டமைப்பு தளம் மற்றும் உங்கள் மென்பொருள் இரண்டையும் தொடர்ந்து உருவாக்குகிறீர்கள்.
வரைபடத்தில், விநியோக குழாய் பல நிலைகளைக் கொண்டுள்ளது. ஆனால் இது ஒரு திட்டவட்டமான வரைபடமாகும், இது ஒரு உதாரணமாக கொடுக்கப்பட்டுள்ளது - அதை ஒவ்வொன்றாக மீண்டும் செய்ய வேண்டிய அவசியமில்லை. நிலைகள் சேவைகளைப் போலவே சேவைகளுடன் தொடர்பு கொள்கின்றன - தளத்தின் ஒவ்வொரு செங்கல்லும் அதன் சொந்த கதையைக் கொண்டுள்ளது: வளங்கள் எவ்வாறு ஒதுக்கப்படுகின்றன, பயன்பாடு எவ்வாறு தொடங்கப்படுகிறது, வளங்களுடன் செயல்படுகிறது, கண்காணிக்கப்படுகிறது மற்றும் மாற்றங்கள்.
மேடையின் ஒவ்வொரு பகுதியும் ஒரு கதையைக் கொண்டுள்ளது என்பதைப் புரிந்துகொள்வது முக்கியம், மேலும் இந்த செங்கல் என்ன கதையை எடுத்துச் செல்கிறது என்பதை நீங்களே கேட்டுக்கொள்ளுங்கள், ஒருவேளை அதை தூக்கி எறிந்துவிட்டு மூன்றாம் தரப்பு சேவையுடன் மாற்றப்பட வேண்டும். உதாரணமாக, ஒரு செங்கலுக்கு பதிலாக Okmeter ஐ நிறுவ முடியுமா? ஒருவேளை தோழர்களே ஏற்கனவே இந்த நிபுணத்துவத்தை நம்மை விட அதிகமாக வளர்த்திருக்கலாம். ஆனால் ஒருவேளை இல்லை - ஒருவேளை எங்களிடம் தனித்துவமான நிபுணத்துவம் இருக்கலாம், நாங்கள் ப்ரோமிதியஸை நிறுவி அதை மேலும் மேம்படுத்த வேண்டும்.
மேடையின் உருவாக்கம்
இது ஒரு சிக்கலான தொடர்பு செயல்முறை. உங்களிடம் அடிப்படை நடைமுறைகள் இருக்கும்போது, தேவைகள் மற்றும் தரநிலைகளை உருவாக்கும் பல்வேறு பொறியாளர்கள் மற்றும் நிபுணர்களுக்கு இடையேயான தொடர்பைத் தொடங்குவீர்கள், மேலும் அவற்றை வெவ்வேறு கருவிகள் மற்றும் அணுகுமுறைகளுக்கு தொடர்ந்து மாற்றுவீர்கள். DevOps இல் இருக்கும் கலாச்சாரம் இங்கே முக்கியமானது.
கலாச்சாரத்துடன் எல்லாம் மிகவும் எளிது - இது ஒத்துழைப்பு மற்றும் தொடர்பு பற்றியது, அதாவது, ஒருவருக்கொருவர் பொதுவான துறையில் வேலை செய்ய ஆசை, ஒரு கருவியை ஒன்றாகப் பயன்படுத்துவதற்கான விருப்பம். இங்கே ராக்கெட் அறிவியல் இல்லை - எல்லாம் மிகவும் எளிமையானது, சாதாரணமானது. உதாரணமாக, நாம் அனைவரும் நுழைவாயிலில் வசிக்கிறோம், அதை சுத்தமாக வைத்திருக்கிறோம் - அத்தகைய கலாச்சாரம்.
உன்னிடம் என்ன இருக்கிறது?
மீண்டும், கேள்விகளை நீங்களே கேட்டுக்கொள்ளலாம்.
உள்கட்டமைப்பு தளம் அர்ப்பணிக்கப்பட்டதா? அதன் வளர்ச்சிக்கு யார் பொறுப்பு? உங்கள் உள்கட்டமைப்பு தளத்தின் போட்டி நன்மைகளை நீங்கள் புரிந்துகொள்கிறீர்களா?
இந்தக் கேள்விகளை நீங்களே தொடர்ந்து கேட்டுக்கொள்ள வேண்டும். மூன்றாம் தரப்பு சேவைகளுக்கு ஏதாவது மாற்றப்பட்டால், அது மாற்றப்பட வேண்டும்; மூன்றாம் தரப்பு சேவை உங்கள் இயக்கத்தைத் தடுக்கத் தொடங்கினால், உங்களுக்குள் ஒரு அமைப்பை உருவாக்க வேண்டும்.
எனவே, DevOps...
... இது ஒரு சிக்கலான அமைப்பு, இதில் இருக்க வேண்டும்:
- டிஜிட்டல் தயாரிப்பு.
- இந்த டிஜிட்டல் தயாரிப்பை உருவாக்கும் வணிக தொகுதிகள்.
- குறியீட்டை எழுதும் தயாரிப்பு குழுக்கள்.
- தொடர்ச்சியான டெலிவரி நடைமுறைகள்.
- ஒரு சேவையாக தளங்கள்.
- ஒரு சேவையாக உள்கட்டமைப்பு.
- குறியீடாக உள்கட்டமைப்பு.
- DevOps இல் உள்ளமைக்கப்பட்ட நம்பகத்தன்மையை பராமரிப்பதற்கான தனி நடைமுறைகள்.
- அனைத்தையும் விவரிக்கும் ஒரு பின்னூட்ட நடைமுறை.
இந்த வரைபடத்தைப் பயன்படுத்தலாம், உங்கள் நிறுவனத்தில் ஏற்கனவே ஏதேனும் ஒரு வடிவத்தில் நீங்கள் வைத்திருப்பதை அதில் முன்னிலைப்படுத்தலாம்: இது உருவாக்கப்பட்டுள்ளதா அல்லது இன்னும் உருவாக்கப்பட வேண்டும்.
ஓரிரு வாரங்களில் முடிந்து விடும் . RIT++ இன் ஒரு பகுதியாக. மாநாட்டிற்கு வாருங்கள், அங்கு தொடர்ச்சியான டெலிவரி, உள்கட்டமைப்பு குறியீட்டு மற்றும் DevOps மாற்றம் பற்றிய பல அருமையான அறிக்கைகளை நீங்கள் காணலாம். , கடைசி விலை காலக்கெடு மே 20 ஆகும்
ஆதாரம்: www.habr.com