Odkrivanje aplikacij, ki se zrušijo takoj po objavi

1. septembra so bile tri objave označene kot uspešne, čeprav se je API aplikacije vsakič sekundo po zagonu zrušil. Ker so bile „uspešne“, povrnitev ni bila izvedena; čez nekaj minut jih je nadzorni preverjevalnik označil kot neuspešne, cela spletna stran pa je dobila 404. Preverjevalnik zdravja je zrušitve štel v seznamu dogodkov gostiteljske platforme – ta na vsakem stroju hrani samo zadnjih pet dogodkov, zato zanka zrušitev seznam vedno napolni, število pa se nikoli ne poveča. Zdaj primerja čas najnovejše zrušitve, objava, pri kateri se zrušitve ponavljajo, pa ne uspe in obnovi prejšnjo različico.

Na kaj čaka objava

Ko objavite aplikacijo z zaledjem na Mythexu, se nova različica namesti na stroje naše gostiteljske platforme, preverjevalnik zdravja pa odloči, ali je objava uspela. Če ni, rollback povrne prejšnjo različico.

Težava je v tem, da „zagnan“ ni isto kot „streže“. Platforma stroj označi kot zagnan takoj, ko se dvigne. Aplikacija, ki se sekundo po zagonu zruši, se takoj znova zažene in čez trenutek spet velja za zagnano. Zato je preverjevalnik zdravja skozi čas dobil nekaj plasti:

1. Poglejte dvakrat. Potem ko stroj velja za zagnanega, na kratko počakajte in pogledajte znova. Zrušitev ob zagonu pogosto pade na drugem pogledu.
2. Poiščite zanke zrušitev. Če platforma poroča, da se je stroj večkrat zrušil in da je prenehala poskušati, objava ne uspe.
3. Štejte zrušitve od začetka objave. Dva pogleda „zagnan“ lahko segata čez ponovni zagon. Če se je od začetka objave zgodila kakršna koli zrušitev, pogledamo še tretjič; če je zrušitev več kot na prejšnjem pogledu, aplikacija ni stabilna.

Tretja preverba je tista, ki je tukaj odpovedala.

Zakaj je število ostalo enako

Podatki o zrušitvah prihajajo iz seznama dogodkov vsakega stroja: zagoni, izhodi, ponovni zagoni. Platforma hrani samo zadnjih pet dogodkov na stroj.

Predstavljajte si aplikacijo, ki se zruši 2,5 sekunde po vsakem zagonu, kot se je zgodilo pri eni od njih. Vsak cikel doda zrušitev in zagon. Po nekaj ciklih je seznam poln. Od takrat naprej vsak nov dogodek potisne starega iz seznama. Seznam se pomika naprej, vendar vedno vsebuje približno enako mešanico: nekaj zrušitev, nekaj zagonov.

Zato je „koliko zrušitev od začetka objave“ vsakič vrnilo isto število. Drugi pogled je videl recimo dve zrušitvi. Tretji pogled je prav tako videl dve – druge zrušitve, a isto število. Preverba je sklepala, da zrušitve prenehajo, in objavo potrdila.

To se je 25. septembra zgodilo trikrat, pri dveh aplikacijah. Vsakič:

• objava je bila označena kot v živo,
• rollback ni bil izveden, ker nič ni odpovedalo,
• naš reconciler, ozadinski proces, ki preverja objave naknadno, je objavo čez nekaj minut označil kot neuspešno,
• in cela spletna stran je vrnila 404.

Objava, ki odpove pravočasno, se da popraviti: rollback povrne prejšnjo različico. Objava, ki odpove nekaj minut prepozno, potem ko je bila razglašena za uspešno, je že preskočila rollback.

Kako smo to odkrili

Reproducirali smo ga lokalno: vzeli smo delujoč API, ga pustili zaspati in nato znova objavili s spremembo, ki se je ob zagonu zrušila. Preverba je objavo označila kot v živo.

To se je ujemalo s produkcijo: pri vsaki od treh objav se je aplikacija sekundo po vsakem zagonu zrušila, vendar število zrušitev, ki ga je preverba primerjala, med pogledi nikoli ni naraslo.

Popravek: primerjaj najnovejšo zrušitev, ne števila

Namesto štetja zrušitev preverba zdaj gleda na čas najnovejše zrušitve od začetka objave.

Če drugi pogled pokaže kakršno koli zrušitev od začetka objave, preverba počaka in pogleda tretjič. Če je najnovejša zrušitev na tretjem pogledu kasnejša od najnovejše na drugem, se je stroj med tem znova zrušil. Ne ostane zagnan, objava pa ne uspe s sporočilom, da se je stroj od objave večkrat zrušil in se še vedno znova zaganja.

To deluje ne glede na to, kako kratek je seznam dogodkov. Drseče okno petih dogodkov lahko skrije, koliko zrušitev je bilo, ne more pa skriti, da se je ravnokar zgodila nova – najnovejši dogodek je vedno tisti, ki ostane.

Z novim popravkom se lokalna reprodukcija obnaša pravilno: objava ne uspe in prejšnja slika se obnovi. Obstaja tudi test, ki simulira obnašanje platforme – vsak pogled doda zrušitev in zagon ter seznam skrajša na pet – in preveri, da je rezultat neuspeh, ne uspeh.

Kaj smo iz tega vzeli

• Vedite, kakšno obliko imajo podatki, ki jih štejete. Štetje na omejenem seznamu nima več pomena, ko je seznam poln. Omejitve nismo skrili; preverba pa ni bila zasnovana z mislijo nanjo.
• Raje vprašajte „ali se je zgodilo kaj novega?“ kot „koliko se jih je zgodilo?“ Najnovejši časovni žig preživi odrezovanje; skupno število ne.
• Poznejša napaka je slabša od zgodnje. Enaka pokvarjena gradnja je neškodljiva, če objava odpove in se povrne, a če jo najprej razglasite za uspešno, spletno stran sesuje.
• Reproducirajte v pravih pogojih. Napaka je potrebovala stroj, ki se je že dovolj krat zrušil, da je napolnil svoj seznam dogodkov. Ena sama hitra zrušitev v testu tega ne bi pokazala.

Ta popravek se dopolnjuje z drugim iz istega dne, ki je zagotovil, da rollback vrne staro različico namesto da bi jo izbrisal: neuspešna ponovna objava nikoli ne izbriše delujočega zaledja. Če vaša aplikacija ne uspe pri objavi, ker se ob zagonu zruši, sta dobri izhodišči dokumentacija odpravljanje težav pri objavi in naš vodnik o odpravljanju napak v aplikaciji, zgrajeni z AI.