കേസ് രീതി: മാനുഷിക നിരീക്ഷണം

Dziiiin! സമയം പുലർച്ചെ 3 മണി, നിങ്ങൾ ഒരു അത്ഭുതകരമായ സ്വപ്നം കാണുന്നു, പെട്ടെന്ന് ഒരു കോൾ. നിങ്ങൾ ഈ ആഴ്ച ഡ്യൂട്ടിയിലാണ്, പ്രത്യക്ഷത്തിൽ എന്തോ സംഭവിച്ചു. എന്താണ് കുഴപ്പമെന്ന് കണ്ടെത്താൻ ഓട്ടോമേറ്റഡ് സിസ്റ്റം വിളിക്കുന്നു. ആധുനിക കമ്പ്യൂട്ടർ സിസ്റ്റങ്ങൾ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഒരു പ്രധാന വശമാണിത്, എന്നാൽ ആളുകൾക്ക് അറിയിപ്പുകൾ എങ്ങനെ മികച്ചതാക്കാമെന്ന് നോക്കാം.

വ്യത്യസ്ത മോണിറ്ററിംഗ് ടീമുകളിൽ എന്റെ നിരവധി ദശാബ്ദങ്ങളായി എന്റെ ചുമതലകളിൽ ജനിച്ച മോണിറ്ററിംഗ് ഫിലോസഫിയുമായി പരിചയപ്പെടുക. റോബ് ഇവാഷ്ചുക്കിൽ നിന്നുള്ള യഥാർത്ഥ ബൈബിളാണ് അവളെ ഏറെ സ്വാധീനിച്ചത് അലേർട്ടിംഗിനെക്കുറിച്ചുള്ള എന്റെ തത്വശാസ്ത്രം (എന്റെ അറിയിപ്പ് തത്വശാസ്ത്രം) എന്ന പുസ്തകത്തിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട് Google SRE, ജോൺ അൽസ്പാഗ് എഴുതിയ പുസ്തകം അലേർട്ട് ഡിസൈനിനുള്ള പരിഗണനകൾ (അലേർട്ടുകൾ സജ്ജീകരിക്കുന്നതിനുള്ള കുറിപ്പുകൾ).

കെല്ലി ഡൺ, അരിജിത് മുഖേരി и മാക്സിം പെറ്റാസോണി - പോസ്റ്റ് എഡിറ്റ് ചെയ്യുന്നതിനുള്ള നിങ്ങളുടെ സഹായത്തിന് നന്ദി.

എന്താണ് കേസ്?

പോലെ മനോഹരമായ ഒരു ചുരുക്കെഴുത്ത് കൊണ്ട് വരാൻ ഞാൻ തീരുമാനിച്ചു ബ്രണ്ടൻ ഗ്രെഗിന്റെ ഉപയോഗ രീതി അഥവാ ടോം വിൽക്കിയുടെ റെഡ് രീതി. ഞാൻ അതിനെ വിളിക്കുന്നു കേസ് രീതി. ഓട്ടോമാറ്റിക് മോണിറ്ററിംഗിൽ പ്രവർത്തിക്കുമ്പോൾ ശ്രദ്ധിക്കേണ്ട നാല് പോയിന്റുകൾ അദ്ദേഹം വിവരിക്കുന്നു:

• Cഓൺടെക്സ്റ്റ്-ഹെവി (സന്ദർഭ ബന്ധിതം)
• Aപ്രവർത്തനക്ഷമമായ (പ്രായോഗിക മൂല്യം)
• Sലക്ഷണം അടിസ്ഥാനമാക്കിയുള്ളത് (ലക്ഷണങ്ങളിൽ ഊന്നൽ)
• Eവിലമതിക്കുന്നു (ഗ്രേഡ്)

നിങ്ങൾ CASE ഉപയോഗിക്കുകയാണെങ്കിൽ, ആരോഗ്യകരമായ നിസ്സംഗതയോടെയാണ് നിങ്ങൾ അറിയിപ്പുകളെ കൈകാര്യം ചെയ്യുന്നത്, രാത്രിയിൽ ആളുകളെ ഉണർത്തരുത്. ഉപയോഗക്ഷമതയ്ക്കും ഫലപ്രാപ്തിക്കും വേണ്ടി നിരീക്ഷണം പതിവായി വിലയിരുത്തണം. ഒരു വ്യക്തിക്ക് അറിയിപ്പ് ലഭിക്കുമ്പോൾ, അവർക്ക് മികച്ച മാനസിക മാതൃകകളും കൂടുതൽ ആത്മവിശ്വാസവും ഉണ്ടാകും.

ഓർമ്മിക്കുന്നത് എളുപ്പമാക്കുന്നതിന്, നിങ്ങൾക്ക് ഒരു കേസ് ആവശ്യമാണെന്ന് സങ്കൽപ്പിക്കുക [അതായത്, ഒരു കേസ്, ഒരു കാരണം - വിവർത്തകന്റെ കുറിപ്പ്] ഓരോ അലേർട്ടും ന്യായീകരിക്കാൻ. :സൺഗ്ലാസ്:

പിന്നെ എന്തിനാണ് ഇതെല്ലാം?

ഡ്യൂട്ടിയിൽ ഇരിക്കുന്നത് ഒരു വേദനയാണ്. പല കാരണങ്ങളാൽ. CASE അവരെയെല്ലാം ഇല്ലാതാക്കില്ല. എന്നാൽ ഇത് ഉപയോഗിച്ച്, മികച്ച അറിയിപ്പുകൾ ലഭിക്കുന്നതിന് നിങ്ങൾ രാത്രിയിൽ ഉണരും. ഈ രീതി വിവിധ സംഘടനാ പ്രക്രിയകൾ ഉൾക്കൊള്ളുന്നു, അത് ഈ വിഷയത്തിൽ സഹായിക്കും.

RED, USE രീതികളുടെ ഭംഗി അവരുടെ സഹായത്തോടെ നമുക്ക് എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് മാത്രമല്ല, പരസ്പരം ഒരേ ഭാഷ സംസാരിക്കുകയും ചെയ്യുന്നു എന്നതാണ്. ഞങ്ങളുടെ സിസ്റ്റങ്ങളെ പരിരക്ഷിക്കുന്ന അറിയിപ്പുകൾ ചർച്ച ചെയ്യുന്നത് CASE രീതി എളുപ്പമാക്കുമെന്നാണ് എന്റെ പ്രതീക്ഷ, എന്നാൽ ഞങ്ങളുടെ സഹപ്രവർത്തകരെ തിരക്കിലാക്കി നിർത്തുന്നു.

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

സന്ദർഭം-ഹെവി - സന്ദർഭ ബൈൻഡിംഗ്

ധാരാളം സ്‌മാർട്ട് വാക്കുകൾ അടങ്ങിയ സന്ദേശങ്ങൾ വായിക്കാനുള്ള ഏറ്റവും നല്ല സമയമല്ല പുലർച്ചെ 3 മണി. ഫലപ്രദമായി പ്രതികരിക്കുന്നതിന്, നിങ്ങൾക്ക് വിവരങ്ങൾ ആവശ്യമാണ്. എബൌട്ട്, ഇത് ഒരു പ്രത്യേക പ്രശ്നത്തെക്കുറിച്ചുള്ള വിവരമായിരിക്കണം, അതിനായി സന്ദർഭം ഉടനടി വ്യക്തമാണ്, കൂടാതെ ഇത് സാധ്യമാകുന്ന തരത്തിൽ അറിയിപ്പുകൾ കോൺഫിഗർ ചെയ്യണം. ഇത് "നിരീക്ഷണവും" "ഓറിയന്റേഷനും" ആണ് OODA ലൂപ്പ്. ഈ സജ്ജീകരണത്തിൽ സമയം ചെലവഴിക്കുന്നത് ലജ്ജാകരമല്ല, കാരണം ഒരു വ്യക്തിയെ നിരന്തരം വ്യതിചലിപ്പിക്കുന്നത് കൂടുതൽ ചെലവേറിയതാണ്. നമുക്ക് പരസ്പരം ബഹുമാനിക്കാം.

പ്രശ്നങ്ങൾക്ക് നിരവധി ഉറവിടങ്ങളുണ്ട്. പ്രത്യേകിച്ച് പ്രേതങ്ങൾ.

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

അതിനാൽ അറിയിപ്പ് സന്ദർഭം എങ്ങനെ മെച്ചപ്പെടുത്താം എന്നതിനെക്കുറിച്ചുള്ള ചില ആശയങ്ങൾ ഇതാ:

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

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

പ്രവർത്തനക്ഷമമായ - പ്രായോഗിക മൂല്യം

അറിയിപ്പിന് മറുപടിയായി ഡ്യൂട്ടി ഓഫീസർ എന്തെങ്കിലും ചെയ്യണോ? നിങ്ങൾക്ക് ഒന്നും ചെയ്യേണ്ടതില്ലെങ്കിലോ എന്തുചെയ്യണമെന്ന് വ്യക്തമല്ലെങ്കിലോ, എന്തുകൊണ്ടാണ് നിങ്ങൾ അവനെ ഉണർത്തുന്നത്? ഡ്യൂട്ടിയിലുള്ളവരെ ശല്യപ്പെടുത്തുന്നതും നടപടി ആവശ്യമില്ലാത്തതുമായ അറിയിപ്പുകൾ നിങ്ങൾ ഒഴിവാക്കേണ്ടതുണ്ട്.

Imgur.com ൽ പോസ്റ്റ് കാണുക

ഞാൻ എന്ത് ചെയ്യണം? എന്തുവേണം?

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

പ്രായോഗിക മൂല്യമുള്ള ഒരു അറിയിപ്പ് ഇങ്ങനെയാണ്:

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

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

രോഗലക്ഷണത്തെ അടിസ്ഥാനമാക്കി - ലക്ഷണങ്ങളിൽ ഊന്നൽ

നിങ്ങൾ ഇഷ്ടപ്പെട്ടാലും ഇല്ലെങ്കിലും, നിങ്ങൾ ഒരു ഡിസ്ട്രിബ്യൂഡ് സിസ്റ്റത്തിലാണ് (കവാജ്) പ്രവർത്തിക്കുന്നത്.2. തൽഫലമായി, സേവനങ്ങളെ ഒറ്റപ്പെടുത്താനും പരാജയത്തിൽ നിന്ന് സംരക്ഷിക്കാനും നിങ്ങൾ വ്യത്യസ്ത തന്ത്രങ്ങൾ ഉപയോഗിക്കുന്നു (ട്രെയിനർ തുടങ്ങിയവർ.)3. കാലതാമസം നേരിടുന്ന മാലിന്യ ശേഖരണമോ സ്തംഭിച്ച ഡാറ്റാബേസ് അന്വേഷണമോ പ്രശ്‌നങ്ങളെ സൂചിപ്പിക്കുന്നുവെങ്കിലും, സമീപഭാവിയിൽ ഉപയോക്താക്കൾക്ക് പ്രശ്‌നങ്ങളില്ലെങ്കിൽ അവ പരിഹരിക്കാൻ തിരക്കുകൂട്ടേണ്ട ആവശ്യമില്ല.

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

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

ലക്ഷണങ്ങൾ വേരിയബിൾ അല്ല

സങ്കീർണമായ സംവിധാനങ്ങൾ പോരായ്മകളും പോരായ്മകളും പ്രശ്നങ്ങളും നിറഞ്ഞതാണെന്ന് റിച്ചാർഡ് കുക്ക് നമ്മെ ഓർമ്മിപ്പിക്കുന്നു4. സാധ്യമായ എല്ലാ കാരണങ്ങളും പട്ടികപ്പെടുത്താൻ ശ്രമിക്കുന്നത് ഒരു സിസിഫിയൻ ചുമതലയാണ്. നിങ്ങൾ പ്രശ്നങ്ങൾ വിവരിക്കാൻ ശ്രമിക്കുന്നു, പക്ഷേ അവ എല്ലാ സമയത്തും മാറുന്നു. സിണ്ടി ശ്രീധരൻ വിശ്വസിക്കുന്നത് "ഓരോ സെക്കൻഡിലും സിസ്റ്റങ്ങൾ തികഞ്ഞ അവസ്ഥയിലായിരിക്കണമെന്നില്ല", കൂടുതൽ മാനുഷികമായ സമീപനം ഉപയോഗിക്കുന്നതാണ് നല്ലത് ("വിതരണ സംവിധാനങ്ങളുടെ നിരീക്ഷണക്ഷമത" (“മോണിറ്ററിംഗ് ഡിസ്ട്രിബ്യൂട്ടഡ് സിസ്റ്റങ്ങൾ”), 7)5.

ഒരു സംഭവത്തിന് ശേഷം അറിയിപ്പുകൾ ഒഴിവാക്കുക

സാധാരണഗതിയിൽ, സംഭവങ്ങൾ ശരിയാക്കുന്നതിനാണ് കാരണങ്ങൾക്കുള്ള അറിയിപ്പുകൾ ക്രമീകരിച്ചിരിക്കുന്നത്. എന്താണ് സംഭവിച്ചതെന്ന വസ്തുതയെക്കുറിച്ചുള്ള ഈ പരിമിത അറിയിപ്പുകൾ തെറ്റായ സുരക്ഷാ ബോധം സൃഷ്ടിക്കുന്നു, കാരണം സിസ്റ്റം ഓരോ തവണയും തകർക്കാനുള്ള പുതിയ വഴികൾ കൊണ്ടുവരുന്നു.

കാരണം നോട്ടീസ് നൽകി വഞ്ചിതരാകരുത്. ചിന്തിക്കുന്നതാണ് നല്ലത്:

• എന്തുകൊണ്ടാണ് രോഗലക്ഷണങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ള അറിയിപ്പ് പ്രശ്നം ശ്രദ്ധിക്കാത്തത്?
• ഉപയോക്താവിനുള്ള സന്ദർഭം മെച്ചപ്പെടുത്താൻ ഇത് സഹായകരമാകുമോ?
• എന്താണ് സംഭവിച്ചതെന്നതിനെക്കുറിച്ചുള്ള അറിയിപ്പുകൾ ശേഖരിക്കുന്നതിനുപകരം രോഗനിർണയം വേഗത്തിലാക്കാൻ മോണിറ്ററിംഗ് ടൂളുകൾ എങ്ങനെ മെച്ചപ്പെടുത്താം?

രോഗലക്ഷണത്തിൽ നിന്ന് പരിഹാരത്തിലേക്ക് നീങ്ങാനുള്ള ഒരു മാർഗമായി നിങ്ങൾ കരുതുന്നുണ്ടെങ്കിൽ മാത്രമേ രോഗനിർണയത്തിനുള്ള മോണിറ്ററിംഗ് ടൂളുകൾ സഹായിക്കൂ. ഈ ഫീഡ്‌ബാക്ക് ഇല്ലെങ്കിൽ, മുൻകാല പരാജയങ്ങളെക്കുറിച്ചുള്ള വൈകിയുള്ള അറിയിപ്പുകളും ചാർട്ടുകളും കൊണ്ട് നിങ്ങൾ പൊട്ടിത്തെറിക്കപ്പെടും-അല്ലാതെ ഭാവിയിലെ പരാജയങ്ങളെക്കുറിച്ച് ഒരു വാക്കുമില്ല. പ്രതിരോധത്തിൽ നിന്ന് ആക്രമണത്തിലേക്ക് നീങ്ങാനുള്ള മികച്ച അവസരമാണിത്. ഡെവലപ്പർമാർക്കും ഉൽപ്പന്ന മാനേജർമാർക്കും ഒരേ പ്രതീക്ഷകളും വ്യക്തമായ ലക്ഷ്യങ്ങളും ഉണ്ടായിരിക്കും. കേസ് - CASE (:wink:) - ഓരോ അറിയിപ്പിനും വ്യക്തമാണ്.

കാരണം അടിസ്ഥാനമാക്കിയുള്ള അറിയിപ്പുകൾ മോഡറേഷനിൽ സഹിക്കാവുന്നതാണ്

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

വിലയിരുത്തി - വിലയിരുത്തൽ

സിസ്റ്റത്തിലെ എന്തെങ്കിലും മാറ്റങ്ങൾ (പുതിയ കോഡ്, പുതിയ ഇൻഫ്രാസ്ട്രക്ചർ, പുതിയതെന്തും) പരാജയങ്ങളുടെ പരിധി വിപുലീകരിക്കുന്നു (കുക്ക്, 3).4 ഈ അറിയിപ്പ് ഇപ്പോഴും പ്രതീക്ഷിച്ചതുപോലെ പ്രവർത്തിക്കുന്നുണ്ടോ? സിസ്റ്റങ്ങളുടെ വ്യക്തവും നിലവിലുള്ളതുമായ മാനസിക മാതൃകകളും ചില പിന്തുണ അറിയിപ്പുകളോട് പ്രതികരിക്കുന്ന അനുഭവവും പ്രതിരോധ സമീപനം - ഇവയാണ് പ്രധാന സവിശേഷതകൾ പഠന-അധിഷ്ഠിത സംഘടന. സിസ്റ്റങ്ങളിലെ വൈകല്യങ്ങൾ നിരന്തരം വികസിച്ചുകൊണ്ടിരിക്കുന്നു, അവയ്‌ക്കൊപ്പം നാം തുടരണം.

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

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

തീരുമാനം

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

മുൻനിര ഉപഭോക്തൃ സേവനത്തെ ത്യജിക്കാതെ ഡ്യൂട്ടിയിലായിരിക്കുമ്പോൾ മുഴുവൻ വ്യവസായവും മാനുഷിക ഘടകത്തെക്കുറിച്ച് ചിന്തിക്കേണ്ടതുണ്ട്. ഈ ഉപകരണങ്ങളും സമ്പ്രദായങ്ങളും എല്ലാം മെച്ചപ്പെടുത്താനും മെച്ചപ്പെടുത്താനും കഴിയും. CASE രീതി ഇതിന് സഹായിക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

മെച്ചപ്പെടുത്തിയ അറിയിപ്പുകൾ ആസ്വദിക്കൂ!

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