أقرت شركة مايكروسوفت بأن الانقطاع الواسع الذي ضرب خدمات «Microsoft 365» بدءًا من يوم الخميس 12 نوفمبر 2026، نتج من خلل كامن أُدخل خلال ترقية سابقة لسعة الشبكة، وظهرت تداعياته لاحقًا إثر تنفيذ تغيير شبكي أحدث.
وكشفت التحقيقات التشغيلية أن ما بدا في الساعات الأولى كأنه ارتفاع مفاجئ في أحمال الخوادم، كان في واقعه نتيجة فقدان عدد كبير من الخوادم قدرتها على معالجة الطلبات، مما أدى إلى اختلال حاد في توزيع الاتصالات وتزايد الضغط على السعة المتبقية.
وامتدت تأثيرات الحادث من تعذر الوصول إلى صناديق بريد «Exchange Online» و«Outlook»، لتشمل وظائف حيوية مترابطة داخل منصات «Teams» و«Copilot» و«SharePoint»، إضافة إلى أدوات الإدارة والأمن والواجهات البرمجية.
وفي أحدث إفصاح تفصيلي صدر مساء الجمعة 13 نوفمبر، أكدت مايكروسوفت أن مرحلة التعافي أصبحت مستقرة على نطاق واسع، غير أنها أبقت الحادث مفتوحًا لمراقبة الأداء ومعالجة رسائل البريد الإلكتروني المتراكمة في الطوابير.
وبناءً على التحديثات الصادرة للحادثتين (EX1550543) و(MO1550821) عبر لوحة صحة الخدمة المؤسسية، يمكن تتبع المسار التقني للإخفاق المتسلسل الذي ضرب البنية التحتية؛ فقد أوضحت الشركة أن المشكلة الأساسية تكمن في خلل كامن لم يظهر فور إدخاله، بل فُعّل لاحقًا في ظل ظروف تشغيلية جديدة.
ورغم هذا الإفصاح، لم تحدد الشركة بعد الإعداد البرمجي أو جهاز الشبكة المسؤول بدقة، ولا توقيت إدخال الخلل الأصلي، مما يجعل ربط الحادث ببروتوكولات (BGP) أو (DNS) أو بوابة شبكية محددة مجرد استنتاجات هندسية غير مثبتة بانتظار التقرير النهائي.
وتحولت المشكلة الشبكية إلى انهيار واسع عبر طبقة استقبال الطلبات؛ إذ واجهت عملية برمجية مسؤولة عن إنشاء الاتصالات الآمنة على الخوادم أعباءً تفوق قدرتها، مما أدى إلى توقف تلك الخوادم عن معالجة الطلبات قبل وصولها إلى المكونات الخلفية.
ونتيجة لذلك، فشلت الخوادم المتأثرة في اجتياز الفحوص الآلية لسلامة الخدمة، واستُبعدت من القدرة المتاحة.
ومع خروج سعة تشغيلية كبيرة من الخدمة، انتقلت الأحمال إلى موارد أقل، مما ولّد إخفاقًا متسلسلًا ضاعف من زمن الاستجابة وأخرج خوادم إضافية من الخدمة.
وواجهت الفرق الهندسية تعقيدات إضافية خلال مرحلة الاستعادة؛ إذ كانت الخوادم تعود للعمل بصورة طبيعية بعد إعادة تشغيلها، لكنها سرعان ما تتوقف مجددًا بمجرد إعادة توجيه حركة الاتصالات الحقيقية إليها.
ورُصدت قفزة في حجم الاستدعاءات الصادرة من خدمات التوجيه إلى الخوادم الخلفية، وتزامنت مع بقاء بعض الأجهزة عالقة في حالة تشغيلية غير سليمة منعتها من مزامنة إعدادات التغيير الشبكي أو استقبال تعديلات الإصلاح.
ولم تقتصر الأزمة على خدمات البريد، بل أبرزت طبيعة الاعتماد المتبادل داخل منظومة مايكروسوفت السحابية؛ فقد تعذر الوصول إلى صناديق البريد عبر واجهات (Outlook) و(MAPI) و(REST)، وتأثرت وظائف التقويم والدعوات وتكاملات (Copilot) داخل (Teams)، رغم استمرار المحادثات والقنوات القياسية بالعمل.
كما واجه Microsoft 365 Copilot صعوبات في الوصول إلى بيانات العمل، وسجلت واجهات (Microsoft Graph) انتهاء مهلة استدعاءات البريد، بينما تعطلت سيناريوهات المشاركة الخارجية في SharePoint.
وامتد الأثر ليشمل صفحات الإدارة في Defender وPurview واضطرابات في تسجيل الأجهزة عبر Intune و Windows 365وصعوبات تحميل في Planner وPower BI.
وعلى صعيد المعالجة، طبقت مايكروسوفت تصحيحًا لمكون تهيئة في مسار المصادقة والتوجيه العلوي، وبدأت توسيع تطبيقه تدريجيًا مع منح الأولوية للمناطق ذات النشاط المرتفع.
واتبعت الشركة نهجًا لعزل أجزاء من البنية المتضررة، وإعادة توجيه الاتصالات، وإضافة قدرات افتراضية لتقليل الضغط، ولحماية تدفق البيانات، مددت الشركة مهلة تسليم البريد إلى 48 ساعة لتأمين الرسائل المتأخرة خلال مرحلة التعافي.
ونفت مايكروسوفت قطعيًا ارتباط الحادث بأي هجوم سيبراني خبيث أو بأنظمة الذكاء الاصطناعي، مؤكدة أنه عطل تقني بحت.
ويختلف هذا الحادث هندسيًا عن أزمة CrowdStrike التي وقعت في يوليو 2024، ولا يرتبط بالعطل المستقل OO1550244 الذي أصاب Word للويب.
ومع استقرار الخدمات، تترقب الأوساط التقنية والاقتصادية تقرير ما بعد الحادث للإجابة عن الأسئلة المتبقية حول طبيعة التغيير الشبكي، وحجم السعة المفقودة، والأسباب التي حالت دون اكتشاف الخلل في بيئات الاختبار قبل وصوله إلى مرحلة الإنتاج الفعلي.
