تشخيص جاهزية Cloud Run وإخفاقات الطلبات

افهم الأسباب المحتملة

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

1. حدّد المراجعة الدقيقة ومرحلة الفشل

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

2. راجع عقد تشغيل الحاوية

بالنسبة إلى خدمة تستقبل الطلبات، تحقّق من PORT المضبوط، والاستماع على 0.0.0.0، ومتطلبات الصورة وبيئة التشغيل المدعومة، واعتماديات بدء التشغيل، وسلوك الذاكرة. للمهام (Jobs) عقد اكتمال مختلف؛ فلا تشخّصها كما لو كانت مستمعاً لخدمة. قد يجتاز الربط بواجهة محلية فقط اختبارات المطور، ثم يفشل عند الوصول عبر مسار المنصة. أبقِ مقتطفات الإعداد الفعلية غير قابلة للتشغيل إلى أن تُكيّف ويُصرَّح باستخدامها.

3. افحص ميزانية اصطناعية لاتصالات الخدمة التابعة

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

import json

model = json.loads('{"instances":12,"pool":8,"reserve":10,"limit":100}')
demand = model["instances"] * model["pool"] + model["reserve"]
print(f"modeled_demand={demand} synthetic_limit={model["limit"]} fits={demand <= model["limit"]}")

modeled_demand=106 synthetic_limit=100 fits=False

4. افصل دخول الشبكة وهوية المستدعي ووصول الخدمة التابعة

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

5. اقترح تصحيحاً محدوداً للتطبيق والتوسع

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

امنع تكرار المشكلة

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