എന്തുകൊണ്ടാണ് എഞ്ചിനീയർമാർ ആപ്ലിക്കേഷൻ നിരീക്ഷണത്തെക്കുറിച്ച് ശ്രദ്ധിക്കാത്തത്?

എല്ലാവർക്കും വെള്ളിയാഴ്ച ആശംസകൾ! സുഹൃത്തുക്കളേ, ഇന്ന് ഞങ്ങൾ കോഴ്സിനായി സമർപ്പിച്ചിരിക്കുന്ന പ്രസിദ്ധീകരണങ്ങളുടെ പരമ്പര തുടരുന്നു "DevOps പ്രാക്ടീസുകളും ടൂളുകളും", കാരണം കോഴ്‌സിനായുള്ള പുതിയ ഗ്രൂപ്പിലെ ക്ലാസുകൾ അടുത്ത ആഴ്ച അവസാനം ആരംഭിക്കും. അതിനാൽ, നമുക്ക് ആരംഭിക്കാം!

നിരീക്ഷണമാണ് വെറും. ഇത് അറിയപ്പെടുന്ന വസ്തുതയാണ്. നാഗിയോസ് കൊണ്ടുവരിക, റിമോട്ട് സിസ്റ്റത്തിൽ NRPE പ്രവർത്തിപ്പിക്കുക, NRPE TCP പോർട്ട് 5666-ൽ നാഗിയോസ് കോൺഫിഗർ ചെയ്യുക, നിങ്ങൾക്ക് നിരീക്ഷണമുണ്ട്.

ഇത് വളരെ എളുപ്പമാണ്, അത് രസകരമല്ല. ഇപ്പോൾ നിങ്ങൾക്ക് സിപിയു സമയം, ഡിസ്ക് സബ്സിസ്റ്റം, റാം, നാഗിയോസ്, എൻആർപിഇ എന്നിവയ്‌ക്കായി ഡിഫോൾട്ടായി വിതരണം ചെയ്യുന്ന അടിസ്ഥാന മെട്രിക്‌സ് ഉണ്ട്. എന്നാൽ ഇത് യഥാർത്ഥത്തിൽ "നിരീക്ഷണം" അല്ല. ഇത് ഒരു തുടക്കം മാത്രമാണ്.

(സാധാരണയായി അവർ PNP4Nagios, RRDtool, Thruk എന്നിവ ഇൻസ്റ്റാൾ ചെയ്യുകയും Slack-ൽ അറിയിപ്പുകൾ സജ്ജീകരിക്കുകയും നേരിട്ട് nagiosexchange-ലേക്ക് പോകുകയും ചെയ്യുന്നു, എന്നാൽ നമുക്ക് അത് ഇപ്പോൾ ഉപേക്ഷിക്കാം).

നല്ല നിരീക്ഷണം യഥാർത്ഥത്തിൽ വളരെ സങ്കീർണ്ണമാണ്, നിങ്ങൾ നിരീക്ഷിക്കുന്ന ആപ്ലിക്കേഷന്റെ ഇന്റേണലുകൾ നിങ്ങൾ ശരിക്കും അറിയേണ്ടതുണ്ട്.

നിരീക്ഷണം ബുദ്ധിമുട്ടാണോ?

ഏത് സെർവറും, അത് ലിനക്സോ വിൻഡോസോ ആകട്ടെ, നിർവചനം അനുസരിച്ച് ചില ഉദ്ദേശ്യങ്ങൾ നിറവേറ്റും. അപ്പാച്ചെ, സാംബ, ടോംകാറ്റ്, ഫയൽ സ്റ്റോറേജ്, എൽഡിഎപി - ഈ സേവനങ്ങളെല്ലാം ഒന്നോ അതിലധികമോ കാര്യങ്ങളിൽ ഏറെക്കുറെ അദ്വിതീയമാണ്. ഓരോന്നിനും അതിന്റേതായ പ്രവർത്തനമുണ്ട്, അതിന്റേതായ സവിശേഷതകളുണ്ട്. സെർവർ ലോഡിലായിരിക്കുമ്പോൾ നിങ്ങൾക്ക് താൽപ്പര്യമുണർത്തുന്ന അളവുകൾ, കെപിഐകൾ (കീ പ്രകടന സൂചകങ്ങൾ) ലഭിക്കുന്നതിന് വ്യത്യസ്ത മാർഗങ്ങളുണ്ട്.

ഫോട്ടോയുടെ രചയിതാവ് ലൂക്ക് ചെസ്സർ ഓൺ Unsplash

(എന്റെ ഡാഷ്‌ബോർഡുകൾ നിയോൺ നീലയായിരുന്നെങ്കിൽ എന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു - സ്വപ്നതുല്യമായി നെടുവീർപ്പിടുന്നു -... ഹും...)

സേവനങ്ങൾ നൽകുന്ന ഏതൊരു സോഫ്‌റ്റ്‌വെയറിനും മെട്രിക്‌സ് ശേഖരിക്കാനുള്ള സംവിധാനം ഉണ്ടായിരിക്കണം. അപ്പാച്ചെയ്ക്ക് ഒരു മൊഡ്യൂൾ ഉണ്ട് mod-status, സെർവർ സ്റ്റാറ്റസ് പേജ് പ്രദർശിപ്പിക്കുന്നു. Nginx ഉണ്ട് - stub_status. പ്രധാന അളവുകൾ കാണിക്കുന്ന JMX അല്ലെങ്കിൽ ഇഷ്‌ടാനുസൃത വെബ് ആപ്ലിക്കേഷനുകൾ ടോംകാറ്റിനുണ്ട്. MySQL-ൽ ഒരു കമാൻഡ് ഉണ്ട് "ആഗോള നില കാണിക്കുക" മുതലായവ.
എന്തുകൊണ്ടാണ് ഡവലപ്പർമാർ അവർ സൃഷ്ടിക്കുന്ന ആപ്ലിക്കേഷനുകളിൽ സമാനമായ സംവിധാനങ്ങൾ നിർമ്മിക്കാത്തത്?

ഡെവലപ്പർമാർ മാത്രമാണോ ഇത് ചെയ്യുന്നത്?

മെട്രിക്സ് ഉൾച്ചേർക്കുന്നതിനുള്ള ഒരു പ്രത്യേക തലത്തിലുള്ള നിസ്സംഗത ഡെവലപ്പർമാർക്ക് മാത്രമായി പരിമിതപ്പെടുത്തിയിട്ടില്ല. ടോംകാറ്റ് ഉപയോഗിച്ച് അവർ ആപ്ലിക്കേഷനുകൾ വികസിപ്പിച്ച കമ്പനികളിൽ ഞാൻ ജോലി ചെയ്തു, പൊതുവായ ടോംകാറ്റ് പിശക് ലോഗുകൾ ഒഴികെ അവരുടെ സ്വന്തം അളവുകളോ സേവന പ്രവർത്തനത്തിന്റെ ലോഗുകളോ നൽകിയിട്ടില്ല. ചില ഡെവലപ്പർമാർ പുലർച്ചെ 3:15 ന് അവ വായിക്കാൻ ഭാഗ്യമില്ലാത്ത സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർക്ക് ഒന്നും അർത്ഥമാക്കാത്ത ധാരാളം ലോഗുകൾ സൃഷ്ടിക്കുന്നു.

ഫോട്ടോയുടെ രചയിതാവ് ടിം ഗ ou വ് ഓൺ Unsplash

അത്തരം ഉൽപ്പന്നങ്ങൾ പുറത്തിറക്കാൻ പ്രാപ്തമാക്കുന്ന സിസ്റ്റം എഞ്ചിനീയർമാരും സാഹചര്യത്തിന് ചില ഉത്തരവാദിത്തങ്ങൾ വഹിക്കണം. ലോഗുകളിൽ നിന്ന് അർത്ഥവത്തായ മെട്രിക്‌സ് എക്‌സ്‌ട്രാക്‌റ്റുചെയ്യാൻ കുറച്ച് സിസ്റ്റം എഞ്ചിനീയർമാർക്ക് സമയമോ ശ്രദ്ധയോ ഇല്ല, ആ മെട്രിക്കുകളുടെ സന്ദർഭവും ആപ്ലിക്കേഷൻ പ്രവർത്തനത്തിന്റെ വെളിച്ചത്തിൽ അവയെ വ്യാഖ്യാനിക്കാനുള്ള കഴിവും ഇല്ലാതെ. "ഇപ്പോൾ എന്തെങ്കിലും തെറ്റാണ് (അല്ലെങ്കിൽ ഉടൻ സംഭവിക്കും)" സൂചകങ്ങൾ അല്ലാതെ അതിൽ നിന്ന് എങ്ങനെ പ്രയോജനം നേടാമെന്ന് ചിലർക്ക് മനസ്സിലാകുന്നില്ല.

മെട്രിക്സിന്റെ ആവശ്യകതയെക്കുറിച്ചുള്ള ചിന്താഗതിയിൽ ഒരു മാറ്റം ഡെവലപ്പർമാർക്കിടയിൽ മാത്രമല്ല, സിസ്റ്റം എഞ്ചിനീയർമാർക്കിടയിലും സംഭവിക്കണം.

നിർണായക സംഭവങ്ങളോട് പ്രതികരിക്കുക മാത്രമല്ല, അവ സംഭവിക്കുന്നില്ലെന്ന് ഉറപ്പാക്കുകയും ചെയ്യേണ്ട ഏതൊരു സിസ്റ്റം എഞ്ചിനീയർക്കും, മെട്രിക്‌സിന്റെ അഭാവം സാധാരണയായി അത് ചെയ്യുന്നതിന് തടസ്സമാണ്.

എന്നിരുന്നാലും, സിസ്റ്റം എഞ്ചിനീയർമാർ സാധാരണയായി അവരുടെ കമ്പനിക്ക് പണം സമ്പാദിക്കാൻ കോഡ് ഉപയോഗിച്ച് ടിങ്കർ ചെയ്യാറില്ല. പ്രശ്‌നങ്ങൾ തിരിച്ചറിയുന്നതിലും പ്രകടന പ്രശ്‌നങ്ങളെക്കുറിച്ച് അവബോധം വളർത്തുന്നതിലും മറ്റും സിസ്റ്റം എഞ്ചിനീയറുടെ ഉത്തരവാദിത്തത്തിന്റെ പ്രാധാന്യം മനസ്സിലാക്കുന്ന ലീഡ് ഡെവലപ്പർമാരെ അവർക്ക് ആവശ്യമുണ്ട്.

ഇത് കാര്യത്തെ വിനിയോഗിക്കുന്നു

ഡെവലപ്‌മെന്റ് (dev) പ്രവർത്തനങ്ങളും (ops) ചിന്തയും തമ്മിലുള്ള സമന്വയത്തെ devops മാനസികാവസ്ഥ വിവരിക്കുന്നു. "Devops ചെയ്യുക" എന്ന് അവകാശപ്പെടുന്ന ഏതൊരു കമ്പനിയും ഇനിപ്പറയുന്നവ ചെയ്യണം:

1. അവർ ഒരുപക്ഷേ ചെയ്യാത്ത കാര്യങ്ങൾ പറയുന്നു (ദി പ്രിൻസസ് ബ്രൈഡ് മെമ്മെ പരാമർശിച്ച് - "ഇതിന്റെ അർത്ഥം നിങ്ങൾ കരുതുന്നതെന്താണെന്ന് ഞാൻ കരുതുന്നില്ല!")
2. തുടർച്ചയായ ഉൽപ്പന്ന മെച്ചപ്പെടുത്തലിന്റെ മനോഭാവം പ്രോത്സാഹിപ്പിക്കുക.

നിങ്ങൾക്ക് ഒരു ഉൽപ്പന്നം മെച്ചപ്പെടുത്താനും അത് നിലവിൽ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് അറിയില്ലെങ്കിൽ അത് മെച്ചപ്പെടുത്തിയെന്ന് അറിയാനും കഴിയില്ല. ഒരു ഉൽപ്പന്നത്തിന്റെ ഘടകങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു, അത് ആശ്രയിക്കുന്ന സേവനങ്ങൾ, അതിന്റെ പ്രധാന വേദന പോയിന്റുകൾ, തടസ്സങ്ങൾ എന്നിവ നിങ്ങൾക്ക് മനസ്സിലാകുന്നില്ലെങ്കിൽ ഒരു ഉൽപ്പന്നം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നിങ്ങൾക്ക് അറിയാൻ കഴിയില്ല.
സാധ്യതയുള്ള തടസ്സങ്ങൾ നിങ്ങൾ നിരീക്ഷിച്ചില്ലെങ്കിൽ, പോസ്റ്റ്‌മോർട്ടം എഴുതുമ്പോൾ നിങ്ങൾക്ക് അഞ്ച് എന്തിന് സാങ്കേതികത പിന്തുടരാൻ കഴിയില്ല. ഒരു ഉൽപ്പന്നം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണാനോ അത് "സാധാരണവും സന്തോഷകരവും" എങ്ങനെയാണെന്ന് അറിയുന്നതിനോ നിങ്ങൾക്ക് എല്ലാം ഒരു സ്ക്രീനിൽ ഇടാൻ കഴിയില്ല.

ഇടത്തേക്ക് ഷിഫ്റ്റ്, ഇടത്തേക്ക്, ഞാൻ പറഞ്ഞു LEEEE-

എന്നെ സംബന്ധിച്ചിടത്തോളം, Devops-ന്റെ പ്രധാന തത്വങ്ങളിലൊന്ന് "ഇടത്തേക്ക് മാറ്റുക" എന്നതാണ്. ഈ സന്ദർഭത്തിൽ ഇടത്തേക്ക് ഷിഫ്റ്റ് ചെയ്യുക എന്നതിനർത്ഥം സാധ്യത മാറ്റുക എന്നാണ് (ഉത്തരവാദിത്തമില്ല, എന്നാൽ കഴിവുകൾ മാത്രം) സോഫ്റ്റ്‌വെയർ ഡെലിവറി ലൈഫ് സൈക്കിളിൽ ഇടതുവശത്ത്, പെർഫോമൻസ് മെട്രിക്‌സ് സൃഷ്‌ടിക്കുക, ലോഗുകൾ കൂടുതൽ കാര്യക്ഷമമായി ഉപയോഗിക്കുക തുടങ്ങിയവ പോലുള്ള സിസ്റ്റം എഞ്ചിനീയർമാർ സാധാരണയായി ശ്രദ്ധിക്കുന്ന കാര്യങ്ങൾ ചെയ്യാൻ.

ഫോട്ടോയുടെ രചയിതാവ് നിർമ്മാതാക്കളുടെ നെസ ഓൺ Unsplash

സോഫ്‌റ്റ്‌വെയർ ഡെവലപ്പർമാർക്ക് കമ്പനി അതിന്റെ എല്ലാ രൂപങ്ങളിലും നിരീക്ഷണം നടത്താൻ ഉപയോഗിക്കുന്ന മോണിറ്ററിംഗ് ടൂളുകൾ ഉപയോഗിക്കാനും അറിയാനും കഴിയണം, അളവുകൾ, ലോഗിംഗ്, മോണിറ്ററിംഗ് ഇന്റർഫേസുകൾ കൂടാതെ, ഏറ്റവും പ്രധാനമായി, ഉൽപ്പാദനത്തിൽ അവരുടെ ഉൽപ്പന്നം എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണുക. ഡെവലപ്പർമാർക്ക് മെട്രിക്കുകൾ കാണാനും അവർ എങ്ങനെ കാണപ്പെടുന്നു, ഉൽപ്പന്ന ഉടമ അവരെ അടുത്ത ബ്രീഫിംഗിൽ CTO യ്ക്ക് എങ്ങനെ അവതരിപ്പിക്കും തുടങ്ങിയവയെ സ്വാധീനിക്കുന്നതുവരെ നിരീക്ഷണത്തിൽ പരിശ്രമവും സമയവും നിക്ഷേപിക്കുന്നതിന് നിങ്ങൾക്ക് അവരെ ലഭിക്കില്ല.

താമസിയാതെ സംസാരിക്കുന്നു

1. നിങ്ങളുടെ കുതിരയെ വെള്ളത്തിലേക്ക് നയിക്കുക. ഡവലപ്പർമാർക്ക് തങ്ങൾക്കായി എത്രമാത്രം പ്രശ്‌നങ്ങൾ ഒഴിവാക്കാനാകുമെന്ന് കാണിക്കുക, അവരുടെ ആപ്ലിക്കേഷനുകൾക്കുള്ള ശരിയായ കെപിഐകളും മെട്രിക്കുകളും തിരിച്ചറിയാൻ അവരെ സഹായിക്കുക, അതുവഴി CTO ആക്രോശിക്കുന്ന ഉൽപ്പന്ന ഉടമയിൽ നിന്ന് കരച്ചിൽ കുറവാണ്. സൌമ്യമായും ശാന്തമായും അവരെ വെളിച്ചത്തിലേക്ക് കൊണ്ടുവരിക. അത് പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, കൈക്കൂലി കൊടുക്കുക, ഭീഷണിപ്പെടുത്തുക, അവരെയോ ഉൽപ്പന്ന ഉടമയെയോ കൈക്കൂലി വാങ്ങുക, ഈ അളവുകൾ ആപ്ലിക്കേഷനുകളിൽ നിന്ന് എത്രയും വേഗം ലഭ്യമാക്കുക, തുടർന്ന് ഡയഗ്രമുകൾ വരയ്ക്കുക. ഇത് ഒരു മുൻ‌ഗണനയായി കാണാത്തതിനാൽ ഇത് ബുദ്ധിമുട്ടായിരിക്കും, കൂടാതെ ഉൽപ്പന്ന റോഡ്‌മാപ്പിൽ വരുമാനമുണ്ടാക്കുന്ന നിരവധി പ്രോജക്‌റ്റുകൾ തീർപ്പുകൽപ്പിക്കാതെ കിടക്കുന്നു. അതിനാൽ, ഉൽപ്പന്നത്തിൽ നിരീക്ഷണം നടപ്പിലാക്കാൻ ചെലവഴിച്ച സമയവും ചെലവും ന്യായീകരിക്കാൻ നിങ്ങൾക്ക് ഒരു ബിസിനസ് കേസ് ആവശ്യമാണ്.
2. സിസ്റ്റം എഞ്ചിനീയർമാരെ സുഖമായി ഉറങ്ങാൻ സഹായിക്കുക. പുറത്തിറക്കുന്ന ഏതൊരു ഉൽപ്പന്നത്തിനും "നമുക്ക് റിലീസ് ചെയ്യാം" എന്ന ചെക്ക്‌ലിസ്റ്റ് ഉപയോഗിക്കുന്നത് നല്ല കാര്യമാണെന്ന് അവരെ കാണിക്കുക. പ്രൊഡക്ഷനിലെ എല്ലാ ആപ്ലിക്കേഷനുകളും മെട്രിക്കുകൾ കൊണ്ട് മൂടിയിരിക്കുന്നുവെന്ന് ഉറപ്പാക്കുന്നത്, എന്താണ് തെറ്റ് സംഭവിക്കുന്നതെന്നും എവിടെയാണെന്നും കാണാൻ ഡവലപ്പർമാരെ അനുവദിച്ചുകൊണ്ട് രാത്രിയിൽ നന്നായി ഉറങ്ങാൻ നിങ്ങളെ സഹായിക്കും. എന്നിരുന്നാലും, ഏതെങ്കിലും ഡവലപ്പറെയോ ഉൽപ്പന്ന ഉടമയെയോ സിടിഒയെയോ പ്രകോപിപ്പിക്കാനും നിരാശപ്പെടുത്താനുമുള്ള ശരിയായ മാർഗം നിലനിൽക്കുകയും ചെറുത്തുനിൽക്കുകയും ചെയ്യുക എന്നതാണ്. നിങ്ങൾ അവസാന നിമിഷം വരെ കാത്തിരിക്കുകയാണെങ്കിൽ ഈ സ്വഭാവം ഏതെങ്കിലും ഉൽപ്പന്നത്തിന്റെ റിലീസ് തീയതിയെ ബാധിക്കും, അതിനാൽ വീണ്ടും ഇടത്തേക്ക് മാറ്റി ഈ പ്രശ്നങ്ങൾ എത്രയും വേഗം നിങ്ങളുടെ പ്രോജക്റ്റ് പ്ലാനിലേക്ക് കൊണ്ടുവരിക. ആവശ്യമെങ്കിൽ, ഉൽപ്പന്ന മീറ്റിംഗുകളിലേക്ക് പോകുക. ഒരു വ്യാജ മീശയും തോന്നിയതോ മറ്റോ ധരിക്കുക, അത് ഒരിക്കലും പരാജയപ്പെടില്ല. നിങ്ങളുടെ ആശങ്കകൾ അറിയിക്കുക, വ്യക്തമായ നേട്ടങ്ങൾ പ്രകടിപ്പിക്കുക, സുവിശേഷം നൽകുക.
3. റെഡ് സോണിലേക്ക് നീങ്ങുന്ന ഉൽപ്പന്ന അളവുകളുടെ അർത്ഥവും അനന്തരഫലവും ഡെവലപ്‌മെന്റും (dev) ഓപ്പറേഷനുകളും (ops) മനസ്സിലാക്കുന്നുവെന്ന് ഉറപ്പാക്കുക. ഉൽപ്പന്ന ആരോഗ്യത്തിന്റെ ഏക രക്ഷാധികാരിയായി Ops-നെ ഉപേക്ഷിക്കരുത്, ഡെവലപ്പർമാരും ഉൾപ്പെട്ടിട്ടുണ്ടെന്ന് ഉറപ്പാക്കുക (#productsquads).
4. ലോഗുകൾ ഒരു മഹത്തായ കാര്യമാണ്, എന്നാൽ അളവുകോലുകളും. അവ സംയോജിപ്പിക്കുക, ഉപയോഗശൂന്യതയുടെ ഒരു വലിയ ജ്വലിക്കുന്ന പന്തിൽ നിങ്ങളുടെ ലോഗുകൾ ചവറ്റുകുട്ടയാകാൻ അനുവദിക്കരുത്. ഡെവലപ്പർമാർക്ക് അവരുടെ ലോഗുകൾ മറ്റാർക്കും മനസ്സിലാകാത്തത് എന്തുകൊണ്ടാണെന്ന് വിശദീകരിക്കുകയും അവരെ കാണിക്കുകയും ചെയ്യുക, പുലർച്ചെ 3:15-ന് ഉപയോഗശൂന്യമായ ലോഗുകൾ നോക്കുന്നത് എങ്ങനെയാണെന്ന് അവരെ കാണിക്കുക.

ഫോട്ടോയുടെ രചയിതാവ് മാർക്കോ ഹോർവാട്ട് ഓൺ Unsplash

അത്രയേയുള്ളൂ. പുതിയ മെറ്റീരിയൽ അടുത്ത ആഴ്ച പുറത്തിറങ്ങും. കോഴ്‌സിനെക്കുറിച്ച് കൂടുതലറിയാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ നിങ്ങളെ ക്ഷണിക്കുന്നു തുറന്ന ദിവസം, തിങ്കളാഴ്ച നടക്കും. ഇപ്പോൾ ഞങ്ങൾ പരമ്പരാഗതമായി നിങ്ങളുടെ അഭിപ്രായങ്ങൾക്കായി കാത്തിരിക്കുകയാണ്.

അവലംബം: www.habr.com