DevOps பற்றி பேசும்போது முக்கிய விஷயத்தைப் புரிந்துகொள்வது கடினமா? நாங்கள் உங்களுக்காக தெளிவான ஒப்புமைகள், அற்புதமான சூத்திரங்கள் மற்றும் நிபுணர்களிடமிருந்து ஆலோசனைகளை சேகரித்துள்ளோம், இது நிபுணர்கள் அல்லாதவர்கள் கூட புள்ளியைப் பெற உதவும். இறுதியில், போனஸ் Red Hat ஊழியர்களின் சொந்த DevOps ஆகும்.
டெவொப்ஸ் என்ற சொல் 10 ஆண்டுகளுக்கு முன்பு உருவானது மற்றும் ட்விட்டர் ஹேஷ்டேக்கில் இருந்து ஐடி உலகில் சக்திவாய்ந்த கலாச்சார இயக்கமாக மாறியுள்ளது, இது டெவலப்பர்களை விரைவாகச் செய்யவும், பரிசோதனை செய்யவும் மற்றும் முன்னோக்கிச் செல்லவும் ஊக்குவிக்கும் உண்மையான தத்துவமாகும். DevOps டிஜிட்டல் மாற்றம் என்ற கருத்துடன் பிரிக்கமுடியாத வகையில் இணைக்கப்பட்டுள்ளது. ஆனால் IT சொற்களில் அடிக்கடி நடப்பது போல, கடந்த பத்து ஆண்டுகளில் DevOps தன்னைப் பற்றிய பல வரையறைகள், விளக்கங்கள் மற்றும் தவறான எண்ணங்களைப் பெற்றுள்ளது.
எனவே, DevOps பற்றிய கேள்விகளை நீங்கள் அடிக்கடி கேட்கலாம், இது சுறுசுறுப்பானது போன்றதா? அல்லது இது ஏதாவது சிறப்பு வழிமுறையா? அல்லது "ஒத்துழைப்பு" என்ற வார்த்தையின் மற்றொரு ஒத்த சொல்லா?
DevOps பல்வேறு கருத்துகளை உள்ளடக்கியது (தொடர்ச்சியான விநியோகம், தொடர்ச்சியான ஒருங்கிணைப்பு, ஆட்டோமேஷன், முதலியன), எனவே முக்கியமானவற்றை வடிகட்டுவது சவாலானதாக இருக்கும், குறிப்பாக இந்த விஷயத்தில் நீங்கள் ஆர்வமாக இருக்கும்போது. இருப்பினும், இந்த திறன் மிகவும் பயனுள்ளதாக இருக்கும், நீங்கள் உங்கள் யோசனைகளை உங்கள் மேலதிகாரிகளுக்கு தெரிவிக்க முயற்சித்தாலும் அல்லது உங்கள் வேலையைப் பற்றி உங்கள் குடும்பத்தினர் அல்லது நண்பர்களிடம் கூறினாலும். எனவே, டெவொப்ஸின் சொற்பொழிவு நுணுக்கங்களை இப்போதைக்கு ஒதுக்கி வைத்துவிட்டு, பெரிய படத்தில் கவனம் செலுத்துவோம்.
DevOps என்றால் என்ன: 6 வரையறைகள் மற்றும் ஒப்புமைகள்
DevOps இன் சாராம்சத்தை முடிந்தவரை எளிமையாகவும் சுருக்கமாகவும் விளக்குமாறு நிபுணர்களிடம் கேட்டோம், இதனால் எந்த அளவிலான தொழில்நுட்ப அறிவும் உள்ள வாசகர்களுக்கு அதன் மதிப்பு தெளிவாகிறது. இந்த உரையாடல்களின் முடிவுகளின் அடிப்படையில், DevOps பற்றிய உங்கள் கதையை உருவாக்க உதவும் மிகவும் குறிப்பிடத்தக்க ஒப்புமைகள் மற்றும் குறிப்பிடத்தக்க சூத்திரங்களை நாங்கள் தேர்ந்தெடுத்துள்ளோம்.
1. DevOps ஒரு கலாச்சார இயக்கம்
"DevOps என்பது ஒரு கலாச்சார இயக்கமாகும், இதில் இரு தரப்பினரும் (மென்பொருள் உருவாக்குநர்கள் மற்றும் ஐடி சிஸ்டம் இயக்க வல்லுநர்கள்) மென்பொருளைப் பயன்படுத்தத் தொடங்கும் வரை உண்மையான பலன்களைத் தருவதில்லை: வாடிக்கையாளர்கள், வாடிக்கையாளர்கள், ஊழியர்கள், முக்கியமல்ல" என்கிறார் மூத்த ஆராய்ச்சியாளரான ஈவ்லைன் ஓர்லிச். DevOps இன்ஸ்டிட்யூட்டில் ஆய்வாளர். "எனவே, இந்த இரு கட்சிகளும் கூட்டாக மென்பொருளின் விரைவான மற்றும் உயர்தர விநியோகத்தை உறுதி செய்கின்றன."
2. DevOps என்பது டெவலப்பர்களை மேம்படுத்துவதாகும்.
"DevOps டெவலப்பர்களுக்கு பயன்பாடுகளை சொந்தமாக வைத்திருக்கவும், அவற்றை இயக்கவும், தொடக்கத்தில் இருந்து இறுதி வரை விநியோகத்தை நிர்வகிக்கவும் அதிகாரம் அளிக்கிறது."
"பொதுவாக, DevOps தானியங்கு செயல்முறைகளை உருவாக்கி செயல்படுத்துவதன் மூலம் உற்பத்திக்கான பயன்பாடுகளை விரைவுபடுத்துவதற்கான ஒரு வழியாகப் பேசப்படுகிறது," என்கிறார் காப்பீட்டு நிறுவனமான Liberty Mutual இல் DevOps இயங்குதளங்களின் இயக்குனர் ஜெய் ஷ்னிப். "ஆனால் என்னைப் பொறுத்தவரை இது மிகவும் அடிப்படையான விஷயம்." DevOps டெவலப்பர்களுக்கு பயன்பாடுகள் அல்லது குறிப்பிட்ட மென்பொருட்களை சொந்தமாக வைத்திருக்கவும், அவற்றை இயக்கவும், தொடக்கம் முதல் இறுதி வரை டெலிவரியை நிர்வகிக்கவும் அதிகாரம் அளிக்கிறது. DevOps பொறுப்புக் குழப்பத்தை நீக்குகிறது மற்றும் தானியங்கு, டெவலப்பர்-உந்துதல் உள்கட்டமைப்பை உருவாக்குவதில் ஈடுபட்டுள்ள அனைவருக்கும் வழிகாட்டுகிறது.
3. DevOps என்பது பயன்பாடுகளை உருவாக்கி வழங்குவதில் ஒத்துழைப்பைப் பற்றியது.
"எளிமையாகச் சொன்னால், DevOps என்பது மென்பொருள் தயாரிப்பு மற்றும் விநியோகத்திற்கான அணுகுமுறையாகும், அங்கு அனைவரும் ஒன்றாக வேலை செய்கிறார்கள்" என்று BMC இன் டிஜிட்டல் வணிக ஆட்டோமேஷனின் தலைவரும் தலைவருமான குர் ஸ்டாஃப் கூறுகிறார்.
4. DevOps ஒரு குழாய்
"எல்லா பாகங்களும் ஒன்றாக பொருந்தினால் மட்டுமே கன்வேயர் அசெம்பிளி சாத்தியம்."
"நான் டெவொப்ஸை கார் அசெம்பிளி லைனுடன் ஒப்பிடுவேன்" என்று குர் ஸ்டாஃப் தொடர்கிறார். - அனைத்து பகுதிகளையும் முன்கூட்டியே வடிவமைத்து உருவாக்க வேண்டும், பின்னர் அவை தனிப்பட்ட சரிசெய்தல் இல்லாமல் கூடியிருக்கும். அனைத்து பகுதிகளும் ஒன்றாக பொருந்தினால் மட்டுமே கன்வேயர் சட்டசபை சாத்தியமாகும். ஒரு இயந்திரத்தை வடிவமைத்து உருவாக்குபவர்கள் அதை உடலிலோ அல்லது சட்டகத்திலோ எவ்வாறு ஏற்றுவது என்பதைக் கருத்தில் கொள்ள வேண்டும். பிரேக் போடுபவர்கள் சக்கரங்கள் மற்றும் பலவற்றைப் பற்றி சிந்திக்க வேண்டும். மென்பொருளிலும் இதுவே உண்மையாக இருக்க வேண்டும்.
வணிக தர்க்கம் அல்லது பயனர் இடைமுகத்தை உருவாக்கும் டெவலப்பர், வாடிக்கையாளர் தகவலைச் சேமிக்கும் தரவுத்தளத்தைப் பற்றி சிந்திக்க வேண்டும், பயனர் தரவைப் பாதுகாப்பதற்கான பாதுகாப்பு நடவடிக்கைகள் மற்றும் இந்தச் சேவையானது ஒரு பெரிய, ஒருவேளை பல மில்லியன் டாலர் பயனர் பார்வையாளர்களுக்கு சேவை செய்யத் தொடங்கும் போது இவை அனைத்தும் எவ்வாறு செயல்படும். ."
"தங்கள் சொந்தப் பணிகளில் மட்டும் கவனம் செலுத்தாமல், மற்றவர்கள் செய்யும் வேலையின் பகுதிகளைப் பற்றி மக்கள் ஒத்துழைத்து சிந்திக்க வைப்பது, கடப்பதற்கான மிகப்பெரிய தடையாகும். நீங்கள் இதைச் செய்ய முடிந்தால், டிஜிட்டல் மாற்றத்திற்கான சிறந்த வாய்ப்பு உங்களுக்கு உள்ளது, ”என்று குர் ஊழியர்கள் கூறுகிறார்கள்.
5. DevOps என்பது மக்கள், செயல்முறைகள் மற்றும் ஆட்டோமேஷன் ஆகியவற்றின் சரியான கலவையாகும்
DevOps இன்ஸ்டிட்யூட்டின் நிர்வாக இயக்குனர் ஜெய்ன் க்ரோல், DevOps ஐ விளக்க ஒரு சிறந்த ஒப்புமையை வழங்கினார். அவரது வார்த்தைகளில், "DevOps என்பது மூன்று முக்கிய வகை பொருட்களைக் கொண்ட ஒரு செய்முறையைப் போன்றது: மக்கள், செயல்முறை மற்றும் ஆட்டோமேஷன். இந்த பொருட்களில் பெரும்பாலானவை பிற பகுதிகள் மற்றும் மூலங்களிலிருந்து எடுக்கப்படலாம்: லீன், அஜில், எஸ்ஆர்இ, சிஐ/சிடி, ஐடிஐஎல், தலைமைத்துவம், கலாச்சாரம், கருவிகள். DevOps இன் ரகசியம், எந்த ஒரு நல்ல செய்முறையைப் போலவே, பயன்பாடுகளை உருவாக்கி வெளியிடுவதற்கான வேகத்தையும் செயல்திறனையும் அதிகரிக்க இந்த பொருட்களின் சரியான விகிதங்கள் மற்றும் கலவையை எவ்வாறு பெறுவது என்பதுதான்.
6. டெவொப்ஸ் என்பது புரோகிராமர்கள் ஃபார்முலா 1 குழுவைப் போல வேலை செய்வதாகும்
"பந்தயம் தொடக்கத்தில் இருந்து முடிக்க திட்டமிடப்படவில்லை, மாறாக, முடிவிலிருந்து ஆரம்பம் வரை."
"DevOps முன்முயற்சியில் இருந்து என்ன எதிர்பார்க்கலாம் என்பதைப் பற்றி நான் பேசும்போது, NASCAR அல்லது Formula 1 பந்தயக் குழுவை ஒரு உதாரணமாகக் கருதுகிறேன்" என்று Red Hat இல் கிளவுட் பிளாட்ஃபார்ம் மார்க்கெட்டிங் மூத்த மேலாளரும் DevOps'ish செய்திமடலின் வெளியீட்டாளருமான கிறிஸ் ஷார்ட் கூறுகிறார். - அத்தகைய குழுவின் தலைவருக்கு ஒரு குறிக்கோள் உள்ளது: பந்தயத்தின் முடிவில் சாத்தியமான மிக உயர்ந்த இடத்தைப் பிடிப்பது, அணிக்கு கிடைக்கும் வளங்கள் மற்றும் அது எதிர்கொள்ளும் சவால்களை கணக்கில் எடுத்துக்கொள்வது. இந்த வழக்கில், பந்தயம் தொடக்கத்தில் இருந்து முடிக்க திட்டமிடப்பட்டுள்ளது, மாறாக, முடிவில் இருந்து தொடங்கும். முதலில், ஒரு லட்சிய இலக்கு அமைக்கப்படுகிறது, பின்னர் அதை அடைவதற்கான வழிகள் தீர்மானிக்கப்படுகின்றன. பின்னர் அவை துணைப் பணிகளாகப் பிரிக்கப்பட்டு குழு உறுப்பினர்களுக்கு வழங்கப்படுகின்றன.
"குழி நிறுத்தத்தை முழுமையாக்குவதற்கு பந்தயத்திற்கு முன் முழு வாரத்தையும் குழு செலவிடுகிறது. கடினமான பந்தய நாளுக்காக அவர் உடல் நிலையில் இருக்க வலிமை பயிற்சி மற்றும் கார்டியோ செய்கிறார். பந்தயத்தின் போது எழக்கூடிய எந்தவொரு பிரச்சனையையும் தீர்க்க ஒன்றாக வேலை செய்யும் நடைமுறைகள். அதேபோல, புதிய பதிப்புகளை அடிக்கடி வெளியிடும் திறமையை மேம்பாட்டுக் குழு பயிற்றுவிக்க வேண்டும். உங்களிடம் அத்தகைய திறன்கள் மற்றும் நன்கு செயல்படும் பாதுகாப்பு அமைப்பு இருந்தால், உற்பத்தியில் புதிய பதிப்புகளை அறிமுகப்படுத்துவதும் அடிக்கடி நிகழ்கிறது. இந்த உலகக் கண்ணோட்டத்தில், அதிகரித்த வேகம் என்பது அதிகரித்த பாதுகாப்பைக் குறிக்கிறது,” என்கிறார் ஷார்ட்.
"இது 'சரியான காரியத்தை' செய்வதைப் பற்றியது அல்ல," ஷார்ட் மேலும் கூறுகிறார், "இது விரும்பிய முடிவின் வழியில் நிற்கும் பல விஷயங்களை முடிந்தவரை நீக்குவது பற்றியது. நிகழ்நேரத்தில் நீங்கள் பெறும் பின்னூட்டத்தின் அடிப்படையில் ஒத்துழைத்து மாற்றியமைக்கவும். முரண்பாடுகளுக்கு தயாராக இருங்கள் மற்றும் உங்கள் இலக்கை நோக்கிய முன்னேற்றத்தில் அவற்றின் தாக்கத்தை குறைக்க தரத்தை மேம்படுத்த வேலை செய்யுங்கள். DevOps உலகில் இதுதான் எங்களுக்குக் காத்திருக்கிறது.
DevOps ஐ அளவிடுவது எப்படி: நிபுணர்களிடமிருந்து 10 உதவிக்குறிப்புகள்
DevOps மற்றும் வெகுஜன DevOps முற்றிலும் வேறுபட்ட விஷயங்கள். முதல் இரண்டாவது பாதையில் உள்ள தடைகளை எவ்வாறு சமாளிப்பது என்பதை நாங்கள் உங்களுக்குச் சொல்வோம்.
பல நிறுவனங்களுக்கு, DevOpsக்கான பயணம் எளிதாகவும் இனிமையாகவும் தொடங்குகிறது. சிறிய உணர்ச்சிமிக்க அணிகள் உருவாக்கப்படுகின்றன, பழைய செயல்முறைகள் புதியவற்றால் மாற்றப்படுகின்றன, மேலும் முதல் வெற்றிகள் வருவதற்கு நீண்ட காலம் இல்லை.
ஐயோ, இது ஒரு தவறான காட்சி, முன்னேற்றத்தின் மாயை என்று நார்த் ஹைலேண்டின் கன்சல்டன்சியின் டிஜிட்டல் நிர்வாக இயக்குநரும் தலைவருமான பென் கிரின்னல் கூறுகிறார். ஆரம்பகால வெற்றிகள் நிச்சயமாக ஊக்கமளிக்கும், ஆனால் அவை நிறுவனம் முழுவதும் DevOps இன் பரவலான தத்தெடுப்பின் இறுதி இலக்கை அடைய உதவாது.
இதன் விளைவாக "நாம்" மற்றும் "அவர்கள்" என்ற பிரிவினை கலாச்சாரம் என்பதை எளிதாகக் காணலாம்.
"பெரும்பாலும், நிறுவனங்கள் இந்த முன்னோடி திட்டங்களைத் தொடங்குகின்றன, அவை முக்கிய டெவொப்களுக்கு வழி வகுக்கும் என்று நினைத்து, மற்றவர்கள் அந்த வழியைப் பின்பற்ற முடியுமா அல்லது விரும்புவார்களா என்பதைக் கருத்தில் கொள்ளாமல்," பென் கிரின்னல் விளக்குகிறார். - இதுபோன்ற திட்டங்களைச் செயல்படுத்துவதற்கான குழுக்கள் பொதுவாக தன்னம்பிக்கையான "வரங்கியர்களிடமிருந்து" ஆட்சேர்ப்பு செய்யப்படுகின்றன, அவர்கள் ஏற்கனவே மற்ற இடங்களில் இதேபோன்ற ஒன்றைச் செய்திருக்கிறார்கள், ஆனால் உங்கள் நிறுவனத்திற்கு புதியவர்கள். அதே சமயம், மற்ற அனைவருக்கும் கட்டுப்பட்டிருக்கும் விதிகளை உடைக்கவும் அழிக்கவும் அவர்கள் ஊக்குவிக்கப்படுகிறார்கள். இதன் விளைவாக அறிவு மற்றும் திறன் பரிமாற்றத்தைத் தடுக்கும் "நாங்கள்" மற்றும் "அவர்கள்" கலாச்சாரம் என்பதை எளிதாகக் காணலாம்.
"மேலும் இந்த கலாச்சார பிரச்சனை DevOps அளவிட கடினமாக இருப்பதற்கான காரணங்களில் ஒன்றாகும். DevOps குழுக்கள் அதிக தொழில்நுட்ப சவால்களை எதிர்கொள்கின்றன, அவை வேகமாக வளர்ந்து வரும் IT-முதல் நிறுவனங்களுக்கு பொதுவானவை, ”என்று ஸ்காலிரின் நிறுவனர் மற்றும் தலைவர் ஸ்டீவ் நியூமன் கூறினார்.
“நவீன உலகில், தேவை ஏற்பட்டவுடன் சேவைகள் மாறுகின்றன. புதிய அம்சங்களை தொடர்ந்து செயல்படுத்துவதும் செயல்படுத்துவதும் மிகவும் நல்லது, ஆனால் இந்த செயல்முறையை ஒருங்கிணைத்து எழும் சிக்கல்களை நீக்குவது உண்மையான தலைவலி, ஸ்டீவ் நியூமன் கூறுகிறார். - மிக வேகமாக வளர்ந்து வரும் நிறுவனங்களில், குறுக்கு-செயல்பாட்டு குழுக்களில் உள்ள பொறியாளர்கள் மாற்றம் மற்றும் அது உருவாக்கும் சார்பு நிலை அடுக்கு விளைவுகளைப் பராமரிக்க போராடுகிறார்கள். மேலும், பொறியாளர்கள் இந்த வாய்ப்பை இழக்கும்போது மகிழ்ச்சியடைய மாட்டார்கள், இதன் விளைவாக, எழும் பிரச்சினைகளின் சாரத்தை புரிந்துகொள்வது அவர்களுக்கு கடினமாகிறது.
மேலே விவரிக்கப்பட்ட இந்த சவால்களை எப்படி சமாளிப்பது மற்றும் ஒரு பெரிய நிறுவனத்தில் DevOps ஐ பெருமளவில் ஏற்றுக்கொள்வது எப்படி? உங்கள் மென்பொருள் மேம்பாட்டு சுழற்சி மற்றும் வணிக செயல்முறைகளை விரைவுபடுத்துவதே உங்கள் இறுதி இலக்காக இருந்தாலும், வல்லுநர்கள் பொறுமையாக இருக்க வேண்டும் என்று வலியுறுத்துகின்றனர்.
1. கலாச்சார மாற்றம் நேரம் எடுக்கும் என்பதை நினைவில் கொள்ளுங்கள்.
ஜெய்ன் க்ரோல், டெவொப்ஸ் இன்ஸ்டிடியூட் நிர்வாக இயக்குனர்: "என் கருத்துப்படி, DevOps இன் விரிவாக்கம், சுறுசுறுப்பான வளர்ச்சியைப் போலவே (மற்றும் கலாச்சாரத்தையும் சமமாகத் தொடும்) அதிகரிக்கும் மற்றும் மீண்டும் செயல்பட வேண்டும். சுறுசுறுப்பான மற்றும் DevOps சிறிய அணிகளை வலியுறுத்துகின்றன. ஆனால் இந்த அணிகள் எண்ணிக்கையிலும் ஒருங்கிணைப்பிலும் வளரும்போது, அதிகமான மக்கள் புதிய வேலை முறைகளைப் பின்பற்றுவதில் நாங்கள் முடிவடைகிறோம், இதன் விளைவாக ஒரு பெரிய கலாச்சார மாற்றம் உள்ளது.
2. போதுமான நேரத்தை திட்டமிடுதல் மற்றும் ஒரு தளத்தைத் தேர்ந்தெடுப்பது
எரான் கின்ஸ்ப்ரூனர், பெர்பெக்டோவில் முன்னணி தொழில்நுட்ப சுவிசேஷகர்: "அளவிடுதல் வேலை செய்ய, DevOps குழுக்கள் முதலில் பாரம்பரிய செயல்முறைகள், கருவிகள் மற்றும் திறன்களை ஒன்றிணைக்க கற்றுக் கொள்ள வேண்டும், பின்னர் DevOps இன் ஒவ்வொரு கட்டத்தையும் மெதுவாக வளர்த்து உறுதிப்படுத்த வேண்டும். இது அனைத்தும் பயனர் கதைகள் மற்றும் மதிப்பு ஸ்ட்ரீம்களை கவனமாக திட்டமிடுவதன் மூலம் தொடங்குகிறது, அதைத் தொடர்ந்து ட்ரங்க் அடிப்படையிலான மேம்பாடு அல்லது குறியீட்டைக் கிளைப்பதற்கும் ஒன்றிணைப்பதற்கும் மிகவும் பொருத்தமான பிற அணுகுமுறைகளைப் பயன்படுத்தி மென்பொருள் மற்றும் பதிப்புக் கட்டுப்பாட்டை எழுதுதல்.
"பின்னர் ஒருங்கிணைப்பு மற்றும் சோதனை நிலை வருகிறது, அங்கு தானியங்குமயமாக்கலுக்கான அளவிடக்கூடிய தளம் ஏற்கனவே தேவைப்படுகிறது. DevOps குழுக்கள் தங்கள் திறன் நிலை மற்றும் திட்டத்தின் இறுதி இலக்குகளுக்கு ஏற்ற சரியான தளத்தைத் தேர்ந்தெடுப்பது இங்குதான் முக்கியம்.
அடுத்த கட்டம் உற்பத்திக்கான வரிசைப்படுத்தல் மற்றும் இது ஆர்கெஸ்ட்ரேஷன் கருவிகள் மற்றும் கொள்கலன்களைப் பயன்படுத்தி முழுமையாக தானியங்குபடுத்தப்பட வேண்டும். DevOps இன் அனைத்து நிலைகளிலும் மெய்நிகராக்கப்பட்ட சூழல்கள் இருப்பது முக்கியம் (உற்பத்தி சிமுலேட்டர், QA சூழல் மற்றும் உண்மையான உற்பத்தி சூழல்) மற்றும் தொடர்புடைய முடிவுகளைப் பெற சோதனைகளுக்கு எப்போதும் சமீபத்திய தரவை மட்டுமே பயன்படுத்தவும். பகுப்பாய்வுகள் புத்திசாலித்தனமாகவும், வேகமான மற்றும் செயல்படக்கூடிய பின்னூட்டத்துடன் பெரிய தரவை செயலாக்கும் திறன் கொண்டதாகவும் இருக்க வேண்டும்.
3. பொறுப்பிலிருந்து குற்றத்தை எடுத்துக் கொள்ளுங்கள்.
கோர்டன் ஹாஃப், ரெட்ஹாட் சுவிசேஷகர்: "சுறுசுறுப்பான மென்பொருள் உருவாக்கத்தில் வெற்றிகரமான தோல்விகள் என அறியப்படும் சோதனையை அனுமதிக்கும் மற்றும் ஊக்குவிக்கும் ஒரு அமைப்பு மற்றும் சூழ்நிலையை உருவாக்குதல். தோல்விகளுக்கு வேறு யாரும் பொறுப்பேற்க மாட்டார்கள் என்று இது அர்த்தப்படுத்துவதில்லை. உண்மையில், யார் பொறுப்பு என்பதை அடையாளம் காண்பது இன்னும் எளிதாகிறது, ஏனெனில் "பொறுப்பாக இருப்பது" இனி "விபத்தை ஏற்படுத்துகிறது" என்று அர்த்தம் இல்லை. அதாவது, பொறுப்பின் சாராம்சம் தரமான முறையில் மாறுகிறது. நான்கு காரணிகள் முக்கியமானவை: இடையூறுகளின் அளவு, அணுகுமுறைகள், உற்பத்தி செயல்முறைகள் மற்றும் ஊக்கங்கள்." (இந்த காரணிகளைப் பற்றி கோர்டன் ஹஃப்பின் “DevOps பாடங்கள்: ஆரோக்கியமான பரிசோதனைகளின் 4 அம்சங்கள்” என்ற கட்டுரையில் நீங்கள் மேலும் படிக்கலாம்.)
4. முன்னோக்கி செல்லும் பாதையை அழிக்கவும்
Ben Grinnell, நிர்வாக இயக்குநரும், ஆலோசனை நிறுவனமான நார்த் ஹைலேண்டின் டிஜிட்டல் தலைவருமான: "அளவை அடைய, முன்னோடி திட்டங்களுடன் சேர்ந்து ஒரு "பாதை சுத்தம்" திட்டத்தை தொடங்க பரிந்துரைக்கிறேன். இந்த திட்டத்தின் குறிக்கோள், DevOps முன்னோடிகள் விட்டுச் செல்லும் குப்பைகளை, காலாவதியான விதிகள் மற்றும் அது போன்ற விஷயங்களைச் சுத்தம் செய்வதாகும், இதனால் முன்னோக்கி செல்லும் பாதை தெளிவாக இருக்கும்.
"புதிய வேலை முறைகளின் வெற்றிகளை பரவலாகக் கொண்டாடுவதன் மூலம் முன்னோடி குழுவிற்கு அப்பாற்பட்ட தகவல்தொடர்பு மூலம் மக்களுக்கு நிறுவன ஆதரவையும் வேகத்தையும் கொடுங்கள். DevOps திட்டங்களின் அடுத்த அலையில் ஈடுபட்டுள்ள மற்றும் முதல் முறையாக DevOps ஐப் பயன்படுத்துவதில் பதட்டமாக உள்ளவர்களுக்கு பயிற்சி அளிக்கவும். இந்த மக்கள் முன்னோடிகளிடமிருந்து மிகவும் வித்தியாசமானவர்கள் என்பதை நினைவில் கொள்ளுங்கள்.
5. கருவிகளை ஜனநாயகப்படுத்துங்கள்
ஸ்டீவ் நியூமன், ஸ்கேலிரின் நிறுவனர் மற்றும் தலைவர்: "கருவிகள் மக்களிடமிருந்து மறைக்கப்படக்கூடாது, மேலும் நேரத்தைச் செலவிட விரும்பும் எவரும் கற்றுக்கொள்வது ஒப்பீட்டளவில் எளிதாக இருக்க வேண்டும். ஒரு கருவியைப் பயன்படுத்துவதற்கு "சான்றளிக்கப்பட்ட" மூன்று நபர்களுக்கு பதிவுகளை வினவுவதற்கான திறன் கட்டுப்படுத்தப்பட்டால், உங்களிடம் மிகப் பெரிய கணினிச் சூழல் இருந்தாலும், சிக்கலைக் கையாள அதிகபட்சமாக மூன்று பேர் மட்டுமே இருப்பார்கள். வேறு வார்த்தைகளில் கூறுவதானால், கடுமையான (வணிக) விளைவுகளுக்கு வழிவகுக்கும் ஒரு இடையூறு இங்கே உள்ளது.
6. குழு வேலைக்கான சிறந்த நிலைமைகளை உருவாக்கவும்
டாம் கிளார்க், ஐடிவியின் காமன் பிளாட்ஃபார்ம் தலைவர்: "நீங்கள் எதையும் செய்யலாம், ஆனால் எல்லாவற்றையும் ஒரே நேரத்தில் செய்ய முடியாது. எனவே பெரிய இலக்குகளை அமைக்கவும், சிறியதாக தொடங்கவும், விரைவான மறு செய்கைகளில் முன்னேறவும். காலப்போக்கில், நீங்கள் விஷயங்களைச் செய்வதில் நற்பெயரைப் பெறுவீர்கள், எனவே மற்றவர்களும் உங்கள் முறைகளைப் பயன்படுத்த விரும்புவார்கள். மிகவும் பயனுள்ள குழுவை உருவாக்குவது பற்றி கவலைப்பட வேண்டாம். மாறாக, மக்களுக்கு சிறந்த பணிச்சூழல்களை வழங்குங்கள் மற்றும் செயல்திறன் பின்பற்றப்படும்."
7. கான்வேயின் சட்டம் மற்றும் கான்பன் பலகைகளைப் பற்றி மறந்துவிடாதீர்கள்
CollabNetVersionOne இல் மென்பொருள் விநியோகம் மற்றும் DevOps உத்தியின் இயக்குனர் லோகன் டெய்கல்: “கான்வேயின் சட்டத்தின் விளைவுகளைப் புரிந்துகொள்வது முக்கியம். எனது தளர்வான சொற்றொடரில், DevOps உட்பட, நாங்கள் உருவாக்கும் தயாரிப்புகள் மற்றும் நாங்கள் பயன்படுத்தும் செயல்முறைகள், எங்கள் நிறுவனத்தைப் போலவே கட்டமைக்கப்பட்டதாக மாறும் என்று இந்த சட்டம் கூறுகிறது.
“ஒரு நிறுவனத்தில் நிறைய குழிகள் இருந்தால், மென்பொருளைத் திட்டமிடும்போதும், உருவாக்கும்போதும், வெளியிடும்போதும் பலமுறை கட்டுப்பாடு கை மாறினால், அளவிடுதலின் விளைவு பூஜ்ஜியமாகவோ அல்லது குறுகிய காலமாகவோ இருக்கும். ஒரு நிறுவனம் சந்தையை மையமாகக் கொண்டு நிதியளிக்கப்பட்ட தயாரிப்புகளைச் சுற்றி குறுக்கு-செயல்பாட்டு குழுக்களை உருவாக்கினால், வெற்றிக்கான வாய்ப்புகள் வியத்தகு அளவில் அதிகரிக்கும்.
"அளவிடுதலின் மற்றொரு முக்கியமான அம்சம், கான்பன் பலகைகளில் அனைத்து வேலைகளையும் (WIP, வேலை முன்னேற்றம்) காட்டுவதாகும். ஒரு நிறுவனத்தில் மக்கள் இவற்றைப் பார்க்கக்கூடிய இடம் இருக்கும்போது, அது ஒத்துழைப்பை பெரிதும் ஊக்குவிக்கிறது, இது அளவிடுதலில் நேர்மறையான தாக்கத்தை ஏற்படுத்துகிறது.
8. பழைய தழும்புகளைத் தேடுங்கள்
Manuel Pais, DevOps ஆலோசகர் மற்றும் டீம் டோபாலஜிஸின் இணை ஆசிரியர்: "Dev மற்றும் Ops ஐத் தாண்டி DevOps நடைமுறைகளை எடுத்து மற்ற செயல்பாடுகளுக்கு அவற்றைப் பயன்படுத்த முயற்சிப்பது ஒரு உகந்த அணுகுமுறை அல்ல. இது நிச்சயமாக சில தாக்கத்தை ஏற்படுத்தும் (உதாரணமாக, கைமுறை கட்டுப்பாட்டை தானியக்கமாக்குவதன் மூலம்), ஆனால் டெலிவரி மற்றும் பின்னூட்ட செயல்முறைகளைப் புரிந்துகொள்வதன் மூலம் நாம் தொடங்கினால் இன்னும் பலவற்றை அடைய முடியும்."
"ஒரு நிறுவனத்தின் தகவல் தொழில்நுட்ப அமைப்பில் பழைய வடுக்கள் இருந்தால் - கடந்த கால சம்பவங்களின் விளைவாக செயல்படுத்தப்பட்ட நடைமுறைகள் மற்றும் மேலாண்மை வழிமுறைகள், ஆனால் அவற்றின் பொருத்தத்தை இழந்துவிட்டன (தயாரிப்புகள், தொழில்நுட்பங்கள் அல்லது செயல்முறைகளில் ஏற்பட்ட மாற்றங்கள் காரணமாக) - அவை நிச்சயமாக அகற்றப்பட வேண்டும். அல்லது திறமையற்ற அல்லது தேவையற்ற செயல்முறைகளை தானியக்கமாக்குவதை விட மென்மையாக்கப்பட்டது."
9. DevOps விருப்பங்களை வளர்க்க வேண்டாம்
அந்தோணி எட்வர்ட்ஸ், கத்தரிக்காய் இயக்க இயக்குனர்: "DevOps என்பது மிகவும் தெளிவற்ற சொல், எனவே ஒவ்வொரு அணியும் அதன் சொந்த DevOps பதிப்பில் முடிவடைகிறது. ஒரு நிறுவனத்தில் திடீரென 20 வகையான DevOps இருந்தால், அது ஒன்றும் நன்றாகப் பழகவில்லை. மூன்று மேம்பாட்டுக் குழுக்கள் ஒவ்வொன்றும் மேம்பாடு மற்றும் தயாரிப்பு மேலாண்மைக்கு இடையே அவற்றின் சொந்த, சிறப்பு இடைமுகத்தைக் கொண்டிருப்பது சாத்தியமற்றது. தயாரிப்பு சிமுலேட்டருக்கு மாற்றப்படும்போது, பின்னூட்டங்களைக் கையாள்வதற்கான தனிப்பட்ட எதிர்பார்ப்புகளை தயாரிப்புகள் கொண்டிருக்கக்கூடாது. இல்லையெனில், நீங்கள் ஒருபோதும் DevOps ஐ அளவிட முடியாது.
10. DevOps இன் வணிக மதிப்பைப் பிரசங்கிக்கவும்
ஸ்டீவ் நியூமன், ஸ்கேலிரின் நிறுவனர் மற்றும் தலைவர்: “DevOps இன் மதிப்பை அங்கீகரிக்க வேலை செய்யுங்கள். நீங்கள் என்ன செய்கிறீர்கள் என்பதன் பலன்களைப் பற்றி பேச தயங்காமல் கற்றுக்கொள்ளுங்கள். DevOps ஒரு நம்பமுடியாத நேரத்தையும் பணத்தையும் மிச்சப்படுத்துகிறது (சிந்திக்கவும்: குறைந்த வேலையில்லா நேரம், மீட்பதற்கான குறுகிய சராசரி நேரம்), மேலும் DevOps குழுக்கள் வணிக வெற்றிக்கான இந்த முயற்சிகளின் முக்கியத்துவத்தை அயராது வலியுறுத்த வேண்டும் (மற்றும் பிரசங்கிக்க வேண்டும்). இந்த வழியில் நீங்கள் பின்பற்றுபவர்களின் வட்டத்தை விரிவுபடுத்தலாம் மற்றும் நிறுவனத்தில் DevOps இன் செல்வாக்கை அதிகரிக்கலாம்.
போனஸ்
மீது எங்களின் சொந்த DevOps செப்டம்பர் 13 அன்று வரும் - ஆம், Red Hat, ஒரு மென்பொருள் தயாரிப்பாளராக, அதன் சொந்த DevOps குழுக்கள் மற்றும் நடைமுறைகளைக் கொண்டுள்ளது.
நிறுவனம் முழுவதிலும் உள்ள பிற குழுக்களுக்கான உள் ஆட்டோமேஷன் சேவைகளை உருவாக்கும் எங்கள் பொறியாளர் மார்க் பிர்கர், தனது சொந்தக் கதையை தூய ரஷ்ய மொழியில் கூறுவார் - Red Hat DevOps குழு எவ்வாறு Hat மெய்நிகராக்க மெய்நிகர் சூழல்களில் இருந்து பயன்பாடுகளை முழு அளவிலான கொள்கலன் வடிவமைப்பிற்கு மாற்றியது. OpenShift இயங்குதளம்.
ஆனால் அதெல்லாம் இல்லை:
நிறுவனங்கள் பணிச்சுமையை கொள்கலன்களுக்கு மாற்றியவுடன், பாரம்பரிய பயன்பாட்டு கண்காணிப்பு முறைகள் வேலை செய்யாமல் போகலாம். இரண்டாவது பேச்சில், நாம் பதிவு செய்யும் முறையை மாற்றுவதற்கான நமது உந்துதலை விளக்குவோம் மற்றும் நவீன பதிவு மற்றும் கண்காணிப்பு முறைகளுக்கு நம்மை இட்டுச் சென்ற பாதையின் தொடர்ச்சியைக் காண்பிப்போம்.
ஆதாரம்: www.habr.com