ستة أنظمة سقطت معا: نقطة الفشل الواحدة التي لا تراها في بنيتك

ستة أنظمة سقطت معا: نقطة الفشل الواحدة التي لا تراها في بنيتك

في مساء 31 أغسطس 2026 بدأ عطل واسع في خدمات Microsoft 365 سجلته الشركة في لوحة الإدارة تحت الرقم EX1464935 ثم وسعته تحت الرقم MO1465074. ولم يقتصر الأثر على البريد. سقط معه Exchange Online و Teams و SharePoint Online و OneDrive for Business، ومعها أدوات الحوكمة والحماية Purview و Defender XDR. أي أن الشركة التي كانت تتصل بعملائها بالبريد، وتنسق داخليا بالمحادثات، وتحفظ ملفاتها في السحابة، وتراقب أمنها بلوحة، فقدت الأربعة في اللحظة نفسها.

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

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

ما تظنه ستة أنظمة قد يكون نظاما واحدا

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

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

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

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

ارسم خريطة اعتمادك في ساعة واحدة

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

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

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

أكثر أصناف الأعطال قابلية للمنع: تواريخ الانتهاء

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

هذي قائمة بتواريخ الانتهاء التي تدير عملك من خلف الستار، والتي يجب أن تكون كلها في تقويم واحد باسم مالك واضح:

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

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

ماذا تفعل في اليوم الذي يسقط فيه مزودك

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

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

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

نظرة أوريجامي

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

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

الخلاصة

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

مصادر

• BleepingComputer: تفاصيل عطل Microsoft 365 وأرقام البلاغات EX1464935 و MO1465074 وبيانات الشركة عن السبب والمعالجة
• Microsoft: صفحة حالة الخدمات السحابية الرسمية
• هيئة الزكاة والضريبة والجمارك: الإرشادات الفنية المفصلة للفوترة الإلكترونية، قسم التسجيل وتجديد معرف الختم المشفر
• Tom's Guide: التغطية الحية لانقطاع الخدمة يوم 31 أغسطس 2026