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