Replit Monitoring Agent: هل تسمح له بنشر الإصلاحات بنفسه؟

ما الذي يفعله Replit Monitoring Agent فعلا

تقدم Replit أداة Monitoring Agent، وهي أحدث خطوة في مراقبة Replit، بوصفها مهندس مناوبة يعمل باستقلالية للتطبيقات المنشورة على منصتها. ويعدد إعلان 22 أكتوبر أربع مهام: الاطلاع على سجلات بيئة الإنتاج ومقاييسها؛ والتحقيق في الأخطاء وحالات البطء وعمليات النشر الفاشلة؛ وإجراء إصلاح والتحقق منه؛ وإرسال رسالة بريد إلكتروني إليك تصف ما حدث وما الذي تغير. وأنت من يقرر، بتعبير الإعلان، «ما إذا كانت الإصلاحات تنشر تلقائيا».

وهي امتداد لميزة App Monitoring التي أطلقت في 29 أبريل 2026. فقد كان ذلك الإصدار يرسل إليك بريدا إلكترونيا حين يتوقف تطبيق منشور، وأضاف زر «Investigate downtime with Agent» على رسم وقت التشغيل، وهو زر يطلق مهمة في الخلفية لتحديد السبب الجذري. وقالت Replit حينها إن Agent يملك صلاحية القراءة فقط على قاعدة بيانات الإنتاج ولا يستطيع تعديلها. ولا يعيد الإعلان الجديد ذكر نطاق الوصول إلى قاعدة البيانات، لذا اعتبر ذلك غير مؤكد في Monitoring Agent إلى أن تقول Replit خلاف ذلك.

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

شرح المفاتيح الثلاثة

ينشأ معظم الالتباس في مراقبة Replit من عدم وجود مفتاح تشغيل وإيقاف واحد. وهكذا تقسمها وثائق Replit (docs.replit.com، بحسب مراجعتنا في 24 أكتوبر 2026):

وهناك تحفظان من الوثائق يستحقان التكرار. فالتنبيه ليس وعدا بإصلاح: إذا كان السبب الجذري خدمة خارجية، فقد لا يكون في شيفرتك ما يمكن تغييره. كما أن الفحوص التلقائية تغطي هذه الإشارات الثلاث فقط، لا كل مقياس يمكنك رؤيته. وتظهر التنبيهات التي لا تستطيع Replit تقييمها حاليا بعبارة «Cannot measure».

كيف تعده

يضبط كل شيء لكل تطبيق منشور على حدة من أداة Publishing:

1. في التطبيق الجديد، فعل Enable Active monitoring ضمن Suggested add-ons أثناء النشر الأول. ويفعل ذلك أيضا فحوص وقت التشغيل حيثما كانت متاحة.
2. في التطبيق المنشور بالفعل، افتح إعدادات Publishing الخاصة به وشغل Monitoring alerts. ويحفظ التغيير من دون إعادة نشر.
3. شغل Auto-fix إذا أردت أن يحقق Agent في المشكلات ويحاول إصلاحها.
4. يمكنك اختياريا تشغيل Auto-republish. ونحن نفضل إبقاءه متوقفا في الأسابيع الأولى، والأسباب مذكورة أدناه.
5. من Settings > Notifications، اختر عتبة لرسائل Active monitoring alerts: الحرجة فقط، أو العالية فما فوق، أو المتوسطة فما فوق، أو كل درجات الخطورة، أو من دون رسائل. وكتم البريد الإلكتروني لا يوقف المراقبة ولا Auto-fix.

وفي حسابات الفرق، يمكن للمشرفين أيضا تحديد مستلمين على مستوى الحساب كله (Off أو Admins أو Custom)، ولكل منهم عتبة خطورة خاصة. ويقسم جدول Monitoring alerts التنبيهات إلى Active وResolved، مع الاحتفاظ بالتنبيهات المحلولة لآخر 30 يوما. ويؤدي توسيع أي تنبيه إلى عرض سبب إطلاقه وعدد جولات المراقبة التي رصدته.

كم يكلف

لم تنشر Replit سعرا منفصلا لـMonitoring Agent، ولا يقصره الإعلان ولا الوثائق على خطة بعينها. وتكتفي الوثائق بالقول إن تشغيل Monitoring Agent «قد يترتب عليه رسوم استخدام Agent»، وتحيل إلى صفحة الاستخدام للمتابعة.

تحتسب أعمال Agent على Replit بحسب الجهد المبذول. إذ تنشأ نقطة حفظ (checkpoint) حين ينهي Agent طلبا ما، وعادة ما تكلف المهام البسيطة مثل إصلاح الأخطاء أقل من عمليات البناء الكبيرة. كما تغطي الأرصدة خدمات سحابية أخرى، منها التطبيقات المنشورة والتخزين وقواعد البيانات، وتحتسب أي خدمات ذكاء اصطناعي خارجية يستدعيها Agent بسعر API العام لدى مزودها. وهذه الأسعار المعروضة على صفحة الأسعار لدى Replit حتى 24 أكتوبر 2026:

المحرك الحقيقي للتكلفة هو مقدار الضجيج في تطبيقك. فإذا كانت واجهة API خارجية غير مستقرة تنتهي مهلتها عدة مرات في اليوم، فقد يفتح Auto-fix تحقيقا لكل تنبيه. وقبل التفعيل، انتقل إلى صفحة Billing في Settings وحدد تنبيها للاستخدام وحدا صارما للميزانية معا. ولاحظ أيضا أن بيانات الاستخدام قد تستغرق حتى 30 دقيقة لتظهر في لوحة التحكم، أي أن العداد لا يعمل في الزمن الحقيقي.

متى تفعل Auto-republish ومتى لا تفعله

تتحدث Replit هنا بصراحة غير معتادة: Auto-republish تجريبي، وبعض التغييرات، مثل عمليات الترحيل وعمليات الفهارس، قد تكون محفوفة بالمخاطر. ومن الصعب أيضا أن ننسى أن Agent الخاص بـReplit حذف في يوليو 2025 قاعدة بيانات الإنتاج لدى إحدى الشركات أثناء تجميد الشيفرة، خلافا لتعليمات المستخدم. لذا يبدو التفعيل على مراحل منطقيا:

1. الأسبوع الأول: التنبيهات فقط. تعرف على عدد مرات إطلاق تطبيقك للتنبيهات ودرجة خطورتها.
2. بعد ذلك: فعل Auto-fix مع إبقاء Auto-republish متوقفا. اقرأ كل إصلاح مقترح في Agent chat، واحتفظ بعدد تقريبي للإصلاحات التي كنت ستنشرها من دون أي تعديل.
3. ثم فقط: إذا كانت الإصلاحات سليمة باستمرار ونادرا ما يحتاج تطبيقك إلى تغييرات في المخطط (schema)، ففكر في تفعيل Auto-republish.

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

في اليوم نفسه: تصحيحات أمنية ما زالت تحتاج إلى إعادة نشر

نشرت Replit أيضا تحديثا أمنيا في 22 أكتوبر. فتطبيقات Python تحتاج إلى إعادة نشر للحصول على تحديث لأدوات التطوير مرتبط بجهة إصدار شهادات مخترقة، وتطبيقات Node.js تحتاج إلى إعادة نشر لتشغيل بيئة التشغيل المصححة، ويوصى بإعادة النشر لتطبيقات PHP. ولا يقوم Monitoring Agent بذلك نيابة عنك؛ فهو يراقب الأخطاء ولا يطبق تصحيحات بيئة التشغيل. وتقترح Replit فتح Security Center، وتصفية التطبيقات المنشورة، وتطبيق التصحيحات المتاحة، ثم إعادة النشر.

اسأل Agent من دون تفعيل أي شيء

إذا لم تكن مستعدا للإصلاحات المؤتمتة، فما زال بإمكانك الاستعلام عن بيئة الإنتاج مباشرة. وتذكر الوثائق حركة HTTP، وزمن الاستجابة لكل نقطة نهاية (المتوسط وp50 وp95 وp99)، والمعالج والذاكرة، وعدد النسخ العاملة، وزمن بدء التشغيل، والقرص والشبكة، وسجلات الأخطاء المصفاة، مع اختلاف التوافر بحسب نوع النشر ومزود الخدمة السحابية. وهذه هي الطريقة الأقل مخاطرة للاستفادة من مراقبة Replit بينما تقرر مقدار ما ستتركه لـAgent.