في 20 أكتوبر 2026، انقطع التيار الكهربائي في إحدى مناطق التوافر بمركز بيانات Google Cloud في لندن لنحو 8 ساعات. وقبل ذلك بخمسة أيام، تعطلت DeepSeek معظم فترة الصباح. ويتساءل كثير من المطورين: هل سيتوقف تطبيق الذكاء الاصطناعي الخاص بهم في المرة المقبلة؟
قد يتعطل مزوّد الخدمة في أي وقت. لست مضطرًا إلى نقل خوادمك لمجرد أنك تستدعي واجهة API للنموذج، لكن لا ينبغي أن تعتمد أعمالك على نموذج واحد فقط.
الفائدة الأساسية: بعد قراءة هذا المقال، ستعرف الحالات التي تتطلب منك اتخاذ إجراء وتلك التي لا تتطلبه، وستعرف كيف تجهّز خطة بديلة للنموذج.
ما الذي تعطّل في كل واحدة من حادثتي هذا الأسبوع؟
لنبدأ بـ Google Cloud. في 20 أكتوبر 2026، من الساعة 14:08 إلى 22:00 بتوقيت بكين، انقطع التيار عن منطقة التوافر europe-west2-b في لندن بسبب مشكلة في إمدادات الطاقة. استمر الانقطاع 7 ساعات و52 دقيقة. تأثرت الحوسبة والتخزين وقواعد البيانات والشبكات الموجودة في منطقة التوافر هذه؛ أما من يكتفون باستدعاء واجهات API للنماذج عن بُعد، فلم يكونوا ضمن نطاق التأثير المباشر. لكن إذا كانت خدمتك تعمل في هذه المنطقة تحديدًا، فستظل المهام الخلفية واتصالات قواعد البيانات والواجهات الخارجية متوقفة طوال ذلك الوقت، ولا يمكن لأحد إنجاز العمل عنها مسبقًا.
أما DeepSeek، فابتداءً من الساعة 08:11 بتوقيت بكين في 15 أكتوبر 2026، شهد الموقع الإلكتروني والمحادثات وواجهات API الخاصة بـ V4 Pro وV4.1 Flash انقطاعات جزئية. سجّلت صفحة الحالة الرسمية أن الانقطاع استمر 4 ساعات و52 دقيقة، وعادت الخدمة إلى طبيعتها في ذلك اليوم عند الساعة 13:04. وصفت Caixin وSouth China Morning Post المدة بأنها «نحو خمس ساعات»، لكن المدة المعتمدة هي الواردة في السجل الرسمي. وأعادت DeepSeek لاحقًا قيمة الاستهلاك بين 8 و14 أكتوبر إلى المستخدمين على شكل رصيد. لم تعلن الشركة رسميًا عن السبب، لذا لن نخمنه. بالنسبة إلى المستخدم، لم يكن السؤال في ذلك الصباح هو سبب الانقطاع، بل ما إذا كان لديه مسار بديل.
الصورة: إشعار من DeepSeek إلى المستخدمين باستعادة الخدمة وتعويضهم. تعذّر استخدام خدمة API بشكل طبيعي من الساعة 8:11 إلى 13:04 بتوقيت بكين يوم 15 أكتوبر. وسيُعاد كامل المبلغ المستهلك في الفترة من 8 إلى 14 أكتوبر إلى الحساب على شكل رصيد مجاني، ويُضاف تلقائيًا. وتُخصم رسوم API أولًا من رصيد المكافآت.
ما يوجع في الحادثتين واحد: النموذج جزء من سير العمل اليومي، وإذا انقطعت واجهته توقفت كتابة الشيفرة والبحث عن المعلومات ومعالجة الدفعات. وبحلول عودة الخدمة لدى مزودها، يكون نصف اليوم قد مضى. الرصيد التعويضي يغطي الفاتورة، لكنه لا يعيد العمل المتوقف. فإذا كان لدى فريق ما في ذلك اليوم مجموعة ترجمات يجب تسليمها، أو جولة تقييم يجب تشغيلها، أو موعد إطلاق وشيك، فلن تُنجز هذه المهام من تلقاء نفسها بسبب التعويض؛ بل ستتأجل، وتزاحم معها جدول اليوم التالي.
| البند | المعلومات المؤكدة عن حادثة Google Cloud |
|---|---|
| رقم الحادثة | Xs2XTHzAVC9YnafnPyzj |
| نطاق التأثير | منطقة التوافر europe-west2-b ضمن منطقة europe-west2 |
| السبب | مشكلة في إمدادات الطاقة، ولم تنشر الشركة تفاصيل إضافية |
| وقت البدء | 2026-10-20، الساعة 14:08 بتوقيت بكين |
| وقت الانتهاء | 2026-10-20، الساعة 22:00 بتوقيت بكين؛ واستمر الانقطاع 7 ساعات و52 دقيقة |
| الخدمات غير المتأثرة | Looker Studio |
ما الفرق بين منطقة التوافر والمنطقة؟
عندما يسمع كثيرون عبارة «انقطاع الكهرباء في لندن»، يكون أول ما يتبادر إلى أذهانهم أن Google Cloud في لندن كلها تعطلت. لكن هذا ليس ما حدث. يمكن اعتبار المنطقة (europe-west2) مجموعة كبيرة من مراكز بيانات Google في لندن، أما مناطق التوافر (europe-west2-a وeurope-west2-b وeurope-west2-c) فهي مبانٍ منفصلة داخل هذه المجموعة، صُممت بحيث يكون لكل منها مصدر طاقة واتصال شبكي مستقلان، كي تواصل المباني الأخرى العمل إذا تعطلت إحداها. في هذه الحادثة، انقطعت الخدمة عن مبنى واحد من أصل ثلاثة، فيما ظل المبنيان الآخران متصلين كالمعتاد.
لذلك تضررت فعلًا الفرق التي وضعت خدماتها في المنطقة b وحدها. أما الخدمات الموزعة مسبقًا بين المنطقتين a وc، فيمكنها تحويل حركة المرور إلى المباني التي لا تزال تعمل، فتكون آثار الانقطاع أقل بكثير. ومن يكتفون باستدعاء واجهات API للنماذج عن بُعد لم يشعروا بهذا الانقطاع تقريبًا.
مقارنة الحادثتين
| بند المقارنة | Google Cloud في لندن | DeepSeek |
|---|---|---|
| الوقت (بتوقيت بكين) | من 2026-10-20، الساعة 14:08 إلى 22:00 | من 2026-10-15، الساعة 08:11 إلى 13:04 |
| مدة الانقطاع | 7 ساعات و52 دقيقة | 4 ساعات و52 دقيقة |
| ما الذي تعطّل؟ | الحوسبة والتخزين وقواعد البيانات والشبكات في europe-west2-b | الموقع الإلكتروني والمحادثات وواجهات API الخاصة بـ V4 Pro وV4.1 Flash |
| السبب | مشكلة في إمدادات الطاقة، من دون تفاصيل إضافية | لم تعلن الشركة رسميًا عن السبب |
| الإجراء بعد الحادثة | أوصت الشركة بالانتقال إلى منطقة توافر أو منطقة أخرى إذا أمكن | تحويل استهلاك الفترة بين 8 و14 أكتوبر إلى رصيد |
| من يكتفون باستدعاء واجهات API للنماذج | لم يكونوا ضمن نطاق التأثير المباشر | كانوا في صلب المشكلة؛ ومن دون بديل، لا خيار أمامهم سوى الانتظار |
توضح المقارنة الفرق بين الحادثتين: في حادثة Google، تضرر من وضعوا أجهزتهم في المنطقة b، والحل هو التوزيع على مناطق توافر متعددة. أما في حادثة DeepSeek، فتضرر من يعتمدون على مزود نموذج واحد، والحل هو تجهيز نموذج بديل مسبقًا. الأولى مشكلة في مركز البيانات، والثانية مشكلة في استدعاء النماذج؛ وما يلي يتناول النوع الثاني.
الدروس المستفادة من هذا الانقطاع
قد يتعطل مزود واحد، لذا جهّز مسبقًا مسارًا ثانيًا وثالثًا، ويفضل ألا تكون كلها لدى الشركة نفسها. لا يُعد الانتقال إلى فئة أرخص لدى الشركة نفسها مسارًا بديلًا حقيقيًا؛ فإذا تعطلت الشركة بأكملها، تعطلت الفئتان معًا.
ومن المهم أيضًا معرفة متى تنتقل إلى نموذج آخر: لا تفعل ذلك إلا عند ظهور أخطاء 429 أو 500 أو 502 أو 503 أو 504، أو عند انتهاء مهلة الانتظار. فهذه الأخطاء تعني أن الطرف الآخر قد لا يستطيع تلبية الطلب مؤقتًا، وقد ينجح الطلب عند استخدام نموذج آخر. أما أخطاء 401 و403 ورفض المحتوى لأسباب تتعلق بالسلامة، فلا تنتقل عندها إلى نموذج آخر؛ فالمشكلة في مفتاح API أو في المحتوى نفسه، ولن يؤدي تغيير عشرة نماذج إلى حلها. وانتبه أيضًا إلى أن تغيير النموذج لن ينقذ قاعدة بياناتك أو تخزينك إذا كانا يعملان في منطقة توافر متوقفة؛ ففي هذه الحالة، عليك تقييم التوزيع على مناطق توافر متعددة. فالاستعداد لتعطل النموذج والتعافي من أعطال مركز البيانات أمران مختلفان، فلا تخلط بينهما.
وبعد إعداد مسارات الاستعادة، لا تزلها بانتهاء العطل. فهي لا ترسل طلبات إضافية في الأوقات العادية، ولا تُستخدم ما دام النموذج الأساسي ينجح في تلبية الطلبات. لكنها ستعمل تلقائيًا عند وقوع العطل التالي، من دون الحاجة إلى النهوض في منتصف الليل لتعديل الشيفرة. قبل البدء، أرسل طلبًا بسيطًا إلى كل نموذج على حدة للتأكد من صحة الاسم ومن أن النموذج يعيد استجابة سليمة، ثم فكّر في كيفية ربطها معًا. وقد تختلف أساليب الإجابة من نموذج إلى آخر. وإذا كان تنسيق المخرجات مهمًا لتطبيقك، فاكتب المتطلبات بوضوح في موجه system لتقليل الفارق عند الانتقال إلى نموذج آخر.
كيف تضبط إعدادات مسار الاستعادة؟
لا يكفي أن تعرف أن عليك «الانتقال إلى نموذج آخر عند الفشل»؛ فالانتقال بسرعة زائدة أو ببطء شديد قد يسبب مشكلات. فيما يلي أكثر الإعدادات التي يكثر السؤال عنها. لا توجد إجابة واحدة تناسب الجميع، لذا اضبطها وفقًا لطبيعة عملك.
| الإعداد | التوصية | السبب |
|---|---|---|
| عدد مرات إعادة المحاولة للنموذج نفسه | مرة واحدة كحد أقصى، ثم الانتقال إلى النموذج التالي عند الفشل مجددًا | عندما يواجه المزود مشكلة، غالبًا ما تعني إعادة الطلب إلى النموذج نفسه مجرد انتظار دور إضافي |
| مدة انتظار الطلب الواحد | أقصر للمحادثات، وأطول لتوليد النصوص الطويلة | إذا طال الانتظار أكثر من اللازم، فقد يغلق المستخدم الصفحة قبل أن ينتقل الطلب إلى نموذج آخر |
| ماذا تفعل عند ظهور الخطأ 429؟ | انتظر ثانية أو ثانيتين، ثم انتقل إلى نموذج آخر | قد يكون تحديد المعدل ناجمًا عن ضغط مؤقت، ويزول بعد قليل |
| الحد الأقصى لانتظار المسار بأكمله | اجعل مجموع مدد انتظار النماذج الثلاثة ضمن الحد الذي يقبله المستخدم | لمنع بقاء الطلب معلقًا إذا كانت النماذج الثلاثة بطيئة |
| ما السجلات التي ينبغي الاحتفاظ بها؟ | سجّل النموذج الذي نجح أو فشل في كل مرة، ورمز الخطأ | لتعرف لاحقًا أي مزود واجه مشكلة، وما إذا كان ترتيب النماذج بحاجة إلى تعديل |
| متى ينبغي تنبيه الفريق؟ | عندما ترتفع فجأة نسبة استخدام النماذج الاحتياطية | قد يعمل المسار الاحتياطي من دون أن يلاحظ المستخدم، وربما لا يلاحظ الفريق أيضًا؛ لذا يجب أن يعرف أحدهم أن النموذج الأساسي يواجه مشكلة |
غالبًا ما يُغفل البند الأخير. فكلما كان مسار الاستعادة أفضل، قلّ ما يلاحظه المستخدم عند تعطل النموذج الأساسي. وإذا لم يراجع أحد السجلات، فقد يظل النموذج الأساسي متوقفًا يومًا كاملًا بينما يظن الجميع أن كل شيء يسير على ما يرام، في حين تتراكم في الفاتورة استدعاءات إضافية للنماذج الاحتياطية.
لا حاجة إلى تغيير مفتاح API عند تبديل النموذج
أصعب ما في إعداد البدائل هو أن يكون التغيير ثقيلًا. فإذا احتاج كل نموذج إلى حساب منفصل وعنوان مختلف وتنسيق طلبات جديد، فغالبًا ما تؤجل الفرق الأمر إلى أن تقع المشكلة التالية.
تعتمد APIYI على عنوان واحد: https://api.apiyi.com/v1/chat/completions، ومفتاح API واحد، ولا يتطلب الأمر سوى تغيير model في نص الطلب. استخدم claude-opus-5-5 نموذجًا رئيسيًا، ثم انتقل عند فشله إلى claude-sonnet-5-5، وإذا فشل أيضًا فانتقل إلى gemini-4-argon. النموذجان الأولان من المورّد نفسه، أما الثالث فمن مورّد آخر، ما يتيح لك مسارًا بديلًا إذا تعطّل أحد المورّدين بالكامل. والتعديل المطلوب بسيط جدًا: إضافة قائمة بأسماء النماذج تُجرَّب بالترتيب في شيفرة التطبيق. لن تحتاج إلى تغيير تنسيق الطلب أو طريقة المصادقة أو بنية الاستجابة، كما أن اختبار ذلك سهل.
| الترتيب | اسم النموذج | سعر الإدخال | سعر الإخراج | الدور |
|---|---|---|---|---|
| 1 | claude-opus-5-5 | 4 | 20 | النموذج الرئيسي |
| 2 | claude-sonnet-5-5 | 2 | 10 | البديل الأول، خيار أرخص من المورّد نفسه |
| 3 | gemini-4-argon | 2 | 10 | البديل الثاني، من مورّد آخر |
| قابل للاستبدال | gpt-6-astra | 10 | 50 | بديل أغلى، لا يعمل إلا عبر واجهة OpenAI |
| قابل للاستبدال | deepseek-v4.1-flash | 0.30 | 1.20 | بديل منخفض التكلفة |
الأسعار في الجدول بالدولار لكل مليون رمز، وهي مرتبة وفق صفحة الأسعار بتاريخ 2026-10-21 وبمعامل 1. قد تتغير الأسعار؛ لذا يُرجى الرجوع إلى صفحة الأسعار على api.apiyi.com.
ثلاثة خطوات لإعداد مسار احتياطي
الخطوة الأولى: احصل على مفتاح API. سجّل في api.apiyi.com وأنشئ مفتاح API. تُحتسب التكلفة حسب الاستخدام، ويمكن الاتصال من داخل الصين مباشرةً من دون ربط بطاقة ائتمان أجنبية. يتيح لك مفتاح API هذا استدعاء جميع النماذج الواردة في الجدول.
الخطوة الثانية: اختبر كل نموذج على حدة. أدخل عنوان الواجهة https://api.apiyi.com/v1. فهي متوافقة مع تنسيق واجهة OpenAI، لذا يمكنك استخدام الشيفرة المكتوبة أصلًا بمكتبة OpenAI الرسمية بعد تغيير العنوان ومفتاح API فقط. استخدم الموجه نفسه لاختبار claude-opus-5-5 وclaude-sonnet-5-5 وgemini-4-argon، وتأكد من أن جميعها تستجيب بشكل صحيح وبالتنسيق المتوقع.
الخطوة الثالثة: رتّب النماذج ثم أجرِ اختبارًا تجريبيًا. أضف أسماء النماذج الثلاثة إلى الإعدادات بالترتيب، وحدّد متى تنتقل إلى النموذج التالي وفق القواعد الواردة في القسم السابق. بعد إعدادها، لا تتعجل في إطلاقها؛ قلّل مؤقتًا مهلة انتظار النموذج الرئيسي عمدًا كي يتجاوزها، ثم تحقق مما إذا كان الطلب قد انتقل إلى البديل الأول، وما إذا كان ذلك قد سُجّل في السجلات. لا يُعد المسار الاحتياطي جاهزًا فعلًا إلا بعد اجتياز الاختبار. يمكنك الاطلاع على وثائق الإعداد في docs.apiyi.com لمعرفة تفاصيل المعلمات.
ترتيب النماذج بحسب نوع العمل
الترتيب المقترح في هذا المقال يعطي الأولوية للجودة، لكنه ليس الخيار الوحيد. فبحسب طبيعة العمل، يمكنك اختيار نموذج مختلف في بداية القائمة.
| نوع العمل | الترتيب المقترح | السبب |
|---|---|---|
| كتابة الشيفرة والاستدلال المعقد | claude-opus-5-5 → claude-sonnet-5-5 → gemini-4-argon | الأولوية للجودة، وهو الترتيب الافتراضي في هذا المقال |
| خدمة العملاء والمحادثات اليومية | claude-sonnet-5-5 → gemini-4-argon → deepseek-v4.1-flash | حجم الاستدعاءات كبير والسعر مهم، لذا لا حاجة إلى البدء بأغلى نموذج |
| الترجمة والتلخيص على نطاق واسع | deepseek-v4.1-flash → gemini-4-argon → claude-sonnet-5-5 | لكثرة الطلبات، ابدأ بالخيار الأرخص وانتقل إلى الأعلى عند الفشل |
| المخرجات التي تتطلب تنسيقًا دقيقًا | ابدأ بنموذجين من المورّد نفسه، ثم أضف نموذجًا من مورّد آخر في النهاية | غالبًا ما تكون أساليب نماذج المورّد نفسه أكثر تقاربًا، فتكون الفروقات أقل عند التبديل |
هناك قاعدتان أساسيتان لترتيب النماذج: حاول أن يكون المورّد في الخيار الأخير مختلفًا عن المورّدين السابقين، واجعل السعر متناسبًا مع قيمة المهمة. ويوضح مثال الترجمة على نطاق واسع قيمة المسار الاحتياطي جيدًا: فلو تعطّل نموذج DeepSeek الذي يتصدر القائمة في 15 أكتوبر، لانتقلت الطلبات تلقائيًا إلى النموذجين التاليين من المورّدين الآخرين، ولأُنجزت المهمة كالمعتاد.
من المهم التوضيح أن تبديل النموذج يضمن استمرار «خطوة استدعاء النموذج»، لكنه لا يعالج انقطاع الكهرباء عن مركز البيانات.
قد يتعطل المورّد، فجهّز مسارًا بديلًا مسبقًا
من الأمثلة المنشورة انقطاع DeepSeek الرسمي في 2026-10-15؛ إذ حوّلت APIYI الحركة إلى قناة النسخة كاملة الأداء لدى Volcano Engine، من دون الحاجة إلى تغيير اسم النموذج، فعادت بيئة الإنتاج إلى العمل بشكل طبيعي. المصدر: التحديثات المباشرة على docs.apiyi.com.
قد يتعطل المورّد، وهذا لا يعني بالضرورة أن أحدًا ارتكب خطأ. تجهيز مسار بديل مسبقًا أنفع من الانتظار لساعات. ولا يتطلب ذلك عادةً تكلفة تُذكر أو وقتًا كبيرًا من الفريق؛ كل ما في الأمر هو إتمام الإعداد قبل وقوع المشكلة. أما بعد وقوعها، فستضطر إلى إجراء التعديلات وأنت تحت الضغط.
عند وقوع المشكلة، ما أول الأماكن التي ينبغي تفقدها؟
إذا بدأت الطلبات بالفشل على نطاق واسع، فلا تتسرع في تعديل الشيفرة. خصص دقيقتين لتفقد ثلاثة أماكن: أولًا، Google Cloud Service Health لمعرفة ما إذا كانت المشكلة على مستوى مركز البيانات؛ ثانيًا، صفحة الحالة الرسمية للمورّد المعني، مثل صفحة حالة DeepSeek في هذه الحالة؛ وثالثًا، قسم التحديثات المباشرة على docs.apiyi.com، حيث تنشر APIYI تفاصيل أي تغييرات في مسارات المورّدين.
إذا كانت الأماكن الثلاثة تشير إلى أن الخدمات تعمل بشكل طبيعي، فارجع إلى إعداداتك: هل انتهت صلاحية مفتاح API؟ هل الرصيد كافٍ؟ هل توجد مشكلة في اتصال الشبكة أو نظام أسماء النطاقات DNS؟ إن عكست ترتيب الفحص، فقد تقضي وقتًا طويلًا في البحث داخل شيفرتك، لتكتشف في النهاية أن المشكلة من المورّد.
أربع خطوات يمكنك إنجازها اليوم
- أعدّ قائمة بكل مواضع استدعاء النماذج في تطبيقك، وحدّد المواضع التي تعتمد على مورّد واحد فقط.
- أضف نموذجًا احتياطيًا واحدًا على الأقل من مورّد آخر لكل موضع يعتمد على مورّد واحد.
- طبّق قواعد الانتقال الواردة أعلاه: انتقل إلى النموذج التالي عند ظهور 429 أو 5xx أو انتهاء المهلة فقط، وسجّل كل انتقال في السجلات.
- تعمّد جعل النموذج الرئيسي يتجاوز المهلة مرة واحدة، وتحقق من انتقال الطلب فعلًا إلى النموذج الاحتياطي.
بعد إنجاز هذه الخطوات الأربع، لن يتسبب انقطاع الكهرباء عن مركز البيانات أو تعطل خدمة المورّد في توقف تطبيقك لنصف يوم؛ بل قد يتأخر لبضع ثوانٍ على الأكثر.
الأسئلة الشائعة
س1: بعد انقطاع الكهرباء عن Google Cloud في لندن، هل ينبغي الانتقال فورًا من لندن؟
ليس بالضرورة. فالتوصية الرسمية تقول «إذا كان ذلك ممكنًا»، ولا تطلب من الجميع الانتقال فورًا. يمكن للفرق التي تشغّل أعباء العمل في `europe-west2-b` تقييم الانتقال إلى منطقة توافر أو منطقة جغرافية أخرى. أما الفرق التي لا تفعل سوى استدعاء واجهات النماذج، فلا تحتاج إلى الانتقال؛ يكفيها إعداد ترتيب احتياطي للنماذج.
س2: هل سيؤدي تبديل النموذج إلى زيادة التكلفة؟
بل إن الترتيب أعلاه يجعل التكلفة أقل. سعر الإدخال للنموذج الرئيسي `claude-opus-5-5` هو 4، وسعر الإخراج 20، بينما يبلغ سعر الإدخال للنموذجين الاحتياطيين 2 وسعر الإخراج 10. لن ترتفع التكلفة إلا إذا أضفت إلى قائمة البدائل نموذجًا مثل `gpt-6-astra`، الذي يبلغ سعر إدخاله 10 وسعر إخراجه 50.
س3: هل يمكن لمفتاح API واحد استدعاء نماذج هذه الشركات كلها؟
نعم. تعمل هذه النماذج عبر العنوان نفسه المتوافق مع OpenAI، وباستخدام مفتاح API واحد؛ وكل ما عليك تغييره هو `model`. لكن انتبه إلى أن `gpt-6-astra` لا يعمل إلا عبر واجهة OpenAI.
س4: هل ستتراجع جودة الإجابات عند الانتقال إلى نموذج احتياطي؟
قد تختلف الإجابات، ولا سيما عند الانتقال من أقوى نموذج إلى خيار أرخص. لكن في معظم التطبيقات، تكون إجابة أبطأ قليلًا وأقل جودة بدرجة بسيطة أفضل من ظهور رسالة خطأ مباشرة. وإذا كان التنسيق مهمًا، فحدّد صيغة المخرجات بوضوح في موجه النظام، واستخدم طريقة الخطوة الثانية لمقارنة مخرجات عدة نماذج مسبقًا. بهذه الطريقة، ستكون لديك صورة واضحة قبل الإطلاق.
س5: هل يكلّفني الاحتفاظ بنموذج احتياطي مالًا عندما لا تقع مشكلة؟
لا. فالفوترة حسب الاستخدام تعني أنك تدفع مقابل الطلبات التي تُرسل فعلًا. إذا نجح النموذج الرئيسي من المحاولة الأولى، فلن يُستدعَ النموذج الاحتياطي ولن تُفرض عليك رسوم عنه. التكلفة الفعلية تقتصر على الوقت اللازم للإعداد، وبعض الطلبات التجريبية أثناء الاختبار.
النقاط الأساسية
- حالتا انقطاع: استمر انقطاع الكهرباء عن
Google Cloud europe-west2-bلمدة 7 ساعات و52 دقيقة؛ وسجّلت DeepSeek رسميًا انقطاعًا استمر 4 ساعات و52 دقيقة. - حدود الوقائع: لم تتعطل أوروبا كلها، ولم يتوقف النموذج نفسه نتيجة لذلك. ولم تُعلن DeepSeek رسميًا عن سبب الانقطاع.
- متى تنتقل إلى نموذج آخر؟ عند ظهور 429 أو 500 أو 502 أو 503 أو 504 أو انتهاء المهلة فقط. لا تنتقل عند ظهور 401 أو 403 أو رفض بسبب سياسات أمان المحتوى.
- طريقة الإعداد: يُفضّل أن يكون النموذج الاحتياطي من مورّد آخر. استخدم العنوان نفسه ومفتاح API نفسه، وغيّر
modelفقط. - التحقق: بعد الإعداد، تعمّد جعل النموذج الرئيسي يتجاوز المهلة مرة واحدة، وتأكد من انتقال الطلب إلى النموذج الاحتياطي ومن تسجيل ذلك في السجلات.
قد تساعد التعويضات في تسديد الفواتير، لكنها لا تعوّض العمل الذي توقف. رتّب النماذج مسبقًا، وعندما يتعطل المورّد في المرة المقبلة، لن يشعر المستخدمون إلا بتأخير لبضع ثوانٍ على الأكثر.
المراجع
- Google Cloud Service Health: حوادث متعددة في
europe-west2(Xs2XTHzAVC9YnafnPyzj)، 2026-10-20 - Google Cloud Service Health: حادثة منفصلة لمنتجات Google SecOps الأمنية في
europe-west2، 2026-10-20 - BBC: تقرير عن تأثر بنوك وخدمات عامة في المملكة المتحدة بعطل Google Cloud، 2026-10-20
- صفحة الحالة الرسمية لـ DeepSeek: سجل انقطاع الخدمة بتاريخ 2026-10-15
- الوثائق الرسمية: التحديثات المباشرة على docs.apiyi.com
الكاتب: فريق APIYI التقني
النقاش التقني: إذا واجهت مشكلة أثناء إعداد مسار احتياطي للنماذج، فنرحب بمشاركتها في التعليقات.
