Az összeomló appok elkapása közvetlenül a publikálás után

Szeptember 25-én három publikálást sikeresnek jelöltünk, pedig az app API-ja minden indítás után pár másodperccel összeomlott. Mivel a publikálások „sikeresek” voltak, nem futott visszavonás; egy háttérellenőrzés néhány perccel később megbuktatta őket, és az egész oldal 404-et adott. Az állapotellenőrzés az összeomlásokat a hosting platform eseménylistájában számolta — amely gépenként mindig csak az utolsó öt eseményt tartja meg, így egy összeomlási ciklus megtölti, és a szám nem nő tovább. Most a legújabb összeomlás időpontját hasonlítja össze, és egy összeomlási ciklusban lévő publikálás megbukik, és visszaállítja az előző verziót.

Mire vár egy publikálás

Amikor backenddel rendelkező appot publikálsz a Mythexen, az új verzió a hosting platformunk gépeire gurul ki, az állapotellenőrzés pedig eldönti, hogy a publikálás élőben van-e vagy meghiúsult. Ha meghiúsult, egy visszavonás visszateszi az előző verziót.

A nehéz rész az, hogy az „elindult” nem ugyanaz, mint a „szolgál”. A platform akkor jelzi a gépet elindultnak, amint az felállt. Az az app, amely indítás után egy másodperccel összeomlik, azonnal újraindul, és egy pillanattal később megint elindultnak látszik. Ezért az állapotellenőrzés az idő során több rétegből állt össze:

1. Kétszer nézz rá. Miután a gép elindultnak látszik, várj egy kicsit, és nézz rá újra. Az indításkori összeomlás gyakran a második ellenőrzésnél bukik.
2. Figyeld az összeomlási ciklusokat. Ha a platform jelzi, hogy a gép többször összeomlott, és feladta az újraindítást, bukjon meg.
3. Számold az összeomlásokat a publikálás kezdete óta. Két „elindult” nézet átível egy újraindításon. Ezért ha a publikálás kezdete óta bármilyen összeomlás történt, harmadszor is nézünk; ha több összeomlás van, mint az előző nézésnél, az app nem marad fent.

A harmadik ellenőrzés volt az, amely itt megbukott.

Miért maradt laposan a szám

Az összeomlási információ minden gép eseménylistájából jön: indulások, kilépések, újraindítások. A platform gépenként csak az utolsó öt eseményt tartja meg.

Képzeld el egy appot, amely indításkor 2,5 másodperccel összeomlik, ahogy az egyik ilyen is tette. Minden ciklus egy összeomlást és egy indulást ad hozzá. Pár ciklus után a lista megtelik. Onnantól minden új esemény kiszorít egy régit. A lista csúszik előre, de mindig nagyjából ugyanazt a keveréket tartalmazza: pár összeomlást, pár indulást.

Ahogy a „hány összeomlás a publikálás kezdete óta” kérdésre minden nézésnél ugyanaz a szám jött vissza. A második nézés mondjuk két összeomlást látott. A harmadik is kettőt — más összeomlásokat, de ugyanannyit. Az ellenőrzés arra jutott, hogy az összeomlás megállt, és átengedte a publikálást.

Ez szeptember 25-én háromszor történt, két appon. Mindannyiszor:

• a publikálás élőként volt jelölve,
• nem futott visszavonás, mert semmi nem bukott meg,
• az egyeztetőnk, egy háttérfeladat, amely utólag ellenőrzi a deployokat, pár perccel később megbuktatta a deployt,
• és az egész oldal 404-et adott.

A időben meghiúsuló publikálást a visszavonás helyre tudja állítani: az előző verziót visszaállítja. A pár perccel később meghiúsuló, miután sikernek lett jelölve, már kihagyta a visszavonást.

Hogyan találtuk meg

Helyben reprodukáltuk: vettünk egy működő API-t, hagytuk elaludni, majd újra publikáltuk egy olyan változtatással, amely indításkor összeomlik. Az állapotellenőrzés élőnek jelölte.

Ez egyezett a productionnel: mindhárom publikálásnál az app minden indítás után pár másodperccel meghalt, mégis az összehasonlított összeomlásszám két nézés között sosem nőtt.

A javítás: a legújabb összeomlást hasonlítsd, ne a számot

Az összeomlások számolása helyett az ellenőrzés most a legutolsó összeomlás időpontját nézi a publikálás kezdete óta.

Ha a második nézésen bármilyen összeomlás látszik a publikálás kezdete óta, az ellenőrzés vár, és harmadszor is megnéz. Ha a harmadik nézésen a legutolsó összeomlás később van, mint a második nézésen, a gép az ellenőrzések között újra összeomlott. Nem marad fent, a publikálás pedig meghiúsul egy üzenettel: a gép a publikálás óta többször összeomlott, és még mindig újraindul.

Ez működik az eseménylista hosszától függetlenül. Az öt eseményes csúszóablak eltakarhatja, hány összeomlás volt, de azt nem takarhatja el, hogy most történt egy új — a legújabb esemény mindig megmarad.

Ezzel a változtatással a helyi reprodukció helyesen viselkedik: a publikálás meghiúsul, és az előző image visszaáll. Van egy teszt is, amely a platform viselkedését szimulálja — minden nézés hozzáad egy összeomlást és egy indulást, és a listát öt elemre vágja —, és ellenőrzi, hogy az ítélet hiba, nem sikeres átmenet.

Amit ebből tanultunk

• Ismerd az adatod alakját, amit számolsz. Egy korlátos listán végzett számlálás nem jelent semmit, amint a lista megtelik. A korlát nem volt elrejtve; egyszerűen nem a korlátra terveztük az ellenőrzést.
• Inkább azt kérdezd, „történt-e valami új?”, mint azt, „hányszor történt?” A legújabb időbélyeg túléli a levágást. Az összeg nem.
• A késői hiba rosszabb a koránál. Ugyanaz a hibás build ártalmatlan, ha a publikálás meghiúsul és visszavonódik, de egy oldalt leáll, ha előbb sikeresnek nyilvánítják.
• Reprodukáld valódi feltételekkel. A hibához egy olyan gép kellett, amely már eleget omlott össze ahhoz, hogy megtöltse az eseménylistáját. Egy egyszeri gyors összeomlás egy tesztben nem mutatta volna meg.

Ez a javítás párja egy ugyanazon a napon készült másiknak, amely biztosította, hogy a visszavonás visszaállítsa a régi verziót, ahelyett hogy törölné: a sikertelen újrapublikálás soha nem töröl működő backendet. Ha a saját appod indításkor összeomlik, és ezért nem publikálódik, a publikálási hibaelhárítás dokumentáció és az AI-val épített app hibakeresése útmutatónk jó kiindulópont.