يبدو هذا العالم أحيانًا وكأنه يُدار بالارتجال فعلًا.
حين تتابع قطاع الذكاء الاصطناعي، تشعر أننا نقف بالفعل على أعتاب المستقبل. النماذج تكتب الشيفرات وتحل المسائل الصعبة، والوكلاء يعدون بتولي مسارات عمل كاملة، والنقاش حول ما سيتبقى للبشر من وظائف يزداد صخبًا يومًا بعد يوم. ثم يأتي الوقت الذي تحتاج فيه إلى هذه التقنية لإنجاز عمل، فلا تصل الإجابة.
حتى DeepSeek، الذي يراه كثيرون من أبرز معايير التقدم في الذكاء الاصطناعي، قد يتعثر.
بحسب الإشعار الذي نشرته DeepSeek، أدى عطل في أنظمة الخدمة إلى تعذر استخدام واجهة API بصورة طبيعية يوم 15 أكتوبر 2026، من الساعة 08:11 إلى 13:04 بتوقيت بكين، UTC+8. وبحساب وقتي البداية والنهاية المذكورين، استمر العطل أربع ساعات و53 دقيقة كاملة، أي ما يقارب خمس ساعات. وصفه بأنه «تعطل لنصف يوم» تعبير عن الضيق، لكن ضياع معظم صباح العمل كان أمرًا واقعًا.[1][2]
إشعار DeepSeek باستعادة الخدمة والتعويض، قدمه أحد القراء. تتفق الأوقات وشروط التعويض الواردة فيه مع التقارير المنشورة في اليوم نفسه.
إذا كنت تستخدم الخدمة للدردشة فقط، فقد تغلق النافذة وتعود لاحقًا. لكن حين تصبح واجهة API جزءًا من منتج، أو خدمة عملاء، أو معالجة محتوى، أو إجراء داخلي في مؤسسة، فإن توقف المزود قد يترك سلسلة العمل كلها في الانتظار. المستخدم يطالبك أنت بالتسليم، والعميل يتواصل مع فريقك أنت. براعة النموذج في الإجابة حين يعمل لا تجعل الناس يقبلون تلقائيًا ساعات من الصمت.
وهذه أكثر النقاط التي يوقظنا إليها هذا العطل: قدرة النموذج وموثوقية الخدمة مسؤوليتان، وعلى كل منهما أن تثبت نفسها.
أن يجيب النموذج عن السؤال بصورة صحيحة أمر، وأن يقدم تلك الإجابة في الوقت الذي يحتاج فيه العمل إليها أمر آخر. الأول يجد مكانه بسهولة في التصنيفات وحفلات الإطلاق، أما الثاني فغالبًا لا يحظى بنقاش جاد إلا بعد وقوع خلل. ومن يعتمدون على الذكاء الاصطناعي لإنجاز أعمالهم يحتاجون إلى الأمرين معًا.
من هذه المفارقة يأتي الشعور بأن العالم قائم على ترتيبات مرتجلة. ما نراه هو ذكاء يستطيع مناقشة الكون وكتابة البرامج، لكن ما يسنده لا يزال آلات وبرمجيات وبشرًا يمكن أن يتعطلوا أو يخطئوا. مهما كانت الهالة التقنية كبيرة، فلا غنى عن العمل الملموس في المراقبة، وتوفير البدائل الاحتياطية، واستعادة الخدمة بعد الأعطال.
ومع ذلك، وبصرف النظر عن الانتقاد المستحق، فإن تعويض DeepSeek يستحق كلمة إنصاف.
ينص الإشعار على أن كل حساب سيحصل على رصيد تعويضي يعادل كامل قيمة استهلاكه الفعلي خلال الأيام السبعة السابقة، من 8 إلى 14 أكتوبر. وسيُضاف الرصيد تلقائيًا، وتُخصم منه رسوم استخدام واجهة API اللاحقة بالأولوية.[1][2]
فإذا استهلك حساب مثلًا ما قيمته 100 يوان خلال تلك الفترة، فسيحصل، وفق الشروط المعلنة، على 100 يوان من الرصيد التعويضي. لم تحصر DeepSeek التعويض في الرسوم المرتبطة بساعات التعطل القليلة، بل اتخذت استهلاك أسبوع سابق كامل أساسًا له. وهذه لفتة لها وزنها.
بالطبع، الرصيد التعويضي يختلف عن رد المال نقدًا. ولا يعني العرض أن الأيام السبعة المقبلة متاحة للاستخدام المجاني غير المحدود. المبلغ يتحدد بحسب الاستهلاك الفعلي خلال الأيام السبعة السابقة المحددة، ويُستخدم لتغطية رسوم واجهة API المستقبلية. توضيح هذه التفاصيل لا ينتقص من تقدير التعويض.
ما يوحي بتحمل المسؤولية هو الاستعداد لدفع تكلفة واضحة مقابل العطل. كما أن الإضافة التلقائية توفر على المستخدمين تقديم الإثباتات كل على حدة وتكرار طلبات التعويض. وللمطورين الذين سيواصلون استخدام الخدمة، قيمة عملية في رصيد يصل تلقائيًا ويُخصم مباشرة من فواتيرهم المقبلة.
ولا تأتي قيمة التعويض من وصف الشركة بأنها «لا ينقصها المال». ما يستحق التقدير هنا هو تحويل الاعتذار إلى رصيد يستطيع المستخدمون الاستفادة منه فعلًا.
لكن الإشادة بالتعويض لا ينبغي أن تحول التعطل إلى خبر سار.
فاتورة واجهة API ليست سوى جزء من التكلفة. هناك أيضًا مخاطر توقف الأعمال، وتأخر التسليم، وخسارة العملاء. وقد لا يغطي رصيد تعويضي خسائر كل فريق. يمكن تعويض المال، أما الوقت الضائع والثقة المتضررة فقد يحتاجان إلى وقت أطول بكثير للإصلاح. تستحق DeepSeek التقدير على استجابتها، وينبغي أن تظل مطالبة بالإجابة عن أسئلة استقرار الخدمة.
ويذكر الإشعار أيضًا أن DeepSeek ستحدد نقاط الاعتماد المنفردة وتزيلها.[1] ما الذي قد يعطل خدمة نموذج بهذه القوة؟ بدأ العطل في الساعة 08:11 بتوقيت بكين. وهذا التوقيت يوحي باحتمال يستحق التحقق: تغيير نُشر ليلًا، ولم يظهر ضعفه إلا أمام حركة الطلبات الصباحية.
لنوضح أولًا حدود ما نعرفه: لا يكشف هذا الإشعار السبب التقني الجذري للحادث. هل نُشر تحديث ليلًا فعلًا، وهل ارتفعت حركة الطلبات صباحًا بوضوح؟ كلاهما يحتاج إلى تأكيد من السجلات والمراقبة. فلنتتبع هذا الاحتمال وحده لنرى كيف يمكن أن يقع.
لنفترض أن خدمة مشتركة حُدثت أثناء الليل. وظيفتها التحقق من مفاتيح API والرصيد المتاح قبل وصول الطلبات إلى النموذج. النسخة الجديدة تعمل وتجتاز فحوصها، لكنها حولت فحصًا كان يقرأ من ذاكرة التخزين المؤقت إلى استعلام في قاعدة البيانات مع كل طلب. هذه الخدمة وهذا التغيير مثال توضيحي، وليسا تفصيلين ثبت وجودهما في البنية الداخلية لـ DeepSeek.
في الليل، تكون الطلبات قليلة، فيبدو الاستعلام الإضافي غير مؤثر. الواجهة ما زالت تجيب، والاختبارات لا تبلغ عن أخطاء، بل قد تبقى مؤشرات المراقبة خضراء. لكن جزءًا من قدرة النظام على المعالجة اختفى بهدوء.
يأتي الصباح ويبدأ الناس عملهم، فتتدفق استدعاءات المنتجات ومهام الخلفية. وفي النهاية تصل الطلبات بسرعة تفوق ما تستطيع هذه الخدمة المشتركة معالجته. تبدأ الطلبات بالانتظار للحصول على اتصالات بقاعدة البيانات، وتحتجز الطلبات المنتظرة مزيدًا من الموارد، فتضطر الطلبات اللاحقة إلى انتظار أطول.
الأمر يشبه مطعم إفطار لم يبق فيه سوى شباك محاسبة واحد. المطبخ يعمل والطهاة موجودون، لكن على الجميع المرور أولًا بالصندوق نفسه. وإذا انسد المدخل، فلن يفيد كثيرًا أن يكون خلفه مطبخ ضخم.
بعد ذلك، تبدأ المشكلة بتغذية نفسها. تنتظر التطبيقات التي تستدعي الخدمة طويلًا، ثم تنتهي مهلة الطلب فتعيد المحاولة. وبعض المنتجات تعيد المحاولة أيضًا نيابة عن مستخدميها. وإذا لم تُلغَ الطلبات السابقة في الوقت المناسب، فإن مهام جديدة تتكدس فوق مهام لم تنتهِ بعد. قد لا تكون الأعمال الجديدة الفعلية قد قفزت، لكن عدد الطلبات الذي يتحمله النظام يستمر في التضخم.
حينها، قد لا يكفي الرجوع إلى النسخة السابقة لاستعادة الخدمة فورًا. الطلبات المتراكمة ما زالت موجودة، ومجمعات الاتصالات لم تتعافَ، ومحاولات الإعادة لا تزال تطرق الباب. وما إن تلتقط الخدمة أنفاسها حتى يسقطها الضغط من جديد. قد تتطلب الاستعادة تقييد حركة الطلبات، وقطع المحاولات غير المجدية، والتخلص من المهام المنتهية الصلاحية، ثم فتح المجال تدريجيًا. إصلاح الشيفرة وإعادة النظام إلى الوقوف على قدميه قد يكونان معركتين منفصلتين.
في هذا التسلسل، يزرع التغيير المشكلة، وتكشفها حركة الطلبات، ثم يضخمها التراكم وإعادة المحاولة. قد تكون مجموعات الاستدلال الباهظة سليمة تمامًا، فيما الطلبات عالقة عند مدخل ضيق يسبقها. ونقطة الاعتماد المنفردة ليست بالضرورة خادمًا وحيدًا؛ فقد تكون اعتمادًا مشتركًا لا تستطيع أي من النسخ تجاوزه.
لهذا النوع من التضخم سابقة موثقة. يذكر تقرير Google Cloud عن حادث يونيو 2025 أن بيانات سياسة حصص الاستخدام تسببت في انهيار Service Control، ثم أدت عمليات إعادة التشغيل المتزامنة أثناء التعافي إلى تحميل قاعدة بيانات أساسية فوق طاقتها، مما أبطأ استعادة الخدمة في بعض المناطق.[3] وهذا يوضح أن إصلاح السبب الأول لا يمنع هندسيًا استمرار الاختناق. لكنه لا يثبت أن ما حدث لدى DeepSeek كان الأمر نفسه.
للتحقق من هذا السيناريو، يجب وضع عدة خطوط زمنية فوق بعضها: ما الذي تغير قبل الحادث، ومتى ارتفعت حركة الطلبات، ومتى بدأت مؤشرات التأخر والانتظار واستخدام الاتصالات في الخدمة المشتركة بالخروج عن المعتاد، وهل زادت معها محاولات الإعادة، وماذا حدث بعد التراجع عن التحديث أو تقييد الحركة. إذا تتابعت هذه الوقائع بصورة متسقة، اكتسبت الفرضية وزنًا. أما توقيت 08:11 فيكفي لطرح السؤال، ولا يكفي لإعلان حل القضية.
منع تكرار المشكلة وعد. وسجل الخدمة في الفترة التالية هو الذي سيبين إن كان هذا الوعد قد تحقق.
وتحمل هذه الواقعة تذكيرًا لكل من يربط الذكاء الاصطناعي بأعماله: حان وقت إعداد خطة بديلة.
في مسارات العمل المهمة، ينبغي أن تقرر مسبقًا هل يمكن وضع المهام في قائمة انتظار، أو التحويل إلى خدمة بديلة جرى اختبارها، أو إعادة المهمة إلى شخص يتولاها حين يتعذر استخدام النموذج مؤقتًا. وإذا كانت إعادة المحاولة ضرورية، فيجب تحديد عددها، وزيادة الفواصل بينها تدريجيًا، وتوزيع توقيتها حتى لا تصب مزيدًا من الزيت على النار. أما المسارات التي تنفذ مدفوعات أو ترسل رسائل أو تعدل بيانات، فتحتاج أيضًا إلى منع تكرار التنفيذ بعد استعادة الخدمة.
هذه الاستعدادات لا تحمل كثيرًا من بريق المستقبل، لكنها تستطيع حماية أعمال اليوم عند وقوع العطل المقبل. وكلما كان استخدامك للذكاء الاصطناعي أكثر جدية، قل ما يمكنك تعليقه من آمال على فكرة أن شركة بهذه القدرة لا بد ألا تتعطل.
تستحق DeepSeek الانتقاد على تعطل استمر قرابة خمس ساعات. فخدمة الذكاء الاصطناعي التي تحظى بكل هذه التوقعات يجب أيضًا أن تثبت موثوقيتها. وتستحق كذلك التقدير على تقديم رصيد تعويضي يعادل استهلاك الأيام السبعة السابقة. الاعتراف بالمشكلة، وتحمل كلفتها، ثم استعادة الثقة بخدمة مستقرة باستمرار، موقف يستحق التشجيع.
قد يكون العالم أكثر ارتجالًا مما نحب أن نصدق. من حقنا أن نطالبه بأخطاء أقل، ومن حقنا أيضًا، حين يقبل أحد تحمل المسؤولية، أن نقول: لقد تعامل مع الأمر بإنصاف هذه المرة.