அரட்டை விவாதத்தின் அடிப்படையில்
சமீபத்தில், DevOps மற்றும் SRE இன் வரையறையில் உண்மையான போர்கள் வெடித்தன.
இந்த தலைப்பில் பல வழிகளில் விவாதங்கள் ஏற்கனவே நான் உட்பட என் பற்களை விளிம்பில் வைத்திருக்கின்றன என்ற போதிலும், இந்த தலைப்பில் எனது பார்வையை ஹப்ரா சமூகத்தின் நீதிமன்றத்திற்கு கொண்டு வர முடிவு செய்தேன். ஆர்வமுள்ளவர்களுக்கு, பூனைக்கு வரவேற்கிறோம். மற்றும் எல்லாம் புதிதாக ஆரம்பிக்கட்டும்!
முன்வரலாறு
எனவே, பண்டைய காலங்களில், மென்பொருள் உருவாக்குநர்கள் மற்றும் சேவையக நிர்வாகிகள் குழு தனித்தனியாக வாழ்ந்தது. முதலாவது வெற்றிகரமாக குறியீட்டை எழுதினார், இரண்டாவதாக, பல்வேறு சூடான, அன்பான வார்த்தைகளைப் பயன்படுத்தி, சேவையகங்களை அமைத்து, டெவலப்பர்களிடம் அவ்வப்போது வந்து, "எனது கணினியில் எல்லாம் வேலை செய்கிறது" என்ற விரிவான பதிலைப் பெறுகிறது. வணிகம் மென்பொருளுக்காகக் காத்திருந்தது, எல்லாம் சும்மா இருந்தது, அது அவ்வப்போது உடைந்தது, எல்லோரும் பதட்டமாக இருந்தனர். குறிப்பாக இந்த முழு குழப்பத்திற்கும் பணம் கொடுத்தவர். புகழ்பெற்ற விளக்கு சகாப்தம். DevOps எங்கிருந்து வருகிறது என்பது உங்களுக்கு ஏற்கனவே தெரியும்.
DevOps நடைமுறைகளின் பிறப்பு
பின்னர் தீவிர தோழர்கள் வந்து சொன்னார்கள் - இது ஒரு தொழில் அல்ல, நீங்கள் அப்படி வேலை செய்ய முடியாது. மேலும் அவர்கள் வாழ்க்கை சுழற்சி மாதிரிகளை கொண்டு வந்தனர். இங்கே, எடுத்துக்காட்டாக, வி-மாடல்.
எனவே நாம் என்ன பார்க்கிறோம்? ஒரு வணிகம் ஒரு கருத்துடன் வருகிறது, கட்டிடக் கலைஞர்கள் வடிவமைப்பு தீர்வுகள், டெவலப்பர்கள் குறியீட்டை எழுதுகிறார்கள், பின்னர் அது தோல்வியடைகிறது. யாரோ ஒருவர் தயாரிப்பை எப்படியாவது சோதிக்கிறார், யாரோ எப்படியாவது அதை இறுதிப் பயனருக்கு வழங்குகிறார்கள், மேலும் இந்த அதிசய மாதிரியின் வெளியீட்டில் எங்காவது ஒரு தனிமையான வணிக வாடிக்கையாளர் கடலில் வாக்குறுதியளிக்கப்பட்ட வானிலைக்காக காத்திருக்கிறார். இந்த செயல்முறையை நிறுவ அனுமதிக்கும் முறைகள் தேவை என்ற முடிவுக்கு வந்தோம். அவற்றைச் செயல்படுத்தும் நடைமுறைகளை உருவாக்க முடிவு செய்தோம்.
நடைமுறை என்றால் என்ன என்ற தலைப்பில் ஒரு பாடல் வரி விலக்கு
நடைமுறையில் நான் தொழில்நுட்பம் மற்றும் ஒழுக்கம் ஆகியவற்றின் கலவையைக் குறிக்கிறேன். டெராஃபார்ம் குறியீட்டைப் பயன்படுத்தி உள்கட்டமைப்பை விவரிக்கும் நடைமுறை ஒரு எடுத்துக்காட்டு. ஒழுக்கம் என்பது உள்கட்டமைப்பை குறியீட்டுடன் விவரிப்பது எப்படி, அது டெவலப்பரின் தலையில் உள்ளது, மேலும் தொழில்நுட்பமே டெராஃபார்ம் ஆகும்.
அவர்கள் அவற்றை DevOps நடைமுறைகள் என்று அழைக்க முடிவு செய்தனர் - அவை வளர்ச்சி முதல் செயல்பாடுகள் வரை என்று நான் நினைக்கிறேன். நாங்கள் பல்வேறு புத்திசாலித்தனமான விஷயங்களைக் கொண்டு வந்தோம் - CI/CD நடைமுறைகள், IaC கொள்கையின் அடிப்படையிலான நடைமுறைகள், அவற்றில் ஆயிரக்கணக்கானவை. நாங்கள் செல்கிறோம், டெவலப்பர்கள் குறியீட்டை எழுதுகிறார்கள், டெவொப்ஸ் பொறியாளர்கள் கணினியின் விளக்கத்தை குறியீட்டின் வடிவத்தில் வேலை செய்யும் அமைப்புகளாக மாற்றுகிறார்கள் (ஆம், குறியீடு, துரதிர்ஷ்டவசமாக, ஒரு விளக்கம், ஆனால் கணினியின் உருவகம் அல்ல), விநியோகம் தொடர்கிறது, மற்றும் பல. நேற்றைய நிர்வாகிகள், புதிய நடைமுறைகளில் தேர்ச்சி பெற்று, DevOps இன்ஜினியர்களாக பெருமையுடன் மீண்டும் பயிற்சி பெற்றனர், எல்லாம் அங்கிருந்து சென்றது. மற்றும் மாலை இருந்தது, மற்றும் காலை இருந்தது ... மன்னிக்கவும், அங்கிருந்து இல்லை.
மீண்டும் எல்லாம் நன்றாக இல்லை, கடவுளுக்கு நன்றி
எல்லாம் அமைதியடைந்து, பல்வேறு தந்திரமான "முறையியலாளர்கள்" DevOps நடைமுறைகளில் தடிமனான புத்தகங்களை எழுதத் தொடங்கியவுடன், மோசமான DevOps பொறியாளர் யார் மற்றும் DevOps ஒரு உற்பத்தி கலாச்சாரம் என்பது பற்றிய சர்ச்சைகள் அமைதியாக வெடித்தன, மீண்டும் அதிருப்தி எழுந்தது. மென்பொருள் விநியோகம் முற்றிலும் அற்பமான பணி என்று திடீரென்று மாறியது. ஒவ்வொரு மேம்பாட்டு உள்கட்டமைப்புக்கும் அதன் சொந்த அடுக்கு உள்ளது, எங்காவது நீங்கள் அதைச் சேகரிக்க வேண்டும், எங்காவது நீங்கள் சூழலை வரிசைப்படுத்த வேண்டும், இங்கே உங்களுக்கு டாம்கேட் தேவை, இங்கே அதைத் தொடங்க உங்களுக்கு ஒரு தந்திரமான மற்றும் சிக்கலான வழி தேவை - பொதுவாக, உங்கள் தலை துடிக்கிறது. சிக்கல், விந்தை போதும், முதன்மையாக செயல்முறைகளின் அமைப்பில் மாறியது - இந்த விநியோக செயல்பாடு, ஒரு இடையூறு போல, செயல்முறைகளைத் தடுக்கத் தொடங்கியது. கூடுதலாக, யாரும் செயல்பாடுகளை ரத்து செய்யவில்லை. வி-மாடலில் இது தெரியவில்லை, ஆனால் முழு வாழ்க்கைச் சுழற்சியும் வலதுபுறத்தில் உள்ளது. இதன் விளைவாக, உள்கட்டமைப்பை எப்படியாவது பராமரிப்பது, கண்காணிப்பது, சம்பவங்களைத் தீர்ப்பது மற்றும் விநியோகத்தை கையாள்வது அவசியம். அந்த. மேம்பாடு மற்றும் செயல்பாடு இரண்டிலும் ஒரு காலில் உட்கார்ந்து - திடீரென்று அது வளர்ச்சி மற்றும் செயல்பாடுகளாக மாறியது. பின்னர் மைக்ரோ சர்வீஸுக்கு பொதுவான ஹைப் இருந்தது. அவற்றுடன், உள்ளூர் இயந்திரங்களின் வளர்ச்சி மேகக்கணிக்கு நகரத் தொடங்கியது - உள்நாட்டில் எதையாவது பிழைத்திருத்த முயற்சிக்கவும், டஜன் கணக்கான மற்றும் நூற்றுக்கணக்கான மைக்ரோ சர்வீஸ்கள் இருந்தால், நிலையான விநியோகம் உயிர்வாழ்வதற்கான வழிமுறையாக மாறும். ஒரு "சிறிய சுமாரான நிறுவனத்திற்கு" அது சரியாக இருந்தது, ஆனால் இன்னும்? Google பற்றி என்ன?
Google வழங்கும் SRE
கூகிள் வந்து, மிகப்பெரிய கற்றாழை சாப்பிட்டு முடிவு செய்தது - எங்களுக்கு இது தேவையில்லை, நம்பகத்தன்மை தேவை. மற்றும் நம்பகத்தன்மை நிர்வகிக்கப்பட வேண்டும். நம்பகத்தன்மையை நிர்வகிக்கும் வல்லுநர்கள் எங்களுக்குத் தேவை என்று நான் முடிவு செய்தேன். நான் அவர்களை எஸ்ஆர் இன்ஜினியர்களை அழைத்து, அது உங்களுக்கு, வழக்கம் போல் நன்றாக செய்யுங்கள். இதோ SLI, இதோ SLO, இதோ கண்காணிப்பு. மேலும் ஆபரேஷன்களில் மூக்கை நுழைத்தார். மேலும் அவர் தனது "நம்பகமான DevOps" SRE என்று அழைத்தார். எல்லாம் நன்றாக இருப்பதாகத் தெரிகிறது, ஆனால் கூகிள் வாங்கக்கூடிய ஒரு அழுக்கு ஹேக் உள்ளது - எஸ்ஆர் பொறியாளர்களின் பதவிக்கு, தகுதிவாய்ந்த டெவலப்பர்கள் மற்றும் ஒரு சிறிய வீட்டுப்பாடம் செய்து, வேலை செய்யும் அமைப்புகளின் செயல்பாட்டைப் புரிந்துகொண்டவர்களை வேலைக்கு அமர்த்தவும். மேலும், அத்தகைய நபர்களை பணியமர்த்துவதில் Google க்கே சிக்கல்கள் உள்ளன - முக்கியமாக இங்கே அது தன்னுடன் போட்டியிடுவதால் - ஒருவருக்கு வணிக தர்க்கத்தை விவரிக்க வேண்டியது அவசியம். பொறியாளர்களை வெளியிடுவதற்கு டெலிவரி ஒதுக்கப்பட்டது, எஸ்ஆர் - பொறியாளர்கள் நம்பகத்தன்மையை நிர்வகிக்கின்றனர் (நிச்சயமாக, நேரடியாக அல்ல, உள்கட்டமைப்பில் செல்வாக்கு செலுத்துவதன் மூலம், கட்டிடக்கலை மாற்றுவதன் மூலம், மாற்றங்கள் மற்றும் குறிகாட்டிகளைக் கண்காணிப்பதன் மூலம், சம்பவங்களைக் கையாள்வதன் மூலம்). நல்லது, உங்களால் முடியும் . ஆனால் நீங்கள் கூகிள் இல்லை, ஆனால் நம்பகத்தன்மை இன்னும் எப்படியாவது கவலையாக இருந்தால் என்ன செய்வது?
DevOps யோசனைகளின் வளர்ச்சி
அப்போதுதான் டோக்கர் வந்தார், அது எல்எக்ஸ்சியில் இருந்து வளர்ந்தது, பின்னர் டோக்கர் ஸ்வார்ம் மற்றும் குபெர்னெட்ஸ் போன்ற பல்வேறு ஆர்கெஸ்ட்ரேஷன் அமைப்புகள் மற்றும் டெவொப்ஸ் பொறியாளர்கள் வெளியேற்றினர் - நடைமுறைகளின் ஒருங்கிணைப்பு டெலிவரியை எளிதாக்கியது. டெவலப்பர்களுக்கு டெலிவரியை அவுட்சோர்ஸ் செய்வது கூட சாத்தியமாகும் அளவுக்கு அதை எளிதாக்கியது - deployment.yaml என்றால் என்ன. கொள்கலன் சிக்கலை தீர்க்கிறது. மேலும் CI/CD அமைப்புகளின் முதிர்வு ஏற்கனவே ஒரு கோப்பை எழுதும் மட்டத்தில் உள்ளது மற்றும் நாங்கள் செல்கிறோம் - டெவலப்பர்கள் அதை அவர்களே கையாள முடியும். பின்னர் நாம் எப்படி நமது சொந்த SRE ஐ உருவாக்கலாம் என்பதைப் பற்றி பேசத் தொடங்குகிறோம்.
SRE Google இல் இல்லை
சரி, சரி, டெலிவரி செய்துவிட்டோம், மூச்சை வெளியேற்றிவிட்டு, பழைய காலத்துக்குத் திரும்பலாம் என்று தோன்றுகிறது, நிர்வாகிகள் ப்ராசசர் லோடைப் பார்த்து, சிஸ்டங்களைச் சரிசெய்து, அமைதியாகவும் அமைதியாகவும் குவளைகளில் இருந்து புரியாத ஒன்றைப் பருகும்போது... நிறுத்துங்கள். இதனாலேயே எல்லாத்தையும் ஆரம்பிச்சோம் (அது பாவம்!). திடீரென்று, கூகிளின் அணுகுமுறையில், சிறந்த நடைமுறைகளை நாம் எளிதாகப் பின்பற்ற முடியும் என்று மாறிவிடும் - இது செயலியின் சுமை முக்கியமல்ல, நாங்கள் எவ்வளவு அடிக்கடி வட்டுகளை மாற்றுகிறோம், அல்லது கிளவுட்டில் செலவை மேம்படுத்துகிறோம் என்பது முக்கியமல்ல, ஆனால் வணிக அளவீடுகள் அதே மோசமானவை. எஸ்எல்எக்ஸ் அவர்களிடமிருந்து உள்கட்டமைப்பு நிர்வாகத்தை யாரும் அகற்றவில்லை, மேலும் அவர்கள் சம்பவங்களைத் தீர்க்க வேண்டும், அவ்வப்போது கடமையில் இருக்க வேண்டும், பொதுவாக வணிக செயல்முறைகளில் முதலிடம் வகிக்க வேண்டும். மேலும் நண்பர்களே, கொஞ்சம் கொஞ்சமாக நல்ல நிலையில் நிரலாக்கத்தை தொடங்குங்கள், கூகுள் உங்களுக்காக ஏற்கனவே காத்திருக்கிறது.
சுருக்க. திடீரென்று, ஆனால் நீங்கள் ஏற்கனவே படித்து சோர்வாகிவிட்டீர்கள், கட்டுரையில் ஒரு கருத்தில் ஆசிரியருக்கு துப்புவதற்கும் எழுதுவதற்கும் நீங்கள் காத்திருக்க முடியாது. டெலிவரி நடைமுறையாக DevOps எப்போதும் இருந்து வருகிறது. மேலும் அது எங்கும் செல்லாது. செயல்பாட்டு நடைமுறைகளின் தொகுப்பாக SRE இந்த விநியோகத்தை மிகவும் வெற்றிகரமாக செய்கிறது.
ஆதாரம்: www.habr.com