توقف مركز بيانات Yandex في كالوغا: قد تتعطل بعض الخدمات

حذّرت Yandex المستخدمين في 9 أكتوبر 2026 من أن بعض خدماتها قد تكون غير متاحة بسبب حادث في مركز البيانات في كالوغا. وأبلغ المكتب الصحفي للشركة موقع Russian Business بذلك. وتعمل فرق الطوارئ في الموقع. ولم تذكر Yandex السبب ولا حجم التداعيات ولا مواعيد الاستعادة.

ويصف RB.RU في عنوانه منشأة كالوغا بأنها «مركز بيانات آخر» للشركة توقف عن العمل. أما ما يقف وراء الحالة السابقة فلا توضحه الرسالة. لذلك لا يمكن حاليًا المقارنة بين الحادثتين ولا البحث عن صلة بينهما، إذ لا تتوافر بيانات لذلك.

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

الوقائع المعلنة قليلة، ويجب الفصل بينها بدقة.

• المصدر: المكتب الصحفي لـ Yandex، بحسب ما نقله Russian Business
• المكان: مركز بيانات الشركة في كالوغا
• الوضع: توقف العمل
• في الموقع: فرق الطوارئ
• التأثير: قد تكون بعض الخدمات غير متاحة مؤقتًا، ولم يُذكر أيّ منها
• غير معلن: السبب، ووجود مصابين من عدمه، وتقدير مواعيد الاستعادة

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

كيف يختلف الحادث المادي عن العطل البرمجي؟

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

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

ما الذي ينبغي متابعته لاحقًا

ستكشف الساعات القريبة ثلاثة أمور.

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

وينبغي أيضًا انتظار تحليل من Yandex نفسها. فبالنسبة لشركة بنية تحتية كبيرة، يكون التقرير العلني بعد الحادث (postmortem) بتسلسله الزمني واستنتاجاته أهم عادةً من البيانات الأولى.

خطوات عملية للمستخدمين والشركات

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

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

يذكّر أي حادث في مركز بيانات بأن موثوقية الخدمة لا يحددها مطوّرها وحده، بل أيضًا الطريقة التي بنى بها العميل بنيته الخاصة. فتعدد المناطق (multi-zone) له كلفة، لكنه عادةً أرخص من التوقف عن العمل.