வணக்கம், ஹப்ர்! நான் பத்து வருடங்களாக Highload IT அமைப்புகளை ஆதரித்து வருகிறேன். 1000+ RPS பயன்முறையில் nginx ஐ அமைப்பதில் உள்ள சிக்கல்கள் அல்லது பிற தொழில்நுட்ப விஷயங்களைப் பற்றி நான் இந்தக் கட்டுரையில் எழுத மாட்டேன். அத்தகைய அமைப்புகளின் ஆதரவு மற்றும் செயல்பாட்டில் எழும் செயல்முறைகளில் உள்ள சிக்கல்கள் பற்றிய எனது அவதானிப்புகளைப் பகிர்ந்து கொள்கிறேன்.
கண்காணிப்பு
"என்ன ஏன்... தளம் மீண்டும் வேலை செய்யவில்லை?" என்ற உள்ளடக்கத்துடன் கோரிக்கை வரும் வரை தொழில்நுட்ப ஆதரவு காத்திருக்காது. தளம் செயலிழந்த ஒரு நிமிடத்திற்குள், ஆதரவு ஏற்கனவே சிக்கலைப் பார்த்து அதைத் தீர்க்கத் தொடங்க வேண்டும். ஆனால் இந்த தளம் பனிப்பாறையின் முனை. அதன் கிடைக்கும் தன்மை முதலில் கண்காணிக்கப்பட வேண்டிய ஒன்றாகும்.
ஆன்லைன் ஸ்டோரின் மீதமுள்ள பொருட்கள் ஈஆர்பி அமைப்பிலிருந்து வராத சூழ்நிலையில் என்ன செய்வது? அல்லது வாடிக்கையாளர்களுக்கான தள்ளுபடியைக் கணக்கிடும் CRM அமைப்பு பதிலளிப்பதை நிறுத்திவிட்டதா? தளம் செயல்படுவது போல் தெரிகிறது. நிபந்தனை Zabbix அதன் 200 பதிலைப் பெறுகிறது. டூட்டி ஷிப்ட் கண்காணிப்பில் இருந்து எந்த அறிவிப்பும் பெறவில்லை மற்றும் கேம் ஆஃப் த்ரோன்ஸ் புதிய சீசனின் முதல் எபிசோடை மகிழ்ச்சியுடன் பார்த்துக் கொண்டிருக்கிறது.
கண்காணிப்பு என்பது நினைவகம், ரேம் மற்றும் சர்வர் ப்ராசசர் சுமை ஆகியவற்றின் நிலையை அளவிடுவதற்கு மட்டுமே வரையறுக்கப்பட்டுள்ளது. ஆனால் வணிகத்தைப் பொறுத்தவரை, இணையதளத்தில் தயாரிப்பு கிடைக்கும் தன்மையைப் பெறுவது மிகவும் முக்கியமானது. கிளஸ்டரில் உள்ள ஒரு மெய்நிகர் இயந்திரத்தின் நிபந்தனை தோல்வி, அதற்கு போக்குவரத்து செல்வதை நிறுத்தும் மற்றும் பிற சேவையகங்களில் சுமை அதிகரிக்கும் என்பதற்கு வழிவகுக்கும். நிறுவனம் பணத்தை இழக்காது.
எனவே, சேவையகங்களில் இயக்க முறைமைகளின் தொழில்நுட்ப அளவுருக்களை கண்காணிப்பதோடு கூடுதலாக, நீங்கள் வணிக அளவீடுகளை உள்ளமைக்க வேண்டும். பணத்தை நேரடியாக பாதிக்கும் அளவீடுகள். வெளிப்புற அமைப்புகளுடன் (CRM, ERP மற்றும் பிற) பல்வேறு தொடர்புகள். ஒரு குறிப்பிட்ட காலத்திற்கு ஆர்டர்களின் எண்ணிக்கை. வெற்றிகரமான அல்லது தோல்வியுற்ற கிளையன்ட் அங்கீகாரங்கள் மற்றும் பிற அளவீடுகள்.
வெளிப்புற அமைப்புகளுடன் தொடர்பு
ஒரு பில்லியனுக்கும் அதிகமான ரூபிள் வருடாந்திர வருவாய் கொண்ட எந்த இணையதளம் அல்லது மொபைல் பயன்பாடு வெளிப்புற அமைப்புகளுடன் தொடர்பு கொள்கிறது. மேலே குறிப்பிட்டுள்ள CRM மற்றும் ERP இலிருந்து தொடங்கி, வாங்குதல்களை பகுப்பாய்வு செய்வதற்கும், வாடிக்கையாளர் நிச்சயமாக வாங்கும் (உண்மையில், இல்லை) ஒரு தயாரிப்பை வழங்குவதற்கும் வெளிப்புற பெரிய தரவு அமைப்புக்கு விற்பனைத் தரவை மாற்றுவதுடன் முடிவடையும். அத்தகைய ஒவ்வொரு அமைப்புக்கும் அதன் சொந்த ஆதரவு உள்ளது. மேலும் பெரும்பாலும் இந்த அமைப்புகளுடனான தொடர்பு வலியை ஏற்படுத்துகிறது. குறிப்பாக பிரச்சனை உலகளாவியதாக இருக்கும்போது, நீங்கள் அதை வெவ்வேறு அமைப்புகளில் பகுப்பாய்வு செய்ய வேண்டும்.
சில அமைப்புகள் தங்கள் நிர்வாகிகளுக்கு தொலைபேசி எண் அல்லது தந்தியை வழங்குகின்றன. எங்காவது நீங்கள் மேலாளர்களுக்கு கடிதங்களை எழுத வேண்டும் அல்லது இந்த வெளிப்புற அமைப்புகளின் பிழை கண்காணிப்பாளர்களுக்குச் செல்ல வேண்டும். ஒரு பெரிய நிறுவனத்தின் சூழலில் கூட, வெவ்வேறு அமைப்புகள் பெரும்பாலும் வெவ்வேறு பயன்பாட்டு கணக்கியல் அமைப்புகளில் செயல்படுகின்றன. சில நேரங்களில் பயன்பாட்டின் நிலையைக் கண்காணிக்க இயலாது. நீங்கள் ஒரு நிபந்தனை ஜிராவில் கோரிக்கையைப் பெறுவீர்கள். இந்த முதல் ஜிராவின் கமெண்டில் இன்னொரு ஜிராவில் பிரச்சினைக்கான லிங்கை போட்டிருக்கிறீர்கள். விண்ணப்பத்தில் இரண்டாவது ஜிராவில், யாரோ ஏற்கனவே ஒரு கருத்தை எழுதுகிறார்கள் சிக்கலைத் தீர்க்க நீங்கள் நிபந்தனை நிர்வாகி ஆண்ட்ரேயை அழைக்க வேண்டும். அதனால் தான்.
இந்த சிக்கலுக்கான சிறந்த தீர்வு, தகவல்தொடர்புக்கு ஒரு தனி இடத்தை உருவாக்குவதாகும், எடுத்துக்காட்டாக ஸ்லாக்கில். வெளிப்புற அமைப்புகளை இயக்கும் செயல்பாட்டில் அனைத்து பங்கேற்பாளர்களையும் சேர அழைக்கிறது. மேலும் அப்ளிகேஷன்களை நகல் எடுக்காமல் இருக்க ஒற்றை டிராக்கர். அறிவிப்புகளை கண்காணிப்பது முதல் எதிர்காலத்தில் பிழை தீர்வுகளின் வெளியீடு வரை பயன்பாடுகள் ஒரே இடத்தில் கண்காணிக்கப்பட வேண்டும். இது நம்பத்தகாதது என்று நீங்கள் கூறுவீர்கள், நாங்கள் ஒரு டிராக்கரில் வேலை செய்கிறோம், அவர்கள் மற்றொரு டிராக்கரில் வேலை செய்கிறோம் என்பது வரலாற்று ரீதியாக நடந்தது. வெவ்வேறு அமைப்புகள் தோன்றின, அவர்கள் தங்கள் சொந்த தன்னாட்சி ஐடி குழுக்களைக் கொண்டிருந்தனர். நான் ஒப்புக்கொள்கிறேன், எனவே CIO அல்லது தயாரிப்பு உரிமையாளர் மட்டத்தில் மேலே இருந்து பிரச்சனை தீர்க்கப்பட வேண்டும்.
நீங்கள் தொடர்பு கொள்ளும் ஒவ்வொரு அமைப்பும், முன்னுரிமையின் அடிப்படையில் சிக்கல்களைத் தீர்க்க தெளிவான SLA உடன் ஒரு சேவையாக ஆதரவை வழங்க வேண்டும். நிபந்தனை நிர்வாகி ஆண்ட்ரே உங்களுக்காக ஒரு நிமிடம் இருக்கும்போது அல்ல.
தடங்கல் மனிதன்
ஒரு திட்டத்தில் (அல்லது தயாரிப்பில்) உள்ள அனைவருக்கும் விடுமுறையில் செல்வது அவர்களின் மேலதிகாரிகளிடையே மன உளைச்சலை ஏற்படுத்துகிறதா? இது டெவொப்ஸ் இன்ஜினியர், ஆய்வாளர் அல்லது டெவலப்பராக இருக்கலாம். எல்லாவற்றிற்கும் மேலாக, ஒரு டெவொப்ஸ் இன்ஜினியர் மட்டுமே எந்த சர்வர்களில் எந்த கொள்கலன்கள் நிறுவப்பட்டுள்ளன, சிக்கல் ஏற்பட்டால் கொள்கலனை எவ்வாறு மறுதொடக்கம் செய்வது என்பது தெரியும், பொதுவாக, எந்தவொரு சிக்கலான சிக்கலையும் அவர் இல்லாமல் தீர்க்க முடியாது. உங்கள் சிக்கலான பொறிமுறை எவ்வாறு செயல்படுகிறது என்பதை ஆய்வாளர் மட்டுமே அறிவார். எந்த டேட்டா ஸ்ட்ரீம்கள் எங்கு செல்கின்றன. எந்தெந்த சேவைகளுக்கான கோரிக்கைகளின் எந்த அளவுருக்களின் கீழ், எந்தெந்த சேவைகளுக்கான பதில்களைப் பெறுவோம்.
பதிவுகளில் ஏன் பிழைகள் உள்ளன என்பதை யார் விரைவாக புரிந்துகொள்வார்கள் மற்றும் தயாரிப்பில் ஒரு முக்கியமான பிழையை உடனடியாக சரிசெய்வார்? நிச்சயமாக அதே டெவலப்பர். மற்றவர்கள் உள்ளனர், ஆனால் சில காரணங்களால் மட்டுமே கணினியின் வெவ்வேறு தொகுதிகள் எவ்வாறு செயல்படுகின்றன என்பதை அவர் புரிந்துகொள்கிறார்.
இந்த பிரச்சனைக்கு காரணம் ஆவணங்கள் இல்லாததுதான். எல்லாவற்றிற்கும் மேலாக, உங்கள் கணினியின் அனைத்து சேவைகளும் விவரிக்கப்பட்டிருந்தால், ஒரு ஆய்வாளர் இல்லாமல் சிக்கலைச் சமாளிக்க முடியும். டெவொப்ஸ் தனது பிஸியான கால அட்டவணையில் இருந்து ஓரிரு நாட்கள் எடுத்து, அனைத்து சர்வர்கள், சேவைகள் மற்றும் வழக்கமான சிக்கல்களைத் தீர்ப்பதற்கான வழிமுறைகளை விவரித்தால், அவர் இல்லாத பிரச்சனையை அவர் இல்லாமல் தீர்க்க முடியும். விடுமுறையில் இருக்கும்போது கடற்கரையில் உங்கள் பீரை விரைவாக முடித்துவிட்டு சிக்கலைத் தீர்க்க வைஃபையைப் பார்க்க வேண்டிய அவசியமில்லை.
ஆதரவு ஊழியர்களின் தகுதி மற்றும் பொறுப்பு
பெரிய திட்டங்களில், நிறுவனங்கள் டெவலப்பர் சம்பளத்தை குறைக்காது. அவர்கள் இதே போன்ற திட்டங்களில் இருந்து விலையுயர்ந்த நடுத்தர அல்லது மூத்தவர்களைத் தேடுகிறார்கள். ஆதரவுடன், நிலைமை சற்று வித்தியாசமானது. சாத்தியமான எல்லா வழிகளிலும் இந்த செலவுகளை குறைக்க முயற்சிக்கின்றனர். நிறுவனங்கள் நேற்றைய எனிகே தொழிலாளர்களை மலிவாக வேலைக்கு அமர்த்தி தைரியமாக போரில் இறங்குகின்றன. Zelenograd இல் உள்ள ஒரு ஆலையின் வணிக அட்டை வலைத்தளத்தைப் பற்றி நாம் பேசினால் இந்த உத்தி சாத்தியமாகும்.
நாங்கள் ஒரு பெரிய ஆன்லைன் ஸ்டோரைப் பற்றி பேசுகிறோம் என்றால், ஒவ்வொரு மணிநேர வேலையில்லா நேரமும் எனிகே நிர்வாகியின் மாத சம்பளத்தை விட அதிகமாக செலவாகும். 1 பில்லியன் ரூபிள் வருடாந்திர விற்றுமுதல் தொடக்க புள்ளியாக எடுத்துக்கொள்வோம். மதிப்பீட்டில் இருந்து எந்த ஆன்லைன் ஸ்டோரின் குறைந்தபட்ச விற்றுமுதல் இதுவாகும் . இந்த தொகையை வருடத்திற்கு மணிநேரங்களின் எண்ணிக்கையால் பிரித்து 100 ரூபிள்களுக்கு மேல் நிகர இழப்புகளைப் பெறுங்கள். நீங்கள் இரவு நேரத்தை கணக்கிடவில்லை என்றால், நீங்கள் பாதுகாப்பாக தொகையை இரட்டிப்பாக்கலாம்.
ஆனால் பணம் முக்கிய விஷயம் அல்ல, இல்லையா? (இல்லை, நிச்சயமாக முக்கிய விஷயம்) நற்பெயர் இழப்புகளும் உள்ளன. நன்கு அறியப்பட்ட ஆன்லைன் ஸ்டோரின் வீழ்ச்சி சமூக வலைப்பின்னல்கள் மற்றும் கருப்பொருள் ஊடகங்களில் உள்ள வெளியீடுகளில் மதிப்புரைகளின் அலைகளை ஏற்படுத்தும். மேலும் “அங்கே எதையும் வாங்காதே, அவர்களின் இணையதளம் எப்போதும் செயலிழந்து கிடக்கிறது” என்ற பாணியில் சமையலறையில் நண்பர்களின் உரையாடல்களை அளவிடவே முடியாது.
இப்போது பொறுப்புக்கு. எனது நடைமுறையில், தளம் கிடைக்காதது குறித்து கண்காணிப்பு அமைப்பின் அறிவிப்புக்கு பணியில் உள்ள நிர்வாகி சரியான நேரத்தில் பதிலளிக்காத ஒரு வழக்கு இருந்தது. ஒரு இனிமையான கோடை வெள்ளிக்கிழமை மாலை, மாஸ்கோவில் உள்ள ஒரு பிரபலமான ஆன்லைன் ஸ்டோரின் வலைத்தளம் அமைதியாக கிடந்தது. சனிக்கிழமை காலை, இந்தத் தளத்தின் தயாரிப்பு மேலாளருக்கு ஏன் தளம் திறக்கப்படவில்லை என்று புரியவில்லை, மேலும் Slack இல் ஆதரவு மற்றும் அவசர அறிவிப்பு அரட்டைகளில் அமைதி நிலவியது. அத்தகைய தவறு எங்களுக்கு ஆறு இலக்கத் தொகையை செலவழித்தது, மேலும் இந்த கடமை அதிகாரி அவரது வேலை.
பொறுப்பு என்பது ஒரு கடினமான திறமை. ஒருவருக்கு அது இருக்கிறதோ இல்லையோ. எனவே, நேர்காணல்களின் போது, ஒரு நபர் பொறுப்பேற்கப் பழகிவிட்டாரா என்பதை மறைமுகமாகக் காட்டும் பல்வேறு கேள்விகளுடன் அதன் இருப்பை அடையாளம் காண முயற்சிக்கிறேன். ஒரு நபர் தனது பெற்றோர் சொன்னதால் பல்கலைக்கழகத்தைத் தேர்ந்தெடுத்ததாக பதிலளித்தால் அல்லது அவர் போதுமான வருமானம் இல்லை என்று அவரது மனைவி சொன்னதால் வேலையை மாற்றினால், அத்தகைய நபர்களுடன் தொடர்பு கொள்ளாமல் இருப்பது நல்லது.
மேம்பாட்டுக் குழுவுடன் தொடர்பு
செயல்பாட்டின் போது பயனர்கள் ஒரு தயாரிப்பில் எளிய சிக்கல்களை எதிர்கொண்டால், ஆதரவு அவற்றைத் தானாகவே தீர்க்கிறது. சிக்கலை மீண்டும் உருவாக்க முயற்சிக்கிறது, பதிவுகளை பகுப்பாய்வு செய்கிறது மற்றும் பல. ஆனால் தயாரிப்பில் பிழை தோன்றினால் என்ன செய்வது? இந்த வழக்கில், ஆதரவு டெவலப்பர்களுக்கு பணியை ஒதுக்குகிறது, இங்குதான் வேடிக்கை தொடங்குகிறது.
டெவலப்பர்கள் தொடர்ந்து அதிக சுமையுடன் உள்ளனர். அவர்கள் புதிய அம்சங்களை உருவாக்குகிறார்கள். விற்பனையுடன் பிழைகளை சரிசெய்வது மிகவும் சுவாரஸ்யமான செயல் அல்ல. அடுத்த ஸ்பிரிண்ட்டை முடிக்க காலக்கெடு நெருங்குகிறது. பின்னர் ஆதரவிலிருந்து விரும்பத்தகாதவர்கள் வந்து கூறுகிறார்கள்: "எல்லாவற்றையும் உடனடியாக விட்டுவிடுங்கள், எங்களுக்கு பிரச்சினைகள் உள்ளன." அத்தகைய பணிகளின் முன்னுரிமை குறைவாக உள்ளது. குறிப்பாக சிக்கல் மிகவும் முக்கியமானதாக இல்லாதபோது மற்றும் தளத்தின் முக்கிய செயல்பாடு செயல்படும் போது, வெளியீட்டு மேலாளர் வீங்கிய கண்களுடன் ஓடாதபோது: "இந்த பணியை அடுத்த வெளியீடு அல்லது ஹாட்ஃபிக்ஸில் அவசரமாகச் சேர்க்கவும்."
இயல்பான அல்லது குறைந்த முன்னுரிமை கொண்ட சிக்கல்கள் வெளியீட்டில் இருந்து வெளியீட்டிற்கு மாற்றப்படுகின்றன. "பணி எப்போது முடிவடையும்?" என்ற கேள்விக்கு. நீங்கள் பின்வரும் பாணியில் பதில்களைப் பெறுவீர்கள்: "மன்னிக்கவும், இப்போது நிறைய பணிகள் உள்ளன, உங்கள் குழுத் தலைவர்களிடம் கேளுங்கள் அல்லது மேலாளரிடம் கேளுங்கள்."
புதிய அம்சங்களை உருவாக்குவதை விட உற்பத்தித்திறன் சிக்கல்கள் அதிக முன்னுரிமை பெறுகின்றன. பயனர்கள் தொடர்ந்து பிழைகள் மீது தடுமாறினால் மோசமான மதிப்புரைகள் வர நீண்ட காலம் இருக்காது. சேதமடைந்த நற்பெயரை மீட்டெடுப்பது கடினம்.
மேம்பாட்டிற்கும் ஆதரவிற்கும் இடையிலான தொடர்பு சிக்கல்கள் DevOps மூலம் தீர்க்கப்படுகின்றன. இந்த சுருக்கமானது ஒரு குறிப்பிட்ட நபரின் வடிவத்தில் அடிக்கடி பயன்படுத்தப்படுகிறது, அவர் வளர்ச்சிக்கான சோதனை சூழல்களை உருவாக்க உதவுகிறது, CICD குழாய்களை உருவாக்குகிறது மற்றும் சோதனை செய்யப்பட்ட குறியீட்டை விரைவாக உற்பத்தியில் கொண்டு வருகிறது. DevOps என்பது மென்பொருள் மேம்பாட்டிற்கான அணுகுமுறையாகும், செயல்பாட்டில் உள்ள அனைத்து பங்கேற்பாளர்களும் ஒருவருக்கொருவர் நெருக்கமாக தொடர்புகொண்டு, மென்பொருள் தயாரிப்புகள் மற்றும் சேவைகளை விரைவாக உருவாக்கவும் புதுப்பிக்கவும் உதவும். அதாவது ஆய்வாளர்கள், டெவலப்பர்கள், சோதனையாளர்கள் மற்றும் ஆதரவு.
இந்த அணுகுமுறையில், ஆதரவு மற்றும் மேம்பாடு ஆகியவை அவற்றின் சொந்த இலக்குகள் மற்றும் நோக்கங்களுடன் வெவ்வேறு துறைகள் அல்ல. வளர்ச்சி செயல்பாட்டில் ஈடுபட்டுள்ளது மற்றும் நேர்மாறாகவும் உள்ளது. விநியோகிக்கப்பட்ட குழுக்களின் பிரபலமான சொற்றொடர்: "பிரச்சினை என் பக்கத்தில் இல்லை" இனி அடிக்கடி அரட்டைகளில் தோன்றாது, மேலும் இறுதி பயனர்கள் கொஞ்சம் மகிழ்ச்சியடைகிறார்கள்.
ஆதாரம்: www.habr.com