Откривање апликации што паѓаат веднаш по објавувањето

На 25 септември три објавувања беа означени како успешни иако API-то на апликацијата паѓаше неколку секунди по секое стартување. Бидејќи „успеаја“, не се изврши враќање назад; позадинска проверка ги означи како неуспешни неколку минути подоцна, а целата страница падна на 404. Проверката на здравјето ги броеше паѓањата во листата на настани на хостинг платформата — која секогаш ги содржи само последните пет настани по машина, па јамката на паѓања ја полни листата и бројот никогаш не расте. Сега ја споредува времето на најновото паѓање, а објавување со јамка на паѓања пропаѓа и ја враќа претходната верзија.

Што чека објавувањето

Кога објавувате апликација со backend на Mythex, новата верзија се распоредува на машините на нашата хостинг платформа, а проверка на здравјето одлучува дали објавувањето успеало. Ако не успеало, враќањето ја враќа претходната верзија.

Тешкиот дел е тоа што „стартувано“ не е исто што „служи“. Платформата ја пријавува машината како стартувана штом е во работа. Апликација што паѓа една секунда по стартувањето се рестартира веднаш, и за миг повторно се чита како стартувана. Затоа проверката на здравјето со текот на времето доби неколку слоеви:

1. Погледни двапати. Откако машината ќе се прочита како стартувана, почекај малку и погледни повторно. Паѓање при стартување често го пропаѓа второто гледање.
2. Следи јамки на паѓања. Ако платформата пријави дека машината паѓала постојано и дека престанала да ја рестартира, пропадни.
3. Броење паѓања од почетокот на објавувањето. Две „стартувано“ гледања може да се протегаат преку рестартирање. Значи, ако се случило каква било паѓање од почетокот на објавувањето, погледни трет пат; ако има повеќе паѓања отколку при претходното гледање, апликацијата не останува во работа.

Третата проверка е онаа што откажа овде.

Зошто бројот остана ист

Информациите за паѓања доаѓаат од листата на настани на секоја машина: стартувања, излегувања, рестартирања. Платформата чува само последните пет настани по машина.

Замислете апликација што паѓа 2,5 секунди по секое стартување, како една од нив. Секој циклус додава паѓање и стартување. После неколку циклуси, листата е полна. Од тогаш, секој нов настан турка стар надвор. Листата се лизга напред, но секогаш ја содржи приближно истата мешавина: неколку паѓања, неколку стартувања.

Значи „колку паѓања од почетокот на објавувањето“ враќаше ист број при секое гледање. Второто гледање виде, да речеме, две паѓања. Третото гледање виде исто така две — различни паѓања, но ист број. Проверката заклучи дека паѓањата запреле и го пропушти објавувањето.

Се случи три пати на 25 септември, кај две апликации. Секој пат:

• објавувањето беше означено како активно,
• не се изврши враќање назад, бидејќи ништо не беше пријавено како неуспешно,
• нашиот reconciler, позадинска задача што ги проверува распоредувањата по фактот, го пропадна распоредувањето неколку минути подоцна,
• и целата страница се врати на 404.

Објавување што пропаѓа на време може да се поправи: враќањето ја враќа претходната верзија. Објавување што пропаѓа неколку минути задоцнето, откако е прогласено за успех, веќе го прескокнало враќањето назад.

Како го најдовме

Го реплициравме локално: земовме работечко API, го пуштивме да заспие, па го објавивме повторно со промена што паѓа при стартување. Проверката на здравјето го означи како активно.

Тоа одговараше на продукцијата: во секое од трите објавувања, апликацијата умираше неколку секунди по секое стартување, а бројот на паѓања што проверката го споредуваше никогаш не растеше помеѓу гледањата.

Поправката: споредете го најновото паѓање, не бројот

Наместо да броиме паѓања, проверката сега го гледа времето на најновото паѓање од почетокот на објавувањето.

Ако второто гледање покаже каква било паѓање од почетокот на објавувањето, проверката чека и гледа трет пат. Ако најновото паѓање на третото гледање е подоцна од најновото на второто, машината повторно паднала помеѓу. Таа не останува во работа, а објавувањето пропаѓа со порака дека машината паѓала постојано од објавувањето и сè уште се рестартира.

Ова работи без оглед колку е кратка листата на настани. Лизгачки прозорец од пет настани може да го сокрие бројот на паѓања, но не може да го сокрие тоа дека управо се случило ново — најновиот настан е секогаш оној што останува.

Со оваа промена, локалната реплика се однесува правилно: објавувањето пропаѓа, а претходната слика се враќа. Постои и тест што го симулира однесувањето на платформата — секое гледање додава паѓање и стартување и ја сече листата на пет — и проверува дека резултатот е неуспех, а не успех.

Што извлековме

• Знајте ја формата на податоците што ги броите. Броењето во ограничена листа престанува да значи нешто штом листата е полна. Ограничувањето не било скриено; едноставно не ја дизајниравме проверката околу него.
• Претпочитајте „се случи ли нешто ново?“ наспроти „колку се случиле?“ Најновата временска ознака преживува скратување. Вкупниот број не.
• Задоцнет неуспех е полош од рано. Истата расипана верзија е безопасна ако објавувањето пропадне и се врати назад, а ја урива страницата ако прво е прогласена за успех.
• Реплицирајте со вистинските услови. Багот бараше машина што веќе паднала доволно пати за да ја наполни листата на настани. Едно брзо паѓање во тест не би го покажало.

Оваа поправка се надополнува со друга од истиот ден, која осигураше дека враќањето ја враќа старата верзија наместо да ја избрише: неуспешното повторно објавување никогаш не брише работечки backend. Ако вашата апликација не се објавува бидејќи паѓа при стартување, документацијата за решавање проблеми при објавување и нашиот водич за поправање апликација направена со AI се добри места за почеток.