قطعی جهانی مایکروسافت در نوامبر ۲۰۲۶؛ نقصی قدیمی چگونه اوت‌لوک، تیمز و کوپایلوت را از کار انداخت؟
یک نقص فنی قدیمی در زیرساخت شبکه مایکروسافت، با اعمال تغییری تازه فعال شد و قطعی گسترده‌ای را در سرویس‌های این شرکت رقم زد. اختلالی که از ۱۲ نوامبر ۲۰۲۶ آغاز شد، دسترسی کاربران به سرویس‌هایی مانند اوت‌لوک، تیمز و کوپایلوت را در ده‌ها کشور مختل کرد و سازمان‌هایی از بیمارستان‌ها و دادگاه‌ها تا نهادهای دولتی و اپراتورهای بورس را به استفاده از روش‌های ارتباطی جایگزین واداشت.
این حادثه بار دیگر نشان داد وابستگی گسترده به زیرساخت‌های ابری، در کنار مزایای فراوان، می‌تواند با خرابی یک مؤلفه مشترک، بخش‌های مختلف یک سازمان را هم‌زمان تحت تأثیر قرار دهد. ماجرای دادگاه منچستر که کارکنانش برای ادامه مکاتبات به دنبال دستگاه فکس می‌گشتند، به یکی از نمادهای این قطعی تبدیل شد.
قطعی مایکروسافت در ۱۲ نوامبر ۲۰۲۶ چقدر گسترده بود؟
اختلال از حدود ظهر پنجشنبه ۱۲ نوامبر به وقت شرق آمریکا آغاز شد. کاربران در نقاط مختلف جهان گزارش دادند که نمی‌توانند وارد صندوق ایمیل اوت‌لوک شوند یا پیام‌هایشان در پوشه ارسال باقی می‌ماند.
بر اساس گزارش آسوشیتدپرس، سامانه داون‌دیتکتور در کمتر از یک ساعت از ۷۴ کشور و منطقه گزارش اختلال دریافت کرد. تعداد گزارش‌های مربوط به اوت‌لوک در اوج حادثه به بیش از دو هزار برابر سطح معمول رسید. همچنین به نقل از ان‌بی‌سی، مجموع گزارش‌های کاربران درباره پنج سرویس مایکروسافت در مقطعی به حدود ۱۹ هزار و ۶۵۰ مورد در دقیقه افزایش یافت؛ درحالی‌که این رقم در یک پنجشنبه عادی کمتر از ۱۵ گزارش در دقیقه بود.
البته داون‌دیتکتور گزارش‌هایی را ثبت می‌کند که کاربران به‌صورت داوطلبانه ارسال می‌کنند و آمار آن لزوماً تعداد واقعی افراد آسیب‌دیده را نشان نمی‌دهد. این داده‌ها بیشتر برای درک سرعت گسترش و گستره جغرافیایی اختلال کاربرد دارند. مایکروسافت نیز تعداد دقیق کاربران متأثر از حادثه را اعلام نکرد.
اهمیت موضوع از آنجا بیشتر می‌شود که به گفته مایکروسافت، بیش از ۴۳۰ میلیون نفر از برنامه‌های Microsoft 365 استفاده می‌کنند. البته همه این کاربران با اختلال روبه‌رو نشدند، اما گستردگی وابستگی سازمان‌ها به این مجموعه، تأثیر حادثه را فراتر از مشکل دسترسی به ایمیل برد.
نقص فنی چگونه سرورهای مایکروسافت را از کار انداخت؟
مایکروسافت در توضیحات اولیه از افزایش بار زیرساخت در چند منطقه خبر داد؛ اما بعدتر مشخص شد مسئله اصلی افزایش ناگهانی ترافیک نبوده است. تعداد زیادی از سرورها به‌طور غیرمنتظره از دسترس خارج شده بودند و درخواست‌های کاربران به سرورهای باقی‌مانده منتقل می‌شد.
شکست سرورها در آزمون سلامت
در زیرساخت‌های ابری، سامانه‌های خودکار به‌طور مداوم وضعیت سرورها را بررسی می‌کنند. اگر سروری نتواند پاسخ مناسب بدهد، از چرخه دریافت درخواست خارج می‌شود تا کاربران به زیرساخت معیوب متصل نشوند.
در جریان این حادثه، سرورهای Exchange Online، سرویس سازمانی ایمیل مایکروسافت، یکی پس از دیگری در بررسی سلامت شکست خوردند. مهندسان ابتدا احتمال دادند روش ارزیابی سلامت دچار مشکل شده باشد و برای گروهی از سرورها شیوه دیگری را آزمایش کردند. برخی سرورها به چرخه خدمات برگشتند، اما به‌محض دریافت ترافیک واقعی دوباره از پاسخ‌گویی بازماندند.
بررسی‌های بعدی نشان داد فرایند مسئول برقراری اتصال امن روی سرورها، زیر فشار درخواست‌ها دچار مشکل می‌شد و مصرف پردازنده را به‌شدت افزایش می‌داد. در نتیجه، هر سروری که از کار می‌افتاد، بار بیشتری به سرورهای سالم منتقل می‌کرد و همین فشار می‌توانست سرورهای بعدی را نیز از دسترس خارج کند.
ریشه مشکل به یک ارتقای قدیمی شبکه بازمی‌گشت
مایکروسافت روز جمعه ۱۳ نوامبر اعلام کرد منشأ اختلال به نقصی فنی در جریان یکی از ارتقاهای قبلی ظرفیت شبکه بازمی‌گردد. این نقص مدتی در زیرساخت باقی مانده بود، اما پس از اعمال تغییر تازه‌ای در تنظیمات شبکه فعال شد.
به این ترتیب، فاصله زمانی میان ایجاد نقص و بروز اختلال، شناسایی علت حادثه را دشوار کرده بود. مهندسان در ابتدا به دنبال تغییرات تازه می‌گشتند، درحالی‌که ریشه مشکل به فرایندی قدیمی‌تر مربوط می‌شد.
تام وارن، خبرنگار ارشد ورج، به نقل از منابع خود ارتباط این اتفاق را با تغییرات پیکربندی Azure Virtual Network، سرویس شبکه مجازی ابری مایکروسافت، مطرح کرد. بااین‌حال، در زمان انتشار گزارش، شرکت جزئیات فنی این ارتباط را به‌طور رسمی تأیید نکرده بود.
گستردگی قطعی احتمال حمله سایبری را نیز مطرح کرد، اما مایکروسافت اعلام کرد این حادثه ناشی از مشکل فنی بوده و ارتباطی با حمله سایبری، حمله محروم‌سازی از سرویس یا فعالیت عوامل هوش مصنوعی نداشته است.
چرا اختلال اوت‌لوک، تیمز و کوپایلوت را هم‌زمان درگیر کرد؟
کاربران معمولاً اوت‌لوک، تیمز و کوپایلوت را سه محصول مستقل می‌بینند؛ اما این سرویس‌ها برای بخشی از قابلیت‌های خود به زیرساخت‌های مشترک وابسته‌اند. یکی از مهم‌ترین این زیرساخت‌ها Exchange Online است که علاوه بر ایمیل، اطلاعات تقویم، مخاطبان و دعوت‌نامه‌های جلسات را نیز مدیریت می‌کند.
به همین دلیل، اختلال در این سرویس فقط ارسال و دریافت ایمیل را تحت تأثیر قرار نداد. برای نمونه، کاربران تیمز در برخی موارد همچنان می‌توانستند تماس برقرار کنند یا در گفت‌وگوهای گروهی شرکت داشته باشند، اما تنظیم جلسه جدید یا مشاهده قرارهای تقویم با مشکل روبه‌رو می‌شد.
کوپایلوت نیز ممکن بود در دسترس باشد، اما برای پاسخ‌گویی به درخواست‌هایی که به ایمیل‌ها، فایل‌ها یا اطلاعات تقویم نیاز داشتند، با محدودیت مواجه می‌شد. به بیان دیگر، اختلال در یک زیرساخت مشترک، قابلیت‌های وابسته در چند محصول متفاوت را هم‌زمان مختل کرد.
فهرست سرویس‌های آسیب‌دیده به اوت‌لوک و تیمز محدود نماند و بخش‌هایی از SharePoint، OneDrive، Intune و Defender نیز با اختلال مواجه شدند. مایکروسافت توضیح داد سرویس‌هایی که به Exchange Online وابستگی داشتند، بیشتر تحت تأثیر قرار گرفتند؛ درحالی‌که بخش‌های مستقل از این زیرساخت توانستند به فعالیت ادامه دهند.
قطعی مایکروسافت چه تأثیری بر بیمارستان‌ها و دادگاه‌ها گذاشت؟
زمان آغاز حادثه، شرایط متفاوتی برای مناطق مختلف جهان ایجاد کرد. وقتی اختلال در آمریکا شروع شد، بخش زیادی از اروپا به پایان روز کاری نزدیک می‌شد و آسیا نیز در ساعات شب قرار داشت. با آغاز صبح جمعه در این مناطق، بسیاری از کارکنان با سرویس‌هایی روبه‌رو شدند که هنوز به وضعیت عادی بازنگشته بودند.
اختلال در خدمات درمانی بریتانیا
در بریتانیا، بخشی از نظام سلامت با مشکلات جدی مواجه شد. سامانه NHS.net Connect که بیش از یک میلیون نفر از کارکنان درمان برای ایمیل، تقویم، جلسات و فایل‌ها از آن استفاده می‌کنند، بر زیرساخت مایکروسافت متکی است.
بر اساس گزارش گاردین، صدها بیمارستان، مطب پزشک عمومی و مرکز درمانی با اختلال روبه‌رو شدند. برخی کارکنان امکان ورود به سامانه یا تبادل اطلاعات بیماران را نداشتند و در مواردی نوبت‌ها و عمل‌های درمانی لغو شد. تعدادی از مراکز نیز برای ادامه کار به پرونده‌های کاغذی بازگشتند.
با وجود این مشکلات، خطوط تماس اضطراری ۹۹۹ و ۱۱۱ در بریتانیا همچنان فعال باقی ماندند. بنابراین اختلال بیشتر ارتباطات و سامانه‌های اداری و اطلاعاتی را تحت تأثیر قرار داد و به معنای توقف کامل همه خدمات اضطراری نبود.
تعطیلی یا تأخیر در جلسات دادگاه‌ها
دادگاه‌های بریتانیا نیز به دلیل اختلال در ایمیل و سامانه‌های وابسته، برخی جلسات کیفری و مدنی را لغو یا به زمان دیگری موکول کردند. صدور تعدادی از آرای مدنی نیز به روز دوشنبه انتقال یافت.
در دادگاه جنایی خیابان مینشال منچستر، کارکنان برای ادامه مکاتبات به دنبال دستگاه فکس می‌گشتند. از آنجا که روند اداری دادگاه به اوت‌لوک وابسته بود، قاضی موریس گرین در نهایت اعضای هیئت منصفه را تا پایان هفته به خانه فرستاد.
در آمریکا نیز قوه قضاییه ایالت مین هشدار داد درخواست‌های دستور حفاظتی که پس از ساعت ۱۲:۳۰ پنجشنبه از طریق ایمیل ارسال شده‌اند، ممکن است به دادگاه نرسیده باشند. این درخواست‌ها برای حمایت فوری از افرادی استفاده می‌شوند که در معرض خطر قرار دارند.
اختلال در نهادهای دولتی و بازارهای مالی
پیامدهای قطعی به بریتانیا و آمریکا محدود نبود. آژانس فناوری دولتی سنگاپور از اختلال در ایمیل‌های دولتی خبر داد و برخی بانک‌های بزرگ این کشور درباره تأخیر در پاسخ‌گویی به مشتریان هشدار دادند.
دیوان عالی فیلیپین اعلام کرد بخشی از فعالیت‌هایش، از جمله پاسخ‌گویی از طریق ایمیل، مختل شده است. وزارت خارجه ژاپن نیز در ارسال و دریافت پیام‌های الکترونیکی با مشکل مواجه شد.
یورونکست، اپراتور چند بورس اروپایی، از شرکت‌های بورسی خواست برای ارتباط با تیم پذیرش از تماس تلفنی استفاده کنند. در آمریکا نیز برخی نهادها و کارکنان دولتی از دشواری دسترسی به سامانه‌های کاری خبر دادند.
سازمان‌هایی که برای قطعی آماده بودند، چگونه از بحران عبور کردند؟
این حادثه نشان داد تفاوت سازمان‌های آسیب‌پذیر و سازمان‌هایی که توانستند فعالیت خود را ادامه دهند، لزوماً در نوع فناوری مورد استفاده نیست؛ بلکه به آمادگی قبلی برای شرایط اضطراری بستگی دارد.
شرکت بیمه بریتانیایی آویوا تنها دو هفته پیش از قطعی مایکروسافت، اختلالی مشابه را در سامانه‌های حیاتی خود تمرین کرده بود. این شرکت پس از بروز حادثه، شماره‌تلفن‌های جایگزین را در اختیار کارکنان قرار داد و فایل‌های صوتی موردنیاز برای تماس‌های اعلام درآمد را از طریق بلوتوث منتقل کرد.
شرکت کشتیرانی مرسک نیز از مشتریان خواست درخواست‌های فوری را تلفنی پیگیری کنند. این شرکت همچنین درباره پیام‌های غیرمنتظره‌ای که ممکن بود با سوءاستفاده از شرایط قطعی ارسال شوند، هشدار داد.
در مقابل، سازمان‌هایی که برای چنین شرایطی برنامه مشخصی نداشتند، ناچار شدند در میانه بحران به دنبال ابزارهای جایگزین بگردند. داشتن تلفن، فکس یا نسخه کاغذی اطلاعات به‌تنهایی کافی نیست؛ کارکنان باید پیش از وقوع حادثه بدانند چه زمانی و چگونه از این ابزارها استفاده کنند.
مایکروسافت چگونه سرویس‌های خود را بازیابی کرد؟
پس از شناسایی منشأ مشکل، مهندسان مایکروسافت راهکار اصلاحی را ابتدا روی گروه کوچکی از سرورها آزمایش کردند. پس از مشاهده نتایج مثبت، فرایند بازیابی را به‌تدریج گسترش دادند.
در این روش، ترافیک هر گروه از سرورها کاهش پیدا می‌کرد، سپس اصلاحات لازم انجام می‌شد و سرورها پس از راه‌اندازی مجدد، به‌صورت مرحله‌ای درخواست‌ها را دریافت می‌کردند. این فرایند کندتر از بازگرداندن یک‌باره تمام ظرفیت بود، اما احتمال تکرار چرخه خرابی را کاهش می‌داد.
بازگشت سرورها به فعالیت، پایان فوری مشکلات نبود. تعداد زیادی از ایمیل‌ها ساعت‌ها در صف ارسال و دریافت باقی مانده بودند و پس از بازیابی سرویس‌ها، حجم زیادی از پیام‌ها باید پردازش می‌شد. مایکروسافت برای جلوگیری از برگشت خوردن پیام‌های معطل، مهلت نگهداری ایمیل‌های در انتظار پردازش را به ۴۸ ساعت افزایش داد.
تا بامداد شنبه ۱۴ نوامبر، شرکت از بازگشت گسترده و پایدار بخش بزرگی از خدمات خبر داد؛ بااین‌حال، صفحه وضعیت سرویس‌ها همچنان نشان می‌داد بازیابی برای برخی مشتریان و مناطق ادامه دارد.
مایکروسافت بابت اختلال از مشتریان خود عذرخواهی کرد و وعده داد پس از تکمیل بررسی‌های داخلی، گزارش جامع حادثه را منتشر کند. این گزارش قرار است جزئیات بیشتری درباره نقص اولیه و دلایل گسترش آن ارائه دهد.
درس قطعی جهانی مایکروسافت برای سازمان‌ها چیست؟
قطعی نوامبر ۲۰۲۶ بار دیگر اهمیت مدیریت ریسک در زیرساخت‌های دیجیتال را برجسته کرد. استفاده از سرویس‌های ابری می‌تواند هزینه‌ها را کاهش دهد و دسترسی به ابزارهای پیشرفته را آسان‌تر کند، اما وابستگی بیش از اندازه به یک تأمین‌کننده یا یک زیرساخت مشترک، خطر توقف هم‌زمان چند فرایند حیاتی را افزایش می‌دهد.
استیون وات، استاد امنیت سایبری دانشگاه سنت‌اندروز، بر ضرورت پاسخ‌گویی سازمان‌ها به چند پرسش اساسی تأکید کرده است: کدام فعالیت‌های حیاتی فقط به یک تأمین‌کننده وابسته‌اند؟ اگر آن تأمین‌کننده از دسترس خارج شود، سازمان چه مدت می‌تواند به کار ادامه دهد؟ آیا مسیر ارتباطی جایگزین واقعاً آزمایش شده یا صرفاً روی کاغذ وجود دارد؟
بر این اساس، سازمان‌ها برای افزایش تاب‌آوری دیجیتال باید چند اقدام را جدی بگیرند:
- شناسایی فرایندهای حیاتی که به یک سرویس یا تأمین‌کننده واحد وابسته‌اند.
- طراحی مسیرهای ارتباطی جایگزین مانند تماس تلفنی و سامانه‌های مستقل.
- آزمایش منظم برنامه‌های تداوم فعالیت و سنجش عملکرد کارکنان در شرایط قطعی.
- نگهداری نسخه‌های پشتیبان از اطلاعات ضروری و فراهم کردن امکان دسترسی مستقل به آن‌ها.
- آموزش کارکنان برای ادامه فعالیت در زمان از دسترس خارج شدن ابزارهای دیجیتال.
- بررسی وابستگی میان سرویس‌های مختلف و شناسایی نقاط شکست مشترک.
ماجرای دادگاه منچستر نشان داد حتی سازمان‌هایی که از فناوری‌های پیشرفته استفاده می‌کنند، ممکن است در برابر اختلال یک سرویس مشترک غافلگیر شوند. مسئله اصلی صرفاً انتخاب فناوری جدید نیست؛ بلکه باید از پیش مشخص باشد که در صورت از کار افتادن آن فناوری، چه راهی برای ادامه فعالیت وجود دارد.
در دنیایی که بخش بزرگی از ارتباطات و خدمات به فضای ابری منتقل شده است، داشتن یک برنامه اضطراری واقعی اهمیت زیادی دارد؛ برنامه‌ای که به همان سامانه ازکارافتاده وابسته نباشد و پیش از وقوع بحران آزمایش شده باشد.
