كيف توقف عملية آلية عن أداء نفس الوظيفة مرتين

يمكن أن تجعل الأتمتة عملية الأعمال أسرع وأكثر اتساقًا

يمكن أن يقوم طلب جديد بتحديث المخزون تلقائيًا

يمكن أن يؤدي الدفع الناجح إلى إنشاء إيصال تلقائيًا

يمكن أن يُخطر الطلب المكتمل الموظف المسؤول تلقائيًا

يمكن أن يبدأ سجل جديد عدة إجراءات عبر أنظمة مختلفة تلقائيًا

لكن هناك مشكلة تصبح أكثر أهمية مع نمو هذه العمليات

ماذا يحدث إذا وصل نفس الحدث إلى النظام مرتين؟

في البداية، قد يبدو أن هذه مشكلة تقنية بسيطة

لكنها ليست كذلك

يمكن أن يؤدي الحدث المكرر إلى تحميل العميل مرتين، أو تقليل المخزون مرتين، أو إرسال رسالتين، أو معالجة نفس الطلب أكثر من مرة

الجزء الصعب هو أن الأحداث المكررة يمكن أن تحدث حتى عندما يعمل كل نظام بشكل طبيعي

لذا، يجب تصميم العمليات الآلية الموثوقة مع وضع هذه الإمكانية في الاعتبار

لماذا يمكن أن يصل نفس الحدث مرتين

تخيل أن نظام الدفع يخبر نظام الشركة بأن الدفع قد اكتمل

يتلقى نظام الشركة الرسالة ويبدأ في معالجتها

لكن قبل أن يتلقى نظام الدفع تأكيدًا بأن الرسالة قد تم التعامل معها بنجاح، يتم قطع الاتصال

لا يعرف نظام الدفع ما إذا كانت الرسالة قد تمت معالجتها

يُرسل نفس الرسالة مرة أخرى

الآن، تلقى نظام الشركة نفس الحدث مرتين

من منظور المرسل، فإن إعادة إرساله أمر معقول

من منظور نظام الاستقبال، ظهرت نفس التعليمات مرتي

إذا كان النظام يعامل كل رسالة كحدث جديد تمامًا، فقد ينفذ الإجراء مرتين

لهذا السبب، فإن مجرد القول “عالج كل حدث” ليس كافيًا لعملية آلية موثوقة

يحتاج النظام أيضًا إلى تحديد ما إذا كان قد عالج هذا الحدث بالفعل

إعطاء كل حدث هوية فريدة

واحدة من أبسط الطرق لحل هذه المشكلة هي إعطاء كل حدث معرف فريد

على سبيل المثال، قد يحتوي حدث يمثل دفعة مكتملة على معرف فريد لذلك الحدث

عندما يستقبله النظام، يمكنه التحقق مما إذا كان ذلك المعرف قد تم معالجته بالفعل

إذا لم يكن كذلك، يقوم النظام بتنفيذ الإجراء المطلوب

إذا كان كذلك، فإن النظام لا يكرر الإجراء

بدلاً من ذلك، يمكنه التعامل مع الرسالة بأمان كنسخة مكررة

هذا يخلق قاعدة بسيطة:

يجب أن ينتج نفس الحدث نفس النتيجة مرة واحدة فقط

الجزء المهم هو أن النظام يحتاج إلى طريقة موثوقة للتعرف على الحدث

استخدام معلومات مثل اسم العميل أو مبلغ الدفع عادةً ليس كافيًا لأن الأحداث المختلفة يمكن أن تحتوي على نفس المعلومات

يحتاج المعرف إلى تمثيل الحدث نفسه

لماذا فحص قاعدة البيانات البسيط ليس كافيًا دائمًا

تنفيذ شائع هو

• تحقق مما إذا كان الحدث موجودًا في قاعدة البيانات

• إذا لم يكن موجودًا، نفذ الإجراء

• احفظ الحدث كمعالج

تظهر المشكلة عندما تصل نسختان من نفس الحدث تقريبًا في نفس الوقت

قد تتحقق كلا العمليتين من قاعدة البيانات قبل أن يقوم أي منهما بحفظ الحدث

كلاهما يرى أنه غير موجود

كلاهما يستمر

يتم تنفيذ الإجراء مرتين

لهذا السبب يجب تصميم حماية من التكرار كجزء من العملية الفعلية بدلاً من إضافتها كتحقق بسيط قبل ذلك

تحتاج النظام إلى وسيلة لجعل التحقق وتسجيل الحدث موثوقين حتى عندما تصل طلبات متعددة معًا

يحتاج الإجراء نفسه إلى حماية

هناك قضية مهمة أخرى

افترض أن النظام يتعرف بنجاح على الأحداث المكررة

هذا مفيد، لكن يجب أيضًا التعامل مع الإجراء التجاري الفعلي بعناية

تخيل عملية آلية تتلقى حدث طلب ثم تقلل المخزون

إذا تم تسجيل الحدث كمعالج قبل أن ينجح تحديث المخزون، يمكن أن يؤدي الفشل في اللحظة الخاطئة إلى مشكلة مختلفة

قد يعتقد النظام أن الحدث قد اكتمل على الرغم من أن الإجراء الفعلي لم يحدث أبدًا

إذا سجل الحدث فقط بعد نجاح الإجراء، قد تظهر مشكلة أخرى إذا نجح الإجراء لكن النظام فشل قبل تسجيل ذلك النجاح

لذا تتطلب الأتمتة الموثوقة التعامل بعناية مع كل من الحدث والإجراء التجاري

تتطلب الإجراءات المختلفة حماية مختلفة

ليس كل إجراء آلي يحمل نفس المخاطر

إرسال بريد إلكتروني مرتين مزعج

تحصيل رسوم من عميل مرتين يمكن أن يكون خطيرًا

إنشاء سجل الموظف نفسه مرتين يمكن أن يسبب مشاكل في أنظمة أخرى

تقليل المخزون مرتين يمكن أن يخلق جردًا غير دقيق

لذا يجب أن يأخذ التصميم في الاعتبار ما يحدث إذا تم تكرار إجراء

على سبيل المثال، قد يكون تحديث حالة العميل من "معلق" إلى "موافق" آمنًا للتكرار لأن النتيجة النهائية هي نفسها

إضافة 100 وحدة إلى رصيد الحساب أمر مختلف. تكرار تلك العملية يغير النتيجة

هذا التمييز مهم عند تصميم أتمتة موثوقة

استخدام سجل فريد لحماية إجراء

نهج عملي هو جعل العمليات المهمة تعتمد على مرجع تجاري فريد

افترض أن الطلب له مرجع طلب فريد

عندما يتلقى النظام حدثًا لمعالجة ذلك الطلب، يمكنه استخدام المرجع لضمان عدم إمكانية إنشاء العملية ذات الصلة مرتين

هذا مفيد بشكل خاص للإجراءات مثل

• إنشاء فاتورة

• تسجيل دفعة

• إنشاء شحنة

• إنشاء طلب صيانة

• إنشاء حساب موظف

• تحديث المخزون

يمكن لقاعدة البيانات فرض تفرد المرجع بدلاً من الاعتماد فقط على كود التطبيق

هذا يمنح العملية طبقة أخرى من الحماية

ماذا لو توقفت العملية في منتصف الطريق؟

تحتاج العملية الآلية الموثوقة أيضًا إلى مراعاة الاكتمال الجزئي

تخيل أن حدث الطلب يحفز ثلاث إجراءات

• تحديث المخزون

• إنشاء فاتورة

• إخطار العميل

العملية الأولى تنجح

العملية الثانية تنجح

ثم يتوقف النظام قبل إرسال الإشعار

عندما تبدأ العملية مرة أخرى، يجب ألا تقوم بتنفيذ جميع العمليات الثلاث مرة أخرى بشكل أعمى

يحتاج النظام إلى معرفة أي الأعمال قد اكتملت بالفعل

يمكن التعامل مع ذلك عن طريق تسجيل حالة العملية وتصميم كل عملية بحيث يمكن إعادة تنفيذها بأمان

الفكرة الرئيسية هي أن الفشل المؤقت يجب ألا يجبر العملية بأكملها على البدء من جديد

إعادة المحاولة جزء من الأتمتة الموثوقة

الفشل أمر لا مفر منه

قد تكون الخدمة البعيدة غير متاحة

قد تفشل اتصال الشبكة

قد يعيد الخادم التشغيل

قد ترفض قاعدة البيانات الطلب مؤقتًا

لهذا السبب، تحتاج العمليات الآلية غالبًا إلى إعادة محاولة الإجراءات الفاشلة

لكن إعادة المحاولة تخلق خطر تكرار آخر

إذا نجحت عملية ولكن النظام لم يتلق تأكيدًا، فقد يحاول تنفيذ العملية مرة أخرى

هذا يعني أنه يجب دمج آلية إعادة المحاولة مع حماية من التكرار

يجب أن يكون النظام قادرًا على السؤال

“هل حدثت هذه العملية بالفعل؟”

إذا كانت الإجابة نعم، يجب ألا يقوم بتنفيذ العملية مرة أخرى

هذه واحدة من الاختلافات الرئيسية بين عملية تعمل فقط في الظروف العادية وواحدة مصممة لتبقى موثوقة عندما تسوء الأمور

تسجيل ما حدث

يجب أن تترك العملية الموثوقة وراءها سجلًا واضحًا

بالنسبة لكل حدث مهم، يجب أن يكون النظام قادرًا على تحديد

• متى تم استلام الحدث

• أي حدث كان

• ما إذا كان قد تم معالجته بالفعل

• أي الإجراءات تم إكمالها

• أي الإجراءات فشلت

• ما إذا كانت هناك محاولة لإعادة إجراء

• ما كانت النتيجة النهائية

هذا يجعل من السهل التحقيق في المشكلات

بدون مثل هذا السجل، قد يرى الموظف أن شيئًا ما حدث مرتين ولكن ليس لديه وسيلة لفهم السبب

مع سجل واضح، يمكن للشركة تحديد ما إذا كان السبب هو حدث متكرر، أو إعادة محاولة، أو فشل في النظام، أو خطأ في العملية نفسها

التصميم حول الفشل بدلاً من افتراض النجاح

خطأ شائع عند بناء العمليات الآلية هو التصميم فقط للطريق الناجح

تُتصور العملية على أنها

يصل الحدث → يحدث الإجراء → تنتهي العملية

الأنظمة الحقيقية ليست بهذه البساطة

عملية أكثر واقعية هي

يصل الحدث → يبدأ الإجراء → قد يفشل شيء ما → قد تحتاج الإجراء إلى إعادة المحاولة → قد يصل الحدث مرة أخرى → يجب أن ينتج النظام النتيجة النهائية الصحيحة

التصميم لهذه الظروف من البداية يجعل الأتمتة أكثر موثوقية

كما أنه يجعل التغييرات المستقبلية أسهل لأن العملية لديها بالفعل قواعد واضحة للتعامل مع المواقف غير المتوقعة

حيث تكون حماية التكرار أكثر أهمية

ليس كل عملية آلية تحتاج إلى نفس مستوى الحماية

يجب عادةً إعطاء الأولوية القصوى للإجراءات التي لها تأثير مباشر على الأعمال أو المالية

تشمل الأمثلة

• المدفوعات والمبالغ المستردة

• تغييرات المخزون

• تغييرات حسابات العملاء

• سجلات الموظفين

• الفواتير

• الطلبات

• طلبات التوصيل

• طلبات الخدمة

• تغييرات الوصول

قد يكون من السهل تصحيح إشعار مكرر

قد لا يكون من السهل تصحيح معاملة مالية مكررة

فهم عواقب التكرار يساعد في تحديد الأماكن التي تتطلب حماية أقوى

جعل الأتمتة موثوقة

الهدف الحقيقي من حماية التكرار ليس مجرد منع خطأ تقني

إنه جعل الأتمتة موثوقة

يجب أن يكون الموظفون قادرين على الاعتماد على النظام دون الحاجة إلى التحقق باستمرار مما إذا كانت العملية قد حدثت مرة واحدة أو مرتين أو لم تحدث على الإطلاق

يجب ألا يضطر العملاء إلى الاتصال بشركة لأن عملية آلية قامت بخصم المبلغ منهم مرتين

يجب أن يكون المديرون قادرين على الثقة في سجلات المخزون والمالية

يجب ألا تتلقى فرق الصيانة عدة طلبات متطابقة لأن نفس حدث الماكينة قد تكرر

لذا فإن الأتمتة الموثوقة ليست مجرد تقليل العمل اليدوي

إنها تتعلق بضمان أن العمل الآلي ينتج النتيجة الصحيحة حتى عند حدوث مشاكل في الاتصال، وإعادة المحاولات، وفشل النظام

طريقة أفضل لتصميم العمليات الآلية

عند تصميم عملية آلية جديدة، يجب ألا يكون المسار الناجح العادي هو الشيء الوحيد الذي يتم أخذه في الاعتبار

يجب أن يسأل التصميم أيضًا

• ماذا يحدث إذا وصل نفس الحدث مرتين؟

• ماذا يحدث إذا نجح الإجراء ولكن تم فقدان التأكيد؟

• ماذا يحدث إذا توقف العملية في منتصف الطريق؟

• ماذا يحدث إذا تم إعادة نفس الإجراء؟

• كيف يعرف النظام ما حدث بالفعل؟

• ما هي الإجراءات التي يمكن تكرارها بأمان؟

• ما هي الإجراءات التي يجب ألا تحدث مرتين؟

قد لا تكون هذه الأسئلة مرئية للمستخدم النهائي

ومع ذلك، فهي ما يفصل بين سير العمل الآلي البسيط والموثوق

لا يفترض أن العملية المصممة بشكل جيد أن الرسائل ستصل مرة واحدة بالضبط أو أن كل نظام سيستجيب بشكل صحيح دائمًا

إنها تفترض أن المشاكل ستحدث وتضمن أن النتيجة النهائية تظل صحيحة

هذه هي أساس الأتمتة المعتمدة على الأحداث الموثوقة

الهدف ليس مجرد جعل العملية تعمل دون تدخل بشري

الهدف هو جعلها آمنة للاعتماد عليها عندما لا يراقب إنسان كل خطوة

شارك