பொறியாளர்கள் பயன்பாட்டு கண்காணிப்பில் ஏன் அக்கறை காட்டுவதில்லை?

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

பொறியாளர்கள் பயன்பாட்டு கண்காணிப்பில் ஏன் அக்கறை காட்டுவதில்லை?

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

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

(வழக்கமாக அவர்கள் PNP4Nagios, RRDtool மற்றும் Thruk ஐ நிறுவி, ஸ்லாக்கில் அறிவிப்புகளை அமைத்து நேராக நாகியோசெக்ஸ்சேஞ்சிற்குச் செல்கிறார்கள், ஆனால் இப்போதைக்கு அதை விட்டுவிடுவோம்).

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

கண்காணிப்பது கடினமா?

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

பொறியாளர்கள் பயன்பாட்டு கண்காணிப்பில் ஏன் அக்கறை காட்டுவதில்லை?
புகைப்படத்தின் ஆசிரியர் லூக் செஸ்ஸர் மீது unsplash

(எனது டாஷ்போர்டுகள் நியான் நீலமாக இருக்க வேண்டும் - கனவாக பெருமூச்சு விடுகின்றன -... ம்ம்...)

சேவைகளை வழங்கும் எந்தவொரு மென்பொருளும் அளவீடுகளைச் சேகரிப்பதற்கான வழிமுறையைக் கொண்டிருக்க வேண்டும். அப்பாச்சிக்கு ஒரு தொகுதி உள்ளது mod-status, சர்வர் நிலைப் பக்கத்தைக் காட்டுகிறது. Nginx உள்ளது - stub_status. முக்கிய அளவீடுகளைக் காட்டும் JMX அல்லது தனிப்பயன் இணையப் பயன்பாடுகளை Tomcat கொண்டுள்ளது. MySQL இல் "உலகளாவிய நிலையைக் காட்டு" போன்ற கட்டளை உள்ளது.
டெவலப்பர்கள் தாங்கள் உருவாக்கும் பயன்பாடுகளில் ஏன் இதே போன்ற வழிமுறைகளை உருவாக்கவில்லை?

டெவலப்பர்கள் மட்டும் இதைச் செய்கிறார்களா?

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

பொறியாளர்கள் பயன்பாட்டு கண்காணிப்பில் ஏன் அக்கறை காட்டுவதில்லை?
புகைப்படத்தின் ஆசிரியர் டிம் கவுவ் மீது unsplash

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

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

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

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

இது பொருளைப் பிரிக்கிறது

டெவொப்ஸ் மனப்பான்மை வளர்ச்சி (டெவ்) மற்றும் செயல்பாடுகள் (ஓப்ஸ்) சிந்தனைக்கு இடையே உள்ள சினெர்ஜியை விவரிக்கிறது. "டெவொப்ஸ் செய்" எனக் கூறும் எந்த நிறுவனமும் கண்டிப்பாக:

  1. அவர்கள் விரும்பாத விஷயங்களைச் சொல்வது (தி பிரின்சஸ் ப்ரைட் நினைவுக் குறிப்பு - "இதன் அர்த்தம் என்ன என்று நான் நினைக்கவில்லை!")
  2. தொடர்ச்சியான தயாரிப்பு மேம்பாட்டிற்கான அணுகுமுறையை ஊக்குவிக்கவும்.

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

இடப்புறம், இடப்புறம், லீஇஇ என்று சொன்னேன்-

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

பொறியாளர்கள் பயன்பாட்டு கண்காணிப்பில் ஏன் அக்கறை காட்டுவதில்லை?
புகைப்படத்தின் ஆசிரியர் தயாரிப்பாளர்களால் நேசா மீது unsplash

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

சுருக்கமாக

  1. உங்கள் குதிரையை தண்ணீருக்கு அழைத்துச் செல்லுங்கள். டெவலப்பர்கள் தங்களுக்கு எவ்வளவு சிக்கலைத் தவிர்க்கலாம் என்பதைக் காட்டுங்கள், அவர்களின் பயன்பாடுகளுக்கான சரியான KPIகள் மற்றும் அளவீடுகளை அடையாளம் காண அவர்களுக்கு உதவுங்கள், இதனால் CTO ஆல் கத்தப்படும் தயாரிப்பு உரிமையாளரிடமிருந்து கத்துவது குறைவாக இருக்கும். மெதுவாகவும் அமைதியாகவும் அவர்களை வெளிச்சத்திற்கு கொண்டு வாருங்கள். அது பலனளிக்கவில்லை என்றால், லஞ்சம் கொடுத்து, மிரட்டி, அவர்களுக்கோ அல்லது தயாரிப்பு உரிமையாளருக்கோ லஞ்சம் கொடுத்து, இந்த அளவீடுகளை அப்ளிகேஷன்களில் இருந்து விரைவாகப் பெறுவதைச் செயல்படுத்தி, பின்னர் வரைபடங்களை வரையவும். இது கடினமானதாக இருக்கும், ஏனெனில் இது முன்னுரிமையாகக் கருதப்படாது மற்றும் தயாரிப்பு வரைபடத்தில் பல வருவாய் ஈட்டும் திட்டங்கள் நிலுவையில் இருக்கும். எனவே, தயாரிப்பில் கண்காணிப்பைச் செயல்படுத்த செலவழித்த நேரத்தையும் செலவையும் நியாயப்படுத்த உங்களுக்கு ஒரு வணிக வழக்கு தேவைப்படும்.
  2. சிஸ்டம் இன்ஜினியர்களுக்கு நல்ல இரவு தூக்கம் வர உதவுங்கள். வெளியிடப்படும் எந்தவொரு தயாரிப்புக்கும் "வெளியிடுவோம்" சரிபார்ப்புப் பட்டியலைப் பயன்படுத்துவது நல்லது என்பதை அவர்களுக்குக் காட்டுங்கள். உற்பத்தியில் உள்ள அனைத்து பயன்பாடுகளும் அளவீடுகளால் மூடப்பட்டிருப்பதை உறுதிசெய்வது, டெவலப்பர்கள் என்ன தவறு நடக்கிறது, எங்கு நடக்கிறது என்பதைப் பார்க்க அனுமதிப்பதன் மூலம் இரவில் நன்றாக தூங்குவதற்கு உதவும். எவ்வாறாயினும், எந்தவொரு டெவலப்பர், தயாரிப்பு உரிமையாளர் அல்லது CTO ஐ எரிச்சலூட்டுவதற்கும் ஏமாற்றுவதற்கும் சரியான வழி, தொடர்ந்து எதிர்ப்பதுதான். இந்த நடத்தை நீங்கள் கடைசி நிமிடம் வரை காத்திருந்தால், எந்தவொரு தயாரிப்பின் வெளியீட்டுத் தேதியையும் பாதிக்கும், எனவே மீண்டும் இடதுபுறம் மாற்றி, இந்த சிக்கல்களை உங்கள் திட்டத் திட்டத்தில் விரைவில் பெறவும். தேவைப்பட்டால், தயாரிப்பு சந்திப்புகளுக்குச் செல்லுங்கள். ஒரு போலி மீசை மற்றும் உணர்ந்தேன் அல்லது ஏதாவது அணியுங்கள், அது ஒருபோதும் தோல்வியடையாது. உங்கள் கவலைகளைத் தெரிவிக்கவும், தெளிவான நன்மைகளை வெளிப்படுத்தவும், சுவிசேஷம் செய்யவும்.
  3. மேம்பாடு (dev) மற்றும் செயல்பாடுகள் (ops) ஆகிய இரண்டும் தயாரிப்பு அளவீடுகள் சிவப்பு மண்டலத்திற்குச் செல்வதன் அர்த்தத்தையும் விளைவுகளையும் புரிந்துகொள்வதை உறுதிசெய்யவும். தயாரிப்பு ஆரோக்கியத்தின் ஒரே பாதுகாவலராக Ops ஐ விட்டுவிடாதீர்கள், டெவலப்பர்களும் இதில் ஈடுபட்டுள்ளனர் என்பதை உறுதிப்படுத்தவும் (#productsquads).
  4. பதிவுகள் ஒரு பெரிய விஷயம், ஆனால் அளவீடுகளும். அவற்றை ஒருங்கிணைத்து, பயனற்ற ஒரு பெரிய எரியும் பந்தில் உங்கள் பதிவுகள் குப்பையாகி விடாதீர்கள். டெவலப்பர்களின் பதிவுகளை வேறு யாரும் ஏன் புரிந்து கொள்ள மாட்டார்கள் என்பதை விளக்கி அவர்களுக்குக் காட்டுங்கள், பயனற்ற பதிவுகளை அதிகாலை 3:15 மணிக்கு பார்ப்பது எப்படி இருக்கும் என்பதை அவர்களுக்குக் காட்டுங்கள்.

பொறியாளர்கள் பயன்பாட்டு கண்காணிப்பில் ஏன் அக்கறை காட்டுவதில்லை?
புகைப்படத்தின் ஆசிரியர் மார்கோ ஹார்வட் மீது unsplash

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

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

கருத்தைச் சேர்