انقطاع تغيير شبكة WAN لدى Azure في 2023 جعل التحقق من التوجيه العالمي اختبارًا للمساءلة

ملخص

• في 25 يناير 2023، شهدت Microsoft حادثًا شبكيًا عالميًا أثّر على الاتصال من الإنترنت إلى Azure، وعلى الاتصال بين الخدمات والمناطق، واتصالات ExpressRoute، وMicrosoft 365، وغيرها من خدمات Microsoft. ويُظهر تقرير جاهز للعملاء خاص بـMicrosoft 365 نافذة تأثير من 07:05 إلى 12:43 بالتوقيت العالمي المنسق، ويشير إلى معرّف تتبع شبكة Azure WAN VSG1-B90. [1][2]
• ذكر التفسير العلني من Microsoft أن تغييرًا مخططًا كان يهدف إلى تحديث عنوان IP على موجّه WAN. وقد تصرّف أمرٌ بشكل مختلف عبر أجهزة الشبكة ولم يكن مؤهَّلًا بالكامل على الموجّه الذي نُفّذ فيه. ووصلت رسائل إلى موجّهات WAN أخرى، فأعادت حساب جداول الجوار والتوجيه؛ وخلال فترة التقارب، تعذّر على الموجّهات توجيه الحزم بشكل صحيح. [1][2][4]
• رصدت ThousandEyes بشكل مستقل عمليات سحب لإعلانات BGP وإعادة إعلان وتغيّرات متكررة في المسارات حول بادئات مرتبطة بـAS8075 التابع لـMicrosoft، وتحوّلات بين النظراء المباشرين ومسارات العبور، وفقدان حزم تزامن مع أحداث التوجيه. ويثبت هذا الدليل عدم استقرار المسارات الظاهر خارجيًا، وليس كل أمر داخلي أو حالة جدول داخلية. [3]
• سؤال المساءلة المفيد ليس ما إذا كان التغيير مخططًا، بل ما إذا كانت دلالاته الدقيقة قد خضعت للاختبار عبر مجموعة الأجهزة والبرمجيات التي ستنفّذه، وما إذا كان الانتشار مقيّدًا، وما إذا كانت ثوابت المسارات وقابلية الوصول قادرة على إيقاف الطرح قبل التأثير العالمي.
• قالت Microsoft إن أعمال المراقبة الأولية فحصت DNS قبل تأكيد أن WAN هو مصدر العطل. ويثير هذا التسلسل سؤالًا حول التصنيف وقابلية الملاحظة: هل رصدت المراقبة أعراض المستخدمين، أم استطاعت التمييز بسرعة بين آلية مستوى التحكم وآلية مستوى التوجيه المسؤولة عنها؟ وهو لا يثبت إخفاءً أو تأخيرًا غير معقول.
• تظل وفرة ExpressRoute بنيةً ذات صلة لدى العملاء، لكنها لا تنقل السيطرة على أوامر العمود الفقري الخاص لـMicrosoft أو جوار الموجّهات أو تقارب التوجيه أو التعافي العالمي إلى العملاء. فالمسؤولية تتبع الضوابط التي يشغّلها كل طرف فعلًا. [8]-[11]
• تشرح معايير BGP والتشغيل الإعلان والسحب والتصفية وتصريف الحركة المخطط. وهي لا تثبت الحالة الداخلية لـMicrosoft. كما أن تفويض الأصل عبر RPKI لم يكن ليصادق على أمر خاص بجهاز، أو إعادة حساب الجوار الداخلي، أو استمرارية التوجيه. [18]-[20]
• أقوى دليل بعد الحادث هو الذي يربط طلب التغيير بالأمر الدقيق والحالة المرشحة، ومصفوفة تأهيل لكل جهاز وإصدار، وثوابت المسارات، واختبارًا تجريبيًا تمثيليًا، ونطاق انتشار أقصى، ومسابير مستقلة، ومشغّل تراجع تلقائي، وسجلات تعافٍ محفوظة.
• تصف وثائق Microsoft الحالية هندسة الشبكة العالمية والمراقبة وExpressRoute وضوابط Virtual WAN. وتحدد هذه الوثائق الآليات المتاحة وادعاءات التصميم الحالية؛ لكنها ليست دليلًا على أن كل ضابط كان موجودًا بالشكل نفسه في يناير 2023 أو أنه يظل مُنفَّذًا باستمرار. [7]-[17]
• لا يحدد السجل العام الأمر الدقيق، أو كل طراز موجّه وإصدار برمجي، أو كل بادئة متأثرة، أو عددًا كاملًا للعملاء، أو خسائر مالية، أو نتائج تنظيمية، أو إهمالًا، أو نية خبيثة، أو خطأ من مورد. وتظل هذه الحدود جزءًا من النتيجة.

التغيير المخطط ليس تغييرًا مؤهَّلًا

قد تبدو عبارة «تغيير مخطط» مطمئنة. فهي توحي بالتفويض والتحضير وهدف معروف. في هذا الحادث، وصفت Microsoft الإجراء المبدئي بأنه تغيير مخطط لتحديث عنوان IP على موجّه WAN. وكان الغرض صيانة عادية، لا محاولة لتغيير قابلية الوصول العالمية. ومع ذلك، ورد أن الأمر المستخدم لهذا العمل تصرّف بشكل مختلف عبر أجهزة الشبكة ولم يكن مؤهَّلًا بالكامل على الموجّه الذي نُفّذ فيه. [1][2][4]

هذه الفجوة هي أول نتائج المساءلة. التخطيط يسجّل ما تنوي المنظمة فعله. أما التأهيل فيختبر ما سيفعله النظام المنشور فعلًا. والأمران مرتبطان، لكنهما غير قابلين للتبادل.

الموجّهات ليست حاويات عامة لأوامر نصية. فالأمر يفسَّر بواسطة منصة معينة، وإصدار نظام تشغيل، ومجموعة ميزات، وسياق إعداد، وطوبولوجيا مجاورة. وقد يكون الصياغ نفسه غير مدعوم، أو يُوسَّع بشكل مختلف، أو يُطبَّق على نطاق مختلف، أو يثير عمليات تابعة مختلفة عبر أسطول غير متجانس. وحتى عندما يبدو الإعداد الناتج مشابهًا، قد يختلف المسار من تغيير محلي إلى رسائل بروتوكول، وحالة جوار، واختيار مسار، ومدخلات توجيه.

لذلك يشير تفسير Microsoft العلني إلى فشل ضبط أكثر تحديدًا من «أخطأ أحدهم». فالسؤال هو ما إذا كان نظام التغيير يعرف الأجهزة التي ستتلقى الأمر أو تتفاعل معه، وما إذا كانت أدلة التأهيل تمثل تلك الأجهزة. فاختبارٌ على منصة واحدة لا يثبت السلوك على منصة أخرى لمجرد أن كليهما يُسمى موجّهًا. واختبار مختبري لا يثبت سلامة الإنتاج إذا أغفل إصدار البرمجيات، أو عدد النظراء، أو حجم المسارات، أو مجموعة السياسات، أو مسار الانتشار الذي يخلق الخطر.

التمييز مهم لأن أوامر الشبكة سلطة قابلة للتنفيذ. قد يقول وصف التغيير «تحديث عنوان IP». لكن الموجّه لا ينفّذ ذلك الوصف. إنه ينفّذ أوامر وبروتوكولات تعدّل الحالة. والموجّهات الأخرى تستجيب للرسائل التي تتلقاها، لا للغرض التجاري للتذكرة. والحزم تواجه جدول التوجيه الناتج، لا سجل الموافقة.

لذلك يجب أن تحافظ عملية تغيير خاضعة للمساءلة على سلسلة من النية إلى الأثر التشغيلي:

1. الهدف المعتمد والنطاق الدقيق.
2. الأمر المُنفَّذ أو الإعداد المرشح.
3. طراز الجهاز وإصدار البرمجيات والدور والطوبولوجيا المتوقع تنفيذها.
4. رسائل البروتوكول وانتقالات الحالة المتوقع أن يسببها.
5. ثوابت المسارات وقابلية الوصول التي يجب أن تظل صحيحة.
6. الاختبار التجريبي وحدود الانتشار المستخدمان لاختبار تلك التوقعات.
7. مشغّل التراجع وسلطته.
8. الملاحظات التي تُظهر عودة الشبكة إلى الحالة المقصودة.

من دون هذه السلسلة، قد يكون التغيير المخطط مكتملًا إجرائيًا وغير مؤهَّل تشغيليًا. وحادث يناير 2023 مهم تحديدًا لأن التفسير العام يربط هدفًا روتينيًا بسلوك يعتمد على الجهاز وعواقب على مستوى الشبكة ككل.

آلية الفشل مرّت عبر WAN

غالبًا ما تنتج انقطاعات التطبيقات أعراضًا شبيهة بالشبكة. يرى المستخدم مهلة، أو فشل تسجيل دخول، أو صفحة لا تُحمَّل. وهذه الملاحظات وحدها لا تثبت ما إذا كان DNS أو المصادقة أو سعة التطبيق أو التخزين أو مسار نقل أو ضابط توجيه قد فشل.

السجل المتاح ليوم 25 يناير أكثر تحديدًا. ربطت Microsoft الحدث بشبكتها الواسعة. وذكرت أنها أُرسلت رسائل إلى موجّهات WAN أخرى، وأن تلك الموجّهات أعادت حساب جداول الجوار والتوجيه، وأنها خلال فترة التقارب لم تستطع توجيه الحزم بشكل صحيح. [1][2][4]

الجوار والتوجيه ليسا عمليتين خلفيتين مجردتين. فجوارات التوجيه تحدد الأجهزة التي تتبادل معلومات قابلية الوصول. ومستوى التحكم يستخدم تلك المعلومات والسياسات لاختيار المسارات. ومستوى التوجيه يثبّت مدخلات تخبر الموجّه أين يرسل الحزم. وإذا جعل تغييرٌ مجموعة واسعة من الموجّهات تعيد حساب تلك العلاقات والمدخلات، فقد ينتشر الأثر بعيدًا عن الجهاز الأول.

النتيجة التي وصفتها Microsoft اتبعت تلك الآلية. تأثر اتصال العملاء من الإنترنت إلى Azure. وتأثر الاتصال بين الخدمات في المناطق. وتأثر اتصال ExpressRoute. كما تأثرت Microsoft 365 وPower Platform. [1][2][4][6]

هذا الاتساع لا يعني أن كل خدمة شهدت فشلًا أو مدة متطابقة، بل يعني أن WAN تقع تحت مسارات خدمات متعددة. فالركيزة الأساسية المشتركة للتوجيه يمكن أن تحوّل تغييرًا شبكيًا واحدًا إلى أعراض تطبيقات تبدو غير مترابطة، لأن الخدمات تعتمد على الربط نفسه والعمود الفقري وقابلية الوصول الإقليمية.

تساعد وثائق شبكة Microsoft العالمية الحالية في تفسير سطح الاعتماد. تصف Microsoft شبكة WAN عالمية خاصة تربط مراكز البيانات، وتنقل الحركة عبر عمودها الفقري، وتتصل بالشبكات الخارجية. وتوفر ExpressRoute اتصالًا خاصًا بخدمات Microsoft عبر علاقات توجيه، بينما تعتمد مناطق وخدمات Azure على شبكة المزوّد لتبادل الحركة. [7]-[10]

لا ينبغي قراءة هذه الأوصاف الحالية إلى الوراء باعتبارها خريطة كاملة لحادث 2023، لكنها تثبت لماذا يمكن لضابط WAN أن تكون له عواقب عبر الخدمات. إذا عجز العمود الفقري عن توجيه الحزم بشكل صحيح، فقد تظل عملية تطبيق سليمة غير قابلة للوصول. وإذا تدهور الاتصال بين المناطق، فقد تفقد الخدمات الموزعة تبعياتها حتى عندما تظل الأجهزة الفردية عاملة. وإذا عبرت مسارات ExpressRoute نطاق التحكم المتأثر، فقد تشهد الدوائر الخاصة تأثيرًا رغم تجنّب الإنترنت العام.

لهذا لا تصمد أطروحة المقال إذا أزيلت حقائق الشبكة. فالحادث ليس درسًا عامًا عن إدارة التغيير مع موجّهات كديكور. إن الأمر، وإعادة حساب الجوار، وحالة جدول التوجيه، وتقلّب المسارات، وفقدان الحزم، والمسارات بين المناطق، وحدود ExpressRoute هي الجوهر السببي والإثباتي.

رصد BGP الخارجي وفّر مستوى إثبات ثانيًا

سيطرت Microsoft على سجلات التغيير الداخلية وقياسات الموجّهات. أما المراقبون المستقلون فسيطروا على نوع مختلف من الأدلة: تغييرات التوجيه وآثار الاتصال التي كانت مرئية من خارج الشبكة الخاصة.

أفادت ThousandEyes برصد عدد كبير من تغييرات مسارات BGP affecting بادئات مرتبطة بـAS8075 التابع لـMicrosoft بدءًا بعد 07:10 بالتوقيت العالمي المنسق بقليل. ورصدت سحبًا أعقبته إعادة إعلانات، وتغييرات متكررة شملت مسارات مباشرة ومزوّدي عبور، وفقدان حزم ارتفع مع نشاط التوجيه. وشهدت بعض المواقع المرصودة فقدانًا كاملًا للحزم خلال أجزاء من الحدث. [3]

هذا الدليل قيّم لأنه لم يُنتج عن سردية حادثة Microsoft. فهو يُظهر أن عدم استقرار المسارات وفقدان قابلية الوصول كانا مرئيين من نقاط مراقبة مستقلة. كما يجعل آلية الشبكة الواسعة قابلة للاختبار. فادعاء أن حدث توجيه WAN أثّر على الاتصال الخارجي يجب أن يكون متسقًا مع ملاحظات المسارات والحزم خارج النطاق الإداري للمشغّل.

مع ذلك، يجب تقييد الدليل المستقل. فراصِد BGP يرى التحديثات التي تصل إلى مجمّعاته أو وكلائه، ولا يرى كل جوار خاص، أو كل مسار داخلي، أو كل مدخلة جدول توجيه، أو الأمر الذي سببها. وقد يرصد سحبًا دون أن يعرف ما إذا كان الموجّه الأصلي أزال مسارًا، أو سياسة وسيطة كتمته، أو حدث داخلي آخر غيّر ما يُصدَّر.

وبالمثل، الترابط الزمني ليس إعادة بناء سببيًا كاملًا. رأت ThousandEyes تغييرات مسارات وفقدان حزم حول الحادث. وتفسير Microsoft يقدم السرد الداخلي لأمر وتقارب WAN. والسجلان متسقان معًا، لكن لا ينبغي جعل أي منهما يدّعي دليل الآخر.

تقرير الحادث الخاضع للمساءلة سيوائم بين المستويين صراحةً:

• ما تغييرات المسارات أو الجوارات الداخلية التي أنتجت كل سحب رُصد خارجيًا؟
• ما البادئات المتأثرة، وما الخدمات التي اعتمدت عليها؟
• ما مسارات النظراء المباشرين التي اختفت، وما مسارات العبور التي أصبحت بدائل؟
• هل انتقلت الحركة إلى مسارات تفتقر إلى سعة كافية أو توجيه مستقر؟
• ما حدث التثبيت الداخلي الذي يقابل العودة الخارجية للمسارات المستقرة؟
• هل كانت هناك إخفاقات قابلية وصول داخلية لم تستطع بيانات BGP العامة رؤيتها؟
• هل أعلنت المسابير الخارجية التعافي قبل تعافي كل خدمة من خدمات Microsoft؟

يوحي الجدول الزمني العلني بأن استقرار المسارات وتعافي الخدمة لم يكونا حدثين متطابقين. أفادت ThousandEyes باستقرار كبير حوالي 08:10، مع رصد نشاط BGP لاحق أيضًا. وقالت Microsoft إن التعافي التلقائي بدأ بعد 08:10 بقليل، وتعافت معظم الخدمات المتأثرة بحلول 09:00 تقريبًا، واستقرت معدات الشبكة بحلول 09:35، وتعافت بقية خدمات Microsoft 365 بحلول 12:43. [1][3][4]

هذا الاختلاف ليس تناقضًا. فقد تكون استعادة مسار ضرورية دون أن تكون كافية لتعافٍ كامل للخدمة. فقد تحتاج الاتصالات إلى إعادة محاولة، وقد تحتاج المخابئ وقوائم الانتظار إلى تفريغ، وقد تحتاج الخدمات التابعة إلى إعادة إنشاء الجلسات أو إصلاح الحالة. وينبغي أن يُظهر السجل المسؤول أين انتهى تعافي الشبكة وأين استمرت استعادة الخدمة.

تقلّب BGP يمكن أن يحوّل الوفرة إلى عدم استقرار

المسارات الفائضة أساس في تصميم شبكات الإنترنت والسحابة. إذا اختفى مسار مباشر، فقد يتاح مسار آخر عبر مزوّد عبور. لكن الوفرة لا تضمن أن تغييرات المسار السريعة والمتكررة ستكون غير ضارة.

وصفت ThousandEyes عمليات سحب أثرت إلى حد كبير على النظراء المباشرين، أعقبها استخدام مسارات بديلة ثم إعادة إعلان مسارات مباشرة أقصر. وأنتج التكرار تقلّبًا في المسارات. [3] وكل تغيير يمكن أن يجعل الموجّهات تعيد النظر في مسارها المختار. وقد تنتقل الحركة بين مسارات مختلفة السعة والكمون والسياسة والتعرض للفشل. وقد تُفقد الحزم بينما تلحق حالة التوجيه بقرارات مستوى التحكم.

تحدد مواصفات BGP كيف يتبادل المتحدثون قابلية الوصول ويسحبون المسارات، لكنها لا تعد بتقارب فوري متزامن عبر الإنترنت. فالمشغّلون يختارون السياسات محليًا، ويتلقون التحديثات في أوقات مختلفة، ويثبّتون تغييرات التوجيه وفق جداولهم الخاصة. [18]

هذا يعني أن المسار الاحتياطي ليس حارة احتياطية ثابتة تنتظر استقبال الحركة، بل هو جزء من نظام تحكم موزّع. فعندما تتغير مسارات كثيرة بسرعة، قد يتلقى مسار عبور حملًا مفاجئًا، وقد يختفي نظير مباشر ويعود قبل أن تتفق جميع الأجهزة على المسار الأفضل نفسه، وقد تحتفظ بعض الشبكات بمسار سحبته شبكات أخرى، وقد تعبر اتصالات التطبيقات حالات مختلفة أثناء الانتقال.

تؤكد إرشادات تشغيلية مثل RFC 7454 على سياسة توجيه وتصفية منضبطتين. وتصف RFC 8326 آليات إغلاق أنيق تهدف إلى تصريف الحركة قبل صيانة BGP مخطط لها. وليس أي من المعيارين وصفة مباشرة لحادثة Microsoft الداخلية، ولا يذكر السجل العام الآليات التي استُخدمت. لكنهما يرسيان مبدأ ضبط مفيدًا: ينبغي أن تهدف الصيانة إلى نقل الحركة عمدًا وبشكل قابل للملاحظة، بدلًا من السماح بانفجار غير منضبط لسحب المسارات وإعادة إعلانها. [19][20]

بالنسبة لتغيير WAN عالمي، الثابت المعني ليس ببساطة «يوجد مسار آخر». فمجموعة أقوى ستسأل:

• هل تظل البادئات المطلوبة قابلة للوصول عبر مسار مؤهَّل واحد على الأقل؟
• هل يملك المسار البديل سعة كافية للتحول المتوقع؟
• هل تواتر تغيير المسار دون عتبة آمنة؟
• هل تتقارب مدخلات التوجيه خلال فترة مختبَرة؟
• هل تغييرات النظراء المباشرين والعبور مرئية للمسابير المستقلة؟
• هل يستطيع الطرح التوقف قبل أن يؤثر الأمر نفسه على نطاق الانتشار التالي؟
• هل يظل وصول الإدارة متاحًا عندما تتغير مسارات الخدمة؟

الوفرة ادعاء تصميمي. أما الإثبات التشغيلي فهو ما إذا كانت الحركة تستطيع استخدام المسار الفائض في ظل ظروف الفشل والتغيير الدقيقة التي تحدث.

النطاق العالمي غيّر معنى نطاق التأثير

قد يبدو الأمر المطبَّق على موجّه واحد محليًا. لكن رسالة بروتوكول تجعل موجّهات كثيرة تعيد حساب الحالة ليست محلية. حدود المساءلة يجب أن تتبع نطاق الانتشار، لا لوحة المفاتيح أو الجهاز الذي أُدخل فيه الأمر المبدئي.

قال تفسير Microsoft العلني إن الأمر أرسل رسائل إلى موجّهات WAN أخرى. [4] وهذا التصريح يجعل الانتشار خاصية تغيير من الدرجة الأولى. فقبل الموافقة، يجب أن يعرف المشغّل الأجهزة التي قد تتفاعل، والحالة التي ستعيد حسابها، وكيف يمكن إيقاف التفاعل.

في العمود الفقري العالمي، لنطاق التأثير أبعاد عدة:

• نطاق الأجهزة:الموجّهات وإصدارات البرمجيات التي تتلقى التغيير أو تفسره.
• نطاق البروتوكول:الجوارات وعاكسات المسارات والنظراء وجلسات التحكم المتأثرة.
• نطاق البادئات:مدخلات قابلية الوصول التي يمكن سحبها أو استبدالها أو اختيارها بشكل مختلف.
• نطاق الحركة:تدفقات العملاء والخدمات والمناطق والإدارة التي تستخدم تلك المدخلات.
• النطاق الجغرافي:المناطق ونقاط الربط التي تشترك في نطاق التحكم.
• نطاق التعافي:الأنظمة والمشغّلون المطلوبون لاستعادة حالة مستقرة.

قد يكون التغيير صغيرًا في عدد الأجهزة لكنه كبير في نطاق البروتوكول، وقد يمس كائن إعداد واحدًا بينما يغيّر آلاف المسارات المختارة، وقد يكون قابلًا للعكس على الموجّه المبدئي بينما يترك بقية الشبكة تعيد التقارب.

هذا يفرض متطلب تنفيذ مقيّد. فالنظام الآمن يجب أن يكون قادرًا على تطبيق المرشح على نطاق تمثيلي لكن محدود، ومراقبة ثوابت المسارات وقابلية الوصول، والتوقف قبل أن تنتشر الرسائل عالميًا. ويجب أن يمارس الاختبار التجريبي دلالات الأمر ودور الشبكة نفسه الذي يقوم به هدف الإنتاج. فموجّه مختبري عام أو حافة غير تمثيلية لا يكفي.

يحتاج الاختبار التجريبي أيضًا إلى مدة مرتبطة بسلوك تقارب النظام. فإذا ظهرت مشكلة مسار فقط بعد وصول الرسائل إلى مجموعة أوسع، فإن فحص نجاح الأمر المحلي لخمس ثوانٍ لا يثبت شيئًا يُذكر. وينبغي أن تشمل نافذة الملاحظة تغييرات الجوار، وتوزيع المسارات، وتثبيت التوجيه، ومسابير الحركة، وأي استجابة أتمتة متأخرة.

أقوى تصميم يجعل حدود نطاق التأثير قابلة للإنفاذ لا استشارية. فيعرف المتحكم في النشر مجموعة الأجهزة المسموحة ونطاق المسارات في كل مرحلة، ويرفض أمرًا يتجاوز مستقبلوه تلك الحدود، ويشترط دليلًا صريحًا قبل التقدم، ويمكن لمتحكم مستقل سحب التفويض أو تشغيل التراجع عند فشل الثوابت.

لا تُظهر المادة العامة ما إذا كانت هذه الضوابط موجودة أو كيف تغيرت بعد الحادث، لكنها تُظهر لماذا لا تستطيع شبكة WAN العالمية معاملة نطاق الأمر كمسألة توقع من المشغّل.

رصدت المراقبة الأعراض قبل تصنيف فشل الشبكة

يشير سرد Microsoft إلى أن التحقيق المبكر نظر في DNS قبل تأكيد أن WAN هو المصدر. [4] ولا ينبغي تهويل هذا التسلسل. فقد تصاحب مهلات DNS مشاكل قابلية وصول واسعة، ومن المعقول أن يختبر المستجيبون فرضيات متعددة. والسؤال المفيد هو ما إذا كانت قابلية الملاحظة تستطيع التمييز بسرعة بين العَرَض والآلية.

من منظور المستخدم، قد يبدو استعلام DNS الفاشل ومهلة HTTP وفشل المصادقة كلها عدم توفر للخدمة. ومن منظور المشغّل، تنشأ في طبقات مختلفة وتتطلب سلطة تعافٍ مختلفة. وإذا كانت الشبكة تُسقط الحزم، فقد تتضاعف إنذارات مستوى التطبيق بينما تفشل في تحديد السبب المشترك.

تصف وثائق Microsoft الحالية أدوات مثل Network Watcher وConnection Monitor التي يمكنها جمع أدلة الاتصال وقابلية الوصول والطوبولوجيا والتشخيص. [12]-[15] وتوضح هذه القدرات ما يمكن أن يحتفظ به تصميم مراقبة متعدد الطبقات، لكنها ليست دليلًا على أن الأدوات أو الإعدادات أو التنبيهات نفسها غطت مسارات يناير 2023.

مجموعة أدلة الحادث المفيدة ستحاذي الإشارات حسب الطبقة:

1. أحداث متحكم التغيير التي تُظهر الأمر الدقيق والهدف.
2. سجلات الموجّهات التي تُظهر توليد الرسائل وتغييرات الجوار.
3. معلومات المسارات التي تُظهر المسارات المختارة والمسحوبة.
4. أدلة التوجيه التي تُظهر الخطوات التالية المثبَّتة.
5. مسابير نشطة عبر الإنترنت والمناطق وExpressRoute.
6. معاملات DNS والتطبيقات التي تُظهر الأعراض المرئية للعملاء.
7. بيانات تبعية الخدمة التي تُظهر الإخفاقات التي تشترك في مسار الشبكة نفسه.

الهدف ليس إلغاء اختبار الفرضيات، بل جعل فشل الشبكة الشائع مقروءًا قبل أن تفتح كل خدمة تابعة حادثًا منفصلًا. فإذا ارتفع تقلّب المسارات وإعادة حساب الجوار وفقدان الحزم في الوقت نفسه مع مهلات DNS وHTTP، يجب أن يكون نظام الاستجابة قادرًا على ربطها.

تحتاج المراقبة أيضًا إلى استقلال عن المسار المتأثر. فلوحة معلومات لا يمكن الوصول إليها إلا عبر WAN الفاشلة قد تختفي عند أشد الحاجة إليها. والمسابير التي تشترك في نطاق التوجيه نفسه قد تؤكد بعضها النقطة العمياء لبعضها الآخر. ومراقبو BGP الخارجيون، والعملاء التركيبيون خارج الشبكة، واتصال الإدارة المنفصل، وقياسات المزوّد الداخلية يغطي كل منها حدودًا مختلفة.

تسأل المساءلة ليس فقط ما إذا كان تنبيه قد انطلق، بل ما الذي يستطيع التنبيه إثباته. فمهلة DNS تثبت معاملة فاشلة، وسحب BGP يثبت تحديث مسار مرصود من نقطة مراقبة، ولقطة جدول توجيه تثبت حالة مثبّتة على جهاز. والتفسير الكامل يحتاج إلى ربط السجلات دون معاملة أحدها بديلًا عن البقية.

يُظهر ExpressRoute أين تنتقل المسؤولية وأين لا تنتقل

يمنح ExpressRoute العملاء اتصالًا خاصًا بخدمات Microsoft السحابية عبر مزوّدي اتصال ومواقع حافة Microsoft، ويستخدم BGP لتبادل المسارات، وتوصي Microsoft بدوائر فائضة ومواقع متنوعة وبنية عملاء مرنة. [8]-[11]

هذه الضوابط مهمة. فعميل يعتمد على دائرة واحدة، أو موقع نظير واحد، أو مزوّد واحد، أو موجّه محلي واحد يخلق تمركزًا يمكن تجنبه. ويمكن للعميل مراقبة جلساته، والتحقق من المسارات المعلنة، واختبار تجاوز الفشل، وتصميم التطبيقات لتحمّل فقدان مسار.

لكن وفرة العملاء لا تنقل السيطرة على تغيير شبكة Microsoft العالمية الخاصة. فالعملاء لم يختاروا الأمر، ولم يؤهلوا سلوكه عبر أسطول موجّهات Microsoft، ولم يقرروا أي أجهزة WAN تلقت الرسائل، ولم يتحكموا في التقارب الداخلي، ولم يستطيعوا فحص كل جدول توجيه لدى Microsoft أو إيقاف طرح المزوّد.

هذه الحدود تمنع خطأين متعاكسين: الأول معاملة مزوّد السحابة كمسؤول عن كل نتيجة تخص العميل، بما في ذلك الإخفاقات في البنية المملوكة للعميل؛ والثاني استخدام إرشادات مرونة العملاء للتماس عذر لحدث نمط مشترك يتحكم فيه المزوّد.

يمكن رسم المسؤولية بحسب السيطرة:

الجدول لا يحدد مسؤولية قانونية، بل يُبقي المسؤولية الواقعية متوافقة مع السلطة التشغيلية.

كما يُظهر حدث يناير لماذا يجب اختبار تنوع المسارات الاسمي مقابل الأنماط المشتركة لدى المزوّد. فقد تنتهي دائرتا عميل عند نقاط مادية مختلفة ومع ذلك تعتمدان على تحكم العمود الفقري نفسه لدى Microsoft. وقد يظل تراجع الإنترنت العام يصل إلى الخدمات عبر WAN المتأثرة نفسها. فالمرونة الحقيقية تتطلب معرفة الإخفاقات التي لا تشترك فيها المسارات.

إرشادات Microsoft للتوافر العالي مفيدة لتصميم جانب العميل. [9] وسجل الحادث ضروري لتقييم جانب المزوّد. وكلاهما مطلوب، ولا ينبغي استخدام أحدهما لمحو الآخر.

تأهيل الأجهزة ينبغي أن يكون نظام أدلة مُصانًا

الاختبار المختبري لمرة واحدة لا يكفي لأسطول موجّهات غير متجانس. فمجموعات الأجهزة تتغير، والبرمجيات تُرقّى، وبطاقات الخطوط والميزات وقوالب السياسات وأدوار الطوبولوجيا تتطور. والأمر المُثبت على إصدار واحد قد يصبح غير مُثبت عندما تتغير مجموعة الإنتاج.

التفسير العلني بأن سلوك الأمر اختلف عبر الأجهزة يخلق طلب دليل ملموس: ما المصفوفة التي ربطت دلالات الأمر بالطراز والبرمجيات والميزة والدور؟

لا ينبغي أن تكون تلك المصفوفة جدولًا ثابتًا منفصلًا عن النشر، بل يجب توليدها من الجرد الحالي وربطها بالتغيير. وينبغي أن تحدد لكل هدف:

• عائلة العتاد ومكونات التوجيه ذات الصلة.
• إصدار نظام تشغيل الشبكة ومستوى التصحيح.
• مجموعة الميزات المفعلة وسلوك محلل الإعداد.
• دور التوجيه وعدد النظراء وحجم المسارات.
• توسيع الأمر المتوقع وانتقال الحالة.
• أدلة مخبرية أو ما قبل إنتاج تستخدم الخصائص نفسها.
• الاستثناءات المعروفة والتوليفات المحظورة.
• تاريخ ومالك نتيجة التأهيل.

يجب أن يفشل متحكم النشر بإغلاق عندما لا يملك الهدف دليلًا حاليًا، وألا يستطيع المشغّل تحويل «غير معروف» إلى «متوافق» بمجرد المتابعة. وإذا كان التنفيذ الطارئ ضروريًا، فيجب أن يكون الاستثناء صريحًا وضيقًا ومقيدًا بزمن ومصحوبًا بنطاق تأثير أصغر وملاحظة أقوى.

ورد أن Microsoft قالت إنها ستحظر الأوامر عالية التأثير وستنشئ إرشادات تنفيذ آمن. [4] والحظر قيّم عندما تكون فئة الأوامر المحظورة دقيقة ولا يمكن تجاوز نقطة الإنفاذ عرضًا. أما الإرشادات فأضعف لأنها تعتمد على التفسير والامتثال.

لذلك فإن أسئلة المتابعة المفيدة تشغيلية:

• ما أنماط الأوامر التي أصبحت محظورة؟
• في أي طبقة حُظرت: العميل، أم متحكم الأتمتة، أم الجهاز، أم خدمة التفويض؟
• هل تشمل الأسماء المستعارة والقوالب وواجهات البرمجة والمتغيرات الخاصة بالمورد؟
• هل يستطيع الوصول الطارئ تجاوز الحظر، ومن يوافق عليه؟
• هل يراعي الحظر الطوبولوجيا وعدد المستقبلين؟
• كيف يُختبر الضابط بعد ترقيات البرمجيات؟
• ما الدليل الذي يُظهر أن الأمر المحظور لا يستطيع الوصول إلى الإنتاج عبر مسار آخر؟

لا يجيب السجل العام عن هذه الأسئلة. وطرحها لا يعني أن Microsoft أخفقت في التصرف، بل يحدد ما الذي يحوّل بيان المعالجة إلى دليل تشغيل قابل للتحقق.

ثوابت المسارات تجعل الواقع المتوقع قابلًا للاختبار

غالبًا ما تتحقق أنظمة التغيير من الصياغة وفروق الإعداد. لكن الأمر الصحيح صياغيًا قد ينتهك غرض الشبكة. وثوابت المسارات تعبّر عن ذلك الغرض بعبارات يستطيع النظام اختبارها.

بالنسبة لهذا الحادث، كان يمكن أن تغطي الثوابت أربع طبقات على الأقل.

ثوابت الجوارستحدد النظائر الحرجة التي يجب أن تظل قائمة، وعمليات إعادة الضبط المخطط لها المسموحة، وعدد الخسائر المتزامنة المقبول. فأي إعادة حساب واسعة خارج المجموعة المعتمدة ستوقف التغيير.

ثوابت المساراتستحدد البادئات المطلوبة، وتوقعات الأصل والخطوة التالية، وتغييرات المسار المسموحة، والحد الأقصى لعمليات السحب. وستكشف متى خرجت قابلية الوصول عن تحديث عنوان IP المقصود.

ثوابت التوجيهستختبر ما إذا كانت الموجّهات ثبّتت خطوات تالية قابلة للاستخدام وما إذا كانت الحزم التمثيلية تستطيع عبورها. فاتفاق مستوى التحكم لا يكفي إذا كانت حالة التوجيه غائبة أو غير متسقة.

ثوابت مسارات الخدمةستفحص مسارات الإنترنت إلى Azure، وبين المناطق، وخدمات Microsoft، والإدارة، وExpressRoute. وستربط حالة الموجّه بالتبعيات التي يستخدمها العملاء فعلًا.

تحتاج مجموعة الثوابت إلى ملكية ومصدر. فقائمة المسارات الحرجة تصبح قديمة إذا أنشأت فرق الخدمات تبعيات جديدة دون تحديثها. والمسبر يصبح مضللًا إذا اختبر مسارًا سليمًا فقط. وسجل البادئة المتوقعة يصبح خطرًا إذا نُقل عنوان أو تغيّر دور توجيه دون تحديث السجل.

هنا يدعم انضباط السجلات العمليات دون ادعاء حكم الواقع. فالمعرّفات الدقيقة وسجلات البادئات وعلاقات ASN وأدوار المسارات وبيانات الملكية تساعد المشغّل على تحديد ما يجب أن يكون موجودًا، لكنها لا تجعل المسار قابلًا للوصول. ويظل الكود العامل وتسليم الحزم المرصود الطبقة الحاسمة.

يقارن النظام الخاضع للمساءلة السجل المتوقع بملاحظات متعددة، فيفحص مخرجات الإعداد ومعلومات التوجيه ومدخلات التوجيه والمسابير النشطة ومناظر المسارات الخارجية. وعدم التطابق ليس تلقائيًا دليل حادث، لكنه سبب لإيقاف طرح عالي التأثير حتى يُفهم الاختلاف.

النموذج نفسه يحسّن مراجعة ما بعد الحادث. فبدلًا من القول فقط إن «الشبكة استُعيدت»، يستطيع التقرير إظهار الثوابت التي فشلت، ومتى عاد كل منها إلى طبيعته، وأيها ظل غير مؤكد. وهذا يجعل التعافي قابلًا للتدقيق واختبارات التراجع المستقبلية ملموسة.

الاختبار التجريبي التمثيلي يجب أن يمارس مسار الانتشار

كثيرًا ما يوصف النشر التجريبي بأنه تطبيق تغيير على عدد صغير من الأهداف. والصغر مفيد، لكن التمثيل أهم. فاختبار تجريبي لا يستطيع إظهار الفشل المعني يقدم ضمانًا ضعيفًا حتى لو ظل سليمًا.

بالنسبة لأمر WAN يعتمد على الجهاز، يجب أن يطابق الاختبار التجريبي التمثيلي دلالات الأمر، وعائلة البرمجيات، ودور التوجيه، وعلاقات النظراء، وسلوك الانتشار لهدف الإنتاج. كما يجب أن يكون معزولًا بما يكفي بحيث لا يؤدي فشله إلى إعادة الحساب العالمية نفسها التي يفترض أن يكشفها الاختبار.

هذه التركيبة صعبة. فإذا كان أثر الأمر الخطير لا يظهر إلا عندما تصل الرسائل إلى موجّهات كثيرة، فقد لا يعيد جهاز معزول واحد إنتاجه. والحل ليس التخلي عن التجهيز، بل بناء بيئة اختبار أو نطاق إنتاج مقيّد يعيد إنتاج الرسم البياني المعني مع تقييد العواقب الخارجية.

يمكن أن يكون التسلسل القوي:

1. عرض وتحليل الأمر الدقيق ثابتًا مقابل الجرد.
2. إعادة تشغيله في مختبر تمثيلي أو بيئة محاكاة شبكة.
3. تأكيد تغييرات الجوار والمسار والتوجيه المتوقعة.
4. تطبيقه على نطاق إنتاج مقيّد واحد مع وصول إدارة مستقل.
5. الملاحظة لفترة تقارب واستقرار كاملة.
6. مقارنة الحالة الداخلية بالمسابير الخارجية للمسارات وقابلية الوصول.
7. التقدم إلى النطاق التالي فقط بعد اجتياز دليل صريح.

تصف وثائق Microsoft الحالية مفاهيم محاكاة الشبكة والمراقبة في هندسة شبكتها العالمية، إضافة إلى أدوات تشخيص موجهة للعملاء. [7][12]-[15] وتشير هذه المواد إلى آليات يمكن أن تدعم مثل هذا التسلسل، لكنها لا تثبت سير عمل 2023 الدقيق.

يجب أن يتضمن سجل الاختبار التجريبي معايير الفشل والنجاح. ما عدد عمليات السحب الذي يوقف الطرح؟ وما تغيير الجوار المتوقع؟ وما مقدار فقدان الحزم المقبول؟ وكم يمكن أن يستمر التقارب قبل التراجع؟ ومن يستطيع إعلان أن مقياسًا مضلل؟

من دون معايير محددة مسبقًا، قد يبرر المستجيبون تحذيرًا بأنه تقارب طبيعي حتى يتسع نطاق التأثير. أما مع المعايير، فيصبح التوقف هو النتيجة الافتراضية عندما يبتعد الواقع عن النموذج المعتمد.

يجب أن يراعي التراجع الحالة الموزعة

التراجع عن تغيير شبكة ليس دائمًا مكافئًا لإلغاء سطر واحد على جهاز واحد. فقد تكون موجّهات أخرى تلقت رسائل، وأعادت حساب المسارات، وثبّتت مدخلات توجيه، وحوّلت الحركة، وشغّلت أتمتة. واستعادة الإعداد المبدئي ضرورية، لكن الشبكة ما زالت بحاجة إلى التقارب إلى حالة مستقرة.

قالت Microsoft إنه بحلول الوقت الذي حددت فيه تغيير WAN الأخير كسبب جذري، كان التعافي التلقائي قد بدأ بالفعل، مع بدء إجراءات التعافي بعد 08:10 بالتوقيت العالمي المنسق بقليل. [1][3][4] ولا يكشف السجل العام كل خطوة تراجع. وهذا الحد مهم لأن أدلة التعافي يجب أن تميز بين عكس الأمر واستقرار المسارات واستعادة الخدمة.

خطة تراجع قابلة للتحقق ستجيب عن:

• أي إعداد أو أمر يُعكس؟
• أي الأجهزة تلقت حالة تابعة ويجب أن تعيد التقارب؟
• ما الحالة المرغوبة الموثوقة؟
• كيف يمنع المشغّل إجراءات معالجة متنافسة؟
• أي فحوصات المسار والتوجيه وقابلية الوصول تعلن التعافي؟
• هل يمكن أن يمضي التراجع عبر مسار إدارة مستقل عن WAN المتأثرة؟
• كيف تُفصل آثار الخدمة المتبقية عن استمرار فشل الشبكة؟
• متى يكون إغلاق الحادث آمنًا؟

يمكن للأتمتة تقليل التأخير، لكن فقط إذا كان مشغّلها ونطاقها جديرين بالثقة. فالتراجع التلقائي القائم فقط على حالة خروج الأمر قد يفوت فشل المسار، والقائم على معدل خطأ التطبيق قد يتفاعل متأخرًا أو مع مشكلة غير ذات صلة. أما المشغّل المركب فيستطيع مقارنة تغييرات الشبكة المتوقعة الدقيقة بالثوابت المحمية.

يجب أن يحافظ سجل التعافي أيضًا على الترتيب السببي. إذا استقرت المسارات حوالي 08:10، وتعافت معظم الخدمات حوالي 09:00، واستقرت المعدات بحلول 09:35، واستمرت بعض آثار Microsoft 365 حتى 12:43، فإن طابعًا زمنيًا واحدًا «تم الحل» يُخفي تمييزات مفيدة. [1][3][4]

تساعد هذه التمييزات المشغّلين على اختبار تدريبات مستقبلية، فيستطيعون قياس زمن كشف آلية الشبكة، وزمن إيقاف الانتشار، وزمن استعادة استقرار المسارات، وزمن استعادة التوجيه، وزمن تصفية آثار الخدمة التابعة. وتحسين مقياس واحد لا يحسّن المقاييس الأخرى تلقائيًا.

لذلك فإن التراجع نظام ضبط، لا زر. ومصداقيته تقوم على أدلة محفوظة تُظهر أن الشبكة الموزعة عادت إلى الواقع التشغيلي المقصود.

القياس العام يجب مواءمته لا معاملته كديكور

كثيرًا ما تستشهد تقارير الحوادث بقياسات خارجية بعد وقوعها. أما الاستخدام الأقوى فهو دمج الملاحظة المستقلة في قرارات التغيير والتعافي.

بالنسبة لشبكة مواجهة للإنترنت، يمكن لبيانات BGP الخارجية كشف عمليات السحب وإعادة الإعلان وتغييرات المسارات والاختلافات بين النظراء، ويمكن للمسابير النشطة إظهار فقدان الحزم والكمون ونتائج DNS وقابلية وصول التطبيقات من شبكات متعددة. وهذه الإشارات لا تحل محل القياسات الداخلية، لكنها تغطي ما قد تفوته نقاط مراقبة المشغّل نفسه.

يُظهر حادث يناير لماذا كلاهما مطلوب. استطاعت Microsoft رؤية حالة الأجهزة الداخلية، واستطاعت ThousandEyes رؤية آثار المسارات والحزم خارج Microsoft. [3] وقد يرى عميل أو نظير حدًا ثالثًا. ولا توجد نقطة مراقبة واحدة تحدد الشبكة كلها.

يجب أن تحافظ المواءمة على الطوابع الزمنية والنطاق وعدم اليقين. فقد يسبق تغيير مسار داخلي على موجّه واحد سحبًا خارجيًا، وقد يتلقى مجمّع تحديثًا بعد تأخير سياسة وسيطة، وقد يفشل مسبر حزم قبل سحب مسار رسمي لأن التوجيه غير متسق بالفعل، وقد يواصل مسبر آخر النجاح عبر مسار يظل متاحًا.

لذلك يجب أن يتجنب نظام الأدلة دمج كل إشارة في جدول زمني مبسط واحد، وأن يحتفظ بـ:

• الطوابع الزمنية الأصلية ومصدر الساعة.
• هوية نقطة المراقبة وشبكتها.
• البادئة والنظير والمسار المرصود.
• تصنيف مستوى التحكم مقابل مستوى التوجيه.
• الثقة والنقاط العمياء المعروفة.
• روابط بإجراء التغيير والتعافي الذي يُعتقد أنه يقابلها.

التحليل التجاري لمراقب خارجي ليس معرفة كلية محايدة، فله خيارات تغطية وحدود منهجية، والأمر نفسه ينطبق على لوحات معلومات المشغّل. وتتحسن المساءلة عندما يذكر كل مصدر ما قاسه ويختبر التقرير الاتفاق والاختلاف بينها.

هذا يحمي أيضًا من المبالغة في الادعاء. فتقلّب BGP العام لا يثبت فشل كل مسار خاص في Azure، والمسابير الناجحة من شبكة واحدة لا تنفي إخفاقات في مكان آخر، وتسمية خدمة عالمية لا تعني تأثيرًا موحدًا. ويصبح السجل أكثر مصداقية عندما يُبقي هذه الحدود مرئية.

لم يكن RPKI ليصادق على هذا الأمر

قد يؤدي وجود تقلّب مسارات BGP إلى توصية تلقائية بـRPKI. وهذا يخلط بين مشكلتي ضبط مختلفتين.

يساعد RPKI والتحقق من أصل المسار الشبكة على تقييم ما إذا كان نظام مستقل مخولًا بالإعلان عن بادئة، وهما حمايتان مهمتان ضد الأصول غير المصرح بها أو الخاطئة. أما هذا الحادث، بحسب الوصف العلني، فكان يتعلق بتغيير مخطط داخل WAN لدى Microsoft، وسلوك أمر يعتمد على الجهاز، وتقارب توجيه واسع. ولا يقول الدليل المتاح إن نظامًا مستقلًا غير مصرح به أعلن بادئات Microsoft.

يمكن أن يكون الأصل صالحًا بينما المسار خاطئ تشغيليًا. فقد تُعلن بادئة من النظام المستقل المصرح به لكن عبر سياسة غير مقصودة، أو بنطاق خاطئ، أو أثناء تقارب غير مستقر. ولا يصادق RPKI على الأمر الداخلي، أو كل جوار، أو الخطوة التالية المختارة، أو تثبيت جدول التوجيه، أو تصميم الاختبار التجريبي، أو تسلسل التراجع.

هذه الحدود لا تجعل بيانات السجلات والتفويض غير ذات صلة. فسجلات البادئات وASN الدقيقة تساعد في تحديد الأصول المتوقعة وكشف فئة مختلفة من الأخطاء، ويجب أن تكون جزءًا من مجموعة الثوابت، لكن لا يمكن ترقيتها إلى إثبات استمرارية الشبكة.

يعكس التمييز مبدأ تشغيليًا أوسع: السجلات تثبت الهوية والتفويض والعلاقات المتوقعة، والموجّهات العاملة تثبت قابلية الوصول. والأولى يمكنها تقييد الثانية وتدقيقها، لكنها ليست حاكمة عليها. فتسليم الحزم يتبع الحالة المثبَّتة.

لذلك فإن ضوابط الأولوية لحدث يناير هي تأهيل الأجهزة، ونطاق الأمر، وثوابت المسارات والتوجيه، والانتشار المقيّد، والملاحظة الخارجية، والتراجع. ويظل RPKI ضابطًا مجاورًا، لا الإصلاح المفقود الذي يدعيه الدليل.

هذه الدقة مهمة للمساءلة العامة. فالتوصيات العامة قد تجعل المقال يبدو مطلعًا تقنيًا بينما يتجنب الفشل الفعلي. والمعالجة مفيدة فقط عندما تعالج الآلية التي يدعمها السجل.

الوثائق الحالية ادعاء ضبط لا إثبات تاريخي

تصف وثائق شبكة Microsoft الحالية عمودًا فقريًا عالميًا، وربطًا مباشرًا، ومرونة ExpressRoute، وNetwork Watcher، وConnection Monitor، وتصميم مراقبة. [7]-[17] وهذه المواد مفيدة لفهم البنية والأدوات المتاحة للمشغّلين والعملاء.

لكنها ليست آلة زمن. فصفحة حُدّثت بعد يناير 2023 لا تستطيع إثبات الإعداد أو سير العمل أو الإنفاذ الذي كان موجودًا أثناء الحادث، ولا إثبات أن عملية معلنة تعمل باستمرار عبر كل جهاز.

يجب أن يشكل هذا التمييز كيفية تقييم المعالجة. فالوثائق العامة تستطيع الإجابة عن:

• ما التصميم الذي تصفه Microsoft حاليًا؟
• ما ميزات المراقبة والمرونة المتاحة حاليًا؟
• ما المسؤوليات التي تسندها Microsoft إلى العملاء؟
• ما آليات الأدلة التي يمكن استخدامها؟

لكنها لا تستطيع وحدها الإجابة عن:

• هل خضع أمر WAN الدقيق للاختبار على الموجّه المتأثر؟
• أي الأجهزة تلقت الرسائل المنتشرة؟
• أي ثوابت المسارات فُحصت قبل الطرح؟
• هل منع حظر تلقائي أوامر مماثلة بعد المعالجة؟
• هل مارست Microsoft التراجع في ظروف تمثيلية؟

إثبات الإصلاح الدائم يتطلب أدلة أقرب إلى التشغيل: اختبارات سياسة ككود، وسجلات أوامر محظورة، ومصفوفات تأهيل، وسجلات اختبارات تجريبية، وتاريخ مسابير تركيبية، وتمارين تراجع، وبيانات تكرار الحوادث. وقد يكون بعضها حساسًا تجاريًا أو أمنيًا. ويمكن للسرية تبرير الحجب، لكنها لا تحوّل صفحة بنية عامة إلى إثبات.

يمكن للمشغّل نشر أدلة مجمعة دون كشف تفاصيل قابلة للاستغلال، فيبلغ بنسب تغطية عائلات الأجهزة المؤهلة، وعدد فئات الأوامر عالية التأثير المحظورة، والحد الأقصى المسموح لنطاق الانتشار، وتواتر تمارين التراجع، وما إذا كانت المسابير المستقلة أكدت كل تغيير كبير. ويجب أن يكون للمقاييس تعريفات وسجلات تدقيق محفوظة.

الانضباط نفسه ينطبق على الادعاءات الموجهة للعملاء. فقد تقدم خدمة ميزات توجيه ومراقبة فائضة، ومع ذلك يظل العميل بحاجة إلى اختبار المسارات التي اشتراها. فالوثائق تصف القدرة، والدليل التشغيلي يُظهر ما إذا كانت تلك القدرة حمَت تبعية معينة.

المساءلة تتبع السيطرة والدليل والإصلاح

من المغري اختزال انقطاع كبير في اللوم. لكن الأدلة العامة تدعم توزيعًا أكثر فائدة.

سيطرت Microsoft على تغيير WAN المخطط، وجرد الموجّهات، وتنفيذ الأوامر، والرسائل الداخلية، وحدود الانتشار، والمراقبة، والتعافي، والتفسير العلني للحادث. وهذه السيطرة تخلق واجب تأهيل السلوك، وتقييد النطاق، وحفظ الأدلة، والتحقق من الإصلاح.

سيطر موردو الموجّهات على دلالات المنتج ووثائقه، لكن السجل العام لا يحدد موردًا ولا يثبت عيب منتج، ولا يوجد ما يبرر ادعاء خطأ مورد.

سيطر مزوّدو الاتصال على دوائر عملائهم وحواف الربط، وسيطر العملاء على توجيههم ووفرة مساراتهم ورسم تبعياتهم وتجاوز فشل تطبيقاتهم. وهذه الضوابط تؤثر على العواقب وخيارات التعافي، لكنها لم تسبب أمر Microsoft الداخلي ولم تحكمه.

سيطر المراقبون المستقلون على أنظمة قياسهم، وواجبهم هو الوضوح المنهجي: أين قاسوا، وماذا رأوا، وما لا يستطيعون استنتاجه.

تشمل المساءلة أيضًا الإصلاح. فالإصلاح الموثوق ليس مجرد غياب حادث عام آخر، بل دليل على تقييد فئة الفشل. وفي هذه الحالة، يعني ذلك إظهار أن:

1. سلوك الأوامر المعتمد على الجهاز مُجرد ومُختبَر.
2. الأوامر عالية التأثير محظورة تقنيًا أو مرخّصة بإحكام.
3. لا يمكن أن يتجاوز الانتشار نطاقًا محددًا دون دليل ناجح.
4. المسارات المطلوبة وقابلية الوصول تُفحص آليًا.
5. الملاحظات الخارجية جزء من القبول والتعافي.
6. يستعيد التراجع الحالة الموزعة، لا الجهاز الأول فقط.
7. تُظهر التمارين أن الضوابط ما زالت تعمل بعد تغييرات الأسطول.

يدعم السجل العام طلب هذه الإثباتات، لكنه لا يدعم إعلان أن Microsoft تجاهلتها، أو أخفت الحدث، أو خالفت قانونًا، أو تصرفت بإهمال.

هذا النهج المقيّد ليس تساهلًا، بل معيار أشد من اللوم الخطابي لأن كل نتيجة وادعاء معالجة يجب أن يرتبط بطرف وضابط وسجل محفوظ ونتيجة قابلة للملاحظة.

جدول أدلة لتغيير WAN العالمي التالي

يحوّل الجدول التالي الحادث إلى سجلات يمكن فحصها، ولا يدّعي أن Microsoft تفتقر إلى كل بند، بل يحدد ما الذي يثبت الضبط.

يفصل الجدول بين السجل والنتيجة. فالوثيقة تثبت أن ضابطًا حُدد، والملاحظة التشغيلية تثبت ما حدث أثناء تنفيذ، وكلاهما ضروري.

كما يحافظ على الحدود غير المحسومة. فأنظمة الأدلة تصبح مضللة عندما تقدم قياسًا جزئيًا كيقين كامل. فجامع مسارات لا يرى كل مسار خاص، والاختبار التجريبي لا يمثل كل مسار عميل، وتمرين تراجع ناجح قد يصبح قديمًا بعد ترقية، وتسمية الحدود تخلق الاختبار التالي.

أجندة تحقق مقيّدة

يمكن أن يدعم الحادث مجموعة أسئلة ملموسة دون تخمين.

دلالات الأمر

• ما سلوك الأمر الدقيق الذي اختلف عبر الأجهزة؟
• أي عتاد أو برمجيات أو دور أو سياق إعداد فسّر الاختلاف؟
• هل روجع الأمر المرشح بالشكل المُنفَّذ نفسه الذي نُفّذ به؟
• أي ضابط حالي يمنع متغيرًا غير مؤهَّل من الوصول إلى الإنتاج؟

الانتشار

• أي الموجّهات تلقت رسائل من التغيير المبدئي؟
• ما مجموعة المستقبلين المقصودة؟
• أي عمليات إعادة حساب للجوار والتوجيه كانت متوقعة؟
• ما الحد التقني الذي يقيد الآن فئة التغيير نفسها؟

حالة المسار والتوجيه

• أي البادئات والمسارات تغيرت؟
• أي ثوابت المسارات كانت ستكشف الانحراف؟
• متى أصبح التوجيه غير متسق، ومتى استقر؟
• كيف ووئمت الملاحظات الداخلية مع تقلّب BGP الخارجي؟

قابلية الوصول

• أي مسارات الإنترنت وبين المناطق وExpressRoute والإدارة فشلت؟
• أي المسابير واصلت العمل، ولماذا؟
• هل امتلكت المسارات البديلة سعة كافية؟
• ما الدليل الذي ميّز أعراض DNS عن فشل WAN؟

التعافي

• ما الإجراء الذي بدأ التعافي التلقائي؟
• أي الأنظمة اضطرت إلى إعادة التقارب بعد عكس الأمر المبدئي؟
• ما المعايير التي أعلنت استقرار معدات الشبكة؟
• لماذا استمرت بعض آثار الخدمة بعد استقرار المسارات الواسع؟

المتانة

• هل الأوامر عالية التأثير محظورة تقنيًا أم محكومة بالإرشادات فقط؟
• كم مرة تُحدَّث مصفوفة تأهيل الأجهزة؟
• متى مُورس التراجع آخر مرة مقابل طوبولوجيا تمثيلية؟
• ما الأدلة المجمعة التي يمكن أن تُظهر استمرار الإنفاذ دون كشف إعداد حساس؟

هذه الأسئلة ضيقة بما يكفي للإجابة وقوية بما يكفي لتغيير الممارسة، وهي تركز على واقع الشبكة العامل بدلًا من وعود عامة بالمرونة.

الخلاصة

أظهر انقطاع Microsoft في يناير 2023 كيف يمكن لهدف صيانة WAN روتيني أن يتحول إلى حدث بنية تحتية عالمي عندما لا تكون دلالات الأوامر وتنوع الأجهزة والانتشار والتقارب مقيّدة بحالة مُتحقق منها.

الدليل مفيد على نحو غير معتاد لأنه يأتي من مستويين. فسرد Microsoft يربط الحادث بتغيير مخطط لعنوان موجّه، وسلوك أمر يعتمد على الجهاز، ورسائل إلى موجّهات WAN أخرى، وإعادة حساب الجوار والتوجيه، وفشل توجيه الحزم. ورصدت ThousandEyes بشكل مستقل سحوبات BGP وإعادة إعلانات وتقلّب مسارات وفقدان حزم حول شبكة Microsoft. [1]-[4]

لا يوجد سجل كامل، لكنهما معًا يحددان معيار مساءلة.

يجب أن ترتبط تذكرة التغيير بالأمر الدقيق الذي ستنفذه الموجّهات، وأن يغطي التأهيل مجموعة أجهزة وبرمجيات الإنتاج، وأن يمارس الاختبار التجريبي الطوبولوجيا ذات الصلة مع تقييد الانتشار، وأن توقف ثوابت المسار والتوجيه ومسار الخدمة الطرح عندما يبتعد الواقع عن النية، وأن يختبر المراقبون المستقلون ما يغادر نطاق المشغّل، وأن يستعيد التراجع الحالة الموزعة ويحفظ جدولًا زمنيًا من تعافي المسار حتى استعادة الخدمة.

سجلات الشبكة الدقيقة مهمة، فالبادئات وعلاقات AS وجرد الأجهزة والطوبولوجيا ومصدر الأوامر والمسارات المتوقعة تجعل النظام قابلًا للاختبار، لكنها لا تتحكم في تسليم الحزم بالإعلان. ويظل الإعداد العامل وحالة التوجيه الناتجة حاسمين.

هذا هو درس المساءلة الجوهري: المشغّل الذي يتحكم في الأمر ونطاق الانتشار يجب أن يقدم دليلًا على أن الشبكة تصرفت كما اعتُمد، لا فقط أن التغيير كان مخططًا. ويحتفظ العملاء والمزوّدون بواجبات ضمن سيطرتهم، لكنهم لا يستطيعون تأهيل أو إيقاف أمر العمود الفقري الخاص لمشغّل سحابي. ويمكن للمعايير وRPKI تقييد مخاطر مجاورة، لكنها لا تستطيع التحقق من مسار تنفيذ خاص بجهاز.

لذلك فإن أقوى إصلاح ليس وعدًا أوسع بالحذر، بل سلسلة حالية قابلة للتدقيق من النية إلى الأمر المُنفَّذ، والتأهيل التمثيلي، والانتشار المقيّد، وحالة المسار المرصودة، وقابلية الوصول المستقلة، والتراجع المنضبط، والتمرين المتكرر. وأي شيء أقل يترك تغيير WAN العالمي التالي محكومًا بالتوقع أكثر من الإثبات.

قيود المصادر

تقرير Microsoft 365 الجاهز للعملاء المستخدم هنا يعرّف نفسه بأنه أولي ويحيل القراء إلى سجل حالة Azure لحادث WAN ذي الصلة. وصفحات حالة Microsoft ديناميكية، وقد تتطلب التفاصيل التاريخية معرّف التتبع. وتلخص التقارير المعاصرة تفسير Microsoft العلني اللاحق، لكنها ليست بديلًا عن سجلات التغيير الداخلية. [1][2][4]

تقدم ThousandEyes ملاحظات مستقلة للمسارات والحزم من تغطية قياسها الخاصة، ولا تستطيع رؤيتها لـBGP إثبات كل مسار خاص أو أمر أو جوار أو مدخلة توجيه أو مسار عميل لدى Microsoft. [3]

تصف صفحات Microsoft Learn الحالية البنية والقدرات المتاحة وقت قراءتها، ولا تثبت الحالة الدقيقة للضوابط في 25 يناير 2023 أو إنفاذها المستمر بعد ذلك. [7]-[17]

لا يكشف السجل العام عن الأمر الدقيق، أو جرد الأجهزة والبرمجيات الكامل، أو مجموعة البادئات المتأثرة الكاملة، أو كل السجلات الداخلية، أو الخسائر الخاصة بالعملاء، أو الأرصدة التعاقدية، أو النتائج التنظيمية، أو النية الخبيثة، أو الإهمال، أو خطأ المورد. وهذا المقال لا يقدم أيًا من هذه الادعاءات.

المصادر

1. https://content.mailplus.nl/m18/docs/user318000551/1126/Post_Incident_Report_Microsoft_verstoring_25_01_23__MO502273___VSG1_B90_.pdf
2. https://azure.status.microsoft/en-us/status/history/?q=VSG1-B90
3. https://www.thousandeyes.com/blog/microsoft-outage-analysis-january-25-2023
4. https://www.theregister.com/2023/01/30/microsoft_blames_router_ip_address_change/
5. https://www.networkworld.com/article/971873/global-microsoft-cloud-service-outage-traced-to-rapid-bgp-router-updates.html
6. https://techcrunch.com/2023/01/25/microsoft-teams-outlook-service-outage/
7. https://learn.microsoft.com/en-us/azure/networking/microsoft-global-network
8. https://learn.microsoft.com/en-us/azure/expressroute/expressroute-introduction
9. https://learn.microsoft.com/en-us/azure/expressroute/designing-for-high-availability-with-expressroute
10. https://learn.microsoft.com/en-us/azure/expressroute/expressroute-routing
11. https://learn.microsoft.com/en-us/azure/expressroute/expressroute-troubleshooting-expressroute-overview
12. https://learn.microsoft.com/en-us/azure/network-watcher/connection-monitor-overview
13. https://learn.microsoft.com/en-us/azure/network-watcher/
14. https://learn.microsoft.com/en-us/azure/networking/networking-overview
15. https://learn.microsoft.com/en-us/azure/networking/design-guide/monitor
16. https://learn.microsoft.com/en-us/azure/virtual-wan/virtual-wan-about
17. https://learn.microsoft.com/en-us/azure/virtual-wan/about-virtual-hub-routing
18. https://www.rfc-editor.org/rfc/rfc4271
19. https://www.rfc-editor.org/rfc/rfc7454
20. https://www.rfc-editor.org/rfc/rfc8326