വെബ് പ്രോജക്റ്റുകളുടെ ലഭ്യത ഉറപ്പാക്കുന്നതിനുള്ള ഒരു സമീപനമാണ് SRE (സൈറ്റ് വിശ്വാസ്യത എഞ്ചിനീയറിംഗ്). ഇത് DevOps-നുള്ള ഒരു ചട്ടക്കൂടായി കണക്കാക്കുകയും DevOps പ്രാക്ടീസുകൾ പ്രയോഗിക്കുന്നതിൽ എങ്ങനെ വിജയം നേടാം എന്നതിനെ കുറിച്ച് സംസാരിക്കുകയും ചെയ്യുന്നു. ഈ ലേഖനത്തിലെ വിവർത്തനം അധ്യായം 4 സേവന നില ലക്ഷ്യങ്ങൾ പുസ്തകങ്ങൾ സൈറ്റ് വിശ്വാസ്യത എഞ്ചിനീയറിംഗ് Google-ൽ നിന്ന്. ഞാൻ ഈ വിവർത്തനം സ്വയം തയ്യാറാക്കുകയും നിരീക്ഷണ പ്രക്രിയകൾ മനസ്സിലാക്കുന്നതിൽ എന്റെ സ്വന്തം അനുഭവത്തെ ആശ്രയിക്കുകയും ചെയ്തു. ടെലിഗ്രാം ചാനലിൽ നിരീക്ഷണം_ഇത് и ഹബ്രെയിലെ അവസാന പോസ്റ്റ് സേവന തലത്തിലുള്ള ലക്ഷ്യങ്ങളെക്കുറിച്ചുള്ള അതേ പുസ്തകത്തിന്റെ ആറാം അധ്യായത്തിന്റെ വിവർത്തനവും ഞാൻ പ്രസിദ്ധീകരിച്ചു.

പൂച്ചയുടെ വിവർത്തനം. വായന ആസ്വദിക്കൂ!

ഏത് സൂചകങ്ങളാണ് യഥാർത്ഥത്തിൽ പ്രാധാന്യമർഹിക്കുന്നതെന്നും അവ എങ്ങനെ അളക്കാമെന്നും വിലയിരുത്തണമെന്നും ധാരണയില്ലെങ്കിൽ ഒരു സേവനം കൈകാര്യം ചെയ്യുന്നത് അസാധ്യമാണ്. ഇതിനായി, ഞങ്ങളുടെ ഉപയോക്താക്കൾ ഞങ്ങളുടെ ആന്തരിക API-കളിലേതെങ്കിലും അല്ലെങ്കിൽ പൊതു ഉൽപ്പന്നം ഉപയോഗിക്കുന്നുണ്ടോ എന്നത് പരിഗണിക്കാതെ തന്നെ ഞങ്ങൾ അവർക്ക് ഒരു നിശ്ചിത തലത്തിലുള്ള സേവനം നിർവചിക്കുകയും നൽകുകയും ചെയ്യുന്നു.

സേവന നില സൂചകങ്ങൾ (എസ്‌എൽ‌ഐകൾ), സേവന തല ലക്ഷ്യങ്ങൾ (എസ്‌എൽ‌ഒകൾ), സേവന നില കരാറുകൾ (എസ്‌എൽ‌എകൾ) എന്നിവ മനസ്സിലാക്കാനുള്ള ഉപയോക്താക്കളുടെ ആഗ്രഹത്തെക്കുറിച്ചുള്ള ഞങ്ങളുടെ അവബോധം, അനുഭവം, മനസ്സിലാക്കൽ എന്നിവ ഞങ്ങൾ ഉപയോഗിക്കുന്നു. ഈ അളവുകൾ ഞങ്ങൾ നിരീക്ഷിക്കാൻ ആഗ്രഹിക്കുന്ന പ്രധാന മെട്രിക്കുകളെ വിവരിക്കുന്നു, കൂടാതെ പ്രതീക്ഷിക്കുന്ന സേവന നിലവാരം നൽകാൻ ഞങ്ങൾക്ക് കഴിയുന്നില്ലെങ്കിൽ ഞങ്ങൾ പ്രതികരിക്കും. ആത്യന്തികമായി, ശരിയായ മെട്രിക്‌സ് തിരഞ്ഞെടുക്കുന്നത് എന്തെങ്കിലും തെറ്റ് സംഭവിച്ചാൽ ശരിയായ പ്രവർത്തനങ്ങളെ നയിക്കാൻ സഹായിക്കുന്നു, കൂടാതെ സേവനത്തിന്റെ ആരോഗ്യത്തിൽ SRE ടീമിന് ആത്മവിശ്വാസം നൽകുകയും ചെയ്യുന്നു.

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

സേവന തലത്തിലുള്ള പദാവലി

പല വായനക്കാർക്കും SLA എന്ന ആശയം പരിചിതമായിരിക്കാം, എന്നാൽ SLI, SLO എന്നീ പദങ്ങൾ ശ്രദ്ധാപൂർവ്വം നിർവചിക്കേണ്ടതാണ്, കാരണം പൊതുവെ SLA എന്ന പദം ഓവർലോഡ് ആയതിനാൽ സന്ദർഭത്തിനനുസരിച്ച് നിരവധി അർത്ഥങ്ങളുണ്ട്. വ്യക്തതയ്ക്കായി, ഈ മൂല്യങ്ങൾ വേർതിരിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

സൂചകങ്ങൾ

SLI എന്നത് ഒരു സേവന നില സൂചകമാണ് - നൽകിയിരിക്കുന്ന സേവന നിലവാരത്തിന്റെ ഒരു വശത്തിന്റെ സൂക്ഷ്മമായി നിർവചിക്കപ്പെട്ട അളവ് അളവ്.

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

എബൌട്ട്, SLI നേരിട്ട് താൽപ്പര്യത്തിന്റെ സേവന നില അളക്കുന്നു, എന്നാൽ യഥാർത്ഥമായത് നേടാനോ വ്യാഖ്യാനിക്കാനോ ബുദ്ധിമുട്ടായതിനാൽ ചിലപ്പോൾ ഒരു അനുബന്ധ മെട്രിക് മാത്രമേ അളക്കാൻ ലഭ്യമാകൂ. ഉദാഹരണത്തിന്, ക്ലയന്റ് സൈഡ് ലേറ്റൻസി പലപ്പോഴും കൂടുതൽ ഉചിതമായ മെട്രിക് ആണ്, എന്നാൽ ചില സമയങ്ങളിൽ സെർവറിൽ മാത്രമേ ലേറ്റൻസി അളക്കാൻ കഴിയൂ.

SRE-കൾക്ക് പ്രധാനപ്പെട്ട മറ്റൊരു തരം SLI ലഭ്യതയാണ്, അല്ലെങ്കിൽ ഒരു സേവനം ഉപയോഗിക്കാനാകുന്ന സമയത്തിന്റെ ഭാഗമാണ്. വിജയകരമായ അഭ്യർത്ഥനകളുടെ നിരക്ക് എന്ന് പലപ്പോഴും നിർവചിക്കപ്പെടുന്നു, ചിലപ്പോൾ വിളവ് എന്ന് വിളിക്കുന്നു. (ആയുഷ്‌കാലം-വിവരണം ദീർഘനേരം നിലനിർത്താനുള്ള സാധ്യത-ഡാറ്റാ സ്റ്റോറേജ് സിസ്റ്റങ്ങൾക്കും പ്രധാനമാണ്.) 100% ലഭ്യത സാധ്യമല്ലെങ്കിലും, 100% ലഭ്യത പലപ്പോഴും കൈവരിക്കാനാകും; ലഭ്യത മൂല്യങ്ങൾ ഇങ്ങനെ പ്രകടിപ്പിക്കുന്നു "ഒമ്പതുകളുടെ" എണ്ണം »ലഭ്യതയുടെ ശതമാനം. ഉദാഹരണത്തിന്, 99%, 99,999% ലഭ്യത "2 നൈൻസ്", "5 നൈൻസ്" എന്നിങ്ങനെ ലേബൽ ചെയ്തേക്കാം. Google കമ്പ്യൂട്ട് എഞ്ചിന്റെ നിലവിലെ പ്രഖ്യാപിത ലഭ്യത ലക്ഷ്യം "മൂന്നര ഒമ്പത്" അല്ലെങ്കിൽ 99,95% ആണ്.

ലക്ഷ്യങ്ങൾ

ഒരു SLO എന്നത് ഒരു സേവന നില ലക്ഷ്യമാണ്: SLI അളക്കുന്ന ഒരു സേവന തലത്തിനായുള്ള ടാർഗെറ്റ് മൂല്യം അല്ലെങ്കിൽ മൂല്യങ്ങളുടെ ശ്രേണി. SLO-യുടെ ഒരു സാധാരണ മൂല്യം "SLI ≤ ടാർഗെറ്റ്" അല്ലെങ്കിൽ "ലോവർ ലിമിറ്റ് ≤ SLI ≤ ഉയർന്ന പരിധി" ആണ്. ഉദാഹരണത്തിന്, 100 മില്ലിസെക്കൻഡിൽ താഴെയുള്ള ശരാശരി തിരയൽ അന്വേഷണ ലേറ്റൻസിയായി SLO സജ്ജീകരിച്ചുകൊണ്ട് ഷേക്സ്പിയർ തിരയൽ ഫലങ്ങൾ "വേഗത" നൽകുമെന്ന് ഞങ്ങൾ തീരുമാനിച്ചേക്കാം.

ശരിയായ SLO തിരഞ്ഞെടുക്കുന്നത് സങ്കീർണ്ണമായ ഒരു പ്രക്രിയയാണ്. ആദ്യം, നിങ്ങൾക്ക് എല്ലായ്പ്പോഴും ഒരു പ്രത്യേക മൂല്യം തിരഞ്ഞെടുക്കാൻ കഴിയില്ല. നിങ്ങളുടെ സേവനത്തിലേക്കുള്ള ബാഹ്യ ഇൻകമിംഗ് HTTP അഭ്യർത്ഥനകൾക്കായി, നിങ്ങളുടെ സേവനം സന്ദർശിക്കാനുള്ള നിങ്ങളുടെ ഉപയോക്താക്കളുടെ ആഗ്രഹത്തെ അടിസ്ഥാനമാക്കിയാണ് ക്വറി പെർ സെക്കൻഡ് (QPS) മെട്രിക് പ്രാഥമികമായി നിർണ്ണയിക്കുന്നത്, അതിനായി നിങ്ങൾക്ക് ഒരു SLO സജ്ജമാക്കാൻ കഴിയില്ല.

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

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

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

കരാറുകൾ

നിങ്ങളുടെ ഉപയോക്താക്കളുമായി അവർ ഉൾക്കൊള്ളുന്ന SLO-കളെ കണ്ടുമുട്ടുന്നതിന്റെ (അല്ലെങ്കിൽ കണ്ടുമുട്ടാത്തതിന്റെ) അനന്തരഫലങ്ങൾ ഉൾപ്പെടുന്ന വ്യക്തമായതോ പരോക്ഷമായതോ ആയ ഒരു കരാറാണ് സേവന നില ഉടമ്പടി. സാമ്പത്തികമായിരിക്കുമ്പോൾ അനന്തരഫലങ്ങൾ വളരെ എളുപ്പത്തിൽ തിരിച്ചറിയാൻ കഴിയും-ഒരു കിഴിവ് അല്ലെങ്കിൽ പിഴ- എന്നാൽ അവയ്ക്ക് മറ്റ് രൂപങ്ങൾ എടുക്കാം. എസ്‌എൽ‌ഒകളും എസ്‌എൽ‌എകളും തമ്മിലുള്ള വ്യത്യാസത്തെക്കുറിച്ച് സംസാരിക്കാനുള്ള ഒരു എളുപ്പ മാർഗം "എസ്‌എൽ‌ഒകൾ കണ്ടുമുട്ടിയില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?" വ്യക്തമായ അനന്തരഫലങ്ങൾ ഇല്ലെങ്കിൽ, നിങ്ങൾ മിക്കവാറും ഒരു SLO യിൽ നോക്കുകയാണ്.

SLA-കൾ ബിസിനസ്, ഉൽപ്പന്ന തീരുമാനങ്ങളുമായി അടുത്ത ബന്ധമുള്ളതിനാൽ SLA-കൾ സൃഷ്ടിക്കുന്നതിൽ SRE സാധാരണയായി ഉൾപ്പെട്ടിട്ടില്ല. എന്നിരുന്നാലും, പരാജയപ്പെട്ട SLO-കളുടെ അനന്തരഫലങ്ങൾ ലഘൂകരിക്കാൻ സഹായിക്കുന്നതിൽ SRE ഉൾപ്പെടുന്നു. SLI നിർണ്ണയിക്കാൻ അവർക്ക് സഹായിക്കാനും കഴിയും: വ്യക്തമായും, കരാറിൽ SLO അളക്കാൻ ഒരു വസ്തുനിഷ്ഠമായ മാർഗം ഉണ്ടായിരിക്കണം അല്ലെങ്കിൽ വിയോജിപ്പ് ഉണ്ടാകും.

ഒരു പൊതു SLA ഇല്ലാത്ത ഒരു പ്രധാന സേവനത്തിന്റെ ഉദാഹരണമാണ് Google തിരയൽ: എല്ലാവരും തിരയൽ കഴിയുന്നത്ര കാര്യക്ഷമമായി ഉപയോഗിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു, എന്നാൽ ഞങ്ങൾ ലോകവുമായി ഒരു കരാർ ഒപ്പിട്ടിട്ടില്ല. എന്നിരുന്നാലും, തിരയൽ ലഭ്യമല്ലെങ്കിൽ, അനന്തരഫലങ്ങൾ ഇപ്പോഴും ഉണ്ട് - ലഭ്യമല്ലാത്തത് ഞങ്ങളുടെ പ്രശസ്തി കുറയുന്നതിനും പരസ്യ വരുമാനം കുറയുന്നതിനും കാരണമാകുന്നു. Google for Work പോലുള്ള മറ്റ് പല Google സേവനങ്ങൾക്കും ഉപയോക്താക്കളുമായി വ്യക്തമായ സേവന നില കരാറുകളുണ്ട്. ഒരു പ്രത്യേക സേവനത്തിന് ഒരു SLA ഉണ്ടോ എന്നത് പരിഗണിക്കാതെ തന്നെ, SLI, SLO എന്നിവ നിർവചിക്കുകയും സേവനം നിയന്ത്രിക്കുന്നതിന് അവ ഉപയോഗിക്കുകയും ചെയ്യേണ്ടത് പ്രധാനമാണ്.

വളരെയധികം സിദ്ധാന്തം - ഇപ്പോൾ അനുഭവിക്കാൻ.

പ്രയോഗത്തിലുള്ള സൂചകങ്ങൾ

സേവന നില അളക്കാൻ ഉചിതമായ മെട്രിക്‌സ് തിരഞ്ഞെടുക്കേണ്ടത് പ്രധാനമാണെന്ന് ഞങ്ങൾ നിഗമനം ചെയ്‌തിരിക്കുന്നതിനാൽ, ഒരു സേവനത്തിനോ സിസ്റ്റത്തിനോ ഏതൊക്കെ മെട്രിക്‌സുകളാണ് പ്രധാനമെന്ന് ഇപ്പോൾ നിങ്ങൾക്ക് എങ്ങനെ അറിയാം?

നിങ്ങളും നിങ്ങളുടെ ഉപയോക്താക്കളും എന്താണ് ശ്രദ്ധിക്കുന്നത്?

നിങ്ങൾക്ക് ഒരു മോണിറ്ററിംഗ് സിസ്റ്റത്തിൽ ട്രാക്ക് ചെയ്യാൻ കഴിയുന്ന ഒരു SLI ആയി എല്ലാ മെട്രിക്സും ഉപയോഗിക്കേണ്ടതില്ല; ഒരു സിസ്റ്റത്തിൽ നിന്ന് ഉപയോക്താക്കൾക്ക് എന്താണ് വേണ്ടതെന്ന് മനസിലാക്കുന്നത് നിരവധി മെട്രിക്കുകൾ തിരഞ്ഞെടുക്കാൻ നിങ്ങളെ സഹായിക്കും. വളരെയധികം സൂചകങ്ങൾ തിരഞ്ഞെടുക്കുന്നത് പ്രധാനപ്പെട്ട സൂചകങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത് ബുദ്ധിമുട്ടാക്കുന്നു, അതേസമയം ഒരു ചെറിയ സംഖ്യ തിരഞ്ഞെടുക്കുന്നത് നിങ്ങളുടെ സിസ്റ്റത്തിന്റെ വലിയ ഭാഗങ്ങൾ ശ്രദ്ധിക്കപ്പെടാതെ പോകും. ഒരു സിസ്റ്റത്തിന്റെ ആരോഗ്യം വിലയിരുത്തുന്നതിനും മനസ്സിലാക്കുന്നതിനും ഞങ്ങൾ സാധാരണയായി നിരവധി പ്രധാന സൂചകങ്ങൾ ഉപയോഗിക്കുന്നു.

സേവനങ്ങളെ പൊതുവായി അവയ്ക്ക് പ്രസക്തമായ SLI അനുസരിച്ച് പല ഭാഗങ്ങളായി വിഭജിക്കാം:

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

സൂചകങ്ങളുടെ ശേഖരണം

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

സമാഹരണം

ലാളിത്യത്തിനും ഉപയോഗത്തിന്റെ എളുപ്പത്തിനും, ഞങ്ങൾ പലപ്പോഴും അസംസ്കൃത അളവുകൾ കൂട്ടിച്ചേർക്കുന്നു. ഇത് ശ്രദ്ധാപൂർവ്വം ചെയ്യണം.

സെക്കന്റിലെ അഭ്യർത്ഥനകൾ പോലെ ചില മെട്രിക്കുകൾ ലളിതമാണെന്ന് തോന്നുന്നു, എന്നാൽ ഈ പ്രത്യക്ഷത്തിൽ നേരായ അളവെടുപ്പ് പോലും കാലക്രമേണ ഡാറ്റയെ പരോക്ഷമായി സമാഹരിക്കുന്നു. അളക്കൽ സെക്കൻഡിൽ ഒരു പ്രാവശ്യം പ്രത്യേകമായി ലഭിച്ചതാണോ അതോ ഒരു മിനിറ്റിലെ അഭ്യർത്ഥനകളുടെ എണ്ണത്തെക്കാൾ ശരാശരിയാണോ അളക്കുന്നത്? കുറച്ച് നിമിഷങ്ങൾ മാത്രം നീണ്ടുനിൽക്കുന്ന അഭ്യർത്ഥനകളുടെ വളരെ ഉയർന്ന തൽക്ഷണ എണ്ണം മറയ്ക്കാൻ രണ്ടാമത്തെ ഓപ്ഷന് കഴിയും. ഒരു സെക്കൻഡിൽ 200 അഭ്യർത്ഥനകൾ ഇരട്ട സംഖ്യകളും ബാക്കി സമയം 0 ഉം നൽകുന്ന ഒരു സിസ്റ്റം പരിഗണിക്കുക. സെക്കൻഡിൽ 100 ​​അഭ്യർത്ഥനകളുടെ ശരാശരി മൂല്യത്തിന്റെ രൂപത്തിലുള്ള ഒരു സ്ഥിരാങ്കവും തൽക്ഷണ ലോഡിന്റെ ഇരട്ടിയും ഒരേ കാര്യമല്ല. അതുപോലെ, ശരാശരി അന്വേഷണ ലേറ്റൻസികൾ ആകർഷകമായി തോന്നിയേക്കാം, പക്ഷേ അത് ഒരു പ്രധാന വിശദാംശം മറയ്ക്കുന്നു: മിക്ക ചോദ്യങ്ങളും വേഗത്തിലാകാൻ സാധ്യതയുണ്ട്, പക്ഷേ മന്ദഗതിയിലുള്ള നിരവധി അന്വേഷണങ്ങൾ ഉണ്ടാകും.

മിക്ക സൂചകങ്ങളും ശരാശരിയെക്കാളും വിതരണങ്ങളായിട്ടാണ് കാണുന്നത്. ഉദാഹരണത്തിന്, SLI ലേറ്റൻസിക്ക്, ചില അഭ്യർത്ഥനകൾ വേഗത്തിൽ പ്രോസസ്സ് ചെയ്യപ്പെടും, ചിലത് എപ്പോഴും കൂടുതൽ സമയമെടുക്കും, ചിലപ്പോൾ കൂടുതൽ സമയം എടുക്കും. ഒരു ലളിതമായ ശരാശരിക്ക് ഈ നീണ്ട കാലതാമസം മറയ്ക്കാൻ കഴിയും. ചിത്രം ഒരു ഉദാഹരണം കാണിക്കുന്നു: ഒരു സാധാരണ അഭ്യർത്ഥന നൽകുന്നതിന് ഏകദേശം 50 എംഎസ് എടുക്കുമെങ്കിലും, 5% അഭ്യർത്ഥനകൾ 20 മടങ്ങ് വേഗത കുറവാണ്! ശരാശരി ലേറ്റൻസിയെ അടിസ്ഥാനമാക്കിയുള്ള നിരീക്ഷണവും അലേർട്ടിംഗും ദിവസം മുഴുവനും പെരുമാറ്റത്തിൽ മാറ്റങ്ങൾ കാണിക്കുന്നില്ല, വാസ്തവത്തിൽ ചില അഭ്യർത്ഥനകളുടെ പ്രോസസ്സിംഗ് സമയത്തിൽ (ഏറ്റവും മുകളിലെ വരി) ശ്രദ്ധേയമായ മാറ്റങ്ങൾ ഉണ്ടാകുമ്പോൾ.

50, 85, 95, 99 ശതമാനം സിസ്റ്റം ലേറ്റൻസി. Y അക്ഷം ലോഗരിഥമിക് ഫോർമാറ്റിലാണ്.

സൂചകങ്ങൾക്കായി പെർസെൻറ്റൈലുകൾ ഉപയോഗിക്കുന്നത് വിതരണത്തിന്റെ ആകൃതിയും അതിന്റെ സവിശേഷതകളും കാണാൻ നിങ്ങളെ അനുവദിക്കുന്നു: 99 അല്ലെങ്കിൽ 99,9 പോലുള്ള ഉയർന്ന പെർസെൻറ്റൈൽ ലെവൽ ഏറ്റവും മോശം മൂല്യം കാണിക്കുന്നു, അതേസമയം 50 ശതമാനം (മീഡിയൻ എന്നും അറിയപ്പെടുന്നു) ഏറ്റവും സാധാരണമായ അവസ്ഥ കാണിക്കുന്നു മെട്രിക്. പ്രതികരണ സമയ വ്യാപനം കൂടുന്തോറും, കൂടുതൽ ദൈർഘ്യമുള്ള അഭ്യർത്ഥനകൾ ഉപയോക്തൃ അനുഭവത്തെ സ്വാധീനിക്കുന്നു. ഉയർന്ന ലോഡിലും ക്യൂകളുടെ സാന്നിധ്യത്തിലും പ്രഭാവം വർദ്ധിപ്പിക്കുന്നു. ഉപയോക്തൃ അനുഭവ ഗവേഷണം കാണിക്കുന്നത് ആളുകൾ സാധാരണയായി ഉയർന്ന പ്രതികരണ സമയ വ്യത്യാസമുള്ള വേഗത കുറഞ്ഞ സംവിധാനമാണ് ഇഷ്ടപ്പെടുന്നത്, അതിനാൽ ചില എസ്ആർഇ ടീമുകൾ ഉയർന്ന പെർസെൻറ്റൈൽ സ്കോറുകളിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു, 99,9 പെർസെൻറ്റൈലിൽ മെട്രിക്കിന്റെ പെരുമാറ്റം നല്ലതാണെങ്കിൽ, മിക്ക ഉപയോക്താക്കൾക്കും പ്രശ്നങ്ങൾ അനുഭവപ്പെടില്ല. .

സ്ഥിതിവിവരക്കണക്ക് പിശകുകളെ കുറിച്ചുള്ള കുറിപ്പ്

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

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

സൂചകങ്ങൾ സ്റ്റാൻഡേർഡ് ചെയ്യുക

എസ്‌എൽ‌ഐയ്‌ക്കായുള്ള പൊതുവായ സ്വഭാവസവിശേഷതകൾ സ്റ്റാൻഡേർഡ് ചെയ്യാൻ ഞങ്ങൾ ശുപാർശചെയ്യുന്നു, അതിലൂടെ നിങ്ങൾ അവയെക്കുറിച്ച് ഓരോ തവണയും ഊഹിക്കേണ്ടതില്ല. സ്റ്റാൻഡേർഡ് പാറ്റേണുകളെ തൃപ്തിപ്പെടുത്തുന്ന ഏതൊരു ഫീച്ചറും ഒരു വ്യക്തിഗത SLI-യുടെ സ്പെസിഫിക്കേഷനിൽ നിന്ന് ഒഴിവാക്കപ്പെട്ടേക്കാം, ഉദാഹരണത്തിന്:

• സമാഹരണ ഇടവേളകൾ: "ശരാശരി 1 മിനിറ്റിൽ കൂടുതൽ"
• അഗ്രഗേഷൻ ഏരിയകൾ: "ക്ലസ്റ്ററിലെ എല്ലാ ജോലികളും"
• എത്ര തവണ അളവുകൾ എടുക്കുന്നു: "ഓരോ 10 സെക്കൻഡിലും"
• എന്ത് അഭ്യർത്ഥനകൾ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്: "ബ്ലാക്ക് ബോക്സ് മോണിറ്ററിംഗ് ജോലികളിൽ നിന്ന് HTTP നേടുക"
• ഡാറ്റ എങ്ങനെ ലഭിക്കും: "സെർവറിൽ അളക്കുന്ന ഞങ്ങളുടെ നിരീക്ഷണത്തിന് നന്ദി"
• ഡാറ്റ ആക്‌സസ് ലേറ്റൻസി: "അവസാന ബൈറ്റിലേക്കുള്ള സമയം"

പരിശ്രമം ലാഭിക്കുന്നതിന്, ഓരോ സാധാരണ മെട്രിക്കിനും പുനരുപയോഗിക്കാവുന്ന ഒരു കൂട്ടം SLI ടെംപ്ലേറ്റുകൾ സൃഷ്ടിക്കുക; ഒരു നിശ്ചിത SLI എന്താണ് അർത്ഥമാക്കുന്നത് എന്ന് എല്ലാവർക്കും മനസ്സിലാക്കാൻ അവ എളുപ്പമാക്കുന്നു.

പ്രായോഗികമായി ലക്ഷ്യങ്ങൾ

നിങ്ങളുടെ ഉപയോക്താക്കൾ എന്താണ് ശ്രദ്ധിക്കുന്നത് എന്നതിനെ കുറിച്ച് ചിന്തിച്ചുകൊണ്ട് (അല്ലെങ്കിൽ കണ്ടെത്തുക!) ആരംഭിക്കുക, നിങ്ങൾക്ക് അളക്കാൻ കഴിയുന്ന കാര്യമല്ല. പലപ്പോഴും നിങ്ങളുടെ ഉപയോക്താക്കൾ ശ്രദ്ധിക്കുന്ന കാര്യങ്ങൾ അളക്കാൻ ബുദ്ധിമുട്ടുള്ളതോ അസാധ്യമോ ആണ്, അതിനാൽ നിങ്ങൾ അവരുടെ ആവശ്യങ്ങളോട് കൂടുതൽ അടുക്കുന്നു. എന്നിരുന്നാലും, അളക്കാൻ എളുപ്പമുള്ളതിൽ നിന്ന് നിങ്ങൾ ആരംഭിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഉപയോഗപ്രദമല്ലാത്ത SLO-കൾ ലഭിക്കും. തൽഫലമായി, തുടക്കത്തിൽ ആവശ്യമുള്ള ലക്ഷ്യങ്ങൾ തിരിച്ചറിയുകയും പിന്നീട് നിർദ്ദിഷ്ട സൂചകങ്ങളുമായി പ്രവർത്തിക്കുകയും ചെയ്യുന്നത് സൂചകങ്ങൾ തിരഞ്ഞെടുത്ത് ലക്ഷ്യങ്ങൾ നേടുന്നതിനേക്കാൾ നന്നായി പ്രവർത്തിക്കുന്നുവെന്ന് ഞങ്ങൾ ചിലപ്പോൾ കണ്ടെത്തിയിട്ടുണ്ട്.

നിങ്ങളുടെ ലക്ഷ്യങ്ങൾ നിർവ്വചിക്കുക

പരമാവധി വ്യക്തതയ്ക്കായി, SLO-കൾ എങ്ങനെ അളക്കുന്നുവെന്നും അവ സാധുതയുള്ള വ്യവസ്ഥകളും നിർവചിക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, നമുക്ക് ഇനിപ്പറയുന്നവ പറയാം (രണ്ടാമത്തെ വരി ആദ്യത്തേതിന് സമാനമാണ്, എന്നാൽ SLI ഡിഫോൾട്ടുകൾ ഉപയോഗിക്കുന്നു):

• Get RPC കോളുകളുടെ 99% (ശരാശരി 1 മിനിറ്റിൽ കൂടുതൽ) 100ms-ൽ താഴെ സമയത്തിനുള്ളിൽ പൂർത്തിയാകും (എല്ലാ ബാക്കെൻഡ് സെർവറുകളിലുടനീളം അളക്കുന്നത്).
• 99% Get RPC കോളുകളും 100ms-ൽ താഴെ സമയത്തിനുള്ളിൽ പൂർത്തിയാകും.

പ്രകടന കർവുകളുടെ ആകൃതി പ്രധാനമാണെങ്കിൽ, നിങ്ങൾക്ക് ഒന്നിലധികം SLO-കൾ വ്യക്തമാക്കാം:

• 90% RPC കോളുകളും 1 എംഎസിൽ താഴെ സമയത്തിനുള്ളിൽ പൂർത്തിയാക്കി.
• 99% RPC കോളുകളും 10 എംഎസിൽ താഴെ സമയത്തിനുള്ളിൽ പൂർത്തിയാക്കി.
• 99.9% RPC കോളുകളും 100 എംഎസിൽ താഴെ സമയത്തിനുള്ളിൽ പൂർത്തിയാക്കി.

നിങ്ങളുടെ ഉപയോക്താക്കൾ വൈവിധ്യമാർന്ന ജോലിഭാരങ്ങൾ സൃഷ്ടിക്കുകയാണെങ്കിൽ: ബൾക്ക് പ്രോസസ്സിംഗും (ഇതിനായി ത്രൂപുട്ട് പ്രധാനമാണ്) ഇന്ററാക്ടീവ് പ്രോസസ്സിംഗും (ഇതിന് ലേറ്റൻസി പ്രധാനമാണ്), ഓരോ ലോഡ് ക്ലാസിനും പ്രത്യേക ലക്ഷ്യങ്ങൾ നിർവചിക്കുന്നത് മൂല്യവത്തായിരിക്കാം:

• ഉപഭോക്തൃ അഭ്യർത്ഥനകളിൽ 95% ത്രൂപുട്ട് ആവശ്യമാണ്. നിർവ്വഹിച്ച RPC കോളുകളുടെ എണ്ണം <1 സെ.
• 99% ക്ലയന്റുകളും കാലതാമസത്തെക്കുറിച്ച് ശ്രദ്ധിക്കുന്നു. ട്രാഫിക്ക് <1 KB, <10 ms പ്രവർത്തിക്കുമ്പോൾ RPC കോളുകളുടെ എണ്ണം സജ്ജീകരിക്കുക.

SLO-കൾ 100% സമയവും പാലിക്കപ്പെടുമെന്ന് ശഠിക്കുന്നത് യാഥാർത്ഥ്യത്തിന് നിരക്കാത്തതും അഭികാമ്യമല്ലാത്തതുമാണ്: ഇത് പുതിയ പ്രവർത്തനക്ഷമതയും വിന്യാസവും അവതരിപ്പിക്കുന്നതിന്റെ വേഗത കുറയ്ക്കും, ചെലവേറിയ പരിഹാരങ്ങൾ ആവശ്യമാണ്. പകരം, ഒരു പിശക് ബജറ്റ് അനുവദിക്കുന്നതാണ് നല്ലത് - സിസ്റ്റം പ്രവർത്തനരഹിതമായ സമയത്തിന്റെ ശതമാനം - അനുവദനീയമാണ് - കൂടാതെ ഈ മൂല്യം ദിവസേനയോ ആഴ്‌ചയിലോ നിരീക്ഷിക്കുക. സീനിയർ മാനേജ്‌മെന്റ് പ്രതിമാസ അല്ലെങ്കിൽ ത്രൈമാസ മൂല്യനിർണ്ണയങ്ങൾ ആഗ്രഹിച്ചേക്കാം. (പിശക് ബജറ്റ് മറ്റൊരു SLO യുമായി താരതമ്യപ്പെടുത്തുന്നതിനുള്ള ഒരു SLO ആണ്.)

SLO ലംഘനങ്ങളുടെ ശതമാനം പിശക് ബജറ്റുമായി താരതമ്യപ്പെടുത്താവുന്നതാണ് (അധ്യായം 3 ഉം വിഭാഗവും കാണുക "പിശക് ബജറ്റുകൾക്കുള്ള പ്രചോദനം"), പുതിയ റിലീസുകൾ എപ്പോൾ വിന്യസിക്കണമെന്ന് തീരുമാനിക്കുന്ന പ്രക്രിയയുടെ ഇൻപുട്ടായി ഉപയോഗിക്കുന്ന വ്യത്യാസ മൂല്യം.

ടാർഗെറ്റ് മൂല്യങ്ങൾ തിരഞ്ഞെടുക്കുന്നു

തിരഞ്ഞെടുത്ത SLI-കളിലും SLO-കളിലും (ഒരുപക്ഷേ SLA-കളിലും) പ്രതിഫലിക്കേണ്ട ഉൽപ്പന്നങ്ങളും ബിസിനസ് താൽപ്പര്യങ്ങളും കാരണം ആസൂത്രണ മൂല്യങ്ങൾ (SLO-കൾ) തിരഞ്ഞെടുക്കുന്നത് തികച്ചും സാങ്കേതിക പ്രവർത്തനമല്ല. അതുപോലെ, സ്റ്റാഫിംഗ്, മാർക്കറ്റിലേക്കുള്ള സമയം, ഉപകരണങ്ങളുടെ ലഭ്യത, ധനസഹായം എന്നിവയുമായി ബന്ധപ്പെട്ട പ്രശ്നങ്ങൾ സംബന്ധിച്ച വിവരങ്ങൾ കൈമാറേണ്ടി വന്നേക്കാം. SRE ഈ സംഭാഷണത്തിന്റെ ഭാഗമാകുകയും വ്യത്യസ്ത ഓപ്ഷനുകളുടെ അപകടസാധ്യതകളും പ്രവർത്തനക്ഷമതയും മനസ്സിലാക്കാൻ സഹായിക്കുകയും വേണം. കൂടുതൽ ഉൽപ്പാദനക്ഷമമായ ചർച്ച ഉറപ്പാക്കാൻ സഹായിച്ചേക്കാവുന്ന ചില ചോദ്യങ്ങളുമായി ഞങ്ങൾ എത്തിയിരിക്കുന്നു:

നിലവിലെ പ്രകടനത്തെ അടിസ്ഥാനമാക്കി ഒരു ലക്ഷ്യം തിരഞ്ഞെടുക്കരുത്.
ഒരു സിസ്റ്റത്തിന്റെ ശക്തിയും പരിമിതികളും മനസ്സിലാക്കുന്നത് പ്രധാനമാണെങ്കിലും, യുക്തിയില്ലാതെ മെട്രിക്‌സ് പൊരുത്തപ്പെടുത്തുന്നത് സിസ്റ്റം നിലനിർത്തുന്നതിൽ നിന്ന് നിങ്ങളെ തടയും: കാര്യമായ പുനർരൂപകൽപ്പന കൂടാതെ നേടിയെടുക്കാൻ കഴിയാത്ത ലക്ഷ്യങ്ങൾ കൈവരിക്കുന്നതിന് വീരോചിതമായ പരിശ്രമങ്ങൾ ആവശ്യമാണ്.

ലളിതമായി സൂക്ഷിക്കുക
സങ്കീർണ്ണമായ SLI കണക്കുകൂട്ടലുകൾക്ക് സിസ്റ്റം പ്രകടനത്തിലെ മാറ്റങ്ങൾ മറയ്ക്കാനും പ്രശ്നത്തിന്റെ കാരണം കണ്ടെത്തുന്നത് ബുദ്ധിമുട്ടാക്കാനും കഴിയും.

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

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

പൂർണതയെ പിന്തുടരരുത്
ലോഡിന് കീഴിലുള്ള സിസ്റ്റത്തിന്റെ പെരുമാറ്റത്തെക്കുറിച്ച് കൂടുതലറിയുമ്പോൾ, കാലക്രമേണ നിങ്ങൾക്ക് SLO-കളുടെ നിർവചനങ്ങളും ലക്ഷ്യങ്ങളും പരിഷ്കരിക്കാനാകും. അത് അപ്രാപ്യമാണെന്ന് നിങ്ങൾ കണ്ടെത്തുമ്പോൾ വിശ്രമിക്കേണ്ട അമിതമായ കർശനമായ ലക്ഷ്യം തിരഞ്ഞെടുക്കുന്നതിനേക്കാൾ, കാലക്രമേണ നിങ്ങൾ പരിഷ്കരിക്കുന്ന ഒരു ഫ്ലോട്ടിംഗ് ലക്ഷ്യത്തോടെ ആരംഭിക്കുന്നതാണ് നല്ലത്.

SLO-കൾക്ക് SRE-കൾക്കും ഉൽപ്പന്ന ഡെവലപ്പർമാർക്കും മുൻഗണന നൽകുന്ന ഒരു പ്രധാന ഡ്രൈവർ ആകാൻ കഴിയും, കാരണം അവ ഉപയോക്താക്കളുടെ ആശങ്ക പ്രതിഫലിപ്പിക്കുന്നു. ഒരു നല്ല SLO ഒരു വികസന ടീമിന് ഉപയോഗപ്രദമായ ഒരു എൻഫോഴ്‌സ്‌മെന്റ് ഉപകരണമാണ്. എന്നാൽ മോശമായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന ഒരു SLO, അമിതമായ ആക്രമണാത്മക SLO നേടാൻ ടീം വീരോചിതമായ ശ്രമങ്ങൾ നടത്തുകയാണെങ്കിൽ, അല്ലെങ്കിൽ SLO വളരെ കുറവാണെങ്കിൽ ഒരു മോശം ഉൽപ്പന്നം പാഴായ ജോലിയിലേക്ക് നയിക്കും. SLO ഒരു ശക്തമായ ലിവർ ആണ്, അത് വിവേകത്തോടെ ഉപയോഗിക്കുക.

നിങ്ങളുടെ അളവുകൾ നിയന്ത്രിക്കുക

സിസ്റ്റങ്ങൾ കൈകാര്യം ചെയ്യാൻ ഉപയോഗിക്കുന്ന പ്രധാന ഘടകങ്ങളാണ് SLI, SLO എന്നിവ:

• SLI സിസ്റ്റങ്ങൾ നിരീക്ഷിക്കുകയും അളക്കുകയും ചെയ്യുക.
• SLI-യെ SLO-മായി താരതമ്യം ചെയ്‌ത് നടപടി ആവശ്യമാണോ എന്ന് തീരുമാനിക്കുക.
• പ്രവർത്തനം ആവശ്യമാണെങ്കിൽ, ലക്ഷ്യം നേടുന്നതിന് എന്താണ് സംഭവിക്കേണ്ടതെന്ന് കണ്ടെത്തുക.
• ഈ പ്രവർത്തനം പൂർത്തിയാക്കുക.

ഉദാഹരണത്തിന്, അഭ്യർത്ഥനയുടെ സമയപരിധി അവസാനിക്കുന്നതായും ഒന്നും ചെയ്തില്ലെങ്കിൽ ഏതാനും മണിക്കൂറുകൾക്കുള്ളിൽ SLO തകർക്കുമെന്നും ഘട്ടം 2 കാണിക്കുന്നുവെങ്കിൽ, സെർവറുകൾ സിപിയു ബന്ധിതമാണെന്നും കൂടുതൽ സെർവറുകൾ ചേർക്കുന്നത് ലോഡ് വിതരണം ചെയ്യുമെന്ന അനുമാനം പരിശോധിക്കുന്നത് ഘട്ടം 3-ൽ ഉൾപ്പെട്ടേക്കാം. ഒരു SLO ഇല്ലെങ്കിൽ, (അല്ലെങ്കിൽ എപ്പോൾ) നടപടിയെടുക്കണമെന്ന് നിങ്ങൾക്കറിയില്ല.

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

നിങ്ങളുടെ ഉപയോക്താക്കൾക്കായി റിയലിസ്റ്റിക് പ്രതീക്ഷകൾ സജ്ജീകരിക്കുന്നതിന്, ഇനിപ്പറയുന്ന ഒന്നോ രണ്ടോ തന്ത്രങ്ങൾ ഉപയോഗിക്കുക:

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

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

പ്രായോഗികമായി കരാറുകൾ

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

വിവർത്തനം അവസാനം വരെ വായിച്ചതിന് നന്ദി. നിരീക്ഷണത്തെക്കുറിച്ച് എന്റെ ടെലിഗ്രാം ചാനൽ സബ്സ്ക്രൈബ് ചെയ്യുക നിരീക്ഷണം_ഇത് и മീഡിയത്തിൽ ബ്ലോഗ്.

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