Odchytávání aplikací, které se hroutí hned po publikování
Dne 25. září prošla tři publikování jako úspěšná, ačkoli se API aplikace sekundy po každém startu zhroutilo. Protože byla „úspěšná“, rollback neproběhl; pozdější background kontrola je o pár minut později označila jako neúspěšná a celý web vrátil 404. Health check počítal pády v seznamu událostí hostingové platformy – ten drží jen posledních pět událostí na stroj, takže smyčka pádů ho pořád zaplňuje a počet nikdy neroste. Teď místo počtu porovnává čas nejnovějšího pádu, a publikování, které se v cyklu hroutí, selže a obnoví předchozí verzi.
Na co publikování čeká
Když publikujete aplikaci s backendem v Mythexu, nová verze se nasadí na stroje naší hostingové platformy a health check rozhodne, zda publikování dopadlo, nebo selhalo. Při selhání rollback vrátí předchozí verzi.
Těžká část je, že „spuštěno“ neznamená „obsluhuje“. Platforma hlásí stroj jako spuštěný, jakmile je nahoře. Aplikace, která se sekundu po startu zhroutí, se okamžitě restartuje a chvíli nato je zase hlášena jako spuštěná. Health check proto během času narostl o několik vrstev:
- Dívat se dvakrát. Poté co stroj hlásí spuštění, chvíli počkejte a podívejte se znovu. Pád při startu často selže už při druhé kontrole.
- Hlídat smyčky pádů. Pokud platforma hlásí, že stroj se opakovaně hroutil a restartování vzdala, selhat.
- Počítat pády od začátku publikování. Dva pohledy „spuštěno“ mohou být rozděleny restartem. Pokud tedy od začátku publikování došlo k jakémukoli pádu, podívejte se potřetí; pokud je pádů víc než při předchozím pohledu, aplikace nezůstává nahoře.
Třetí kontrola je ta, která tady selhala.
Proč počet zůstal stejný
Informace o pádech pochází z event listu každého stroje: starty, ukončení, restarty. Platforma drží jen posledních pět událostí na stroj.
Představte si aplikaci, která se 2,5 sekundy po každém startu zhroutí, jako jedna z nich. Každý cyklus přidá pád a start. Po pár cyklech je seznam plný. Od té chvíle každá nová událost vytlačí nějakou starou. Seznam se posouvá dopředu, ale vždy obsahuje zhruba stejnou směs: pár pádů a pár startů.
Takže „kolik pádů od začátku publikování“ vracelo při každém pohledu stejné číslo. Druhý pohled viděl třeba dva pády. Třetí pohled také viděl dva – jiné pády, ale stejný počet. Kontrola usoudila, že pády ustaly, a publikování prošlo.
Stalo se to třikrát 25. září, u dvou aplikací. Pokaždé:
- publikování bylo označeno jako živé,
- rollback neproběhl, protože nic nepadlo,
- náš reconciler, background úloha, která nasazení kontroluje zpětně, nasazení o pár minut později označil jako neúspěšné,
- a celý web vrátil 404.
Publikování, které selže včas, se dá zachránit: rollback obnoví předchozí verzi. Publikování, které selže o pár minut později poté, co bylo označeno za úspěch, rollback už přeskočilo.
Jak jsme to našli
Reprodukovali jsme to lokálně: vzali fungující API, nechali ho usnout a pak ho znovu publikovali se změnou, která se při startu zhroutila. Health check ho označil za živý.
Odpovídalo to produkci: u každého ze tří publikování aplikace při každém startu zemřela sekundy po startu, a přesto se počet pádů, který kontrola porovnávala, mezi pohledy nezvýšil.
Oprava: porovnat nejnovější pád, ne počet
Místo počítání pádů se kontrola teď dívá na čas nejnovějšího pádu od začátku publikování.
Pokud druhý pohled ukáže jakýkoli pád od začátku publikování, kontrola počká a podívá se potřetí. Pokud je nejnovější pád při třetím pohledu později než nejnovější pád při druhém, stroj se mezitím znovu zhroutil. Nezůstává nahoře a publikování selže se zprávou, že stroj se od publikování opakovaně hroutil a stále se restartuje.
To funguje bez ohledu na to, jak krátký je event list. Klouzavé okno pěti událostí může skrýt, kolik pádů bylo, ale nemůže skrýt, že se právě stal nový – nejnovější událost je vždy ta, která zůstane.
S touto změnou se lokální reprodukce chová správně: publikování selže a předchozí image se obnoví. Existuje i test, který simuluje chování platformy – každý pohled přidá pád a start a seznam zkrátí na pět – a ověřuje, že verdikt je selhání, ne úspěch.
Co si z toho bereme
- Znejte tvar dat, která počítáte. Počet v omezeném seznamu přestane něco znamenat, jakmile je seznam plný. Ta hranice nebyla skrytá; jen jsme kontrolu nenavrhli s ohledem na ni.
- Dávejte přednost otázce „stalo se něco nového?“ před „kolik se toho stalo?“ Nejnovější časové razítko přežije zkrácení. Součet ne.
- Pozdní selhání je horší než brzké. Stejný rozbitý build je neškodný, pokud publikování selže a rollbackne, a shodí web, pokud je nejdřív označeno jako úspěch.
- Reprodukujte za skutečných podmínek. Chyba potřebovala stroj, který se už dost zhroutil, aby zaplnil svůj event list. Jeden rychlý pád v testu by ji neukázal.
Tato oprava navazuje na další ze stejného dne, která zajistila, že rollback obnoví starou verzi místo jejího smazání: neúspěšné opětovné publikování nikdy nesmaže fungující backend. Pokud se vaše aplikace nepublikuje, protože se při startu hroutí, dobrým začátkem jsou dokumentace řešení problémů s publikováním a náš průvodce laděním aplikace postavené AI.