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