ഇപ്പോൾ DevOps എന്ന വിഷയം ഹൈപ്പിലാണ്. തുടർച്ചയായ സംയോജനവും ഡെലിവറി പൈപ്പ് ലൈൻ സിഐ / സിഡി എല്ലാവരും അത് നടപ്പിലാക്കുന്നു. എന്നാൽ സിഐ/സിഡി പൈപ്പ്ലൈനിന്റെ വിവിധ ഘട്ടങ്ങളിലെ വിവര സംവിധാനങ്ങളുടെ വിശ്വാസ്യത ഉറപ്പാക്കുന്നതിൽ മിക്കവരും എപ്പോഴും ശ്രദ്ധ ചെലുത്തുന്നില്ല. ഈ ലേഖനത്തിൽ സോഫ്‌റ്റ്‌വെയർ ഗുണനിലവാര പരിശോധന ഓട്ടോമേറ്റ് ചെയ്യുന്നതിലും അതിന്റെ "സ്വയം സൗഖ്യമാക്കൽ" സാധ്യമായ സാഹചര്യങ്ങൾ നടപ്പിലാക്കുന്നതിലുമുള്ള എന്റെ അനുഭവത്തെക്കുറിച്ച് സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

ഉറവിടം

ഞാൻ ഒരു കമ്പനിയുടെ ഐടി സർവീസ് മാനേജ്‌മെന്റ് വിഭാഗത്തിൽ എഞ്ചിനീയറായി ജോലി ചെയ്യുന്നു "ലാനിറ്റ്-ഇന്റഗ്രേഷൻ". വിവിധ ആപ്ലിക്കേഷൻ പ്രകടനവും ലഭ്യത നിരീക്ഷണ സംവിധാനങ്ങളും നടപ്പിലാക്കുക എന്നതാണ് എന്റെ വൈദഗ്ധ്യത്തിന്റെ പ്രധാന മേഖല. വിവിധ വിപണി വിഭാഗങ്ങളിൽ നിന്നുള്ള ഐടി ഉപഭോക്താക്കളുമായി അവരുടെ ഐടി സേവനങ്ങളുടെ ഗുണനിലവാരം നിരീക്ഷിക്കുന്നത് സംബന്ധിച്ച നിലവിലെ പ്രശ്‌നങ്ങളെക്കുറിച്ച് ഞാൻ പലപ്പോഴും ആശയവിനിമയം നടത്താറുണ്ട്. റിലീസ് സൈക്കിൾ സമയം കുറയ്ക്കുകയും റിലീസുകളുടെ ആവൃത്തി വർദ്ധിപ്പിക്കുകയും ചെയ്യുക എന്നതാണ് പ്രധാന ലക്ഷ്യം. ഇത് തീർച്ചയായും നല്ലതാണ്: കൂടുതൽ റിലീസുകൾ - കൂടുതൽ പുതിയ സവിശേഷതകൾ - കൂടുതൽ സംതൃപ്തരായ ഉപയോക്താക്കൾ - കൂടുതൽ ലാഭം. എന്നാൽ വാസ്തവത്തിൽ, കാര്യങ്ങൾ എല്ലായ്പ്പോഴും നന്നായി പ്രവർത്തിക്കുന്നില്ല. വളരെ ഉയർന്ന വിന്യാസ നിരക്കുകൾ ഉള്ളതിനാൽ, ഞങ്ങളുടെ റിലീസുകളുടെ ഗുണനിലവാരത്തെക്കുറിച്ചുള്ള ചോദ്യം ഉടനടി ഉയർന്നുവരുന്നു. പൂർണ്ണമായും ഓട്ടോമേറ്റഡ് പൈപ്പ്‌ലൈൻ ആണെങ്കിലും, ആപ്ലിക്കേഷന്റെ പ്രവർത്തന സമയത്തെയും ഉപയോക്തൃ അനുഭവത്തെയും ബാധിക്കാതെ സേവനങ്ങളെ ടെസ്റ്റിംഗിൽ നിന്ന് ഉൽപ്പാദനത്തിലേക്ക് മാറ്റുന്നതാണ് ഏറ്റവും വലിയ വെല്ലുവിളി.

ഉപഭോക്താക്കളുമായുള്ള നിരവധി സംഭാഷണങ്ങളുടെ ഫലങ്ങളെ അടിസ്ഥാനമാക്കി, CI യുടെ വിവിധ ഘട്ടങ്ങളിൽ റിലീസ് ഗുണനിലവാര നിയന്ത്രണം, ആപ്ലിക്കേഷൻ വിശ്വാസ്യതയുടെ പ്രശ്നം, അതിന്റെ "സ്വയം-രോഗശാന്തി" (ഉദാഹരണത്തിന്, ഒരു സ്ഥിരതയുള്ള പതിപ്പിലേക്ക് മടങ്ങൽ) സാധ്യത എന്നിവയെക്കുറിച്ച് എനിക്ക് പറയാൻ കഴിയും. /സിഡി പൈപ്പ്‌ലൈൻ ഏറ്റവും ആവേശകരവും പ്രസക്തവുമായ വിഷയങ്ങളിൽ ഒന്നാണ്.

അടുത്തിടെ, ഞാൻ തന്നെ ഉപഭോക്തൃ ഭാഗത്ത് പ്രവർത്തിച്ചു - ഓൺലൈൻ ബാങ്കിംഗ് ആപ്ലിക്കേഷൻ സോഫ്റ്റ്വെയർ പിന്തുണാ സേവനത്തിൽ. ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ആർക്കിടെക്ചർ സ്വയം എഴുതിയ മൈക്രോസർവീസുകളുടെ ഒരു വലിയ സംഖ്യ ഉപയോഗിച്ചു. എല്ലാ ഡെവലപ്പർമാർക്കും വികസനത്തിന്റെ ഉയർന്ന വേഗതയെ നേരിടാൻ കഴിഞ്ഞില്ല എന്നതാണ് ഏറ്റവും സങ്കടകരമായ കാര്യം; ചില മൈക്രോ സർവീസുകളുടെ ഗുണനിലവാരം അനുഭവപ്പെട്ടു, ഇത് അവർക്കും അവരുടെ സ്രഷ്‌ടാക്കൾക്കും തമാശയുള്ള വിളിപ്പേരുകൾക്ക് കാരണമായി. ഈ ഉൽപ്പന്നങ്ങൾ ഏത് വസ്തുക്കളിൽ നിന്നാണ് നിർമ്മിച്ചതെന്നതിനെക്കുറിച്ചുള്ള കഥകൾ ഉണ്ടായിരുന്നു.

"പ്രശ്നത്തിന്റെ രൂപീകരണം"

റിലീസുകളുടെ ഉയർന്ന ആവൃത്തിയും ധാരാളം മൈക്രോസർവീസുകളും ടെസ്റ്റിംഗ് ഘട്ടത്തിലും പ്രവർത്തന ഘട്ടത്തിലും ആപ്ലിക്കേഷന്റെ മൊത്തത്തിലുള്ള പ്രവർത്തനം മനസ്സിലാക്കുന്നത് ബുദ്ധിമുട്ടാക്കുന്നു. മാറ്റങ്ങൾ നിരന്തരം സംഭവിക്കുന്നു, നല്ല നിരീക്ഷണ ഉപകരണങ്ങൾ ഇല്ലാതെ അവയെ നിയന്ത്രിക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്. മിക്കപ്പോഴും, രാവിലെ ഒരു രാത്രി റിലീസ് ചെയ്ത ശേഷം, ഡവലപ്പർമാർ ഒരു പൊടിക്കട്ടിയിൽ ഇരിക്കുകയും ഒന്നും തകരാതിരിക്കാൻ കാത്തിരിക്കുകയും ചെയ്യുന്നു, എന്നിരുന്നാലും എല്ലാ പരിശോധനകളും പരീക്ഷണ ഘട്ടത്തിൽ വിജയിച്ചു.

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

സിഐ/സിഡി പൈപ്പ്ലൈനിന്റെ വിവിധ ഘട്ടങ്ങളിൽ സോഫ്‌റ്റ്‌വെയർ ഗുണനിലവാരം പരിശോധിക്കുന്നതിനുള്ള പ്രക്രിയകൾ നടപ്പിലാക്കുക, അടിയന്തിര സാഹചര്യങ്ങളിൽ സിസ്റ്റം പുനഃസ്ഥാപിക്കുന്നതിനുള്ള വിവിധ സാഹചര്യങ്ങൾ ചേർക്കുക എന്നിവയാണ് പരിഹാരങ്ങളിലൊന്ന്. ഞങ്ങൾക്ക് DevOps ഉണ്ടെന്നും ഞങ്ങൾ ഓർക്കുന്നു. ഒരു പുതിയ ഉൽപ്പന്നം എത്രയും വേഗം ലഭിക്കുമെന്ന് ബിസിനസുകൾ പ്രതീക്ഷിക്കുന്നു. അതിനാൽ, ഞങ്ങളുടെ എല്ലാ ചെക്കുകളും സ്ക്രിപ്റ്റുകളും ഓട്ടോമേറ്റഡ് ആയിരിക്കണം.

ചുമതല രണ്ട് ഘടകങ്ങളായി തിരിച്ചിരിക്കുന്നു:

• ടെസ്റ്റിംഗ് ഘട്ടത്തിൽ അസംബ്ലികളുടെ ഗുണനിലവാര നിയന്ത്രണം (കുറഞ്ഞ നിലവാരമുള്ള അസംബ്ലികൾ പിടിക്കുന്ന പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിന്);
• ഉൽപ്പാദന പരിതസ്ഥിതിയിൽ സോഫ്റ്റ്വെയർ ഗുണനിലവാര നിയന്ത്രണം (പ്രശ്നങ്ങൾ സ്വയമേവ കണ്ടെത്തുന്നതിനുള്ള മെക്കാനിസങ്ങളും അവയുടെ സ്വയം രോഗശാന്തിക്കുള്ള സാധ്യമായ സാഹചര്യങ്ങളും).

അളവുകൾ നിരീക്ഷിക്കുന്നതിനും ശേഖരിക്കുന്നതിനുമുള്ള ഉപകരണം

സെറ്റ് ലക്ഷ്യങ്ങൾ കൈവരിക്കുന്നതിന്, സിഐ/സിഡി പൈപ്പ്ലൈനിന്റെ വിവിധ ഘട്ടങ്ങളിൽ പ്രശ്നങ്ങൾ കണ്ടെത്താനും അവയെ ഓട്ടോമേഷൻ സിസ്റ്റങ്ങളിലേക്ക് മാറ്റാനും കഴിയുന്ന ഒരു നിരീക്ഷണ സംവിധാനം ആവശ്യമാണ്. ഈ സിസ്റ്റം വിവിധ ടീമുകൾക്ക് ഉപയോഗപ്രദമായ അളവുകൾ നൽകുന്നുവെങ്കിൽ അത് ഒരു നല്ല കാര്യമായിരിക്കും: വികസനം, പരിശോധന, പ്രവർത്തനം. ഇത് ബിസിനസ്സിനാണെങ്കിൽ അത് തികച്ചും അത്ഭുതകരമാണ്.

അളവുകൾ ശേഖരിക്കുന്നതിന്, നിങ്ങൾക്ക് വിവിധ സംവിധാനങ്ങളുടെ ഒരു കൂട്ടം ഉപയോഗിക്കാം (പ്രോമിത്യൂസ്, ELK സ്റ്റാക്ക്, Zabbix, മുതലായവ), എന്നാൽ, എന്റെ അഭിപ്രായത്തിൽ, APM-ക്ലാസ് സൊല്യൂഷനുകൾ ഈ ജോലികൾക്ക് ഏറ്റവും അനുയോജ്യമാണ് (അപ്ലിക്കേഷൻ പ്രകടന നിരീക്ഷണം), ഇത് നിങ്ങളുടെ ജീവിതത്തെ വളരെ ലളിതമാക്കും.

പിന്തുണാ സേവനത്തിലെ എന്റെ ജോലിയുടെ ഭാഗമായി, Dynatrace-ൽ നിന്നുള്ള APM ക്ലാസ് സൊല്യൂഷൻ ഉപയോഗിച്ച് ഞാൻ സമാനമായ ഒരു പ്രോജക്റ്റ് ചെയ്യാൻ തുടങ്ങി. ഇപ്പോൾ, ഒരു ഇന്റഗ്രേറ്ററിന് വേണ്ടി പ്രവർത്തിക്കുന്നു, എനിക്ക് മോണിറ്ററിംഗ് സിസ്റ്റം മാർക്കറ്റ് നന്നായി അറിയാം. എന്റെ ആത്മനിഷ്ഠമായ അഭിപ്രായം: അത്തരം പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന് ഡൈനാട്രേസ് ഏറ്റവും അനുയോജ്യമാണ്.
കോഡ് എക്‌സിക്യൂഷൻ തലം വരെ ഗ്രാനുലാർ തലത്തിൽ ഓരോ ഉപയോക്തൃ പ്രവർത്തനത്തിന്റെയും തിരശ്ചീന കാഴ്ച ഡൈനാട്രേസ് നൽകുന്നു. വിവിധ വിവര സേവനങ്ങൾ തമ്മിലുള്ള ആശയവിനിമയത്തിന്റെ മുഴുവൻ ശൃംഖലയും നിങ്ങൾക്ക് ട്രാക്ക് ചെയ്യാൻ കഴിയും: വെബ്, മൊബൈൽ ആപ്ലിക്കേഷനുകളുടെ ഫ്രണ്ട്-എൻഡ് ലെവലുകൾ, ബാക്ക്-എൻഡ് ആപ്ലിക്കേഷൻ സെർവറുകൾ, ഇന്റഗ്രേഷൻ ബസ്, ഡാറ്റാബേസിലേക്കുള്ള ഒരു നിർദ്ദിഷ്ട കോളിലേക്ക്.

ഉറവിടം. സിസ്റ്റം ഘടകങ്ങൾ തമ്മിലുള്ള എല്ലാ ഡിപൻഡൻസികളുടെയും യാന്ത്രിക നിർമ്മാണം

ഉറവിടം. സേവന പ്രവർത്തന പാതയുടെ യാന്ത്രിക കണ്ടെത്തലും നിർമ്മാണവും

വിവിധ ഓട്ടോമേഷൻ ടൂളുകളുമായി സംയോജിപ്പിക്കേണ്ടതുണ്ടെന്നും ഞങ്ങൾ ഓർക്കുന്നു. ഇവിടെ പരിഹാരത്തിന് സൗകര്യപ്രദമായ ഒരു API ഉണ്ട്, അത് വിവിധ അളവുകളും ഇവന്റുകളും അയയ്‌ക്കാനും സ്വീകരിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു.

അടുത്തതായി, ഡൈനാട്രേസ് സിസ്റ്റം ഉപയോഗിച്ച് ഈ പ്രശ്നങ്ങൾ എങ്ങനെ പരിഹരിക്കാമെന്ന് കൂടുതൽ വിശദമായി നോക്കാം.

ടാസ്ക് 1. ടെസ്റ്റിംഗ് ഘട്ടത്തിൽ അസംബ്ലികളുടെ ഗുണനിലവാര നിയന്ത്രണത്തിന്റെ ഓട്ടോമേഷൻ

ആപ്ലിക്കേഷൻ ഡെലിവറി പൈപ്പ്ലൈനിലെ പ്രശ്നങ്ങൾ എത്രയും വേഗം കണ്ടെത്തുക എന്നതാണ് ആദ്യത്തെ വെല്ലുവിളി. "നല്ല" കോഡ് ബിൽഡുകൾ മാത്രമേ ഉൽപ്പാദനത്തിൽ എത്തുകയുള്ളൂ. ഇത് ചെയ്യുന്നതിന്, ടെസ്റ്റിംഗ് ഘട്ടത്തിൽ നിങ്ങളുടെ പൈപ്പ്ലൈനിൽ നിങ്ങളുടെ സേവനങ്ങളുടെ ഗുണനിലവാരം പരിശോധിക്കുന്നതിന് അധിക മോണിറ്ററുകൾ ഉൾപ്പെടുത്തണം.

ഇത് എങ്ങനെ നടപ്പിലാക്കാമെന്നും ഈ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യാമെന്നും നമുക്ക് ഘട്ടം ഘട്ടമായി നോക്കാം:

ഉറവിടം

ഓട്ടോമേറ്റഡ് സോഫ്‌റ്റ്‌വെയർ ഗുണനിലവാര പരിശോധന ഘട്ടങ്ങളുടെ ഒഴുക്ക് ചിത്രം കാണിക്കുന്നു:

1. ഒരു മോണിറ്ററിംഗ് സിസ്റ്റത്തിന്റെ വിന്യാസം (ഏജന്റ്സിന്റെ ഇൻസ്റ്റാളേഷൻ);
2. നിങ്ങളുടെ സോഫ്‌റ്റ്‌വെയറിന്റെ ഗുണനിലവാരം (മെട്രിക്‌സും ത്രെഷോൾഡ് മൂല്യങ്ങളും) വിലയിരുത്തുന്നതിനും അവയെ മോണിറ്ററിംഗ് സിസ്റ്റത്തിലേക്ക് മാറ്റുന്നതിനുമുള്ള ഇവന്റുകൾ തിരിച്ചറിയുക;
3. ലോഡ്, പെർഫോമൻസ് ടെസ്റ്റുകളുടെ ജനറേഷൻ;
4. മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ പ്രകടനവും ലഭ്യതയും ഡാറ്റ ശേഖരിക്കുന്നു;
5. മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ നിന്ന് CI/CD സിസ്റ്റത്തിലേക്ക് സോഫ്റ്റ്‌വെയർ ഗുണനിലവാര വിലയിരുത്തൽ ഇവന്റുകൾ അടിസ്ഥാനമാക്കിയുള്ള ടെസ്റ്റ് ഡാറ്റ കൈമാറ്റം. അസംബ്ലികളുടെ യാന്ത്രിക വിശകലനം.

ഘട്ടം 1. നിരീക്ഷണ സംവിധാനത്തിന്റെ വിന്യാസം

ആദ്യം നിങ്ങളുടെ ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ ഏജന്റ്സ് ഇൻസ്റ്റാൾ ചെയ്യണം. അതേ സമയം, Dynatrace പരിഹാരത്തിന് ഒരു നല്ല സവിശേഷതയുണ്ട് - ഇത് ഒരു OS ഇൻസ്റ്റൻസിൽ (Windows, Linux, AIX) ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള യൂണിവേഴ്സൽ ഏജന്റ് OneAgent ഉപയോഗിക്കുന്നു, നിങ്ങളുടെ സേവനങ്ങൾ സ്വയമേവ കണ്ടെത്തുകയും അവയിൽ നിരീക്ഷണ ഡാറ്റ ശേഖരിക്കാൻ തുടങ്ങുകയും ചെയ്യുന്നു. ഓരോ പ്രക്രിയയ്ക്കും നിങ്ങൾ ഒരു പ്രത്യേക ഏജന്റ് കോൺഫിഗർ ചെയ്യേണ്ടതില്ല. ക്ലൗഡ്, കണ്ടെയ്‌നർ പ്ലാറ്റ്‌ഫോമുകളുടെ സ്ഥിതി സമാനമായിരിക്കും. അതേ സമയം, നിങ്ങൾക്ക് ഏജന്റ് ഇൻസ്റ്റലേഷൻ പ്രക്രിയ ഓട്ടോമേറ്റ് ചെയ്യാനും കഴിയും. "ഇൻഫ്രാസ്ട്രക്ചർ കോഡ്" എന്ന ആശയവുമായി ഡൈനാട്രേസ് തികച്ചും യോജിക്കുന്നു (കോഡ് അല്ലെങ്കിൽ IaC ആയി ഇൻഫ്രാസ്ട്രക്ചർ): എല്ലാ ജനപ്രിയ പ്ലാറ്റ്ഫോമുകൾക്കുമായി റെഡിമെയ്ഡ് സ്ക്രിപ്റ്റുകളും നിർദ്ദേശങ്ങളും ഉണ്ട്. നിങ്ങളുടെ സേവനത്തിന്റെ കോൺഫിഗറേഷനിലേക്ക് നിങ്ങൾ ഏജന്റിനെ ഉൾച്ചേർക്കുക, നിങ്ങൾ അത് വിന്യസിക്കുമ്പോൾ, ഇതിനകം പ്രവർത്തിക്കുന്ന ഒരു ഏജന്റിനൊപ്പം നിങ്ങൾക്ക് ഉടനടി ഒരു പുതിയ സേവനം ലഭിക്കും.

ഘട്ടം 2: നിങ്ങളുടെ സോഫ്റ്റ്‌വെയർ നിലവാരമുള്ള ഇവന്റുകൾ നിർവ്വചിക്കുക

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

അടുത്തതായി, ഓരോ ലെവലിനുമുള്ള അവലോകനത്തിൽ ഏതൊക്കെ മെട്രിക്കുകൾ ഉൾപ്പെടുത്തണമെന്ന് നിങ്ങൾ നിർണ്ണയിക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, ഇത് നിർവ്വഹണ സമയം (ശരാശരി, മീഡിയൻ, പെർസന്റൈലുകൾ മുതലായവയായി തിരിച്ചിരിക്കുന്നു), പിശകുകൾ (ലോജിക്കൽ, സർവീസ്, ഇൻഫ്രാസ്ട്രക്ചർ മുതലായവ) വിവിധ ഇൻഫ്രാസ്ട്രക്ചർ മെട്രിക്സ് (മെമ്മറി ഹീപ്പ്, ഗാർബേജ് കളക്ടർ, ത്രെഡ് കൗണ്ട് മുതലായവ) ആകാം.

DevOps ടീമിന്റെ ഓട്ടോമേഷനും എളുപ്പത്തിലുള്ള ഉപയോഗത്തിനും, "കോഡ് ആയി നിരീക്ഷിക്കൽ" എന്ന ആശയം ദൃശ്യമാകുന്നു. സോഫ്‌റ്റ്‌വെയർ ഗുണനിലവാര ഉറപ്പ് മെട്രിക്‌സ് നിർവചിക്കുന്ന ഒരു ലളിതമായ JSON ഫയൽ ഒരു ഡവലപ്പർ/ടെസ്റ്ററിന് എഴുതാൻ കഴിയും എന്നതാണ് ഞാൻ ഇത് കൊണ്ട് ഉദ്ദേശിക്കുന്നത്.

അത്തരമൊരു JSON ഫയലിന്റെ ഉദാഹരണം നോക്കാം. Dynatrace API-ൽ നിന്നുള്ള ഒബ്ജക്റ്റുകൾ കീ/മൂല്യം ജോഡികളായി ഉപയോഗിക്കുന്നു (API വിവരണം ഇവിടെ കാണാം Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

ഫയൽ സമയ ശ്രേണി നിർവചനങ്ങളുടെ ഒരു നിരയാണ്:

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

അത്തരം ത്രെഷോൾഡുകളുടെ ഉപയോഗത്തിന്റെ ഒരു ഉദാഹരണം ഇനിപ്പറയുന്ന ചിത്രം കാണിക്കുന്നു.

ഉറവിടം

ഘട്ടം 3: ലോഡിംഗ് ജനറേഷൻ

ഞങ്ങളുടെ സേവനത്തിന്റെ ഗുണനിലവാരം ഞങ്ങൾ നിർണ്ണയിച്ചുകഴിഞ്ഞാൽ, ഞങ്ങൾക്ക് ഒരു ടെസ്റ്റ് ലോഡ് സൃഷ്ടിക്കേണ്ടതുണ്ട്. Jmeter, Selenium, Neotys, Gatling മുതലായ, നിങ്ങൾക്ക് സൗകര്യപ്രദമായ ഏത് ടെസ്റ്റിംഗ് ടൂളുകളും നിങ്ങൾക്ക് ഉപയോഗിക്കാം.

നിങ്ങളുടെ ടെസ്റ്റുകളിൽ നിന്ന് വിവിധ മെറ്റാഡാറ്റ ക്യാപ്‌ചർ ചെയ്യാനും ഏത് റിലീസ് സൈക്കിളിലേത്, ഏത് സേവനമാണ് എന്ന് തിരിച്ചറിയാനും ഡൈനാട്രേസിന്റെ മോണിറ്ററിംഗ് സിസ്റ്റം നിങ്ങളെ അനുവദിക്കുന്നു. HTTP ടെസ്റ്റ് അഭ്യർത്ഥനകളിലേക്ക് അധിക തലക്കെട്ടുകൾ ചേർക്കാൻ ശുപാർശ ചെയ്യുന്നു.

എക്‌സ്-ഡൈനാട്രേസ്-ടെസ്റ്റ് എന്ന അധിക ഹെഡർ ഉപയോഗിച്ച്, കാർട്ടിലേക്ക് ഒരു ഇനം ചേർക്കുന്നതിന്റെ പ്രവർത്തനം പരിശോധിക്കുന്നതുമായി ഈ പരിശോധന ബന്ധപ്പെട്ടിരിക്കുന്നുവെന്ന് ഞങ്ങൾ സൂചിപ്പിക്കുന്ന ഒരു ഉദാഹരണം ഇനിപ്പറയുന്ന ചിത്രം കാണിക്കുന്നു.

ഉറവിടം

നിങ്ങൾ ഓരോ ലോഡ് ടെസ്റ്റും പ്രവർത്തിപ്പിക്കുമ്പോൾ, CI/CD സെർവറിൽ നിന്നുള്ള ഇവന്റ് API ഉപയോഗിച്ച് നിങ്ങൾ Dynatrace-ലേക്ക് കൂടുതൽ സന്ദർഭോചിത വിവരങ്ങൾ അയയ്ക്കുന്നു. ഈ രീതിയിൽ, സിസ്റ്റത്തിന് വ്യത്യസ്ത പരിശോധനകൾ തമ്മിൽ വേർതിരിച്ചറിയാൻ കഴിയും.

ഉറവിടം. ലോഡ് ടെസ്റ്റിംഗ് ആരംഭിക്കുന്നതിനെക്കുറിച്ചുള്ള മോണിറ്ററിംഗ് സിസ്റ്റത്തിലെ ഇവന്റ്

ഘട്ടം 4-5. പ്രകടന ഡാറ്റ ശേഖരിക്കുകയും CI/CD സിസ്റ്റത്തിലേക്ക് ഡാറ്റ കൈമാറുകയും ചെയ്യുക

ജനറേറ്റുചെയ്‌ത പരിശോധനയ്‌ക്കൊപ്പം, സേവന ഗുണനിലവാര സൂചകങ്ങൾ പരിശോധിക്കുന്നതിനുള്ള ഡാറ്റ ശേഖരിക്കേണ്ടതിന്റെ ആവശ്യകതയെക്കുറിച്ച് ഒരു ഇവന്റ് മോണിറ്ററിംഗ് സിസ്റ്റത്തിലേക്ക് കൈമാറുന്നു. കീ മെട്രിക്കുകൾ നിർവചിക്കുന്ന ഞങ്ങളുടെ JSON ഫയലും ഇത് വ്യക്തമാക്കുന്നു.

മോണിറ്ററിംഗ് സിസ്റ്റത്തിലേക്ക് അയയ്‌ക്കുന്നതിന് CI/CD സെർവറിൽ സൃഷ്‌ടിച്ച സോഫ്റ്റ്‌വെയറിന്റെ ഗുണനിലവാരം പരിശോധിക്കേണ്ടതിന്റെ ആവശ്യകതയെക്കുറിച്ചുള്ള ഇവന്റ്

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

ഒരു ബിൽഡ് ക്വാളിറ്റി പരിശോധന ആരംഭിക്കുന്നതിനെക്കുറിച്ചുള്ള മോണിറ്ററിംഗ് സിസ്റ്റത്തിലെ ഇവന്റ്. ഉറവിടം

ടെസ്റ്റ് പൂർത്തിയാക്കിയ ശേഷം, സോഫ്റ്റ്വെയർ ഗുണനിലവാരം വിലയിരുത്തുന്നതിനുള്ള എല്ലാ അളവുകളും തുടർച്ചയായ സംയോജന സംവിധാനത്തിലേക്ക് തിരികെ മാറ്റുന്നു, ഉദാഹരണത്തിന്, ഫലങ്ങളിൽ ഒരു റിപ്പോർട്ട് സൃഷ്ടിക്കുന്ന ജെങ്കിൻസ്.

CI/CD സെർവറിലെ അസംബ്ലികളിലെ സ്ഥിതിവിവരക്കണക്കുകളുടെ ഫലം. ഉറവിടം

ഓരോ വ്യക്തിഗത ബിൽഡിനും, മുഴുവൻ ടെസ്റ്റിലുടനീളം ഞങ്ങൾ സജ്ജമാക്കിയ ഓരോ മെട്രിക്കിന്റെയും സ്ഥിതിവിവരക്കണക്കുകൾ ഞങ്ങൾ കാണുന്നു. ചില ത്രെഷോൾഡ് മൂല്യങ്ങളിൽ (മുന്നറിയിപ്പ്, ഗുരുതരമായ ത്രഷ്ഹോൾഡുകൾ) ലംഘനങ്ങൾ ഉണ്ടായിട്ടുണ്ടോ എന്നും ഞങ്ങൾ കാണുന്നു. മൊത്തത്തിലുള്ള മെട്രിക്കുകളുടെ അടിസ്ഥാനത്തിൽ, മുഴുവൻ ബിൽഡും സ്ഥിരതയുള്ളതോ അസ്ഥിരമായതോ പരാജയപ്പെട്ടതോ ആയി അടയാളപ്പെടുത്തിയിരിക്കുന്നു. കൂടാതെ, സൗകര്യാർത്ഥം, നിലവിലെ ബിൽഡിനെ മുമ്പത്തേതുമായി താരതമ്യം ചെയ്യുന്ന റിപ്പോർട്ടിലേക്ക് നിങ്ങൾക്ക് സൂചകങ്ങൾ ചേർക്കാൻ കഴിയും.

CI/CD സെർവറിൽ അസംബ്ലികളെക്കുറിച്ചുള്ള വിശദമായ സ്ഥിതിവിവരക്കണക്കുകൾ കാണുക. ഉറവിടം

രണ്ട് അസംബ്ലികളുടെ വിശദമായ താരതമ്യം

ആവശ്യമെങ്കിൽ, നിങ്ങൾക്ക് Dynatrace ഇന്റർഫേസിലേക്ക് പോകാം, അവിടെ നിങ്ങളുടെ ഓരോ ബിൽഡിന്റെയും സ്ഥിതിവിവരക്കണക്കുകൾ കൂടുതൽ വിശദമായി കാണാനും അവ പരസ്പരം താരതമ്യം ചെയ്യാനും കഴിയും.

ഡൈനാട്രേസിലെ ബിൽഡ് സ്റ്റാറ്റിസ്റ്റിക്സിന്റെ താരതമ്യം. ഉറവിടം
 
കണ്ടെത്തലുകൾ

തൽഫലമായി, തുടർച്ചയായ സംയോജന പൈപ്പ്ലൈനിൽ ഓട്ടോമേറ്റഡ് "ഒരു സേവനമായി നിരീക്ഷണം" സേവനം ഞങ്ങൾക്ക് ലഭിക്കുന്നു. ഡെവലപ്പർ അല്ലെങ്കിൽ ടെസ്റ്റർ ഒരു JSON ഫയലിലെ മെട്രിക്കുകളുടെ ഒരു ലിസ്റ്റ് നിർവചിക്കേണ്ടതുണ്ട്, മറ്റെല്ലാം സ്വയമേവ സംഭവിക്കും. റിലീസുകളുടെ സുതാര്യമായ ഗുണനിലവാര നിയന്ത്രണം ഞങ്ങൾക്ക് ലഭിക്കുന്നു: പ്രകടനം, വിഭവ ഉപഭോഗം അല്ലെങ്കിൽ ആർക്കിടെക്ചറൽ റിഗ്രഷനുകൾ എന്നിവയെക്കുറിച്ചുള്ള എല്ലാ അറിയിപ്പുകളും.

ടാസ്ക് 2. ഒരു പ്രൊഡക്ഷൻ പരിതസ്ഥിതിയിൽ സോഫ്റ്റ്വെയർ ഗുണനിലവാര നിയന്ത്രണത്തിന്റെ ഓട്ടോമേഷൻ

അതിനാൽ, പൈപ്പ്ലൈനിലെ ടെസ്റ്റിംഗ് ഘട്ടത്തിൽ നിരീക്ഷണ പ്രക്രിയ എങ്ങനെ ഓട്ടോമേറ്റ് ചെയ്യാം എന്ന പ്രശ്നം ഞങ്ങൾ പരിഹരിച്ചു. ഇതുവഴി ഉൽപ്പാദന പരിതസ്ഥിതിയിൽ എത്തുന്ന നിലവാരം കുറഞ്ഞ അസംബ്ലികളുടെ ശതമാനം ഞങ്ങൾ കുറയ്ക്കുന്നു.

എന്നാൽ മോശം സോഫ്‌റ്റ്‌വെയർ വിൽക്കപ്പെടുകയോ അല്ലെങ്കിൽ എന്തെങ്കിലും തകരാറിലാകുകയോ ചെയ്‌താൽ എന്തുചെയ്യും. ഒരു ഉട്ടോപ്യയെ സംബന്ധിച്ചിടത്തോളം, പ്രശ്നങ്ങൾ സ്വയമേവ കണ്ടെത്തുന്നതിനുള്ള മെക്കാനിസങ്ങൾ ഞങ്ങൾ ആഗ്രഹിച്ചു, സാധ്യമെങ്കിൽ, കുറഞ്ഞത് രാത്രിയിലെങ്കിലും സിസ്റ്റം തന്നെ അതിന്റെ പ്രവർത്തനം പുനഃസ്ഥാപിക്കാൻ.

ഇത് ചെയ്യുന്നതിന്, മുമ്പത്തെ വിഭാഗവുമായി സാമ്യമുള്ളതിനാൽ, പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിൽ ഓട്ടോമാറ്റിക് സോഫ്‌റ്റ്‌വെയർ ഗുണനിലവാര പരിശോധനകൾ നൽകുകയും സിസ്റ്റം സ്വയം സുഖപ്പെടുത്തുന്നതിനുള്ള സാഹചര്യങ്ങളെ അടിസ്ഥാനമാക്കി അവയെ അടിസ്ഥാനമാക്കുകയും വേണം.

കോഡായി സ്വയം ശരിയാക്കുക

മിക്ക കമ്പനികൾക്കും ഇതിനകം തന്നെ വിവിധ തരത്തിലുള്ള പൊതുവായ പ്രശ്‌നങ്ങളെക്കുറിച്ചുള്ള അറിവിന്റെ അടിത്തറയും അവ പരിഹരിക്കാനുള്ള പ്രവർത്തനങ്ങളുടെ ഒരു പട്ടികയും ഉണ്ട്, ഉദാഹരണത്തിന്, പ്രോസസ്സുകൾ പുനരാരംഭിക്കുക, ഉറവിടങ്ങൾ വൃത്തിയാക്കുക, പതിപ്പുകൾ തിരികെ കൊണ്ടുവരിക, അസാധുവായ കോൺഫിഗറേഷൻ മാറ്റങ്ങൾ പുനഃസ്ഥാപിക്കുക, ഘടകങ്ങളുടെ എണ്ണം കൂട്ടുകയോ കുറയ്ക്കുകയോ ചെയ്യുക. ക്ലസ്റ്റർ, നീല അല്ലെങ്കിൽ പച്ച രൂപരേഖ മാറ്റുക തുടങ്ങിയവ.

ഈ ഉപയോഗ കേസുകൾ ഞാൻ സംസാരിക്കുന്ന പല ടീമുകളാലും വർഷങ്ങളായി അറിയപ്പെട്ടിരുന്നുവെങ്കിലും, കുറച്ച് പേർ അവയെ ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനെക്കുറിച്ച് ചിന്തിക്കുകയോ നിക്ഷേപിക്കുകയോ ചെയ്തിട്ടുണ്ട്.

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

നിങ്ങളുടെ മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ നിന്നുള്ള ഏതൊരു മെട്രിക്കും സ്‌ക്രിപ്റ്റ് സമാരംഭിക്കുന്നതിനുള്ള ഒരു ട്രിഗറായി പ്രവർത്തിക്കും, പ്രധാന കാര്യം, ഈ അളവുകൾ എല്ലാം മോശമാണെന്ന് കൃത്യമായി നിർണ്ണയിക്കുന്നു, കാരണം ഉൽ‌പാദനപരമായ അന്തരീക്ഷത്തിൽ നിങ്ങൾ തെറ്റായ പോസിറ്റീവ് ലഭിക്കാൻ ആഗ്രഹിക്കുന്നില്ല.

നിങ്ങൾക്ക് ഏത് സിസ്റ്റമോ സെറ്റ് സിസ്റ്റമോ ഉപയോഗിക്കാം: പ്രോമിത്യൂസ്, ELK സ്റ്റാക്ക്, സാബിക്സ് മുതലായവ. എന്നാൽ നിങ്ങളുടെ ജീവിതം എളുപ്പമാക്കാൻ സഹായിക്കുന്ന ഒരു എപിഎം സൊല്യൂഷനെ അടിസ്ഥാനമാക്കിയുള്ള ചില ഉദാഹരണങ്ങൾ ഞാൻ നൽകും (ഡൈനാട്രേസ് വീണ്ടും ഒരു ഉദാഹരണമായിരിക്കും).

ഒന്നാമതായി, ആപ്ലിക്കേഷൻ പ്രവർത്തനത്തിന്റെ കാര്യത്തിൽ പ്രകടനവുമായി ബന്ധപ്പെട്ട എല്ലാം ഉണ്ട്. നിങ്ങൾക്ക് ട്രിഗറുകളായി ഉപയോഗിക്കാൻ കഴിയുന്ന വിവിധ തലങ്ങളിൽ നൂറുകണക്കിന് അളവുകൾ പരിഹാരം നൽകുന്നു:

• ഉപയോക്തൃ നില (ബ്രൗസറുകൾ, മൊബൈൽ ആപ്ലിക്കേഷനുകൾ, IoT ഉപകരണങ്ങൾ, ഉപയോക്തൃ പെരുമാറ്റം, പരിവർത്തനം മുതലായവ);
• സേവനത്തിന്റെയും പ്രവർത്തനങ്ങളുടെയും നില (പ്രകടനം, ലഭ്യത, പിശകുകൾ മുതലായവ);
• ആപ്ലിക്കേഷൻ ഇൻഫ്രാസ്ട്രക്ചർ ലെവൽ (ഹോസ്റ്റ് OS മെട്രിക്സ്, JMX, MQ, വെബ്-സെർവർ മുതലായവ);
• പ്ലാറ്റ്ഫോം ലെവൽ (വെർച്വലൈസേഷൻ, ക്ലൗഡ്, കണ്ടെയ്നർ മുതലായവ).

ഡൈനാട്രേസിലെ മോണിറ്ററിംഗ് ലെവലുകൾ. ഉറവിടം

രണ്ടാമതായി, ഞാൻ നേരത്തെ പറഞ്ഞതുപോലെ, Dynatrace-ന് ഒരു ഓപ്പൺ API ഉണ്ട്, ഇത് വിവിധ മൂന്നാം കക്ഷി സിസ്റ്റങ്ങളുമായി സംയോജിപ്പിക്കുന്നത് വളരെ എളുപ്പമാക്കുന്നു. ഉദാഹരണത്തിന്, നിയന്ത്രണ പാരാമീറ്ററുകൾ കവിയുമ്പോൾ ഓട്ടോമേഷൻ സിസ്റ്റത്തിലേക്ക് ഒരു അറിയിപ്പ് അയയ്ക്കുന്നു.

അൻസിബിളുമായി ഇടപഴകുന്നതിനുള്ള ഒരു ഉദാഹരണം ചുവടെയുണ്ട്.

ഉറവിടം

ഏത് തരത്തിലുള്ള ഓട്ടോമേഷൻ ചെയ്യാമെന്നതിന്റെ കുറച്ച് ഉദാഹരണങ്ങൾ ഞാൻ ചുവടെ നൽകും. ഇത് കേസുകളുടെ ഒരു ഭാഗം മാത്രമാണ്; നിങ്ങളുടെ പരിതസ്ഥിതിയിലെ അവരുടെ ലിസ്റ്റ് നിങ്ങളുടെ ഭാവനയും നിങ്ങളുടെ നിരീക്ഷണ ഉപകരണങ്ങളുടെ കഴിവുകളും മാത്രം പരിമിതപ്പെടുത്താം.

1. മോശം വിന്യാസം - പതിപ്പ് റോൾബാക്ക്

ഒരു ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ ഞങ്ങൾ എല്ലാം നന്നായി പരീക്ഷിച്ചാലും, ഒരു പുതിയ പതിപ്പ് ഒരു പ്രൊഡക്ഷൻ എൻവയോൺമെന്റിൽ നിങ്ങളുടെ ആപ്ലിക്കേഷനെ നശിപ്പിക്കാനുള്ള ഒരു അവസരമുണ്ട്. അതേ മാനുഷിക ഘടകം റദ്ദാക്കപ്പെട്ടിട്ടില്ല.

സേവനത്തിലെ പ്രവർത്തനങ്ങളുടെ നിർവ്വഹണ സമയത്ത് മൂർച്ചയുള്ള ജമ്പ് ഉണ്ടെന്ന് ഇനിപ്പറയുന്ന ചിത്രത്തിൽ കാണാം. ഈ ജമ്പിന്റെ ആരംഭം ആപ്ലിക്കേഷനിലേക്കുള്ള വിന്യാസ സമയവുമായി പൊരുത്തപ്പെടുന്നു. ഈ വിവരങ്ങളെല്ലാം ഞങ്ങൾ ഓട്ടോമേഷൻ സിസ്റ്റത്തിലേക്ക് ഇവന്റുകളായി കൈമാറുന്നു. ഞങ്ങൾ സജ്ജമാക്കിയ സമയത്തിന് ശേഷം സേവനത്തിന്റെ പ്രകടനം സാധാരണ നിലയിലായില്ലെങ്കിൽ, പതിപ്പിനെ പഴയതിലേക്ക് തിരികെ കൊണ്ടുവരുന്ന ഒരു സ്ക്രിപ്റ്റ് സ്വയമേവ വിളിക്കപ്പെടും.

വിന്യാസത്തിനു ശേഷമുള്ള പ്രവർത്തനങ്ങളുടെ പ്രകടനത്തിന്റെ അപചയം. ഉറവിടം

2. റിസോഴ്സ് ലോഡിംഗ് 100% - റൂട്ടിംഗിലേക്ക് ഒരു നോഡ് ചേർക്കുക

ഇനിപ്പറയുന്ന ഉദാഹരണത്തിൽ, ഘടകങ്ങളിലൊന്ന് 100% സിപിയു ലോഡ് അനുഭവപ്പെടുന്നതായി മോണിറ്ററിംഗ് സിസ്റ്റം നിർണ്ണയിക്കുന്നു.

സിപിയു ലോഡ് 100%
 
ഈ സംഭവത്തിന് നിരവധി വ്യത്യസ്ത സാഹചര്യങ്ങളുണ്ട്. ഉദാഹരണത്തിന്, സേവനത്തിലെ ലോഡ് വർദ്ധിക്കുന്നതുമായി വിഭവങ്ങളുടെ അഭാവം ബന്ധപ്പെട്ടിട്ടുണ്ടോ എന്ന് മോണിറ്ററിംഗ് സിസ്റ്റം അധികമായി പരിശോധിക്കുന്നു. അങ്ങനെയാണെങ്കിൽ, റൂട്ടിംഗിലേക്ക് സ്വയമേവ ഒരു നോഡ് ചേർക്കുന്ന ഒരു സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യപ്പെടുന്നു, അതുവഴി സിസ്റ്റത്തിന്റെ മൊത്തത്തിലുള്ള പ്രവർത്തനക്ഷമത പുനഃസ്ഥാപിക്കുന്നു.

ഒരു സംഭവത്തിന് ശേഷം സ്കെയിലിംഗ്

3. ഹാർഡ് ഡ്രൈവിൽ സ്ഥലത്തിന്റെ അഭാവം - ഡിസ്ക് ക്ലീനിംഗ്

പലരും ഇതിനകം തന്നെ ഈ പ്രക്രിയകൾ യാന്ത്രികമാക്കിയിട്ടുണ്ടെന്ന് ഞാൻ കരുതുന്നു. APM ഉപയോഗിച്ച്, നിങ്ങൾക്ക് ഡിസ്ക് സബ്സിസ്റ്റത്തിലെ ശൂന്യമായ ഇടം നിരീക്ഷിക്കാനും കഴിയും. സ്ഥലമില്ലെങ്കിലോ ഡിസ്ക് സാവധാനത്തിൽ പ്രവർത്തിക്കുകയാണെങ്കിലോ, അത് വൃത്തിയാക്കുന്നതിനോ സ്ഥലം ചേർക്കുന്നതിനോ ഞങ്ങൾ ഒരു സ്ക്രിപ്റ്റ് വിളിക്കുന്നു.

ഡിസ്ക് ലോഡ് 100%
 
4. കുറഞ്ഞ ഉപയോക്തൃ പ്രവർത്തനം അല്ലെങ്കിൽ കുറഞ്ഞ പരിവർത്തനം - നീല, പച്ച ശാഖകൾക്കിടയിൽ മാറൽ

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

സോഫ്‌റ്റ്‌വെയർ ശാഖകൾക്കിടയിൽ മാറിയതിനുശേഷം പരിവർത്തന നിരക്ക് കുറയുന്നു. ഉറവിടം

യാന്ത്രിക പ്രശ്നം കണ്ടെത്തുന്നതിനുള്ള സംവിധാനങ്ങൾ

അവസാനമായി, ഞാൻ ഡൈനാട്രേസിനെ ഏറ്റവും ഇഷ്ടപ്പെടുന്നതിന്റെ ഒരു ഉദാഹരണം കൂടി ഞാൻ നിങ്ങൾക്ക് തരാം.

ഒരു ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ അസംബ്ലികളുടെ ഗുണനിലവാര പരിശോധന ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള എന്റെ കഥയുടെ ഭാഗത്ത്, ഞങ്ങൾ എല്ലാ പരിധി മൂല്യങ്ങളും സ്വമേധയാ നിർണ്ണയിച്ചു. ഒരു ടെസ്റ്റ് പരിതസ്ഥിതിക്ക് ഇത് സാധാരണമാണ്; ലോഡിനെ ആശ്രയിച്ച് ഓരോ ടെസ്റ്റിനും മുമ്പുള്ള സൂചകങ്ങൾ ടെസ്റ്റർ തന്നെ നിർണ്ണയിക്കുന്നു. ഒരു ഉൽ‌പാദന അന്തരീക്ഷത്തിൽ, വിവിധ അടിസ്ഥാന സംവിധാനങ്ങൾ കണക്കിലെടുത്ത് പ്രശ്നങ്ങൾ സ്വയമേവ കണ്ടെത്തുന്നത് അഭികാമ്യമാണ്.

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

ഘടകങ്ങൾ തമ്മിലുള്ള ഡിപൻഡൻസികൾ സ്വയമേവ വിശകലനം ചെയ്യുന്നതിലൂടെ, പ്രശ്നമുള്ള സേവനമാണോ മൂലകാരണം എന്ന് മാത്രമല്ല, മറ്റ് സേവനങ്ങളിലുള്ള അതിന്റെ ആശ്രിതത്വവും Dynatrace നിർണ്ണയിക്കുന്നു. ചുവടെയുള്ള ഉദാഹരണത്തിൽ, ഇടപാട് നടത്തിപ്പിനുള്ളിലെ ഓരോ സേവനത്തിന്റെയും ആരോഗ്യം Dynatrace സ്വയമേവ നിരീക്ഷിക്കുകയും വിലയിരുത്തുകയും ചെയ്യുന്നു, Golang സേവനത്തെ മൂലകാരണമായി തിരിച്ചറിയുന്നു.

ഒരു പരാജയത്തിന്റെ മൂലകാരണം നിർണ്ണയിക്കുന്നതിനുള്ള ഒരു ഉദാഹരണം. ഉറവിടം

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

അവയിൽ എല്ലാ ഘടകങ്ങളും ഇവന്റുകളും പ്രദർശിപ്പിക്കുന്നതിലൂടെ ഉയർന്നുവരുന്ന പ്രശ്നത്തിന്റെ ദൃശ്യവൽക്കരണം

മോണിറ്ററിംഗ് സിസ്റ്റം ഉയർന്നുവന്ന പ്രശ്നവുമായി ബന്ധപ്പെട്ട സംഭവങ്ങളുടെ പൂർണ്ണമായ കാലഗണന ശേഖരിച്ചു. ടൈംലൈനിന് താഴെയുള്ള വിൻഡോയിൽ ഓരോ ഘടകങ്ങളിലെയും എല്ലാ പ്രധാന ഇവന്റുകളും ഞങ്ങൾ കാണുന്നു. ഈ സംഭവങ്ങളെ അടിസ്ഥാനമാക്കി, നിങ്ങൾക്ക് കോഡ് സ്ക്രിപ്റ്റുകളുടെ രൂപത്തിൽ യാന്ത്രിക തിരുത്തലിനുള്ള നടപടിക്രമങ്ങൾ സജ്ജമാക്കാൻ കഴിയും.

കൂടാതെ, ഒരു മോണിറ്ററിംഗ് സിസ്റ്റം സർവീസ് ഡെസ്ക് അല്ലെങ്കിൽ ഒരു ബഗ് ട്രാക്കർ എന്നിവയുമായി സംയോജിപ്പിക്കാൻ ഞാൻ നിങ്ങളെ ഉപദേശിക്കുന്നു. ഒരു പ്രശ്നം സംഭവിക്കുമ്പോൾ, പ്രൊഡക്ഷൻ പരിതസ്ഥിതിയിലെ കോഡ് തലത്തിൽ അത് വിശകലനം ചെയ്യുന്നതിനായി ഡെവലപ്പർമാർക്ക് പൂർണ്ണമായ വിവരങ്ങൾ വേഗത്തിൽ ലഭിക്കും.

തീരുമാനം

തൽഫലമായി, പൈപ്പ്‌ലൈനിൽ ബിൽറ്റ്-ഇൻ ഓട്ടോമേറ്റഡ് സോഫ്‌റ്റ്‌വെയർ ഗുണനിലവാര പരിശോധനകളുള്ള ഒരു CI/CD പൈപ്പ്‌ലൈനിൽ ഞങ്ങൾ അവസാനിച്ചു. നിലവാരം കുറഞ്ഞ അസംബ്ലികളുടെ എണ്ണം ഞങ്ങൾ കുറയ്ക്കുന്നു, സിസ്റ്റത്തിന്റെ മൊത്തത്തിലുള്ള വിശ്വാസ്യത വർദ്ധിപ്പിക്കുന്നു, ഞങ്ങളുടെ സിസ്റ്റം ഇപ്പോഴും പരാജയപ്പെടുകയാണെങ്കിൽ, അത് പുനഃസ്ഥാപിക്കുന്നതിനുള്ള സംവിധാനങ്ങൾ ഞങ്ങൾ സമാരംഭിക്കുന്നു.

സോഫ്‌റ്റ്‌വെയർ ഗുണനിലവാര നിരീക്ഷണം ഓട്ടോമേറ്റ് ചെയ്യുന്നതിനുള്ള ശ്രമം തീർച്ചയായും മൂല്യവത്താണ്; ഇത് എല്ലായ്പ്പോഴും ഒരു പെട്ടെന്നുള്ള പ്രക്രിയയല്ല, എന്നാൽ കാലക്രമേണ അത് ഫലം കായ്ക്കും. പ്രൊഡക്ഷൻ പരിതസ്ഥിതിയിൽ ഒരു പുതിയ സംഭവം പരിഹരിച്ചതിന് ശേഷം, നിർമ്മാണത്തിലേക്ക് പ്രവേശിക്കുന്നതിൽ നിന്ന് മോശമായ ബിൽഡ് ഒഴിവാക്കുന്നതിന് ടെസ്റ്റ് പരിതസ്ഥിതിയിൽ പരിശോധനകൾക്കായി ഏത് മോണിറ്ററുകൾ ചേർക്കണമെന്ന് നിങ്ങൾ ഉടൻ ചിന്തിക്കണമെന്ന് ഞാൻ ശുപാർശ ചെയ്യുന്നു, കൂടാതെ ഈ പ്രശ്നങ്ങൾ സ്വയമേവ ശരിയാക്കാൻ ഒരു സ്ക്രിപ്റ്റ് സൃഷ്ടിക്കുക.

നിങ്ങളുടെ ശ്രമങ്ങളിൽ എന്റെ ഉദാഹരണങ്ങൾ നിങ്ങളെ സഹായിക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. സ്വയം രോഗശാന്തി സംവിധാനങ്ങൾ നടപ്പിലാക്കാൻ ഉപയോഗിക്കുന്ന അളവുകളുടെ നിങ്ങളുടെ ഉദാഹരണങ്ങൾ കാണാനും എനിക്ക് താൽപ്പര്യമുണ്ട്.

ഉറവിടം

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