تصميم Browser Automation قابل للاستعادة بعد الفشل

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

قسّم المهمة إلى خطوات لها أثر معروف

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

صمم Idempotency قبل Retry

إضافة Retry بدون Idempotency قد تنفذ نفس الأثر مرتين. استخدم Idempotency key عندما توفره ال ـAPI، أو تحقق من وجود النتيجة قبل إعادة النقر. مثال: إذا فشلت الاستجابة بعد الضغط على زر إرسال، لا تضغطه مرة ثانية مباشرة؛ ابحث أولًا هل العنصر ظهر أو هل الخادم سجل العملية.

Checkpoint يجب أن يكون صغيرًا وقابلًا للتحقق

Checkpoint جيد لا يحتاج حفظ DOM كامل أو Screenshot فقط. احفظ Task ID، Step ID، URL المتوقع، هوية البروفايل، وأي مخرجات لازمة للخطوة التالية. عند الاستعادة، لا تثق في الحالة القديمة وحدها؛ تحقق من الصفحة الحالية ومن أن البروفايل نفسه يعمل قبل المتابعة.

اختبر الفشل عمدًا

لا تنتظر الإنتاج ليختبر الاستعادة. أثناء التطوير، أغلق التبويب في منتصف المهمة، أوقف الشبكة، اجعل Selector غير موجود، واقتل Worker. راقب هل المهمة تنتقل إلى Retry أو Failed أو Manual Review بصورة مفهومة. إذا كانت الاستعادة تعتمد على شخص يعرف ما حدث من ذاكرته، فالنظام لم يكتمل بعد.

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

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

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

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

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

عند الفشل، لا تبدأ من أول Workflow تلقائيًا. تحقق من آخر checkpoint والأثر الخارجي، ثم اختر retry أو resume أو manual review وفق حالة مؤكدة. عند التحقيق استخدم هذه القائمة كحد أدنى: Task ID ثابت.؛ Profile ID محفوظ.؛ Step ID معروف.؛ URL أو سياق الصفحة قابل للتحقق.. سجل ما الذي جربته وما الذي لم يتغير بعد التجربة. هذه المعلومة تمنع الفريق من إعادة نفس المحاولات وتساعد على تحديد ما إذا كان الخطأ في الإعداد أو الأداة أو الشبكة أو بيانات المهمة.

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

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