Yandex تتفق مع Selectel وK2Cloud وVK Cloud بعد الهجمات على مراكز بياناتها

اتفقت Yandex مع ثلاثة مزوّدين روس للخدمات السحابية، هم Selectel وK2Cloud وVK Cloud، على الإسراع في استضافة بيانات عملائها وخدماتهم. وجاء الاتفاق على خلفية هجمات استهدفت مراكز البيانات التابعة للشركة. ونقل موقع vc.ru الخبر في 9 أكتوبر 2026. ويؤدي منافسو Yandex في سوق السحابة في هذه الصيغة دور موقع احتياطي، وهذا من أكثر المؤشرات مباشرةً على مدى خطورة الوضع.

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

التقرير الأصلي قصير. فقد سمّى المزوّدين الثلاثة والهدف العام، وهو أن تستقبل هذه الشركات بسرعة بيانات عملاء Yandex وخدماتهم. أما كل ما عدا ذلك فغائب عن المادة المنشورة.

• الأطراف المشاركة: Yandex مصدرًا للعملاء، وSelectel وK2Cloud وVK Cloud مواقع مستقبِلة.
• ما الذي يُنقل: بيانات العملاء وخدماتهم، دون تفصيل بحسب المنتجات.
• السبب: هجمات على مراكز بيانات Yandex. ولم يُحدَّد نوع الهجوم (هجوم سيبراني أو تأثير مادي أو شيء آخر).
• ما لم يُكشف عنه: عدد العملاء المتأثرين، وحجم البيانات المنقولة، والمواعيد، والشروط التجارية، وقائمة الخدمات.

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

لماذا يساعد المنافسون بعضهم بعضًا

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

والجانب التقني للانتقال أقل وضوحًا. فلكل سحابة واجهات API مختلفة، وخدمات قواعد بيانات مُدارة مختلفة، ولها مخططاتها الخاصة في موازنة الأحمال والتخزين. وتُنقل الأجهزة الافتراضية البسيطة والتخزين الكائني بسرعة. أما خدمات Managed وقوائم الانتظار والدوال عديمة الخوادم (serverless) وآليات الهوية المرتبطة بمزوّد بعينه فتتطلب إعادة تصميم. لذلك ينبغي أن تُقرأ كلمة «الإسراع» في البيان على أنها وعد بالأولوية وبتخصيص موارد، لا ضمانًا لهجرة فورية.

وثمة مسألة منفصلة تخص أحمال الذكاء الاصطناعي. فتدريب النماذج والاستدلال (inference) يعتمدان على عناقيد GPU وعلى شبكات سريعة بين العقد، وهذه القدرات شحيحة في روسيا. أما هل ستشمل الاتفاقات نُسخ GPU ومنصات ML، فالمصدر لا يذكر ذلك.

ما العمل لعملاء الخدمات السحابية

تقدّم هذه القصة درسًا عمليًا لا يتوقف على الكيفية التي ستنتهي بها هذه الواقعة بعينها: المزوّد الواحد، حتى لو كان كبيرًا، يبقى نقطة فشل وحيدة.

• تحقّق من مكان النسخ الاحتياطية. فإن كانت في السحابة نفسها والمنطقة نفسها اللتين تعمل فيهما بيئة الإنتاج، فهذا لا يُعدّ نسخًا احتياطيًا حقيقيًا.
• صِف البنية التحتية في صورة شيفرة (Terraform وAnsible وHelm). فهذا يقلّص مدة النقل من أسابيع إلى أيام.
• تجنّب الارتباط المفرط بخدمات Managed المملوكة حيثما توجد بدائل مفتوحة: PostgreSQL وKafka وتخزين متوافق مع S3.
• اخفض مسبقًا قيمة TTL في DNS للسجلات الحرجة، وتأكد من هوية من يستطيع تغيير التوجيه في شركتك.
• أعد قراءة العقد: ما التزامات الإتاحة والاستعادة المنصوص عليها، ومن يتحمل المسؤولية عن الخسائر، وكيف تُنظَّم عملية استخراج البيانات.
• إذا كان عملاء Yandex ضمن سلسلة التوريد لديك، فاطلب منهم خطة الاستعادة المحدّثة.

وسيتحدد المسار اللاحق للأحداث بثلاثة أمور: التوضيحات الرسمية من Yandex حول طبيعة الهجمات، ومواعيد نقل الخدمات، ومدى سلاسة الهجرة لدى أول العملاء. وحتى الآن لم يتأكد سوى الاتفاق نفسه، أما تقدير حجمه فيبقى مفتوحًا.