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

كل عمليات الدخول في MasterLinux تمرّ عبر خدمة المصادقة ml-auth (auth.masterlinux.lab):

• في الموقع، ببوسكورة: بوابة الواجهات nginx المسمّاة ml-gw-01 (العنوان الافتراضي النشط، keepalived) و نسختها الاحتياطية ml-gw-02؛ وهي تمرّر الطلبات إلى AWS عبر Direct Connect؛
• في AWS (eu-west-3): الـ Deployment المسمّى ml-auth على EKS (النطاق auth، توسيع تلقائي من 6 إلى 40 حاوية pod) وقاعدة بياناته RDS PostgreSQL Multi-AZ المسمّاة ml-auth-db؛
• العملاء: التطبيق المحمول للطلاب، ومحطات الوكالات الـ 14 (إعدادات إعادة المحاولة توزّعها AWS AppConfig) ودفعة مزامنة الشركاء، وهي مهمة Cloud Run في مشروع GCP المسمّى masterlinux-batch.

على الساعة 06:09، تسببت صيانة من AWS في انتقال Multi-AZ لقاعدة ml-auth-db: 3 دقائق دون قاعدة بيانات. ومنذ 06:12، صارت RDS متاحة. لكن المصادقة لم تتعافَ أبدًا: البوابة تعيد أخطاء 502 و504، والتوسيع التلقائي صعد إلى 40 حاوية تعيد التشغيل بلا توقف، والحركة الواردة أعلى بعشر مرات من المعتاد. على الساعة 08:00، كان الفريق الليلي قد «أعاد تشغيل كل الحاويات» و «أضاف عُقدًا»، دون جدوى. يقترح مدير العمليات «إعادة نقل القاعدة مرة أخرى، احتياطًا»؛ ويريد فريق التطبيق «الصعود إلى 80 حاوية».

أنت مهندس الموثوقية (SRE) المناوب، على ml-bastion (kubectl على العنقود eks-masterlinux-prod، وAWS CLI v2، وgcloud، وpsql للقراءة فقط)، مع وصول SSH إلى ml-gw-01 وml-gw-02. دليل تخفيف الحِمل الخاص بالبوابة يحمل الاسم RB-AUTH-07.