DevOps கோட்பாடுகளின் அடிப்படையில் ஏழு உருமாற்ற ஆர்க்கிடைப்கள்

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

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

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

பேச்சாளர் பற்றி:

35 ஆண்டுகளுக்கும் மேலாக IT நிர்வாகத்தில், Canonical இல் OpenCloud இன் முன்னோடி உருவாக்கத்தில் பங்கேற்றார், 10 தொடக்கங்களில் பங்கேற்றார், அவற்றில் இரண்டு டெல் மற்றும் டோக்கருக்கு விற்கப்பட்டன. தற்போது அவர் SJ டெக்னாலஜிஸில் DevOps மற்றும் டிஜிட்டல் நடைமுறைகளின் துணைத் தலைவராக உள்ளார்.

ஜானின் பார்வையில் அடுத்த கதை.

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

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

DevOps என்றால் என்ன?

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

இப்போது எங்களிடம் நிறைய தரவு உள்ளது, ஐந்து வருட கல்வி ஆராய்ச்சி, தொழில்துறை அளவில் கோட்பாடுகளின் சோதனை. இந்த ஆய்வுகள் எங்களிடம் கூறுவது என்னவென்றால், நீங்கள் ஒரு நிறுவன கலாச்சாரத்தில் சில நடத்தை முறைகளை இணைத்தால், நீங்கள் 2000x வேகத்தை அடையலாம். இந்த முடுக்கம் நிலைத்தன்மையில் சமமான முன்னேற்றத்துடன் பொருந்துகிறது. இது DevOps எந்த நிறுவனத்திற்கும் கொண்டு வரக்கூடிய நன்மையின் அளவு அளவீடு ஆகும். ஓரிரு வருடங்களுக்கு முன்பு, Fortune 5000 நிறுவனத்தின் CEO விடம் DevOps பற்றிப் பேசிக்கொண்டிருந்தேன். நான் விளக்கக்காட்சிக்குத் தயாராகும் போது, ​​எனது பல வருட அனுபவத்தை 5 நிமிடங்களில் சுருக்கமாகச் சொல்ல வேண்டியிருந்ததால், நான் மிகவும் பதட்டமாக இருந்தேன்.

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

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

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

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

மோசமான கலாச்சாரம் காலை உணவுக்கு நல்ல அணுகுமுறைகளை உண்கிறது

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

இந்த முக்கிய சிக்கலை தீர்க்க, நீங்கள் பின்வரும் படிகளை எடுக்க வேண்டும்:

1. எல்லா வேலைகளையும் பார்க்கும்படி செய்: நீங்கள் அனைத்து வேலைகளையும் பார்க்க வேண்டும். அது அவசியம் சில திரையில் காட்டப்பட வேண்டும் என்ற அர்த்தத்தில் அல்ல, ஆனால் அது கவனிக்கத்தக்கதாக இருக்க வேண்டும் என்ற அர்த்தத்தில்.
2. ஒருங்கிணைந்த பணி மேலாண்மை அமைப்புகள்: மேலாண்மை அமைப்புகள் ஒருங்கிணைக்கப்பட வேண்டும். "பழங்குடியினர்" அறிவு மற்றும் நிறுவன அறிவின் பிரச்சனையில், 9ல் 10 வழக்குகளில் மக்கள்தான் இடையூறாக உள்ளனர். புத்தகத்தில் "பீனிக்ஸ் திட்டம்" ப்ரெண்ட் என்ற ஒரு தனி நபருடன் தான் பிரச்சனை இருந்தது, அவர் திட்டம் மூன்று வருடங்கள் தாமதமாக இருந்தது. நான் எல்லா இடங்களிலும் இந்த "ப்ரெண்ட்ஸ்" உடன் ஓடுகிறேன். இந்தத் தடைகளைத் தீர்க்க, எங்கள் பட்டியலில் உள்ள அடுத்த இரண்டு உருப்படிகளைப் பயன்படுத்துகிறேன்.
3. கட்டுப்பாடுகள் முறையின் கோட்பாடு: கட்டுப்பாடுகளின் கோட்பாடு.
4. ஒத்துழைப்பு ஹேக்குகள்: ஒத்துழைப்பு ஹேக்ஸ்.
5. டொயோட்டா கட்டா (கோச்சிங் கேட்டா): நான் டொயோட்டா கட்டா பற்றி அதிகம் பேசமாட்டேன். ஆர்வமாக இருந்தால், என் கிட்ஹப்பில் விளக்கக்காட்சிகள் உள்ளன இந்த ஒவ்வொரு தலைப்புகளிலும்.
6. சந்தை சார்ந்த அமைப்பு: சந்தை சார்ந்த அமைப்பு.
7. ஷிப்ட்-லெப்ட் ஆடிட்டர்கள்: சுழற்சியின் ஆரம்ப கட்டங்களில் தணிக்கை.

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

(இந்த விளக்கத்தை தனித்தனியாக பார்க்கலாம் இணைப்பைப் பாருங்கள்)

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

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

(இந்த விளக்கத்தை தனித்தனியாக பார்க்கலாம் இணைப்பைப் பாருங்கள்)

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

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

(இந்த விளக்கத்தை தனித்தனியாக பார்க்கலாம் இணைப்பைப் பாருங்கள்)

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

(இந்த விளக்கத்தை தனித்தனியாக பார்க்கலாம் இணைப்பைப் பாருங்கள்)

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

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

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

(இந்த விளக்கத்தை தனித்தனியாக பார்க்கலாம் இணைப்பைப் பாருங்கள்)

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

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

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

1. எல்லா வேலைகளையும் காணக்கூடியதாக ஆக்குங்கள்: வேலையைத் தெரியும்படி செய்யுங்கள்

நான் பணிபுரியும் பெரும்பாலான நிறுவனங்களில் தெரியாத வேலைகளின் சதவீதம் அதிகம். உதாரணமாக, ஒரு ஊழியர் மற்றொருவரிடம் வந்து ஏதாவது செய்யச் சொல்லும்போது இது நடக்கும். பெரிய நிறுவனங்களில், 60% திட்டமிடப்படாத வேலைகள் இருக்கலாம். மேலும் 40% வேலை எந்த வகையிலும் ஆவணப்படுத்தப்படவில்லை. போயிங் விமானமாக இருந்தால், என் வாழ்நாளில் நான் அவர்களின் விமானத்தில் ஏறவே மாட்டேன். பாதி வேலை ஆவணப்படுத்தப்பட்டால், இந்த பணி சரியாக நடக்கிறதா இல்லையா என்பது தெரியவில்லை. மற்ற எல்லா முறைகளும் பயனற்றதாக மாறிவிடும் - எதையும் தானியக்கமாக்க முயற்சிப்பதில் எந்த அர்த்தமும் இல்லை, ஏனென்றால் அறியப்பட்ட 50% வேலையின் மிகவும் ஒத்திசைவான மற்றும் தெளிவான பகுதியாக இருக்கலாம், இதன் ஆட்டோமேஷன் சிறந்த முடிவுகளைத் தராது, மேலும் மோசமானது விஷயங்கள் கண்ணுக்கு தெரியாத பாதியில் உள்ளன. ஆவணங்கள் இல்லாத நிலையில், அனைத்து வகையான ஹேக்குகள் மற்றும் மறைக்கப்பட்ட வேலைகளைக் கண்டுபிடிப்பது சாத்தியமில்லை, இடையூறுகளைக் கண்டுபிடிக்க முடியாது, நான் ஏற்கனவே பேசிய "ப்ரெண்ட்ஸ்". டொமினிகா டி கிராண்டிஸின் அற்புதமான புத்தகம் உள்ளது "வேலையைக் காணும்படி செய்தல்". அவள் வெளிப்படுத்துகிறாள் ஐந்து வெவ்வேறு "நேர கசிவுகள்" (கால திருடர்கள்):

• செயல்பாட்டில் அதிக வேலை (WIP)
• அறியப்படாத சார்புகள்
• திட்டமிடப்படாத வேலை
• முரண்பட்ட முன்னுரிமைகள்
• புறக்கணிக்கப்பட்ட வேலை

இது மிகவும் மதிப்புமிக்க பகுப்பாய்வு மற்றும் புத்தகம் சிறந்தது, ஆனால் 50% தரவு மட்டுமே தெரிந்தால் இந்த அறிவுரை அனைத்தும் பயனற்றது. டொமினிகா முன்மொழியப்பட்ட முறைகள் 90% க்கு மேல் துல்லியமாக இருந்தால் பயன்படுத்தப்படலாம். நான் ஒரு முதலாளி கீழ்நிலை அதிகாரிக்கு 15 நிமிட பணியை கொடுக்கும் சூழ்நிலைகளைப் பற்றி பேசுகிறேன், ஆனால் அது அவருக்கு மூன்று நாட்கள் ஆகும்; ஆனால் இந்த அடிபணிந்தவர் நான்கு அல்லது ஐந்து பேரைச் சார்ந்திருப்பது முதலாளிக்கு உண்மையில் தெரியாது.

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

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

வேலை தெரியும் போது, ​​தரவை நேர்த்தியாக வகைப்படுத்தலாம் (அதுதான் புகைப்படத்தில் டொமினிகா செய்கிறார்), ஐந்து முறை கசிவுகளின் சுருக்கத்தைப் பயன்படுத்தலாம் மற்றும் ஆட்டோமேஷனைப் பயன்படுத்தலாம்.

2. வேலை மேலாண்மை அமைப்புகளை ஒருங்கிணைக்கவும்: பணி மேலாண்மை

நான் பேசும் தொன்மங்கள் ஒரு வகையான பிரமிடு. முதலாவது சரியாகச் செய்யப்பட்டிருந்தால், இரண்டாவது ஏற்கனவே ஒரு வகையான செருகு நிரலாகும். இவற்றில் பல ஸ்டார்ட்அப்களுக்கு வேலை செய்யாது, பார்ச்சூன் 5000 போன்ற பெரிய நிறுவனங்களுக்கு அவை நினைவில் வைக்கப்பட வேண்டும். நான் கடைசியாக பணிபுரிந்த நிறுவனத்தில் 10 டிக்கெட் அமைப்புகள் இருந்தன. ஒரு குழுவில் ரெமிடி இருந்தது, மற்றொன்று அதன் சொந்த அமைப்பை எழுதியது, மூன்றாவது ஜிராவைப் பயன்படுத்தியது, மேலும் சிலர் மின்னஞ்சலைப் பயன்படுத்தினர். நிறுவனத்தில் 30 வெவ்வேறு குழாய்கள் இருந்தால் அதே சிக்கல் எழுகிறது, ஆனால் இதுபோன்ற எல்லா நிகழ்வுகளையும் விவாதிக்க எனக்கு நேரம் இல்லை.

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

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

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

சேவைகள் குழாய்

இது மீண்டும் பெரிய நிறுவனங்களுக்கு மட்டுமே பொருந்தும். நீங்கள் ஒரு புதிய துறையில் புதிய நிறுவனமாக இருந்தால், உங்கள் சட்டைகளை விரித்து உங்கள் டிராவிஸ் CI அல்லது CircleCI உடன் வேலை செய்யுங்கள். பார்ச்சூன் 5000 நிறுவனங்களுக்கு வரும்போது, ​​நான் பணிபுரிந்த வங்கியில் நடந்த ஒரு வழக்கு. கூகுள் அவர்களிடம் வந்து பழைய ஐபிஎம் அமைப்புகளின் வரைபடங்கள் காட்டப்பட்டன. கூகுளின் தோழர்கள் குழப்பத்துடன் கேட்டார்கள் - இதற்கான மூல குறியீடு எங்கே? ஆனால் மூல குறியீடு இல்லை, GUI கூட இல்லை. பெரிய நிறுவனங்கள் சமாளிக்க வேண்டிய உண்மை இதுதான்: பண்டைய மெயின்பிரேமில் 40 வருட வங்கி பதிவுகள். எனது வாடிக்கையாளர்களில் ஒருவர், சர்க்யூட் பிரேக்கர் பேட்டர்ன்கள் கொண்ட குபெர்னெட்டஸ் கன்டெய்னர்கள் மற்றும் கேயாஸ் மங்கி, அனைத்தையும் கீபேங்க் பயன்பாட்டிற்காக பயன்படுத்துகிறார். ஆனால் இந்த கொள்கலன்கள் இறுதியில் ஒரு COBOL பயன்பாட்டுடன் இணைக்கப்படுகின்றன.

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

3. கட்டுப்பாடுகளின் கோட்பாடு: கட்டுப்பாடுகளின் கோட்பாடு

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

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

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

இது எனது முக்கிய அம்சம்: எந்தவொரு உயர் தொழில்நுட்பத்தையும் பரிந்துரைக்க, நீங்கள் முதலில் அவற்றுக்கான அடித்தளத்தை ஒழுங்கமைக்க வேண்டும், மேலும் இப்போது விவரிக்கப்பட்டுள்ள குறைந்த தொழில்நுட்ப தீர்வுகள் மூலம் இதைச் செய்யலாம். நீங்கள் உயர் தொழில்நுட்பங்களுடன் தொடங்கினால், அவை ஏன் தேவை என்பதை விளக்கவில்லை என்றால், ஒரு விதியாக, இது நன்றாக முடிவடையாது. எங்கள் வாடிக்கையாளர்களில் ஒருவர் Azure ML ஐப் பயன்படுத்துகிறார், இது மிகவும் மலிவான மற்றும் எளிமையான தீர்வாகும். அவர்களின் கேள்விகளில் சுமார் 30% சுய-கற்றல் இயந்திரம் மூலம் பதிலளிக்கப்பட்டது. இந்த விஷயம் தரவு அறிவியல், புள்ளியியல் அல்லது கணிதத்தில் ஈடுபடாத ஆபரேட்டர்களால் எழுதப்பட்டது. இது குறிப்பிடத்தக்கது. அத்தகைய தீர்வுக்கான செலவு மிகக் குறைவு.

4. Collaboration hacks: Collaboration hacks

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

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

5. கோச்சிங் கேட்டா

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

மைக் ரோதரின் இந்த தலைப்பில் ஒரு நல்ல பேச்சு உள்ளது:

6. சந்தை சார்ந்த: சந்தை சார்ந்த அமைப்பு

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

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

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

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

7. ஷிப்ட்-லெப்ட் ஆடிட்டர்கள்: சுழற்சியின் ஆரம்பத்தில் தணிக்கை. காட்சிக்கு பாதுகாப்பு விதிகளுக்கு இணங்குதல்

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

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

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

படி அறிக்கை, 2018 இல் Sonatype ஆல் உருவாக்கப்பட்டது, 2017 இல் 87 பில்லியன் OSS பதிவிறக்க கோரிக்கைகள் இருந்தன.

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

இந்த வரிசையின் உதாரணம்:


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

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

இதன் விளைவாக

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

பயனுள்ள இணைப்புகள்

உங்களுக்கு பயனுள்ளதாக இருக்கும் DevOops மாநாட்டின் சில பேச்சுக்கள் இங்கே:

• Sergey Berdnikov, Artyom Kalichkin - வெற்றிக் கதை, அல்லது “Dev+DevOps+Ops” (видео, அறிக்கையின் பிரதி)
• பருச் சடோகுர்ஸ்கி, லியோனிட் இகோல்னிக் - டெவொப்ஸ் அளவில்: மூன்று செயல்களில் ஒரு கிரேக்க சோகம் (видео, அறிக்கையின் பிரதி)
• அலெக்சாண்டர் டிடோவ், கிரில் டோல்கச்சேவ் - DevOps, பொறியாளர்கள் மற்றும் சமூகம்
• திமோதி லிஸ்டர் - பாத்திரங்கள், சமூகம் மற்றும் கலாச்சாரம்: செழுமைக்கான முக்கிய காரணிகள்

உள்ளே பார் நிரல் DevOops 2020 மாஸ்கோ - நிறைய சுவாரஸ்யமான விஷயங்கள் உள்ளன.

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