Yandex Go تستعيد خدمة طلب سيارات الأجرة بحلول 19:40 بعد عطل تزامن مع أضرار في مراكز البيانات

في يوم الجمعة 9 أكتوبر 2026، واجه مستخدمو Yandex Go مشكلات عند طلب سيارات الأجرة. وظهرت التقارير عن العطل في ظل معلومات عن أضرار لحقت بمراكز بيانات الشركة. وعند 19:40 أعلنت Yandex أن الخدمة عادت إلى العمل. وقد نشر موقع vc.ru مادته عند 19:35، أي إن نحو خمس دقائق فقط فصلت بين النشر والإعلان عن استعادة الخدمة. ولا يمكن من هذه المعطيات تحديد المدة الفعلية للعطل.

ما المعروف حتى الآن

التفاصيل المعلنة قليلة. وفيما يلي القائمة الكاملة لما تأكد:

• الخدمة: Yandex Go، طلب سيارات الأجرة.
• العَرَض: أفاد المستخدمون بصعوبات في طلب الرحلة.
• السياق: أضرار لحقت بمراكز بيانات Yandex (هكذا وُصفت الحادثة في عنوان vc.ru).
• الحالة: عادت الخدمة إلى العمل عند 19:40، بحسب ما أعلنت الشركة.
• غير مكشوف: سبب الأضرار، وعدد المواقع المتأثرة، والوقت الدقيق لبداية العطل ونهايته، وتأثيره في الخدمات الأخرى ضمن المنظومة.

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

لماذا تتأثر خدمات سيارات الأجرة بالبنية التحتية إلى هذا الحد

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

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

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

ماذا يفعل المستخدمون والشركات

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

أما الشركات التي تبني منتجاتها على بنية تحتية سحابية، فالخلاصة بالنسبة إليها أكثر عملية:

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

والخطوة التالية على Yandex: أن توضح ما حدث لمراكز البيانات، وما إذا تأثرت خدمات أخرى، وما الإجراءات التي اتُخذت. ودون ذلك سيصعب على المراقبين الخارجيين تقييم مدى متانة البنية التحتية للشركة.