குறியீட்டாக உள்கட்டமைப்பு: XP ஐப் பயன்படுத்தி சிக்கல்களை எவ்வாறு சமாளிப்பது

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

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

நாம் யார், நாம் எங்கே இருக்கிறோம், என்ன பிரச்சனைகள் உள்ளன

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

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

எங்கள் IaC இல் நாம் பயன்படுத்தும் தொழில்நுட்ப அடுக்கு.

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

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

பின்வரும் IaC சிக்கல்களுடன் நாங்கள் தற்போது போராடி வருகிறோம்:

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

எக்ஸ்ட்ரீம் புரோகிராமிங் (எக்ஸ்பி) மீட்புக்கு

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

உங்கள் தொழில்துறைக்கு XP அணுகுமுறையின் பொருந்தக்கூடிய தன்மையை சரிபார்க்கிறதுஎக்ஸ்பி மிகவும் பொருத்தமான சூழல் மற்றும் அது எங்களுடன் எவ்வாறு தொடர்புடையது என்பது பற்றிய விளக்கம் இங்கே:

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

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

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

சில எக்ஸ்பி நடைமுறைகள் மற்றும் அவை பின்னூட்டத்தின் வேகம் மற்றும் தரத்தை எவ்வாறு பாதிக்கின்றன என்பதைப் பார்ப்போம்.

XP பின்னூட்டக் கொள்கை

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

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

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

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

விரக்தியின் படுகுழியில் இருந்து உங்களை எவ்வாறு வெளியேற்றுவது: மூன்று நடைமுறைகள்

சோதனைகள்

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

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

ஒரு உன்னதமான சோதனை பிரமிடு உள்ளது, இது அதிக சோதனைகள் இருக்க வேண்டும் என்பதைக் காட்டுகிறது.

IaC திட்டத்தில் இந்த கட்டமைப்பு நமக்கு எவ்வாறு பொருந்தும்? உண்மையில்... இல்லை.

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

  ஒருங்கிணைப்பு சோதனைகள் இப்படித்தான் இருக்கும்.

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

  பட சரிபார்ப்பு அல்காரிதம்

  1. பேக்கர் முதலில் படத்தை முழுமையாக தயார் செய்ய வேண்டும்.
  2. சோதனைக்கு அடுத்ததாக ஒரு உள்ளூர் மாநிலத்துடன் ஒரு டெர்ராஃபார்ம் உள்ளது, இந்த படத்தை வரிசைப்படுத்த நாங்கள் பயன்படுத்துகிறோம்.
  3. விரிக்கும்போது, ​​படத்துடன் வேலை செய்வதை எளிதாக்குவதற்கு அருகில் இருக்கும் ஒரு சிறிய தொகுதி பயன்படுத்தப்படுகிறது.
  4. படத்திலிருந்து VM பயன்படுத்தப்பட்டதும், சோதனைகள் தொடங்கும். அடிப்படையில், காசோலைகள் கார் மூலம் மேற்கொள்ளப்படுகின்றன. தொடக்கத்தில் ஸ்கிரிப்ட்கள் எவ்வாறு செயல்படுகின்றன மற்றும் டெமான்கள் எவ்வாறு செயல்படுகின்றன என்பதை இது சரிபார்க்கிறது. இதைச் செய்ய, ssh அல்லது winrm வழியாக புதிதாக உயர்த்தப்பட்ட கணினியில் உள்நுழைந்து, உள்ளமைவு நிலையை அல்லது சேவைகள் செயல்படுகின்றனவா என்பதைச் சரிபார்க்கவும்.

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

  
  
  பைப்லைன் பற்றிய கருத்து சுமார் 40 நிமிடங்கள் ஆகும். எல்லாம் மிக நீண்ட காலமாக நடக்கும். இது பின்னடைவுக்குப் பயன்படுத்தப்படலாம், ஆனால் புதிய வளர்ச்சிக்கு இது பொதுவாக நம்பத்தகாதது. இதற்கு நீங்கள் மிகவும் தயாராக இருந்தால், இயங்கும் ஸ்கிரிப்ட்களை தயார் செய்யுங்கள், பிறகு அதை 10 நிமிடங்களாக குறைக்கலாம். ஆனால் இவை இன்னும் 5 வினாடிகளில் 100 துண்டுகளை செய்யும் அலகு சோதனைகள் அல்ல.

படங்கள் அல்லது டெர்ராஃபார்ம் தொகுதிகளை அசெம்பிள் செய்யும் போது யூனிட் சோதனைகள் இல்லாதது, REST அல்லது பைதான் ஸ்கிரிப்ட்கள் வழியாக இயக்கக்கூடிய தனி சேவைகளுக்கு வேலையை மாற்றுவதை ஊக்குவிக்கிறது.

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

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

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

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

ஜோடி நிரலாக்கம்

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

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

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

கீழே ஜோடி நிரலாக்க பாணிகள் மற்றும் IaC இல் வேலை செய்வதில் அவற்றின் பொருந்தக்கூடிய தன்மை:

1. கிளாசிக், அனுபவம்+அனுபவம், டைமர் மூலம் மாற்றம். இரண்டு பாத்திரங்கள் - டிரைவர் மற்றும் நேவிகேட்டர். இருவர். அவர்கள் ஒரே குறியீட்டில் வேலை செய்கிறார்கள் மற்றும் ஒரு குறிப்பிட்ட காலத்திற்குப் பிறகு பாத்திரங்களை மாற்றுகிறார்கள்.

பாணியுடன் எங்கள் சிக்கல்களின் பொருந்தக்கூடிய தன்மையைக் கருத்தில் கொள்வோம்:

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

IaC இல் இந்த பாணியைப் பயன்படுத்துவதில் முக்கிய சிக்கல் வேலையின் சீரற்ற வேகம். பாரம்பரிய மென்பொருள் மேம்பாட்டில், நீங்கள் மிகவும் சீரான இயக்கம் வேண்டும். நீங்கள் ஐந்து நிமிடங்கள் செலவழித்து N எழுதலாம். 10 நிமிடங்கள் செலவழித்து 2N, 15 நிமிடங்கள் - 3N என்று எழுதலாம். இங்கே நீங்கள் ஐந்து நிமிடங்கள் செலவழித்து N ஐ எழுதலாம், பின்னர் மற்றொரு 30 நிமிடங்கள் செலவழித்து N இல் பத்தில் ஒரு பங்கை எழுதலாம். இங்கே உங்களுக்கு எதுவும் தெரியாது, நீங்கள் சிக்கிக்கொண்டீர்கள், முட்டாள். விசாரணை நேரம் எடுக்கும் மற்றும் நிரலாக்கத்திலிருந்து திசைதிருப்பப்படுகிறது.

முடிவு: அதன் தூய வடிவத்தில் அது நமக்குப் பொருந்தாது.

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

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

முடிவு: ஐயோ, வேலையின் வேகம் IaC இல் ஒரு ஜோடி நிரலாக்க நடைமுறையாக பிங்-பாங்கைப் பயன்படுத்த அனுமதிக்காது.

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

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

முடிவு: இது சாத்தியமாக பயன்படுத்தப்படலாம், நாங்கள் முயற்சியை கைவிடவில்லை.

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

ஜோடி நிரலாக்கத்தைப் பயன்படுத்துவதற்கான பொதுவான முடிவுகள்:

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

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

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

திட்டமிடல் மற்றும் தொடர்பு

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

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

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

பணிகளின் காட்சி பார்வையின் நன்மைகள்:

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

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

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

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

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

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

சரிபார்ப்புப் பட்டியலைப் பயன்படுத்தி அறிக்கையை நடத்தலாம்.1. சூழலில் உள்ளிடவும். பணி எங்கிருந்து வந்தது, அது ஏன் அவசியம்?

2. பிரச்சனை முன்பு எப்படி தீர்க்கப்பட்டது? எடுத்துக்காட்டாக, பெரிய மவுஸ் கிளிக் தேவை, அல்லது எதையும் செய்ய இயலாது.

3. அதை எப்படி மேம்படுத்துகிறோம். எடுத்துக்காட்டாக: "பார், இப்போது ஸ்கிரிப்டோசிக் உள்ளது, இங்கே ரீட்மீ உள்ளது."

4. இது எவ்வாறு செயல்படுகிறது என்பதைக் காட்டு. சில பயனர் சூழ்நிலையை நேரடியாக செயல்படுத்துவது நல்லது. எனக்கு X வேண்டும், நான் Y செய்கிறேன், நான் Y (அல்லது Z) பார்க்கிறேன். எடுத்துக்காட்டாக, நான் NGINX ஐப் பயன்படுத்துகிறேன், url ஐப் புகைக்கிறேன், 200 ஓகே பெறுகிறேன். செயல் நீண்டதாக இருந்தால், அதை முன்கூட்டியே தயார் செய்து பின்னர் காட்டலாம். டெமோ உடையக்கூடியதாக இருந்தால், டெமோவுக்கு ஒரு மணி நேரத்திற்கு முன்பு அதை உடைக்காமல் இருப்பது நல்லது.

5. சிக்கல் எவ்வளவு வெற்றிகரமாக தீர்க்கப்பட்டது, என்ன சிரமங்கள் உள்ளன, என்ன முடிக்கப்படவில்லை, எதிர்காலத்தில் என்ன மேம்பாடுகள் சாத்தியமாகும் என்பதை விளக்குங்கள். உதாரணமாக, இப்போது CLI, பின்னர் CI இல் முழு ஆட்டோமேஷன் இருக்கும்.

ஒவ்வொரு பேச்சாளரும் அதை 5-10 நிமிடங்கள் வரை வைத்திருப்பது நல்லது. உங்கள் பேச்சு முக்கியத்துவம் வாய்ந்ததாகவும் அதிக நேரம் எடுக்கும் எனவும் இருந்தால், sre-டேக்ஓவர் சேனலில் இதை முன்கூட்டியே ஒருங்கிணைக்கவும்.

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

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

நீண்ட முடிவுகள் மற்றும் அடுத்து என்ன

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

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

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

OS இல் செல்வாக்கு செலுத்துவதற்கான உயர்-நிலை வழிகள் - திட்டமிடல் மற்றும் பணிகளுடன் பணிபுரிவது துல்லியமாக விளைவுகளை உருவாக்குகிறது: உயர்தர அறிவு பரிமாற்றம் மற்றும் மேம்படுத்தப்பட்ட வளர்ச்சி தரம்.

ஒரு வரியில் குறுகிய முடிவுகள்

• HR பயிற்சியாளர்கள் IaC இல் பணிபுரிகிறார்கள், ஆனால் குறைந்த செயல்திறனுடன்.
• வேலை செய்வதை பலப்படுத்துங்கள்.
• உங்கள் சொந்த ஈடுசெய்யும் வழிமுறைகள் மற்றும் நடைமுறைகளைக் கொண்டு வாருங்கள்.

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