Hvatanje aplikacija koje se sruše odmah nakon objavljivanja

Dana 25. septembra, tri objave su označene kao uspješne, iako se API aplikacije rušio nekoliko sekundi nakon svakog pokretanja. Pošto su „uspjele”, rollback se nije pokrenuo; kasnija provjera u pozadini označila ih je kao neuspjele nekoliko minuta poslije, i cijeli sajt je prešao na 404. Health check je brojao padove u listi događaja hosting platforme — koja uvijek drži samo posljednjih pet događaja po mašini, pa petlja padanja drži listu punom i brojač nikada ne raste. Sada upoređuje vrijeme najnovijeg pada, a objava koja se ruši u petlji pada i vraća prethodnu verziju.

Na šta objava čeka

Kada objavite aplikaciju sa backendom na Mythexu, nova verzija se postavlja na mašine na našoj hosting platformi, a health check odlučuje da li je objava prošla uživo ili je pala. Ako je pala, rollback vraća prethodnu verziju.

Teško je to što „pokrenuto” nije isto što i „servira”. Platforma prijavljuje mašinu kao pokrenutu čim se podigne. Aplikacija koja se sruši sekundu nakon pokretanja odmah se ponovo pokrene, pa u sljedećem trenutku opet izgleda kao pokrenuta. Health check je tokom vremena dobio nekoliko slojeva:

1. Pogledaj dvaput. Nakon što mašina izgleda pokrenuto, sačekaj kratko i pogledaj ponovo. Pad pri pokretanju često pukne u drugoj provjeri.
2. Traži petlje padanja. Ako platforma prijavi da se mašina stalno rušila i da je prestala da je ponovo pokreće, pad.
3. Broj padove od početka objave. Dvije „pokrenuto” provjere mogu da obuhvate restart između njih. Zato, ako se bilo koji pad dogodio od početka ove objave, pogledaj treći put; ako ima više padova nego pri prethodnoj provjeri, aplikacija se ne održava podignutom.

Treća provjera je ona koja je ovdje pukla.

Zašto je brojač ostao isti

Informacije o padovima dolaze iz liste događaja svake mašine: pokretanja, izlazi, restarti. Platforma čuva samo posljednjih pet događaja po mašini.

Zamislite aplikaciju koja se ruši 2,5 sekundi nakon svakog pokretanja, kao jedna od ovih. Svaki ciklus dodaje jedan pad i jedno pokretanje. Nakon nekoliko ciklusa, lista je puna. Od tada, svaki novi događaj gurne jedan stari van. Lista klizi unaprijed, ali uvijek drži približno istu mješavinu: nekoliko padova, nekoliko pokretanja.

Zato je „koliko padova od početka objave” vraćalo isti broj pri svakoj provjeri. Druga provjera je vidjela, recimo, dva pada. Treća je takođe vidjela dva pada — drugačija, ali isti broj. Provjera je zaključila da je rušenje stalo i propustila objavu.

To se desilo tri puta 25. septembra, na dvije aplikacije. Svaki put:

• objava je označena kao živa,
• rollback se nije pokrenuo, jer ništa nije palo,
• naš reconciler, pozadinski posao koji provjerava deploymente naknadno, označio je deployment kao neuspjeli nekoliko minuta kasnije,
• i cijeli sajt je vraćao 404.

Objava koja pukne na vrijeme može se oporaviti: rollback vraća prethodnu verziju. Objava koja pukne nekoliko minuta kasnije, nakon što je proglašena uspjehom, već je preskočila svoj rollback.

Kako smo to otkrili

Reprodukovali smo lokalno: uzeli smo radni API, pustili ga da zaspi, pa ga ponovo objavili sa izmjenom koja se rušila pri pokretanju. Health check ga je označio kao živ.

To se poklapalo sa produkcijom: u svakoj od tri objave, aplikacija je umirala nekoliko sekundi nakon svakog pokretanja, ali broj padova koji provjera upoređuje nikada nije rastao između provjera.

Ispravka: uporedi najnoviji pad, a ne broj

Umjesto brojanja padova, provjera sada gleda vrijeme najnovijeg pada od početka objave.

Ako druga provjera pokaže bilo koji pad od početka objave, provjera čeka i gleda treći put. Ako je najnoviji pad na trećoj provjeri kasniji od najnovijeg pada na drugoj, mašina se ponovo srušila u međuvremenu. Ne ostaje podignuta, a objava pada uz poruku da se mašina ponavljano rušila od objavljivanja i da se i dalje ponovo pokreće.

Ovo radi bez obzira na to koliko je kratka lista događaja. Klizeći prozor od pet događaja može sakriti koliko je padova bilo, ali ne može sakriti da se upravo dogodio novi — najnoviji događaj je uvijek onaj koji ostaje.

Sa ovom promjenom, lokalna reprodukcija se ponaša ispravno: objava pada, a prethodni image se vraća. Postoji i test koji simulira ponašanje platforme — svaka provjera dodaje pad i pokretanje i skraćuje listu na pet — i provjerava da je presuda neuspjeh, a ne prolaz.

Šta smo iz toga naučili

• Znajte oblik podataka koje brojite. Brojanje u ograničenoj listi prestaje da znači išta kada se lista napuni. Ograničenje nije bilo skriveno; samo nismo projektovali provjeru oko njega.
• Radije pitajte „da li se desilo nešto novo?” nego „koliko se toga desilo?” Najnoviji vremenski žig preživljava skraćivanje. Ukupan broj ne preživljava.
• Kasna greška je gora od rane. Ista pokvarena verzija je bezopasna ako objava pukne i vrati se unazad, a obori sajt ako je prvo proglašena uspjehom.
• Reprodukujte u stvarnim uslovima. Greška je zahtijevala mašinu koja se već dovoljno puta srušila da popuni listu događaja. Jedan brzi pad u testu to ne bi pokazao.

Ova ispravka se nadovezuje na drugu iz istog dana, koja je osigurala da rollback vrati staru verziju umjesto da je obriše: neuspjelo ponovno objavljivanje nikada ne briše backend koji radi. Ako vaša aplikacija ne može da se objavi jer se ruši pri pokretanju, rješavanje problema sa objavom u dokumentaciji i naš vodič o debugovanju aplikacije napravljene AI-jem dobra su polazna tačka.