تعطلت ChatGPT وClaude وGrok معًا: خطط الاستمرارية صارت ضرورة

تعرضت ChatGPT وClaude وGrok لأعطال تداخلت زمنيًا في 3 سبتمبر 2026، قبل أن تستعيد الخدمات عملها. ووثقت تغطية The Register تعذر استخدام ChatGPT وCodex لدى بعض المستخدمين، واضطراب خدمات Claude، ومشكلة Grok التي ربطتها الجهة المشغلة بانقطاع في مركز الحوسبة بممفيس.

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

الخط الزمني يكشف تداخلًا لا انقطاعًا واحدًا

كانت أول نافذة معلنة لدى Anthropic: بدأ ارتفاع الأخطاء في طلبات Claude Sonnet 5 عند 12:37 بالتوقيت العالمي، وطُبق إصلاح عند 12:47، ثم أُغلق الحادث عند 12:56. وبعد نصف ساعة، فتحت الشركة حادثًا آخر عند 13:26 شمل عدة نماذج؛ وتوضح سجلات حالة Claude الرسمية أن معظم النماذج تعافت أولًا، قبل انتهاء الأثر المتبقي عند 16:16 ونشر تحديث الحل عند 16:23.

هذا التفصيل يمنع وصف Claude بأنه كان متوقفًا بصورة متصلة منذ 12:37 حتى 16:16. السجل يعرض حادثين منفصلين، وبين إغلاق الأول وبدء الثاني نحو 30 دقيقة، كما يتحدث عن ارتفاع معدلات الأخطاء وتعافٍ تدريجي لا عن غياب كامل ومتساوٍ للخدمة لدى جميع المستخدمين.

بدأ التحقيق المعلن في عطل Grok عند 13:30 بالتوقيت العالمي، فتداخل مع الحادث الثاني لدى Claude. وعندما دخل ChatGPT وCodex نافذة الاضطراب، كانت مشكلات Claude وGrok لا تزال مستمرة؛ وهذه هي الفترة التي تبرر كلمة «معًا» في العنوان، من دون أن تعني أن الخدمات الثلاث تعطلت في الثانية نفسها أو بالطريقة نفسها.

أما OpenAI فبدأ سجلها العلني بالتحقيق عند 14:43، وانتقلت إلى المراقبة بعد تطبيق المعالجة عند 15:17، ثم أغلقت الحادث عند 16:55. وتبين صفحة حادثة OpenAI الصحيحة أن الأثر طال 15 مكونًا من ChatGPT وأربعة مكونات من Codex، وأن بعض مستخدمي التحكم عن بعد في Codex قد يحتاجون إلى إعادة إقران أجهزتهم المحمولة.

نطاق الأثر اختلف من مزود إلى آخر

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

لدى Anthropic، ظهرت الأخطاء أولًا في Sonnet 5، ثم شملت الحادثة الثانية نماذج من عائلات Mythos وFable وOpus. وبحلول 15:25 كان الأثر المعلن مقتصرًا على Opus 4.8 وOpus 5، قبل انتهاء المشكلة المتبقية عند 16:16؛ لذلك لم يكن مسار التعافي موحدًا بين النماذج.

وشمل الاضطراب الجزئي لدى Anthropic خدمات Claude.ai وClaude API وClaude Code وClaude Cowork، بينما سجلت منصات Grok مشكلة في النماذج قبل عودة حركة الاستخدام إلى وضعها الطبيعي. النتيجة العملية واحدة للمستخدم الذي تلقى رسالة خطأ، لكن النطاق الفني المعلن مختلف: توجيه لدى OpenAI، وبنية تحتية لدى Anthropic، ومركز حوسبة لدى الجهة المشغلة لـGrok.

لماذا لا يثبت التزامن سببًا سحابيًا مشتركًا؟

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

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

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

الحادث يجعل الاستمرارية مسألة تشغيلية

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

لذلك تحتاج الفرق التي أدخلت هذه الخدمات في عمليات لا تحتمل التوقف إلى خطة محددة وقابلة للاختبار:

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

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

اقرأ أيضًا:

• ChatGPT رفع جودة أعمال الطلاب 0.86 نقطة، لا تنوع الأفكار