ഒരു SRE എഞ്ചിനീയർ ഇന്റേൺ ആയി ഞാൻ എങ്ങനെ ഒരാഴ്ച ചെലവഴിച്ചു. ഒരു സോഫ്റ്റ്‌വെയർ എഞ്ചിനീയറുടെ കണ്ണിലൂടെയുള്ള ഡ്യൂട്ടി

SRE എഞ്ചിനീയർ - ട്രെയിനി

ആദ്യം, ഞാൻ എന്നെത്തന്നെ പരിചയപ്പെടുത്തട്ടെ. ഞാൻ - @tristan.വായിക്കുക, ഗ്രൂപ്പിലെ ഫ്രണ്ട് എൻഡ് എഞ്ചിനീയർ നിരീക്ഷിക്കുക:: ആരോഗ്യം GitLab. കഴിഞ്ഞ ആഴ്ച ഞങ്ങളുടെ ഓൺ-കോൾ SRE എഞ്ചിനീയർമാരിൽ ഒരാളുമായി ഇന്റേൺ ചെയ്യാനുള്ള ബഹുമതി എനിക്ക് ലഭിച്ചു. ഡ്യൂട്ടിയിലുള്ള ഉദ്യോഗസ്ഥൻ ദിവസേനയുള്ള സംഭവങ്ങളോട് എങ്ങനെ പ്രതികരിക്കുന്നുവെന്ന് നിരീക്ഷിക്കുകയും ജോലിയിൽ യഥാർത്ഥ ജീവിതാനുഭവം നേടുകയും ചെയ്യുക എന്നതായിരുന്നു ലക്ഷ്യം. ഞങ്ങളുടെ എഞ്ചിനീയർമാർ ഉപയോക്തൃ ആവശ്യങ്ങൾ നന്നായി മനസ്സിലാക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു പ്രവർത്തനങ്ങൾ നിരീക്ഷിക്കുക:: ആരോഗ്യം.

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

സംഭവങ്ങൾ

ഒരാഴ്ചയ്ക്കിടെ 2 സംഭവങ്ങളുണ്ടായി.

1. ക്രിപ്‌റ്റോമിനർ

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

ഈ സംഭവം ശ്രദ്ധയിൽപ്പെട്ടില്ലെങ്കിൽ, ഒരു ഓട്ടോമേറ്റഡ് ടൂൾ അത് പിടിക്കുമായിരുന്നു, എന്നാൽ ഈ സാഹചര്യത്തിൽ, SRE എഞ്ചിനീയർ ആദ്യം ലംഘനം ശ്രദ്ധിച്ചു. ഒരു സംഭവ ടാസ്‌ക് സൃഷ്‌ടിച്ചു, പക്ഷേ അതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ അടച്ചിരിക്കുന്നു.

2. കാനറിയുടെയും പ്രധാന ആപ്ലിക്കേഷനുകളുടെയും പ്രകടന നിലവാരത്തകർച്ച

Gitlab.com-ലെ കാനറിയിലെയും പ്രധാന വെബ് ആപ്ലിക്കേഷനുകളിലെയും മാന്ദ്യവും പിശകുകളുടെ ആവൃത്തിയും വർധിച്ചതാണ് സംഭവത്തിന് കാരണം. നിരവധി അപ്ഡെക്സ് മൂല്യങ്ങൾ ലംഘിക്കപ്പെട്ടു.

സംഭവ ടാസ്ക് തുറക്കുക: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

പ്രധാന കണ്ടെത്തലുകൾ

എന്റെ ഡ്യൂട്ടിയിലെ ആഴ്ചയിൽ ഞാൻ പഠിച്ച ചില കാര്യങ്ങൾ ഇതാ.

1. മാനദണ്ഡത്തിൽ നിന്നുള്ള വ്യതിയാനങ്ങൾ കണ്ടെത്തുമ്പോൾ അലേർട്ടുകൾ ഏറ്റവും ഉപയോഗപ്രദമാണ്.

അലേർട്ടുകളെ പല തരങ്ങളായി തിരിക്കാം:

• "സെക്കൻഡിൽ 10 5xx പിശകുകൾ സംഭവിച്ചു" പോലുള്ള ഒരു നിശ്ചിത പരിധി മൂല്യത്തെ അടിസ്ഥാനമാക്കിയുള്ള അലേർട്ടുകൾ.
• "ഒരു നിശ്ചിത സമയത്ത് അഭ്യർത്ഥനകളുടെ മൊത്തം വോളിയത്തിന്റെ 5% ന് 10xx പിശകുകളുടെ ആവൃത്തി" പോലുള്ള ഒരു ശതമാനം മൂല്യമുള്ള അലേർട്ടുകൾ.
• ചരിത്രപരമായ ശരാശരിയെ അടിസ്ഥാനമാക്കിയുള്ള അലേർട്ടുകൾ "5-ാം പെർസെൻറ്റൈലിൽ 90xx പിശകുകൾ".

സാധാരണയായി പറഞ്ഞാൽ, ഡ്യൂട്ടിയിലുള്ള SRE-കൾക്ക് 2 ഉം 3 ഉം കൂടുതൽ ഉപയോഗപ്രദമാണ്, കാരണം അവ പ്രക്രിയയിലെ മാനദണ്ഡത്തിൽ നിന്നുള്ള വ്യതിയാനങ്ങൾ വെളിപ്പെടുത്തുന്നു.

2. പല അലേർട്ടുകളും ഒരിക്കലും സംഭവങ്ങളിലേക്ക് വർദ്ധിക്കുന്നില്ല.

എസ്ആർ എഞ്ചിനീയർമാർ നിരന്തരമായ അലേർട്ടുകൾ കൈകാര്യം ചെയ്യുന്നു, അവയിൽ പലതും യഥാർത്ഥത്തിൽ നിർണായകമല്ല.

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

ഏത് അലേർട്ടുകളാണ് യഥാർത്ഥത്തിൽ ഗുരുതരമായ എന്തെങ്കിലും സൂചിപ്പിക്കുന്നതെന്നും അവ വർധിപ്പിച്ച് കൈകാര്യം ചെയ്യേണ്ടതുണ്ടോ എന്നും നിർണ്ണയിക്കുക എന്നതാണ് ഓൺ-കോൾ SRE-യുടെ ജോലി. ഇത് അലേർട്ടുകളുടെ വഴക്കമില്ലായ്മ മൂലമാണെന്ന് ഞാൻ സംശയിക്കുന്നു: മുകളിൽ വിവരിച്ച സാഹചര്യത്തിന് അനുസൃതമായി അലേർട്ടുകൾ ക്രമീകരിക്കുന്നതിന് നിരവധി ലെവലുകളോ “സ്മാർട്ട്” വഴികളോ ഉണ്ടെങ്കിൽ അത് നന്നായിരിക്കും.

ഫീച്ചർ നിർദ്ദേശം: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. ഡ്യൂട്ടിയിലുള്ള ഞങ്ങളുടെ SRE-കൾ ധാരാളം ടൂളുകൾ ഉപയോഗിക്കുന്നു.

ആന്തരികം:

• GitLab ഇൻഫ്രാ പ്രോജക്റ്റ്: റൺബുക്കുകൾ ഇവിടെയുണ്ട്, ഷിഫ്റ്റ്/ആഴ്‌ച അസൈൻമെന്റുകൾ, സംഭവ പ്രതികരണ ടാസ്‌ക്കുകൾ.
• GitLab പ്രശ്നങ്ങൾ: അന്വേഷണങ്ങൾ, അവലോകനങ്ങൾ, പരിപാലനം എന്നിവയും പ്രശ്നങ്ങളിൽ ട്രാക്ക് ചെയ്യപ്പെടുന്നു.
• GitLab ലേബലുകൾ: ടാസ്ക് ആക്റ്റിവിറ്റി ട്രാക്ക് ചെയ്യാൻ ബോട്ടുകൾ ഉപയോഗിക്കുന്ന നിർദ്ദിഷ്ട ലേബലുകൾ ഉപയോഗിച്ച് ഓട്ടോമേഷൻ ടാസ്ക്കുകൾ സമാരംഭിക്കുന്നു.

ബാഹ്യ:

• പേജർഡ്യൂട്ടി: അലേർട്ടുകൾ
• Slack: PagerDuty/AlertManager സന്ദേശ ഫ്ലോ ഇവിടെ പോകുന്നു. ഒരു അലേർട്ട് ക്ലോസ് ചെയ്യുക അല്ലെങ്കിൽ ഒരു സംഭവത്തിലേക്ക് വർദ്ധിക്കുന്നത് പോലുള്ള വിവിധ ജോലികൾ ചെയ്യുന്നതിന് സ്ലാഷ് കമാൻഡുകളുമായുള്ള സംയോജനം.
• ഗ്രാഫാന: ദീർഘകാല ട്രെൻഡുകളിൽ ശ്രദ്ധ കേന്ദ്രീകരിച്ച് മെട്രിക്സിന്റെ ദൃശ്യവൽക്കരണം.
• കിബാന: വിഷ്വലൈസേഷൻ/ലോഗ് സെർച്ച്, നിർദ്ദിഷ്ട ഇവന്റുകൾ കൂടുതൽ ആഴത്തിൽ പരിശോധിക്കാനുള്ള കഴിവ് എന്നിവ നൽകുന്നു.
• സൂം: സൂമിൽ നിരന്തരം പ്രവർത്തിക്കുന്ന "ബ്രേക്ക്ഔട്ട് റൂം" ഉണ്ട്. വിലയേറിയ സമയം പാഴാക്കാതെ ഒരു മുറി സൃഷ്ടിക്കാതെയും പങ്കാളികളെ ലിങ്കുചെയ്യാതെയും ഇവന്റുകൾ വേഗത്തിൽ ചർച്ച ചെയ്യാൻ ഇത് SRE എഞ്ചിനീയർമാരെ അനുവദിക്കുന്നു.

കൂടാതെ മറ്റു പലതും.

4. GitLab ഉപയോഗിച്ച് GitLab.com നിരീക്ഷിക്കുന്നത് പരാജയത്തിന്റെ ഒരു പോയിന്റാണ്

GitLab.com-ന് ഒരു വലിയ സേവന തടസ്സം അനുഭവപ്പെടുകയാണെങ്കിൽ, പ്രശ്നം പരിഹരിക്കാനുള്ള ഞങ്ങളുടെ കഴിവിനെ അത് ബാധിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ല. GitLab.com മാനേജ് ചെയ്യാൻ രണ്ടാമത്തെ GitLab ഇൻസ്റ്റൻസ് സമാരംഭിച്ചുകൊണ്ട് ഇത് നിർത്താം. വാസ്തവത്തിൽ, ഇത് ഇതിനകം ഞങ്ങൾക്ക് വേണ്ടി പ്രവർത്തിക്കുന്നു: https://ops.gitlab.net/.

5. GitLab-ലേക്ക് ചേർക്കുന്നത് പരിഗണിക്കേണ്ട ചില സവിശേഷതകൾ

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

SRE എഞ്ചിനീയർമാർക്ക് ഒരുപാട് സങ്കീർണ്ണതകളാൽ ബുദ്ധിമുട്ടാണ്. ഈ പ്രശ്‌നങ്ങളെ അഭിസംബോധന ചെയ്യുന്ന കൂടുതൽ GitLab ഉൽപ്പന്നങ്ങൾ കാണുന്നത് വളരെ നല്ലതായിരിക്കും. മുകളിൽ സൂചിപ്പിച്ച വർക്ക്ഫ്ലോകൾ എളുപ്പമാക്കുന്ന ഉൽപ്പന്നത്തിലേക്ക് ചില കൂട്ടിച്ചേർക്കലുകൾക്കായി ഞങ്ങൾ ഇതിനകം പ്രവർത്തിക്കുന്നു. വിശദാംശങ്ങൾ ലഭ്യമാണ് Ops ഉൽപ്പന്ന വിഷൻ വിഭാഗം.

ഈ മികച്ച ഫീച്ചറുകളെല്ലാം ഒരുമിച്ച് കൊണ്ടുവരാൻ 2020-ൽ ഞങ്ങൾ ടീമിനെ വികസിപ്പിക്കുകയാണ്. താൽപ്പര്യമുണ്ടെങ്കിൽ, ദയവായി പരിശോധിക്കുക ഒഴിവുകൾ, കൂടാതെ എന്തെങ്കിലും ചോദ്യങ്ങൾ ഉണ്ടെങ്കിൽ ഞങ്ങളുടെ ടീമിലെ ആരെയും ബന്ധപ്പെടാൻ മടിക്കേണ്ടതില്ല.

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