انهيار Railway: حين يُوقف مزوّد سحابي واحد بنيتك التحتية بأكملها

ثماني عشرة دقيقة استغرقت ثماني ساعات لإصلاحها

في الساعة 22:10 UTC من يوم 19 مايو 2026، رصدت أنظمة مراقبة Railway إخفاقات في فحص صحة واجهة برمجة التطبيقات (API). في غضون دقائق، بدأت لوحة تحكم Railway ترجع أخطاء 503 وأخذت طلبات تسجيل الدخول تفشل على نطاق المنصة بأكملها. بحلول الساعة 22:19 UTC، حدّد الفريق السبب: وضع Google Cloud حساب الإنتاج الخاص بـ Railway في حالة مقيّدة ضمن ما وصفته الشركة لاحقاً بأنه إجراء تلقائي على مستوى المنصة، دون إشعار مسبق للعملاء المتضررين.

أعاد GCP الوصول إلى الحساب بحلول الساعة 22:29 UTC — فلم تدم القيود سوى 18 دقيقة. لكن التعافي استمر حتى الساعة 06:14 UTC من صباح اليوم التالي. هذه الفجوة بين “استعادة الحساب” و”استعادة الخدمات” ليست استثناءً. إنها البنية المعمارية تخبرك بشيء.

Railway ليست شركة صغيرة. كانت المنصة تعالج أكثر من 50 مليون عملية بناء (build) شهرياً في مايو 2026، بأسطول بنية تحتية يمتد عبر 8 مواقع في 4 مناطق حول العالم على Railway Metal، إضافةً إلى سعة فائضة على AWS وGCP. المنافسون في مجال المنصات كخدمة — إذ بلغت قيمة Render 1.5 مليار دولار عام 2024 — يُبرزون الحجم التجاري المعرّض للخطر حين تتوقف هذه المنصات.

في الساعة 22:35 UTC — أي بعد 15 دقيقة فحسب من فرض القيود — بدأت مسارات التوجيه المخزّنة مؤقتاً في الانتهاء. بدأت أعباء العمل التي تعمل على Railway Metal وAWS، والتي لم تتأثر بقيود GCP، فجأةً في إعادة أخطاء 404. لقد استهلكت إخفاقٌ نشأ عند مزود سحابي واحد الأسطولَ بأكمله.

كيف انهار نظام موزَّع عبر خيط واحد

تُشغّل Railway ما تُسوّقه على أنه شبكة شبكية متعددة السحابة (multi-cloud mesh): أعباء عمل العملاء موزعة عبر Railway Metal وAWS وGCP، مترابطة بطبقة توجيه حافّة. في بنية متعددة السحابة حقيقية، يجب أن يُضعف فقدان أحد المزوّدين القدرةَ لا أن ينهي الخدمة. ما كشفه حادث Railway هو أن بنيتهم كانت متعددة السحابة في مستوى البيانات (data plane) لكنها أحادية السحابة في مستوى التحكم (control plane).

كان مستوى التحكم — واجهة برمجة التطبيقات (API) التي تُنسّق جداول التوجيه وتُصادق الطلبات وتُدير قابلية اكتشاف أعباء العمل عبر الشبكة — مستضافاً حصراً على آلات GCP. حين توقفت تلك الآلات، لم يعد للشبكة مصدر موثوق يحدد وجهة حركة المرور. اشترى ذاكرة التخزين المؤقت للتوجيه نحو 15 دقيقة قبل أن يصبح الصمت منهجياً.

يوضّح التسلسل الوارد في تقرير الحادث الرسمي ذلك بشكل ملموس:

• 22:10 UTC — ترصد المراقبة إخفاقات فحص صحة API
• 22:11 UTC — اللوحة ترجع 503؛ تبدأ إخفاقات تسجيل الدخول
• 22:19 UTC — تحديد السبب الجذري: تعليق حساب GCP
• 22:22 UTC — تقديم تذكرة P0؛ التواصل مع مدير حساب GCP
• 22:29 UTC — استعادة الوصول إلى حساب GCP
• 22:35 UTC — انتهاء صلاحية ذاكرة التخزين المؤقت لتوجيه الحافة؛ بدء إخفاق أعباء العمل على AWS وMetal
• 01:30 UTC — بدء تعافي حالات الحوسبة
• 01:38 UTC — استعادة حركة مرور الحافة والشبكة
• 02:47 UTC — تحديد GitHub معدل تكاملات OAuth والـ webhooks الخاصة بـ Railway بسبب أحجام إعادة المحاولة
• 04:00 UTC — تأكيد تشغيل API ولوحة التحكم وOAuth
• 06:14 UTC — انتقال الحادث إلى مرحلة المراقبة؛ الإعلان عن الحل

يستحق تحديد معدل GitHub في الساعة 02:47 UTC التوقف عنده. كانت عاصفة إعادة المحاولة لدى Railway خلال التعافي ضخمة بما يكفي لتشغيل الحماية الخارجية للمنصة — إخفاق ثانوي ناجم عن التعافي ذاته لا عن GCP. كما أُعيدت تعيين سجلات قبول شروط الخدمة عبر المنصة، ما استوجب على المستخدمين قبولها من جديد عند تسجيل الدخول التالي.

كما أشار المعلّقون على Hacker News في خيط النقاش الرئيسي، لم يكن هذا نمط إخفاق جديداً في GCP. “امتد هذا الإجراء إلى حسابات كثيرة داخل Google Cloud. نظراً لكونه إجراءً على مستوى المنصة، لم يكن هناك تواصل استباقي” — صياغة مستقاة من تقرير ما بعد الحادث (post-mortem) الخاص بـ Railway، تردّد صدى نمط يُوجَّه لـ Google النقد بسببه منذ عام 2008 على الأقل: أنظمة تلقائية قادرة على سحب الوصول إلى منصة كبرى دون مراجعة بشرية أو إنذار مسبق.

ما يجب على فرق البنية التحتية فعله

حادث Railway ليس قصة سوء حظ. إنه أداة تشخيصية. يجب على كل فريق يُشغّل بنية تحتية موزعة أن يتساءل الآن عما إذا كانت بنيته “متعددة السحابة” تشترك في ثغرة Railway الهيكلية: أعباء عمل موزعة عبر المزودين، لكن مستوى تحكم يعيش ويموت عند أحدهم.

1. ارسم خريطة تبعياتك الخفية لمزود واحد

أخطر التبعيات هي تلك غير المُصنَّفة “أحادية المزوّد”. لم تكن تبعية مستوى التحكم لدى Railway إغفالاً في التصميم — بل كانت قراراً متعمداً اتُّخذ خلال التوسع السريع. هاجر الفريق أعباء عمل العملاء إلى شبكة متعددة السحابة مطلع عام 2025 لكنه أبقى على API وقاعدة البيانات في GCP لأنها كانت تعمل وبدت عملية الترحيل أقل أولوية.

أجرِ تدقيقاً منهجياً للتبعيات: اسرد كل مكوّن في مسار التحكم لديك (بوابات API، وسجلات الخدمات، وجداول التوجيه، ومديري الأسرار، ومزودي الهوية) وحدّد أي حساب أو مزود سحابي مرتبط بكل منها. جدول بيانات بسيط بأعمدة للمكوّن والمزوّد ومعرف الحساب و”يفشل إذا توقف المزوّد X” يكفي. كان إشكال Railway سيبدو واضحاً فوراً في هذا التنسيق: API مستوى التحكم ← حساب إنتاج GCP ← نقطة إخفاق واحدة.

أولِ اهتماماً خاصاً لقواعد البيانات المُدارة وطبقات التخزين المؤقت. كانت مثيل CloudSQL الخاص بـ Railway المرساة الصامتة. حين توقف GCP، تبعته قاعدة البيانات — وبدون قاعدة البيانات، حتى مستوى التحكم الذي يعمل على بنية تحتية أخرى لن يجد ما يقرأ منه. النسخ المتطابق لقاعدة البيانات عبر السحابة أو قاعدة بيانات مُدارة محايدة للمزوّد (Neon أو PlanetScale أو CockroachDB) هو الحل المعماري الصحيح هنا، لا مجرد نقل API.

2. اختبر استقلالية مستوى التحكم صراحةً

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

استمرت پاندRailway 8 ساعات لا لأن GCP كان متوقفاً 8 ساعات — بل كان متوقفاً 18 دقيقة — لكن لأن التعافي استلزم استعادة الأقراص الدائمة يدوياً (23:09–23:54 UTC)، وانتظار إعادة تشغيل حالات الحوسبة (اكتملت نحو 01:30 UTC)، وإعادة بناء حالة التوجيه التي كانت ذاكرة التخزين المؤقت تُقدّمها. لم يكن شيء من هذا مؤتمتاً. كان تمرين هندسة الفوضى (chaos engineering) الذي يُعلّق أو يعزل حساب سحابة مستوى التحكم عمداً سيكشف عن هذه الثغرة في التعافي قبل أشهر من 19 مايو.

أضف سيناريو “حساب مزوّد معلّق” إلى runbook الخاص بك. إنه يختلف عن “منطقة غير متاحة” ويستوجب تخفيفات مختلفة: وصول خارج النطاق إلى بيانات التكوين، ومستوى تحكم تجاوز فشل مُعدّ مسبقاً لدى مزوّد وحساب منفصلَين، وخطوات يدوية موثّقة لا تفترض توافر API.

3. تفاوض على اتفاقيات مستوى خدمة التعليق ومسارات التصعيد مع مزودي السحابة

قدّمت Railway تذكرة P0 وتواصلت مع مدير حسابها في غضون 3 دقائق من تحديد السبب الجذري (22:22 UTC). استُعيد الوصول إلى الحساب بعد 7 دقائق (22:29 UTC). هذه سرعة استجابة سريعة بمعايير الصناعة — لكنها تركت Railway مع إخفاق تتالٍ لم تستطع حلّه بالكامل طوال قرابة 8 ساعات.

الدرس ليس أن Railway كان ينبغي لها الاتصال بشكل أسرع. الدرس هو أن مسار التصعيد يجب الاتفاق عليه قبل الحادث. يجب أن تشمل اتفاقيات السحابة للمؤسسات اتفاقيات مستوى خدمة (SLA) صريحة لحل التعليق على مستوى الحساب (لا مجرد “اتفاقيات مستوى خدمة توافر الخدمة”)، وجهة اتصال تصعيد مسمّاة يمكن الوصول إليها خارج ساعات العمل، والتزاماً تعاقدياً بأن إجراءات التعليق الآلية ستتضمن إشعاراً بشرياً موازياً. بدون هذه الشروط مكتوبة، تعتمد على نية طيبة قائمة انتظار الاستجابة للحوادث لدى أحد الهايبرسكيلرز.

يذكر تقرير ما بعد الحادث لدى Railway أن Google Cloud “لم يتواصل بشكل استباقي” بسبب كون الإجراء على مستوى المنصة. هذه هي الجملة التي يجب أن تظهر في كل عقد سحابي مُعاد التفاوض عليه كبند للوقاية.

الدرس الهيكلي: مستويات التحكم ليست تفصيلاً في البنية التحتية

كان رد Railway العلني على الانقطاع مباشراً: “الخدمة المرئية للمستخدمين هي Railway لا Google Cloud، لذا فإن المسؤولية عن التوافر — بما في ذلك اختيار المزوّد — تقع على عاتق Railway.” هذه الصياغة صادقة وصحيحة — وتنطبق على كل مؤسسة تُشغّل بنية تحتية على أي هايبرسكيلر.

أمضت الصناعة سنوات في النقاش حول “متعددة السحابة” كاستراتيجية لتحسين التكاليف أو الاستفادة من نفوذ المزوّد. يُعيد حادث Railway صياغة النقاش. متعددة السحابة ليست استراتيجية تجارية في المقام الأول؛ إنها استراتيجية مرونة. والمرونة تقتضي أن يكون مستوى التحكم — الطبقة التي تُخبر كل طبقة أخرى بما تفعله وأين تذهب — مستقلاً حقاً عن حالة حساب أي مزوّد واحد.

هذا أصعب مما يبدو. تحتاج مستويات التحكم إلى وصول منخفض الكمون إلى الحالة، مما يدفع نحو المركزية. كما أنها أصعب اختباراً لإخفاقات على مستوى المزوّد مقارنةً بإخفاقات البنية التحتية. لكن حادث Railway يُبيّن تكلفة تأجيل هذا العمل المعماري. دامت قيود GCP 18 دقيقة. دام تأثيرها على الأعمال 8 ساعات. سيدوم التأثير على السمعة — الظهور في كل نشرة بنية تحتية، وتوليد خيوط متعددة على الصفحة الأولى لـ Hacker News، وحثّ منافسين مثل Northflank على نشر مقارنات — وقتاً أطول بكثير.

تعمل Railway الآن على إعادة بناء بنيتها المعمارية للقضاء على تبعية مستوى التحكم على GCP: توزيع قاعدة البيانات عالية التوافر عبر AWS وRailway Metal، وإزالة خدمات GCP من المسار الساخن لمستوى البيانات، وتطوير تصميم جديد لمستوى التحكم مستقل عن أي مزوّد واحد. هذه قرارات صحيحة. والسؤال الذي يواجه كل فريق بنية تحتية آخر هو ما إذا كان سيتخذ القرارات ذاتها قبل حادث التعليق المؤلف من 18 دقيقة الخاص به.

الأسئلة الشائعة

المصادر والقراءات الإضافية

• تقرير الحادث: 19 مايو 2026 — تعليق حساب GCP — مدونة Railway
• تقرير الحادث: Railway محجوبة من Google Cloud — Hacker News
• تقرير الحادث: 19 مايو 2026 — تعليق GCP — Hacker News
• انقطاع GCP 19 مايو 2026 — Railway Central Station
• انقطاع تطبيق Railway: أين تستضيف مشاريعك — مدونة Northflank
• Google Cloud تغلق Railway فجأةً — SecurityOnline