ചാവോസ് എഞ്ചിനീയറിംഗ്: ബോധപൂർവ്വം നശിപ്പിക്കുന്ന കല. ഭാഗം 2

കുറിപ്പ്. വിവർത്തനം.: ഐടി സംവിധാനങ്ങളിലെ പരാജയങ്ങളുടെ അനന്തരഫലങ്ങൾ ലഘൂകരിക്കാനുള്ള പരീക്ഷണത്തിന്റെ പ്രാധാന്യം ലളിതവും വ്യക്തവുമായ രീതിയിൽ വിശദീകരിക്കാൻ പുറപ്പെടുന്ന AWS സാങ്കേതിക സുവിശേഷകനായ അഡ്രിയാൻ ഹോൺസ്ബിയിൽ നിന്നുള്ള ലേഖനങ്ങളുടെ ഒരു വലിയ പരമ്പര ഈ ലേഖനം തുടരുന്നു.

"നിങ്ങൾ ഒരു പ്ലാൻ തയ്യാറാക്കുന്നതിൽ പരാജയപ്പെട്ടാൽ, നിങ്ങൾ പരാജയപ്പെടാൻ പദ്ധതിയിടുന്നു." - ബെഞ്ചമിൻ ഫ്രാങ്ക്ലിൻ

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

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

വലിയ ചോദ്യം! എന്നിരുന്നാലും, ഈ പാണ്ടയിൽ അദ്ദേഹം പ്രത്യേകിച്ച് വിഷമിക്കുന്നതായി തോന്നുന്നില്ല ...

അരാജകത്വ പാണ്ടയിൽ കുഴപ്പമുണ്ടാക്കരുത്!

ചെറിയ ഉത്തരം: അഭ്യർത്ഥന പാതയിൽ നിർണായക സേവനങ്ങൾ ലക്ഷ്യമിടുന്നു.

ദൈർഘ്യമേറിയതും എന്നാൽ വ്യക്തമായതുമായ ഉത്തരം: അരാജകത്വത്തിൽ എവിടെ നിന്ന് പരീക്ഷണം തുടങ്ങണമെന്ന് മനസിലാക്കാൻ, മൂന്ന് മേഖലകൾ ശ്രദ്ധിക്കുക:

1. നോക്ക് ക്രാഷ് ചരിത്രം പാറ്റേണുകൾ തിരിച്ചറിയുക;
2. തീരുമാനിക്കാൻ നിർണായക ആശ്രിതത്വങ്ങൾ;
3. വിളിക്കപ്പെടുന്നവ ഉപയോഗിക്കുക അമിത ആത്മവിശ്വാസ പ്രഭാവം.

ഇത് തമാശയാണ്, പക്ഷേ ഈ ഭാഗം വളരെ എളുപ്പത്തിൽ വിളിക്കാം "സ്വയം കണ്ടെത്തലിലേക്കും പ്രബുദ്ധതയിലേക്കുമുള്ള ഒരു യാത്ര". അതിൽ ഞങ്ങൾ ചില രസകരമായ ഉപകരണങ്ങൾ ഉപയോഗിച്ച് "കളിക്കാൻ" തുടങ്ങും.

1. ഉത്തരം ഭൂതകാലത്തിലാണ്

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

"വർത്തമാനകാലം മനസിലാക്കാൻ, നിങ്ങൾ ഭൂതകാലത്തെ അറിയേണ്ടതുണ്ട്." - കാൾ സാഗൻ

പരാജയങ്ങളുടെ ചരിത്രം നോക്കുക, അവയെ COE അല്ലെങ്കിൽ പോസ്റ്റ്‌മോർട്ടത്തിൽ ടാഗ് ചെയ്ത് തരംതിരിക്കുക. പലപ്പോഴും പ്രശ്‌നങ്ങളിലേക്ക് നയിക്കുന്ന പൊതുവായ പാറ്റേണുകൾ തിരിച്ചറിയുക, ഓരോ COE-നും ഇനിപ്പറയുന്ന ചോദ്യം സ്വയം ചോദിക്കുക:

"ഇത് പ്രവചിക്കാൻ കഴിയുമോ, അതിനാൽ തെറ്റായ കുത്തിവയ്പ്പ് വഴി തടയാനാകുമോ?"

എന്റെ കരിയറിന്റെ തുടക്കത്തിലെ ഒരു പരാജയം ഞാൻ ഓർക്കുന്നു. ഞങ്ങൾ കുറച്ച് ലളിതമായ അരാജകത്വ പരീക്ഷണങ്ങൾ നടത്തിയിരുന്നെങ്കിൽ ഇത് എളുപ്പത്തിൽ തടയാമായിരുന്നു:

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

എന്നിരുന്നാലും, കുറച്ച് സമയത്തേക്ക് എല്ലാം ശരിയായിരുന്നു.

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

പെട്ടെന്ന്, മറ്റെല്ലാ സംഭവങ്ങളും ആരോഗ്യ പരിശോധനയിൽ പരാജയപ്പെടാൻ തുടങ്ങി.

ഒരു പുതിയ ഉദാഹരണം ആരംഭിക്കുന്നതിന്, പാക്കേജുകൾ ഡൗൺലോഡ് ചെയ്യുകയും ഇൻസ്റ്റാൾ ചെയ്യുകയും ചെയ്യേണ്ടതുണ്ട്, കൂടാതെ ഓട്ടോസ്‌കേലിംഗ് ഗ്രൂപ്പിൽ അവ പ്രവർത്തനരഹിതമാക്കാൻ ELB എടുത്തതിനേക്കാൾ കൂടുതൽ സമയമെടുത്തു. താമസിയാതെ മുഴുവൻ പ്രക്രിയയും ഒരു നിർണായക ഘട്ടത്തിലെത്തുകയും ആപ്ലിക്കേഷൻ തകരാറിലാവുകയും ചെയ്തുവെന്ന് വ്യക്തമാണ്.

അപ്പോൾ ഞങ്ങൾ ഇനിപ്പറയുന്ന പോയിന്റുകൾ എന്നെന്നേക്കുമായി മനസ്സിലാക്കി:

• ഒരു പുതിയ ഉദാഹരണം സൃഷ്‌ടിക്കുമ്പോൾ സോഫ്‌റ്റ്‌വെയർ ഇൻസ്റ്റാളുചെയ്യുന്നതിന് വളരെയധികം സമയമെടുക്കും; മാറ്റമില്ലാത്ത സമീപനത്തിന് മുൻഗണന നൽകുന്നതാണ് നല്ലത്. ഗോൾഡൻ എഎംഐ.
• ബുദ്ധിമുട്ടുള്ള സാഹചര്യങ്ങളിൽ, ആരോഗ്യ പരിശോധനകൾക്കും ELB-കൾക്കുമുള്ള പ്രതികരണങ്ങൾ മുൻഗണന നൽകണം - നിങ്ങൾ ആഗ്രഹിക്കുന്ന അവസാന കാര്യം ശേഷിക്കുന്ന സന്ദർഭങ്ങളിൽ ജീവിതം സങ്കീർണ്ണമാക്കുക എന്നതാണ്.
• ആരോഗ്യ പരിശോധനകളുടെ ലോക്കൽ കാഷിംഗ് വളരെയധികം സഹായിക്കുന്നു (കുറച്ച് നിമിഷങ്ങൾ പോലും).
• ബുദ്ധിമുട്ടുള്ള സാഹചര്യത്തിൽ, ക്രോൺ ടാസ്ക്കുകളും മറ്റ് നിർണ്ണായകമല്ലാത്ത പ്രക്രിയകളും പ്രവർത്തിപ്പിക്കരുത് - ഏറ്റവും പ്രധാനപ്പെട്ട ജോലികൾക്കായി വിഭവങ്ങൾ സംരക്ഷിക്കുക.
• ഓട്ടോസ്‌കേലിംഗ് ചെയ്യുമ്പോൾ, ചെറിയ സന്ദർഭങ്ങൾ ഉപയോഗിക്കുക. 10 ചെറിയ മാതൃകകളുടെ ഒരു ഗ്രൂപ്പാണ് 4 വലിയവയുടെ ഗ്രൂപ്പിനേക്കാൾ നല്ലത്; ഒരു സംഭവം പരാജയപ്പെട്ടാൽ, ആദ്യ സന്ദർഭത്തിൽ ട്രാഫിക്കിന്റെ 10% 9 പോയിന്റിൽ വിതരണം ചെയ്യും, രണ്ടാമത്തേതിൽ - 25% ട്രാഫിക്കിൽ മൂന്ന് പോയിന്റുകൾ.

അങ്ങനെയാണെങ്കിൽ, ഇത് മുൻകൂട്ടിക്കാണാൻ കഴിയുമായിരുന്നോ, അതിനാൽ പ്രശ്നം അവതരിപ്പിച്ചുകൊണ്ട് തടയാൻ കഴിയുമോ?

ആ, കൂടാതെ പല തരത്തിൽ.

ആദ്യം, പോലുള്ള ഉപകരണങ്ങൾ ഉപയോഗിച്ച് ഉയർന്ന സിപിയു ഉപയോഗം അനുകരിക്കുന്നതിലൂടെ stress-ng അഥവാ cpuburn:

❯ stress-ng --matrix 1 -t 60s

സമ്മർദ്ദം- ng

രണ്ടാമതായി, ഉദാഹരണം ഓവർലോഡ് ചെയ്യുന്നതിലൂടെ wrk കൂടാതെ സമാനമായ മറ്റ് യൂട്ടിലിറ്റികളും:

❯ wrk -t12 -c400 -d20s http://127.0.0.1/api/health

പരീക്ഷണങ്ങൾ താരതമ്യേന ലളിതമാണ്, പക്ഷേ ഒരു യഥാർത്ഥ പരാജയത്തിന്റെ സമ്മർദ്ദത്തിലൂടെ കടന്നുപോകാതെ തന്നെ ചിന്തയ്ക്ക് നല്ല ഭക്ഷണം നൽകാൻ കഴിയും.

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

ഇതൊരു സ്വപ്നമായിരുന്നോ, അതോ ശരിക്കും സംഭവിച്ചതാണോ?

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

തുടർന്ന് ഏറ്റവും വലിയ ശ്രേണിയിലുള്ള ഏറ്റവും സാധാരണമായ പാറ്റേണുകളിലേക്ക് മാറുക.

2. ഒരു ഡിപൻഡൻസി മാപ്പ് നിർമ്മിക്കുക

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

നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ കോഡ് നിങ്ങൾക്ക് അത്ര പരിചിതമല്ലെങ്കിലോ അത് വളരെ വലുതായാലോ, കോഡ് എന്താണ് ചെയ്യുന്നതെന്നും അതിന്റെ ഡിപൻഡൻസികൾ എന്താണെന്നും മനസ്സിലാക്കാൻ ബുദ്ധിമുട്ടായിരിക്കും. ഈ ഡിപൻഡൻസികളും ആപ്ലിക്കേഷനിലും ഉപയോക്താക്കളിലും അവയ്ക്ക് സാധ്യമായ ആഘാതവും മനസ്സിലാക്കുന്നത് ചായോസ് എഞ്ചിനീയറിംഗ് എവിടെ നിന്ന് ആരംഭിക്കണമെന്ന് അറിയാൻ പ്രധാനമാണ്: ഏറ്റവും വലിയ ആഘാത ദൂരമുള്ള ഘടകമാണ് ആരംഭ പോയിന്റ്.

ഡിപൻഡൻസികൾ തിരിച്ചറിയുകയും രേഖപ്പെടുത്തുകയും ചെയ്യുന്നതിനെ വിളിക്കുന്നു "ഒരു ഡിപൻഡൻസി മാപ്പ് നിർമ്മിക്കുന്നു» (ആശ്രിതത്വ മാപ്പിംഗ്). കോഡ് പ്രൊഫൈലിംഗ് ടൂളുകൾ ഉപയോഗിച്ച് വലിയ കോഡ് ബേസ് ഉള്ള ആപ്ലിക്കേഷനുകൾക്കാണ് ഇത് സാധാരണയായി ചെയ്യുന്നത്. (കോഡ് പ്രൊഫൈലിംഗ്) ഇൻസ്ട്രുമെന്റേഷനും (ഉപകരണങ്ങൾ). നെറ്റ്‌വർക്ക് ട്രാഫിക് നിരീക്ഷിച്ച് നിങ്ങൾക്ക് ഒരു മാപ്പ് നിർമ്മിക്കാനും കഴിയും.

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

നിർണായകമായ ആശ്രിതത്വങ്ങളില്ലാതെ, സേവനം പ്രവർത്തിക്കില്ല. നിർണ്ണായകമല്ലാത്ത ആശ്രിതത്വങ്ങൾ "പാടില്ല» വീഴ്ച സംഭവിച്ചാൽ സേവനത്തെ സ്വാധീനിക്കാൻ. ഡിപൻഡൻസികൾ മനസിലാക്കാൻ, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ഉപയോഗിക്കുന്ന API-കളെ കുറിച്ച് നിങ്ങൾക്ക് വ്യക്തമായ ധാരണ ഉണ്ടായിരിക്കണം. ഇത് തോന്നുന്നതിനേക്കാൾ വളരെ ബുദ്ധിമുട്ടാണ് - കുറഞ്ഞത് വലിയ ആപ്ലിക്കേഷനുകൾക്കെങ്കിലും.

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

പോലുള്ള പ്രോഗ്രാമുകൾ നിങ്ങൾക്ക് ഉപയോഗിക്കാം netstat - സിസ്റ്റത്തിലെ എല്ലാ നെറ്റ്‌വർക്ക് കണക്ഷനുകളുടെയും (സജീവ സോക്കറ്റുകൾ) ഒരു ലിസ്റ്റ് പ്രദർശിപ്പിക്കുന്ന ഒരു കമാൻഡ് ലൈൻ യൂട്ടിലിറ്റി. ഉദാഹരണത്തിന്, നിലവിലുള്ള എല്ലാ കണക്ഷനുകളും ലിസ്റ്റുചെയ്യാൻ, ടൈപ്പ് ചെയ്യുക:

❯ netstat -a | more 

AWS-ൽ നിങ്ങൾക്ക് ഉപയോഗിക്കാം ഒഴുക്ക് രേഖകൾ (ഫ്ലോ ലോഗുകൾ) VPC-യിലെ നെറ്റ്‌വർക്ക് ഇന്റർഫേസുകളിലേക്കോ അതിൽ നിന്നോ പോകുന്ന ഐപി ട്രാഫിക്കിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ശേഖരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു രീതിയാണ് VPC. അത്തരം ലോഗുകൾക്ക് മറ്റ് ജോലികൾക്കും സഹായിക്കാനാകും - ഉദാഹരണത്തിന്, ചില ട്രാഫിക്ക് ഈ സംഭവത്തിലേക്ക് എത്താത്തത് എന്തുകൊണ്ടെന്ന ചോദ്യത്തിന് ഉത്തരം കണ്ടെത്തുക.

നിങ്ങൾക്ക് ഉപയോഗിക്കാനും കഴിയും AWS എക്സ്-റേ. എക്സ്-റേ നിങ്ങളെ വിശദമായി, "ആത്യന്തികമായി" ലഭിക്കാൻ അനുവദിക്കുന്നു (അവസാനം മുതൽ അവസാനം വരെ) ആപ്ലിക്കേഷനിലൂടെ നീങ്ങുമ്പോൾ അഭ്യർത്ഥനകളുടെ അവലോകനം, കൂടാതെ ആപ്ലിക്കേഷന്റെ അടിസ്ഥാന ഘടകങ്ങളുടെ ഒരു മാപ്പ് നിർമ്മിക്കുകയും ചെയ്യുന്നു. നിങ്ങൾക്ക് ഡിപൻഡൻസികൾ തിരിച്ചറിയണമെങ്കിൽ വളരെ സൗകര്യപ്രദമാണ്.

AWS എക്സ്-റേ കൺസോൾ

നെറ്റ്‌വർക്ക് ഡിപൻഡൻസി മാപ്പ് ഒരു ഭാഗിക പരിഹാരം മാത്രമാണ്. അതെ, ഏത് ആപ്ലിക്കേഷനുമായി ആശയവിനിമയം നടത്തുന്നുവെന്ന് ഇത് കാണിക്കുന്നു, എന്നാൽ മറ്റ് ഡിപൻഡൻസികളും ഉണ്ട്.

പല ആപ്ലിക്കേഷനുകളും ഡിപൻഡൻസികളിലേക്ക് കണക്റ്റുചെയ്യാൻ DNS ഉപയോഗിക്കുന്നു, മറ്റുള്ളവ കോൺഫിഗറേഷൻ ഫയലുകളിൽ സേവന കണ്ടെത്തൽ അല്ലെങ്കിൽ ഹാർഡ്-കോഡ് ചെയ്ത IP വിലാസങ്ങൾ ഉപയോഗിച്ചേക്കാം (ഉദാ. /etc/hosts).

ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് സൃഷ്ടിക്കാൻ കഴിയും DNS ബ്ലാക്ക്‌ഹോൾ സഹായത്തോടെ iptables എന്താണ് തകർക്കുന്നതെന്ന് കാണുക. ഇത് ചെയ്യുന്നതിന്, ഇനിപ്പറയുന്ന കമാൻഡ് നൽകുക:

❯ iptables -I OUTPUT -p udp --dport 53 -j REJECT -m comment --comment "Reject DNS"

DNS തമോദ്വാരം

ഉള്ളിലാണെങ്കിൽ /etc/hosts അല്ലെങ്കിൽ മറ്റ് കോൺഫിഗറേഷൻ ഫയലുകൾ, നിങ്ങൾക്ക് ഒന്നും അറിയാത്ത IP വിലാസങ്ങൾ നിങ്ങൾ കണ്ടെത്തും (അതെ, നിർഭാഗ്യവശാൽ, ഇതും സംഭവിക്കുന്നു), നിങ്ങൾക്ക് വീണ്ടും രക്ഷാപ്രവർത്തനത്തിലേക്ക് വരാം iptables. നിങ്ങൾ കണ്ടെത്തി എന്ന് പറയാം 8.8.8.8 ഇത് Google-ന്റെ പൊതു DNS സെർവർ വിലാസമാണെന്ന് അറിയില്ല. ഉപയോഗിച്ച് iptables ഇനിപ്പറയുന്ന കമാൻഡുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഈ വിലാസത്തിലേക്കുള്ള ഇൻകമിംഗ്, ഔട്ട്ഗോയിംഗ് ട്രാഫിക് തടയാൻ കഴിയും:

❯ iptables -A INPUT -s 8.8.8.8 -j DROP -m comment --comment "Reject from 8.8.8.8"
❯ iptables -A OUTPUT -d 8.8.8.8 -j DROP -m comment --comment "Reject to 8.8.8.8"

പ്രവേശനം അടയ്ക്കുന്നു

Google-ന്റെ പൊതു DNS-ൽ നിന്നുള്ള എല്ലാ പാക്കറ്റുകളും ആദ്യ നിയമം ഉപേക്ഷിക്കുന്നു: ping പ്രവർത്തിക്കുന്നു, പക്ഷേ പാക്കറ്റുകൾ തിരികെ നൽകുന്നില്ല. രണ്ടാമത്തെ നിയമം നിങ്ങളുടെ സിസ്റ്റത്തിൽ നിന്ന് ഉത്ഭവിക്കുന്ന എല്ലാ പാക്കറ്റുകളും Google-ന്റെ പൊതു DNS-ലേക്ക് ഡ്രോപ്പ് ചെയ്യുന്നു ping നമുക്ക് ലഭിക്കുന്നു ഈ പ്രവർത്തനം അനുവദിച്ചിട്ടില്ല.

ശ്രദ്ധിക്കുക: ഈ പ്രത്യേക സാഹചര്യത്തിൽ അത് ഉപയോഗിക്കുന്നതാണ് നല്ലത് whois 8.8.8.8, എന്നാൽ ഇത് ഒരു ഉദാഹരണം മാത്രമാണ്.

നമുക്ക് മുയൽ ദ്വാരത്തിലേക്ക് കൂടുതൽ ആഴത്തിൽ പോകാം, കാരണം ടിസിപിയും യുഡിപിയും ഉപയോഗിക്കുന്ന എല്ലാം യഥാർത്ഥത്തിൽ ഐപിയെയും ആശ്രയിച്ചിരിക്കുന്നു. മിക്ക കേസുകളിലും, IP ARP-യുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു. ഫയർവാളുകളെ കുറിച്ച് മറക്കരുത്...

നിങ്ങൾ ചുവന്ന ഗുളിക കഴിക്കുകയാണെങ്കിൽ, നിങ്ങൾ വണ്ടർലാൻഡിൽ തുടരും, മുയലിന്റെ ദ്വാരം എത്ര ആഴത്തിൽ പോകുന്നുവെന്ന് ഞാൻ കാണിച്ചുതരാം.

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

ഒരു ഡിപൻഡൻസി മാപ്പ് നിർമ്മിക്കുന്നത് പലപ്പോഴും വളരെ ദൈർഘ്യമേറിയ കാര്യമാണ്. നൂറുകണക്കിന് മൈക്രോസർവീസുകൾക്കും കമാൻഡുകൾക്കുമായി സെമി-ഓട്ടോമാറ്റിക്കായി ഡിപൻഡൻസി മാപ്പുകൾ സൃഷ്ടിക്കുന്ന ഒരു ടൂൾ വികസിപ്പിക്കുന്നതിന് ഏകദേശം 2 വർഷം ചെലവഴിച്ച ഒരു ക്ലയന്റുമായി ഞാൻ അടുത്തിടെ സംസാരിച്ചു.

എന്നിരുന്നാലും, ഫലം വളരെ രസകരവും ഉപയോഗപ്രദവുമാണ്. നിങ്ങളുടെ സിസ്റ്റത്തെക്കുറിച്ചും അതിന്റെ ഡിപൻഡൻസികളെക്കുറിച്ചും പ്രവർത്തനങ്ങളെക്കുറിച്ചും നിങ്ങൾ ധാരാളം പഠിക്കും. വീണ്ടും, ക്ഷമയോടെയിരിക്കുക: യാത്രയാണ് ഏറ്റവും പ്രധാനം.

3. അമിത ആത്മവിശ്വാസം സൂക്ഷിക്കുക

"ആരെങ്കിലും എന്തിനെക്കുറിച്ചാണ് സ്വപ്നം കാണുന്നത്, അതിൽ വിശ്വസിക്കുന്നു." - ഡെമോസ്തനീസ്

നിങ്ങൾ എപ്പോഴെങ്കിലും കേട്ടിട്ടുണ്ടോ അമിത ആത്മവിശ്വാസ പ്രഭാവം?

വിക്കിപീഡിയ പറയുന്നതനുസരിച്ച്, അമിതമായ ആത്മവിശ്വാസത്തിന്റെ പ്രഭാവം "ഒരു വ്യക്തിയുടെ പ്രവർത്തനങ്ങളിലും തീരുമാനങ്ങളിലും ഉള്ള ആത്മവിശ്വാസം ആ വിധികളുടെ വസ്തുനിഷ്ഠമായ കൃത്യതയേക്കാൾ വളരെ കൂടുതലാണ്, പ്രത്യേകിച്ചും ആത്മവിശ്വാസത്തിന്റെ തോത് താരതമ്യേന ഉയർന്നതാണെങ്കിൽ".

സഹജാവബോധത്തിന്റെയും അനുഭവത്തിന്റെയും അടിസ്ഥാനത്തിൽ...

എന്റെ അനുഭവത്തിൽ, ഈ വക്രീകരണം കുഴപ്പം എഞ്ചിനീയറിംഗ് എവിടെ തുടങ്ങണം എന്നതിന്റെ ഒരു വലിയ സൂചനയാണ്.

അമിത ആത്മവിശ്വാസമുള്ള ഓപ്പറേറ്ററെ സൂക്ഷിക്കുക:

ചാർലി: "അഞ്ച് വർഷമായി ഈ കാര്യം വീണില്ല, എല്ലാം ശരിയാണ്!"
ക്രാഷ്: "കാത്തിരിക്കൂ... ഞാൻ ഉടൻ അവിടെയെത്തും!"

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

സംഗ്രഹിക്കുന്നു

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

ഇത് രണ്ടാം ഭാഗം അവസാനിക്കുന്നു. ദയവായി അവലോകനങ്ങൾ എഴുതുക, അഭിപ്രായങ്ങൾ പങ്കിടുക അല്ലെങ്കിൽ കൈയ്യടിക്കുക മീഡിയം. അടുത്ത ഭാഗത്തിൽ ഐ ശരിക്കും സിസ്റ്റങ്ങളിൽ പരാജയങ്ങൾ അവതരിപ്പിക്കുന്നതിനുള്ള ഉപകരണങ്ങളും രീതികളും ഞാൻ പരിഗണിക്കും. വരുവോളം!

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «ചാവോസ് എഞ്ചിനീയറിംഗ്: ബോധപൂർവ്വം നശിപ്പിക്കുന്ന കല. ഭാഗം 1";
• «കുബർനെറ്റസിൽ ഉയർന്ന ലഭ്യത എങ്ങനെ നേടാം";
• «നിരീക്ഷണവും കുബർനെറ്റസും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• «Kubernetes-ൽ kube-proxy, node ലഭ്യത എന്നിവ പരീക്ഷിക്കുന്നു".

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