HighLoad++, Evgeniy Kuzovlev (EcommPay IT): ഒരു മിനിറ്റ് പ്രവർത്തനരഹിതമായാൽ $100000 ചെലവാകുമ്പോൾ എന്തുചെയ്യണം

എല്ലാവരും വികസനത്തിന്റെയും പരിശോധനയുടെയും പ്രക്രിയകളെക്കുറിച്ച് സംസാരിക്കുന്നു, സ്റ്റാഫിനെ പരിശീലിപ്പിക്കുക, പ്രചോദനം വർദ്ധിപ്പിക്കുക, എന്നാൽ ഒരു മിനിറ്റ് സേവന പ്രവർത്തനരഹിതമായ സമയത്തിന് വലിയ തുക ചിലവാകുമ്പോൾ ഈ പ്രക്രിയകൾ മതിയാകില്ല. കർശനമായ SLA-യുടെ കീഴിൽ സാമ്പത്തിക ഇടപാടുകൾ നടത്തുമ്പോൾ എന്തുചെയ്യണം? സമവാക്യത്തിൽ നിന്ന് വികസനവും പരിശോധനയും എടുത്ത് നിങ്ങളുടെ സിസ്റ്റങ്ങളുടെ വിശ്വാസ്യതയും തെറ്റ് സഹിഷ്ണുതയും എങ്ങനെ വർദ്ധിപ്പിക്കാം?

അടുത്ത ഹൈലോഡ്++ കോൺഫറൻസ് 6 ഏപ്രിൽ 7, 2020 തീയതികളിൽ സെന്റ് പീറ്റേഴ്‌സ്ബർഗിൽ നടക്കും. വിശദാംശങ്ങളും ടിക്കറ്റുകളും ലിങ്ക്. നവംബർ 9, 18:00. ഹൈലോഡ്++ മോസ്കോ 2018, ഡൽഹി + കൊൽക്കത്ത ഹാൾ. തീസുകളും അവതരണം.

Evgeniy Kuzovlev (ഇനി മുതൽ - EC): - സുഹൃത്തുക്കളേ, ഹലോ! എന്റെ പേര് കുസോവ്ലെവ് എവ്ജെനി. ഞാൻ EcommPay കമ്പനിയിൽ നിന്നാണ്, ഒരു പ്രത്യേക ഡിവിഷൻ EcommPay IT ആണ്, കമ്പനികളുടെ ഗ്രൂപ്പിന്റെ IT ഡിവിഷൻ. ഇന്ന് നമ്മൾ പ്രവർത്തനരഹിതമായ സമയങ്ങളെക്കുറിച്ച് സംസാരിക്കും - അവ എങ്ങനെ ഒഴിവാക്കാം, ഒഴിവാക്കാൻ കഴിയുന്നില്ലെങ്കിൽ അവയുടെ അനന്തരഫലങ്ങൾ എങ്ങനെ കുറയ്ക്കാം എന്നതിനെക്കുറിച്ച്. വിഷയം ഇനിപ്പറയുന്ന രീതിയിൽ പ്രസ്താവിച്ചിരിക്കുന്നു: "ഒരു മിനിറ്റ് പ്രവർത്തനരഹിതമായ സമയത്തിന് $ 100 ചെലവാകുമ്പോൾ എന്തുചെയ്യണം"? മുന്നോട്ട് നോക്കുമ്പോൾ, ഞങ്ങളുടെ സംഖ്യകൾ താരതമ്യപ്പെടുത്താവുന്നതാണ്.

EcommPay ഐടി എന്താണ് ചെയ്യുന്നത്?

നമ്മളാരാണ്? ഞാനെന്തിനാ ഇവിടെ നിന്റെ മുന്നിൽ നിൽക്കുന്നത്? ഇവിടെ നിന്നോട് എന്തെങ്കിലും പറയാൻ എനിക്ക് എന്തിനാണ് അവകാശം? നമ്മൾ ഇവിടെ കൂടുതൽ വിശദമായി എന്താണ് സംസാരിക്കുന്നത്?

EcommPay ഗ്രൂപ്പ് ഓഫ് കമ്പനികൾ ഒരു അന്താരാഷ്ട്ര ഏറ്റെടുക്കലാണ്. ഞങ്ങൾ ലോകമെമ്പാടുമുള്ള പേയ്‌മെന്റുകൾ പ്രോസസ്സ് ചെയ്യുന്നു - റഷ്യ, യൂറോപ്പ്, തെക്കുകിഴക്കൻ ഏഷ്യ (ലോകമെമ്പാടും). ഞങ്ങൾക്ക് 9 ഓഫീസുകളുണ്ട്, ആകെ 500 ജീവനക്കാർ, അവരിൽ പകുതിയിൽ താഴെ മാത്രം ഐടി വിദഗ്ധരാണ്. നമ്മൾ ചെയ്യുന്നതെല്ലാം, പണം സമ്പാദിക്കുന്നതെല്ലാം, ഞങ്ങൾ സ്വയം ചെയ്തു.

ഞങ്ങളുടെ എല്ലാ ഉൽപ്പന്നങ്ങളും ഞങ്ങൾ എഴുതി (അവയിൽ ധാരാളം ഉണ്ട് - ഞങ്ങളുടെ വലിയ ഐടി ഉൽപ്പന്നങ്ങളുടെ നിരയിൽ ഞങ്ങൾക്ക് ഏകദേശം 16 വ്യത്യസ്ത ഘടകങ്ങൾ ഉണ്ട്) ഞങ്ങൾ തന്നെ; ഞങ്ങൾ സ്വയം എഴുതുന്നു, ഞങ്ങൾ സ്വയം വികസിപ്പിക്കുന്നു. ഇപ്പോൾ ഞങ്ങൾ ഒരു ദിവസം ഏകദേശം ഒരു ദശലക്ഷം ഇടപാടുകൾ നടത്തുന്നു (ദശലക്ഷക്കണക്കിന് അത് പറയാനുള്ള ശരിയായ മാർഗമാണ്). ഞങ്ങൾ വളരെ ചെറുപ്പമായ ഒരു കമ്പനിയാണ് - ഞങ്ങൾക്ക് ഏകദേശം ആറ് വയസ്സ് മാത്രമേ ഉള്ളൂ.

6 വർഷങ്ങൾക്ക് മുമ്പ് ഇത്തരമൊരു സ്റ്റാർട്ടപ്പായിരുന്നു, ആളുകൾ ബിസിനസ്സിനൊപ്പം വന്നപ്പോൾ. അവർ ഒരു ആശയത്താൽ ഒന്നിച്ചു (ഒരു ആശയമല്ലാതെ മറ്റൊന്നും ഇല്ല), ഞങ്ങൾ ഓടി. ഏതൊരു സ്റ്റാർട്ടപ്പും പോലെ, ഞങ്ങൾ വേഗത്തിൽ ഓടി ... ഞങ്ങൾക്ക്, ഗുണനിലവാരത്തേക്കാൾ വേഗതയായിരുന്നു പ്രധാനം.

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

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

പ്രവർത്തനരഹിതമായ സമയങ്ങൾ. പ്രവർത്തനത്തിന്റെ കമാൻഡുകൾ.

എല്ലായ്‌പ്പോഴും പ്രധാന മൂലക്കല്ല്, ഇന്ന് നമ്മൾ യഥാർത്ഥത്തിൽ സംസാരിക്കുന്നത് പ്രവർത്തനരഹിതമായ സമയത്തെക്കുറിച്ചാണ്. ഭയങ്കര വാക്ക്. നമുക്ക് പ്രവർത്തനരഹിതമായാൽ, എല്ലാം നമുക്ക് ദോഷകരമാണ്. ഞങ്ങൾ അത് ഉയർത്താൻ ഓടുകയാണ്, അഡ്മിൻമാർ സെർവറിനെ പിടിക്കുന്നു - ആ പാട്ടിൽ അവർ പറയുന്നതുപോലെ ഇത് വീഴാതിരിക്കട്ടെ. ഇതാണ് നമ്മൾ ഇന്ന് സംസാരിക്കുന്നത്.

ഞങ്ങൾ ഞങ്ങളുടെ സമീപനങ്ങളിൽ മാറ്റം വരുത്താൻ തുടങ്ങിയപ്പോൾ, ഞങ്ങൾ 4 കൽപ്പനകൾ രൂപീകരിച്ചു. ഞാൻ അവ സ്ലൈഡുകളിൽ അവതരിപ്പിച്ചിട്ടുണ്ട്:

ഈ കൽപ്പനകൾ വളരെ ലളിതമാണ്:

• പ്രശ്നം പെട്ടെന്ന് തിരിച്ചറിയുക.
• അതിലും വേഗത്തിൽ അതിൽ നിന്ന് മുക്തി നേടൂ.
• കാരണം മനസ്സിലാക്കാൻ സഹായിക്കുക (പിന്നീട്, ഡവലപ്പർമാർക്ക്).
• ഒപ്പം സമീപനങ്ങളെ സ്റ്റാൻഡേർഡ് ചെയ്യുക.

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

ട്രബിൾഷൂട്ടിംഗ്: അവ എപ്പോഴാണ് സംഭവിക്കുന്നത്, അവയെക്കുറിച്ച് എന്തുചെയ്യണം?

എന്നാൽ ഞങ്ങൾ ക്രമരഹിതമായി ആരംഭിക്കും, ഞങ്ങൾ പോയിന്റ് നമ്പർ 2-ൽ ആരംഭിക്കും - പ്രശ്നം എങ്ങനെ വേഗത്തിൽ ഒഴിവാക്കാം? ഒരു പ്രശ്നമുണ്ട് - ഞങ്ങൾ അത് പരിഹരിക്കേണ്ടതുണ്ട്. "ഇതിന് നമ്മൾ എന്താണ് ചെയ്യേണ്ടത്?" - പ്രധാന ചോദ്യം. പ്രശ്‌നം എങ്ങനെ പരിഹരിക്കാമെന്ന് ഞങ്ങൾ ചിന്തിക്കാൻ തുടങ്ങിയപ്പോൾ, ട്രബിൾഷൂട്ടിംഗ് പിന്തുടരേണ്ട ചില ആവശ്യകതകൾ ഞങ്ങൾ സ്വയം വികസിപ്പിച്ചെടുത്തു.

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

• ഹാർഡ്‌വെയർ പരാജയം.
• ബാഹ്യ സേവനങ്ങൾ പരാജയപ്പെട്ടു.
• സോഫ്റ്റ്വെയർ പതിപ്പ് മാറ്റുന്നു (അതേ വിന്യാസം).
• സ്ഫോടനാത്മക ലോഡ് വളർച്ച.

ആദ്യ രണ്ടിനെക്കുറിച്ച് നമ്മൾ സംസാരിക്കില്ല. ഒരു ഹാർഡ്‌വെയർ തകരാർ വളരെ ലളിതമായി പരിഹരിക്കാൻ കഴിയും: നിങ്ങൾക്ക് എല്ലാം തനിപ്പകർപ്പ് ഉണ്ടായിരിക്കണം. ഇവ ഡിസ്കുകളാണെങ്കിൽ, ഡിസ്കുകൾ RAID-ൽ കൂട്ടിച്ചേർക്കണം; ഇതൊരു സെർവറാണെങ്കിൽ, സെർവർ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യണം; നിങ്ങൾക്ക് ഒരു നെറ്റ്‌വർക്ക് ഇൻഫ്രാസ്ട്രക്ചർ ഉണ്ടെങ്കിൽ, നെറ്റ്‌വർക്ക് ഇൻഫ്രാസ്ട്രക്ചറിന്റെ രണ്ടാമത്തെ പകർപ്പ് നിങ്ങൾ നൽകണം, അതായത്, നിങ്ങൾ അത് എടുക്കുകയും അത് ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യുക. എന്തെങ്കിലും പരാജയപ്പെടുകയാണെങ്കിൽ, നിങ്ങൾ കരുതൽ ശക്തിയിലേക്ക് മാറുക. ഇവിടെ കൂടുതലൊന്നും പറയാൻ പ്രയാസമാണ്.

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

അപ്പോൾ എന്താണ് ചെയ്യേണ്ടത്? ഇവിടെ രണ്ട് ഓപ്ഷനുകൾ ഉണ്ട്. ആദ്യം, നിങ്ങൾക്ക് കഴിയുമെങ്കിൽ, ഈ സേവനം ഏതെങ്കിലും വിധത്തിൽ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യണം. ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് കഴിയുമെങ്കിൽ, ഞങ്ങൾ ഒരു സേവനത്തിൽ നിന്ന് മറ്റൊന്നിലേക്ക് ട്രാഫിക് ട്രാൻസ്ഫർ ചെയ്യുന്നു: ഉദാഹരണത്തിന്, കാർഡുകൾ Sberbank വഴി പ്രോസസ്സ് ചെയ്തു, Sberbank-ന് പ്രശ്നങ്ങളുണ്ട് - ഞങ്ങൾ ട്രാഫിക് [സോപാധികമായി] Raiffeisen-ലേക്ക് മാറ്റുന്നു. നമുക്ക് ചെയ്യാൻ കഴിയുന്ന രണ്ടാമത്തെ കാര്യം, ബാഹ്യ സേവനങ്ങളുടെ പരാജയം വളരെ വേഗത്തിൽ ശ്രദ്ധിക്കുന്നതാണ്, അതിനാൽ റിപ്പോർട്ടിന്റെ അടുത്ത ഭാഗത്ത് പ്രതികരണ വേഗതയെക്കുറിച്ച് ഞങ്ങൾ സംസാരിക്കും.

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

ഈ നാല് പ്രശ്‌നങ്ങളിൽ പലതും നിങ്ങൾക്ക് ഒരു ക്ലൗഡ് ഉണ്ടെങ്കിൽ ഉടനടി പരിഹരിക്കപ്പെടും. നിങ്ങൾ Microsoft Azhur, Ozone മേഘങ്ങളിൽ ആണെങ്കിൽ, Yandex അല്ലെങ്കിൽ Mail-ൽ നിന്നുള്ള ഞങ്ങളുടെ ക്ലൗഡുകൾ ഉപയോഗിക്കുകയാണെങ്കിൽ, കുറഞ്ഞത് ഒരു ഹാർഡ്‌വെയർ തകരാറെങ്കിലും അവരുടെ പ്രശ്‌നമായി മാറുകയും ഒരു ഹാർഡ്‌വെയർ തകരാറിന്റെ പശ്ചാത്തലത്തിൽ എല്ലാം ഉടനടി നിങ്ങൾക്ക് ശരിയാകും.

ഞങ്ങൾ അല്പം പാരമ്പര്യേതര കമ്പനിയാണ്. ഇവിടെ എല്ലാവരും സംസാരിക്കുന്നത് “കുബർനെറ്റ്സ്”, മേഘങ്ങളെക്കുറിച്ച് - ഞങ്ങൾക്ക് “കുബർനെറ്റ്” അല്ലെങ്കിൽ മേഘങ്ങൾ ഇല്ല. എന്നാൽ ഞങ്ങൾക്ക് പല ഡാറ്റാ സെന്ററുകളിലും ഹാർഡ്‌വെയറുകളുടെ റാക്കുകൾ ഉണ്ട്, ഈ ഹാർഡ്‌വെയറിൽ ജീവിക്കാൻ ഞങ്ങൾ നിർബന്ധിതരാകുന്നു, അതിനെല്ലാം ഉത്തരവാദികളാകാൻ ഞങ്ങൾ നിർബന്ധിതരാകുന്നു. അതിനാൽ, ഈ സന്ദർഭത്തിൽ നമ്മൾ സംസാരിക്കും. അതിനാൽ, പ്രശ്നങ്ങളെക്കുറിച്ച്. ആദ്യത്തെ രണ്ടെണ്ണം ബ്രാക്കറ്റിൽ നിന്ന് പുറത്തെടുത്തു.

സോഫ്റ്റ്വെയർ പതിപ്പ് മാറ്റുന്നു. അടിസ്ഥാനങ്ങൾ

ഞങ്ങളുടെ ഡെവലപ്പർമാർക്ക് ഉൽപ്പാദനത്തിലേക്ക് പ്രവേശനമില്ല. എന്തുകൊണ്ടാണത്? ഞങ്ങൾ പി‌സി‌ഐ ഡി‌എസ്‌എസ് സർ‌ട്ടിഫൈഡ് ആണെന്നും ഞങ്ങളുടെ ഡെവലപ്പർ‌മാർക്ക് “ഉൽ‌പ്പന്ന”ത്തിലേക്ക് പ്രവേശിക്കാനുള്ള അവകാശം ഇല്ലെന്നും മാത്രം. അത്രയേയുള്ളൂ, കാലഘട്ടം. എല്ലാം. അതിനാൽ, ഡെവലപ്‌മെന്റ് ബിൽഡ് റിലീസിനായി സമർപ്പിക്കുന്ന നിമിഷത്തിൽ തന്നെ വികസന ഉത്തരവാദിത്തം അവസാനിക്കുന്നു.

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

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

സോഫ്റ്റ്വെയർ പതിപ്പ് മാറ്റുന്നതിനുള്ള ആവശ്യകതകൾ

മൂന്ന് ആവശ്യകതകൾ ഉണ്ട്:

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

  
  
  ഇത് വളരെ നന്നായി അറിയാം, ഞങ്ങൾ ഇത് ഒരിക്കലും കണ്ടുപിടിച്ചിട്ടില്ല - ഇതാണ് നീല/പച്ച വിന്യാസം. അത് എന്താണ്? നിങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള ഓരോ സെർവറുകളുടെയും ഒരു പകർപ്പ് നിങ്ങൾക്കുണ്ടായിരിക്കണം. പകർപ്പ് "ഊഷ്മളമാണ്": അതിൽ ട്രാഫിക് ഇല്ല, എന്നാൽ ഏത് നിമിഷവും ഈ ട്രാഫിക്ക് ഈ പകർപ്പിലേക്ക് അയയ്ക്കാം. ഈ പകർപ്പിൽ മുമ്പത്തെ പതിപ്പ് അടങ്ങിയിരിക്കുന്നു. വിന്യാസ സമയത്ത്, നിങ്ങൾ കോഡ് ഒരു നിഷ്‌ക്രിയ പകർപ്പിലേക്ക് റോൾ ചെയ്യുക. തുടർന്ന് നിങ്ങൾ ട്രാഫിക്കിന്റെ ഒരു ഭാഗം (അല്ലെങ്കിൽ എല്ലാം) പുതിയ പതിപ്പിലേക്ക് മാറ്റുക. അതിനാൽ, പഴയ പതിപ്പിൽ നിന്ന് പുതിയതിലേക്ക് ട്രാഫിക് ഫ്ലോ മാറ്റുന്നതിന്, നിങ്ങൾ ഒരു പ്രവർത്തനം മാത്രം ചെയ്യേണ്ടതുണ്ട്: നിങ്ങൾ അപ്‌സ്ട്രീമിലെ ബാലൻസർ മാറ്റേണ്ടതുണ്ട്, ദിശ മാറ്റുക - ഒന്നിൽ നിന്ന് മറ്റൊന്നിലേക്ക്. ഇത് വളരെ സൗകര്യപ്രദമാണ്, ദ്രുത സ്വിച്ചിംഗിന്റെയും പെട്ടെന്നുള്ള റോൾബാക്കിന്റെയും പ്രശ്നം പരിഹരിക്കുന്നു.

  ഇവിടെ രണ്ടാമത്തെ ചോദ്യത്തിനുള്ള പരിഹാരം ചെറുതാക്കലാണ്: നിങ്ങളുടെ ട്രാഫിക്കിന്റെ ഒരു ഭാഗം മാത്രമേ നിങ്ങൾക്ക് ഒരു പുതിയ ലൈനിലേക്ക്, ഒരു പുതിയ കോഡുള്ള ഒരു ലൈനിലേക്ക് അയയ്ക്കാൻ കഴിയൂ (ഉദാഹരണത്തിന്, 2% ആയിരിക്കട്ടെ). ഈ 2% 100% അല്ല! വിന്യാസം പരാജയപ്പെട്ടതിനാൽ നിങ്ങളുടെ ട്രാഫിക്കിന്റെ 100% നഷ്‌ടപ്പെട്ടാൽ, അത് ഭയാനകമാണ്; നിങ്ങളുടെ ട്രാഫിക്കിന്റെ 2% നഷ്‌ടപ്പെട്ടാൽ, അത് അസുഖകരമാണ്, പക്ഷേ അത് ഭയാനകമല്ല. മാത്രമല്ല, ഉപയോക്താക്കൾ ഇത് മിക്കവാറും ശ്രദ്ധിക്കില്ല, കാരണം ചില സന്ദർഭങ്ങളിൽ (എല്ലാത്തിലും അല്ല) ഒരേ ഉപയോക്താവ്, F5 അമർത്തുന്നത്, മറ്റൊരു, പ്രവർത്തിക്കുന്ന പതിപ്പിലേക്ക് കൊണ്ടുപോകും.

  നീല/പച്ച വിന്യാസം. റൂട്ടിംഗ്

  എന്നിരുന്നാലും, എല്ലാം വളരെ ലളിതമല്ല "നീല / പച്ച വിന്യാസം"... ഞങ്ങളുടെ എല്ലാ ഘടകങ്ങളും മൂന്ന് ഗ്രൂപ്പുകളായി തിരിക്കാം:

  • ഇതാണ് മുൻഭാഗം (ഞങ്ങളുടെ ക്ലയന്റുകൾ കാണുന്ന പേയ്‌മെന്റ് പേജുകൾ);
  • പ്രോസസ്സിംഗ് കോർ;
  • പേയ്മെന്റ് സംവിധാനങ്ങളുമായി പ്രവർത്തിക്കുന്നതിനുള്ള അഡാപ്റ്റർ (ബാങ്കുകൾ, മാസ്റ്റർകാർഡ്, വിസ ...).

  ഇവിടെ ഒരു സൂക്ഷ്മതയുണ്ട് - വരികൾക്കിടയിലുള്ള റൂട്ടിംഗിലാണ് സൂക്ഷ്മത സ്ഥിതിചെയ്യുന്നത്. നിങ്ങൾ ട്രാഫിക്കിന്റെ 100% മാറുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഈ പ്രശ്‌നങ്ങളൊന്നുമില്ല. എന്നാൽ നിങ്ങൾക്ക് 2% മാറണമെങ്കിൽ, നിങ്ങൾ ചോദ്യങ്ങൾ ചോദിക്കാൻ തുടങ്ങുന്നു: "ഇത് എങ്ങനെ ചെയ്യാം?" ഏറ്റവും ലളിതമായ കാര്യം നേരെയാണ്: ക്രമരഹിതമായ ചോയിസിലൂടെ നിങ്ങൾക്ക് nginx-ൽ റൗണ്ട് റോബിൻ സജ്ജീകരിക്കാം, നിങ്ങൾക്ക് 2% ഇടത്തോട്ടും 98% വലത്തോട്ടും ഉണ്ട്. എന്നാൽ ഇത് എല്ലായ്പ്പോഴും അനുയോജ്യമല്ല.

  ഉദാഹരണത്തിന്, ഞങ്ങളുടെ കാര്യത്തിൽ, ഒരു ഉപയോക്താവ് ഒന്നിലധികം അഭ്യർത്ഥനകളുമായി സിസ്റ്റവുമായി സംവദിക്കുന്നു. ഇത് സാധാരണമാണ്: 2, 3, 4, 5 അഭ്യർത്ഥനകൾ - നിങ്ങളുടെ സിസ്റ്റങ്ങളും സമാനമായിരിക്കാം. കൂടാതെ, ഉപയോക്താവിന്റെ എല്ലാ അഭ്യർത്ഥനകളും ആദ്യ അഭ്യർത്ഥന വന്ന അതേ വരിയിലേക്ക് വരുന്നത് നിങ്ങൾക്ക് പ്രധാനമാണെങ്കിൽ, അല്ലെങ്കിൽ (രണ്ടാം പോയിന്റ്) സ്വിച്ചിന് ശേഷം ഉപയോക്താവിന്റെ എല്ലാ അഭ്യർത്ഥനകളും പുതിയ ലൈനിലേക്ക് വരുന്നു (അവന് നേരത്തെ പ്രവർത്തിക്കാൻ തുടങ്ങാമായിരുന്നു സിസ്റ്റം, സ്വിച്ചിന് മുമ്പ്), - അപ്പോൾ ഈ ക്രമരഹിതമായ വിതരണം നിങ്ങൾക്ക് അനുയോജ്യമല്ല. തുടർന്ന് ഇനിപ്പറയുന്ന ഓപ്ഷനുകൾ ഉണ്ട്:

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

  ചില കാരണങ്ങളാൽ ഇത് നിങ്ങൾക്ക് അനുയോജ്യമല്ലെങ്കിൽ ഉപയോക്താവിന്റെ പ്രാരംഭ, പ്രാരംഭ അഭ്യർത്ഥന വന്ന വരിയിലേക്ക് നിങ്ങൾ അഭ്യർത്ഥനകൾ അയയ്‌ക്കേണ്ടതുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് രണ്ട് ഓപ്ഷനുകളുണ്ട്...
  ആദ്യ ഓപ്ഷൻ: നിങ്ങൾക്ക് പണമടച്ചുള്ള nginx+ വാങ്ങാം. ഒരു സ്റ്റിക്കി സെഷൻസ് മെക്കാനിസം ഉണ്ട്, അത് ഉപയോക്താവിന്റെ പ്രാരംഭ അഭ്യർത്ഥന പ്രകാരം ഉപയോക്താവിന് ഒരു സെഷൻ നൽകുകയും ഒന്നോ അല്ലെങ്കിൽ മറ്റൊരു അപ്‌സ്ട്രീമിലേക്ക് ബന്ധിപ്പിക്കുകയും ചെയ്യുന്നു. സെഷൻ ലൈഫ് ടൈമിനുള്ളിൽ തുടർന്നുള്ള എല്ലാ ഉപയോക്തൃ അഭ്യർത്ഥനകളും സെഷൻ പോസ്റ്റ് ചെയ്ത അതേ അപ്‌സ്ട്രീമിലേക്ക് അയയ്ക്കും.

  ഞങ്ങൾക്ക് ഇതിനകം സാധാരണ nginx ഉള്ളതിനാൽ ഇത് ഞങ്ങൾക്ക് അനുയോജ്യമല്ല. nginx+ ലേക്ക് മാറുന്നത് അത് ചെലവേറിയതാണെന്നല്ല, ഇത് ഞങ്ങൾക്ക് ഒരു പരിധിവരെ വേദനാജനകവും വളരെ ശരിയായതുമായിരുന്നില്ല എന്നതാണ്. ഉദാഹരണത്തിന്, "സ്റ്റിക്ക് സെഷനുകൾ", "ഒന്നുകിൽ-അല്ലെങ്കിൽ" അടിസ്ഥാനമാക്കിയുള്ള റൂട്ടിംഗ് അനുവദിക്കാത്ത ലളിതമായ കാരണത്താൽ ഞങ്ങൾക്കായി പ്രവർത്തിച്ചില്ല. IP വിലാസം അല്ലെങ്കിൽ IP വിലാസം, കുക്കികൾ അല്ലെങ്കിൽ പോസ്റ്റ്പാരാമീറ്റർ വഴി ഞങ്ങൾ "സ്റ്റിക്ക് സെഷനുകൾ" എന്താണ് ചെയ്യുന്നതെന്ന് അവിടെ നിങ്ങൾക്ക് വ്യക്തമാക്കാൻ കഴിയും, എന്നാൽ "ഒന്നുകിൽ-അല്ലെങ്കിൽ" അവിടെ കൂടുതൽ സങ്കീർണ്ണമാണ്.

  അതിനാൽ, ഞങ്ങൾ നാലാമത്തെ ഓപ്ഷനിലേക്ക് എത്തി. ഞങ്ങൾ സ്റ്റിറോയിഡുകളിൽ nginx എടുത്തു (ഇത് ഓപ്പൺ റെസ്റ്റിയാണ്) - ഇത് അതേ nginx ആണ്, ഇത് അവസാന സ്ക്രിപ്റ്റുകൾ ഉൾപ്പെടുത്തുന്നതിനെ പിന്തുണയ്ക്കുന്നു. നിങ്ങൾക്ക് അവസാന സ്ക്രിപ്റ്റ് എഴുതാം, അതിന് "ഓപ്പൺ റെസ്റ്റ്" നൽകുക, ഉപയോക്തൃ അഭ്യർത്ഥന വരുമ്പോൾ ഈ അവസാന സ്ക്രിപ്റ്റ് എക്സിക്യൂട്ട് ചെയ്യപ്പെടും.

  വാസ്തവത്തിൽ, അത്തരമൊരു സ്ക്രിപ്റ്റ് ഞങ്ങൾ എഴുതി, "ഓപ്പൺറെസ്റ്റി" എന്ന് സ്വയം സജ്ജമാക്കി, ഈ സ്ക്രിപ്റ്റിൽ ഞങ്ങൾ 6 വ്യത്യസ്ത പാരാമീറ്ററുകളിലൂടെ "അല്ലെങ്കിൽ" എന്നതിലൂടെ അടുക്കുന്നു. ഒന്നോ അല്ലെങ്കിൽ മറ്റൊരു പരാമീറ്ററിന്റെ സാന്നിധ്യത്തെ ആശ്രയിച്ച്, ഉപയോക്താവ് ഒരു പേജ് അല്ലെങ്കിൽ മറ്റൊന്ന്, ഒരു വരി അല്ലെങ്കിൽ മറ്റൊന്നിലേക്ക് വന്നതായി ഞങ്ങൾക്കറിയാം.

  നീല/പച്ച വിന്യാസം. ഗുണങ്ങളും ദോഷങ്ങളും

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

  
  
  അതിനാൽ, ഇത് ഞങ്ങൾക്ക് വേണ്ടി പ്രവർത്തിച്ചില്ല - ഞങ്ങൾ തുറന്ന വിശ്രമം നടത്തി. അതനുസരിച്ച്, റൂട്ടിംഗ് ഉപയോഗിച്ച് ഞങ്ങൾക്ക് ഇതുപോലൊന്ന് ലഭിച്ചു:

  നീല/പച്ച വിന്യാസത്തിന്, അതനുസരിച്ച്, ഞാൻ സൂചിപ്പിച്ച ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്.

  രണ്ട് ദോഷങ്ങൾ:

  • റൂട്ടിംഗിൽ നിങ്ങൾ ബുദ്ധിമുട്ടിക്കേണ്ടതുണ്ട്;
  • രണ്ടാമത്തെ പ്രധാന പോരായ്മ ചെലവാണ്.

  നിങ്ങൾക്ക് ഇരട്ടി സെർവറുകൾ ആവശ്യമാണ്, നിങ്ങൾക്ക് ഇരട്ടി പ്രവർത്തന ഉറവിടങ്ങൾ ആവശ്യമാണ്, ഈ മൃഗശാല മുഴുവൻ പരിപാലിക്കാൻ നിങ്ങൾ ഇരട്ടി പരിശ്രമം ചെലവഴിക്കേണ്ടതുണ്ട്.

  വഴിയിൽ, നേട്ടങ്ങളിൽ ഞാൻ മുമ്പ് പരാമർശിച്ചിട്ടില്ലാത്ത ഒരു കാര്യം കൂടിയുണ്ട്: ലോഡ് വളർച്ചയുടെ കാര്യത്തിൽ നിങ്ങൾക്ക് ഒരു കരുതൽ ഉണ്ട്. നിങ്ങൾക്ക് ലോഡിൽ സ്ഫോടനാത്മകമായ വളർച്ചയുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ധാരാളം ഉപയോക്താക്കളുണ്ട്, തുടർന്ന് 50 മുതൽ 50 വരെയുള്ള വിതരണത്തിൽ നിങ്ങൾ രണ്ടാമത്തെ വരി ഉൾപ്പെടുത്തിയാൽ മതി - കൂടുതൽ സെർവറുകൾ ഉള്ള പ്രശ്നം പരിഹരിക്കുന്നതുവരെ നിങ്ങളുടെ ക്ലസ്റ്ററിൽ ഉടനടി x2 സെർവറുകൾ ഉണ്ടാകും.

  പെട്ടെന്നുള്ള വിന്യാസം എങ്ങനെ നടത്താം?

  ചെറുതാക്കലിന്റെയും പെട്ടെന്നുള്ള റോൾബാക്കിന്റെയും പ്രശ്നം എങ്ങനെ പരിഹരിക്കാമെന്ന് ഞങ്ങൾ സംസാരിച്ചു, പക്ഷേ ചോദ്യം അവശേഷിക്കുന്നു: "എങ്ങനെ വേഗത്തിൽ വിന്യസിക്കാം?"

  
  
  ഇത് ഇവിടെ ചെറുതും ലളിതവുമാണ്.

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

    ഒരു പുരാവസ്തു എന്താണ്? എല്ലാ അസംബ്ലി ഭാഗങ്ങളും ഇതിനകം പൂർത്തിയാക്കിയ ഒരു അസംബിൾഡ് ബിൽഡാണ് ആർട്ടിഫാക്റ്റ്. ഈ പുരാവസ്തു ഞങ്ങൾ ആർട്ടിഫാക്റ്റ് സ്റ്റോറേജിൽ സൂക്ഷിക്കുന്നു. ഒരു കാലത്ത് ഞങ്ങൾ അത്തരത്തിലുള്ള രണ്ട് സ്റ്റോറേജുകൾ ഉപയോഗിച്ചിരുന്നു - അത് Nexus ആണ്, ഇപ്പോൾ jFrog ആർട്ടിഫാക്‌ടറി).ജാവ ആപ്ലിക്കേഷനുകളിൽ ഈ സമീപനം ഞങ്ങൾ പരിശീലിക്കാൻ തുടങ്ങിയതിനാൽ ഞങ്ങൾ തുടക്കത്തിൽ "Nexus" ആണ് ഉപയോഗിച്ചത് (അത് നന്നായി യോജിക്കുന്നു). എന്നിട്ട് പി.എച്ച്.പിയിൽ എഴുതിയ ചില ആപ്ലിക്കേഷനുകൾ അവിടെ ഇട്ടു; കൂടാതെ "Nexus" ഇനി അനുയോജ്യമല്ല, അതിനാൽ ഞങ്ങൾ jFrog Artefactory തിരഞ്ഞെടുത്തു, അത് മിക്കവാറും എല്ലാം കൃത്രിമമാക്കാൻ കഴിയും. സെർവറുകൾക്കായി ഞങ്ങൾ ശേഖരിക്കുന്ന ഞങ്ങളുടെ സ്വന്തം ബൈനറി പാക്കേജുകൾ ഈ ആർട്ടിഫാക്റ്റ് റിപ്പോസിറ്ററിയിൽ ഞങ്ങൾ സംഭരിക്കുന്നു എന്ന ഘട്ടത്തിലേക്ക് ഞങ്ങൾ എത്തിയിരിക്കുന്നു.

  സ്ഫോടനാത്മക ലോഡ് വളർച്ച

  സോഫ്റ്റ്വെയർ പതിപ്പ് മാറ്റുന്നതിനെക്കുറിച്ച് ഞങ്ങൾ സംസാരിച്ചു. നമുക്ക് അടുത്തത് ലോഡിലെ സ്ഫോടനാത്മകമായ വർദ്ധനവാണ്. ഇവിടെ, ഭാരത്തിന്റെ സ്ഫോടനാത്മകമായ വളർച്ച എന്നതുകൊണ്ട് ഞാൻ ഉദ്ദേശിച്ചത് ശരിയായ കാര്യമല്ല...

  ഞങ്ങൾ ഒരു പുതിയ സംവിധാനം എഴുതി - അത് സേവന-അധിഷ്ഠിതമാണ്, ഫാഷനാണ്, മനോഹരമാണ്, എല്ലായിടത്തും തൊഴിലാളികൾ, എല്ലായിടത്തും ക്യൂകൾ, എല്ലായിടത്തും അസമന്വിതമാണ്. അത്തരം സിസ്റ്റങ്ങളിൽ, ഡാറ്റയ്ക്ക് വ്യത്യസ്ത ഫ്ലോകളിലൂടെ ഒഴുകാൻ കഴിയും. ആദ്യ ഇടപാടിന്, 1, 3, 10 തൊഴിലാളികളെ ഉപയോഗിക്കാം, രണ്ടാമത്തെ ഇടപാടിന് - 2, 4, 5. ഇന്ന്, നമുക്ക് പറയാം, രാവിലെ നിങ്ങൾക്ക് ആദ്യത്തെ മൂന്ന് തൊഴിലാളികളെ ഉപയോഗിക്കുന്ന ഒരു ഡാറ്റാ ഫ്ലോ ഉണ്ട്, വൈകുന്നേരം അത് നാടകീയമായി മാറുന്നു, എല്ലാം മറ്റ് മൂന്ന് തൊഴിലാളികളെ ഉപയോഗിക്കുന്നു.

  ഇവിടെ നിങ്ങൾ എങ്ങനെയെങ്കിലും തൊഴിലാളികളെ സ്കെയിൽ ചെയ്യേണ്ടതുണ്ട്, നിങ്ങളുടെ സേവനങ്ങൾ എങ്ങനെയെങ്കിലും സ്കെയിൽ ചെയ്യേണ്ടതുണ്ട്, എന്നാൽ അതേ സമയം റിസോഴ്സ് ബ്ലാറ്റ് തടയുക.

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

  എന്തുകൊണ്ടാണ് ഇത് ഞങ്ങൾക്ക് ഒരു പ്രശ്നം? നമുക്ക് അല്പം പിന്നോട്ട് പോകാം. ഇപ്പോൾ ഞങ്ങൾക്ക് പിന്നിൽ 70 പേയ്‌മെന്റ് സംവിധാനങ്ങളുണ്ട്. രാവിലെ, ട്രാഫിക് Sberbank വഴി കടന്നുപോകുന്നു, തുടർന്ന് Sberbank വീണു, ഉദാഹരണത്തിന്, ഞങ്ങൾ അത് മറ്റൊരു പേയ്മെന്റ് സിസ്റ്റത്തിലേക്ക് മാറുന്നു. Sberbank-ന് മുമ്പ് ഞങ്ങൾക്ക് 100 തൊഴിലാളികൾ ഉണ്ടായിരുന്നു, അതിനുശേഷം മറ്റൊരു പേയ്മെന്റ് സംവിധാനത്തിനായി 100 തൊഴിലാളികളെ കുത്തനെ വർദ്ധിപ്പിക്കേണ്ടതുണ്ട്. മനുഷ്യ പങ്കാളിത്തമില്ലാതെ ഇതെല്ലാം സംഭവിക്കുന്നത് അഭികാമ്യമാണ്. കാരണം മനുഷ്യപങ്കാളിത്തമുണ്ടെങ്കിൽ, 24/7 അവിടെ ഇരിക്കുന്ന ഒരു എഞ്ചിനീയർ ഉണ്ടായിരിക്കണം, ആരാണ് ഇത് ചെയ്യേണ്ടത്, കാരണം 70 സംവിധാനങ്ങൾ നിങ്ങളുടെ പിന്നിലായിരിക്കുമ്പോൾ അത്തരം പരാജയങ്ങൾ പതിവായി സംഭവിക്കുന്നു.

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

  ഇതുവരെ ഞങ്ങൾ ഇത് ഓപ്പൺ സോഴ്‌സ് ചെയ്‌തിട്ടില്ല, പക്ഷേ റിപ്പോർട്ടിന് ശേഷം, നിങ്ങൾക്ക് അത്തരമൊരു കാര്യം ആവശ്യമാണെന്ന് തിരിച്ചറിഞ്ഞ ശേഷം, നിങ്ങൾക്കത് ആവശ്യമാണ്, എന്റെ കോൺടാക്റ്റുകൾ അവസാന സ്ലൈഡിലാണ് - ദയവായി എനിക്ക് എഴുതുക. കുറഞ്ഞത് 3-5 പേരെങ്കിലും ഉണ്ടെങ്കിൽ, ഞങ്ങൾ അത് സ്പോൺസർ ചെയ്യും.

  
  
  ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു? നമുക്ക് ഒന്ന് നോക്കാം! മുന്നോട്ട് നോക്കുന്നു: ഇടതുവശത്ത് ഞങ്ങളുടെ നിരീക്ഷണത്തിന്റെ ഒരു ഭാഗമുണ്ട്: ഇത് ഒരു വരിയാണ്, മുകളിൽ ഇവന്റ് പ്രോസസ്സിംഗ് സമയമാണ്, മധ്യത്തിൽ ഇടപാടുകളുടെ എണ്ണം, താഴെ തൊഴിലാളികളുടെ എണ്ണം.

  നിങ്ങൾ നോക്കിയാൽ, ഈ ചിത്രത്തിൽ ഒരു കുഴപ്പമുണ്ട്. ടോപ്പ് ചാർട്ടിൽ, ചാർട്ടുകളിലൊന്ന് 45 സെക്കൻഡിനുള്ളിൽ തകർന്നു - പേയ്‌മെന്റ് സിസ്റ്റങ്ങളിലൊന്ന് കുറഞ്ഞു. ഉടൻ തന്നെ, 2 മിനിറ്റിനുള്ളിൽ ട്രാഫിക് കൊണ്ടുവന്നു, തൊഴിലാളികളില്ലാത്ത മറ്റൊരു പേയ്‌മെന്റ് സിസ്റ്റത്തിൽ ക്യൂ വളരാൻ തുടങ്ങി (ഞങ്ങൾ വിഭവങ്ങൾ ഉപയോഗിച്ചില്ല - നേരെമറിച്ച്, ഞങ്ങൾ റിസോഴ്‌സ് ശരിയായി വിനിയോഗിച്ചു). ഞങ്ങൾക്ക് ചൂടാക്കാൻ താൽപ്പര്യമില്ല - കുറഞ്ഞത് 5-10 തൊഴിലാളികൾ ഉണ്ടായിരുന്നു, പക്ഷേ അവർക്ക് നേരിടാൻ കഴിഞ്ഞില്ല.

  അവസാന ഗ്രാഫ് ഒരു "ഹംപ്" കാണിക്കുന്നു, അതിനർത്ഥം "സ്കലെനോ" ഈ തുക ഇരട്ടിയാക്കി എന്നാണ്. പിന്നെ, ഗ്രാഫ് അൽപ്പം കുറഞ്ഞപ്പോൾ, അവൻ അത് കുറച്ച് കുറച്ചു - തൊഴിലാളികളുടെ എണ്ണം യാന്ത്രികമായി മാറി. അങ്ങനെയാണ് ഈ കാര്യം പ്രവർത്തിക്കുന്നത്. ഞങ്ങൾ പോയിന്റ് നമ്പർ 2 നെക്കുറിച്ച് സംസാരിച്ചു - “കാരണങ്ങളിൽ നിന്ന് എങ്ങനെ വേഗത്തിൽ രക്ഷപ്പെടാം.”

  നിരീക്ഷണം. പ്രശ്നം എങ്ങനെ വേഗത്തിൽ തിരിച്ചറിയാം?

  ഇപ്പോൾ ആദ്യത്തെ പോയിന്റ് "പ്രശ്നം എങ്ങനെ വേഗത്തിൽ തിരിച്ചറിയാം?" നിരീക്ഷണം! ചില കാര്യങ്ങൾ നമ്മൾ പെട്ടെന്ന് മനസ്സിലാക്കണം. എന്ത് കാര്യങ്ങൾ നമ്മൾ പെട്ടെന്ന് മനസ്സിലാക്കണം?

  
  
  മൂന്ന് കാര്യങ്ങൾ!

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

  ഞാൻ ഒരുപക്ഷേ ഇവിടെ രസകരമായ ഒന്നും നിങ്ങളോട് പറയില്ല. ഞാൻ ക്യാപ്റ്റൻ വ്യക്തമാകും. ഞങ്ങൾ മാർക്കറ്റിൽ എന്താണെന്ന് അന്വേഷിച്ചു. ഞങ്ങൾക്ക് ഒരു "രസകരമായ മൃഗശാല" ഉണ്ട്. ഞങ്ങൾക്ക് ഇപ്പോൾ ഉള്ളത് ഇത്തരത്തിലുള്ള മൃഗശാലയാണ്:

  
  
  ഹാർഡ്‌വെയർ നിരീക്ഷിക്കുന്നതിനും സെർവറുകളുടെ പ്രധാന സൂചകങ്ങൾ നിരീക്ഷിക്കുന്നതിനും ഞങ്ങൾ Zabbix ഉപയോഗിക്കുന്നു. ഡാറ്റാബേസുകൾക്കായി ഞങ്ങൾ Okmeter ഉപയോഗിക്കുന്നു. ആദ്യ രണ്ട് സൂചകങ്ങൾക്ക് അനുയോജ്യമല്ലാത്ത മറ്റെല്ലാ സൂചകങ്ങൾക്കും ഞങ്ങൾ "ഗ്രാഫാന", "പ്രോമിത്യൂസ്" എന്നിവ ഉപയോഗിക്കുന്നു, ചിലത് "ഗ്രാഫാന", "പ്രോമിത്യൂസ്", ചിലത് "ഗ്രാഫാന" എന്നിവയിൽ "ഇൻഫ്ലക്സ്", ടെലിഗ്രാഫ്.

  ഒരു വർഷം മുമ്പ് ഞങ്ങൾ പുതിയ അവശിഷ്ടം ഉപയോഗിക്കാൻ ആഗ്രഹിച്ചു. രസകരമായ കാര്യം, അതിന് എല്ലാം ചെയ്യാൻ കഴിയും. എന്നാൽ അവൾക്ക് എല്ലാം ചെയ്യാൻ കഴിയുന്നിടത്തോളം, അവൾ വളരെ ചെലവേറിയതാണ്. ഞങ്ങൾ 1,5 ആയിരം സെർവറുകളുടെ വോളിയത്തിലേക്ക് വളർന്നപ്പോൾ, ഒരു വെണ്ടർ ഞങ്ങളുടെ അടുത്ത് വന്ന് പറഞ്ഞു: "നമുക്ക് അടുത്ത വർഷത്തേക്കുള്ള ഒരു കരാർ അവസാനിപ്പിക്കാം." ഞങ്ങൾ വില നോക്കി പറഞ്ഞു, ഞങ്ങൾ അത് ചെയ്യില്ല. ഇപ്പോൾ ഞങ്ങൾ പുതിയ അവശിഷ്ടം ഉപേക്ഷിക്കുകയാണ്, ഞങ്ങൾക്ക് ഏകദേശം 15 സെർവറുകൾ ന്യൂ റെലിക്കിന്റെ നിരീക്ഷണത്തിൽ അവശേഷിക്കുന്നു. വില തികച്ചും വന്യമായി മാറി.

  ഞങ്ങൾ സ്വയം നടപ്പിലാക്കിയ ഒരു ഉപകരണമുണ്ട് - ഇതാണ് ഡീബഗ്ഗർ. ആദ്യം ഞങ്ങൾ അതിനെ "ബാഗർ" എന്ന് വിളിച്ചിരുന്നു, എന്നാൽ ഒരു ഇംഗ്ലീഷ് അദ്ധ്യാപകൻ അതുവഴി കടന്നുപോയി, വന്യമായി ചിരിച്ചു, അതിനെ "ഡീബാഗർ" എന്ന് പുനർനാമകരണം ചെയ്തു. അത് എന്താണ്? സിസ്റ്റത്തിന്റെ "ബ്ലാക്ക് ബോക്സ്" പോലെ ഓരോ ഘടകത്തിലും 15-30 സെക്കൻഡുകൾക്കുള്ളിൽ, ഘടകത്തിന്റെ മൊത്തത്തിലുള്ള പ്രകടനത്തെക്കുറിച്ചുള്ള പരിശോധനകൾ നടത്തുന്ന ഒരു ഉപകരണമാണിത്.

  ഉദാഹരണത്തിന്, ഒരു ബാഹ്യ പേജ് (പേയ്മെന്റ് പേജ്) ഉണ്ടെങ്കിൽ, അവൻ അത് തുറന്ന് അത് എങ്ങനെ കാണണമെന്ന് നോക്കുന്നു. ഇത് പ്രോസസ്സ് ചെയ്യുകയാണെങ്കിൽ, അവൻ ഒരു ടെസ്റ്റ് "ഇടപാട്" അയയ്ക്കുകയും ഈ "ഇടപാട്" എത്തുന്നുവെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുന്നു. ഇത് പേയ്‌മെന്റ് സംവിധാനങ്ങളുമായുള്ള ബന്ധമാണെങ്കിൽ, അതിനനുസരിച്ച് ഞങ്ങൾ ഒരു ടെസ്റ്റ് അഭ്യർത്ഥന നടത്തുന്നു, ഞങ്ങൾക്ക് കഴിയുന്നിടത്ത് ഞങ്ങൾ എല്ലാം ശരിയാണെന്ന് കാണുക.

  നിരീക്ഷണത്തിന് എന്ത് സൂചകങ്ങളാണ് പ്രധാനം?

  നമ്മൾ പ്രധാനമായും നിരീക്ഷിക്കുന്നത് എന്താണ്? ഏത് സൂചകങ്ങളാണ് ഞങ്ങൾക്ക് പ്രധാനം?

  
  

  • ഫ്രണ്ടുകളിലെ പ്രതികരണ സമയം / RPS വളരെ പ്രധാനപ്പെട്ട ഒരു സൂചകമാണ്. നിങ്ങൾക്ക് എന്തോ കുഴപ്പമുണ്ടെന്ന് അദ്ദേഹം ഉടൻ ഉത്തരം നൽകുന്നു.
  • എല്ലാ ക്യൂവുകളിലും പ്രോസസ്സ് ചെയ്ത സന്ദേശങ്ങളുടെ എണ്ണം.
  • തൊഴിലാളികളുടെ എണ്ണം.
  • അടിസ്ഥാന കൃത്യത അളവുകൾ.

  അവസാന പോയിന്റ് "ബിസിനസ്", "ബിസിനസ്" മെട്രിക് ആണ്. നിങ്ങൾക്ക് ഒരേ കാര്യം നിരീക്ഷിക്കണമെങ്കിൽ, നിങ്ങൾക്കുള്ള പ്രധാന സൂചകങ്ങളായ ഒന്നോ രണ്ടോ മെട്രിക്‌സ് നിങ്ങൾ നിർവചിക്കേണ്ടതുണ്ട്. ഞങ്ങളുടെ മെട്രിക് ത്രോപുട്ട് ആണ് (ഇത് വിജയകരമായ ഇടപാടുകളുടെ എണ്ണത്തിന്റെ മൊത്തം ഇടപാട് പ്രവാഹത്തിന്റെ അനുപാതമാണ്). 5-10-15 മിനിറ്റ് ഇടവേളയിൽ അതിൽ എന്തെങ്കിലും മാറുകയാണെങ്കിൽ, അതിനർത്ഥം ഞങ്ങൾക്ക് പ്രശ്നങ്ങളുണ്ട് (അത് സമൂലമായി മാറുകയാണെങ്കിൽ).

  ഞങ്ങൾക്ക് ഇത് എങ്ങനെ കാണപ്പെടുന്നു എന്നത് ഞങ്ങളുടെ ബോർഡുകളിലൊന്നിന്റെ ഉദാഹരണമാണ്:

  
  
  ഇടതുവശത്ത് 6 ഗ്രാഫുകൾ ഉണ്ട്, ഇത് വരികൾക്കനുസൃതമാണ് - തൊഴിലാളികളുടെ എണ്ണവും ക്യൂകളിലെ സന്ദേശങ്ങളുടെ എണ്ണവും. വലതുവശത്ത് - RPS, RTS. താഴെ അതേ "ബിസിനസ്" മെട്രിക് ആണ്. "ബിസിനസ്" മെട്രിക്കിൽ, രണ്ട് മധ്യ ഗ്രാഫുകളിൽ എന്തോ കുഴപ്പം സംഭവിച്ചതായി നമുക്ക് പെട്ടെന്ന് കാണാൻ കഴിയും ... ഇത് നമ്മുടെ പിന്നിൽ വീണുപോയ മറ്റൊരു സംവിധാനം മാത്രമാണ്.

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

  
  
  പേയ്‌മെന്റ് സിസ്റ്റങ്ങളിലൊന്ന് 3 സെക്കൻഡിനുള്ളിൽ പ്രതികരിക്കാൻ തുടങ്ങിയെന്ന് ഗ്രാഫ് കാണിക്കുന്നു - ഞങ്ങൾക്ക് പ്രശ്‌നങ്ങളുണ്ട്. മാത്രമല്ല, പ്രശ്നങ്ങൾ ആരംഭിക്കുമ്പോൾ, 20-30 സെക്കൻഡ് ഇടവേളയിൽ ഈ കാര്യം പ്രതികരിക്കും.

  നിലവിലുള്ള മോണിറ്ററിംഗ് പിശകുകളുടെ മൂന്നാമത്തെ ക്ലാസ് ലോജിക്കൽ മോണിറ്ററിംഗ് ആണ്.

  സത്യം പറഞ്ഞാൽ, ഈ സ്ലൈഡിൽ എന്താണ് വരയ്ക്കേണ്ടതെന്ന് എനിക്കറിയില്ല, കാരണം ഞങ്ങൾക്ക് അനുയോജ്യമായ എന്തെങ്കിലും വിപണിയിൽ ഞങ്ങൾ വളരെക്കാലമായി തിരയുകയായിരുന്നു. ഞങ്ങൾ ഒന്നും കണ്ടെത്തിയില്ല, അതിനാൽ ഞങ്ങൾ അത് സ്വയം ചെയ്യേണ്ടിവന്നു.

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

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

  പ്രശ്നം എങ്ങനെ വേഗത്തിൽ തിരിച്ചറിയാം എന്നതിനെക്കുറിച്ചായിരുന്നു ഇത്.

  വിന്യാസത്തിനുള്ള കാരണങ്ങൾ എങ്ങനെ നിർണ്ണയിക്കും

  ഞങ്ങൾ പരിഹരിക്കുന്ന മൂന്നാമത്തെ ഗ്രൂപ്പ് പ്രശ്‌നങ്ങൾ തിരിച്ചറിഞ്ഞതിന് ശേഷം, അതിൽ നിന്ന് മുക്തി നേടിയതിന് ശേഷം, വികസനത്തിന്റെ കാരണം മനസിലാക്കുകയും പരിശോധന നടത്തുകയും അതിനെക്കുറിച്ച് എന്തെങ്കിലും ചെയ്യുന്നത് നന്നായിരിക്കും. അതനുസരിച്ച്, ഞങ്ങൾ അന്വേഷിക്കേണ്ടതുണ്ട്, ലോഗുകൾ ഉയർത്തേണ്ടതുണ്ട്.

  
  
  നമ്മൾ ലോഗുകളെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ (പ്രധാന കാരണം ലോഗുകളാണ്), ഞങ്ങളുടെ ലോഗുകളുടെ ഭൂരിഭാഗവും ELK സ്റ്റാക്കിലാണ് - മിക്കവാറും എല്ലാവർക്കും സമാനമാണ്. ചിലർക്ക്, ഇത് ELK-ൽ ആയിരിക്കില്ല, പക്ഷേ നിങ്ങൾ ജിഗാബൈറ്റിൽ ലോഗുകൾ എഴുതിയാൽ, താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് നിങ്ങൾ ELK- ൽ വരും. ഞങ്ങൾ അവ ടെറാബൈറ്റിൽ എഴുതുന്നു.

  
  
  ഇവിടെ ഒരു പ്രശ്നമുണ്ട്. ഞങ്ങൾ അത് പരിഹരിച്ചു, ഉപയോക്താവിനുള്ള പിശക് ശരിയാക്കി, അവിടെയുള്ളത് കുഴിക്കാൻ തുടങ്ങി, കിബാനയിൽ കയറി, അവിടെയുള്ള ഇടപാട് ഐഡിയിൽ പ്രവേശിച്ച് ഇതുപോലെ ഒരു കാൽവയ്പ്പ് ലഭിച്ചു (ഒരുപാട് കാണിക്കുന്നു). ഈ കാൽവസ്ത്രത്തിൽ ഒന്നും വ്യക്തമല്ല. എന്തുകൊണ്ട്? അതെ, കാരണം ഏത് തൊഴിലാളിയുടേതാണ്, ഏത് ഭാഗം ഏത് ഘടകത്തിന്റേതാണെന്ന് വ്യക്തമല്ല. ആ നിമിഷം ഞങ്ങൾക്ക് ട്രേസിംഗ് ആവശ്യമാണെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി - ഞാൻ സംസാരിച്ച അതേ ഓപ്പൺ ട്രേസിംഗ്.

  ഒരു വർഷം മുമ്പ് ഞങ്ങൾ ഇത് ചിന്തിച്ചു, വിപണിയിലേക്ക് ശ്രദ്ധ തിരിച്ചു, അവിടെ രണ്ട് ഉപകരണങ്ങൾ ഉണ്ടായിരുന്നു - “സിപ്കിൻ”, “ജെയ്ഗർ”. "ജാഗർ" വാസ്തവത്തിൽ അത്തരമൊരു പ്രത്യയശാസ്ത്രപരമായ അവകാശിയാണ്, "സിപ്കിൻ" ന്റെ പ്രത്യയശാസ്ത്ര പിൻഗാമിയാണ്. Zipkin-ൽ എല്ലാം നല്ലതാണ്, അത് എങ്ങനെ കൂട്ടിച്ചേർക്കണമെന്ന് അറിയില്ല, ട്രെയ്‌സിൽ ലോഗുകൾ എങ്ങനെ ഉൾപ്പെടുത്തണമെന്ന് അതിന് അറിയില്ല, ടൈം ട്രെയ്സ് മാത്രം. "ജാഗർ" ഇതിനെ പിന്തുണച്ചു.

  ഞങ്ങൾ “ജാഗർ” നോക്കി: നിങ്ങൾക്ക് ഇൻസ്ട്രുമെന്റ് ആപ്ലിക്കേഷനുകൾ ചെയ്യാം, നിങ്ങൾക്ക് എപിയിൽ എഴുതാം (അക്കാലത്ത് പി‌എച്ച്‌പിയുടെ എപിഐ സ്റ്റാൻഡേർഡ് അംഗീകരിച്ചില്ല - ഇത് ഒരു വർഷം മുമ്പായിരുന്നു, പക്ഷേ ഇപ്പോൾ ഇത് ഇതിനകം അംഗീകരിച്ചു), പക്ഷേ അവിടെ തികച്ചും ക്ലയന്റ് ആയിരുന്നില്ല. “ശരി,” ഞങ്ങൾ ചിന്തിച്ചു, ഞങ്ങളുടെ സ്വന്തം ക്ലയന്റ് എഴുതി. നമുക്ക് എന്താണ് ലഭിച്ചത്? ഇത് ഏകദേശം ഇങ്ങനെയാണ്:

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

  
  
  സ്പാനിനുള്ളിൽ ഒരു കൂട്ടം അടയാളങ്ങളുണ്ട്. ഈ സാഹചര്യത്തിൽ, ഇവ മൂന്ന് ടെസ്റ്റ് ട്രെയ്സുകളാണ്, മൂന്നാമത്തെ ട്രെയ്സ് ഒരു പിശക് സംഭവിച്ചതായി പറയുന്നു. അതേ സമയം, ഇവിടെ നമ്മൾ ഒരു ടൈം ട്രെയ്സ് കാണുന്നു: നമുക്ക് മുകളിൽ ഒരു സമയ സ്കെയിൽ ഉണ്ട്, ഈ അല്ലെങ്കിൽ ആ ലോഗ് ഏത് സമയ ഇടവേളയിലാണ് രേഖപ്പെടുത്തിയതെന്ന് ഞങ്ങൾ കാണുന്നു.

  അതനുസരിച്ച്, ഞങ്ങൾക്ക് കാര്യങ്ങൾ നന്നായി പോയി. ഞങ്ങൾ സ്വന്തം വിപുലീകരണം എഴുതി, ഞങ്ങൾ അത് ഓപ്പൺ സോഴ്‌സ് ചെയ്തു. നിങ്ങൾക്ക് ട്രെയ്‌സിംഗ് ഉപയോഗിച്ച് പ്രവർത്തിക്കണമെങ്കിൽ, പി‌എച്ച്‌പിയിൽ “ജാഗർ” ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞങ്ങളുടെ വിപുലീകരണം ഉണ്ട്, അവർ പറയുന്നത് പോലെ ഉപയോഗിക്കാൻ സ്വാഗതം:

  
  
  ഞങ്ങൾക്ക് ഈ വിപുലീകരണം ഉണ്ട് - ഇത് OpenTracing Api-യുടെ ഒരു ക്ലയന്റാണ്, ഇത് php-extention ആയി നിർമ്മിച്ചതാണ്, അതായത്, നിങ്ങൾ ഇത് അസംബിൾ ചെയ്ത് സിസ്റ്റത്തിൽ ഇൻസ്റ്റാൾ ചെയ്യേണ്ടതുണ്ട്. ഒരു വർഷം മുമ്പ് വ്യത്യസ്തമായി ഒന്നുമില്ല. ഇപ്പോൾ ഘടകങ്ങൾ പോലെയുള്ള മറ്റ് ക്ലയന്റുകൾ ഉണ്ട്. ഇവിടെ ഇത് നിങ്ങളുടേതാണ്: ഒന്നുകിൽ നിങ്ങൾ ഒരു കമ്പോസർ ഉപയോഗിച്ച് ഘടകങ്ങൾ പമ്പ് ചെയ്യുക, അല്ലെങ്കിൽ നിങ്ങൾക്കായി വിപുലീകരണം ഉപയോഗിക്കുക.

  കോർപ്പറേറ്റ് മാനദണ്ഡങ്ങൾ

  ഞങ്ങൾ മൂന്ന് കല്പനകളെ കുറിച്ച് സംസാരിച്ചു. നാലാമത്തെ കൽപ്പന സമീപനങ്ങളെ മാനദണ്ഡമാക്കുക എന്നതാണ്. ഇത് എന്തിനെക്കുറിച്ചാണ്? ഇത് ഇതിനെക്കുറിച്ച്:

  
  
  എന്തുകൊണ്ടാണ് "കോർപ്പറേറ്റ്" എന്ന വാക്ക് ഇവിടെ വന്നത്? ഞങ്ങൾ ഒരു വലിയ അല്ലെങ്കിൽ ബ്യൂറോക്രാറ്റിക് കമ്പനിയായതുകൊണ്ടല്ല, ഇല്ല! നിങ്ങളുൾപ്പെടെ എല്ലാ കമ്പനികൾക്കും എല്ലാ ഉൽപ്പന്നങ്ങൾക്കും അതിന്റേതായ മാനദണ്ഡങ്ങൾ ഉണ്ടായിരിക്കണം എന്ന പശ്ചാത്തലത്തിലാണ് ഇവിടെ "കോർപ്പറേറ്റ്" എന്ന വാക്ക് ഉപയോഗിക്കാൻ ഞാൻ ആഗ്രഹിച്ചത്. നമുക്ക് എന്ത് മാനദണ്ഡങ്ങളുണ്ട്?

  
  

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

  എന്താണ് പ്രവർത്തനരഹിതമായി കണക്കാക്കുന്നത്?

  
  
  ഇതെല്ലാം എന്തിലേക്ക് നയിച്ചു?

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

  ഞങ്ങൾ രാത്രി ഉറങ്ങാൻ പഠിച്ചു. ഒടുവിൽ! ആറുമാസം മുമ്പ് ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല. ഫലങ്ങളുള്ള ഈ കുറിപ്പിൽ, ഞാൻ ഒരു കുറിപ്പ് ഇടാൻ ആഗ്രഹിക്കുന്നു. ആണവ റിയാക്ടറിന്റെ നിയന്ത്രണ സംവിധാനത്തെക്കുറിച്ച് ഇന്നലെ രാത്രി ഒരു അത്ഭുതകരമായ റിപ്പോർട്ട് ഉണ്ടായിരുന്നു. ഈ സിസ്റ്റം എഴുതിയ ആളുകൾക്ക് ഞാൻ പറയുന്നത് കേൾക്കാൻ കഴിയുമെങ്കിൽ, "2% പ്രവർത്തനരഹിതമായ സമയമല്ല" എന്ന് ഞാൻ പറഞ്ഞത് ദയവായി മറക്കരുത്. നിങ്ങൾക്കായി, 2% പ്രവർത്തനരഹിതമാണ്, രണ്ട് മിനിറ്റെങ്കിലും!

  അത്രയേയുള്ളൂ! നിങ്ങളുടെ ചോദ്യങ്ങൾ.

  
  

  ബാലൻസറുകളെക്കുറിച്ചും ഡാറ്റാബേസ് മൈഗ്രേഷനെക്കുറിച്ചും

  പ്രേക്ഷകരിൽ നിന്നുള്ള ചോദ്യം (ഇനി മുതൽ - ബി): - ശുഭ സായാഹ്നം. അത്തരമൊരു അഡ്മിൻ റിപ്പോർട്ടിന് വളരെ നന്ദി! നിങ്ങളുടെ ബാലൻസറുകളെക്കുറിച്ചുള്ള ഒരു ചെറിയ ചോദ്യം. നിങ്ങൾക്ക് ഒരു WAF ഉണ്ടെന്ന് നിങ്ങൾ സൂചിപ്പിച്ചു, അതായത്, ഞാൻ മനസ്സിലാക്കിയതുപോലെ, നിങ്ങൾ ഏതെങ്കിലും തരത്തിലുള്ള ബാഹ്യ ബാലൻസറാണ് ഉപയോഗിക്കുന്നത്...

  EK: – ഇല്ല, ഞങ്ങൾ ഞങ്ങളുടെ സേവനങ്ങൾ ഒരു ബാലൻസറായി ഉപയോഗിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, WAF ഞങ്ങൾക്ക് മാത്രമായി ഒരു DDoS സംരക്ഷണ ഉപകരണമാണ്.

  വി: - ബാലൻസറിനെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ പറയാമോ?

  EK: - ഞാൻ ഇതിനകം പറഞ്ഞതുപോലെ, ഇത് ഓപ്പൺ റെസ്റ്റിയിലുള്ള ഒരു കൂട്ടം സെർവറുകളാണ്. ഞങ്ങൾക്ക് ഇപ്പോൾ പ്രത്യേകമായി പ്രതികരിക്കുന്ന 5 റിസർവ് ഗ്രൂപ്പുകളുണ്ട്... അതായത്, ഓപ്പൺ റെസ്റ്റിയിൽ മാത്രം പ്രവർത്തിക്കുന്ന ഒരു സെർവർ, അത് ട്രാഫിക്കിനെ മാത്രം പ്രോക്സി ചെയ്യുന്നു. അതനുസരിച്ച്, ഞങ്ങൾ എത്രത്തോളം കൈവശം വയ്ക്കുന്നുവെന്ന് മനസിലാക്കാൻ: ഞങ്ങൾക്ക് ഇപ്പോൾ നൂറുകണക്കിന് മെഗാബൈറ്റുകളുടെ ഒരു സാധാരണ ട്രാഫിക് ഫ്ലോ ഉണ്ട്. അവർ നേരിടുന്നു, അവർക്ക് സുഖം തോന്നുന്നു, അവർ സ്വയം ബുദ്ധിമുട്ടുന്നില്ല.

  വി: - കൂടാതെ ഒരു ലളിതമായ ചോദ്യം. നീല/പച്ച വിന്യാസം ഇതാ. ഉദാഹരണത്തിന്, ഡാറ്റാബേസ് മൈഗ്രേഷനിൽ നിങ്ങൾ എന്താണ് ചെയ്യുന്നത്?

  EK: - നല്ല ചോദ്യം! നോക്കൂ, നീല/പച്ച വിന്യാസത്തിൽ ഞങ്ങൾക്ക് ഓരോ ലൈനിനും പ്രത്യേക ക്യൂകളുണ്ട്. അതായത്, തൊഴിലാളിയിൽ നിന്ന് തൊഴിലാളിയിലേക്ക് കൈമാറുന്ന ഇവന്റ് ക്യൂകളെക്കുറിച്ചാണ് നമ്മൾ സംസാരിക്കുന്നതെങ്കിൽ, നീല വരയ്ക്കും പച്ച ലൈനിനും പ്രത്യേക ക്യൂകളുണ്ട്. ഞങ്ങൾ ഡാറ്റാബേസിനെക്കുറിച്ചാണ് സംസാരിക്കുന്നതെങ്കിൽ, ഞങ്ങൾ അത് മനഃപൂർവം പരമാവധി ചുരുക്കി, എല്ലാം പ്രായോഗികമായി ക്യൂകളിലേക്ക് മാറ്റി; ഡാറ്റാബേസിൽ ഞങ്ങൾ ഇടപാടുകളുടെ ഒരു കൂട്ടം മാത്രമേ സംഭരിക്കുന്നുള്ളൂ. ഞങ്ങളുടെ ഇടപാട് സ്റ്റാക്ക് എല്ലാ ലൈനുകൾക്കും തുല്യമാണ്. ഈ സന്ദർഭത്തിൽ ഡാറ്റാബേസ് ഉപയോഗിച്ച്: ഞങ്ങൾ അതിനെ നീലയും പച്ചയും ആയി വിഭജിക്കില്ല, കാരണം കോഡിന്റെ രണ്ട് പതിപ്പുകളും ഇടപാടിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് അറിഞ്ഞിരിക്കണം.

  സുഹൃത്തുക്കളേ, നിങ്ങളെ പ്രോത്സാഹിപ്പിക്കാൻ എനിക്കും ഒരു ചെറിയ സമ്മാനമുണ്ട് - ഒരു പുസ്തകം. മികച്ച ചോദ്യത്തിന് എനിക്ക് അത് നൽകണം.

  വി: - ഹലോ. റിപ്പോർട്ടിന് നന്ദി. ചോദ്യം ഇതാണ്. നിങ്ങൾ പേയ്‌മെന്റുകൾ നിരീക്ഷിക്കുന്നു, നിങ്ങൾ ആശയവിനിമയം നടത്തുന്ന സേവനങ്ങൾ നിങ്ങൾ നിരീക്ഷിക്കുന്നു... എന്നാൽ ഒരു വ്യക്തി എങ്ങനെയെങ്കിലും നിങ്ങളുടെ പേയ്‌മെന്റ് പേജിലേക്ക് വരികയും പണമടയ്ക്കുകയും പ്രോജക്റ്റ് അവനു പണം ക്രെഡിറ്റ് ചെയ്യുകയും ചെയ്യുന്നത് എങ്ങനെ നിരീക്ഷിക്കും? അതായത്, മാർച്ചന്റ് ലഭ്യമാണെന്നും നിങ്ങളുടെ കോൾബാക്ക് സ്വീകരിച്ചിട്ടുണ്ടെന്നും നിങ്ങൾ എങ്ങനെ നിരീക്ഷിക്കും?

  EK: - ഈ സാഹചര്യത്തിൽ ഞങ്ങൾക്ക് "വ്യാപാരി" എന്നത് പേയ്‌മെന്റ് സിസ്റ്റത്തിന്റെ അതേ ബാഹ്യ സേവനമാണ്. വ്യാപാരിയുടെ പ്രതികരണ വേഗത ഞങ്ങൾ നിരീക്ഷിക്കുന്നു.

  ഡാറ്റാബേസ് എൻക്രിപ്ഷനെ കുറിച്ച്

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

  
  
  EK: - അത്ഭുതകരമായ ചോദ്യം! ഒന്നാമതായി, ഞങ്ങൾ ക്യൂവിൽ പാൻ സംഭരിക്കുന്നില്ല. വ്യക്തമായ രൂപത്തിൽ എവിടെയും പാൻ സംഭരിക്കാൻ ഞങ്ങൾക്ക് അവകാശമില്ല, തത്വത്തിൽ, അതിനാൽ ഞങ്ങൾ ഒരു പ്രത്യേക സേവനം ഉപയോഗിക്കുന്നു (ഞങ്ങൾ ഇതിനെ “കടമോൻ” എന്ന് വിളിക്കുന്നു) - ഇത് ഒരു കാര്യം മാത്രം ചെയ്യുന്ന ഒരു സേവനമാണ്: ഇത് ഇൻപുട്ടായി ഒരു സന്ദേശം സ്വീകരിക്കുകയും അയയ്ക്കുകയും ചെയ്യുന്നു ഒരു എൻക്രിപ്റ്റ് ചെയ്ത സന്ദേശം പുറത്ത്. ഈ എൻക്രിപ്റ്റ് ചെയ്ത സന്ദേശം ഉപയോഗിച്ച് ഞങ്ങൾ എല്ലാം സംഭരിക്കുന്നു. അതനുസരിച്ച്, ഞങ്ങളുടെ കീ ദൈർഘ്യം ഒരു കിലോബൈറ്റിന് താഴെയാണ്, അതിനാൽ ഇത് ഗൗരവമുള്ളതും വിശ്വസനീയവുമാണ്.

  വി: – നിങ്ങൾക്ക് ഇപ്പോൾ 2 കിലോബൈറ്റ് ആവശ്യമുണ്ടോ?

  EK: – ഇന്നലെ അത് 256 ആണെന്ന് തോന്നുന്നു... ശരി, വേറെ എവിടെ?!

  അതനുസരിച്ച്, ഇത് ആദ്യത്തേതാണ്. രണ്ടാമതായി, നിലവിലുള്ള പരിഹാരം, ഇത് റീ-എൻക്രിപ്ഷൻ നടപടിക്രമത്തെ പിന്തുണയ്ക്കുന്നു - എൻക്രിപ്റ്റ് ചെയ്യുന്ന "ഡെക്കുകൾ" നൽകുന്ന രണ്ട് ജോഡി "കെക്കുകൾ" (കീകൾ) ഉണ്ട് (കീകളാണ് കീകൾ, ഡെക്ക് എൻക്രിപ്റ്റ് ചെയ്യുന്ന കീകളുടെ ഡെറിവേറ്റീവുകളാണ്) . നടപടിക്രമം ആരംഭിച്ചാൽ (ഇത് പതിവായി സംഭവിക്കുന്നത്, 3 മാസം മുതൽ ± ചിലത് വരെ), ഞങ്ങൾ ഒരു പുതിയ ജോഡി "കേക്കുകൾ" ഡൗൺലോഡ് ചെയ്യുകയും ഡാറ്റ വീണ്ടും എൻക്രിപ്റ്റ് ചെയ്യുകയും ചെയ്യുന്നു. എല്ലാ ഡാറ്റയും കീറിമുറിച്ച് പുതിയ രീതിയിൽ എൻക്രിപ്റ്റ് ചെയ്യുന്ന പ്രത്യേക സേവനങ്ങൾ ഞങ്ങൾക്കുണ്ട്; എൻക്രിപ്റ്റ് ചെയ്ത കീയുടെ ഐഡന്റിഫയറിന് അടുത്താണ് ഡാറ്റ സംഭരിച്ചിരിക്കുന്നത്. അതനുസരിച്ച്, പുതിയ കീകൾ ഉപയോഗിച്ച് ഡാറ്റ എൻക്രിപ്റ്റ് ചെയ്തയുടൻ, ഞങ്ങൾ പഴയ കീ ഇല്ലാതാക്കുന്നു.

  ചിലപ്പോൾ പേയ്‌മെന്റുകൾ സ്വമേധയാ നൽകേണ്ടതുണ്ട്...

  വി: - അതായത്, എന്തെങ്കിലും പ്രവർത്തനത്തിന് റീഫണ്ട് വന്നിട്ടുണ്ടെങ്കിൽ, പഴയ കീ ഉപയോഗിച്ച് നിങ്ങൾ അത് ഡീക്രിപ്റ്റ് ചെയ്യുമോ?

  EK: - അതെ.

  വി: - പിന്നെ ഒരു ചെറിയ ചോദ്യം കൂടി. ഏതെങ്കിലും തരത്തിലുള്ള പരാജയമോ വീഴ്ചയോ സംഭവമോ സംഭവിക്കുമ്പോൾ, ഇടപാട് സ്വമേധയാ മുന്നോട്ട് കൊണ്ടുപോകേണ്ടത് ആവശ്യമാണ്. അങ്ങനെയൊരു സാഹചര്യമുണ്ട്.

  EK: - അതെ, ചിലപ്പോൾ.

  വി: - നിങ്ങൾക്ക് ഈ ഡാറ്റ എവിടെ നിന്ന് ലഭിക്കും? അതോ നിങ്ങൾ തന്നെ ഈ സ്റ്റോറേജ് സൗകര്യത്തിലേക്ക് പോകുമോ?

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

  
  
  വി: - എനിക്ക് രണ്ട് ചോദ്യങ്ങളുണ്ട്. അവയിലൊന്ന് പിസിഐ ഡിഎസ്എസ് സോണിന്റെ തുടർച്ചയാണ്: നിങ്ങൾ എങ്ങനെയാണ് അവരുടെ സർക്യൂട്ട് ലോഗ് ചെയ്യുന്നത്? ഡവലപ്പർക്ക് ലോഗുകളിൽ എന്തും ഇടാമായിരുന്നു എന്നതിനാലാണ് ഈ ചോദ്യം! രണ്ടാമത്തെ ചോദ്യം: നിങ്ങൾ എങ്ങനെയാണ് ഹോട്ട്ഫിക്സുകൾ പുറത്തിറക്കുന്നത്? ഡാറ്റാബേസിൽ ഹാൻഡിലുകൾ ഉപയോഗിക്കുന്നത് ഒരു ഓപ്ഷനാണ്, പക്ഷേ സൗജന്യ ഹോട്ട്-ഫിക്സുകൾ ഉണ്ടാകാം - അവിടെ എന്താണ് നടപടിക്രമം? മൂന്നാമത്തെ ചോദ്യം RTO, RPO എന്നിവയുമായി ബന്ധപ്പെട്ടതാകാം. നിങ്ങളുടെ ലഭ്യത 99,97 ആയിരുന്നു, ഏകദേശം നാല് ഒമ്പത് ആയിരുന്നു, എന്നാൽ ഞാൻ മനസ്സിലാക്കിയതുപോലെ, നിങ്ങൾക്ക് രണ്ടാമത്തെ ഡാറ്റാ സെന്റർ, മൂന്നാമത്തെ ഡാറ്റാ സെന്റർ, അഞ്ചാമത്തെ ഡാറ്റാ സെന്റർ എന്നിവയുണ്ട്... നിങ്ങൾ എങ്ങനെയാണ് അവയെ സമന്വയിപ്പിക്കുക, അവ ആവർത്തിക്കുക, കൂടാതെ മറ്റെല്ലാം?

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

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

  വി: - നിങ്ങൾക്ക് രണ്ടാമത്തേത് ലഭിച്ചെങ്കിൽ, എന്തുകൊണ്ടാണ് നിങ്ങൾക്ക് മൂന്നാമത്തേത് ലഭിക്കാത്തത്? കാരണം ഇതുവരെ ആർക്കും തലച്ചോറ് പിളർന്നിട്ടില്ല...

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

  വി: - ഗുഡ് ഈവനിംഗ്. റിപ്പോർട്ടിന് നന്ദി. നിർമ്മാണത്തിൽ ചില പരീക്ഷണ ഇടപാടുകൾ നടത്തുന്ന നിങ്ങളുടെ ഡീബഗ്ഗറിനെ കുറിച്ച് നിങ്ങൾ സംസാരിച്ചു. എന്നാൽ ടെസ്റ്റ് ഇടപാടുകളെക്കുറിച്ച് ഞങ്ങളോട് പറയൂ! അത് എത്ര ആഴത്തിൽ പോകുന്നു?

  EK: - ഇത് മുഴുവൻ ഘടകത്തിന്റെയും മുഴുവൻ ചക്രത്തിലൂടെ കടന്നുപോകുന്നു. ഒരു ഘടകത്തിന്, ഒരു ടെസ്റ്റ് ഇടപാടും ഉൽപ്പാദന ഇടപാടും തമ്മിൽ വ്യത്യാസമില്ല. എന്നാൽ ഒരു ലോജിക്കൽ വീക്ഷണകോണിൽ, ഇത് സിസ്റ്റത്തിലെ ഒരു പ്രത്യേക പ്രോജക്റ്റാണ്, അതിൽ ടെസ്റ്റ് ഇടപാടുകൾ മാത്രം പ്രവർത്തിക്കുന്നു.

  വി: - നിങ്ങൾ എവിടെയാണ് അത് മുറിക്കുന്നത്? ഇവിടെ കോർ അയച്ചു...

  EK: – ടെസ്റ്റ് ഇടപാടുകൾക്കായി ഞങ്ങൾ ഈ കേസിൽ “Kor” ന് പിന്നിലാണ്... ഞങ്ങൾക്ക് റൂട്ടിംഗ് പോലുള്ള ഒരു സംഗതിയുണ്ട്: ഏത് പേയ്‌മെന്റ് സിസ്റ്റത്തിലേക്കാണ് അയയ്‌ക്കേണ്ടതെന്ന് “Kor” ന് അറിയാം - ഞങ്ങൾ ഒരു വ്യാജ പേയ്‌മെന്റ് സിസ്റ്റത്തിലേക്ക് അയയ്‌ക്കുന്നു, അത് ഒരു http സിഗ്നൽ നൽകുന്നു. അത്രയേയുള്ളൂ.

  വി: - ദയവായി എന്നോട് പറയൂ, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഒരു വലിയ മോണോലിത്തിൽ എഴുതിയതാണോ, അതോ നിങ്ങൾ അത് ചില സേവനങ്ങളിലേക്കോ മൈക്രോ സർവീസുകളിലേക്കോ മുറിച്ചോ?

  EK: - ഞങ്ങൾക്ക് ഒരു മോണോലിത്ത് ഇല്ല, തീർച്ചയായും, ഞങ്ങൾക്ക് ഒരു സേവന-അധിഷ്ഠിത ആപ്ലിക്കേഷനുണ്ട്. ഞങ്ങളുടെ സേവനം മോണോലിത്തുകളാൽ നിർമ്മിച്ചതാണെന്ന് ഞങ്ങൾ തമാശ പറയുന്നു - അവ ശരിക്കും വളരെ വലുതാണ്. ഇതിനെ മൈക്രോസർവീസ് എന്ന് വിളിക്കുന്നത് ബുദ്ധിമുട്ടാണ്, എന്നാൽ ഇവ വിതരണം ചെയ്ത മെഷീനുകളുടെ തൊഴിലാളികൾ പ്രവർത്തിക്കുന്ന സേവനങ്ങളാണ്.

  സെർവറിലെ സേവനം തകരാറിലായാൽ...

  വി: - അപ്പോൾ എനിക്ക് അടുത്ത ചോദ്യമുണ്ട്. ഇത് ഒരു മോണോലിത്ത് ആണെങ്കിലും, നിങ്ങൾക്ക് ഈ തൽക്ഷണ സെർവറുകൾ ഉണ്ടെന്ന് നിങ്ങൾ ഇപ്പോഴും പറഞ്ഞു, അവയെല്ലാം അടിസ്ഥാനപരമായി ഡാറ്റ പ്രോസസ്സ് ചെയ്യുന്നു, കൂടാതെ ചോദ്യം ഇതാണ്: “തൽക്ഷണ സെർവറുകളിൽ ഒന്നോ ആപ്ലിക്കേഷനോ വിട്ടുവീഴ്ച ചെയ്താൽ, ഏതെങ്കിലും വ്യക്തിഗത ലിങ്ക് , അവർക്ക് എന്തെങ്കിലും തരത്തിലുള്ള ആക്‌സസ് കൺട്രോൾ ഉണ്ടോ? അവരിൽ ആർക്കാണ് എന്ത് ചെയ്യാൻ കഴിയുക? എന്ത് വിവരങ്ങൾക്ക് ഞാൻ ആരെയാണ് ബന്ധപ്പെടേണ്ടത്?

  
  
  EK: - അതെ തീർച്ചയായും. സുരക്ഷാ ആവശ്യകതകൾ വളരെ ഗുരുതരമാണ്. ഒന്നാമതായി, ഞങ്ങൾക്ക് ഓപ്പൺ ഡാറ്റാ ചലനങ്ങളുണ്ട്, പോർട്ടുകൾ വഴി ട്രാഫിക് ചലനം മുൻകൂട്ടി പ്രതീക്ഷിക്കുന്നവ മാത്രമാണ്. 5-4-3-2 വഴി ഒരു ഘടകം ഡാറ്റാബേസുമായി ആശയവിനിമയം നടത്തുകയാണെങ്കിൽ (പറയുക, മസ്‌കുലിനൊപ്പം), 5-4-3-2 മാത്രമേ അതിന് തുറന്നിരിക്കൂ, മറ്റ് പോർട്ടുകളും മറ്റ് ട്രാഫിക് ദിശകളും ലഭ്യമല്ല. കൂടാതെ, ഞങ്ങളുടെ നിർമ്മാണത്തിൽ ഏകദേശം 10 വ്യത്യസ്ത സുരക്ഷാ ലൂപ്പുകൾ ഉണ്ടെന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. ആപ്ലിക്കേഷൻ എങ്ങനെയെങ്കിലും വിട്ടുവീഴ്ച ചെയ്യപ്പെടുകയാണെങ്കിൽ പോലും, ദൈവം വിലക്കട്ടെ, ആക്രമണകാരിക്ക് സെർവർ മാനേജുമെന്റ് കൺസോൾ ആക്സസ് ചെയ്യാൻ കഴിയില്ല, കാരണം ഇത് മറ്റൊരു നെറ്റ്‌വർക്ക് സുരക്ഷാ മേഖലയാണ്.

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

  EK: - ഞാൻ മനസ്സിലാക്കുന്നു. ഒരു സാധാരണ സാഹചര്യത്തിൽ മറ്റൊരു സെർവർ ആശയവിനിമയം അനുവദിച്ചിട്ടുണ്ടെങ്കിൽ, അതെ. SLA കരാർ അനുസരിച്ച്, നിങ്ങൾക്ക് ആദ്യത്തെ 3 "പ്രവർത്തനങ്ങൾ" മാത്രമേ അനുവദിച്ചിട്ടുള്ളൂ എന്ന് ഞങ്ങൾ നിരീക്ഷിക്കുന്നില്ല, കൂടാതെ 4 "പ്രവർത്തനങ്ങൾ" നിങ്ങൾക്ക് അനുവദനീയമല്ല. ഇത് ഞങ്ങൾക്ക് അനാവശ്യമാണ്, കാരണം ഞങ്ങൾക്ക് ഇതിനകം തന്നെ 4-ലെവൽ പ്രൊട്ടക്ഷൻ സിസ്റ്റം ഉണ്ട്, തത്വത്തിൽ, സർക്യൂട്ടുകൾക്കായി. ഇൻസൈഡുകളുടെ തലത്തിലല്ല, ബാഹ്യരേഖകൾ ഉപയോഗിച്ച് സ്വയം പ്രതിരോധിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

  വിസ, മാസ്റ്റർകാർഡ്, സ്ബെർബാങ്ക് എന്നിവ എങ്ങനെ പ്രവർത്തിക്കുന്നു

  വി: - ഒരു ഉപയോക്താവിനെ ഒരു ഡാറ്റാ സെന്ററിൽ നിന്ന് മറ്റൊന്നിലേക്ക് മാറ്റുന്നതിനെ കുറിച്ച് ഒരു കാര്യം വ്യക്തമാക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. എനിക്കറിയാവുന്നിടത്തോളം, വിസയും മാസ്റ്റർകാർഡും 8583 ബൈനറി സിൻക്രണസ് പ്രോട്ടോക്കോൾ ഉപയോഗിച്ചാണ് പ്രവർത്തിക്കുന്നത്, അവിടെ മിക്സുകളും ഉണ്ട്. എനിക്ക് അറിയാൻ ആഗ്രഹമുണ്ടായിരുന്നു, ഇപ്പോൾ നമ്മൾ സ്വിച്ചിംഗ് എന്നാണ് അർത്ഥമാക്കുന്നത് - ഇത് നേരിട്ട് "വിസ", "മാസ്റ്റർകാർഡ്" എന്നിവയാണോ അതോ പേയ്‌മെന്റ് സിസ്റ്റങ്ങൾക്ക് മുമ്പാണോ, പ്രോസസ്സ് ചെയ്യുന്നതിന് മുമ്പ്?

  EK: - ഇത് മിശ്രിതങ്ങൾക്ക് മുമ്പാണ്. ഞങ്ങളുടെ മിക്സുകൾ ഒരേ ഡാറ്റാ സെന്ററിലാണ് സ്ഥിതി ചെയ്യുന്നത്.

  വി: - ഏകദേശം പറഞ്ഞാൽ, നിങ്ങൾക്ക് ഒരു കണക്ഷൻ പോയിന്റ് ഉണ്ടോ?

  EK: - "വിസ", "മാസ്റ്റർകാർഡ്" - അതെ. ഉദാഹരണത്തിന്, വിസയ്ക്കും മാസ്റ്റർകാർഡിനും മറ്റൊരു ജോഡി മിശ്രിതങ്ങൾ ലഭിക്കുന്നതിന് പ്രത്യേക കരാറുകൾ അവസാനിപ്പിക്കുന്നതിന് അടിസ്ഥാന സൗകര്യങ്ങളിൽ വളരെ ഗുരുതരമായ നിക്ഷേപം ആവശ്യമാണ്. അവ ഒരു ഡാറ്റാ സെന്ററിനുള്ളിൽ റിസർവ് ചെയ്‌തിരിക്കുന്നു, പക്ഷേ, ദൈവം വിലക്കിയാൽ, വിസയിലേക്കും മാസ്റ്റർകാർഡിലേക്കും കണക്‌റ്റുചെയ്യുന്നതിനുള്ള മിക്സുകൾ ഉള്ള ഞങ്ങളുടെ ഡാറ്റാ സെന്റർ മരിക്കുകയാണെങ്കിൽ, ഞങ്ങൾക്ക് വിസയുമായും മാസ്റ്റർകാർഡുമായും ഒരു ബന്ധം നഷ്ടപ്പെടും...

  വി: - അവ എങ്ങനെ സംവരണം ചെയ്യാൻ കഴിയും? വിസ തത്വത്തിൽ ഒരു കണക്ഷൻ മാത്രമേ അനുവദിക്കൂ എന്ന് എനിക്കറിയാം!

  EK: - അവർ സ്വയം ഉപകരണങ്ങൾ വിതരണം ചെയ്യുന്നു. ഏത് സാഹചര്യത്തിലും, ഉള്ളിൽ പൂർണ്ണമായും അനാവശ്യമായ ഉപകരണങ്ങൾ ഞങ്ങൾക്ക് ലഭിച്ചു.

  വി: – അപ്പോൾ സ്റ്റാൻഡ് അവരുടെ കണക്ട്സ് ഓറഞ്ചിൽ നിന്നാണോ?..

  EK: - അതെ.

  വി: - എന്നാൽ ഈ കേസിന്റെ കാര്യമോ: നിങ്ങളുടെ ഡാറ്റാ സെന്റർ അപ്രത്യക്ഷമായാൽ, നിങ്ങൾക്ക് അത് എങ്ങനെ ഉപയോഗിക്കുന്നത് തുടരാനാകും? അതോ ഗതാഗതം നിലയ്ക്കുമോ?

  EK: - ഇല്ല. ഈ സാഹചര്യത്തിൽ, ഞങ്ങൾ ട്രാഫിക് മറ്റൊരു ചാനലിലേക്ക് മാറ്റും, അത് സ്വാഭാവികമായും ഞങ്ങൾക്ക് കൂടുതൽ ചെലവേറിയതും ഞങ്ങളുടെ ക്ലയന്റുകൾക്ക് കൂടുതൽ ചെലവേറിയതുമായിരിക്കും. എന്നാൽ വിസ, മാസ്റ്റർകാർഡ് എന്നിവയിലേക്കുള്ള ഞങ്ങളുടെ നേരിട്ടുള്ള കണക്ഷനിലൂടെ ട്രാഫിക് പോകില്ല, മറിച്ച് സോപാധികമായ Sberbank വഴി (വളരെ അതിശയോക്തിപരമാണ്).

  ഞാൻ Sberbank ജീവനക്കാരെ വ്രണപ്പെടുത്തിയെങ്കിൽ ഞാൻ വന്യമായി ക്ഷമ ചോദിക്കുന്നു. എന്നാൽ ഞങ്ങളുടെ സ്ഥിതിവിവരക്കണക്കുകൾ പ്രകാരം, റഷ്യൻ ബാങ്കുകൾക്കിടയിൽ, Sberbank മിക്കപ്പോഴും വീഴുന്നു. Sberbank-ൽ എന്തെങ്കിലും വീഴാതെ ഒരു മാസം പോലും കടന്നുപോകുന്നില്ല.

  
  
  

  ചില പരസ്യങ്ങൾ 🙂

  ഞങ്ങളോടൊപ്പം താമസിച്ചതിന് നന്ദി. ഞങ്ങളുടെ ലേഖനങ്ങൾ നിങ്ങൾക്ക് ഇഷ്ടമാണോ? കൂടുതൽ രസകരമായ ഉള്ളടക്കം കാണാൻ ആഗ്രഹിക്കുന്നുണ്ടോ? ഒരു ഓർഡർ നൽകി അല്ലെങ്കിൽ സുഹൃത്തുക്കൾക്ക് ശുപാർശ ചെയ്തുകൊണ്ട് ഞങ്ങളെ പിന്തുണയ്ക്കുക, $4.99 മുതൽ ഡെവലപ്പർമാർക്കുള്ള ക്ലൗഡ് VPS, എൻട്രി ലെവൽ സെർവറുകളുടെ ഒരു അദ്വിതീയ അനലോഗ്, നിങ്ങൾക്കായി ഞങ്ങൾ കണ്ടുപിടിച്ചതാണ്: VPS (KVM) E5-2697 v3 (6 കോറുകൾ) 10GB DDR4 480GB SSD 1Gbps-നെക്കുറിച്ചുള്ള മുഴുവൻ സത്യവും $19 മുതൽ അല്ലെങ്കിൽ എങ്ങനെ ഒരു സെർവർ പങ്കിടാം? (RAID1, RAID10 എന്നിവയ്‌ക്കൊപ്പം 24 കോറുകൾ വരെയും 40GB DDR4 വരെയും ലഭ്യമാണ്).

  ആംസ്റ്റർഡാമിലെ Equinix Tier IV ഡാറ്റാ സെന്ററിൽ Dell R730xd 2 മടങ്ങ് വിലക്കുറവാണോ? ഇവിടെ മാത്രം 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 മുതൽ നെതർലാൻഡിൽ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 മുതൽ! കുറിച്ച് വായിക്കുക ഇൻഫ്രാസ്ട്രക്ചർ കോർപ്പറേഷൻ എങ്ങനെ നിർമ്മിക്കാം. ഒരു പൈസയ്ക്ക് 730 യൂറോ വിലയുള്ള Dell R5xd E2650-4 v9000 സെർവറുകൾ ഉപയോഗിക്കുന്ന ക്ലാസ്?

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