الذكاء الاصطناعي والأتمتة

تعطل ChatGPT وClaude وGrok معًا: خطة الاحتياط لم تعد رفاهية

|الكاتب: فريق تحرير QUASA|5 دقيقة للقراءة| 2
تعطل ChatGPT وClaude وGrok معًا: خطة الاحتياط لم تعد رفاهية

شهدت خدمات ChatGPT وClaude وGrok اضطرابات متداخلة في 3 سبتمبر 2026، قبل أن تعلن الجهات المشغلة استعادة التشغيل في اليوم نفسه. ويبين التسلسل الزمني الذي نشرته ITPro أن المشكلات لدى OpenAI وAnthropic وxAI بدأت في أوقات متقاربة، بين 6:23 و7:45 صباحًا بتوقيت المحيط الهادئ.

أكدت صفحة حالة OpenAI ارتفاع الأخطاء في ChatGPT وCodex ثم حل المشكلة، مع تنبيه إلى احتمال اضطرار بعض مستخدمي التحكم عن بُعد في Codex إلى إعادة إقران أجهزتهم المحمولة. كما سجلت صفحة حالة Grok على Android عطلًا في النماذج من 13:30 إلى 17:04 بالتوقيت العالمي، قبل إعلان عودة حركة الطلبات إلى وضع صحي.

تزامن مؤكد من دون سبب مشترك مؤكد

المؤكد هو تداخل فترات الاضطراب لدى الشركات الثلاث، لا سقوط كل منتجاتها بالطريقة نفسها أو للمدة نفسها. شملت حالة OpenAI خمسة عشر مكونًا في ChatGPT وأربعة مكونات في Codex، بينما تركزت تحديثات Anthropic على أخطاء مرتفعة في طلبات نماذج Claude، وسجلت xAI حالات منفصلة لواجهات Grok.

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

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

القرار الأول: إعادة المحاولة أم حفظ الطلب؟

طلبات تعتمد على ChatGPT وClaude وGrok تنتقل من إعادة المحاولة المحدودة إلى قائمة انتظار محفوظة أثناء الاضطراب.

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

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

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

قائمة الانتظار أم مزود ثانٍ؟

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

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

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

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

يمكن تلخيص قرار الاستجابة بهذا الترتيب:

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

المسار البشري يحفظ الوظيفة الحرجة

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

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

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

ما بقي بعد استعادة التشغيل

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

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

اقرأ أيضًا:

مشاركة:

اشترك في نشرتنا الإخبارية

احصل على أحدث أخبار الويب 3 والذكاء الاصطناعي والعملات المشفرة مباشرة في بريدك.

0