Sovellusten kaatumisten kiinni saaminen heti julkaisun jälkeen

Syyskuun 25. päivänä kolme julkaisua merkittiin onnistuneiksi, vaikka sovelluksen API kaatui sekunteja jokaisen käynnistyksen jälkeen. Koska julkaisut ”onnistuivat”, peruutusta ei ajettu. Taustatarkistus epäonnisti ne muutamaa minuuttia myöhemmin, ja koko sivusto antoi 404-virheen. Terveystarkistus laski kaatumisia alustan tapahtumalistasta, johon mahtuu vain koneen viimeiset viisi tapahtumaa. Kaatumissilmukka täyttää listan, eikä laskuri koskaan kasva. Nyt tarkistus vertaa uusimman kaatumisen aikaa, ja kaatumissilmukassa oleva julkaisu epäonnistuu ja palauttaa edellisen version.

Mitä julkaisu odottaa

Kun julkaiset Mythexissä sovelluksen, jolla on taustapalvelu, uusi versio viedään koneille hostausalustallamme, ja terveystarkistus päättää, meneekö julkaisu käyttöön vai epäonnistuuko se. Jos se epäonnistuu, peruutus palauttaa edellisen version.

Vaikea osa on, että ”käynnistynyt” ei tarkoita samaa kuin ”palvelee”. Alusta raportoi koneen käynnistyneeksi heti, kun se on ylhäällä. Sovellus, joka kaatuu sekunnin käynnistyksen jälkeen, käynnistetään heti uudelleen, ja hetken kuluttua se näkyy taas käynnistyneenä. Terveystarkistus oli kasvanut ajan myötä muutamaan kerrokseen:

1. Katso kahdesti. Kun kone näkyy käynnistyneenä, odota hetki ja katso uudelleen. Kaatuminen käynnistyksessä epäonnistuu usein tässä toisessa tarkistuksessa.
2. Etsi kaatumissilmukoita. Jos alusta kertoo, että kone kaatui toistuvasti ja se lopetti uudelleenkäynnistyksen, epäonnistu.
3. Laske kaatumiset julkaisun alusta. Kaksi ”käynnissä”-tarkistusta voi osua uudelleenkäynnistyksen yli. Jos julkaisun alun jälkeen on tapahtunut kaatumisia, katso kolmannen kerran. Jos kaatumisia on enemmän kuin edellisellä kerralla, sovellus ei pysy pystyssä.

Kolmas tarkistus oli se, joka epäonnistui tässä.

Miksi laskuri pysyi paikallaan

Kaatumistiedot tulevat kunkin koneen tapahtumalistasta: käynnistykset, lopetukset ja uudelleenkäynnistykset. Alusta säilyttää vain viimeiset viisi tapahtumaa per kone.

Kuvittele sovellus, joka kaatuu 2,5 sekuntia jokaisen käynnistyksen jälkeen, kuten yksi niistä teki. Jokainen sykli lisää yhden kaatumisen ja yhden käynnistyksen. Parin syklin jälkeen lista on täynnä. Siitä eteenpäin jokainen uusi tapahtuma työntää vanhan ulos. Lista liukuu eteenpäin, mutta se sisältää aina suunnilleen saman sekoituksen: pari kaatumista ja pari käynnistystä.

Joten ”kuinka monta kaatumista julkaisun alun jälkeen” antoi saman luvun joka kerta. Toinen katselukerta näki esimerkiksi kaksi kaatumista. Kolmas katselukerta näki myös kaksi, eri kaatumiset mutta sama määrä. Tarkistus päätteli, että kaatuminen oli loppunut, ja hyväksyi julkaisun.

Näin kävi kolme kertaa 25. syyskuuta kahdessa sovelluksessa. Joka kerta:

• julkaisu merkittiin käyttöön otetuksi,
• peruutusta ei ajettu, koska mitään ei ollut epäonnistunut,
• taustalla toimiva tarkistusjärjestelmämme, joka tarkistaa julkaisut jälkikäteen, epäonnisti julkaisun muutamaa minuuttia myöhemmin,
• ja koko sivusto palautti 404-virheen.

Julkaisu, joka epäonnistuu ajoissa, on palautettavissa: peruutus palauttaa edellisen version. Julkaisu, joka epäonnistuu muutamaa minuuttia myöhemmin sen jälkeen, kun se on julistettu onnistuneeksi, on jo ohittanut peruutuksensa.

Miten löysimme vian

Toistimme sen paikallisesti: otimme toimivan API:n, annoimme sen nukahtaa ja julkaisimme sen uudelleen muutoksella, joka kaatui käynnistyessään. Terveystarkistus merkitsi sen käyttöön otetuksi.

Se vastasi tuotantoa: jokaisessa kolmessa julkaisussa sovellus kuoli sekunteja jokaisen käynnistyksen jälkeen, mutta vertailtava kaatumislaskuri ei noussut katselukertojen välillä.

Korjaus: vertaa uusinta kaatumista, ei määrää

Sen sijaan, että tarkistus laskisi kaatumisia, se katsoo nyt viimeisimmän kaatumisen aikaa julkaisun alun jälkeen.

Jos toinen katselukerta näyttää minkä tahansa kaatumisen julkaisun alun jälkeen, tarkistus odottaa ja katsoo kolmannen kerran. Jos uusin kaatuminen kolmannella kerralla on myöhäisempi kuin uusin kaatuminen toisella kerralla, kone kaatui uudelleen välissä. Se ei pysy pystyssä, ja julkaisu epäonnistuu viestillä, jonka mukaan kone kaatui toistuvasti julkaisun jälkeen ja käynnistyy yhä uudelleen.

Tämä toimii riippumatta siitä, kuinka lyhyt tapahtumalista on. Liukuva ikkuna viidelle tapahtumalle voi piilottaa, kuinka monta kaatumista oli, mutta se ei voi piilottaa sitä, että uusi kaatuminen just tapahtui. Uusin tapahtuma säilyy aina.

Paikallinen toisto käyttäytyy nyt oikein: julkaisu epäonnistuu ja edellinen image palautetaan. Mukana on myös testi, joka jäljittelee alustan käyttäytymistä: jokainen katselukerta lisää kaatumisen ja käynnistyksen ja leikkaa listan viiteen, ja testi varmistaa, että tulos on epäonnistuminen, ei läpäisy.

Mitä opimme

• Tiedä, minkälaista dataa laskit. Laskuri, joka laskee rajatun listan, ei tarkoita enää mitään, kun lista on täynnä. Rajaus ei ollut piilossa, emme vain olleet suunnitelleet tarkistusta sen ympärille.
• Kysy ”tapahtuiko jotain uutta?” mieluummin kuin ”montako tapahtui?” Uusin aikaleima säilyy katkaisun jälkeenkin. Summa ei säily.
• Myöhäinen epäonnistuminen on pahempi kuin varhainen. Sama rikkinäinen versio on vaaraton, jos julkaisu epäonnistuu ja peruutetaan, mutta se kaataa sivuston, jos julkaisu julistetaan onnistuneeksi ensin.
• Toista oikeissa olosuhteissa. Vika vaati koneen, joka oli jo kaatunut tarpeeksi kertoja täyttääkseen tapahtumalistansa. Yksi nopea kaatuminen testissä ei olisi paljastanut sitä.

Tämä korjaus liittyy samana päivänä tehtyyn toiseen korjaukseen, joka varmisti, että peruutus palauttaa vanhan version eikä poista sitä: epäonnistunut uudelleenjulkaisu ei koskaan poista toimivaa taustapalvelua. Jos oma sovelluksesi ei julkaise, koska se kaatuu käynnistyessään, julkaisun vianmääritys -dokumentaatio ja oppaamme AI-rakennetun sovelluksen vianmääritys ovat hyvä paikka aloittaa.