ഉൽപ്പന്നത്തെക്കുറിച്ചുള്ള പരിശോധന: കാനറി വിന്യാസം

കാനറി പക്ഷികൾ നിരന്തരം പാടുന്ന ഒരു ചെറിയ പക്ഷിയാണ്. ഈ പക്ഷികൾ മീഥേൻ, കാർബൺ മോണോക്സൈഡ് എന്നിവയോട് സംവേദനക്ഷമതയുള്ളവയാണ്. വായുവിലെ ഈ വാതകങ്ങളുടെ ചെറിയ സാന്ദ്രത പോലും അവയ്ക്ക് ബോധം നഷ്ടപ്പെടാനോ മരിക്കാനോ കാരണമാകും. സ്വർണ്ണ ഖനിത്തൊഴിലാളികളും ഖനിത്തൊഴിലാളികളും ഖനനം ചെയ്യുമ്പോൾ ഈ പക്ഷികളെ കൂടെ കൊണ്ടുപോകും: കാനറികൾ പാടുമ്പോൾ, അവയ്ക്ക് ജോലി ചെയ്യാൻ കഴിയും; അവ പാടുന്നത് നിർത്തിയാൽ, ഖനിയിൽ വാതകം ഉണ്ടായിരുന്നു, ഖനി വിടാൻ സമയമായി. ജീവനോടെ രക്ഷപ്പെടാൻ ഖനിത്തൊഴിലാളികൾ ചെറിയ പക്ഷിയെ ബലിയർപ്പിക്കും.

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

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

ഇൻഫോബിപ്പിനെക്കുറിച്ച്

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

ഇൻഫോബിപ്പിന്റെ ഐടി അടിസ്ഥാന സൗകര്യങ്ങൾ കണക്കുകളിൽ:

• ലോകമെമ്പാടുമുള്ള 15 ഡാറ്റാ സെന്ററുകൾ;
• പ്രവർത്തനത്തിലുള്ള 500 അതുല്യ സേവനങ്ങൾ;
• 2500 സർവീസ് സന്ദർഭങ്ങൾ, ഇത് കമാൻഡുകളേക്കാൾ വളരെ കൂടുതലാണ്;
• പ്രതിമാസ ട്രാഫിക് 4,5 TB;
• 4,5 ബില്യൺ ടെലിഫോൺ നമ്പറുകൾ;

ബിസിനസ്സ് വളരുകയാണ്, അതോടൊപ്പം റിലീസുകളുടെ എണ്ണവും വർദ്ധിക്കുന്നു. ഞങ്ങൾ നടത്തുന്നത് പ്രതിദിനം 60 റിലീസുകൾ, കാരണം ക്ലയന്റുകൾ കൂടുതൽ സവിശേഷതകളും ശേഷിയും ആഗ്രഹിക്കുന്നു. പക്ഷേ അത് ബുദ്ധിമുട്ടാണ്—ധാരാളം സേവനങ്ങളും കുറച്ച് ടീമുകളും ഉണ്ട്. ഉൽ‌പാദനത്തിൽ കുറ്റമറ്റ രീതിയിൽ പ്രവർത്തിക്കുന്ന കോഡ് നിങ്ങൾ വേഗത്തിൽ എഴുതണം.

റിലീസുകൾ

ഞങ്ങൾക്ക് ഒരു സാധാരണ റിലീസ് ഇങ്ങനെയാണ്. ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് A, B, C, D, E എന്നീ സേവനങ്ങൾ ഉണ്ട്, ഓരോന്നും പ്രത്യേക ടീം വികസിപ്പിച്ചെടുത്തതാണ്.

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

നടത്തും ഇൻക്രിമെന്റൽ റിലീസ്: ആദ്യം ഒരു പതിപ്പ് മാറ്റിസ്ഥാപിക്കുക, തുടർന്ന് രണ്ടാമത്തേത്.

പക്ഷേ രണ്ടാമത്തെ ഓപ്ഷൻ കൂടിയുണ്ട്: ടീം അധിക ശേഷിയും യന്ത്രങ്ങളും കണ്ടെത്തും, പുതിയ പതിപ്പ് വിന്യസിക്കുക, തുടർന്ന് റൂട്ടർ മാറ്റുക, പതിപ്പ് ഉൽ‌പാദനത്തിൽ പ്രവർത്തിക്കാൻ തുടങ്ങും.

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

അപ്പോൾ നമുക്ക് എന്താണ് വേണ്ടത്?

ഞങ്ങൾക്ക് പ്രശ്‌നങ്ങൾ ആവശ്യമില്ല. ക്ലയന്റുകൾ ഞങ്ങളുടെ മുന്നിൽ അവരെ കണ്ടെത്തിയാൽ, അത് ഞങ്ങളുടെ പ്രശസ്തിയെ നശിപ്പിക്കും. അതുകൊണ്ടാണ് നമ്മൾ ഉപഭോക്താക്കളേക്കാൾ വേഗത്തിൽ പ്രശ്നങ്ങൾ കണ്ടെത്തുകമുൻകരുതലോടെ പ്രവർത്തിക്കുന്നതിലൂടെ, ഞങ്ങൾ നാശനഷ്ടങ്ങൾ കുറയ്ക്കുന്നു.

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

വിന്യാസ പ്രശ്നങ്ങൾ

ഉപഭോക്തൃ ട്രാഫിക് പ്രവചനാതീതമാണ്ഉപഭോക്തൃ ട്രാഫിക് എപ്പോൾ ഏറ്റവും താഴ്ന്ന നിലയിലായിരിക്കുമെന്ന് പ്രവചിക്കുക അസാധ്യമാണ്. ഉപഭോക്താക്കൾ എവിടെ, എപ്പോൾ അവരുടെ കാമ്പെയ്‌നുകൾ ആരംഭിക്കുമെന്ന് ഞങ്ങൾക്ക് അറിയില്ല - ഇന്ത്യയിൽ ഇന്ന് രാത്രിയും നാളെ ഹോങ്കോങ്ങിലും ആകാം. വലിയ സമയ വ്യത്യാസം കണക്കിലെടുക്കുമ്പോൾ, പുലർച്ചെ 2 മണിക്ക് വിന്യസിക്കുന്നത് പോലും ഉപഭോക്തൃ സംതൃപ്തി ഉറപ്പുനൽകുന്നില്ല.

ദാതാവിന്റെ പ്രശ്നങ്ങൾമെസഞ്ചർമാരും ദാതാക്കളും ഞങ്ങളുടെ പങ്കാളികളാണ്. ചിലപ്പോൾ പുതിയ പതിപ്പുകൾ വിന്യസിക്കുമ്പോൾ പിശകുകൾക്ക് കാരണമാകുന്ന തകരാറുകൾ അവർക്ക് അനുഭവപ്പെടാറുണ്ട്.

വിതരണം ചെയ്ത ടീമുകൾക്ലയന്റും ബാക്കെൻഡും വികസിപ്പിക്കുന്ന ടീമുകൾ വ്യത്യസ്ത സമയ മേഖലകളിലാണ് സ്ഥിതി ചെയ്യുന്നത്. ഇക്കാരണത്താൽ, അവർക്ക് പലപ്പോഴും ആശയവിനിമയം നടത്താൻ കഴിയാതെ വരുന്നു.

ഡാറ്റാ സെന്ററുകൾ സ്റ്റേജിൽ പകർത്താൻ കഴിയില്ല.ഒരു ഡാറ്റാ സെന്ററിൽ 200 റാക്കുകൾ ഉണ്ട് - ഒരു സാൻഡ്‌ബോക്‌സിൽ അത് പകർത്തുക അസാധ്യമാണ്.

പ്രവർത്തനരഹിതമായ സമയങ്ങൾഅസ്വീകാര്യമാണ്! ഞങ്ങൾക്ക് സ്വീകാര്യമായ ലഭ്യതാ നിലവാരമുണ്ട് (പിശക് ബജറ്റ്), ഉദാഹരണത്തിന്, ഞങ്ങൾ 99,99% സമയവും പ്രവർത്തിക്കുന്നു, ശേഷിക്കുന്ന ശതമാനം "പിശകിനുള്ള മാർജിൻ" ആയി കണക്കാക്കപ്പെടുന്നു. 100% വിശ്വാസ്യത കൈവരിക്കുക അസാധ്യമാണ്, പക്ഷേ തടസ്സങ്ങളും പ്രവർത്തനരഹിതമായ സമയവും നിരന്തരം നിരീക്ഷിക്കേണ്ടത് പ്രധാനമാണ്.

ക്ലാസിക് പരിഹാരങ്ങൾ

ബഗ്-ഫ്രീ കോഡ് എഴുതുകഞാൻ ഒരു യുവ ഡെവലപ്പർ ആയിരുന്നപ്പോൾ, ബഗുകൾ ഇല്ലാതെ റിലീസ് ചെയ്യാനുള്ള അഭ്യർത്ഥനകളുമായി മാനേജർമാർ എന്നെ സമീപിക്കുമായിരുന്നു, പക്ഷേ ഇത് എല്ലായ്പ്പോഴും സാധ്യമല്ല.

പരീക്ഷകൾ എഴുതുകപരീക്ഷണങ്ങൾ ഫലപ്രദമാണ്, പക്ഷേ ചിലപ്പോൾ ബിസിനസ്സ് ആഗ്രഹിക്കുന്ന രീതിയിൽ അല്ല. പണമുണ്ടാക്കുക എന്നത് പരീക്ഷണങ്ങളുടെ ലക്ഷ്യമല്ല.

സ്റ്റേജിൽ പരീക്ഷണംഇൻഫോബിപ്പിലെ എന്റെ 3,5 വർഷത്തിനിടയിൽ, സ്റ്റേജ് പ്രൊഡക്ഷൻ സ്റ്റേറ്റുമായി ഭാഗികമായി പോലും പൊരുത്തപ്പെടുന്നത് ഞാൻ കണ്ടിട്ടില്ല.

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

ഇത് വികസിപ്പിച്ചയാൾ തന്നെയാണ് റിലീസ് ചെയ്യുന്നത്. വ്യത്യസ്തമായ തലക്കെട്ട് നൽകിയാലും, പ്രൊഡക്ഷനിൽ ഉടനടി ഒരു അഭിപ്രായം ചേർക്കുന്നത് നല്ലൊരു ശീലമാണ്. ഇത് ഉത്തരവാദിത്തം വളർത്താൻ സഹായിക്കുകയും മാറ്റങ്ങൾ ഓർമ്മിക്കപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുന്നു.

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

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

പുക പരിശോധനകൾ

ഞങ്ങളുടെ വിന്യാസ പ്രശ്നങ്ങൾ പരിഹരിക്കാനുള്ള മറ്റൊരു മാർഗം. ടീം എ ഒരു പുതിയ പതിപ്പ് വിന്യസിക്കാൻ ആഗ്രഹിക്കുമ്പോൾ, മുമ്പത്തെ ഉദാഹരണം ഉപയോഗിച്ച് പുക പരിശോധനകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് നോക്കാം.

ആദ്യം, ടീം ഒരു ഉദാഹരണം നിർമ്മാണത്തിനായി വിന്യസിക്കുന്നു. മോക്കുകളിൽ നിന്നുള്ള ഉദാഹരണത്തിലേക്കുള്ള സന്ദേശങ്ങൾ യഥാർത്ഥ ട്രാഫിക് സിമുലേറ്റ് ചെയ്തിരിക്കുന്നു.സാധാരണ ദൈനംദിന ട്രാഫിക്കുമായി പൊരുത്തപ്പെടുന്നതിന്. എല്ലാം ശരിയാണെങ്കിൽ, ടീം പുതിയ പതിപ്പ് ഉപയോക്തൃ ട്രാഫിക്കിലേക്ക് മാറ്റുന്നു.

രണ്ടാമത്തെ ഓപ്ഷൻ വിന്യസിക്കുക എന്നതാണ് അധിക ഇരുമ്പ് ഉപയോഗിച്ച്. ടീം അത് ഉൽ‌പാദനത്തിൽ പരീക്ഷിക്കുന്നു, തുടർന്ന് അത് മാറ്റുന്നു, എല്ലാം പ്രവർത്തിക്കുന്നു.

പുക പരിശോധനയുടെ ദോഷങ്ങൾ:

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

ഇവിടെയുള്ള ഏക ബോണസ് നിങ്ങൾക്ക് പ്രകടനം പരിശോധിക്കാം..

കാനറി റിലീസുകൾ

പുക പരിശോധനകളുടെ പോരായ്മകൾ കാരണം, ഞങ്ങൾ കാനറി റിലീസുകൾ ഉപയോഗിക്കാൻ തുടങ്ങി.

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

നടപ്പാക്കലും സൂക്ഷ്മതകളും

ഞങ്ങൾ എങ്ങനെയാണ് കാനറി റിലീസുകൾ നടപ്പിലാക്കിയത്? ഉദാഹരണത്തിന്, ഒരു കൂട്ടം ക്ലയന്റുകൾ ഞങ്ങളുടെ സേവനത്തിലൂടെ സന്ദേശങ്ങൾ അയയ്ക്കുന്നു.

വിന്യാസം ഇങ്ങനെയാണ്: ബാലൻസറിൽ നിന്ന് (1) ഒരു നോഡ് നീക്കം ചെയ്യുക, പതിപ്പ് (2) മാറ്റുക, കൂടാതെ കുറച്ച് ട്രാഫിക് പ്രത്യേകം സമാരംഭിക്കുക (3).

മൊത്തത്തിൽ, ഗ്രൂപ്പിലെ എല്ലാവരും സന്തുഷ്ടരായിരിക്കും, ഒരു ഉപയോക്താവ് അസന്തുഷ്ടനാണെങ്കിൽ പോലും. എല്ലാം ശരിയാണെങ്കിൽ, ഞങ്ങൾ എല്ലാ പതിപ്പുകളും മാറ്റും.

മിക്ക കേസുകളിലും മൈക്രോസർവീസുകൾക്ക് ഇത് എങ്ങനെയിരിക്കുമെന്ന് കാണിക്കുന്ന ഒരു ഡയഗ്രം ഞാൻ നിങ്ങൾക്ക് കാണിച്ചുതരാം.

സർവീസ് ഡിസ്കവറിയും മറ്റ് രണ്ട് സേവനങ്ങളും ഉണ്ട്: S1N1 ഉം S2 ഉം. ആദ്യ സേവനം (S1N1) സർവീസ് ഡിസ്കവറിയെ ആരംഭിക്കുമ്പോൾ അറിയിക്കുന്നു, സർവീസ് ഡിസ്കവറിയെ അത് ഓർമ്മിക്കുന്നു. രണ്ട് നോഡുകൾ (S2N1 ഉം S2N2 ഉം) ഉള്ള രണ്ടാമത്തെ സേവനം, സർവീസ് ഡിസ്കവറിയെ ആരംഭിക്കുമ്പോൾ അറിയിക്കുന്നു.

രണ്ടാമത്തെ സേവനം ആദ്യത്തേതിന് ഒരു സെർവറായി പ്രവർത്തിക്കുന്നു. ആദ്യ സേവനം സർവീസ് ഡിസ്കവറിയിൽ നിന്ന് അതിന്റെ സെർവറുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ അഭ്യർത്ഥിക്കുന്നു, അത് ലഭിക്കുമ്പോൾ, അത് അവ തിരയുകയും പരിശോധിക്കുകയും ചെയ്യുന്നു ("ആരോഗ്യ പരിശോധനകൾ"). പരിശോധിച്ചുറപ്പിച്ചുകഴിഞ്ഞാൽ, അത് അവർക്ക് സന്ദേശങ്ങൾ അയയ്ക്കുന്നു.

രണ്ടാമത്തെ സേവനത്തിന്റെ പുതിയ പതിപ്പ് വിന്യസിക്കാൻ ആരെങ്കിലും ആഗ്രഹിക്കുമ്പോൾ, രണ്ടാമത്തെ നോഡ് ഒരു കാനറി നോഡ് ആയിരിക്കുമെന്ന് അവർ സർവീസ് ഡിസ്കവറിയെ അറിയിക്കുന്നു: വിന്യാസം നടക്കാൻ പോകുന്നതിനാൽ അതിലേക്ക് കുറച്ച് ട്രാഫിക് മാത്രമേ അയയ്ക്കൂ. ലോഡ് ബാലൻസറിൽ നിന്ന് ഞങ്ങൾ കാനറി നോഡ് നീക്കം ചെയ്യുന്നു, ആദ്യ സേവനം അതിലേക്ക് ട്രാഫിക് അയയ്ക്കുന്നത് നിർത്തുന്നു.

ഞങ്ങൾ പതിപ്പ് മാറ്റുന്നു, രണ്ടാമത്തെ നോഡ് ഇപ്പോൾ കാനറി ആണെന്ന് സർവീസ് ഡിസ്കവറിക്ക് അറിയാം - നമുക്ക് അതിന് കുറഞ്ഞ ലോഡ് (5%) നൽകാൻ കഴിയും. എല്ലാം ശരിയായി നടക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ പതിപ്പ് മാറ്റി, ലോഡ് പുനഃസ്ഥാപിച്ച്, പ്രവർത്തിക്കുന്നത് തുടരും.

ഇതെല്ലാം നടപ്പിലാക്കാൻ, നമുക്ക് ഇത് ആവശ്യമാണ്:

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

ബാലൻസിംഗ്

ഇതാണ് നമ്മൾ ആദ്യം ചിന്തിക്കേണ്ടത്. രണ്ട് സന്തുലന തന്ത്രങ്ങളുണ്ട്.

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

വിന്യാസ പ്രക്രിയയിൽ കാനറി നോഡ് സജ്ജീകരിച്ചിരിക്കുന്നു.വിന്യാസം പൂർത്തിയായിക്കഴിഞ്ഞാൽ, കാനറി നോഡ് സ്റ്റാറ്റസിൽ നിന്ന് ഞങ്ങൾ അത് നീക്കം ചെയ്‌താൽ, ട്രാഫിക് ബാലൻസ് പുനഃസ്ഥാപിക്കപ്പെടും. കുറച്ച് മെഷീനുകൾ ഉള്ളതിനാൽ, ഞങ്ങൾക്ക് ന്യായമായ വിതരണം കൈവരിക്കാനാകും.

നിരീക്ഷിക്കുന്നു

കാനറി റിലീസുകളുടെ മൂലക്കല്ല്: നമ്മൾ എന്തിനാണ് ഇത് ചെയ്യുന്നതെന്നും ഏതൊക്കെ മെട്രിക്കുകൾ ശേഖരിക്കണമെന്നും വ്യക്തമായി മനസ്സിലാക്കേണ്ടതുണ്ട്.

ഞങ്ങളുടെ സേവനങ്ങളിൽ നിന്ന് ഞങ്ങൾ ശേഖരിക്കുന്ന മെട്രിക്കുകളുടെ ഉദാഹരണങ്ങൾ.

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

ഏറ്റവും ജനപ്രിയമായ മോണിറ്ററിംഗ് സിസ്റ്റങ്ങളിലെ മെട്രിക്കുകളുടെ ഉദാഹരണങ്ങൾ.

കൗണ്ടർ. ഇത് വർദ്ധിച്ചുവരുന്ന മൂല്യമാണ്, ഉദാഹരണത്തിന്, പിശകുകളുടെ എണ്ണം. ഈ മെട്രിക് ഇന്റർപോളേറ്റ് ചെയ്ത് ഗ്രാഫ് പഠിക്കാൻ എളുപ്പമാണ്: ഇന്നലെ 2 പിശകുകൾ ഉണ്ടായിരുന്നു, ഇന്ന് 500 ഉണ്ട്, അതായത് എന്തോ കുഴപ്പം സംഭവിച്ചു എന്നാണ്.

മിനിറ്റിലോ സെക്കൻഡിലോ ഉണ്ടാകുന്ന പിശകുകളുടെ എണ്ണം കൗണ്ടർ ഉപയോഗിച്ച് കണക്കാക്കാൻ കഴിയുന്ന ഒരു പ്രധാന മെട്രിക് ആണ്. കാലക്രമേണ സിസ്റ്റത്തിന്റെ പ്രകടനത്തിന്റെ വ്യക്തമായ ചിത്രം ഈ ഡാറ്റ നൽകുന്നു. ഒരു പ്രൊഡക്ഷൻ സിസ്റ്റത്തിന്റെ രണ്ട് പതിപ്പുകൾക്കായി സെക്കൻഡിൽ ഉണ്ടാകുന്ന പിശകുകളുടെ എണ്ണത്തിന്റെ ഒരു ഉദാഹരണ ഗ്രാഫ് നോക്കാം.

ആദ്യ പതിപ്പിൽ കുറച്ച് ബഗുകൾ ഉണ്ടായിരുന്നു, ഒരുപക്ഷേ ഓഡിറ്റിംഗ് പ്രവർത്തിച്ചില്ലായിരിക്കാം. രണ്ടാമത്തെ പതിപ്പ് വളരെ മോശമാണ്. തീർച്ചയായും പ്രശ്‌നങ്ങളുണ്ടെന്ന് നമുക്ക് പറയാൻ കഴിയും, അതിനാൽ ആ പതിപ്പ് ഞങ്ങൾ പഴയപടിയാക്കേണ്ടതുണ്ട്.

ഗേജ്. മെട്രിക്കുകൾ കൗണ്ടറിന് സമാനമാണ്, പക്ഷേ അഭ്യർത്ഥന നിർവ്വഹണ സമയം അല്ലെങ്കിൽ ക്യൂ വലുപ്പം പോലുള്ള വർദ്ധിക്കുകയോ കുറയുകയോ ചെയ്യാവുന്ന മൂല്യങ്ങൾ ഞങ്ങൾ രേഖപ്പെടുത്തുന്നു.

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

സംഗ്രഹം. ബിസിനസ്സിന് ഏറ്റവും പ്രധാനപ്പെട്ട മെട്രിക്സുകളിലൊന്നാണ് പെർസെന്റൈലുകൾ. മെട്രിക് കാണിക്കുന്നത് 95% കേസുകൾ നമ്മുടെ സിസ്റ്റം നമ്മൾ ആഗ്രഹിക്കുന്ന രീതിയിലാണ് പ്രവർത്തിക്കുന്നത്. കാര്യങ്ങൾ എത്ര നല്ലതോ ചീത്തയോ ആണെന്ന് മൊത്തത്തിലുള്ള പ്രവണത, നമുക്ക് മനസ്സിലാകുന്നതിനാൽ എവിടെയെങ്കിലും പ്രശ്നങ്ങൾ അംഗീകരിക്കാൻ കഴിയും.

ഉപകരണങ്ങൾ

ELK സ്റ്റാക്ക്നിങ്ങൾക്ക് Elasticsearch ഉപയോഗിച്ച് canary നടപ്പിലാക്കാൻ കഴിയും—ഇവന്റുകൾ സംഭവിക്കുമ്പോൾ ഞങ്ങൾ അവിടെ പിശകുകൾ രേഖപ്പെടുത്തുന്നു. ഒരു ലളിതമായ API കോൾ ഏത് സമയത്തും പിശകുകളുടെ എണ്ണം നേടാനും അവയെ മുൻ പിരീഡുകളുമായി താരതമ്യം ചെയ്യാനും നിങ്ങളെ അനുവദിക്കുന്നു: GET /applg/_cunt?q=level:errr.

പ്രോമിത്യൂസ്. ഇൻഫോബിപ്പിൽ ഇത് മികച്ച പ്രകടനം കാഴ്ചവച്ചു. ലേബലുകൾ ഉപയോഗിക്കുന്നതിനാൽ മൾട്ടിഡൈമൻഷണൽ മെട്രിക്സ് നടപ്പിലാക്കാൻ ഇത് അനുവദിക്കുന്നു.

നമുക്ക് ഉപയോഗിക്കാം level, instance, service, അവയെ ഒരു സിസ്റ്റത്തിൽ സംയോജിപ്പിക്കുക. സഹായത്തോടെ offset ഉദാഹരണത്തിന്, ഒരു കമാൻഡ് ഉപയോഗിച്ച് ഒരു ആഴ്ച മുമ്പുള്ള ഒരു അളവിന്റെ മൂല്യം നിങ്ങൾക്ക് കാണാൻ കഴിയും. GET /api/v1/query?query={query}എവിടെ {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

പതിപ്പ് വിശകലനം

പതിപ്പ് വിശകലനത്തിന് നിരവധി തന്ത്രങ്ങളുണ്ട്.

കാനറി നോഡുകൾക്ക് മാത്രമുള്ള മെട്രിക്‌സ് കാണുക. ഏറ്റവും ലളിതമായ ഓപ്ഷനുകളിൽ ഒന്ന്: പുതിയ പതിപ്പ് വിന്യസിക്കുക, അത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് പഠിക്കുക. എന്നാൽ ഒരു എഞ്ചിനീയർ ഇത് ചെയ്യുമ്പോൾ ലോഗുകൾ പഠിക്കാൻ തുടങ്ങിയാൽ, നിരന്തരം പേജുകൾ പുതുക്കുകയാണെങ്കിൽ, ഈ പരിഹാരവും മറ്റുള്ളവയിൽ നിന്ന് വ്യത്യസ്തമല്ല.

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

കാനറി നോഡിനെ അതിന്റെ പഴയ സ്വത്വവുമായി താരതമ്യം ചെയ്യുന്നു. കാനറികൾക്കായി അനുവദിച്ച നോഡുകളെ ചരിത്രപരമായ ഡാറ്റയുമായി താരതമ്യം ചെയ്യാൻ കഴിയും. ഉദാഹരണത്തിന്, ഒരു ആഴ്ച മുമ്പ് എല്ലാം ശരിയായിരുന്നുവെങ്കിൽ, നിലവിലെ സാഹചര്യം മനസ്സിലാക്കാൻ നമുക്ക് ഈ ഡാറ്റ ഉപയോഗിക്കാം.

ഓട്ടോമേഷൻ

എഞ്ചിനീയർമാരെ മാനുവൽ താരതമ്യങ്ങളിൽ നിന്ന് മോചിപ്പിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു, അതിനാൽ ഓട്ടോമേഷൻ നടപ്പിലാക്കേണ്ടത് പ്രധാനമാണ്. വിന്യാസ പൈപ്പ്‌ലൈൻ സാധാരണയായി ഇതുപോലെ കാണപ്പെടുന്നു:

• നമുക്ക് തുടങ്ങാം;
• ബാലൻസറിന് കീഴിൽ നിന്ന് നോഡ് നീക്കം ചെയ്യുക;
• ഞങ്ങൾ ഒരു കാനറി നോഡ് ഇൻസ്റ്റാൾ ചെയ്യുന്നു;
• പരിമിതമായ ട്രാഫിക്കിൽ ഞങ്ങൾ ബാലൻസർ ഓണാക്കുന്നു;
• താരതമ്യം ചെയ്യാം.

ഈ ഘട്ടത്തിൽ ഞങ്ങൾ നടപ്പിലാക്കുന്നത് യാന്ത്രിക താരതമ്യംഇത് എങ്ങനെയായിരിക്കാമെന്നും പോസ്റ്റ്-ഡിപ്ലോയ്‌മെന്റ് പരിശോധനയേക്കാൾ ഇത് എന്തുകൊണ്ട് മികച്ചതാണെന്നും കാണാൻ ജെൻകിൻസിൽ നിന്നുള്ള ഒരു ഉദാഹരണം നോക്കാം.

ഇത് ഗ്രൂവിയിലേക്കുള്ള ഒരു പൈപ്പ്‌ലൈനാണ്.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

ഇവിടെ ലൂപ്പിൽ, ഒരു മണിക്കൂറിനുള്ളിൽ പുതിയ നോഡ് താരതമ്യം ചെയ്യുമെന്ന് ഞങ്ങൾ വ്യക്തമാക്കുന്നു. കാനറി പ്രക്രിയ ഇതുവരെ പൂർത്തിയായിട്ടില്ലെങ്കിൽ, ഞങ്ങൾ ഫംഗ്ഷനെ വിളിക്കുന്നു. എല്ലാം ശരിയാണോ അല്ലയോ എന്ന് ഇത് റിപ്പോർട്ട് ചെയ്യുന്നു: def isOk = compare(srv, canary, time, base, offset, metrics).

എല്ലാം നല്ലതാണെങ്കിൽ - sleep DEFAULT SLEEPഉദാഹരണത്തിന്, ഒരു സെക്കൻഡ് നേരത്തേക്ക്, തുടർന്ന് തുടരുക. അല്ലെങ്കിൽ, പുറത്തുകടക്കുക—വിന്യാസം പരാജയപ്പെട്ടു.

മെട്രിക്കിന്റെ വിവരണം. ഫംഗ്ഷൻ എങ്ങനെയായിരിക്കുമെന്ന് നമുക്ക് നോക്കാം. compare ഒരു ഉദാഹരണമായി DSL ഉപയോഗിക്കുന്നു.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

നമ്മൾ പിശകുകളുടെ എണ്ണം താരതമ്യം ചെയ്യുകയാണെന്നും കഴിഞ്ഞ 5 മിനിറ്റിനുള്ളിൽ സെക്കൻഡിൽ എത്ര പിശകുകൾ ഉണ്ടായെന്നും അറിയാൻ ആഗ്രഹിക്കുന്നുവെന്നും കരുതുക.

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

ഇതെല്ലാം ആവശ്യമായിരിക്കുന്നത് എന്തുകൊണ്ട്?

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

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

പ്രശ്നങ്ങൾ ഉണ്ടായാൽ, ഞങ്ങൾ കാനറി നോഡ് സ്വയമേവ പഴയപടിയാക്കുകയും, മുൻ പതിപ്പുകളിൽ പ്രവർത്തിപ്പിക്കുകയും, കണ്ടെത്തിയ പിശകുകൾ പരിഹരിക്കുകയും ചെയ്യും. മെട്രിക്കുകൾ അവ തിരിച്ചറിയുന്നതും പുതിയ പതിപ്പിന്റെ സ്വാധീനം കാണുന്നതും എളുപ്പമാക്കുന്നു.

തടസ്സങ്ങൾ

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

അത് പ്രായോഗികമായി പരീക്ഷിക്കേണ്ടതുണ്ട് മെട്രിക്സിന്റെ സ്ഥിരത. പരിശോധിക്കുന്നത് മനസ്സിലാക്കാൻ നിങ്ങളെ സഹായിക്കുന്നു ഗുണനിലവാരം ഉറപ്പാക്കാൻ ആവശ്യമായ ഏറ്റവും കുറഞ്ഞ അളവുകോലുകൾ എന്തൊക്കെയാണ്?.

ഇത് എങ്ങനെ നേടാം? വിന്യാസ സമയത്ത് ഉപയോഗിക്കാതെ കാനറി സേവനം ഉപയോഗിക്കുക.പഴയ പതിപ്പിലേക്ക് ഞങ്ങൾ ഒരു സേവനം ചേർക്കുന്നു, അത് ഏത് സമയത്തും ഏത് സമർപ്പിത നോഡിനെയും ഏറ്റെടുക്കാനും, വിന്യസിക്കാതെ തന്നെ ട്രാഫിക് കുറയ്ക്കാനും കഴിയും. തുടർന്ന് ഞങ്ങൾ താരതമ്യം ചെയ്യുന്നു: പിശകുകൾ പഠിക്കുകയും ഗുണനിലവാരം കൈവരിക്കുന്ന പരിധി കണ്ടെത്തുകയും ചെയ്യുന്നു.

കാനറി റിലീസുകളിൽ നിന്ന് നമുക്ക് എന്ത് നേട്ടങ്ങളാണ് ലഭിച്ചത്?

ബഗുകൾ മൂലമുണ്ടാകുന്ന നാശത്തിന്റെ ശതമാനം കുറച്ചു. ഡാറ്റയോ മുൻഗണനാക്രമത്തിലുള്ള പൊരുത്തക്കേടുകളോ മൂലമാണ് മിക്ക വിന്യാസ പിശകുകളും സംഭവിക്കുന്നത്. നിമിഷങ്ങൾക്കുള്ളിൽ നമുക്ക് പ്രശ്നം പരിഹരിക്കാൻ കഴിയുന്നതിനാൽ ഈ പിശകുകൾ വളരെ കുറവാണ്.

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

ഓട്ടോമേറ്റഡ് വിന്യാസംഇത് മുമ്പത്തെപ്പോലെ ഇനി ഒരു മാനുവൽ പ്രക്രിയയല്ല, മറിച്ച് ശരിക്കും ഓട്ടോമേറ്റഡ് ആണ്. പക്ഷേ ഇതിന് കൂടുതൽ സമയമെടുക്കും.

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

ഞങ്ങളെ സഹായിക്കുന്ന നിരവധി മികച്ച രീതികളും സംവിധാനങ്ങളും ഞങ്ങൾക്കുണ്ട്. എന്നിരുന്നാലും, ഞങ്ങളെ സഹായിക്കാൻ ഒരു സംവിധാനമുണ്ടോ ഇല്ലയോ എന്നത് പരിഗണിക്കാതെ, പ്രൊഫഷണലായിരിക്കാനും ഞങ്ങളുടെ ജോലി നന്നായി ചെയ്യാനും ഞങ്ങൾ ശ്രമിക്കുന്നു.

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

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

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