استعادة أقفال ملفات تعريف المتصفح المعلقة
يمنع قفل ملف تعريف المتصفح عامليْن من فتح الحساب نفسه في آن واحد.
تفشل معظم أنظمة الأتمتة أثناء عملية الاستعادة. فعندما يتعطل عامل أو يفقد الاتصال بالشبكة، يرى النظام قفلاً قديماً ويقوم بحذفه. هذا يؤدي إلى تحريك الطابور، ولكنه يتسبب في إفساد حالة الحساب.
القفل المعلق ليس مجرد ملف يجب حذفه، بل هو عملية غير مكتملة تتطلب مسار استعادة محكوم.
توقف عن التعامل مع الأقفال كملفات بسيطة، وعاملها كعقود إيجار (leases).
يتطلب عقد الإيجار الآمن ما يلي:
- مالكاً
- وقت انتهاء الصلاحية
- إشارة نبض (heartbeat)
- رقم الإصدار (fencing token)
رقم الإصدار أمر حيوي؛ إذ يجب أن تتضمن كل عملية كتابة أحدث رمز (token). إذا عاد عامل قديم بعد أن تولى عامل جديد المهمة، سيرفض النظام الرمز القديم، مما يمنع حدوث فساد صامت للبيانات.
لا تنتقل مباشرة من الحالة "المقفلة" إلى "المتاحة". استخدم آلة حالة (state machine) للانتقال عبر هذه المراحل:
- محتجز (Held)
- يُشتبه في كونه معلقاً (Suspected stale)
- في الحجر الصحي (Quarantined)
- تم فحصه (Inspected)
- متاح | استئناف معلق | مراجعة يدوية (Available | Resume pending | Manual review)
مرحلة الحجر الصحي (quarantine) بالغة الأهمية، فهي تمنع عاملاً ثانياً من المساس بملف التعريف أثناء قيامك بالتحقيق.
أثناء التحقيق، يجب عليك جمع الأدلة:
- هل كانت عملية المتصفح لا تزال تعمل؟
- ما هو آخر عنوان URL معروف؟
- هل كانت المهمة في خطوة حساسة مثل إتمام الشراء أو تغيير الإعدادات؟
- هل توجد لقطة شاشة للفشل؟
إذا توقفت مهمة أثناء عملية حساسة، فلا تقم باستئنافها تلقائياً، بل أرسلها للمراجعة اليدوية. يجب أن يكون للأتمتة حدود لمنع اتخاذ قرارات خاطئة.
أخطاء شائعة يجب تجنبها:
- حذف القفل دون التحقق من سلامة ملف التعريف.
- عدم استخدام رموز السياج (fencing tokens) لرفض عمليات الكتابة المتأخرة من العمال القدامى.
- إعادة محاولة إرسال النماذج دون وجود نقطة تفتيش آمنة ومعروفة.
- تغيير البروكسيات (proxies) أثناء عملية الاستعادة.
الهدف ليس جعل عملية الاستعادة معقدة، بل جعلها صريحة وواضحة.
القفل ليس سوى عرض للمشكلة؛ يجب أن يحمي نظامك بيئة الحساب الكامنة وراء ذلك القفل.
ملف تعريف واحد. عقد إيجار لمالك واحد. مهمة نشطة واحدة. مسار أدلة واحد. قرار استعادة واحد.