فروم بچه های تولز

حمله‌های پهپادی به سه مرکز داده یاندکس در شهرهای ساسووو، کالوگا و ولادیمیر، بخشی از زیرساخت Yandex Cloud را دچار اختلال کرد. مرکز داده ساسووو از ۸ اکتبر و مرکز داده ولادیمیر از ۱۱ اکتبر ۲۰۲۶ به‌طور دقیق خاموش شدند و بخشی از زیرساخت کالوگا نیز از مدار خارج شد. در آخرین اطلاعیه رسمی قابل‌مشاهده هنگام نگارش این مطلب، یاندکس بیان کرده بود پلتفرم ابری همچنان با ظرفیت محدود کار می‌کند و به مشتریان توصیه کرد بازیابی سرویس‌ها روی زیرساخت‌های جایگزین را تحلیل کنند.

این رویداد فقط یک قطعی موقت در یک سرور نبود. از دسترس خارج‌شدن چند مرکز داده در فاصله چند روز، ظرفیت‌های پشتیبان را تحت فشار قرار داد و نشان داد که داشتن نسخه جدید پشتیبان یا استقرار در چند ناحیه، زمانی مؤثر است که خودِ معماری بازیابی نیز در برابر خرابی هم‌زمان چند سایت آماده باشد.

آخرین وضعیت مرور‌شده: ۱۳ اکتبر ۲۰۲۶

اطلاعیه رسمی یاندکس در ۱۱ اکتبر عنوان کرد Yandex Cloud با قابلیت محدود فعالیت می‌کند. صفحه وضعیت ممکن است بعد از انتشار این مقاله تغییر کند؛ برای اطلاع از وضعیت لحظه‌ای، صفحه رسمی وضعیت Yandex Cloud را ارزیابی کنید.

نخستین اختلال در شب ۷ به ۸ اکتبر ۲۰۲۶ در منطقه دسترس‌پذیری ru-central1-b ثبت شد. یاندکس ابتدا از مشکل تأمین برق خبر داد و سپس تأیید کرد حمله یک پهپاد باعث آتش‌سوزی در مرکز داده ساسووو و توقف دقیق فعالیت آن شده است. شرکت بیان کرد کارکنان این مرکز آسیب ندیده‌اند.

یک روز بعد، یاندکس از حمله به مرکز داده دیگری در کالوگا خبر داد که بخشی از زیرساخت آن را از مدار خارج کرد. در ۱۱ اکتبر نیز مرکز داده ولادیمیر هدف حمله قرار گرفت و فعالیت آن به‌طور دقیق متوقف شد. یاندکس در همان روز خبر داد مناطق ru-central1-a و ru-central1-b در دسترس نیستند و وضعیت باقی‌مانده زیرساخت را ناپایدار ارزیابی کرد. اطلاعیه شرکتی یاندکس و گزارش رویترز هر سه حادثه را تأیید می‌کنند؛ هیچ‌یک از اطلاعیه‌های رسمی یاندکس زمان دقیقی برای بازگشت جامع تجهیزات اعلام نکرده‌اند.

شدت اختلال برای همه مشتریان و سرویس‌ها یکسان نبود. در اطلاعیه‌های ۱۱ اکتبر، کنسول و API یاندکس کلاد در دسترس انتشار یافتند؛ اما سرویس Compute فقط بخشی از ظرفیت خود را ارائه می‌کرد. بیشتر خوشه‌های پایگاه داده با دسترس‌پذیری بالا به زیرساخت جایگزین منتقل شده بودند، ولی برخی خوشه‌ها ممکن بود فقط خواندنی یا خارج از دسترس باشند.

ذخیره‌سازی سازگار با S3 پس از مشکلات اولیه نوشتن، دوباره برای خواندن و نوشتن در دسترس قرار گرفت؛ بااین‌حال احتمال کم شدن سرعت عملیات وجود داشت. Kubernetes و Yandex AI Studio نیز با محدودیت یا اختلال در برخی اجزا فعالیت می‌کردند و Yandex Monium در یکی از به‌روز رسانی‌ها خارج از دسترس روشن شد. رشد سهمیه منابع ابری هم موقتاً متوقف شده بود.

این شرحات یک نکته مهم دارد: «فعال بودن پلتفرم» لزوماً به معنی سلامت همه سرویس‌ها و همه منابع یک مشتری نیست. وضعیت هر ماشین مجازی، دیتابیس، دیسک، خوشه Kubernetes و وابستگی شبکه باید جداگانه تحلیل شود.

ارائه‌دهندگان ابری معمولاً یک ناحیه جغرافیایی را به چند Availability Zone تقسیم می‌کنند. هر منطقه دسترس‌پذیری قرار است دامنه خرابی جداگانه‌ای داشته باشد تا اختلال یک سایت، همه بارهای کاری را متوقف نکند. ru-central1-b یکی از همین مناطق در زیرساخت روسیه Yandex Cloud است که به مرکز داده ساسووو وابسته بود.

استقرار چندمنطقه‌ای زمانی مفید است که اجزای حیاتی واقعاً میان چند منطقه توزیع شده باشند. اگر ماشین‌های برنامه در چند منطقه قرار داشته باشند اما دیتابیس، بکاپ، رجیستری یا مسیر مدیریت فقط به یک منطقه وابسته باشد، همان وابستگی می‌تواند کل سرویس را متوقف کند.

تا زمان نگارش این مقاله، یاندکس گزارشی عمومی مبنی بر نابودی گسترده داده‌های همه مشتریان منتشر نکرده است؛ اما دسترس‌پذیری و سلامت داده هر مشتری باید جداگانه ارزیابی شود. خارج از دسترس بودن یک مرکز داده با ازدست‌رفتن قطعی داده‌ها یکسان نیست. داده ممکن است روی دیسک‌های خاموش باقی مانده باشد، در منطقه دیگری Replicate شده باشد یا از ویرایش پشتیبان بازیابی شود. از طرف دیگر، بدون دسترسی به زیرساخت و بدون ویرایش سالم در محل دیگر، فرصت استفاده از آن داده وجود ندارد.

اظهارنظر یاندکس درباره Yandex Pay نیز فقط به همان سرویس مربوط بود: شرکت عنوان کرد سوابق حساب‌ها در چند محل نگهداری شده و سلامت آن‌ها تحلیل شده است. این گفته را نمی‌توان به همه حساب‌ها و همه محصولات Yandex Cloud تعمیم داد.

اگر بخشی از کسب‌وکار شما به یک ارائه‌دهنده ابری یا یک دیتاسنتر وابسته است، این حادثه فرصتی برای ارزیابی عملی برنامه بازیابی است. اقدامات زیر باید پیش از بحران تعریف و آزمایش شوند:

یاندکس در اطلاعیه ۸ اکتبر، سرورهای فیزیکی اختصاصی یا Bare Metal را یکی از روش‌های جایگزین بازیابی معرفی کرد. Bare Metal می‌تواند برای راه‌اندازی سریع‌تر بارهای کاری سازگار یا تأمین ظرفیت خارج از بخش آسیب‌دیده مفید باشد؛ اما به‌تنهایی افزونگی جغرافیایی ایجاد نمی‌کند. اگر سرور فیزیکی جایگزین در همان دامنه خرابی یا بدون بکاپ و فرآیند Failover باشد، همچنان یک نقطه شکست خواهد داشت.

ارزش راهکار جایگزین به محل استقرار، ظرفیت آماده، دسترسی به داده سالم، توانایی خودکارسازی و زمان واقعی بازیابی وابسته است. بنابراین تصمیم بین Cloud، Bare Metal و معماری ترکیبی باید با یک سناریوی آزمایش‌شده همراه باشد.

معماری چندمنطقه‌ای احتمال توقف سرویس را افت می‌دهد، اما در برابر هر سناریویی مصون نیست. حمله به چند مرکز داده در فاصله کوتاه می‌تواند ظرفیت آزاد، شبکه، سهمیه منابع، سامانه پشتیبانی و سرویس‌های مدیریتی مشترک را هم‌زمان تحت فشار قرار دهد.

برای سرویس‌های حیاتی، سه مسئله باید جداگانه طراحی شوند: دسترس‌پذیری روزمره، بازیابی پس از بحران و تداوم کسب‌وکار. کلاستر HA می‌تواند خرابی یک نود را تحمل کند؛ Disaster Recovery باید خرابی یک سایت یا ارائه‌دهنده را پوشش دهد؛ و برنامه تداوم کسب‌وکار مشخص می‌کند سازمان در زمان بازیابی چگونه خدمت‌رسانی می‌کند.

اختلال یاندکس کلاد با خاموش‌شدن مرکز داده ساسووو آغاز شد و پس از آسیب به مراکز کالوگا و ولادیمیر، به یک بحران زیرساختی گسترده‌تر تبدیل شد. دو منطقه دسترس‌پذیری از مدار خارج شدند، برخی سرویس‌ها با محدودیت ادامه دادند و یاندکس استفاده از زیرساخت‌های جایگزین را به مشتریان توصیه کرد.

پیام اصلی این حادثه برای کسب‌وکارها روشن است: ویرایش پشتیبان باید خارج از دامنه خرابی نگهداری شود، بازیابی باید آزمایش شود و سرویس حیاتی نباید به یک منطقه، حساب یا ارائه‌دهنده وابستگی مفصل داشته باشد. وضعیت حادثه همچنان ممکن است تغییر کند؛ تاریخ و ساعت آخرین آپدیت رسمی را هنگام تصمیم‌گیری عملی ارزیابی کنید.

طبق اعلام رسمی یاندکس، حمله پهپادی باعث آتش‌سوزی و توقف دقیق مرکز داده ساسووو شد. در روزهای بعد مراکز داده کالوگا و ولادیمیر نیز در حمله‌های جداگانه آسیب دیدند.

در آخرین اطلاعیه رسمی قابل‌مشاهده هنگام ارزیابی این مقاله، این منطقه همچنان خارج از دسترس بود و زمان دقیقی برای بازگشت جامع آن اعلام نشده بود. برای وضعیت لحظه‌ای باید صفحه رسمی وضعیت یاندکس کلاد ارزیابی شود.

خیر. شدت اختلال میان محصولات و مشتریان متفاوت بود. برخی سرویس‌ها فعال، بعضی محدود و تعدادی خارج از دسترس بودند. سرویس‌های اصلی مصرف‌کنندگان نیز در مراحل ابتدایی حادثه به‌طور مفصل متوقف نشده بودند.

اگر بکاپ در همان منطقه یا وابسته به همان حساب و سرویس مدیریتی باشد، ممکن است هم‌زمان از دسترس خارج شود. دست‌کم یک ویرایش مستقل و قابل‌بازیابی باید خارج از دامنه خرابی نگهداری و به‌طور دوره‌ای آزمایش شود.

خیر. استقرار چندمنطقه‌ای ریسک را افت می‌دهد؛ اما خرابی هم‌زمان چند منطقه یا وابستگی مشترک در شبکه، دیتابیس، ذخیره‌سازی یا پنل مدیریت همچنان می‌تواند سرویس را مختل کند.