قطعی گسترده‌ی کلاود مایکروسافت؛ وابستگی کسب‌وکارها به چند پلتفرم دیجیتال زیر سؤال رفت

سرویس ابری Azure مایکروسافت و مجموعه‌ای از خدمات مرتبط با آن، در تاریخ ۱ مرداد ۱۴۰۵ (۲۳ ژوئیه‌ی ۲۰۲۶ میلادی) دچار یک قطعی گسترده شدند که ساعت‌ها طول کشید و بار دیگر توجه‌ها را به ریسک تمرکز زیرساخت دیجیتال جهانی در دست تعداد محدودی از شرکت‌های بزرگ فناوری جلب کرد.

چه اتفاقی افتاد؟

طبق گزارش رسمی مایکروسافت، این اختلال از ساعت ۱۴:۴۴ به وقت جهانی (UTC) آغاز شد؛ زمانی که یک فرآیند خودکار نگهداری معیوب (Faulty Maintenance Automation)، مسیرهای شبکه‌ای حیاتی را در منطقه‌ی West US حذف کرد و باعث بروز مشکلات اتصال گسترده در سراسر سرویس‌های ابری مایکروسافت شد. این مشکل به‌طور خاص، ترافیک ورودی و خروجی این منطقه را تحت‌تأثیر قرار داد، هرچند بارهای کاری‌ای که کاملاً درون همان منطقه ارتباط برقرار می‌کردند، آسیب ندیدند.

هزاران کاربر در سراسر آمریکای شمالی، مشکلاتی را در دسترسی به سرویس‌های کلیدی مایکروسافت گزارش کردند، از جمله:

• Outlook و Teams
• SharePoint و OneDrive
• Copilot و خود Azure
• Xbox Live و فروشگاه مایکروسافت
• برخی کاربران هم در دانلود آپدیت‌های ویندوز و نصب اپلیکیشن‌های آفیس با مشکل مواجه شدند

جدول زمانی حادثه

طبق گزارش فنی اولیه‌ی مایکروسافت (Preliminary Post-Incident Review)، روند این حادثه به این شکل بود:

• ۱۴:۴۴ UTC: عملیات نگهداری دستگاه‌ها آغاز شد و بلافاصله کاربران با اختلال مواجه شدند
• ۱۴:۴۵ UTC: تیم‌های شبکه و واکنش به حوادث مایکروسافت، بررسی ناهنجاری‌های ترافیکی را آغاز کردند
• ۱۵:۰۰ تا ۱۶:۰۰ UTC: مهندسان داده‌های تله‌متری و گزارش‌های کاربران را برای تعیین وسعت قطعی تحلیل کردند
• ۱۶:۰۰ تا ۱۷:۴۵ UTC: رفتار غیرعادی مسیریابی، مرتبط با فعالیت اخیر نگهداری شبکه شناسایی شد
• ۱۷:۴۵ UTC: مایکروسافت شروع به بازگردانی تغییرات نگهداری کرد
• ۱۸:۲۶ UTC: فرآیند بازگردانی کامل شد و ثبات شبکه بازیابی شد

به بیان ساده، از آغاز اختلال تا رفع کامل آن، نزدیک به چهار ساعت طول کشید.

این اولین‌بار نیست؛ الگویی نگران‌کننده در حال شکل‌گیری

نکته‌ی مهمی که این حادثه را جدی‌تر می‌کند، این است که این دومین قطعی بزرگ مایکروسافت ظرف کمتر از یک سال بوده است. پیش‌تر، در ۷ آبان ۱۴۰۴ (۲۹ اکتبر ۲۰۲۵ میلادی)، یک قطعی گسترده‌تر و طولانی‌تر (از ساعت ۱۵:۴۵ تا نیمه‌شب به وقت جهانی) رخ داده بود که ناشی از یک تغییر پیکربندی نادرست در سرویس Azure Front Door (شبکه‌ی توزیع محتوای مایکروسافت) بود. آن حادثه، علاوه‌بر سرویس‌های داخلی مایکروسافت مثل Xbox Live و ماینکرفت، شرکت‌های بزرگ دیگری مثل استارباکس، کپیتال وان، ودافون، فرودگاه هیترو و الاسکا ایرلاینز را هم مختل کرده بود.

جالب توجه است که آن قطعی اکتبر ۲۰۲۵، خودش تنها یک هفته پس از یک قطعی بزرگ در AWS آمازون (که خدمات محبوبی مثل اسنپ‌چت و ردیت را از کار انداخته بود) رخ داده بود — الگویی که کارشناسان را نسبت به شکنندگی زیرساخت دیجیتال جهانی نگران‌تر کرده است.

چرا کارشناسان نگرانند؟

طبق اظهارات مارک بوست، مدیرعامل شرکت ابری Civo، وقوع دو قطعی بزرگ در دو غول ابری جهان (آمازون و مایکروسافت) ظرف کمتر از یک هفته، «زنگ هشداری» برای دولت‌ها و سازمان‌ها محسوب می‌شود: «چرا نهادهای حیاتی، از سازمان مالیاتی گرفته تا بانک‌های بزرگ و فرودگاه‌ها، این‌قدر به زیرساختی وابسته‌اند که هزاران کیلومتر دورتر میزبانی می‌شود؟»

نیکی استوارت، مشاور ارشد ائتلاف Open Cloud، هم بر لزوم تنوع‌بخشی (Diversification) در انتخاب ارائه‌دهندگان ابری تأکید کرده است. طبق آمار موجود، تنها دو شرکت AWS (با حدود ۳۰ درصد سهم بازار) و Azure (با حدود ۲۰ درصد) کنترل نزدیک به نیمی از کل بازار جهانی رایانش ابری را در دست دارند — تمرکزی که به گفته‌ی کارشناسان، ریسک سیستمی قابل‌توجهی برای اقتصاد دیجیتال جهانی ایجاد می‌کند.

چرا این الگو رخ می‌دهد؟

طبق تحلیل‌های فنی منتشرشده درباره‌ی این نوع حوادث، ریشه‌ی مشترک بسیاری از این قطعی‌های بزرگ، خطای انسانی در فرآیندهای خودکار نگهداری و پیکربندی است، نه لزوماً حملات سایبری یا نقص سخت‌افزاری. طبق آمار مؤسسه‌ی Uptime Institute، نزدیک به ۷۰ درصد از قطعی‌های بزرگ زیرساخت ابری، ریشه در پیکربندی‌های پیچیده و خطای انسانی دارند — نه رویدادهای غیرقابل‌پیش‌بینی.

توصیه‌ی کارشناسان به کسب‌وکارها

با توجه به تکرار این الگو، توصیه‌های اصلی کارشناسان امنیت و زیرساخت برای کسب‌وکارهایی که به‌شدت به یک ارائه‌دهنده‌ی ابری واحد متکی هستند، شامل این موارد است:

• طراحی معماری چند‌ابری (Multi-cloud) برای کاهش وابستگی به یک ارائه‌دهنده‌ی واحد
• در نظر گرفتن این نکته که سرویس‌های احراز هویت مثل Azure AD/Entra ID اغلب نقطه‌ی شکست واحد (Single Point of Failure) برای کل اکوسیستم یک سازمان محسوب می‌شوند
• بررسی دقیق قراردادهای سطح خدمات (SLA) و در نظر گرفتن جریمه‌های مالی برای قطعی‌های طولانی‌مدت
• پذیرش این واقعیت که با تبدیل‌شدن سیستم‌های مبتنی بر هوش مصنوعی به ستون فقرات عملیات جهانی، پایداری کلاود دیگر صرفاً یک نگرانی فنی نیست، بلکه به یک دغدغه‌ی جدی در سطح مدیریت ارشد سازمان‌ها تبدیل شده است

جمع‌بندی

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