تصميم Browser Workers لتشغيل الأتمتة على مدار الساعة

تشغيل Automation على مدار الساعة يحتاج فصلًا بين من يقرر المهمة ومن ينفذها. Browser Worker هو عملية أو خدمة تستقبل Task من Queue، تحجز Profile أو موردًا، تنفذ الخطوات، ترسل Heartbeat، ثم تسجل النتيجة. هذا يمنع أن يؤدي تعطل Workflow واحد إلى إسقاط النظام كله ويجعل التوسع عبر أكثر من جهاز ممكنًا.

افصل Scheduler عن Worker

Scheduler يحدد ما يجب أن يعمل ومتى، لكنه لا يحتاج فتح المتصفح بنفسه. يضع Job في Queue. Worker يسحب Job عندما تتوفر سعة. هذا الفصل يسمح بإعادة تشغيل العمال وتوزيعهم على أجهزة مختلفة بدون فقد الجدول.

احجز Profile قبل التنفيذ

لا تسمح لعاملين بتشغيل نفس Profile في وقت واحد إلا لو التصميم يدعم ذلك بوضوح. استخدم Lease له مدة وتجديد. إذا مات Worker ينتهي ال ـLease ويمكن إعادة المهمة بعد التحقق.

Heartbeat يكشف العمال العالقين

Worker يرسل إشارة دورية. إذا غابت عدة مرات لا تعتبر المهمة فاشلة فورًا؛ حدد حالة suspected ثم تحقق أو انتظر Lease. هذا يقلل تشغيل نسختين من نفس المهمة أثناء انقطاع مؤقت.

خطط للتحديث بدون إيقاف الخدمة

استخدم Drain mode: أوقف قبول Jobs جديدة على Worker، انتظر الحالية، حدث النسخة، ثم أعده لل ـPool. هذا أفضل من قتل كل العمال في نفس اللحظة.

سيناريو تطبيقي قبل الاعتماد

تخيل المهمة تعمل عشرات المرات يوميًا، ويحدث في إحدى المرات timeout بعد خطوة لها أثر خارجي. التصميم الجيد يجب أن يعرف أين توقف وما الذي تم بالفعل. في موضوع «تصميم Browser Workers لتشغيل الأتمتة على مدار الساعة»، نفّذ تجربة صغيرة قبل تعميم القرار. ابدأ ب ـ1- اسحب Job من Queue.، 2- احجز Profile وموارده.، 3- ابدأ Heartbeat.، ثم سجل النتيجة قبل توسيع النطاق. لا تحاول تحسين كل شيء في أول Run؛ المطلوب أولًا إنشاء حالة مرجعية تستطيع العودة إليها ومقارنتها. عندما تنجح التجربة، كررها مرة ثانية بنفس الشروط للتأكد أن النتيجة لم تكن صدفة أو أثر Cache أو حالة مؤقتة.

كيف تقيس نجاح التجربة؟

راقب نسبة النجاح من أول محاولة، عدد retries، زمن كل خطوة، عدد التدخلات اليدوية، وحالات التكرار أو ال ـloop. هذه المقاييس أهم من مجرد انتهاء Run واحدة بنجاح. حوّل النقاط الموجودة في المقال إلى مؤشرات قابلة للرصد: Queue تمنع اندفاع المهام دفعة واحدة.؛ Worker يمكن أن يعلن قدرته مثل OS أو RAM.؛ Scheduler يبقى خفيفًا ومستقرًا.. احتفظ بالقياسات مع timestamp ونسخة التطبيق أو البيئة، لأن مقارنة أرقام من إصدارات أو شروط مختلفة قد تعطي استنتاجًا خاطئًا. وإذا كانت النتيجة رقمية، استخدم أكثر من عينة بدل أفضل أو أسوأ قيمة منفردة.

عند الفشل: ماذا تراجع أولًا؟

عند الفشل، لا تبدأ من أول Workflow تلقائيًا. تحقق من آخر checkpoint والأثر الخارجي، ثم اختر retry أو resume أو manual review وفق حالة مؤكدة. عند التحقيق استخدم هذه القائمة كحد أدنى: Heartbeat interval معروف.؛ Timeout أكبر من jitter الطبيعي.؛ Lease له expiry.؛ Job ID ثابت.. سجل ما الذي جربته وما الذي لم يتغير بعد التجربة. هذه المعلومة تمنع الفريق من إعادة نفس المحاولات وتساعد على تحديد ما إذا كان الخطأ في الإعداد أو الأداة أو الشبكة أو بيانات المهمة.

متى تعتمد القرار على نطاق أوسع؟

قرار الاعتماد لا يجب أن يعتمد على أن التجربة «عملت مرة». في «تصميم Browser Workers لتشغيل الأتمتة على مدار الساعة» اعتبر الحل جاهزًا عندما تستطيع إعادة نفس السيناريو بنتيجة متقاربة، ويفهم شخص آخر خطوات الاختبار وحدود النتيجة، وتعرف ماذا ستفعل لو فشلت الحالة الطبيعية. لو لم تتحقق هذه الشروط، احتفظ بالحل كتجربة أو إعداد مبدئي ولا تحوله إلى Default لكل الحسابات أو المهام.