DevOps இன்ஜினியர்கள் இல்லை. பின்னர் யார் இருக்கிறார், அதை என்ன செய்வது?

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

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

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

கலாச்சாரம் மற்றும் செயல்முறைகள் பற்றி

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

எடுத்துக்காட்டாக, ஒரு கணினி நிர்வாகிக்கும் சேவை நிர்வாகத்திற்கான SRE அணுகுமுறைக்கும் உள்ள வித்தியாசத்தை விவரிக்கிறது புகழ்பெற்ற Google SRE புத்தகம் தொடங்குகிறது. சுவாரஸ்யமான ஆய்வுகள் உள்ளே மேற்கொள்ளப்பட்டுள்ளன டோரா கணக்கெடுப்பு - சிறந்த டெவலப்பர்கள் எப்படியாவது ஒரு மணி நேரத்திற்கு ஒரு முறைக்கு மேல் புதிய மாற்றங்களை உற்பத்தியில் ஈடுபடுத்துகிறார்கள் என்பது தெளிவாகிறது. அவர்கள் தங்கள் கைகளால் 10% க்கு மேல் சோதனை செய்கிறார்கள் (இதிலிருந்து பார்க்கலாம் கடந்த ஆண்டு DORA) இதை எப்படி செய்கிறார்கள்? "எக்செல் அல்லது டை" அறிக்கை தலைப்புகளில் ஒன்று கூறுகிறது. சோதனையின் பின்னணியில் இந்த புள்ளிவிவரங்களைப் பற்றிய விரிவான விவாதத்திற்கு, நீங்கள் பாரூச் சடோகுர்ஸ்கியின் முக்கிய குறிப்பைப் பார்க்கவும். “எங்களிடம் DevOps உள்ளது. எல்லா சோதனையாளர்களையும் நீக்குவோம்." எங்கள் மற்றொரு மாநாட்டில், ஹைசன்பக்.

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

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

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

தீய வட்டம்

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

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

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

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

எனவே எங்களுக்கு வழங்கல் மற்றும் தேவை உள்ளது. தனக்குத்தானே உணவளிக்கும் ஒரு தீய வட்டம். இதைத்தான் நாங்கள் எதிர்த்துப் போராடுகிறோம் (DevOops மாநாட்டை உருவாக்குவது உட்பட).

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

DevOps இல் மக்கள் என்ன செய்கிறார்கள் (உண்மையில்)

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

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

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

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

சிக்கலின் தொழில்நுட்ப பகுதியும் உள்ளது, நிச்சயமாக. உங்கள் புதிய குறியீடு ஒரு மாதத்தில் சோதிக்கப்பட்டு, ஒரு வருடம் கழித்து வெளியிடப்பட்டால், அதை விரைவுபடுத்துவது உடல் ரீதியாக சாத்தியமற்றது என்றால், நீங்கள் நல்ல நடைமுறைகளுக்கு ஏற்ப வாழ முடியாது. நல்ல நடைமுறைகள் நல்ல கருவிகளால் ஆதரிக்கப்படுகின்றன. எடுத்துக்காட்டாக, உள்கட்டமைப்பு-குறியீடு என்ற யோசனையை மனதில் கொண்டு, AWS CloudFormation மற்றும் Terraform முதல் Chef-Ansible-Puppet வரை எதையும் நீங்கள் பயன்படுத்தலாம். இதையெல்லாம் நீங்கள் தெரிந்து கொள்ள வேண்டும் மற்றும் செய்ய முடியும், இது ஏற்கனவே ஒரு பொறியியல் துறையாகும். காரணத்தை விளைவுடன் குழப்பாமல் இருப்பது முக்கியம்: முதலில் நீங்கள் SRE இன் கொள்கைகளின்படி வேலை செய்கிறீர்கள், பின்னர் சில குறிப்பிட்ட தொழில்நுட்ப தீர்வுகளின் வடிவத்தில் இந்த கொள்கைகளை செயல்படுத்தவும். அதே நேரத்தில், SRE என்பது மிகவும் விரிவான வழிமுறையாகும், இது ஜென்கின்ஸை எவ்வாறு அமைப்பது என்று உங்களுக்குச் சொல்லவில்லை, ஆனால் ஐந்து அடிப்படைக் கொள்கைகளைப் பற்றி:

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

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

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

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

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

இதையெல்லாம் என்ன செய்வது

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

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

• செயல்முறைகள் மற்றும் கலாச்சாரம்;
• தள நம்பகத்தன்மை பொறியியல்;
• கிளவுட் நேட்டிவ்;

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

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

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

• உள்கட்டமைப்பில் பணிபுரியும் டெவலப்பர்கள். SRE மற்றும் Cloud Native பற்றிய அறிக்கைகளின் குழுக்கள் உங்களுக்கு மிகவும் பொருத்தமானவை.
• கணினி நிர்வாகிகள். இது இங்கே மிகவும் சிக்கலானது. DevOops என்பது கணினி நிர்வாகத்தைப் பற்றியது அல்ல. அதிர்ஷ்டவசமாக, கணினி நிர்வாகத்தின் தலைப்பில் சிறந்த மாநாடுகள், புத்தகங்கள், கட்டுரைகள், இணையத்தில் வீடியோக்கள் போன்றவை நிறைய உள்ளன. மறுபுறம், கலாச்சாரம் மற்றும் செயல்முறைகளைப் புரிந்துகொள்வது, கிளவுட் தொழில்நுட்பங்கள் மற்றும் கிளவுட் நேட்டிவ் மூலம் வாழ்க்கையின் விவரங்களைப் பற்றி அறிந்துகொள்வதில் நீங்கள் ஆர்வமாக இருந்தால், நாங்கள் உங்களைப் பார்க்க விரும்புகிறோம்! இதைப் பற்றி யோசித்துப் பாருங்கள்: நீங்கள் நிர்வாகம் செய்கிறீர்கள், பிறகு நீங்கள் என்ன செய்வீர்கள்? திடீரென்று விரும்பத்தகாத சூழ்நிலையில் உங்களைக் கண்டுபிடிப்பதைத் தவிர்க்க, நீங்கள் இப்போது கற்றுக்கொள்ள வேண்டும்.

மற்றொரு விருப்பம் உள்ளது: நீங்கள் விடாமுயற்சியுடன் இருக்கிறீர்கள் குறிப்பாக ஒரு DevOps பொறியாளர் மற்றும் வேறு எதுவும் இல்லை, அது என்ன அர்த்தம். நாங்கள் உங்களை ஏமாற்ற வேண்டும், DevOops என்பது DevOps பொறியாளர்களுக்கான மாநாடு அல்ல!

இருந்து ஸ்லைடு கான்ஸ்டான்டின் டைனரின் அறிக்கை முனிச்சில்

DevOops 2020 மாஸ்கோ ஏப்ரல் 29-30 அன்று மாஸ்கோவில் நடைபெறும், டிக்கெட்டுகள் ஏற்கனவே உள்ளன அதிகாரப்பூர்வ இணையதளத்தில் வாங்கவும்.

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

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