வெபினாரில் மோசமான ஆடியோ இருப்பதால், அதை டிரான்ஸ்கிரிப்ட் செய்துள்ளோம்.
என் பெயர் மெட்வெடேவ் எட்வார்ட். இன்று நான் SRE என்றால் என்ன, SRE எப்படி தோன்றியது, SRE இன்ஜினியர்களுக்கு என்ன வேலை அளவுகோல்கள் உள்ளன, நம்பகத்தன்மை அளவுகோல்கள் பற்றி கொஞ்சம், அதன் கண்காணிப்பு பற்றி கொஞ்சம் பேசுவேன். நாங்கள் உச்சியில் நடப்போம், ஏனென்றால் நீங்கள் ஒரு மணி நேரத்தில் அதிகம் சொல்ல முடியாது, ஆனால் கூடுதல் மதிப்பாய்வுக்கான பொருட்களை நான் தருகிறேன், நாங்கள் அனைவரும் உங்களுக்காக காத்திருக்கிறோம் . ஜனவரி இறுதியில் மாஸ்கோவில்.
முதலில், SRE என்றால் என்ன - தள நம்பகத்தன்மை பொறியியல் பற்றி பேசலாம். அது எப்படி ஒரு தனி நிலையாக, ஒரு தனி திசையாக தோன்றியது. பாரம்பரிய வளர்ச்சி வட்டங்களில், Dev மற்றும் Ops இரண்டு முற்றிலும் வேறுபட்ட அணிகள், பொதுவாக இரண்டு முற்றிலும் வேறுபட்ட இலக்குகளுடன் இது தொடங்கியது. மேம்பாட்டுக் குழுவின் குறிக்கோள் புதிய அம்சங்களை வெளியிடுவதும் வணிகத்தின் தேவைகளைப் பூர்த்தி செய்வதும் ஆகும். ஓப்ஸ் குழுவின் குறிக்கோள் எல்லாம் செயல்படுவதையும், எதுவும் உடைக்கப்படாமல் இருப்பதையும் உறுதி செய்வதாகும். வெளிப்படையாக, இந்த இலக்குகள் ஒருவருக்கொருவர் நேரடியாக முரண்படுகின்றன: எல்லாம் வேலை செய்ய மற்றும் எதுவும் உடைக்கப்படாமல் இருக்க, புதிய அம்சங்களை முடிந்தவரை குறைவாக வெளியிடவும். இதன் காரணமாக, இப்போது DevOps என்று அழைக்கப்படும் முறையானது தீர்க்க முயற்சிக்கும் பல உள் முரண்பாடுகள் உள்ளன.
பிரச்சனை என்னவென்றால், DevOps பற்றிய தெளிவான வரையறை மற்றும் DevOps இன் தெளிவான செயலாக்கம் எங்களிடம் இல்லை. நான் 2 ஆண்டுகளுக்கு முன்பு யெகாடெரின்பர்க்கில் ஒரு மாநாட்டில் பேசினேன், இப்போது வரை DevOps பிரிவு "DevOps என்றால் என்ன" என்ற அறிக்கையுடன் தொடங்கியது. 2017 இல், டெவொப்ஸ் கிட்டத்தட்ட 10 வயதாகிறது, ஆனால் அது என்ன என்று நாங்கள் இன்னும் வாதிடுகிறோம். இது மிகவும் விசித்திரமான சூழ்நிலையாகும், இது சில ஆண்டுகளுக்கு முன்பு கூகிள் தீர்க்க முயற்சித்தது.
2016 இல், கூகுள் தள நம்பகத்தன்மை பொறியியல் என்ற புத்தகத்தை வெளியிட்டது. உண்மையில், இந்த புத்தகத்தில்தான் SRE இயக்கம் தொடங்கியது. SRE என்பது ஒரு குறிப்பிட்ட நிறுவனத்தில் DevOps முன்னுதாரணத்தின் ஒரு குறிப்பிட்ட செயலாக்கமாகும். அமைப்புகள் நம்பகத்தன்மையுடன் செயல்படுவதை உறுதிசெய்ய SRE பொறியாளர்கள் உறுதிபூண்டுள்ளனர். அவை பெரும்பாலும் டெவலப்பர்களிடமிருந்து வந்தவை, சில சமயங்களில் வலுவான வளர்ச்சி பின்னணி கொண்ட நிர்வாகிகள். கணினி நிர்வாகிகள் செய்ததை அவர்கள் செய்கிறார்கள், ஆனால் குறியீட்டின் அடிப்படையில் கணினியின் வளர்ச்சி மற்றும் அறிவின் வலுவான பின்னணி இந்த மக்கள் வழக்கமான நிர்வாகப் பணிகளில் ஈடுபடவில்லை, ஆனால் ஆட்டோமேஷனில் சாய்ந்துள்ளனர் என்பதற்கு வழிவகுக்கிறது.
SRE குழுக்களில் DevOps முன்னுதாரணமானது, கட்டமைப்பு சிக்கல்களை தீர்க்கும் SRE பொறியாளர்கள் இருப்பதால் செயல்படுத்தப்படுகிறது. இதோ, 8 வருடங்களாக மக்கள் பேசிக்கொண்டிருக்கும் அதே தொடர்பு Dev-க்கும் Ops-க்கும் இடையே உள்ளது. புதிதாக வருபவர்கள் SRE களாக மாறாமல் இருப்பதில் SRE இன் பங்கு ஒரு கட்டிடக் கலைஞரின் பங்கு போன்றது. தங்கள் வாழ்க்கையின் தொடக்கத்தில் உள்ளவர்களுக்கு இன்னும் எந்த அனுபவமும் இல்லை, தேவையான அறிவின் அகலம் இல்லை. ஏனெனில் SRE க்கு என்ன, எப்போது சரியாகத் தவறாகப் போகலாம் என்பது பற்றிய மிக நுட்பமான அறிவு தேவைப்படுகிறது. எனவே, இங்கே சில அனுபவம் தேவை, ஒரு விதியாக, நிறுவனத்திற்கு உள்ளேயும் வெளியேயும்.
SRE மற்றும் devops இடையே உள்ள வேறுபாடு விவரிக்கப்படுமா என்று அவர்கள் கேட்கிறார்கள். அவள் இப்போது விவரிக்கப்பட்டாள். நிறுவனத்தில் SRE இடம் பற்றி பேசலாம். இந்த உன்னதமான DevOps அணுகுமுறையைப் போலன்றி, Ops இன்னும் ஒரு தனித் துறையாக உள்ளது, SRE என்பது மேம்பாட்டுக் குழுவின் ஒரு பகுதியாகும். அவர்கள் தயாரிப்பு வளர்ச்சியில் ஈடுபட்டுள்ளனர். SRE என்பது ஒரு டெவலப்பரிடமிருந்து மற்றொருவருக்கு அனுப்பும் ஒரு அணுகுமுறை கூட உள்ளது. எடுத்துக்காட்டாக, UX வடிவமைப்பாளர்கள், டெவலப்பர்கள், சில சமயங்களில் தயாரிப்பு மேலாளர்கள் போன்றே குறியீடு மதிப்புரைகளில் அவர்கள் பங்கேற்கின்றனர். SRE கள் அதே மட்டத்தில் வேலை செய்கின்றன. நாங்கள் அவற்றை அங்கீகரிக்க வேண்டும், அவற்றை மதிப்பாய்வு செய்ய வேண்டும், எனவே ஒவ்வொரு வரிசைப்படுத்தலுக்கும் SRE கூறுகிறது: “சரி, இந்த வரிசைப்படுத்தல், இந்த தயாரிப்பு நம்பகத்தன்மையை எதிர்மறையாக பாதிக்காது. அது நடந்தால், சில ஏற்றுக்கொள்ளக்கூடிய வரம்புகளுக்குள். இதைப் பற்றியும் பேசுவோம்.
அதன்படி, குறியீட்டை மாற்ற SRE க்கு வீட்டோ உள்ளது. பொதுவாக, SRE தவறாக செயல்படுத்தப்பட்டால், இது ஒருவித சிறிய மோதலுக்கும் வழிவகுக்கிறது. தள நம்பகத்தன்மை பொறியியல் பற்றிய அதே புத்தகத்தில், பல பகுதிகள், ஒன்று கூட இல்லை, இந்த மோதல்களைத் தவிர்ப்பது எப்படி என்று கூறுகிறது.
SRE தகவல் பாதுகாப்புடன் எவ்வாறு தொடர்புடையது என்று அவர்கள் கேட்கிறார்கள். தகவல் பாதுகாப்பில் SRE நேரடியாக ஈடுபடவில்லை. அடிப்படையில், பெரிய நிறுவனங்களில், இது தனிநபர்கள், சோதனையாளர்கள், ஆய்வாளர்களால் செய்யப்படுகிறது. ஆனால் சில செயல்பாடுகள், சில பொறுப்புகள், பாதுகாப்பைப் பாதிக்கும் சில வரிசைப்படுத்தல்கள் ஆகியவை தயாரிப்பின் கிடைக்கும் தன்மையையும் பாதிக்கலாம் என்ற அர்த்தத்தில் SRE அவர்களுடன் தொடர்பு கொள்கிறது. எனவே, ஒட்டுமொத்தமாக SRE ஆனது ஆய்வாளர்கள் உட்பட பாதுகாப்பு குழுக்கள் உட்பட எந்தவொரு அணிகளுடனும் தொடர்பு கொண்டுள்ளது. எனவே, DevOps ஐ செயல்படுத்த முயற்சிக்கும்போது SRE கள் முக்கியமாக தேவைப்படுகின்றன, ஆனால் அதே நேரத்தில், டெவலப்பர்கள் மீதான சுமை மிகவும் அதிகமாகிறது. அதாவது, இப்போது அவர்களும் Ops க்கு பொறுப்பேற்க வேண்டும் என்ற உண்மையை மேம்பாட்டுக் குழுவால் இனி சமாளிக்க முடியாது. மற்றும் ஒரு தனி பாத்திரம் உள்ளது. இந்த பாத்திரம் பட்ஜெட்டில் திட்டமிடப்பட்டுள்ளது. சில நேரங்களில் இந்த பாத்திரம் அணியின் அளவில் அமைக்கப்பட்டுள்ளது, ஒரு தனி நபர் தோன்றுகிறார், சில சமயங்களில் டெவலப்பர்களில் ஒருவர் மாறுகிறார். அணியில் முதல் SRE இப்படித்தான் தோன்றுகிறது.
SRE ஆல் பாதிக்கப்படும் அமைப்பின் சிக்கலானது, செயல்பாட்டின் நம்பகத்தன்மையை பாதிக்கும் சிக்கலானது, அவசியமானது மற்றும் தற்செயலானது. புதிய தயாரிப்பு அம்சங்களுக்குத் தேவைப்படும் அளவிற்கு ஒரு பொருளின் சிக்கலான தன்மை அதிகரிக்கும் போது அவசியமான சிக்கலானது. சீரற்ற சிக்கலானது அமைப்பின் சிக்கலானது அதிகரிக்கும் போது, ஆனால் தயாரிப்பு அம்சம் மற்றும் வணிகத் தேவைகள் இதை நேரடியாகப் பாதிக்காது. டெவலப்பர் எங்காவது தவறு செய்துவிட்டார், அல்லது அல்காரிதம் உகந்ததாக இல்லை, அல்லது சிறப்புத் தேவை இல்லாமல் தயாரிப்பின் சிக்கலை அதிகரிக்கும் சில கூடுதல் ஆர்வங்கள் அறிமுகப்படுத்தப்பட்டுள்ளன. ஒரு நல்ல SRE எப்போதும் இந்த சூழ்நிலையை குறைக்க வேண்டும். அதாவது, தற்செயலாகச் சேர்ப்பதால் சிரமம் அதிகரிக்கும் எந்த உறுதிமொழியும், எந்த வரிசைப்படுத்தலும், எந்த இழுக்கும் கோரிக்கையும் தடுக்கப்பட வேண்டும்.
ஒரு பொறியாளரை, அதிக அறிவுள்ள ஒரு கணினி நிர்வாகியை அணியில் ஏன் நியமிக்கக்கூடாது என்பது கேள்வி. ஒரு பொறியாளரின் பாத்திரத்தில் ஒரு டெவலப்பர், சிறந்த பணியாளர் தீர்வு அல்ல என்று நாங்கள் கூறுகிறோம். ஒரு பொறியியலாளரின் பாத்திரத்தில் ஒரு டெவலப்பர் எப்போதும் சிறந்த பணியாளர் தீர்வு அல்ல, ஆனால் இங்கே புள்ளி என்னவென்றால், Ops இல் ஈடுபட்டுள்ள ஒரு டெவலப்பருக்கு ஆட்டோமேஷனில் இன்னும் கொஞ்சம் விருப்பம் உள்ளது, இன்னும் கொஞ்சம் அறிவு மற்றும் செயல்படுத்தும் திறன் உள்ளது. இந்த ஆட்டோமேஷன். அதற்கேற்ப, சில குறிப்பிட்ட செயல்பாடுகளுக்கான நேரத்தை மட்டும் குறைக்கிறோம், வழக்கமான நேரத்தை மட்டுமல்ல, MTTR (மீட்புக்கான சராசரி நேரம், மீட்பு நேரம்) போன்ற முக்கியமான வணிக அளவுருக்களையும் குறைக்கிறோம். எனவே, இதைப் பற்றி சிறிது நேரம் கழித்து பேசுவோம், நிறுவனத்திற்கு பணத்தை மிச்சப்படுத்துகிறோம்.
இப்போது SRE இன் செயல்பாட்டிற்கான அளவுகோல்களைப் பற்றி பேசலாம். மற்றும் முதலில் நம்பகத்தன்மை பற்றி. சிறிய நிறுவனங்கள், ஸ்டார்ட்அப்களில், சேவை நன்றாக எழுதப்பட்டால், தயாரிப்பு நன்றாகவும் சரியாகவும் எழுதப்பட்டால், அது வேலை செய்யும், அது உடைந்து போகாது என்று மக்கள் கருதுவது அடிக்கடி நிகழ்கிறது. அவ்வளவுதான், நல்ல குறியீடு எழுதுகிறோம், அதனால் உடைக்க எதுவும் இல்லை. குறியீடு மிகவும் எளிமையானது, உடைக்க எதுவும் இல்லை. எங்களுக்கு சோதனைகள் தேவையில்லை என்று கூறும் அதே நபர்களைப் பற்றியது இவை, ஏனென்றால், பாருங்கள், இவை மூன்று VPI முறைகள், ஏன் இங்கே உடைக்க வேண்டும்.
இது எல்லாம் தவறு, நிச்சயமாக. இந்த மக்கள் நடைமுறையில் இதுபோன்ற குறியீட்டால் அடிக்கடி கடிக்கப்படுகிறார்கள், ஏனென்றால் விஷயங்கள் உடைந்து போகின்றன. சில நேரங்களில் மிகவும் எதிர்பாராத வழிகளில் விஷயங்கள் உடைந்து விடுகின்றன. சில நேரங்களில் மக்கள் இல்லை, அது நடக்காது என்று கூறுகிறார்கள். அது எல்லா நேரத்திலும் நடக்கும். அடிக்கடி நடக்கும் போதும். அதனால்தான் 100% கிடைப்பதற்கு யாரும் பாடுபடுவதில்லை, ஏனென்றால் 100% கிடைப்பது ஒருபோதும் நடக்காது. இதுதான் நியதி. எனவே, ஒரு சேவையின் கிடைக்கும் தன்மையைப் பற்றி பேசும்போது, நாங்கள் எப்போதும் ஒன்பதுகளைப் பற்றி பேசுகிறோம். 2 ஒன்பது, 3 ஒன்பது, 4 ஒன்பது, 5 ஒன்பது. நாம் இதை வேலையில்லா நேரமாக மொழிபெயர்த்தால், எடுத்துக்காட்டாக, 5 ஒன்பதுகள், இது வருடத்திற்கு 5 நிமிடங்களுக்கு சற்று அதிகமாக இருக்கும், 2 ஒன்பதுகள் என்பது 3,5 நாட்கள் வேலையில்லா நேரமாகும்.
ஆனால் ஒரு கட்டத்தில் POI, முதலீட்டின் மீதான வருமானம் குறைவது வெளிப்படையானது. இரண்டு ஒன்பதுகளில் இருந்து மூன்று ஒன்பதுகளுக்குச் செல்வது என்பது 3 நாட்களுக்கு மேல் வேலையில்லா நேரத்தைக் குறைக்கும். நான்கு ஒன்பதுகளில் இருந்து ஐந்திற்கு செல்வது வேலையில்லா நேரத்தை வருடத்திற்கு 47 நிமிடங்கள் குறைக்கிறது. வணிகத்திற்கு இது முக்கியமானதாக இருக்காது என்று மாறிவிடும். பொதுவாக, தேவையான நம்பகத்தன்மை ஒரு தொழில்நுட்ப பிரச்சினை அல்ல, முதலில், இது ஒரு வணிக பிரச்சினை, இது ஒரு தயாரிப்பு பிரச்சினை. தயாரிப்பைப் பயன்படுத்துபவர்களுக்கு எந்த அளவிலான வேலையில்லா நேரம் ஏற்றுக்கொள்ளப்படுகிறது, அவர்கள் என்ன எதிர்பார்க்கிறார்கள், எவ்வளவு செலுத்துகிறார்கள், உதாரணமாக, எவ்வளவு பணத்தை இழக்கிறார்கள், கணினி எவ்வளவு பணத்தை இழக்கிறது.
மீதமுள்ள கூறுகளின் நம்பகத்தன்மை என்ன என்பது இங்கே ஒரு முக்கியமான கேள்வி. ஏனெனில் 4 நைன்கள் நம்பகத்தன்மை கொண்ட ஸ்மார்ட்போனில் 5 மற்றும் 2 நைன்களுக்கு இடையிலான வித்தியாசம் தெரியவில்லை. தோராயமாகச் சொன்னால், உங்கள் சேவையில் உள்ள ஸ்மார்ட்போனில் வருடத்திற்கு 10 முறை ஏதாவது உடைந்தால், OS பக்கத்தில் 8 மடங்கு முறிவு ஏற்பட்டிருக்கலாம். பயனர் இதற்குப் பழகிவிட்டார், மேலும் வருடத்திற்கு ஒரு முறை கவனம் செலுத்த மாட்டார். நம்பகத்தன்மையை அதிகரிப்பதற்கும் லாபத்தை அதிகரிப்பதற்கும் விலையை தொடர்புபடுத்துவது அவசியம்.
SRE பற்றிய புத்தகத்தில் 4 ஒன்பதுகளில் இருந்து 3 ஒன்பதுகளாக அதிகரிப்பதற்கான சிறந்த உதாரணம் உள்ளது. கிடைக்கும் அதிகரிப்பு 0,1% ஐ விட சற்று குறைவாக உள்ளது என்று மாறிவிடும். சேவையின் வருவாய் ஆண்டுக்கு $1 மில்லியன் என்றால், வருவாய் அதிகரிப்பு $900 ஆகும். மலிவு விலையை ஒன்பது ஆல் அதிகரிக்க, ஆண்டுக்கு $900க்கும் குறைவாக செலவாகும் என்றால், இந்த அதிகரிப்பு நிதி அர்த்தமுள்ளதாக இருக்கும். ஒரு வருடத்திற்கு 900 டாலர்களுக்கு மேல் செலவழித்தால், அது இனி அர்த்தமற்றது, ஏனென்றால் வருவாயின் அதிகரிப்பு வெறுமனே தொழிலாளர் செலவுகள், வள செலவுகளை ஈடுசெய்யாது. மேலும் 3 ஒன்பதுகள் எங்களுக்கு போதுமானதாக இருக்கும்.
அனைத்து கோரிக்கைகளும் சமமாக இருக்கும் எளிமையான உதாரணம் இது. 3 ஒன்பதுகளில் இருந்து 4 நைன்களுக்குச் செல்வது மிகவும் எளிதானது, ஆனால் அதே நேரத்தில், எடுத்துக்காட்டாக, 2 நைன்களில் இருந்து 3 வரை செல்வது, இது ஏற்கனவே 9 ஆயிரம் டாலர்கள் சேமிப்பாகும், இது நிதி அர்த்தமுள்ளதாக இருக்கும். இயற்கையாகவே, உண்மையில், பதிவு கோரிக்கையின் தோல்வி பக்கத்தைக் காண்பிக்கத் தவறியதை விட மோசமானது, கோரிக்கைகள் வெவ்வேறு எடைகளைக் கொண்டுள்ளன. வணிகக் கண்ணோட்டத்தில் அவர்கள் முற்றிலும் மாறுபட்ட அளவுகோல்களைக் கொண்டிருக்கலாம், ஆனால் எப்படியிருந்தாலும், ஒரு விதியாக, சில குறிப்பிட்ட சேவைகளைப் பற்றி நாங்கள் பேசவில்லை என்றால், இது மிகவும் நம்பகமான தோராயமாகும்.
சேவைக்கான கட்டடக்கலை தீர்வைத் தேர்ந்தெடுக்கும் போது SRE ஒருங்கிணைப்பாளர்களில் ஒருவரா என்ற கேள்வி எங்களுக்குக் கிடைத்தது. தற்போதுள்ள உள்கட்டமைப்பில் ஒருங்கிணைக்கப்படும் வகையில், அதன் நிலைத்தன்மையில் எந்த இழப்பும் ஏற்படாது. ஆம், SREகள், அதே வழியில் கோரிக்கைகளை இழுத்தல், உறுதி செய்தல், வெளியீடுகள் கட்டமைப்பை பாதிக்கிறது, புதிய சேவைகளின் அறிமுகம், மைக்ரோ சர்வீஸ்கள், புதிய தீர்வுகளை செயல்படுத்துதல். அனுபவம் வேண்டும், தகுதி வேண்டும் என்று ஏன் முன்பே சொன்னேன். உண்மையில், SRE என்பது எந்தவொரு கட்டடக்கலை மற்றும் மென்பொருள் தீர்வுகளிலும் தடுக்கும் குரல்களில் ஒன்றாகும். அதன்படி, ஒரு பொறியியலாளராக ஒரு SRE முதலில், சில குறிப்பிட்ட முடிவுகள் நம்பகத்தன்மை, ஸ்திரத்தன்மை ஆகியவற்றை எவ்வாறு பாதிக்கும் என்பதைப் புரிந்துகொள்வது மட்டுமல்லாமல், வணிகத் தேவைகளுடன் இது எவ்வாறு தொடர்புடையது என்பதைப் புரிந்து கொள்ள வேண்டும், மேலும் எந்தக் கண்ணோட்டத்தில் இது ஏற்றுக்கொள்ளத்தக்கது மற்றும் எது இல்லை.
எனவே, இப்போது நாம் நம்பகத்தன்மை அளவுகோல்களைப் பற்றி பேசலாம், அவை பாரம்பரியமாக SRE இல் SLA (சேவை நிலை ஒப்பந்தம்) என வரையறுக்கப்படுகின்றன. பெரும்பாலும் ஒரு பழக்கமான சொல். SLI (சேவை நிலை காட்டி). SLO (சேவை நிலை நோக்கம்). சேவை நிலை ஒப்பந்தம் என்பது ஒரு குறியீட்டுச் சொல்லாக இருக்கலாம், குறிப்பாக நீங்கள் நெட்வொர்க்குகளுடன், வழங்குநர்களுடன், ஹோஸ்டிங் மூலம் பணிபுரிந்திருந்தால். இது உங்கள் முழு சேவையின் செயல்திறன், அபராதங்கள், பிழைகளுக்கான சில அபராதங்கள், அளவீடுகள், அளவுகோல்கள் ஆகியவற்றை விவரிக்கும் பொதுவான ஒப்பந்தமாகும். மேலும் SLI என்பது கிடைக்கும் அளவீடு ஆகும். அதாவது, SLI என்னவாக இருக்கும்: சேவையிலிருந்து பதிலளிக்கும் நேரம், சதவீதமாக பிழைகளின் எண்ணிக்கை. இது ஒருவித கோப்பு ஹோஸ்டிங் என்றால் அது அலைவரிசையாக இருக்கலாம். அங்கீகாரம் அல்காரிதம்களுக்கு வரும்போது, குறிகாட்டியாக இருக்கலாம், எடுத்துக்காட்டாக, பதிலின் சரியான தன்மையும் கூட. SLO (சேவை நிலை நோக்கம்) முறையே, SLI காட்டி, அதன் மதிப்பு மற்றும் காலம் ஆகியவற்றின் கலவையாகும்.
SLA இப்படி இருக்கலாம் என்று வைத்துக் கொள்வோம். இந்த சேவை ஆண்டு முழுவதும் 99,95% நேரம் கிடைக்கும். அல்லது 99 முக்கியமான ஆதரவு டிக்கெட்டுகள் ஒரு காலாண்டிற்கு 3 மணி நேரத்திற்குள் மூடப்படும். அல்லது 85% வினவல்களுக்கு ஒவ்வொரு மாதமும் 1,5 வினாடிகளுக்குள் பதில் கிடைக்கும். அதாவது, பிழைகள் மற்றும் தோல்விகள் மிகவும் இயல்பானவை என்பதை நாம் படிப்படியாக புரிந்துகொள்கிறோம். இது ஏற்றுக்கொள்ளக்கூடிய சூழ்நிலை, நாங்கள் திட்டமிட்டு வருகிறோம், ஓரளவுக்கு கூட எண்ணிக் கொண்டிருக்கிறோம். அதாவது, SRE தவறுகளைச் செய்யக்கூடிய அமைப்புகளை உருவாக்குகிறது, இது பிழைகளுக்கு சாதாரணமாக பதிலளிக்க வேண்டும், அவற்றை கணக்கில் எடுத்துக்கொள்ள வேண்டும். முடிந்த போதெல்லாம், பயனர் அவற்றைக் கவனிக்காத அல்லது கவனிக்காத வகையில் பிழைகளைக் கையாள வேண்டும், ஆனால் சில வகையான தீர்வுகள் உள்ளன, இதற்கு நன்றி எல்லாம் முழுமையாக கீழே விழாது.
எடுத்துக்காட்டாக, நீங்கள் YouTube இல் ஒரு வீடியோவைப் பதிவேற்றினால், YouTube அதை உடனடியாக மாற்ற முடியாது, வீடியோ மிகப் பெரியதாக இருந்தால், வடிவம் உகந்ததாக இல்லாவிட்டால், கோரிக்கை இயல்பாகவே காலாவதியாகாது, YouTube 502 பிழையைக் கொடுக்காது. , YouTube கூறும்: “நாங்கள் அனைத்தையும் உருவாக்கியுள்ளோம், உங்கள் வீடியோ செயலாக்கப்படுகிறது. இன்னும் 10 நிமிடத்தில் தயாராகிவிடும்." நீங்கள் எப்போதாவது இதைச் செய்திருந்தால், எடுத்துக்காட்டாக, முன்-இறுதி வளர்ச்சியிலிருந்து இது நன்கு அறியப்பட்ட அழகிய சீரழிவின் கொள்கையாகும்.
நாம் பேசும் அடுத்த விதிமுறைகள், நம்பகத்தன்மையுடன், பிழைகளுடன், எதிர்பார்ப்புகளுடன் பணிபுரிய மிகவும் முக்கியமானவை, எம்டிபிஎஃப் மற்றும் எம்டிடிஆர். MTBF என்பது தோல்விகளுக்கு இடையிலான சராசரி நேரம். MTTR மீண்டிற்கான சராசரி நேரம், மீட்பதற்கான சராசரி நேரம். அதாவது, பிழை கண்டுபிடிக்கப்பட்ட தருணத்திலிருந்து, பிழை தோன்றிய தருணத்திலிருந்து சேவை முழு இயல்பான செயல்பாட்டிற்கு மீட்டமைக்கப்படும் தருணம் வரை எவ்வளவு நேரம் கடந்துவிட்டது. MTBF முக்கியமாக குறியீடு தரத்தில் வேலை செய்வதன் மூலம் சரி செய்யப்படுகிறது. அதாவது, SRE கள் "இல்லை" என்று சொல்லலாம். SRE "இல்லை" என்று கூறும்போது, அவர் தீங்கு விளைவிப்பவர் என்பதற்காக அல்ல, அவர் மோசமானவர் என்பதற்காக அல்ல, இல்லையெனில் எல்லோரும் பாதிக்கப்படுவார்கள் என்பதால் ஒட்டுமொத்த குழுவைப் பற்றிய புரிதல் உங்களுக்குத் தேவை.
மீண்டும், நான் அடிக்கடி குறிப்பிடும் புத்தகத்தில் கூட நிறைய கட்டுரைகள், நிறைய முறைகள், நிறைய வழிகள் உள்ளன, மற்ற டெவலப்பர்கள் SRE ஐ வெறுக்கத் தொடங்காமல் இருப்பதை எப்படி உறுதி செய்வது. MTTR, மறுபுறம், உங்கள் SLO களில் (சேவை நிலை நோக்கம்) வேலை செய்வதாகும். மேலும் இது பெரும்பாலும் ஆட்டோமேஷன். ஏனெனில், எடுத்துக்காட்டாக, எங்கள் SLO என்பது ஒரு காலாண்டிற்கு 4 ஒன்பதுகள் ஆகும். அதாவது 3 மாதங்களில் 13 நிமிட வேலையில்லா நேரத்தை அனுமதிக்கலாம். MTTR 13 நிமிடங்களுக்கு மேல் இருக்க முடியாது என்று மாறிவிடும். 13 நிமிடங்களில் குறைந்தபட்சம் 1 வேலையில்லா நேரத்துக்குப் பதிலளித்தால், காலாண்டிற்கான முழு பட்ஜெட்டையும் நாங்கள் ஏற்கனவே முடித்துவிட்டோம் என்று அர்த்தம். நாங்கள் SLO ஐ உடைக்கிறோம். செயலிழப்பைச் சரிசெய்வதற்கு 13 நிமிடங்கள் என்பது ஒரு இயந்திரத்திற்கு அதிகம், ஆனால் மனிதனுக்கு மிகக் குறைவு. ஏனென்றால், ஒரு நபர் விழிப்பூட்டலைப் பெறும் வரை, அவர் எதிர்வினையாற்றும் வரை, அவர் பிழையைப் புரிந்துகொள்ளும் வரை, அது ஏற்கனவே பல நிமிடங்கள் ஆகும். ஒரு நபர் அதை எவ்வாறு சரிசெய்வது, சரியாக என்ன சரிசெய்வது, என்ன செய்வது என்பதைப் புரிந்துகொள்ளும் வரை, இது இன்னும் சில நிமிடங்கள் ஆகும். உண்மையில், நீங்கள் சேவையகத்தை மறுதொடக்கம் செய்ய வேண்டியிருந்தாலும், அல்லது ஒரு புதிய முனையை உயர்த்தினால், கைமுறையாக MTTR ஏற்கனவே 7-8 நிமிடங்கள் ஆகும். செயல்முறையை தானியங்குபடுத்தும் போது, MTTR பெரும்பாலும் ஒரு வினாடி, சில நேரங்களில் மில்லி விநாடிகளை அடைகிறது. கூகிள் வழக்கமாக மில்லி விநாடிகளைப் பற்றி பேசுகிறது, ஆனால் உண்மையில், நிச்சயமாக, எல்லாம் நன்றாக இல்லை.
வெறுமனே, SRE அதன் வேலையை முழுவதுமாக தானியக்கமாக்க வேண்டும், ஏனெனில் இது MTTR, அதன் அளவீடுகள், முழு சேவையின் SLO மற்றும் அதற்கேற்ப வணிக லாபத்தையும் நேரடியாக பாதிக்கிறது. நேரம் மீறினால், SRE தவறு உள்ளதா என்று கேட்கப்படும். அதிர்ஷ்டவசமாக, யாரும் குற்றம் சொல்லவில்லை. இது balmeless postmortem என்று அழைக்கப்படும் ஒரு தனி கலாச்சாரம், இதைப் பற்றி இன்று நாம் பேச மாட்டோம், ஆனால் ஸ்லர்மில் அதை பகுப்பாய்வு செய்வோம். இது மிகவும் சுவாரஸ்யமான தலைப்பு, இது பற்றி நிறைய பேசலாம். தோராயமாகச் சொன்னால், ஒரு காலாண்டிற்கு ஒதுக்கப்பட்ட நேரத்தைத் தாண்டினால், எல்லாரையும் கொஞ்சம் குறை சொல்ல வேண்டும், அதாவது அனைவரையும் குற்றம் சாட்டுவது பலனளிக்காது, மாறாக, யாரையும் குறை சொல்லாமல், சூழ்நிலையை சரிசெய்து, நம்மிடம் இருப்பதைக் கொண்டு செயல்படுவோம். எனது அனுபவத்தில், இந்த அணுகுமுறை பெரும்பாலான அணிகளுக்கு சற்று அந்நியமானது, குறிப்பாக ரஷ்யாவில், ஆனால் இது அர்த்தமுள்ளதாக இருக்கிறது மற்றும் நன்றாக வேலை செய்கிறது. எனவே, இந்த தலைப்பில் நீங்கள் படிக்கக்கூடிய கட்டுரை மற்றும் இலக்கியத்தின் முடிவில் நான் பரிந்துரைக்கிறேன். அல்லது ஸ்லர்ம் SRE க்கு வாருங்கள்.
என்னை விவரிக்க விடு. காலாண்டுக்கான SLO நேரம் அதிகமாக இருந்தால், வேலையில்லா நேரம் 13 நிமிடங்கள் அல்ல, 15 ஆக இருந்தால், இதற்கு யார் காரணம்? நிச்சயமாக, SRE குற்றம் சாட்டப்படலாம், ஏனென்றால் அவர் ஒருவித மோசமான அர்ப்பணிப்பு அல்லது வரிசைப்படுத்தலை தெளிவாக செய்தார். டேட்டா சென்டரின் நிர்வாகி இதற்குக் காரணமாக இருக்கலாம், ஏனென்றால் அவர் திட்டமிடப்படாத சில பராமரிப்புகளை மேற்கொண்டிருக்கலாம். டேட்டா சென்டரின் நிர்வாகிதான் இதற்குக் காரணம் என்றால், SLOவை ஒருங்கிணைத்தபோது பராமரிப்பைக் கணக்கிடாத Ops-லிருந்து வந்தவர்தான் இதற்குக் காரணம். மேலாளர், தொழில்நுட்ப இயக்குநர் அல்லது தரவு மைய ஒப்பந்தத்தில் கையெழுத்திட்ட ஒருவர் மற்றும் தரவு மையத்தின் SLA தேவையான வேலையில்லா நேரத்திற்காக வடிவமைக்கப்படவில்லை என்பதில் கவனம் செலுத்தாத ஒருவர் இதற்குக் காரணம். அதன்படி, இந்த சூழ்நிலையில் கொஞ்சம் கொஞ்சமாக அனைவரும் குற்றம் சாட்டுகிறார்கள். இந்த நிலையில் யார் மீதும் பழி சுமத்துவதில் அர்த்தமில்லை என்பதும் இதன் பொருள். ஆனால் நிச்சயமாக அது சரி செய்யப்பட வேண்டும். அதனால்தான் போஸ்ட்மார்ட்டம் இருக்கிறது. எடுத்துக்காட்டாக, கிட்ஹப் போஸ்ட்மார்ட்டம்களைப் படித்தால், ஒவ்வொரு விஷயத்திலும் இது எப்போதும் மிகவும் சுவாரஸ்யமான, சிறிய மற்றும் எதிர்பாராத கதையாக இருந்தால், இந்த குறிப்பிட்ட நபர் தான் காரணம் என்று யாரும் சொல்லவில்லை என்பதை நீங்கள் மாற்றலாம். குற்றம் எப்போதும் குறிப்பிட்ட அபூரண செயல்முறைகள் மீது வைக்கப்படுகிறது.
அடுத்த கேள்விக்கு செல்லலாம். ஆட்டோமேஷன். மற்ற சூழல்களில் ஆட்டோமேஷனைப் பற்றி நான் பேசும்போது, நீங்கள் சேமித்ததை விட, ஒரு பணியை தானியக்கமாக்குவதற்கு அதிக நேரத்தை எடுத்துக் கொள்ளாமல், எவ்வளவு காலம் தன்னியக்கமாக வேலை செய்ய முடியும் என்று உங்களுக்குச் சொல்லும் அட்டவணையை நான் அடிக்கடிப் பார்க்கிறேன். ஒரு சறுக்கல் உள்ளது. கேட்ச் என்னவெனில், SRE கள் ஒரு பணியை தானியக்கமாக்கும்போது, அவை நேரத்தை மிச்சப்படுத்துவது மட்டுமல்லாமல், பணத்தையும் மிச்சப்படுத்துகின்றன, ஏனெனில் ஆட்டோமேஷன் MTTR ஐ நேரடியாக பாதிக்கிறது. அவர்கள் பேசுவதற்கு, ஊழியர்கள் மற்றும் டெவலப்பர்களின் மன உறுதியை சேமிக்கிறார்கள், இது ஒரு தீர்ந்துபோகக்கூடிய வளமாகும். அவை வழக்கத்தை குறைக்கின்றன. இவை அனைத்தும் வேலையில் நேர்மறையான விளைவைக் கொண்டிருக்கின்றன, இதன் விளைவாக, வணிகத்தில், நேரச் செலவுகளின் அடிப்படையில் ஆட்டோமேஷன் அர்த்தமல்ல என்று தோன்றினாலும்.
உண்மையில், இது எப்பொழுதும் உள்ளது, மேலும் SRE இன் பாத்திரத்தில் ஏதாவது தானியங்குபடுத்தப்படக் கூடாத சில நிகழ்வுகள் உள்ளன. பிழை பட்ஜெட், பிழைகளுக்கான பட்ஜெட் என்று எதைப் பற்றி பேசுவோம். உண்மையில், உங்களுக்காக நீங்கள் அமைத்துள்ள SLO ஐ விட எல்லாம் உங்களுக்கு மிகவும் சிறப்பாக இருந்தால், இதுவும் நல்லதல்ல. இது மிகவும் மோசமானது, ஏனெனில் SLO குறைந்த அளவாக மட்டுமல்ல, தோராயமான மேல் வரம்பாகவும் செயல்படுகிறது. 99% கிடைக்கும் என்ற SLOவை நீங்களே அமைத்துக் கொள்ளும்போது, உண்மையில் உங்களிடம் 99,99% இருந்தால், வியாபாரத்திற்கு எந்தப் பாதிப்பையும் ஏற்படுத்தாத சோதனைகளுக்கு உங்களிடம் கொஞ்சம் இடம் இருக்கிறது என்று மாறிவிடும், ஏனென்றால் நீங்களே இதை எல்லாம் சேர்ந்து தீர்மானித்துள்ளீர்கள். இந்த இடம் பயன்படுத்தப்படவில்லை. தவறுகளுக்கான பட்ஜெட் உங்களிடம் உள்ளது, இது உங்கள் விஷயத்தில் பயன்படுத்தப்படவில்லை.
அதை வைத்து என்ன செய்வது. நாம் அதை எல்லாவற்றிற்கும் பயன்படுத்துகிறோம். உற்பத்தி நிலைகளில் சோதனை செய்வதற்கு, செயல்திறனைப் பாதிக்கக்கூடிய புதிய அம்சங்களை வெளியிடுவதற்கு, வெளியீடுகள், பராமரிப்பு, திட்டமிடப்பட்ட வேலையில்லா நேரங்கள். தலைகீழ் விதியும் பொருந்தும்: பட்ஜெட் தீர்ந்துவிட்டால், புதிதாக எதையும் வெளியிட முடியாது, இல்லையெனில் நாம் SLO ஐ மீறுவோம். பட்ஜெட் ஏற்கனவே தீர்ந்து விட்டது, செயல்திறனை எதிர்மறையாக பாதித்தால் நாங்கள் எதையாவது வெளியிட்டுள்ளோம், அதாவது, இது SLO ஐ நேரடியாக அதிகரிக்கும் ஒருவித தீர்வாக இல்லாவிட்டால், நாங்கள் பட்ஜெட்டைத் தாண்டி செல்கிறோம், இது ஒரு மோசமான சூழ்நிலை. , இது பகுப்பாய்வு செய்யப்பட வேண்டும் , போஸ்ட்மார்ட்டம் மற்றும் சில செயல்முறை திருத்தங்கள்.
அதாவது, சேவையே சரியாக வேலை செய்யவில்லை என்றால், மற்றும் SLO செலவழிக்கப்பட்டு, பட்ஜெட் சோதனைகளுக்காக அல்ல, சில வெளியீடுகளில் அல்ல, ஆனால் தானாகவே, சில சுவாரஸ்யமான திருத்தங்களுக்கு பதிலாக, சுவாரஸ்யமான அம்சங்களுக்கு பதிலாக, சுவாரஸ்யமான வெளியீடுகளுக்கு பதிலாக. எந்தவொரு ஆக்கப்பூர்வமான வேலைக்கும் பதிலாக, பட்ஜெட்டை மீண்டும் ஒழுங்கமைக்க அல்லது SLO ஐத் திருத்த முட்டாள்தனமான திருத்தங்களைச் செய்ய வேண்டியிருக்கும், மேலும் இதுவும் அடிக்கடி நடக்கக் கூடாத ஒரு செயலாகும்.
எனவே, பிழைகளுக்கு அதிக பட்ஜெட் உள்ள சூழ்நிலையில், அனைவருக்கும் ஆர்வமாக உள்ளது: SRE மற்றும் டெவலப்பர்கள் இருவரும். டெவலப்பர்களுக்கு, பிழைகளுக்கான ஒரு பெரிய பட்ஜெட், வெளியீடுகள், சோதனைகள், சோதனைகள் ஆகியவற்றை நீங்கள் சமாளிக்க முடியும். SRE களுக்கு, பிழைகளுக்கான பட்ஜெட் மற்றும் அந்த பட்ஜெட்டை உள்ளிடுவது அவர்கள் நேரடியாக தங்கள் வேலையைச் சிறப்பாகச் செய்கிறார்கள் என்று அர்த்தம். இது ஒருவித கூட்டு வேலையின் உந்துதலை பாதிக்கிறது. டெவலப்பர்களாக உங்கள் SREகளை நீங்கள் கேட்டால், நல்ல வேலைக்கான அதிக இடமும், வழக்கத்தை விடவும் குறைவாக இருக்கும்.
உற்பத்தியில் சோதனைகள் பெரிய குழுக்களில் SRE இன் மிக முக்கியமான மற்றும் கிட்டத்தட்ட ஒருங்கிணைந்த பகுதியாகும் என்று மாறிவிடும். இது வழக்கமாக கேயாஸ் இன்ஜினியரிங் என்று அழைக்கப்படுகிறது, இது கேயாஸ் குரங்கு என்ற பயன்பாட்டை வெளியிட்ட நெட்ஃபிக்ஸ் குழுவிலிருந்து வருகிறது.
கேயாஸ் குரங்கு CI/CD பைப்லைனுடன் இணைகிறது மற்றும் உற்பத்தியில் சர்வரை தோராயமாக செயலிழக்கச் செய்கிறது. மீண்டும், SRE கட்டமைப்பில், கீழே விழுந்த சேவையகம் மோசமாக இல்லை என்ற உண்மையைப் பற்றி நாங்கள் பேசுகிறோம், அது எதிர்பார்க்கப்படுகிறது. அது பட்ஜெட்டுக்குள் இருந்தால், அது ஏற்றுக்கொள்ளத்தக்கது மற்றும் வணிகத்திற்கு தீங்கு விளைவிக்காது. நிச்சயமாக, நெட்ஃபிக்ஸ் போதுமான தேவையற்ற சேவையகங்களைக் கொண்டுள்ளது, போதுமான நகலெடுக்கிறது, இதனால் இவை அனைத்தையும் சரிசெய்ய முடியும், மேலும் ஒட்டுமொத்தமாக பயனர் கூட கவனிக்கவில்லை, மேலும் எந்தவொரு பட்ஜெட்டிற்கும் ஒரு சேவையகத்தை யாரும் விட்டுவிடுவதில்லை.
நெட்ஃபிக்ஸ் சிறிது காலத்திற்கு இதுபோன்ற பயன்பாடுகளின் முழு தொகுப்பையும் கொண்டிருந்தது, அதில் ஒன்று, கேயாஸ் கொரில்லா, அமேசானின் கிடைக்கும் மண்டலங்களில் ஒன்றை முழுவதுமாக மூடுகிறது. எதைப் பாதிக்கிறது, எதைப் பொறுத்தது என்பது முற்றிலும் தெளிவாகத் தெரியாதபோது, முதலில், மறைக்கப்பட்ட சார்புகளை வெளிப்படுத்த இதுபோன்ற விஷயங்கள் உதவுகின்றன. இது, நீங்கள் மைக்ரோ சர்வீஸுடன் பணிபுரிகிறீர்கள் என்றால், மற்றும் ஆவணங்கள் சரியாக இல்லை என்றால், இது உங்களுக்கு நன்கு தெரிந்திருக்கும். மீண்டும், நீங்கள் ஸ்டேஜிங்கில் பிடிக்க முடியாத குறியீட்டில் உள்ள பிழைகளைப் பிடிக்க இது நிறைய உதவுகிறது, ஏனென்றால் எந்த நிலையும் துல்லியமான உருவகப்படுத்துதல் அல்ல, சுமை அளவு வேறுபட்டது, சுமை முறை வேறுபட்டது, உபகரணங்கள் மேலும், பெரும்பாலும், மற்றவை. உச்ச சுமைகள் எதிர்பாராததாகவும் கணிக்க முடியாததாகவும் இருக்கலாம். மீண்டும் வரவு செலவுத் திட்டத்திற்கு அப்பால் செல்லாத அத்தகைய சோதனை, ஸ்டேஜிங், ஆட்டோடெஸ்ட்கள், சிஐ / சிடி பைப்லைன் ஒருபோதும் பிடிக்காத உள்கட்டமைப்பில் உள்ள பிழைகளைப் பிடிக்க நன்றாக உதவுகிறது. உங்கள் பட்ஜெட்டில் இவை அனைத்தும் சேர்க்கப்படும் வரை, உங்கள் சேவை கீழே சென்றாலும் பரவாயில்லை, இது மிகவும் பயமாகத் தோன்றினாலும், சர்வர் செயலிழந்தது, என்ன ஒரு கனவு. இல்லை, இது சாதாரணமானது, அது நல்லது, பிழைகளைப் பிடிக்க உதவுகிறது. உங்களிடம் பட்ஜெட் இருந்தால், நீங்கள் அதை செலவிடலாம்.
கே: நான் எந்த இலக்கியத்தை பரிந்துரைக்க முடியும்? இறுதியில் பட்டியல். நிறைய இலக்கியங்கள் உள்ளன, சில அறிக்கைகளை நான் அறிவுறுத்துகிறேன். இது எவ்வாறு இயங்குகிறது மற்றும் SRE நிறுவனங்களில் தங்கள் சொந்த மென்பொருள் தயாரிப்பு இல்லாமல் அல்லது குறைந்த வளர்ச்சியுடன் வேலை செய்கிறது. எடுத்துக்காட்டாக, முக்கிய செயல்பாடு மென்பொருள் அல்லாத நிறுவனத்தில். ஒரு நிறுவனத்தில், முக்கிய செயல்பாடு மென்பொருளாக இல்லாத இடத்தில், SRE எல்லா இடங்களிலும் ஒரே மாதிரியாக செயல்படுகிறது, ஏனெனில் ஒரு நிறுவனத்தில் நீங்கள் மென்பொருள் தயாரிப்புகளை உருவாக்கவில்லை என்றாலும், நீங்கள் புதுப்பிப்புகளை வெளியிட வேண்டும், நீங்கள் மாற்ற வேண்டும். உள்கட்டமைப்பு, நீங்கள் வளர வேண்டும், நீங்கள் அளவிட வேண்டும். மேலும் SREகள் இந்த செயல்முறைகளில் சாத்தியமான சிக்கல்களைக் கண்டறிந்து கணிக்க உதவுகின்றன மற்றும் சில வளர்ச்சி தொடங்கி வணிகத் தேவைகள் மாறிய பிறகு அவற்றைக் கட்டுப்படுத்துகின்றன. ஏனெனில் உங்களிடம் குறைந்தபட்சம் சில சேவையகங்களாவது இருந்தால் SRE ஐப் பெறுவதற்கு மென்பொருள் மேம்பாட்டில் ஈடுபட வேண்டிய அவசியமில்லை.
சிறிய திட்டங்களுக்கும், சிறிய நிறுவனங்களுக்கும் இதுவே செல்கிறது, ஏனென்றால் பெரிய நிறுவனங்களுக்கு பட்ஜெட் மற்றும் பரிசோதனைக்கான இடமும் உள்ளது. ஆனால் அதே நேரத்தில், இந்த சோதனைகளின் அனைத்து பழங்களும் எங்கும் பயன்படுத்தப்படலாம், அதாவது, SRE, நிச்சயமாக, கூகிளில், நெட்ஃபிக்ஸ், டிராப்பாக்ஸில் தோன்றியது. ஆனால் அதே நேரத்தில், சிறிய நிறுவனங்கள் மற்றும் தொடக்க நிறுவனங்கள் ஏற்கனவே சுருக்கப்பட்ட பொருட்களைப் படிக்கலாம், புத்தகங்களைப் படிக்கலாம், அறிக்கைகளைப் பார்க்கலாம். அவர்கள் இதைப் பற்றி அடிக்கடி கேட்கத் தொடங்குகிறார்கள், அவர்கள் குறிப்பிட்ட எடுத்துக்காட்டுகளைப் பார்க்கிறார்கள், பரவாயில்லை என்று நினைக்கிறேன், இது உண்மையில் பயனுள்ளதாக இருக்கும், எங்களுக்கும் இது தேவை, இது மிகவும் நல்லது.
அதாவது, இந்த செயல்முறைகளை தரப்படுத்துவதற்கான அனைத்து முக்கிய வேலைகளும் உங்களுக்காக ஏற்கனவே செய்யப்பட்டுள்ளன. உங்கள் நிறுவனத்தில் குறிப்பாக SRE இன் பங்கைத் தீர்மானிப்பது மற்றும் இந்த நடைமுறைகள் அனைத்தையும் செயல்படுத்தத் தொடங்குவது உங்களுக்கு உள்ளது, இது மீண்டும், ஏற்கனவே விவரிக்கப்பட்டுள்ளது. அதாவது, சிறிய நிறுவனங்களுக்கான பயனுள்ள கொள்கைகளிலிருந்து, இது எப்போதும் SLA, SLI, SLO ஆகியவற்றின் வரையறையாகும். நீங்கள் மென்பொருளில் ஈடுபடவில்லை என்றால், இவை உள் SLAகள் மற்றும் உள் SLOக்கள், பிழைகளுக்கான உள் பட்ஜெட். இது எப்போதும் குழுவிற்குள் மற்றும் வணிகத்திற்குள் சில சுவாரஸ்யமான விவாதங்களுக்கு வழிவகுக்கிறது, ஏனென்றால் நீங்கள் உள்கட்டமைப்புக்காக, சில வகையான சிறந்த செயல்முறைகளை ஒழுங்கமைப்பதில் செலவழிக்கிறீர்கள், சிறந்த குழாய்த்திட்டம் தேவையானதை விட அதிகமாக உள்ளது. தகவல் தொழில்நுட்பத் துறையில் உங்களிடம் உள்ள இந்த 4 நைன்கள் உங்களுக்கு இப்போது தேவையில்லை. ஆனால் அதே நேரத்தில், நீங்கள் நேரத்தை செலவிடலாம், தவறுகளுக்கு பட்ஜெட்டை வேறு ஏதாவது செலவிடலாம்.
அதன்படி, எந்த அளவிலான நிறுவனத்திற்கும் கண்காணிப்பு மற்றும் கண்காணிப்பு அமைப்பு பயனுள்ளதாக இருக்கும். பொதுவாக, இந்த சிந்தனை முறை, தவறுகள் ஏற்றுக்கொள்ளக்கூடிய ஒன்று, பட்ஜெட் இருக்கும் இடத்தில், குறிக்கோள்கள் இருக்கும் இடத்தில், 3 நபர்களுக்கான தொடக்கத்திலிருந்து தொடங்கி எந்த அளவிலான நிறுவனத்திற்கும் இது மீண்டும் பயனுள்ளதாக இருக்கும்.
தொழில்நுட்ப நுணுக்கங்களில் கடைசியாக பேசுவது கண்காணிப்பு. ஏனெனில் நாம் SLA, SLI, SLO பற்றி பேசினால், நாம் பட்ஜெட்டுக்கு பொருந்துகிறோமா, நமது குறிக்கோள்களுக்கு இணங்குகிறோமா, மற்றும் இறுதி SLA ஐ எவ்வாறு பாதிக்கிறோம் என்பதை கண்காணிக்காமல் புரிந்து கொள்ள முடியாது. கண்காணிப்பு இப்படி நடப்பதை நான் பலமுறை பார்த்திருக்கிறேன்: சில மதிப்பு உள்ளது, எடுத்துக்காட்டாக, சேவையகத்திற்கான கோரிக்கையின் நேரம், சராசரி நேரம் அல்லது தரவுத்தளத்திற்கான கோரிக்கைகளின் எண்ணிக்கை. ஒரு பொறியாளரால் நிர்ணயிக்கப்பட்ட ஒரு தரநிலை அவருக்கு உள்ளது. மெட்ரிக் விதிமுறையிலிருந்து விலகினால், ஒரு மின்னஞ்சல் வரும். ஒரு விதியாக, இது முற்றிலும் பயனற்றது, ஏனென்றால் இது விழிப்பூட்டல்களின் பெருக்கத்திற்கு வழிவகுக்கிறது, கண்காணிப்பிலிருந்து வரும் செய்திகளின் பெருக்கம், ஒரு நபர், முதலில், ஒவ்வொரு முறையும் அவற்றை விளக்க வேண்டும், அதாவது, மெட்ரிக் வழிமுறையின் மதிப்பை தீர்மானிக்க வேண்டும். சில நடவடிக்கை தேவை. இரண்டாவதாக, அவரிடமிருந்து எந்த நடவடிக்கையும் தேவைப்படாதபோது, இந்த எச்சரிக்கைகள் அனைத்தையும் கவனிப்பதை அவர் நிறுத்துகிறார். இது ஒரு நல்ல கண்காணிப்பு விதி மற்றும் SRE செயல்படுத்தப்படும் போது முதல் விதி, நடவடிக்கை தேவைப்படும் போது மட்டுமே அறிவிப்பு வர வேண்டும்.
நிலையான வழக்கில், நிகழ்வுகளின் 3 நிலைகள் உள்ளன. எச்சரிக்கைகள் உள்ளன, டிக்கெட்டுகள் உள்ளன, பதிவுகள் உள்ளன. விழிப்பூட்டல்கள் நீங்கள் உடனடியாக நடவடிக்கை எடுக்க வேண்டும். அதாவது, எல்லாம் உடைந்துவிட்டது, நீங்கள் இப்போதே அதை சரிசெய்ய வேண்டும். டிக்கெட்டுகள் தாமதமான நடவடிக்கை தேவை. ஆம், நீங்கள் ஏதாவது செய்ய வேண்டும், நீங்கள் கைமுறையாக ஏதாவது செய்ய வேண்டும், ஆட்டோமேஷன் தோல்வியடைந்தது, ஆனால் அடுத்த சில நிமிடங்களுக்கு நீங்கள் அதைச் செய்ய வேண்டியதில்லை. பதிவுகள் என்பது செயல் தேவையில்லாத எதுவும், பொதுவாக, விஷயங்கள் சரியாக நடந்தால், யாரும் அவற்றைப் படிக்க மாட்டார்கள். பின்னோக்கிப் பார்த்தால், சிறிது நேரம் ஏதோ உடைந்ததாகத் தெரிந்தால், அதைப் பற்றி எங்களுக்குத் தெரியாதபோது மட்டுமே நீங்கள் பதிவுகளைப் படிக்க வேண்டும். அல்லது நீங்கள் ஏதாவது ஆராய்ச்சி செய்ய வேண்டும். ஆனால் பொதுவாக, எந்த நடவடிக்கையும் தேவைப்படாத அனைத்தும் பதிவுகளுக்குச் செல்கின்றன.
இவை அனைத்தின் பக்க விளைவுகளாக, எந்த நிகழ்வுகளுக்கு செயல்கள் தேவை என்பதை வரையறுத்து, இந்த செயல்கள் என்னவாக இருக்க வேண்டும் என்பதை நன்கு விவரித்திருந்தால், செயல் தானாகவே செய்யப்படலாம் என்று அர்த்தம். அதாவது, என்ன நடக்கும். நாங்கள் எச்சரிக்கையிலிருந்து செல்கிறோம். செயலுக்கு செல்வோம். இந்த செயலின் விளக்கத்திற்கு செல்கிறோம். பின்னர் நாம் ஆட்டோமேஷனுக்கு செல்கிறோம். அதாவது, எந்தவொரு ஆட்டோமேஷனும் ஒரு நிகழ்வின் எதிர்வினையுடன் தொடங்குகிறது.
கண்காணிப்பில் இருந்து, நாம் கவனிப்பு என்ற சொல்லுக்கு செல்கிறோம். கடந்த சில ஆண்டுகளாக இந்த வார்த்தையைச் சுற்றி ஒரு பிட் ஹைப் உள்ளது. மற்றும் சில மக்கள் சூழலில் வெளியே அர்த்தம் என்ன புரிந்து. ஆனால் முக்கிய விஷயம் என்னவென்றால், கண்காணிப்பு என்பது கணினி வெளிப்படைத்தன்மைக்கான ஒரு மெட்ரிக் ஆகும். ஏதேனும் தவறு நடந்தால், சரியாக என்ன தவறு நடந்தது மற்றும் அந்த நேரத்தில் அமைப்பின் நிலை என்ன என்பதை நீங்கள் எவ்வளவு விரைவாக தீர்மானிக்க முடியும். குறியீட்டின் அடிப்படையில்: எந்த செயல்பாடு தோல்வியடைந்தது, எந்த சேவை தோல்வியடைந்தது. எடுத்துக்காட்டாக, உள் மாறிகள், உள்ளமைவின் நிலை என்ன. உள்கட்டமைப்பைப் பொறுத்தவரை, இது கிடைக்கக்கூடிய மண்டலத்தில் தோல்வி ஏற்பட்டது, உங்களிடம் ஏதேனும் குபர்னெட்டுகள் இருந்தால், எந்த பாட்டில் தோல்வி ஏற்பட்டது, அதன் நிலை என்ன. அதன்படி, கவனிப்பு MTTR உடன் நேரடி உறவைக் கொண்டுள்ளது. சேவையின் கண்காணிப்புத் திறன் அதிகமாக இருந்தால், பிழையைக் கண்டறிவது எளிது, பிழையைச் சரிசெய்வது எளிது, பிழையைத் தானியக்கமாக்குவது எளிது, MTTR குறையும்.
மீண்டும் சிறிய நிறுவனங்களுக்குச் செல்லும்போது, இப்போது கூட, குழு அளவை எவ்வாறு கையாள்வது, மற்றும் ஒரு சிறிய குழு தனி SRE ஐ நியமிக்க வேண்டுமா என்று கேட்பது மிகவும் பொதுவானது. இதைப் பற்றி ஏற்கனவே கொஞ்சம் முன்பே பேசப்பட்டது. ஒரு தொடக்கத்தின் வளர்ச்சியின் முதல் கட்டங்களில் அல்லது, எடுத்துக்காட்டாக, ஒரு குழு, இது அவசியமில்லை, ஏனெனில் SRE ஐ ஒரு இடைநிலைப் பாத்திரமாக மாற்ற முடியும். இது அணியை சிறிது புதுப்பிக்கும், ஏனென்றால் குறைந்தபட்சம் சில வேறுபாடுகள் உள்ளன. மேலும் வளர்ச்சியுடன், பொதுவாக, SRE இன் பொறுப்புகள் மிகவும் குறிப்பிடத்தக்க அளவில் மாறும் என்பதற்கு இது மக்களை தயார்படுத்தும். நீங்கள் ஒரு நபரை வேலைக்கு அமர்த்தினால், நிச்சயமாக, அவருக்கு சில எதிர்பார்ப்புகள் உள்ளன. இந்த எதிர்பார்ப்புகள் காலப்போக்கில் மாறாது, ஆனால் தேவைகள் மிகவும் மாறும். எனவே, ஒரு SRE ஐ எவ்வாறு பணியமர்த்துவது என்பது ஆரம்ப கட்டங்களில் மிகவும் கடினம். சொந்தமாக வளர்ப்பது மிகவும் எளிதானது. ஆனால் இது சிந்திக்கத் தக்கது.
ஒரே விதிவிலக்கு, ஒருவேளை, மிகவும் கடுமையான மற்றும் நன்கு வரையறுக்கப்பட்ட வளர்ச்சி தேவைகள் இருக்கும் போது. அதாவது, ஒரு தொடக்க விஷயத்தில், இது முதலீட்டாளர்களிடமிருந்து ஒருவித அழுத்தமாக இருக்கலாம், ஒரே நேரத்தில் பல முறை வளர்ச்சிக்கான சில வகையான முன்னறிவிப்பு. ஒரு SRE ஐ பணியமர்த்துவது அடிப்படையில் நியாயப்படுத்தப்படுகிறது, ஏனெனில் அது நியாயப்படுத்தப்படலாம். வளர்ச்சிக்கான தேவைகள் எங்களிடம் உள்ளன, அத்தகைய வளர்ச்சியால் எதுவும் உடைக்கப்படாது என்பதற்கு பொறுப்பான ஒரு நபர் நமக்குத் தேவை.
இன்னும் ஒரு கேள்வி. டெவலப்பர்கள் பல முறை சோதனைகளில் தேர்ச்சி பெறும் அம்சத்தை வெட்டும்போது என்ன செய்வது, ஆனால் உற்பத்தியை உடைக்கிறது, அடிப்படையை ஏற்றுகிறது, பிற அம்சங்களை உடைக்கிறது, என்ன செயல்முறையை செயல்படுத்த வேண்டும். அதன்படி, இந்த வழக்கில், இது அறிமுகப்படுத்தப்பட்ட பிழைகளுக்கான பட்ஜெட் ஆகும். மேலும் சில சேவைகள், சில அம்சங்கள் ஏற்கனவே தயாரிப்பில் சோதிக்கப்பட்டு வருகின்றன. இது கேனரியாக இருக்கலாம், குறைந்த எண்ணிக்கையிலான பயனர்கள் மட்டுமே, ஆனால் ஏற்கனவே தயாரிப்பில், ஒரு அம்சம் பயன்படுத்தப்படுகிறது, ஆனால் ஏற்கனவே ஏதேனும் உடைந்தால், எடுத்துக்காட்டாக, அனைத்து பயனர்களில் அரை சதவீதத்திற்கும், அது இன்னும் சந்திக்கும் என்ற எதிர்பார்ப்புடன் பிழைகளுக்கான பட்ஜெட். அதன்படி, ஆம், ஒரு பிழை இருக்கும், சில பயனர்களுக்கு எல்லாம் உடைந்துவிடும், ஆனால் இது சாதாரணமானது என்று நாங்கள் ஏற்கனவே கூறியுள்ளோம்.
SRE கருவிகள் பற்றி ஒரு கேள்வி இருந்தது. அதாவது, SRE கள் பயன்படுத்தக்கூடிய குறிப்பாக மற்ற அனைவரும் பயன்படுத்தாத ஏதாவது உள்ளதா. உண்மையில், மிகவும் சிறப்பு வாய்ந்த சில பயன்பாடுகள் உள்ளன, சில வகையான மென்பொருள்கள் உள்ளன, எடுத்துக்காட்டாக, சுமைகளை உருவகப்படுத்துகிறது அல்லது கேனரி ஏ / பி சோதனையில் ஈடுபட்டுள்ளது. ஆனால் அடிப்படையில் SRE கருவித்தொகுப்பை உங்கள் டெவலப்பர்கள் ஏற்கனவே பயன்படுத்தி வருகின்றனர். ஏனெனில் SRE நேரடியாக மேம்பாட்டுக் குழுவுடன் தொடர்பு கொள்கிறது. உங்களிடம் வெவ்வேறு கருவிகள் இருந்தால், ஒத்திசைக்க நேரம் எடுக்கும். குறிப்பாக SRE கள் பெரிய குழுக்களில் பணிபுரிந்தால், பல குழுக்கள் இருக்கக்கூடிய பெரிய நிறுவனங்களில், இது நிறுவன அளவிலான தரநிலைப்படுத்தல் இங்கே நிறைய உதவும், ஏனெனில் 50 குழுக்களில் 50 வெவ்வேறு பயன்பாடுகள் பயன்படுத்தப்பட்டால், SRE அவற்றை அறிந்திருக்க வேண்டும். அனைத்து. மற்றும் நிச்சயமாக இது நடக்காது. மேலும் பணியின் தரம், குறைந்தபட்சம் சில குழுக்களின் கட்டுப்பாட்டின் தரம் கணிசமாகக் குறையும்.
எங்கள் வலைப்பதிவு முடிவுக்கு வருகிறது. சில அடிப்படை விஷயங்களைச் சொல்ல முடிந்தது. நிச்சயமாக, SRE பற்றி எதுவும் ஒரு மணி நேரத்தில் சொல்லி புரிந்து கொள்ள முடியாது. ஆனால் இந்த சிந்தனை வழியை, முக்கிய முக்கிய புள்ளிகளை என்னால் தெரிவிக்க முடிந்தது என்று நம்புகிறேன். பின்னர், ஆர்வமாக இருந்தால், தலைப்பை ஆராய்வது, சொந்தமாக கற்றுக்கொள்வது, பிற நிறுவனங்களில் மற்றவர்களால் எவ்வாறு செயல்படுத்தப்படுகிறது என்பதைப் பார்ப்பது சாத்தியமாகும். அதன்படி, பிப்ரவரி தொடக்கத்தில், ஸ்லர்ம் SRE இல் எங்களிடம் வாருங்கள்.
ஸ்லர்ம் எஸ்ஆர்ஈ என்பது மூன்று நாள் தீவிர பாடமாகும், இது நான் இப்போது பேசுவதைப் பற்றி பேசுவேன், ஆனால் அதிக ஆழத்துடன், உண்மையான நிகழ்வுகளுடன், நடைமுறையில், முழு தீவிரமும் நடைமுறை வேலைகளை இலக்காகக் கொண்டது. மக்கள் அணிகளாகப் பிரிக்கப்படுவார்கள். நீங்கள் அனைவரும் உண்மையான வழக்குகளில் வேலை செய்வீர்கள். அதன்படி, எங்களிடம் Booking.com பயிற்றுனர்கள் Ivan Kruglov மற்றும் Ben Tyler உள்ளனர். சான் ஃபிரான்சிஸ்கோவிலிருந்து கூகுளில் இருந்து எங்களிடம் அற்புதமான யூஜின் பரபாஸ் உள்ளது. மேலும் நான் உங்களுக்கு ஒன்று சொல்கிறேன். எனவே எங்களை தவறாமல் பார்வையிடவும்.
எனவே, நூலியல். SRE பற்றிய குறிப்புகள் உள்ளன. அதே புத்தகத்தில், அல்லது Google ஆல் எழுதப்பட்ட SRE பற்றிய 2 புத்தகங்களில். மற்றொன்று , விதிமுறைகள் மற்றும் அவற்றின் பயன்பாடு சற்று விரிவாக இருக்கும். அடுத்த 3 வெவ்வேறு நிறுவனங்களில் SRE பற்றிய அறிக்கைகள். முதலில் - , இது கூகுளின் பென் ட்ரெய்னரின் முக்கிய குறிப்பு. இரண்டாவது - . மூன்றாவது மீண்டும் . இருந்து நான்காவது அறிக்கை 5 நாடுகளில் 190 முக்கிய SRE ஊழியர்களை மட்டுமே கொண்டுள்ளது. இதையெல்லாம் பார்ப்பது மிகவும் சுவாரஸ்யமாக இருக்கிறது, ஏனென்றால் DevOps என்பது வெவ்வேறு நிறுவனங்களுக்கும் வெவ்வேறு குழுக்களுக்கும் மிகவும் வித்தியாசமான விஷயங்களைக் குறிக்கிறது, SRE ஆனது ஒரே அளவிலான நிறுவனங்களில் கூட வேறுபட்ட பொறுப்புகளைக் கொண்டுள்ளது.
கேயாஸ் இன்ஜினியரிங் கொள்கைகளில் மேலும் 2 இணைப்புகள்: , . மற்றும் முடிவில் அற்புதமான பட்டியல்கள் தொடரில் இருந்து 3 பட்டியல்கள் உள்ளன , பற்றி மற்றும் பற்றி . SRE இல் உள்ள பட்டியல் நம்பமுடியாத அளவிற்கு பெரியது, இது அனைத்தையும் கடந்து செல்ல வேண்டிய அவசியமில்லை, சுமார் 200 கட்டுரைகள் உள்ளன. திறன் திட்டமிடல் மற்றும் குற்றமற்ற போஸ்ட்மார்ட்டம் பற்றிய கட்டுரைகளை நான் மிகவும் பரிந்துரைக்கிறேன்.
சுவாரஸ்யமான கட்டுரை:
இவ்வளவு நேரம் நான் சொல்வதைக் கேட்டதற்கு நன்றி. நீங்கள் ஏதாவது கற்றுக்கொண்டீர்கள் என்று நம்புகிறேன். இன்னும் அதிகமாகக் கற்றுக்கொள்ள உங்களிடம் போதுமான பொருள் இருப்பதாக நம்புகிறேன். மற்றும் சந்திப்போம். பிப்ரவரியில் நம்புகிறேன்.
வெபினாரை எட்வர்ட் மெத்வதேவ் தொகுத்து வழங்கினார்.
PS: படிக்க விரும்புவோருக்கு, எட்வர்ட் குறிப்புகளின் பட்டியலைக் கொடுத்தார். நடைமுறையில் புரிந்து கொள்ள விரும்புபவர்கள் வரவேற்கப்படுகிறார்கள் .
ஆதாரம்: www.habr.com