تحليل ما بعد المشكلة: حدث خطأ غير متوقع 500 أثناء تسجيل دخول المستخدم

الملخص#

في 18 يوليو 2024، واجه Logto Cloud انقطاعًا في الخدمة مع خطأ خادم داخلي 500 من خدمات المصادقة.

• المستخدمون المتأثرون: جميع مستخدمي السحابة الذين يحاولون المصادقة
• المناطق المتأثرة: أوروبا والولايات المتحدة
• الشدة: حرجة، تعطل تجربة تسجيل الدخول للمستخدمين

السبب الجذري#

أثناء نشر حديث للسحابة، أحدث تغيير جذري في مخطط قاعدة البيانات فشل API تجربة تسجيل الدخول أثناء الانتقال بين بيئات التدريج والإنتاج.

الجدول الزمني#

• 2024-07-18 08:57 (UTC): تم نشر التحديثات على Logto Cloud
• 2024-07-18 09:28 (UTC): أبلغ أول مستخدم عن خطأ 500
• 2024-07-18 09:31 (UTC): اعترفت فريق التطوير بالمشكلة وبدأ التحقيق
• 2024-07-18 09:32 (UTC): تم حل المشكلة تلقائيًا
• 2024-07-18 09:40 (UTC): تحديد السبب الجذري

تحليل الحادث#

ما هو التغيير الجذري في قاعدة البيانات، ولماذا؟#

نحن نقوم حاليًا بتطوير ميزة جديدة تسمى "أحضر واجهتك الخاصة" ، والتي تتيح للمستخدمين تخصيص تجربة تسجيل الدخول إلى Logto باستخدام صفحات الويب الخاصة بهم. تتطلب هذه الميزة عمودًا جديدًا في جدول sign-in-exp لتخزين إعدادات الواجهة المخصصة.

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

لسوء الحظ، لم يكن هذا التغيير متوافقًا مع الخلف، مما تسبب في فشل طلبات API من التعليمات البرمجية القديمة عند التواصل مع قاعدة البيانات الجديدة.

كيف نقوم بنشر نسخة جديدة من Logto Cloud؟#

عند نشر نسخة جديدة من Logto Cloud، نقوم أولاً بنشرها في بيئة التدريج ثم نقوم بتبديل بيئات التدريج والإنتاج. العملية كما يلي:

1. تشغيل نص تعديل قاعدة البيانات وتحديث قاعدة البيانات.
2. نشر التعليمات البرمجية الجديدة على خادم التدريج.
3. تشغيل خادم التدريج وإجراء الاختبارات.
4. تبديل خوادم التدريج والإنتاج بحيث يصبح "التدريج" هو "الإنتاج"، مما يتيح للمستخدمين الوصول إلى النسخة الجديدة بدون توقف.

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

كان هذا هو السبب الجذري للحادث والسبب في أنه تم حله تلقائيًا في 35 دقيقة.

لماذا لم يتم معالجة ذلك في عملية مراجعة التعليمات البرمجية؟#

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

هذه المرة، تأخر إصدار الميزة، وانتشرت تغييرات المخطط عبر إصدارين. افترض المطور أن إخفاق CI كان متوقعًا وأبلغ المراجعين بأنه لا ينبغي أن يعوق دمج PR.

كان هناك فجوة في التواصل بالتأكيد، وأخيرًا تم دمج PR دون توفير أي دعم لازم للتوافق مع الخلف.

الدروس المستفادة#

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

التدابير التصحيحية والوقائية#

• ✅ فحص CI لتوافق قاعدة البيانات مع الخلف مطلوب الآن لاجتيازه قبل دمج PR الذي يحتوي على تغيير في المخطط.
• ✅ التأكيد على أهمية التوافق مع الخلف بين أعضاء الفريق.