أفصحت شركة مايكروسوفت رسميًا عن التفاصيل التقنية الكامنة وراء العطل الواسع الذي ضرب خدمات Microsoft 365 في منتصف نوفمبر 2026. وأوضحت الشركة أن الأزمة لم تكن ناتجة عن هجوم خارجي، بل عن خلل برمجى كامن أُدخل خلال عملية ترقية سابقة لسعة الشبكة، ولم يظهر أثره الكارثي إلا بعد تنفيذ تغيير شبكي أحدث. هذا الاضطراب أدى إلى خروج عدد هائل من الخوادم عن الخدمة وفشلها في معالجة طلبات المستخدمين، مما خلق حالة من عدم التوازن الحاد في توزيع الأحمال التقنية عبر بنيتها التحتية العالمية.
- ✅ السبب الجذري يعود لخطأ في ترقية قديمة للسعة الشبكية تفعّل بسبب تحديث أحدث.
- ✅ تعطلت خدمات حيوية مثل Outlook وTeams وCopilot نتيجة الاعتماد المتبادل على Exchange Online.
- ✅ واجهت الخوادم فشلاً متكرراً في "فحوص السلامة" مما أدى لاستبعادها آلياً من الخدمة.
- ✅ استغرقت عملية التعافي وقتاً طويلاً بسبب صعوبة مزامنة الإعدادات مع الأجهزة المتضررة.
السبب الحقيقي للعطل: خلل كامن أيقظه تحديث جديد
وفقاً لأحدث التقارير الصادرة عن مايكروسوفت، فإن "المشكلة الكامنة" نشأت أثناء ترقية سابقة لسعة الشبكة، وظلت غير مكتشفة حتى تسبب تغيير شبكي لاحق في تفعيلها. هذا السيناريو التقني يسمى "الخطأ الكامن"، حيث تظل الشيفرة المعيبة غير مؤثرة حتى تتوفر ظروف تشغيلية معينة. وأكدت الشركة أن حجم حركة المرور لم يرتفع بشكل غير طبيعي، بل إن "السعة المتاحة" هي التي تقلصت نتيجة خروج الخوادم عن الخدمة بشكل متسلسل.
على الرغم من استقرار الخدمات تدريجياً، إلا أن الشركة لم تكشف بعد عن المكون البرمجي الدقيق أو البروتوكول المسؤول (سواء كان DNS أو BGP أو غيرهما). هذا الغموض يترك الباب مفتوحاً أمام التساؤلات حول فعالية بيئات الاختبار قبل النشر في واحدة من أكبر البنى التحتية السحابية في العالم.
رحلة الانهيار: كيف تحول الخلل البسيط إلى توقف شامل؟
1. اختناق طبقة الاتصال الآمن
بدأت الأزمة في الطبقة المسؤولة عن استقبال ومعالجة طلبات الوصول. رصد المهندسون أن العملية البرمجية المكلفة بإنشاء الاتصالات الآمنة تعرضت لعبء فاق قدرتها الاستيعابية، مما جعل الخوادم تتوقف عن الاستجابة تماماً. هذا يعني أن الطلب كان يفشل قبل أن يصل إلى صندوق البريد أو الملف المطلوب، بسبب تعثر "المصافحة" الرقمية بين المستخدم والخادم.
2. تأثير "الدومينو" وفشل فحوص السلامة
تمتلك أنظمة مايكروسوفت آلية آلية لاستبعاد أي خادم لا يعمل بكفاءة، وهو ما يعرف بـ "فحوص السلامة" (Health Checks). عندما بدأت الخوادم في الفشل، قام النظام آلياً بتحويل حركة المرور إلى الخوادم المتبقية، مما أدى إلى زيادة الضغط عليها وتسبب في انهيارها هي الأخرى فيما يعرف بـ "الإخفاق المتسلسل" (Cascading Failure).
3. معضلة إعادة التشغيل والمزامنة
واجهت الفرق الهندسية تحدياً غريباً؛ فبمجرد إعادة تشغيل الخوادم، كانت تعود للعمل لفترة وجيزة ثم تنهار مجدداً بمجرد استقبالها لحركة المرور الحقيقية. بالإضافة إلى ذلك، علقت بعض الأجهزة في حالة تقنية تمنعها من استقبال "تحديثات الإصلاح"، مما اضطر الفرق إلى معالجة كل مجموعة خوادم بشكل يدوي ومنفصل.
تأثير العطل على الخدمات المختلفة
لم تتأثر جميع الخدمات بنفس القدر، ولكن بسبب الاعتماد الوثيق على Exchange Online، شهدت المنصة اضطراباً واسعاً. يوضح الجدول التالي الأثر التقني على أبرز الخدمات:
| الخدمة المتأثرة | طبيعة الأثر التقني |
|---|---|
| Outlook & Exchange | فشل الوصول لصناديق البريد عبر الويب والتطبيقات وتأخر تسليم الرسائل. |
| Microsoft Teams | تعطل وظائف التقويم، الدعوات، وتكاملات كوبايلوت داخل الاجتماعات. |
| Microsoft 365 Copilot | صعوبة استرجاع المحادثات أو الوصول لبيانات العمل المرتبطة بالبريد. |
| SharePoint Online | اضطراب في سيناريوهات المشاركة الخارجية والوظائف المرتبطة بالبريد. |
| Defender & Purview | تعطل صفحات الإدارة وسياسات تصنيف البيانات وحماية الروابط Safe Links. |
كيف تمت السيطرة على الموقف؟
اعتمدت مايكروسوفت استراتيجية متعددة المحاور للتعافي، بدأت بتطبيق "تصحيح" لمكونات التوجيه والمصادقة العلوية. كما قامت الشركة بتقليل الحمل قسراً عبر عزل الأجزاء المتضررة وتوسيع استخدام الآلات الافتراضية لتعويض السعة المفقودة. ولحماية بيانات المستخدمين، تم تمديد مهلة تسليم البريد المتراكم في الطوابير إلى 48 ساعة لضمان عدم فقدان أي رسالة أثناء فترة التعافي.
التسلسل الزمني للأزمة (بتوقيت الإمارات)
| التوقيت | الحدث التقني |
|---|---|
| الخميس، 20:17 | رصد أولى بوادر الخلل في خدمة Exchange Online. |
| الخميس، 23:43 | تأكيد فشل الخوادم في فحوص السلامة الآلية وبدء انهيار السعة. |
| الجمعة، 05:06 | تحديد اختناق في عمليات الاتصال الآمن والبدء في التراجع عن التغييرات. |
| الجمعة، 21:57 | إعلان السبب الجذري (ترقية قديمة للسعة) وتأكيد معالجة المشكلة الأساسية. |
| السبت، 02:00 | استقرار واسع النطاق وبدء مراقبة طوابير البريد المتراكمة. |
هل كان هجوماً سيبرانياً؟
نفت مايكروسوفت بشكل قاطع وجود أي نشاط تخريبي أو هجوم سيبراني وراء هذا الانقطاع. كما أكدت أن الحادث لا علاقة له بأنظمة الذكاء الاصطناعي، وهو يختلف تقنياً عن حادثة "كراود سترايك" الشهيرة التي وقعت في يوليو 2024. الأزمة الحالية كانت "داخلية" بحتة، تتعلق بكيفية إدارة الشبكة وتوجيه البيانات داخل مراكز بيانات الشركة.
ما هو السبب الدقيق وراء تعطل الخدمات؟
السبب هو خلل في ترقية سابقة لسعة الشبكة، تفعّل نتيجة تغيير شبكي أحدث، مما أدى لفشل الخوادم في معالجة طلبات الاتصال الآمن وخروجها من الخدمة.
هل فُقدت رسائل البريد الإلكتروني خلال العطل؟
لم تشر مايكروسوفت إلى فقدان دائم للبيانات؛ بل تم وضع الرسائل في طوابير انتظار، وتم تمديد مهلة التسليم لضمان وصولها بعد استقرار النظام.
لماذا تأثر تطبيق Teams رغم أن المشكلة في الشبكة؟
بسبب الاعتماد المتبادل؛ حيث يعتمد Teams على Exchange Online لجلب بيانات التقويم وجهات الاتصال، فإذا تعطل المصدر، تتوقف الوظائف المرتبطة به في التطبيقات الأخرى.
كيف يمكنني التأكد من حالة الخدمة الآن؟
يمكن للمسؤولين التقنيين متابعة لوحة صحة الخدمة الرسمية أو التحقق من التحديثات المستمرة عبر القنوات الرسمية لمايكروسوفت.
🔎 تُظهر هذه الحادثة مدى تعقيد وحساسية الأنظمة السحابية الحديثة؛ فحتى الشركات العملاقة مثل مايكروسوفت ليست محصنة ضد "الأخطاء الكامنة" التي قد تنتظر سنوات قبل أن تسبب شللاً عالمياً. وبينما تواصل الشركة مراقبة استقرار أنظمتها، يبقى الدرس الأهم للمؤسسات هو ضرورة وجود خطط بديلة لاستمرارية الأعمال، حيث أن الاعتماد الكلي على سحابة واحدة قد يحمل مخاطر غير متوقعة مهما بلغت درجة تطورها التقني.
قم بالتعليق على الموضوع