പബ്ലിഷ് ചെയ്ത ഉടൻ ക്രാഷ് ആകുന്ന ആപ്പുകളെ പിടികൂടുക

സെപ്റ്റംബർ 25-ന് മൂന്ന് പബ്ലിഷുകൾ വിജയകരമെന്ന് അടയാളപ്പെടുത്തി, എന്നിട്ടും അവയുടെ ആപ്പ് API ഓരോ boot-ലും സെക്കൻഡുകൾക്കകം ക്രാഷ് ആയിക്കൊണ്ടിരുന്നു. പബ്ലിഷ് "വിജയിച്ചതിനാൽ" rollback പ്രവർത്തിച്ചില്ല; മിനിറ്റുകൾക്ക് ശേഷം ഒരു പശ്ചാത്തല പരിശോധന അവയെ പരാജയപ്പെടുത്തി, മുഴുവൻ സൈറ്റും 404 ആയി. Health check ക്രാഷുകൾ എണ്ണിയത് hosting പ്ലാറ്റ്‌ഫോമിന്റെ ഇവന്റ് പട്ടികയിൽ ആയിരുന്നു — ഓരോ machine-നും അവസാന അഞ്ച് ഇവന്റുകൾ മാത്രമേ അതിൽ ഉണ്ടാകൂ, അതിനാൽ ക്രാഷ് ലൂപ്പ് ഉണ്ടായാൽ പട്ടിക നിറഞ്ഞിരിക്കും, എണ്ണം ഒരിക്കലും കൂടില്ല. ഇപ്പോൾ അത് പകരം ഏറ്റവും പുതിയ ക്രാഷിന്റെ സമയം താരതമ്യം ചെയ്യുന്നു, ക്രാഷ് ലൂപ്പ് ചെയ്യുന്ന പബ്ലിഷ് പരാജയപ്പെടുകയും മുമ്പത്തെ പതിപ്പ് പുനഃസ്ഥാപിക്കുകയും ചെയ്യുന്നു.

ഒരു പബ്ലിഷ് എന്തിനായി കാത്തിരിക്കുന്നു

Backend ഉള്ള ഒരു ആപ്പ് Mythex-ൽ പബ്ലിഷ് ചെയ്യുമ്പോൾ, പുതിയ പതിപ്പ് ഞങ്ങളുടെ hosting പ്ലാറ്റ്‌ഫോമിലെ machines-ലേക്ക് വിന്യസിക്കപ്പെടുന്നു, പബ്ലിഷ് ലൈവായോ പരാജയപ്പെട്ടോ എന്ന് ഒരു health check തീരുമാനിക്കുന്നു. പരാജയപ്പെട്ടാൽ rollback മുമ്പത്തെ പതിപ്പ് തിരികെ കൊണ്ടുവരുന്നു.

ബുദ്ധിമുട്ടുള്ള കാര്യം, "തുടങ്ങി" എന്നത് "സേവനം നൽകുന്നു" എന്നതിന് തുല്യമല്ല എന്നതാണ്. Machine ഉയർന്നാലുടൻ പ്ലാറ്റ്‌ഫോം അതിനെ started എന്ന് റിപ്പോർട്ട് ചെയ്യുന്നു. Boot ആയി ഒരു സെക്കൻഡിൽ ക്രാഷ് ആകുന്ന ആപ്പ് ഉടൻ പുനരാരംഭിക്കപ്പെടുന്നു, ഒരു നിമിഷത്തിനുശേഷം അത് വീണ്ടും started എന്ന് വായിക്കപ്പെടുന്നു. അതിനാൽ health check കാലക്രമേണ പല പാളികൾ ചേർത്തിരുന്നു:

1. രണ്ടുതവണ നോക്കുക. Machine started എന്ന് വായിക്കപ്പെട്ടതിന് ശേഷം, ചെറുതായി കാത്തിരുന്ന് വീണ്ടും നോക്കുന്നു. Boot-ൽ ഉണ്ടാകുന്ന ക്രാഷ് പലപ്പോഴും രണ്ടാമത്തെ നോട്ടത്തിൽ പരാജയം കാണിക്കും.
2. ക്രാഷ് ലൂപ്പുകൾ ശ്രദ്ധിക്കുക. ഒരു machine ആവർത്തിച്ച് ക്രാഷ് ആയെന്നും പുനരാരംഭിക്കുന്നത് പ്ലാറ്റ്‌ഫോം ഉപേക്ഷിച്ചെന്നും റിപ്പോർട്ട് ചെയ്താൽ, പരാജയപ്പെടുക.
3. പബ്ലിഷ് തുടങ്ങിയതിന് ശേഷമുള്ള ക്രാഷുകൾ എണ്ണുക. രണ്ട് "started" നോട്ടങ്ങൾ ഒരു restart-നെ ഇടയിൽ പിടിച്ചേക്കാം. അതിനാൽ ഈ പബ്ലിഷ് തുടങ്ങിയ ശേഷം ഏതെങ്കിലും ക്രാഷ് സംഭവിച്ചിട്ടുണ്ടെങ്കിൽ മൂന്നാമതും നോക്കുന്നു; മുമ്പത്തെ നോട്ടത്തേക്കാൾ കൂടുതൽ ക്രാഷുകൾ ഉണ്ടെങ്കിൽ ആപ്പ് നിലനിൽക്കുന്നില്ല.

ഇവിടെ പരാജയപ്പെട്ടത് മൂന്നാമത്തെ പരിശോധനയാണ്.

എണ്ണം നിശ്ചലമായി നിന്നത് എന്തുകൊണ്ട്

ക്രാഷ് വിവരം വരുന്നത് ഓരോ machine-ന്റെയും ഇവന്റ് പട്ടികയിൽ നിന്നാണ്: starts, exits, restarts. പ്ലാറ്റ്‌ഫോം ഓരോ machine-നും അവസാനത്തെ അഞ്ച് ഇവന്റുകൾ മാത്രമേ സൂക്ഷിക്കൂ.

ഓരോ boot-ലും 2.5 സെക്കൻഡിൽ ക്രാഷ് ആകുന്ന ഒരു ആപ്പ് സങ്കൽപ്പിക്കുക, അവയിലൊന്ന് ചെയ്തതുപോലെ. ഓരോ സൈക്കിളും ഒരു ക്രാഷും ഒരു start-ഉം ചേർക്കുന്നു. ഏതാനും സൈക്കിളുകൾക്ക് ശേഷം പട്ടിക നിറയുന്നു. അതിനുശേഷം പുതിയ ഓരോ ഇവന്റും ഒരു പഴയ ഇവന്റിനെ പുറത്താക്കുന്നു. പട്ടിക മുന്നോട്ട് നീങ്ങുന്നു, പക്ഷേ എപ്പോഴും ഏകദേശം ഒരേ മിശ്രിതമാണ് കാണിക്കുന്നത്: രണ്ട് ക്രാഷുകൾ, രണ്ട് starts.

അതുകൊണ്ട് "പബ്ലിഷ് തുടങ്ങിയതിന് ശേഷം എത്ര ക്രാഷുകൾ" എന്നത് ഓരോ നോട്ടത്തിലും ഒരേ സംഖ്യ തിരികെ നൽകി. രണ്ടാമത്തെ നോട്ടം, ഉദാഹരണത്തിന്, രണ്ട് ക്രാഷുകൾ കണ്ടു. മൂന്നാമത്തെ നോട്ടവും രണ്ട് കണ്ടു — വ്യത്യസ്ത ക്രാഷുകളാണെങ്കിലും എണ്ണം ഒന്നുതന്നെ. ക്രാഷിംഗ് നിന്നുപോയി എന്ന് പരിശോധന നിഗമനം ചെയ്തു, പബ്ലിഷ് കടത്തിവിട്ടു.

സെപ്റ്റംബർ 25-ന് ഇത് മൂന്ന് തവണ സംഭവിച്ചു, രണ്ട് ആപ്പുകളിൽ. ഓരോ തവണയും:

• പബ്ലിഷ് ലൈവ് ആയി അടയാളപ്പെടുത്തി,
• ഒന്നും പരാജയപ്പെട്ടില്ലാത്തതിനാൽ rollback പ്രവർത്തിച്ചില്ല,
• ഞങ്ങളുടെ reconciler — പിന്നീട് deployments പരിശോധിക്കുന്ന ഒരു പശ്ചാത്തല ജോലി — മിനിറ്റുകൾക്ക് ശേഷം deployment പരാജയപ്പെടുത്തി,
• മുഴുവൻ സൈറ്റും 404 തിരികെ നൽകി.

സമയത്ത് പരാജയപ്പെടുന്ന ഒരു പബ്ലിഷ് വീണ്ടെടുക്കാവുന്നതാണ്: rollback മുമ്പത്തെ പതിപ്പ് തിരികെ കൊണ്ടുവരുന്നു. വിജയമെന്ന് പ്രഖ്യാപിച്ചതിന് ശേഷം മിനിറ്റുകൾക്ക് പിന്നീട് പരാജയപ്പെടുന്ന പബ്ലിഷ് ഇതിനകം അതിന്റെ rollback ഒഴിവാക്കിയിരിക്കുന്നു.

ഞങ്ങൾ ഇത് എങ്ങനെ കണ്ടെത്തി

ഞങ്ങൾ പ്രാദേശികമായി ഇത് പുനഃസൃഷ്ടിച്ചു: പ്രവർത്തിക്കുന്ന ഒരു API എടുത്ത്, അത് ഉറങ്ങാൻ വിട്ട്, boot-ൽ ക്രാഷ് ചെയ്യുന്ന ഒരു മാറ്റത്തോടെ വീണ്ടും പബ്ലിഷ് ചെയ്തു. Health check അതിനെ ലൈവായി അടയാളപ്പെടുത്തി.

ഇത് പ്രൊഡക്ഷനുമായി പൊരുത്തപ്പെട്ടു: മൂന്ന് പബ്ലിഷുകളിലും ആപ്പ് ഓരോ boot-ലും സെക്കൻഡുകൾക്കകം മരിച്ചു, എന്നിട്ടും പരിശോധന താരതമ്യം ചെയ്ത ക്രാഷ് എണ്ണം നോട്ടങ്ങൾക്കിടയിൽ ഒരിക്കലും കൂടിയില്ല.

പരിഹാരം: എണ്ണമല്ല, ഏറ്റവും പുതിയ ക്രാഷ് താരതമ്യം ചെയ്യുക

ക്രാഷുകൾ എണ്ണുന്നതിന് പകരം, പരിശോധന ഇപ്പോൾ പബ്ലിഷ് തുടങ്ങിയതിന് ശേഷമുള്ള ഏറ്റവും പുതിയ ക്രാഷിന്റെ സമയം നോക്കുന്നു.

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

ഇവന്റ് പട്ടിക എത്ര ചെറുതായാലും ഇത് പ്രവർത്തിക്കുന്നു. അഞ്ച് ഇവന്റുകളുള്ള ഒരു sliding window എത്ര ക്രാഷുകൾ ഉണ്ടായി എന്ന് മറയ്ക്കാം, പക്ഷേ ഒരു പുതിയ ക്രാഷ് ഇപ്പോൾ സംഭവിച്ചു എന്ന് മറയ്ക്കാനാവില്ല — ഏറ്റവും പുതിയ ഇവന്റ് എപ്പോഴും സൂക്ഷിക്കപ്പെടുന്നു.

ഈ മാറ്റത്തോടെ, പ്രാദേശിക പുനഃസൃഷ്ടി ശരിയായി പെരുമാറുന്നു: പബ്ലിഷ് പരാജയപ്പെടുന്നു, മുമ്പത്തെ image പുനഃസ്ഥാപിക്കപ്പെടുന്നു. പ്ലാറ്റ്‌ഫോമിന്റെ പെരുമാറ്റം അനുകരിക്കുന്ന ഒരു ടെസ്റ്റും ഉണ്ട് — ഓരോ നോട്ടവും ഒരു ക്രാഷും ഒരു start-ഉം ചേർക്കുകയും പട്ടിക അഞ്ചിലേക്ക് ചുരുക്കുകയും ചെയ്യുന്നു — വിധി വിജയമല്ല പരാജയമാണെന്ന് അത് ഉറപ്പാക്കുന്നു.

ഞങ്ങൾ പഠിച്ചത്

• നിങ്ങൾ എണ്ണുന്ന ഡാറ്റയുടെ ആകൃതി അറിയുക. പരിമിതമായ ഒരു പട്ടികയിലുള്ള എണ്ണം പട്ടിക നിറഞ്ഞുകഴിഞ്ഞാൽ അർത്ഥം നഷ്ടപ്പെടുന്നു. പരിധി മറച്ചുവെച്ചിരുന്നില്ല; പരിശോധന അതിനെ മുൻനിർത്തി രൂപകൽപ്പന ചെയ്തിരുന്നില്ല എന്ന് മാത്രം.
• "ഒന്നുകൂടി സംഭവിച്ചോ?" എന്നത് "എത്ര സംഭവിച്ചു?" എന്നതിനേക്കാൾ മുൻഗണന നൽകുക. ഏറ്റവും പുതിയ timestamp പട്ടിക ചുരുങ്ങുന്നതിനെ അതിജീവിക്കുന്നു. ആകെ എണ്ണം അതിജീവിക്കില്ല.
• വൈകിയുള്ള പരാജയം നേരത്തെയുള്ള പരാജയത്തേക്കാൾ മോശമാണ്. അതേ തകർന്ന build പബ്ലിഷ് പരാജയപ്പെടുകയും rollback ചെയ്യുകയുമാണെങ്കിൽ ദോഷമില്ല; ആദ്യം വിജയമെന്ന് പ്രഖ്യാപിച്ചാൽ സൈറ്റ് താഴെ വീഴ്ത്തും.
• യഥാർത്ഥ സാഹചര്യങ്ങളിൽ പുനഃസൃഷ്ടിക്കുക. ഇവന്റ് പട്ടിക നിറയാൻ വേണ്ടത്ര തവണ ഇതിനകം ക്രാഷ് ചെയ്ത ഒരു machine ആണ് ബഗിന് വേണ്ടിയിരുന്നത്. ടെസ്റ്റിലെ ഒരു ദ്രുത ക്രാഷ് ഇത് കാണിക്കില്ലായിരുന്നു.

അതേ ദിവസം മറ്റൊരു പരിഹാരം ഇതുമായി ചേരുന്നു: ഒരു പരാജയപ്പെട്ട republish ഒരിക്കലും പ്രവർത്തിക്കുന്ന backend ഇല്ലാതാക്കുന്നില്ല എന്ന് ഉറപ്പാക്കിയ മാറ്റം: ഒരു പരാജയപ്പെട്ട republish ഒരിക്കലും പ്രവർത്തിക്കുന്ന backend ഇല്ലാതാക്കുന്നില്ല. നിങ്ങളുടെ സ്വന്തം ആപ്പ് start ചെയ്യുമ്പോൾ ക്രാഷ് ആകുന്നതിനാൽ പബ്ലിഷ് പരാജയപ്പെടുന്നുവെങ്കിൽ, publish troubleshooting docs ഉം AI നിർമ്മിച്ച ആപ്പ് debug ചെയ്യുന്നതിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ guide ഉം നല്ല തുടക്കങ്ങളാണ്.