Lietotņu avāriju noķeršana tieši pēc publicēšanas

1. septembrī trīs publicēšanas tika atzītas par veiksmīgām, lai gan lietotnes API avarēja sekundes pēc katras palaišanas. Tā kā tās bija „veiksmīgas”, atsaukšana netika palaista; fona pārbaude tās vēlāk dažu minūšu laikā atzīmēja kā neizdevušās, un viss vietnes saturs kļuva par 404. Veselības pārbaude skaitīja avārijas hostinga platformas notikumu sarakstā, kurā katrai mašīnai glabājas tikai pēdējie pieci notikumi — tāpēc avāriju cikls to vienmēr piepilda, un skaits nekad nepieaug. Tagad tā salīdzina jaunākās avārijas laiku, un publicēšana, kas cikliski avarē, neizdodas un atjauno iepriekšējo versiju.

Ko gaida publicēšana

Kad publicējat lietotni ar aizmugurējo daļu Mythex, jaunā versija tiek izvietota uz mašīnām mūsu hostinga platformā, un veselības pārbaude nosaka, vai publicēšana tika palaista vai neizdevās. Ja neizdevās, atsaukšana atjauno iepriekšējo versiju.

Grūtība ir tā, ka „sākts” nav tas pats, kas „apkalpo”. Platforma atzīmē mašīnu kā sāktu, tiklīdz tā ir augšā. Lietotne, kas avarē sekundi pēc palaišanas, tiek nekavējoties restartēta, un brīdi vēlāk tā atkal izskatās sākta. Tāpēc veselības pārbaude laika gaitā bija uzkrājusi vairākus slāņus:

1. Paskatīties divreiz. Pēc tam, kad mašīna izskatās sākta, īsi pagaidīt un paskatīties vēlreiz. Avārija palaišanas brīdī bieži neizturēs otro pārbaudi.
2. Meklēt avārijas ciklus. Ja platforma ziņo, ka mašīna atkārtoti avarēja un tā pārstāja to restartēt, neizdoties.
3. Skaitīt avārijas kopš publicēšanas sākuma. Divi „sākts” skatieni var pārklāties ar restartu. Tāpēc, ja kopš šīs publicēšanas sākuma notikusi kāda avārija, skatāmies vēl trešo reizi; ja avāriju ir vairāk nekā iepriekšējā skatienā, lietotne nepaliek augšā.

Trešā pārbaude bija tā, kas šeit neizdevās.

Kāpēc skaits palika nemainīgs

Informācija par avārijām nāk no katras mašīnas notikumu saraksta: starti, izejas, restarti. Platforma glabā tikai pēdējos piecus notikumus katrai mašīnai.

Iedomājieties lietotni, kas avarē 2,5 sekundes pēc katras palaišanas, kā viena no tām darīja. Katrs cikls pievieno vienu avāriju un vienu startu. Pēc dažiem cikliem saraksts ir pilns. No tā brīža katrs jaunais notikums izspiež vecu. Saraksts slīd uz priekšu, bet vienmēr satur aptuveni vienu un to pašu sajaukumu: pāris avāriju, pāris startu.

Tāpēc „cik avāriju kopš publicēšanas sākuma” katrā skatienā atgrieza vienu un to pašu skaitli. Otrais skatiens redzēja, teiksim, divas avārijas. Arī trešais redzēja divas — citas avārijas, bet tāds pats skaits. Pārbaude secināja, ka avarēšana beigusies, un publicēšanu atzina par veiksmīgu.

Tas notika trīs reizes 25. septembrī, diviem lietotnēm. Katrā gadījumā:

• publicēšana tika atzīmēta kā dzīva,
• atsaukšana netika palaista, jo nekas nebija neizdevies,
• mūsu saskaņotājs — fona darbs, kas pārbauda izvietojumus pēc fakta — izvietojumu atzina par neizdevušos dažas minūtes vēlāk,
• un viss vietnes saturs atgrieza 404.

Publicēšana, kas neizdodas laikā, ir atgūstama: atsaukšana atjauno iepriekšējo versiju. Publicēšana, kas neizdodas dažas minūtes vēlāk pēc tam, kad tika atzīta par veiksmīgu, jau ir izlaidusi savu atsaukšanu.

Kā mēs to atradām

Mēs to reproducējām lokāli: ņēmām strādājošu API, ļāvām tam aizmigt un tad to atkal publicējām ar izmaiņu, kas avarē palaišanas brīdī. Veselības pārbaude to atzina par dzīvu.

Tas atbilda produkcijai: katrā no trim publicēšanām lietotne nomira sekundes pēc katras palaišanas, tomēr pārbaudes salīdzinātais avāriju skaits starp skatieniem nekad nepieauga.

Labojums: salīdzināt jaunāko avāriju, nevis skaitu

Avāriju skaitīšanas vietā pārbaude tagad skatās jaunākās avārijas laiku kopš publicēšanas sākuma.

Ja otrais skatiens parāda jebkuru avāriju kopš publicēšanas sākuma, pārbaude gaida un skatās vēl trešo reizi. Ja jaunākā avārija trešajā skatienā ir vēlāka nekā jaunākā avārija otrajā, mašīna avarēja vēlreiz pa vidu. Tā nepaliek augšā, un publicēšana neizdodas ar ziņojumu, ka mašīna kopš publicēšanas atkārtoti avarēja un joprojām restartējas.

Tas darbojas neatkarīgi no tā, cik īss ir notikumu saraksts. Slīdošs logs ar pieciem notikumiem var paslēpt, cik daudz avāriju bija, bet nevar paslēpt to, ka tikko notika jauna — jaunākais notikums vienmēr ir tas, kas paliek.

Ar šīm izmaiņām lokālā reproducēšana uzvedas pareizi: publicēšana neizdodas un iepriekšējais attēls tiek atjaunots. Ir arī tests, kas simulē platformas uzvedību — katrs skatiens pievieno vienu avāriju un vienu startu un apgriež sarakstu līdz pieciem — un pārbauda, ka spriedums ir neveiksme, nevis izturēšana.

Ko no tā guvām

• Zini datu formu, ko skaiti. Skaitīšana pār ierobežotu sarakstu pārstāj ko nozīmēt, kad saraksts ir pilns. Ierobežojums nebija paslēpts; mēs vienkārši nebijām pārbaudi izveidojuši, ņemot to vērā.
• Dod priekšroku jautājumam „vai notika kaut kas jauns?” nevis „cik notika?” Jaunākais laika zīmogs izdzīvo saraksta apgriešanu. Kopsumma — nē.
• Vēla neveiksme ir sliktāka par agru. Tā pati salauzta būve ir nekaitīga, ja publicēšana neizdodas un atgriežas atpakaļ, bet nogalina vietni, ja vispirms tiek atzīta par veiksmi.
• Reproducē ar reāliem apstākļiem. Kļūdai vajadzēja mašīnu, kas jau bija avarējusi pietiekami daudz reižu, lai piepildītu savu notikumu sarakstu. Viena ātra avārija testā to nebūtu parādījusi.

Šis labojums sader ar citu no tās pašas dienas, kas nodrošināja, ka atsaukšana atjauno vecu versiju, nevis to izdzēš: neveiksmīga atkārtota publicēšana nekad neizdzēš darbīgu aizmugurējo daļu. Ja jūsu pašas lietotne neizdodas publicēšanā, jo avarē palaižot, publicēšanas problēmu risināšanas dokumentācija un mūsu rokasgrāmata kā labot ar MI veidotu lietotni ir labas vietas, kur sākt.