Zachytávanie aplikácií, ktoré spadnú hneď po publikovaní

1. septembra boli tri publikovania označené ako úspešné, hoci API aplikácie pri každom štarte spadlo už po sekundách. Keďže sa „podarili“, nespustil sa rollback; o niekoľko minút neskôr ich zhodilo kontrolné pozadie a celá stránka vrátila 404. Kontrola stavu počítala pády v zozname udalostí hostingovej platformy — ten drží len posledných päť udalostí na stroj, takže slučka pádov ho zaplní a počet sa nikdy nezvýši. Teraz porovnáva čas najnovšieho pádu a publikovanie, ktoré sa v slučke pádov zrúti, zlyhá a obnoví predchádzajúcu verziu.

Na čo publikovanie čaká

Keď na Mythex publikujete aplikáciu s backendom, nová verzia sa nasadí na stroje našej hostingovej platformy a kontrola stavu rozhodne, či publikovanie prešlo, alebo zlyhalo. Ak zlyhalo, rollback vráti predchádzajúcu verziu.

Ťažké je v tom, že „spustené“ neznamená „obsluhuje požiadavky“. Platforma hlási stroj ako spustený hneď, ako je hore. Aplikácia, ktorá spadne sekundu po štarte, sa okamžite reštartuje a chvíľu nato sa znova tvári ako spustená. Kontrola stavu sa preto v čase rozrástla do niekoľkých vrstiev:

1. Pozri sa dvakrát. Keď stroj hlási, že beží, krátko počkaj a pozri sa znova. Pád pri štarte druhú kontrolu často nevydrží.
2. Sleduj slučky pádov. Ak platforma hlási, že stroj opakovane padal a prestala ho reštartovať, zlyhaj.
3. Počítaj pády od začiatku publikovania. Dva pohľady „spustené“ môžu prekrývať reštart. Ak preto od začiatku publikovania nastal akýkoľvek pád, pozri sa ešte raz; ak je pádov viac než pri predchádzajúcom pohľade, aplikácia nezostáva hore.

Tretia kontrola bola tá, ktorá zlyhala.

Prečo počet zostal rovnaký

Informácie o pádoch pochádzajú zo zoznamu udalostí každého stroja: štarty, ukončenia, reštarty. Platforma uchováva len posledných päť udalostí na stroj.

Predstavte si aplikáciu, ktorá pri každom štarte spadne po 2,5 sekunde, ako jedna z nich. Každý cyklus pridá jeden pád a jeden štart. Po pár cykloch je zoznam plný. Odvtedy každá nová udalosť vytlačí jednu starú. Zoznam sa posúva dopredu, ale vždy obsahuje približne rovnakú zmes: pár pádov, pár štartov.

Takže „koľko pádov od začiatku publikovania“ vracalo pri každom pohľade rovnaké číslo. Druhý pohľad videl povedzme dva pády. Tretí pohľad tiež videl dva — iné pády, ale rovnaký počet. Kontrola usúdila, že padanie sa zastavilo, a publikovanie prešlo.

Stalo sa to tri razy 25. septembra, v dvoch aplikáciách. Pokaždé:

• publikovanie bolo označené ako živé,
• rollback sa nespustil, pretože nič nezlyhalo,
• náš reconciler, pozadie úloha, ktorá nasadenia kontroluje dodatočne, nasadenie o niekoľko minút neskôr zrušil,
• a celá stránka vrátila 404.

Publikovanie, ktoré zlyhá včas, sa dá zotaviť: rollback vráti predchádzajúcu verziu. Publikovanie, ktoré zlyhá o niekoľko minút neskôr, potom čo bolo ohlásené ako úspešné, už rollback vynechalo.

Ako sme to našli

Reprodukovali sme to lokálne: vzali sme funkčné API, nechali ho zaspať a potom ho znova publikovali so zmenou, ktorá pri štarte padala. Kontrola stavu ho označila ako živé.

To zodpovedalo produkcii: pri každom z troch publikovaní aplikácia zomrela sekundy po každom štarte, no počet pádov, s ktorým kontrola porovnávala, medzi pohľadmi nikdy nevzrástol.

Oprava: porovnaj najnovší pád, nie počet

Namiesto počítania pádov kontrola teraz sleduje čas najnovšieho pádu od začiatku publikovania.

Ak druhý pohľad ukáže akýkoľvek pád od začiatku publikovania, kontrola počká a pozrie sa ešte raz. Ak je najnovší pád pri treťom pohľade neskorší než najnovší pád pri druhom, stroj medzitým znova spadol. Nezostáva hore a publikovanie zlyhá so správou, že sa stroj od publikovania opakovane zrútil a stále sa reštartuje.

Toto funguje bez ohľadu na to, aký krátky je zoznam udalostí. Posuvné okno piatich udalostí môže skryť, koľko pádov bolo, ale nemôže skryť, že práve nastal nový — najnovšia udalosť sa vždy uchová.

S touto zmenou sa lokálna reprodukcia správa správne: publikovanie zlyhá a predchádzajúci obraz sa obnoví. Existuje aj test, ktorý simuluje správanie platformy — každý pohľad pridá pád a štart a zoznam zníži na päť — a overí, že výsledok je zlyhanie, nie úspech.

Čo sme si z toho odniesli

• Poznaj tvar dát, ktoré počítaš. Počet v zozname s limitom prestane niečo znamenať, keď je zoznam plný. Limit nebol skrytý; len sme kontrolu nenavrhli s ohľadom naň.
• Uprednostni otázku „stalo sa niečo nové?“ pred „koľko sa toho stalo?“ Najnovšia časová pečiatka prežije skrátenie zoznamu. Súčet nie.
• Neskoré zlyhanie je horšie než skoré. Ten istý rozbitý build je neškodný, ak publikovanie zlyhá a vráti sa späť, a zhodí stránku, ak je najprv ohlásený ako úspech.
• Reprodukuj za skutočných podmienok. Chyba potrebovala stroj, ktorý sa už dostatočne veľakrát zrútil, aby zaplnil svoj zoznam udalostí. Jeden rýchly pád v teste by sa neukázal.

Táto oprava nadväzuje na ďalšiu z toho istého dňa, ktorá zabezpečila, že rollback vráti starú verziu namiesto jej vymazania: neúspešné opätovné publikovanie nikdy nevymaže funkčný backend. Ak vaša aplikácia nejde publikovať, pretože pri štarte padá, dobrým začiatkom sú dokumentácia riešenie problémov s publikovaním a náš sprievodca ladením aplikácie vytvorenej AI.