Menangkap Aplikasi yang Ranap Sejurus Selepas Diterbitkan

Pada 25 September, tiga publish ditandakan berjaya walaupun API aplikasi ranap beberapa saat selepas setiap boot. Oleh kerana publish itu “berjaya”, tiada rollback dijalankan. Satu semakan latar belakang kemudian menggagalkannya beberapa minit kemudian, dan keseluruhan laman bertukar kepada 404. Health check mengira ranapan dalam senarai peristiwa platform hosting, yang hanya menyimpan lima peristiwa terakhir bagi setiap mesin, jadi gelung ranapan sentiasa memenuhinya dan kiraan itu tidak pernah bertambah. Kini ia membandingkan masa ranapan terbaharu, dan publish yang berada dalam gelung ranapan akan gagal dan memulihkan versi sebelumnya.

Apa yang ditunggu oleh publish

Apabila anda menerbitkan aplikasi dengan backend di Mythex, versi baharu dilancarkan ke mesin di platform hosting kami, dan health check memutuskan sama ada publish itu berjaya menjadi live atau gagal. Jika gagal, rollback mengembalikan versi sebelumnya.

Bahagian yang sukar ialah “telah bermula” tidak sama dengan “sedang melayani”. Platform melaporkan mesin sebagai sudah bermula sebaik sahaja ia bangkit. Aplikasi yang ranap sejurus selepas boot dimulakan semula serta-merta, dan sebentar kemudian ia kembali dibaca sebagai sudah bermula. Jadi health check telah berkembang dengan beberapa lapisan dari semasa ke semasa:

1. Lihat dua kali. Selepas mesin dibaca sebagai sudah bermula, tunggu seketika dan lihat semula. Ranapan semasa boot sering gagal pada pandangan kedua.
2. Perhatikan gelung ranapan. Jika platform melaporkan bahawa mesin terus ranap dan ia berhenti cuba memulakannya semula, gagal.
3. Kira ranapan sejak publish bermula. Dua pandangan “sudah bermula” boleh merentasi satu permulaan semula. Jadi jika sebarang ranapan berlaku sejak publish ini bermula, lihat sekali lagi yang ketiga; jika terdapat lebih banyak ranapan daripada pandangan sebelumnya, aplikasi itu tidak kekal berjalan.

Pemeriksaan ketiga ialah yang gagal di sini.

Mengapa kiraan kekal rata

Maklumat ranapan datang daripada senarai peristiwa setiap mesin: permulaan, keluar dan permulaan semula. Platform hanya menyimpan lima peristiwa terakhir bagi setiap mesin.

Bayangkan aplikasi yang ranap 2.5 saat selepas setiap boot, seperti salah satu daripadanya. Setiap kitaran menambah satu ranapan dan satu permulaan. Selepas beberapa kitaran, senarai itu penuh. Dari situ, setiap peristiwa baharu menolak satu peristiwa lama. Senarai itu bergerak ke hadapan, tetapi sentiasa mengandungi campuran yang lebih kurang sama: beberapa ranapan, beberapa permulaan.

Jadi “berapa banyak ranapan sejak publish bermula” memulangkan nombor yang sama pada setiap pandangan. Pandangan kedua melihat, katakan, dua ranapan. Pandangan ketiga juga melihat dua, iaitu ranapan yang berbeza tetapi bilangan yang sama. Semakan itu membuat kesimpulan bahawa ranapan sudah berhenti, dan meluluskan publish itu.

Ia berlaku tiga kali pada 25 September, merentasi dua aplikasi. Setiap kali:

• publish ditandakan sebagai live,
• tiada rollback dijalankan, kerana tiada apa yang gagal,
• penyelaras kami, iaitu kerja latar belakang yang menyemak deployment selepas ia berlaku, menggagalkan deployment beberapa minit kemudian,
• dan keseluruhan laman mengembalikan 404.

Publish yang gagal tepat pada masanya masih boleh dipulihkan: rollback memulihkan versi sebelumnya. Publish yang gagal beberapa minit lewat, selepas diisytiharkan berjaya, sudah melangkau rollbacknya.

Bagaimana kami menemuinya

Kami mengulang semula secara tempatan: mengambil API yang berfungsi, membiarkannya tidur, kemudian menerbitkannya semula dengan perubahan yang ranap semasa boot. Health check menandakannya sebagai live.

Ia sepadan dengan pengeluaran: dalam ketiga-tiga publish, aplikasi itu mati beberapa saat selepas setiap boot, namun kiraan ranapan yang dibandingkan oleh pemeriksaan itu tidak pernah meningkat antara pandangan.

Pembetulannya: bandingkan ranapan terbaharu, bukan kiraan

Daripada mengira ranapan, pemeriksaan kini melihat masa ranapan terbaharu sejak publish bermula.

Jika pandangan kedua menunjukkan sebarang ranapan sejak publish bermula, pemeriksaan menunggu dan melihat sekali lagi yang ketiga. Jika ranapan terbaharu pada pandangan ketiga lebih lewat daripada ranapan terbaharu pada pandangan kedua, mesin itu telah ranap sekali lagi di antara keduanya. Ia tidak kekal berjalan, dan publish gagal dengan mesej yang menyatakan mesin itu ranap berulang kali sejak penerbitan dan masih dimulakan semula.

Ini berfungsi tanpa mengira betapa pendeknya senarai peristiwa itu. Tetingkap gelongsor lima peristiwa boleh menyembunyikan berapa banyak ranapan yang berlaku, tetapi ia tidak boleh menyembunyikan bahawa satu ranapan baharu baru sahaja berlaku. Peristiwa terbaharu sentiasa yang disimpan.

Dengan perubahan ini, ulangan tempatan berkelakuan betul: publish gagal, dan imej sebelumnya dipulihkan. Terdapat juga ujian yang mensimulasikan tingkah laku platform, iaitu setiap pandangan menambah satu ranapan dan satu permulaan serta memangkas senarai kepada lima, dan ujian itu menyemak bahawa keputusannya adalah kegagalan, bukan lulus.

Apa yang kami pelajari daripadanya

• Ketahui bentuk data yang anda kira. Kiraan ke atas senarai yang dihadkan berhenti bermakna apabila senarai itu penuh. Hadnya tidak tersembunyi; kami hanya belum mereka bentuk pemeriksaan itu di sekelilingnya.
• Utamakan soalan “adakah sesuatu yang baharu berlaku?” berbanding “berapa banyak yang berlaku?” Cap masa terbaharu terselamat daripada pemangkasan. Jumlah tidak.
• Kegagalan lewat lebih teruk daripada kegagalan awal. Binaan yang rosak sama juga jika publish gagal dan dipulihkan, tetapi ia menjatuhkan laman jika diisytiharkan berjaya dahulu.
• Ulang semula dengan keadaan sebenar. Pepijat itu memerlukan mesin yang sudah ranap cukup banyak kali untuk memenuhi senarai peristiwanya. Satu ranapan pantas tunggal dalam ujian tidak akan menunjukkannya.

Pembetulan ini berpasangan dengan pembetulan lain dari hari yang sama, yang memastikan rollback mengembalikan versi lama dan bukannya memadamnya: republish yang gagal tidak pernah memadam backend yang berfungsi. Jika aplikasi anda sendiri gagal diterbitkan kerana ia ranap semasa bermula, dokumentasi penyelesaian masalah publish dan panduan kami tentang menyahpepijat aplikasi yang dibina AI ialah tempat yang baik untuk bermula.