SRE (தள நம்பகத்தன்மை பொறியியல்) என்பது வலைத் திட்டங்களின் கிடைக்கும் தன்மையை உறுதி செய்வதற்கான அணுகுமுறையாகும். இது DevOps க்கான கட்டமைப்பாகக் கருதப்படுகிறது மற்றும் DevOps நடைமுறைகளைப் பயன்படுத்துவதில் வெற்றியை எவ்வாறு அடைவது என்பது பற்றி பேசுகிறது. இந்த கட்டுரையில் மொழிபெயர்ப்பு பாடம் 4 சேவை நிலை நோக்கங்கள் புத்தகங்கள் தளத்தின் நம்பகத்தன்மை பொறியியல் Google இலிருந்து. இந்த மொழிபெயர்ப்பை நானே தயார் செய்து, கண்காணிப்பு செயல்முறைகளைப் புரிந்து கொள்வதில் எனது சொந்த அனுபவத்தை நம்பியிருந்தேன். டெலிகிராம் சேனலில் கண்காணிப்பு_அது и Habré இல் கடைசி இடுகை சேவை நிலை இலக்குகள் பற்றிய அதே புத்தகத்தின் 6 ஆம் அத்தியாயத்தின் மொழிபெயர்ப்பையும் வெளியிட்டேன்.

பூனையின் மொழிபெயர்ப்பு. படித்து மகிழுங்கள்!

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

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

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

சேவை நிலை சொற்கள்

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

குறிகாட்டிகள்

SLI என்பது சேவை நிலைக் குறிகாட்டியாகும் - வழங்கப்பட்ட சேவையின் மட்டத்தின் ஒரு அம்சத்தின் கவனமாக வரையறுக்கப்பட்ட அளவு அளவீடு.

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

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

SRE களுக்கு முக்கியமான மற்றொரு வகை SLI, கிடைக்கும் தன்மை அல்லது ஒரு சேவையைப் பயன்படுத்தக்கூடிய நேரத்தின் பகுதி. பெரும்பாலும் வெற்றிகரமான கோரிக்கைகளின் வீதமாக வரையறுக்கப்படுகிறது, சில சமயங்களில் மகசூல் என்று அழைக்கப்படுகிறது. (ஆயுட்காலம்-நீண்ட காலத்திற்கு தரவு தக்கவைக்கப்படும் வாய்ப்பு-தரவு சேமிப்பக அமைப்புகளுக்கும் முக்கியமானது.) 100% கிடைப்பது சாத்தியமில்லை என்றாலும், 100%க்கு அருகில் கிடைப்பது பெரும்பாலும் அடையக்கூடியது; கிடைக்கும் மதிப்புகள் இவ்வாறு வெளிப்படுத்தப்படுகின்றன. "ஒன்பதுகளின்" எண்ணிக்கை » கிடைக்கும் சதவீதம். எடுத்துக்காட்டாக, 99% மற்றும் 99,999% கிடைப்பது "2 நைன்ஸ்" மற்றும் "5 நைன்ஸ்" என லேபிளிடப்படலாம். கூகுள் கம்ப்யூட் இன்ஜினின் தற்போதைய கிடைக்கும் இலக்கு "மூன்றரை ஒன்பதுகள்" அல்லது 99,95% ஆகும்.

இலக்குகளை

ஒரு SLO என்பது ஒரு சேவை நிலை நோக்கம்: SLI ஆல் அளவிடப்படும் சேவை நிலைக்கான இலக்கு மதிப்பு அல்லது மதிப்புகளின் வரம்பு. SLO க்கான இயல்பான மதிப்பு "SLI ≤ இலக்கு" அல்லது "குறைந்த வரம்பு ≤ SLI ≤ மேல் வரம்பு" ஆகும். எடுத்துக்காட்டாக, 100 மில்லி விநாடிகளுக்கும் குறைவான சராசரி தேடல் வினவல் தாமதத்திற்கு SLO ஐ அமைப்பதன் மூலம் ஷேக்ஸ்பியர் தேடல் முடிவுகளை "வேகமாக" வழங்குவோம் என்று நாங்கள் முடிவு செய்யலாம்.

சரியான SLO ஐத் தேர்ந்தெடுப்பது ஒரு சிக்கலான செயல்முறையாகும். முதலில், நீங்கள் எப்போதும் ஒரு குறிப்பிட்ட மதிப்பைத் தேர்ந்தெடுக்க முடியாது. உங்கள் சேவைக்கான வெளிப்புற உள்வரும் HTTP கோரிக்கைகளுக்கு, வினாடிக்கான வினவல் (QPS) மெட்ரிக் முதன்மையாக உங்கள் சேவையைப் பார்வையிட உங்கள் பயனர்களின் விருப்பத்தால் தீர்மானிக்கப்படுகிறது, மேலும் அதற்கான SLO ஐ அமைக்க முடியாது.

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

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

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

ஒப்பந்தங்கள்

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

SRE பொதுவாக SLA களை உருவாக்குவதில் ஈடுபடுவதில்லை, ஏனெனில் SLAக்கள் வணிகம் மற்றும் தயாரிப்பு முடிவுகளுடன் நெருக்கமாக இணைக்கப்பட்டுள்ளன. இருப்பினும், SRE தோல்வியுற்ற SLO களின் விளைவுகளைத் தணிக்க உதவுவதில் ஈடுபட்டுள்ளது. அவர்கள் SLI ஐ தீர்மானிக்க உதவலாம்: வெளிப்படையாக, ஒப்பந்தத்தில் SLO ஐ அளவிட ஒரு புறநிலை வழி இருக்க வேண்டும் அல்லது கருத்து வேறுபாடு இருக்கும்.

Google தேடல் என்பது பொது SLA இல்லாத ஒரு முக்கியமான சேவையின் ஒரு எடுத்துக்காட்டு: எல்லோரும் தேடலை முடிந்தவரை திறமையாகப் பயன்படுத்த வேண்டும் என்று நாங்கள் விரும்புகிறோம், ஆனால் நாங்கள் உலகத்துடன் ஒப்பந்தத்தில் கையெழுத்திடவில்லை. இருப்பினும், தேடல் கிடைக்கவில்லை என்றால் பின்விளைவுகள் இன்னும் இருக்கும் - கிடைக்காததன் விளைவாக எங்கள் நற்பெயரில் வீழ்ச்சி மற்றும் விளம்பர வருவாய் குறைகிறது. Google for Work போன்ற பல Google சேவைகள் பயனர்களுடன் வெளிப்படையான சேவை நிலை ஒப்பந்தங்களைக் கொண்டுள்ளன. ஒரு குறிப்பிட்ட சேவையில் SLA உள்ளதா என்பதைப் பொருட்படுத்தாமல், SLI மற்றும் SLO ஐ வரையறுத்து, சேவையை நிர்வகிக்க அவற்றைப் பயன்படுத்துவது முக்கியம்.

இவ்வளவு கோட்பாடு - இப்போது அனுபவிக்க வேண்டும்.

நடைமுறையில் உள்ள குறிகாட்டிகள்

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

நீங்களும் உங்கள் பயனர்களும் எதைப் பற்றி கவலைப்படுகிறீர்கள்?

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

சேவைகளை பொதுவாக SLI இன் அடிப்படையில் பல பகுதிகளாகப் பிரிக்கலாம்:

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

குறிகாட்டிகளின் சேகரிப்பு

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

திரட்டுதல்

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

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

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

50, 85, 95, மற்றும் 99 சதவீத அமைப்பு தாமதம். Y அச்சு மடக்கை வடிவத்தில் உள்ளது.

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

புள்ளியியல் பிழைகள் பற்றிய குறிப்பு

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

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

குறிகாட்டிகளை தரப்படுத்தவும்

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

• ஒருங்கிணைப்பு இடைவெளிகள்: "சராசரியாக 1 நிமிடத்திற்கு மேல்"
• ஒருங்கிணைப்பு பகுதிகள்: "கிளஸ்டரில் உள்ள அனைத்து பணிகளும்"
• எவ்வளவு அடிக்கடி அளவீடுகள் எடுக்கப்படுகின்றன: "ஒவ்வொரு 10 வினாடிகளும்"
• என்ன கோரிக்கைகள் சேர்க்கப்பட்டுள்ளன: "கருப்பு பெட்டி கண்காணிப்பு வேலைகளில் இருந்து HTTP பெறவும்"
• தரவு எவ்வாறு பெறப்படுகிறது: "சர்வரில் அளவிடப்பட்ட எங்கள் கண்காணிப்புக்கு நன்றி"
• தரவு அணுகல் தாமதம்: "கடைசி பைட்டுக்கான நேரம்"

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

நடைமுறையில் உள்ள இலக்குகள்

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

இலக்குகளை வரையறுக்கவும்

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

• கெட் RPC அழைப்புகளில் 99% (சராசரியாக 1 நிமிடம்) 100msக்கும் குறைவான நேரத்தில் முடிவடையும் (அனைத்து பின்தள சேவையகங்களிலும் அளவிடப்படுகிறது).
• 99% Get RPC அழைப்புகள் 100msக்கும் குறைவான நேரத்தில் முடிவடையும்.

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

• 90% கெட் RPC அழைப்புகள் 1 ms க்கும் குறைவான நேரத்தில் முடிக்கப்படும்.
• 99% கெட் RPC அழைப்புகள் 10 ms க்கும் குறைவான நேரத்தில் முடிக்கப்படும்.
• 99.9% கெட் RPC அழைப்புகள் 100 ms க்கும் குறைவான நேரத்தில் முடிக்கப்படும்.

உங்கள் பயனர்கள் பன்முகப் பணிச்சுமைகளை உருவாக்கினால்: மொத்தச் செயலாக்கம் (இதற்கு செயல்திறன் முக்கியமானது) மற்றும் ஊடாடும் செயலாக்கம் (இதற்கு தாமதம் முக்கியமானது), ஒவ்வொரு சுமை வகுப்பிற்கும் தனித்தனி இலக்குகளை வரையறுப்பது பயனுள்ளது:

• 95% வாடிக்கையாளர் கோரிக்கைகளுக்கு செயல்திறன் தேவைப்படுகிறது. <1 வினாடிக்கு செயல்படுத்தப்பட்ட RPC அழைப்புகளின் எண்ணிக்கையை அமைக்கவும்.
• 99% வாடிக்கையாளர்கள் தாமதத்தைப் பற்றி கவலைப்படுகிறார்கள். ட்ராஃபிக் <1 KB மற்றும் <10 ms இயங்கும் RPC அழைப்புகளின் எண்ணிக்கையை அமைக்கவும்.

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

SLO மீறல்களின் சதவீதத்தை பிழை வரவு செலவுத் திட்டத்துடன் ஒப்பிடலாம் (பாடம் 3 மற்றும் பகுதியைப் பார்க்கவும் "பிழை பட்ஜெட்களுக்கான உந்துதல்"), புதிய வெளியீடுகளை எப்போது வரிசைப்படுத்துவது என்பதை தீர்மானிக்கும் செயல்பாட்டின் உள்ளீடாக பயன்படுத்தப்படும் வித்தியாச மதிப்பு.

இலக்கு மதிப்புகளைத் தேர்ந்தெடுப்பது

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

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

எளிமையாக இருங்கள்
சிக்கலான SLI கணக்கீடுகள் கணினி செயல்திறனில் ஏற்படும் மாற்றங்களை மறைத்து, சிக்கலின் காரணத்தைக் கண்டறிவதை கடினமாக்கும்.

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

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

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

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

உங்கள் அளவீடுகளைக் கட்டுப்படுத்தவும்

SLI மற்றும் SLO ஆகியவை அமைப்புகளை நிர்வகிக்கப் பயன்படும் முக்கிய கூறுகள்:

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

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

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

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

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

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

நடைமுறையில் உள்ள ஒப்பந்தங்கள்

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

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

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