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

மூல

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

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

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

"பிரச்சினையின் உருவாக்கம்"

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

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

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

பணி இரண்டு கூறுகளாக பிரிக்கப்பட்டுள்ளது:

• சோதனை கட்டத்தில் கூட்டங்களின் தரக் கட்டுப்பாடு (குறைந்த தரமான கூட்டங்களைப் பிடிக்கும் செயல்முறையை தானியக்கமாக்குவதற்கு);
• உற்பத்தி சூழலில் மென்பொருள் தரக் கட்டுப்பாடு (சிக்கல்களைத் தானாகக் கண்டறிவதற்கான வழிமுறைகள் மற்றும் அவற்றின் சுய-குணப்படுத்தலுக்கான சாத்தியமான காட்சிகள்).

அளவீடுகளைக் கண்காணித்து சேகரிப்பதற்கான கருவி

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

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

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

மூல. கணினி கூறுகளுக்கு இடையே உள்ள அனைத்து சார்புகளின் தானியங்கி கட்டுமானம்

மூல. சேவை செயல்பாட்டு பாதையின் தானியங்கி கண்டறிதல் மற்றும் கட்டுமானம்

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

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

பணி 1. சோதனை கட்டத்தில் கூட்டங்களின் தரக் கட்டுப்பாட்டின் ஆட்டோமேஷன்

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

இதை எவ்வாறு செயல்படுத்துவது மற்றும் இந்த செயல்முறையை தானியக்கமாக்குவது எப்படி என்பதை படிப்படியாகப் பார்ப்போம்:

மூல

தானியங்கி மென்பொருள் தர சோதனை படிகளின் ஓட்டத்தை படம் காட்டுகிறது:

1. ஒரு கண்காணிப்பு அமைப்பின் வரிசைப்படுத்தல் (முகவர்களின் நிறுவல்);
2. உங்கள் மென்பொருளின் தரத்தை மதிப்பிடுவதற்கான நிகழ்வுகளைக் கண்டறிதல் (அளவீடுகள் மற்றும் வரம்பு மதிப்புகள்) மற்றும் அவற்றை கண்காணிப்பு அமைப்புக்கு மாற்றுதல்;
3. சுமை மற்றும் செயல்திறன் சோதனைகளின் தலைமுறை;
4. கண்காணிப்பு அமைப்பில் செயல்திறன் மற்றும் கிடைக்கும் தரவுகளை சேகரித்தல்;
5. மென்பொருள் தர மதிப்பீட்டு நிகழ்வுகளின் அடிப்படையில் சோதனைத் தரவை கண்காணிப்பு அமைப்பிலிருந்து CI/CD அமைப்புக்கு மாற்றுதல். கூட்டங்களின் தானியங்கி பகுப்பாய்வு.

படி 1. கண்காணிப்பு அமைப்பின் வரிசைப்படுத்தல்

முதலில் உங்கள் சோதனைச் சூழலில் முகவர்களை நிறுவ வேண்டும். அதே நேரத்தில், Dynatrace தீர்வு ஒரு நல்ல அம்சத்தைக் கொண்டுள்ளது - இது உலகளாவிய முகவர் OneAgent ஐப் பயன்படுத்துகிறது, இது OS நிகழ்வில் (Windows, Linux, AIX) நிறுவப்பட்டுள்ளது, தானாகவே உங்கள் சேவைகளைக் கண்டறிந்து அவற்றில் கண்காணிப்புத் தரவைச் சேகரிக்கத் தொடங்குகிறது. ஒவ்வொரு செயல்முறைக்கும் நீங்கள் ஒரு தனி முகவரை உள்ளமைக்க வேண்டியதில்லை. கிளவுட் மற்றும் கன்டெய்னர் பிளாட்ஃபார்ம்களுக்கும் இதே நிலைதான் இருக்கும். அதே நேரத்தில், நீங்கள் முகவர் நிறுவல் செயல்முறையை தானியங்குபடுத்தலாம். டைனட்ரேஸ் "உள்கட்டமைப்பைக் குறியீடாக" கருத்துடன் முழுமையாகப் பொருந்துகிறது (குறியீடு அல்லது IaC ஆக உள்கட்டமைப்பு): அனைத்து பிரபலமான தளங்களுக்கும் ஆயத்த ஸ்கிரிப்டுகள் மற்றும் வழிமுறைகள் உள்ளன. உங்கள் சேவையின் உள்ளமைவில் முகவரை உட்பொதித்து, அதை பயன்படுத்தும்போது, ​​ஏற்கனவே பணிபுரியும் முகவருடன் உடனடியாக புதிய சேவையைப் பெறுவீர்கள்.

படி 2: உங்கள் மென்பொருள் தர நிகழ்வுகளை வரையறுக்கவும்

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

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

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

அத்தகைய JSON கோப்பின் உதாரணத்தைப் பார்ப்போம். Dynatrace API இலிருந்து வரும் பொருள்கள் முக்கிய/மதிப்பு ஜோடிகளாகப் பயன்படுத்தப்படுகின்றன (API விவரத்தை இங்கே காணலாம் Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

கோப்பு என்பது நேரத் தொடர் வரையறைகளின் வரிசை:

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

பின்வரும் படம் அத்தகைய வரம்புகளைப் பயன்படுத்துவதற்கான உதாரணத்தைக் காட்டுகிறது.

மூல

படி 3: சுமை உருவாக்கம்

எங்கள் சேவையின் தர நிலைகளை நாங்கள் தீர்மானித்தவுடன், சோதனைச் சுமையை உருவாக்க வேண்டும். Jmeter, Selenium, Neotys, Gatling போன்ற உங்களுக்கு வசதியான எந்த சோதனைக் கருவிகளையும் நீங்கள் பயன்படுத்தலாம்.

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

கூடுதல் தலைப்பு X-Dynatrace-Test ஐப் பயன்படுத்தி, வண்டியில் ஒரு பொருளைச் சேர்ப்பதற்கான செயல்பாட்டைச் சோதிப்பதில் இந்தச் சோதனை தொடர்புடையது என்பதை பின்வரும் படம் எடுத்துக்காட்டுகிறது.

மூல

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

மூல. சுமை சோதனையின் தொடக்கத்தைப் பற்றிய கண்காணிப்பு அமைப்பில் நிகழ்வு

படி 4-5. செயல்திறன் தரவைச் சேகரித்து, CI/CD அமைப்புக்கு தரவை மாற்றவும்

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

கண்காணிப்பு அமைப்புக்கு அனுப்ப CI/CD சர்வரில் உருவாக்கப்பட்ட மென்பொருளின் தரத்தை சரிபார்க்க வேண்டிய அவசியம் பற்றிய நிகழ்வு

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

கட்டுமானத் தரச் சரிபார்ப்பின் தொடக்கத்தைப் பற்றிய கண்காணிப்பு அமைப்பில் நிகழ்வு. மூல

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

CI/CD சர்வரில் உள்ள அசெம்பிளிகளின் புள்ளிவிவரங்களின் முடிவு. மூல

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

CI/CD சர்வரில் அசெம்பிளிகள் பற்றிய விரிவான புள்ளிவிவரங்களைக் காண்க. மூல

இரண்டு கூட்டங்களின் விரிவான ஒப்பீடு

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

Dynatrace இல் உருவாக்க புள்ளிவிவரங்களின் ஒப்பீடு. மூல
 
கண்டுபிடிப்புகள்

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

பணி 2. உற்பத்தி சூழலில் மென்பொருள் தரக் கட்டுப்பாட்டின் தானியங்கு

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

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

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

குறியீடாக தானாகத் திருத்தம்

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

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

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

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

நீங்கள் எந்த அமைப்பு அல்லது அமைப்புகளின் தொகுப்பையும் பயன்படுத்தலாம்: Prometheus, ELK Stack, Zabbix போன்றவை. ஆனால் APM தீர்வின் அடிப்படையில் சில உதாரணங்களை தருகிறேன் (Dynatrace மீண்டும் ஒரு உதாரணம்) இது உங்கள் வாழ்க்கையை எளிதாக்க உதவும்.

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

• பயனர் நிலை (உலாவிகள், மொபைல் பயன்பாடுகள், IoT சாதனங்கள், பயனர் நடத்தை, மாற்றம் போன்றவை);
• சேவை மற்றும் செயல்பாடுகளின் நிலை (செயல்திறன், கிடைக்கும் தன்மை, பிழைகள் போன்றவை);
• பயன்பாட்டு உள்கட்டமைப்பு நிலை (புரவலன் OS அளவீடுகள், JMX, MQ, இணைய சேவையகம் போன்றவை);
• இயங்குதள நிலை (மெய்நிகராக்கம், மேகம், கொள்கலன் போன்றவை).

Dynatrace இல் கண்காணிப்பு நிலைகள். மூல

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

அன்சிபிலுடன் தொடர்புகொள்வதற்கான எடுத்துக்காட்டு கீழே உள்ளது.

மூல

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

1. மோசமான வரிசைப்படுத்தல் - பதிப்பு திரும்பப் பெறுதல்

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

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

வரிசைப்படுத்தப்பட்ட பிறகு செயல்பாடுகளின் செயல்திறன் குறைதல். மூல

2. 100% வளத்தை ஏற்றுதல் - ரூட்டிங்கில் ஒரு முனையைச் சேர்க்கவும்

பின்வரும் எடுத்துக்காட்டில், ஒரு கூறு 100% CPU சுமையை அனுபவிப்பதாக கண்காணிப்பு அமைப்பு தீர்மானிக்கிறது.

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

ஒரு சம்பவத்திற்குப் பிறகு அளவிடுதல்

3. வன்வட்டில் இடமின்மை - வட்டு சுத்தம்

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

வட்டு ஏற்றம் 100%
 
4. குறைந்த பயனர் செயல்பாடு அல்லது குறைந்த மாற்றம் - நீலம் மற்றும் பச்சை கிளைகளுக்கு இடையில் மாறுதல்

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

மென்பொருள் கிளைகளுக்கு இடையில் மாறிய பிறகு மாற்று விகிதம் குறைகிறது. மூல

தானாக சிக்கலை கண்டறிவதற்கான வழிமுறைகள்

இறுதியாக, நான் ஏன் டைனட்ரேஸை மிகவும் விரும்புகிறேன் என்பதற்கு இன்னும் ஒரு உதாரணம் தருகிறேன்.

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

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

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

தோல்விக்கான மூல காரணத்தை தீர்மானிப்பதற்கான எடுத்துக்காட்டு. மூல

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

அனைத்து கூறுகள் மற்றும் நிகழ்வுகளின் காட்சியுடன் எழும் பிரச்சனையின் காட்சிப்படுத்தல்

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

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

முடிவுக்கு

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

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

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

மூல

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