Kohe pärast avaldamist kokkukukkuvate rakenduste püüdmine

1. septembril märgiti kolm avaldamist õnnestunuks, kuigi rakenduse API kukkus iga käivituse paar sekundit pärast alustamist kokku. Kuna need olid „õnnestunud”, tagasivõtmist ei käivitatud. Taustakontroll ebaõnnestus need mõne minuti pärast ja kogu sait läks 404-vigasse. Tervisekontroll luges krahhe hostingplatvormi sündmuste nimekirjast, kuhu mahub masina kohta ainult viimased viis sündmust. Krahhitsükkel täidab nimekirja, nii et arv ei kasvanud kunagi. Nüüd võrdleb kontroll uusima krahhi aega ning krahhitsükliga avaldamine ebaõnnestub ja taastab eelmise versiooni.

Mida avaldamine ootab

Kui avaldad Mythexis rakenduse, mille taga on tagarakendus, rullitakse uus versioon meie hostingplatvormi masinatele ja tervisekontroll otsustab, kas avaldamine läks elavaks või ebaõnnestus. Kui ebaõnnestus, taastab tagasivõtmine eelmise versiooni.

Raske osa on see, et „käivitatud” ei ole sama mis „teenindab”. Platvorm märgib masina käivitatuks kohe, kui see on üles. Rakendus, mis kukub kokku sekund pärast alustamist, taaskäivitatakse kohe ja hetk hiljem loetakse ta jälle käivitatuks. Seetõttu on tervisekontroll aja jooksul kihtideks kasvanud:

1. Vaata kaks korda. Pärast seda, kui masin loetakse käivitatuks, oota natuke ja vaata uuesti. Krahh käivitamisel ebaõnnestub sageli teisel vaatamisel.
2. Jälgi krahhitsükleid. Kui platvorm ütleb, et masin kukkus korduvalt kokku ja ta on taaskäivitamise lõpetanud, ebaõnnestu.
3. Loe krahhe alates avaldamise algusest. Kaks „käivitatud” vaatamist võivad jääda taaskäivituse vahele. Seega, kui alates avaldamise algusest on toimunud mõni krahh, vaata kolmandat korda; kui krahhe on rohkem kui eelmisel vaatamisel, rakendus ei püsi üleval.

Kolmas kontroll oli see, mis siin ebaõnnestus.

Miks arv jäi lamedaks

Krahhiinfo tuleb iga masina sündmuste nimekirjast: käivitused, lõpetamised, taaskäivitused. Platvorm hoiab masina kohta alles ainult viimased viis sündmust.

Kujuta ette rakendust, mis kukub kokku 2,5 sekundit pärast iga käivitust, nagu üks neist tegi. Iga tsükkel lisab krahhi ja käivituse. Paari tsükli pärast on nimekiri täis. Sellest hetkest igas uues sündmuses lükkub mõni vana välja. Nimekiri liigub edasi, aga selles on alati umbes sama segu: paar krahhi, paar käivitust.

Seega „mitu krahhi on alates avaldamise algusest” andis igal vaatamisel sama arvu. Teine vaatamine nägi näiteks kahte krahhi. Kolmas vaatamine nägi ka kahte, küll teisi krahhe, aga sama arvu. Kontroll järeldas, et kukkumine on lõppenud, ja lubas avaldamise läbi.

See juhtus kolm korda 25. septembril kahe rakendusega. Igal korral:

• avaldamine märgiti elavaks,
• tagasivõtmist ei käivitunud, sest midagi ei olnud ebaõnnestunud,
• meie reconciler, taustatöö, mis kontrollib deploy'sid pärast fakti, ebaõnnestus deploy mõne minuti pärast,
• ja kogu sait tagastas 404.

Avaldamine, mis ebaõnnestub õigel ajal, on taastatav: tagasivõtmine taastab eelmise versiooni. Avaldamine, mis ebaõnnestub mõne minuti hiljem, pärast seda kui see on õnnestunuks kuulutatud, on juba tagasivõtmise vahele jätnud.

Kuidas me selle leidsime

Reprodutseerisime selle kohapeal: võtsime töötava API, lasime tal magama minna ja avaldasime uuesti muudatusega, mis kukub käivitamisel kokku. Tervisekontroll märkis selle elavaks.

See vastas tootmisele: igas kolmes avaldamises kukkus rakendus paar sekundit pärast igat käivitust, ometi krahhide arv, mida kontroll võrdles, ei kasvanud vaatamiste vahel kunagi.

Parandus: võrdle uusimat krahhi, mitte arvu

Krahhide lugemise asemel vaatab kontroll nüüd viimase krahhi aega alates avaldamise algusest.

Kui teine vaatamine näitab mõnda krahhi alates avaldamise algusest, ootab kontroll ja vaatab kolmandat korda. Kui kolmanda vaatamise uusim krahh on hilisem kui teise vaatamise uusim krahh, kukkus masin vahepeal uuesti kokku. Ta ei püsi üleval ja avaldamine ebaõnnestub, koos teatega, et masin kukkus alates avaldamisest korduvalt kokku ja taaskäivitub endiselt.

See töötab sõltumata sellest, kui lühike sündmuste nimekiri on. Viie sündmuse libisev aken võib peita, mitu krahhi oli, aga ei saa peita seda, et uus krahh just toimus. Uusim sündmus on alati see, mis alles jääb.

Kohaliku reprodutseerimisega käitub uus kontroll nüüd õigesti: avaldamine ebaõnnestub ja eelmine konteiner taastatakse. On ka test, mis simuleerib platvormi käitumist (iga vaatamine lisab krahhi ja käivituse ning kärbib nimekirja viiele) ja kontrollib, et otsus on ebaõnnestumine, mitte läbimine.

Mida sellest õppisime

• Tea oma andmete kuju. Loendamine piiratud nimekirjas ei tähenda pärast täitumist enam midagi. Piirang ei olnud peidetud; me ei olnud kontrolli selle järgi kavandanud.
• Eelista küsimust „kas midagi uut toimus?” küsimusele „mitu toimus?”. Uusim ajatempel jääb alles pärast kärpimist, kogusumma ei jää.
• Hiline ebaõnnestumine on halvem kui varajane. Sama katkine ehitis on kahjutu, kui avaldamine ebaõnnestub ja taastub, ja viib sündmuse alla, kui see kuulutatakse kõigepealt õnnestunuks.
• Reprodutseeri päris tingimustega. Viga vajas masinat, mis oli juba piisavalt kokku kukkunud, et täita oma sündmuste nimekiri. Üks kiire krahh testis poleks seda näidanud.

See parandus käib koos teisega samalt päevalt, mis tagas, et tagasivõtmine taastab vana versiooni, selle asemel et seda kustutada: ebaõnnestunud uuesti avaldamine ei kustuta kunagi töötavat tagarakendust. Kui sinu rakendus ei avaldu, sest see kukub käivitamisel kokku, on avaldamise tõrkeotsingu dokumentatsioon ja meie juhend AI-ga ehitatud rakenduse silumisest head kohad alustamiseks.