بنية الموثوقية

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

لماذا تُعدّ الموثوقية صعبة إلى هذا الحد؟

يواجه المطورون الذين يتصلون مباشرةً بالـ API الرسمي أمورًا مثل:

• تقييد إقليمي للمعدل / عدم التوفّر
• حظر قناة دفع واحدة أو حساب واحد
• مشكلات توافق أثناء تبديل إصدارات النماذج
• الاصطفاف في ساعات الذروة وارتفاعات في كمون أول رمز (token)

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

بنية التوجيه متعدد المصادر لدينا

لكل استدعاء API، تُعالَج الطلبات عبر المسار التالي:

الآليات الأساسية:

• مجمّع متعدد المصادر المُنبع: تجلس عدة قنوات مستقلة خلف النموذج نفسه، ما يتجنّب أعطال النقطة الواحدة
• فحص السلامة: نراقب باستمرار معدل نجاح كل مصدر مُنبع، وكمون أول رمز (token)، ومعدل تقييد المعدل، ويتم تلقائيًا تقليل وزن القنوات غير السليمة أو إزالتها
• التبديل التلقائي عند الفشل: عندما تُعيد القناة الرئيسية 5xx / تقييد معدل / انتهاء مهلة، يتحوّل الطلب إلى قناة احتياطية في غضون أجزاء من الثانية، عادةً دون أي تأثير من جانبك
• إعادة اتصال التدفّق عند الانقطاع: عندما ينقطع استجابة تدفّق في منتصفها، نحاول استئنافها على البروتوكولات التي تدعم ذلك

مستوى الخدمة (SLA)

تعهداتنا الخارجية مبنية على "ما يمكننا تقديمه فعليًا" — لا نطلق وعودًا فارغة.

طبقة Economy مخصّصة للمطورين الأفراد الذين يريدون أفضل قيمة ويمكنهم تحمّل تذبذبات عرضية؛ إذا كان لعملك متطلبات موثوقية صارمة، فاختَر طبقة Enterprise أو اتصل بفريق المبيعات للحصول على خطة مخصّصة.

كيف يُقاس التوفّر:

• نحسب فقط معدل نجاح الطلبات "من جانب LMU AI"، باستثناء مشكلات الشبكة من جانب المستخدم، وأخطاء المعاملات، ورفض المحتوى من نموذج المصدر المُنبع نفسه
• عطل واحد يستمر أقل من 60 ثانية لا يُحتسب
• يتضمّن التقرير الشهري معدلات النجاح وكمون P95 مُقسّمة حسب النموذج وحسب الفترة الزمنية

ماذا يحدث أثناء الحادث

تذبذب قصير (< 5 دقائق)

• تبدّل طبقة التوجيه المصادر المُنبع تلقائيًا، دون إعلان
• تُسجّل صفحة الحالة الحدث

انقطاع مصدر مُنبع واحد (< ساعة واحدة)

• تُكمل طبقة التوجيه التبديل؛ وإذا كان مرئيًا لبعض المستخدمين/النماذج، فإننا ننشره على صفحة الحالة
• يُخطَر مستخدمو Standard وEnterprise عبر البريد الإلكتروني

تأثير إقليمي أو تأثير متزامن على عدة مصادر مُنبع

• يُثبَّت الحدث على صفحة الحالة مع تحديثات دورية
• يحصل مستخدمو Enterprise على تحديثات تقدّم عبر البريد الإلكتروني في الوقت الفعلي
• يُنشر تقرير ما بعد الحادث في غضون 48 ساعة بعد انتهاء الحدث

ما لا نفعله

لتجنّب تضليل المستخدمين، نحن حاليًا لا نَعِد بما يلي:

• تبديل سلس بلا كمون: يُدخِل التبديل عند الفشل كمونًا إضافيًا يتراوح من أجزاء من الثانية إلى ثوانٍ، لذا لن يكون سلسًا تمامًا أبدًا
• تعويض توافق عبر النماذج: إذا تم سحب نموذج مصدر مُنبع نفسه من الخدمة (على سبيل المثال، إيقاف مزوّد لإصدار نموذج)، فإننا نعلن عن ذلك بدلًا من التبديل بصمت إلى نموذج مختلف
• إعادات محاولة غير محدودة: تُعاد محاولة الطلبات الفاشلة عددًا محدودًا من المرات وفق السياسة، حتى لا تدفع مقابل استدعاءات مكررة غير متوقعة

الأسئلة الشائعة

آخر تحديث: 2026-09-10