الخلاصة

  • كان انقطاع الشبكة في 9 أكتوبر وتعطل مجمعات قاعدة البيانات في 10 أكتوبر حادثين منفصلين، لكن كليهما عطل التنفيذ عبر اعتماديات مشتركة.
  • بقيت بعض العمليات التي أخفقتها أخطاء داخلية في حالة Running؛ فلم تتلق معالجات الفشل أو الدوال الأب إشعاراً. واحتاج العملاء إلى الإلغاء أو إعادة التشغيل.

تَعِدُ «عمليات التنفيذ المستمرة» بالحفاظ على التقدم عندما تنتظر الدالة أو تتعطل، ثم استئنافها لاحقاً. لكن نقاط الحفظ وحدها لا تجيب عن أسئلة التشغيل: أين تحفظ حالة العملية؟ ما الحسابات التي تشترك في مسار الطابور؟ ما الحالة التي تسجلها المنصة عند تعطل اعتماد داخلي؟ ومن يعلم أن العملية لن تواصل من تلقاء نفسها؟ يتيح تقرير Inngest عن 9–11 أكتوبر اختبار هذه الحدود على واقعتين موثقتين.

في 9 أكتوبر عند 21:05 بالتوقيت العالمي، فقد أحد مزودي Inngest الاتصال بين مركز بياناته ومراكز Inngest الأخرى، وفقد كذلك الوصول إلى الإنترنت الصادر. ونقل التقرير أن التفسير الأولي للمزود كان خطأ أثناء تعديل إعدادات الحماية من هجمات حجب الخدمة؛ ولم تكن Inngest قد تلقت التقرير الكامل، لذلك بقي التفسير أولياً. عاد الاتصال عند 21:49. وفي اليوم التالي فقد مجمعا PgBouncer أمام قاعدة البيانات الأساسية جميع اتصالاتهما عند 14:00 ثم عند 15:30. وتوقفت جدولة العمليات ومعالجة الطوابير لدى معظم الحسابات. أعاد إجراء تخفيفي الخدمة، لكنه أضاف تأخيرات متقطعة، خصوصاً إلى مهام cron، حتى أعادت Inngest الجدولة إلى المجمعات الأصلية عند 04:17 من يوم 11 أكتوبر.

وحسّنت توجيه البوابات في 12 أكتوبر. لم تكن هذه مراحل لسبب واحد مستمر؛ فقد اختلفت آلية كل حادث وطريق استعادته.

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

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

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

أضاف الحل المؤقت مسار اعتماد جديداً. فقد أدى نقل الخدمات إلى مجمعات يشغلها مزود قاعدة البيانات بجوارها إلى استعادة المعالجة بين 16:10 و16:25. لكن هذا المسار مر عبر بوابات ترجمة عناوين الشبكة التي أسقطت بعض الاتصالات بصمت؛ وقد يظل الاستعلام عالقاً حتى 16 دقيقة قبل إخفاقه، وظهر الأثر خصوصاً في مهام cron. أعادت Inngest جدولة cron إلى المجمعات الأصلية عند 04:17 في 11 أكتوبر، ثم حسّنت توجيه البوابات في 12 أكتوبر. الإجراء التخفيفي تغيير في الطوبولوجيا أيضاً: قد يزيل عنق زجاجة ويضيف حداً زمنياً آخر يصعب رصده.

كانت الفجوة الأشد أهمية في انتقال حالة العملية. قالت Inngest إن الأخطاء الداخلية استهلكت محاولات إعادة التنفيذ المهيأة. وعندما أخفق أحد الخطوات نهائياً بسبب خطأ داخلي، بقيت بعض العمليات في Running بدلاً من الانتقال إلى Failed. فلم يعمل onFailure، ولم يصل الإخفاق إلى الدالة الأب التي تنتظر عبر step.invoke. وذكر التقرير أن تلك العمليات لن تستأنف وحدها، وأن على العملاء إلغاءها أو إعادة تشغيلها. لذلك لا يعني تعافي العمال أن كل عملية أعمال انقطعت قد وصلت إلى حالة نهائية.

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

أفادت Inngest بأنها نشرت إصلاحات: لم تعد الاستعلامات التي تنتظر اتصالاً تُلغى مع العميل؛ ويُسجل الفشل الداخلي الدائم كفشل للعملية؛ وإذا تعذرت قراءة الحالة مؤقتاً يبقى العمل في الطابور ويستأنف عندما تصبح الحالة متاحة. كما حسّنت توجيه البوابات وتحديث صفحة الحالة. أما الدمج الأوسع في مركز بيانات واحد فكان لا يزال جارياً. ولا يصف التقرير الطوبولوجيا النهائية أو ترتيبات استعادة مستقلة عند الكوارث.

المصادر