التقاط التطبيقات التي تنهار مباشرة بعد النشر

في 25 سبتمبر، أُعلن نجاح ثلاث عمليات نشر مع أن واجهة برمجة التطبيقات كانت تنهار بعد ثوانٍ من كل إقلاع. ولأنها «نجحت»، لم يعمل أي تراجع. ثم أفشلها فحص خلفي بعد بضع دقائق، فتحوّل الموقع كله إلى خطأ 404. كان فحص الصحة يحسب الانهيارات في قائمة أحداث منصة الاستضافة، والقائمة لا تحتفظ إلا بآخر خمسة أحداث لكل آلة، فيبقيها حلقة الانهيار ممتلئة ولا يزيد العدد أبداً. أصبح الفحص الآن يقارن وقت أحدث انهيار، فيفشل النشر الذي يدخل حلقة انهيار ويعيد النسخة السابقة.

ما الذي ينتظره النشر

عندما تنشر تطبيقاً له خلفية على Mythex، تُطرح النسخة الجديدة على آلات في منصة الاستضافة لدينا، ويقرر فحص الصحة ما إذا كان النشر قد أصبح حياً أم فشل. وإذا فشل، يعيد التراجع النسخة السابقة.

الصعوبة أن «بدأ» لا تعني «يخدم». تبلغ المنصة عن الآلة بأنها بدأت بمجرد أن تعمل. والتطبيق الذي ينهار بعد ثانية من الإقلاع يُعاد تشغيله فوراً، وبعد لحظة يُقرأ من جديد على أنه بدأ. لذلك تراكمت في فحص الصحة عدة طبقات مع الوقت:

1. انظر مرتين. بعد أن تُقرأ الآلة على أنها بدأت، انتظر قليلاً وانظر من جديد. الانهيار عند الإقلاع يفشل غالباً في النظرة الثانية.
2. راقب حلقات الانهيار. إذا أبلغت المنصة أن آلة ظلت تنهار وأنها توقفت عن إعادة تشغيلها، فافشل.
3. عُدّ الانهيارات منذ بدء النشر. قد تمتد نظرتان للبدء عبر إعادة تشغيل. لذلك إذا وقع أي انهيار منذ بدء هذا النشر، فانظر نظرة ثالثة؛ وإذا كانت هناك انهيارات أكثر مما في النظرة السابقة، فالتطبيق لا يبقى قائماً.

والفحص الثالث هو الذي فشل هنا.

لماذا بقي العدد ثابتاً

تأتي معلومات الانهيار من قائمة الأحداث لكل آلة: البدء والخروج وإعادة التشغيل. وتحتفظ المنصة بـآخر خمسة أحداث فقط لكل آلة.

تخيّل تطبيقاً ينهار بعد 2.5 ثانية من كل إقلاع، كما حدث لأحدها. كل دورة تضيف انهياراً وبدءاً. وبعد دورتين أو ثلاث تمتلئ القائمة. ومن ذلك الحين، كل حدث جديد يدفع حدثاً قديماً خارجها. القائمة تتحرك إلى الأمام، لكنها تحتفظ دائماً بالخليط نفسه تقريباً: انهياران أو اثنان، وبدءان أو اثنان.

لذلك أعطى سؤال «كم عدد الانهيارات منذ بدء النشر» الرقم نفسه في كل نظرة. فرأت النظرة الثانية، مثلاً، انهيارين. ورأت النظرة الثالثة انهيارين أيضاً، وهما انهياران مختلفان، لكن بالعدد نفسه. فاستنتج الفحص أن الانهيار توقف، ونجح النشر.

وحدث ذلك ثلاث مرات في 25 سبتمبر، عبر تطبيقين. وفي كل مرة:

• أُعلن النشر حياً،
• لم يعمل أي تراجع، لأن شيئاً لم يفشل،
• أفشل المُصالِح لدينا، وهو مهمة خلفية تفحص عمليات النشر بعد وقوعها، فيفشل النشر بعد بضع دقائق،
• وأعاد الموقع كله خطأ 404.

النشر الذي يفشل في وقته قابل للاسترداد: إذ يعيد التراجع النسخة السابقة. أما النشر الذي يفشل بعد بضع دقائق من إعلانه ناجحاً، فيكون قد تخطى التراجع بالفعل.

كيف اكتشفناه

أعدنا إنتاجه محلياً: أخذنا واجهة برمجة تعمل، وتركناها تنام، ثم أعدنا نشرها بتغيير ينهار عند الإقلاع. وأعلن فحص الصحة أنها حية.

وتطابق ذلك مع الإنتاج: في كل من عمليات النشر الثلاث، كان التطبيق يموت بعد ثوانٍ من كل إقلاع، ومع ذلك لم يرتفع عدد الانهيارات الذي يقارنه الفحص بين النظرات.

الإصلاح: قارن أحدث انهيار، لا العدد

بدلاً من عدّ الانهيارات، ينظر الفحص الآن إلى وقت أحدث انهيار منذ بدء النشر.

إذا أظهرت النظرة الثانية أي انهيار منذ بدء النشر، ينتظر الفحص وينظر نظرة ثالثة. وإذا كان أحدث انهيار في النظرة الثالثة أحدث من أحدث انهيار في النظرة الثانية، فإن الآلة انهارت مرة أخرى في الأثناء. وهي لا تبقى قائمة، فيفشل النشر برسالة تقول إن الآلة انهارت مراراً منذ النشر وما زالت تعيد التشغيل.

هذا يعمل بغض النظر عن قصر قائمة الأحداث. فالنافذة المنزلقة من خمسة أحداث قد تخفي عدد الانهيارات، لكنها لا تستطيع أن تخفي أن انهياراً جديداً قد وقع للتو، لأن الحدث الأحدث هو الذي يبقى دائماً.

مع هذا التغيير، يتصرف الإعادة المحلية كما ينبغي: يفشل النشر، وتُستعاد الصورة السابقة. وهناك أيضاً اختبار يحاكي سلوك المنصة، فكل نظرة تضيف انهياراً وبدءاً وتقص القائمة إلى خمسة، ويتحقق من أن الحكم فشل وليس نجاحاً.

ما استخلصناه

• اعرف شكل البيانات التي تعدّها. العد على قائمة محدودة يفقد معناه عندما تمتلئ القائمة. لم يكن الحد مخفياً، لكننا لم نصمم الفحص حوله.
• فضّل سؤال «هل حدث شيء جديد؟» على «كم حدث؟». الطابع الزمني للأحدث يبقى بعد القص، أما المجموع فلا يبقى.
• الفشل المتأخر أسوأ من المبكر. البناء المعطوب نفسه لا يضر إذا فشل النشر وتراجع، لكنه يُسقط موقعاً إذا أُعلن نجاحه أولاً.
• أعد الإنتاج بالظروف الحقيقية. احتاج الخلل إلى آلة انهارت من قبل ما يكفي لملء قائمة أحداثها. ولم يكن انهيار سريع واحد في اختبار ليُظهره.

يكمل هذا الإصلاح إصلاحاً آخر من اليوم نفسه، ضمن الاستعادة بحيث يعيد التراجع النسخة القديمة بدلاً من حذفها: إعادة النشر الفاشلة لا تحذف خلفية تعمل أبداً. وإذا فشل تطبيقك الخاص في النشر لأنه ينهار عند البدء، فإن وثائق استكشاف أخطاء النشر ودليلنا عن تصحيح تطبيق بناه الذكاء الاصطناعي مكانان جيدان للبدء.