தயாரிப்பு மீதான சோதனை: கேனரி வரிசைப்படுத்தல்

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

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

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

Infobip பற்றி

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

Infobip IT உள்கட்டமைப்பு எண்களில்:

• உலகம் முழுவதும் 15 தரவு மையங்கள்;
• செயல்பாட்டில் 500 தனிப்பட்ட சேவைகள்;
• 2500 சேவை நிகழ்வுகள், இது கட்டளைகளை விட அதிகம்;
• 4,5 TB மாதாந்திர போக்குவரத்து;
• 4,5 பில்லியன் தொலைபேசி எண்கள்;

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

வெளியிடுகிறது

ஒரு வழக்கமான வெளியீடு இப்படி செல்கிறது. எடுத்துக்காட்டாக, A, B, C, D மற்றும் E சேவைகள் உள்ளன, அவை ஒவ்வொன்றும் ஒரு தனி குழுவால் உருவாக்கப்படுகின்றன.

ஒரு கட்டத்தில், சேவைக் குழு A புதிய பதிப்பைப் பயன்படுத்த முடிவு செய்கிறது, ஆனால் B, C, D மற்றும் E ஆகிய சேவைக் குழுக்களுக்கு இது பற்றித் தெரியாது. சேவை குழு A என்ன செய்யும் என்பதற்கு இரண்டு விருப்பங்கள் உள்ளன.

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

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

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

எனவே நமக்கு என்ன வேண்டும்?

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

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

வரிசைப்படுத்தல் சிக்கல்கள்

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

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

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

தரவு மையங்களை மேடையில் பிரதிபலிக்க முடியாது. ஒரு தரவு மையத்தில் 200 ரேக்குகள் உள்ளன - இதை சாண்ட்பாக்ஸில் மீண்டும் செய்வது கூட சாத்தியமில்லை.

வேலையில்லா நேரங்கள்ஏற்றுக்கொள்ள முடியாதது! நாம் 99,99% நேரம் வேலை செய்யும் போது, ​​எங்களிடம் ஏற்றுக்கொள்ளக்கூடிய அளவு கிடைக்கும் (பிழை பட்ஜெட்), எடுத்துக்காட்டாக, மீதமுள்ள சதவீதம் "பிழைக்கான உரிமை" ஆகும். 100% நம்பகத்தன்மையை அடைவது சாத்தியமில்லை, ஆனால் செயலிழப்புகள் மற்றும் வேலையில்லா நேரத்தை தொடர்ந்து கண்காணிப்பது முக்கியம்.

கிளாசிக் தீர்வுகள்

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

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

மேடையில் சோதனை. Infobip இல் நான் பணியாற்றிய 3,5 வருடங்களில், மேடையின் நிலை, தயாரிப்புடன் ஓரளவு ஒத்துப்போவதை நான் பார்த்ததில்லை.

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

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

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

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

புகை சோதனைகள்

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

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

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

புகை பரிசோதனையின் தீமைகள்:

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

இங்கே ஒரே போனஸ் நீங்கள் செயல்திறனை சரிபார்க்கலாம்.

கேனரி வெளியிடுகிறது

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

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

செயல்படுத்தல் மற்றும் நுணுக்கங்கள்

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

வரிசைப்படுத்தல் இப்படிச் செல்கிறது: பேலன்சரின் (1) கீழ் இருந்து ஒரு முனையை அகற்றி, பதிப்பை (2) மாற்றி, தனித்தனியாக சில ட்ராஃபிக்கை அனுமதிக்கிறோம் (3).

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

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

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

இரண்டாவது சேவை முதல் சேவையகமாக செயல்படுகிறது. முதலாவது சர்வீஸ் டிஸ்கவரியிடம் அதன் சேவையகங்களைப் பற்றிய தகவலைக் கேட்கிறது, அது அதைப் பெறும்போது, ​​அவற்றைத் தேடிச் சரிபார்க்கிறது (“சுகாதார சோதனை”). அவர் சரிபார்க்கும்போது, ​​அவர் அவர்களுக்கு செய்திகளை அனுப்புவார்.

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

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

இதையெல்லாம் செயல்படுத்த, நமக்குத் தேவை:

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

சமநிலைப்படுத்துதல்

இதைத்தான் நாம் முதலில் சிந்திக்க வேண்டும். இரண்டு சமநிலை உத்திகள் உள்ளன.

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

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

கண்காணிப்பு

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

எங்கள் சேவைகளிலிருந்து நாங்கள் சேகரிக்கும் அளவீடுகளின் எடுத்துக்காட்டுகள்.

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

மிகவும் பிரபலமான கண்காணிப்பு அமைப்புகளில் உள்ள அளவீடுகளின் எடுத்துக்காட்டுகள்.

எதிர். இது சில அதிகரிக்கும் மதிப்பு, எடுத்துக்காட்டாக, பிழைகளின் எண்ணிக்கை. இந்த அளவீட்டை இடைக்கணித்து வரைபடத்தைப் படிப்பது எளிது: நேற்று 2 பிழைகள் இருந்தன, இன்று 500 பிழைகள் உள்ளன, அதாவது ஏதோ தவறாகிவிட்டது.

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

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

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

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

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

கருவிகள்

ELK ஸ்டாக். Elasticsearch ஐப் பயன்படுத்தி நீங்கள் ஒரு கேனரியை செயல்படுத்தலாம் - நிகழ்வுகள் நிகழும்போது அதில் பிழைகளை பதிவு செய்கிறோம். எளிய API அழைப்பின் மூலம் நீங்கள் எந்த நேரத்திலும் பிழைகளின் எண்ணிக்கையைப் பெறலாம் மற்றும் அவற்றை முந்தைய காலகட்டங்களுடன் ஒப்பிடலாம்: GET /applg/_cunt?q=level:errr.

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

நாம் பயன்படுத்தலாம் level, instance, service, ஒரு அமைப்பில் அவற்றை இணைக்கவும். உதவியுடன் offset உதாரணமாக, ஒரு வாரத்திற்கு முன்பு ஒரு மதிப்பின் மதிப்பை ஒரே ஒரு கட்டளையுடன் பார்க்கலாம் GET /api/v1/query?query={query}அங்கு {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

பதிப்பு பகுப்பாய்வு

பதிப்பு பகுப்பாய்வுக்கு பல உத்திகள் உள்ளன.

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

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

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

ஆட்டோமேஷன்

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

• ஆரம்பிக்கலாம்;
• பேலன்சரின் கீழ் இருந்து முனையை அகற்றவும்;
• ஒரு கேனரி முனையை நிறுவவும்;
• குறைந்த அளவிலான போக்குவரத்துடன் பேலன்சரை இயக்குகிறோம்;
• ஒப்பிடுவோம்.

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

இது க்ரூவிக்கு ஒரு குழாய்.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

இங்கே வளையத்தில் ஒரு மணி நேரத்திற்குள் புதிய முனையை ஒப்பிடுவோம் என்று அமைத்துள்ளோம். கேனரி செயல்முறை இன்னும் செயல்முறையை முடிக்கவில்லை என்றால், செயல்பாட்டை அழைக்கவும். எல்லாம் நன்றாக இருக்கிறதா இல்லையா என்பதை அவள் தெரிவிக்கிறாள்: def isOk = compare(srv, canary, time, base, offset, metrics).

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

மெட்ரிக் விளக்கம். செயல்பாடு எப்படி இருக்கும் என்று பார்ப்போம் compare உதாரணமாக DSL ஐப் பயன்படுத்துகிறது.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

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

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

இதெல்லாம் ஏன் தேவை?

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

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

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

தடைகள்

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

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

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

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

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

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

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

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

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

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

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

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