ടോപ്പ് ഫകപോവ് സിയാൻ

എല്ലാം നല്ലത്! 

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

പ്രീമുൽ

വളരെക്കാലം മുമ്പ്, സിയാൻ മോണോലിത്തുകൾ അടങ്ങിയപ്പോൾ, ഇതുവരെ മൈക്രോസർവീസുകളുടെ സൂചനകളൊന്നും ഇല്ലാതിരുന്നപ്പോൾ, ഞങ്ങൾ 3-5 പേജുകൾ പരിശോധിച്ച് ഒരു ഉറവിടത്തിന്റെ ലഭ്യത അളന്നു. 

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

സൈറ്റിന്റെ പ്രധാന പേജുകൾ അല്ലെങ്കിൽ ഞങ്ങൾ താഴെ തട്ടിയെന്ന് ഞങ്ങൾ എങ്ങനെ മനസ്സിലാക്കുന്നു

 
പിശകിന്റെ മുൻ‌ഗണന എങ്ങനെയെങ്കിലും മനസ്സിലാക്കുന്നതിന്, ബിസിനസ്സ് പ്രവർത്തനത്തിനുള്ള ഏറ്റവും നിർണായക സൈറ്റ് പേജുകൾ ഞങ്ങൾ തിരിച്ചറിഞ്ഞു. അവ ഉപയോഗിച്ച്, വിജയിച്ച/പരാജയപ്പെട്ട അഭ്യർത്ഥനകളുടെയും കാലഹരണപ്പെടലുകളുടെയും എണ്ണം ഞങ്ങൾ കണക്കാക്കുന്നു. ഞങ്ങൾ പ്രവർത്തനസമയം അളക്കുന്നത് ഇങ്ങനെയാണ്. 

പ്രധാന സേവനത്തിന് - പരസ്യങ്ങൾ തിരയുന്നതിനും സമർപ്പിക്കുന്നതിനും ഉത്തരവാദികളായ നിരവധി സൂപ്പർ-പ്രധാന വിഭാഗങ്ങൾ സൈറ്റിൽ ഉണ്ടെന്ന് ഞങ്ങൾ കണ്ടെത്തിയെന്ന് പറയാം. പരാജയപ്പെടുന്ന അഭ്യർത്ഥനകളുടെ എണ്ണം 1% കവിയുന്നുവെങ്കിൽ, ഇതൊരു നിർണായക സംഭവമാണ്. പ്രൈം ടൈമിൽ 15 മിനിറ്റിനുള്ളിൽ പിശക് നിരക്ക് 0,1% കവിയുന്നുവെങ്കിൽ, ഇതും ഒരു നിർണായക സംഭവമായി കണക്കാക്കപ്പെടുന്നു. ഈ മാനദണ്ഡങ്ങൾ മിക്ക സംഭവങ്ങളെയും ഉൾക്കൊള്ളുന്നു; ബാക്കിയുള്ളവ ഈ ലേഖനത്തിന്റെ പരിധിക്കപ്പുറമാണ്.

മികച്ച സംഭവങ്ങൾ സിയാൻ

അതിനാൽ, ഒരു സംഭവം നടന്നുവെന്ന വസ്തുത നിർണ്ണയിക്കാൻ ഞങ്ങൾ തീർച്ചയായും പഠിച്ചു. 

ഇപ്പോൾ എല്ലാ സംഭവങ്ങളും വിശദമായി വിവരിക്കുകയും ജീര ഇതിഹാസത്തിൽ പ്രതിഫലിക്കുകയും ചെയ്യുന്നു. വഴി: ഇതിനായി ഞങ്ങൾ ഒരു പ്രത്യേക പ്രോജക്റ്റ് ആരംഭിച്ചു, അതിനെ FAIL എന്ന് വിളിക്കുന്നു - അതിൽ ഇതിഹാസങ്ങൾ മാത്രമേ സൃഷ്ടിക്കാൻ കഴിയൂ. 

കഴിഞ്ഞ കുറച്ച് വർഷങ്ങളിലെ എല്ലാ പരാജയങ്ങളും നിങ്ങൾ ശേഖരിക്കുകയാണെങ്കിൽ, നേതാക്കൾ: 

• mssql ബന്ധപ്പെട്ട സംഭവങ്ങൾ;
• ബാഹ്യ ഘടകങ്ങൾ മൂലമുണ്ടാകുന്ന സംഭവങ്ങൾ;
• അഡ്മിൻ പിശകുകൾ.

അഡ്മിനിസ്ട്രേറ്റർമാരുടെ തെറ്റുകളും മറ്റ് രസകരമായ ചില പരാജയങ്ങളും കൂടുതൽ വിശദമായി നോക്കാം.

അഞ്ചാം സ്ഥാനം - "ഡിഎൻഎസിൽ കാര്യങ്ങൾ ക്രമീകരിക്കുന്നു"

കൊടുങ്കാറ്റുള്ള ഒരു ചൊവ്വാഴ്ചയായിരുന്നു അത്. DNS ക്ലസ്റ്ററിലെ ക്രമം പുനഃസ്ഥാപിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു. 

ആന്തരിക ഡിഎൻഎസ് സെർവറുകൾ ബൈൻഡിൽ നിന്ന് പവർഡിഎൻഎസിലേക്ക് മാറ്റാൻ ഞാൻ ആഗ്രഹിച്ചു, ഇതിനായി ഡിഎൻഎസ് ഒഴികെ മറ്റൊന്നുമില്ല. 

ഞങ്ങളുടെ DC-കളുടെ ഓരോ ലൊക്കേഷനിലും ഞങ്ങൾ ഒരു DNS സെർവർ സ്ഥാപിച്ചു, സോണുകൾ ബൈൻഡിൽ നിന്ന് powerdns-ലേക്ക് മാറ്റാനും ഇൻഫ്രാസ്ട്രക്ചർ പുതിയ സെർവറുകളിലേക്ക് മാറ്റാനുമുള്ള നിമിഷം വന്നു. 

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

നിഗമനങ്ങൾ:

ജോലിക്കുള്ള തയ്യാറെടുപ്പിനിടെ ഞങ്ങൾ മുമ്പ് ബാഹ്യ ഘടകങ്ങളെ അവഗണിച്ചെങ്കിൽ, ഇപ്പോൾ അവയും ഞങ്ങൾ തയ്യാറെടുക്കുന്ന പട്ടികയിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. ഇപ്പോൾ എല്ലാ ഘടകങ്ങളും n-2 റിസർവ് ചെയ്തിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു, കൂടാതെ ജോലി സമയത്ത് ഈ ലെവൽ n-1 ആയി താഴ്ത്താൻ കഴിയും.

• ഒരു ആക്ഷൻ പ്ലാൻ തയ്യാറാക്കുമ്പോൾ, സേവനം പരാജയപ്പെടാൻ സാധ്യതയുള്ള പോയിന്റുകൾ അടയാളപ്പെടുത്തുക, കൂടാതെ എല്ലാം "മോശം മുതൽ മോശം വരെ" മുൻകൂട്ടി കണ്ട ഒരു സാഹചര്യത്തിലൂടെ ചിന്തിക്കുക.
• വ്യത്യസ്ത ജിയോലൊക്കേഷനുകൾ/ഡാറ്റ സെന്ററുകൾ/റാക്കുകൾ/സ്വിച്ചുകൾ/ഇൻപുട്ടുകൾ എന്നിവയിലുടനീളം ആന്തരിക DNS സെർവറുകൾ വിതരണം ചെയ്യുക.
• ഓരോ സെർവറിലും, ഒരു ലോക്കൽ കാഷിംഗ് DNS സെർവർ ഇൻസ്റ്റാൾ ചെയ്യുക, അത് പ്രധാന DNS സെർവറുകളിലേക്ക് അഭ്യർത്ഥനകൾ റീഡയറക്‌ടുചെയ്യുന്നു, അത് ലഭ്യമല്ലെങ്കിൽ, അത് കാഷെയിൽ നിന്ന് പ്രതികരിക്കും. 

നാലാം സ്ഥാനം - "Nginx-ൽ കാര്യങ്ങൾ ക്രമീകരിക്കുന്നു"

ഒരു നല്ല ദിവസം, "ഞങ്ങൾക്ക് ഇത് മതിയാകും" എന്ന് ഞങ്ങളുടെ ടീം തീരുമാനിച്ചു, കൂടാതെ nginx കോൺഫിഗറുകൾ റീഫാക്റ്ററിംഗ് പ്രക്രിയ ആരംഭിച്ചു. കോൺഫിഗറുകളെ അവബോധജന്യമായ ഒരു ഘടനയിലേക്ക് കൊണ്ടുവരിക എന്നതാണ് പ്രധാന ലക്ഷ്യം. മുമ്പ്, എല്ലാം "ചരിത്രപരമായി സ്ഥാപിതമായിരുന്നു" കൂടാതെ ഒരു യുക്തിയും വഹിച്ചിരുന്നില്ല. ഇപ്പോൾ ഓരോ സെർവർ_നാമവും അതേ പേരിലുള്ള ഒരു ഫയലിലേക്ക് നീക്കി, എല്ലാ കോൺഫിഗറേഷനുകളും ഫോൾഡറുകളായി വിതരണം ചെയ്തു. വഴിയിൽ, കോൺഫിഗറിൽ 253949 ലൈനുകൾ അല്ലെങ്കിൽ 7836520 പ്രതീകങ്ങൾ അടങ്ങിയിരിക്കുന്നു കൂടാതെ ഏകദേശം 7 മെഗാബൈറ്റുകൾ എടുക്കുന്നു. ഘടനയുടെ ഉയർന്ന നില: 

Nginx ഘടന

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

ഇത് വളരെ മികച്ചതായി മാറി, എന്നാൽ കോൺഫിഗറുകളുടെ പേരുമാറ്റുകയും വിതരണം ചെയ്യുകയും ചെയ്യുന്ന പ്രക്രിയയിൽ, അവയിൽ ചിലത് തെറ്റായ വിപുലീകരണമുള്ളതിനാൽ ഉൾപ്പെടുത്തിയ *.conf നിർദ്ദേശത്തിൽ ഉൾപ്പെടുത്തിയിട്ടില്ല. തൽഫലമായി, ചില ഹോസ്റ്റുകൾ ലഭ്യമല്ലാതായി, പ്രധാന പേജിലേക്ക് 301 തിരികെ നൽകി. പ്രതികരണ കോഡ് 5xx/4xx അല്ല എന്ന വസ്തുത കാരണം, ഇത് പെട്ടെന്ന് ശ്രദ്ധയിൽപ്പെട്ടില്ല, പക്ഷേ രാവിലെ മാത്രം. അതിനുശേഷം, ഇൻഫ്രാസ്ട്രക്ചർ ഘടകങ്ങൾ പരിശോധിക്കാൻ ഞങ്ങൾ ടെസ്റ്റുകൾ എഴുതാൻ തുടങ്ങി.

നിഗമനങ്ങൾ: 

• നിങ്ങളുടെ കോൺഫിഗറേഷനുകൾ ശരിയായി രൂപപ്പെടുത്തുക (nginx മാത്രമല്ല) പ്രോജക്റ്റിന്റെ പ്രാരംഭ ഘട്ടത്തിൽ ഘടനയെക്കുറിച്ച് ചിന്തിക്കുക. ഇതുവഴി നിങ്ങൾ അവരെ ടീമിന് കൂടുതൽ മനസ്സിലാക്കാൻ കഴിയും, ഇത് TTM കുറയ്ക്കും.
• ചില ഇൻഫ്രാസ്ട്രക്ചർ ഘടകങ്ങൾക്കായി ടെസ്റ്റുകൾ എഴുതുക. ഉദാഹരണത്തിന്: എല്ലാ കീ സെർവർ_നാമങ്ങളും ശരിയായ സ്റ്റാറ്റസ് + പ്രതികരണ ബോഡി നൽകുന്നു എന്ന് പരിശോധിക്കുന്നു. ഘടകത്തിന്റെ അടിസ്ഥാന പ്രവർത്തനങ്ങൾ പരിശോധിക്കുന്ന കുറച്ച് സ്‌ക്രിപ്റ്റുകൾ കയ്യിലുണ്ടെങ്കിൽ മാത്രം മതിയാകും, അതിനാൽ മറ്റെന്താണ് പരിശോധിക്കേണ്ടതെന്ന് വെളുപ്പിന് 3 മണിക്ക് ഓർമ്മിക്കാതിരിക്കാൻ. 

മൂന്നാം സ്ഥാനം - "പെട്ടെന്ന് കസാന്ദ്രയിൽ സ്ഥലം തീർന്നു"

ഡാറ്റ ക്രമാനുഗതമായി വളർന്നു, കസാന്ദ്ര ക്ലസ്റ്ററിൽ വലിയ കേസുകളുടെ അറ്റകുറ്റപ്പണികൾ പരാജയപ്പെടാൻ തുടങ്ങിയ നിമിഷം വരെ എല്ലാം ശരിയായിരുന്നു, കാരണം അവയിൽ ഒതുക്കത്തിന് പ്രവർത്തിക്കാൻ കഴിഞ്ഞില്ല. 

ഒരു കൊടുങ്കാറ്റുള്ള ദിവസം, ക്ലസ്റ്റർ മിക്കവാറും ഒരു മത്തങ്ങയായി മാറി, അതായത്:

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

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

നിഗമനങ്ങൾ:

• എല്ലാ കസാന്ദ്ര സെർവറുകളിലും, ഓരോ പാർട്ടീഷനിലും 60% ത്തിൽ കൂടുതൽ സ്ഥലമെടുക്കാൻ പാടില്ല. 
• അവ 50% cpu-ൽ കൂടുതലാകാതെ ലോഡ് ചെയ്യണം.
• കപ്പാസിറ്റി ആസൂത്രണത്തെക്കുറിച്ച് നിങ്ങൾ മറക്കരുത്, ഓരോ ഘടകത്തിനും അതിന്റെ പ്രത്യേകതകളെ അടിസ്ഥാനമാക്കി അത് ചിന്തിക്കേണ്ടതുണ്ട്.
• ക്ലസ്റ്ററിലെ കൂടുതൽ നോഡുകൾ, നല്ലത്. ചെറിയ അളവിലുള്ള ഡാറ്റ അടങ്ങിയ സെർവറുകൾ വേഗത്തിൽ ഓവർലോഡ് ചെയ്യപ്പെടുന്നു, അത്തരമൊരു ക്ലസ്റ്റർ പുനരുജ്ജീവിപ്പിക്കാൻ എളുപ്പമാണ്. 

രണ്ടാം സ്ഥാനം - "കൺസൽ കീ-വാല്യൂ സ്റ്റോറേജിൽ നിന്ന് ഡാറ്റ അപ്രത്യക്ഷമായി"

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

നിഗമനങ്ങൾ:

• യാതൊരു അംഗീകാരവുമില്ലാത്ത സേവനങ്ങളിൽ സൈറ്റിന്റെ പ്രവർത്തനത്തിന് നിർണായകമായ ഡാറ്റ അടങ്ങിയിരിക്കരുത്. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ES-ൽ അംഗീകാരം ഇല്ലെങ്കിൽ, നെറ്റ്‌വർക്ക് തലത്തിൽ ആവശ്യമില്ലാത്ത എല്ലായിടത്തുനിന്നും ആക്‌സസ്സ് നിരസിക്കുന്നതാണ് നല്ലത്, ആവശ്യമായവ മാത്രം ഉപേക്ഷിക്കുക, കൂടാതെ action.destructive_requires_name: true.
• നിങ്ങളുടെ ബാക്കപ്പും വീണ്ടെടുക്കൽ സംവിധാനവും മുൻകൂട്ടി പരിശീലിക്കുക. ഉദാഹരണത്തിന്, ബാക്കപ്പ് ചെയ്യാനും പുനഃസ്ഥാപിക്കാനും കഴിയുന്ന ഒരു സ്ക്രിപ്റ്റ് മുൻകൂട്ടി തയ്യാറാക്കുക (ഉദാഹരണത്തിന്, പൈത്തണിൽ).

ഒന്നാം സ്ഥാനം - "ക്യാപ്റ്റൻ അവ്യക്തം" 

ചില ഘട്ടങ്ങളിൽ, ബാക്കെൻഡിൽ 10+ സെർവറുകൾ ഉള്ള സന്ദർഭങ്ങളിൽ nginx അപ്‌സ്ട്രീമുകളിൽ ലോഡ് അസമമായ വിതരണം ഞങ്ങൾ ശ്രദ്ധിച്ചു. റൗണ്ട്-റോബിൻ 1 മുതൽ അവസാനത്തെ അപ്‌സ്ട്രീം വരെ ക്രമത്തിൽ അഭ്യർത്ഥനകൾ അയച്ചതിനാലും ഓരോ nginx റീലോഡ് വീണ്ടും ആരംഭിച്ചതിനാലും, ആദ്യ അപ്‌സ്ട്രീമുകൾക്ക് എല്ലായ്‌പ്പോഴും ബാക്കിയുള്ളതിനേക്കാൾ കൂടുതൽ അഭ്യർത്ഥനകൾ ലഭിച്ചു. തൽഫലമായി, അവ സാവധാനത്തിൽ പ്രവർത്തിക്കുകയും സൈറ്റ് മുഴുവൻ കഷ്ടപ്പെടുകയും ചെയ്തു. തിരക്ക് വർധിച്ചതോടെ ഇത് കൂടുതൽ ശ്രദ്ധിക്കപ്പെട്ടു. റാൻഡം പ്രവർത്തനക്ഷമമാക്കാൻ nginx അപ്‌ഡേറ്റ് ചെയ്യുന്നത് പ്രവർത്തിച്ചില്ല - പതിപ്പ് 1.15-ൽ (ആ നിമിഷം) ടേക്ക് ഓഫ് ചെയ്യാത്ത ഒരു കൂട്ടം lua കോഡ് ഞങ്ങൾ വീണ്ടും ചെയ്യേണ്ടതുണ്ട്. ഞങ്ങളുടെ nginx 1.14.2 പാച്ച് ചെയ്യേണ്ടി വന്നു, അതിൽ ക്രമരഹിതമായ പിന്തുണ അവതരിപ്പിച്ചു. ഇതോടെ പ്രശ്നം പരിഹരിച്ചു. ഈ ബഗ് "ക്യാപ്റ്റൻ നോൺ-വ്യക്തത" വിഭാഗത്തിൽ വിജയിക്കുന്നു.

നിഗമനങ്ങൾ:

ഈ ബഗ് പര്യവേക്ഷണം ചെയ്യുന്നത് വളരെ രസകരവും ആവേശകരവുമായിരുന്നു). 

• അത്തരം ഏറ്റക്കുറച്ചിലുകൾ വേഗത്തിൽ കണ്ടെത്താൻ നിങ്ങളെ സഹായിക്കുന്ന തരത്തിൽ നിങ്ങളുടെ നിരീക്ഷണം സംഘടിപ്പിക്കുക. ഉദാഹരണത്തിന്, ഓരോ അപ്‌സ്ട്രീമിന്റെയും ഓരോ ബാക്കെൻഡിലും ആർ‌പി‌എസ് നിരീക്ഷിക്കാനും അവയുടെ പ്രതികരണ സമയം nginx-ന്റെ വീക്ഷണകോണിൽ നിന്ന് നിരീക്ഷിക്കാനും നിങ്ങൾക്ക് ELK ഉപയോഗിക്കാം. ഈ സാഹചര്യത്തിൽ, പ്രശ്നം തിരിച്ചറിയാൻ ഇത് ഞങ്ങളെ സഹായിച്ചു. 

തൽഫലമായി, നിങ്ങൾ ചെയ്യുന്ന കാര്യങ്ങളിൽ കൂടുതൽ സൂക്ഷ്മമായ സമീപനത്തിലൂടെ മിക്ക പരാജയങ്ങളും ഒഴിവാക്കാമായിരുന്നു. മർഫിയുടെ നിയമം നാം എപ്പോഴും ഓർക്കണം: തെറ്റ് സംഭവിക്കാവുന്ന എന്തും തെറ്റായി പോകും, അതിന്റെ അടിസ്ഥാനത്തിൽ ഘടകങ്ങൾ നിർമ്മിക്കുകയും ചെയ്യുക. 

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