تعطل سير العمل يحتاج مسؤولًا وخطوة تالية
التعامل مع استثناءات الأتمتة يحدد ما يحدث عندما لا يستطيع النظام إكمال العملية بأمان. ظهور رسالة خطأ ليس نهاية المعالجة. المسار المفيد يحفظ الطلب، ويحدد من يراجعه، ويوضح الإجراء التالي، ويسجل ما إذا كانت الاستعادة نجحت بالفعل.
هذا الدليل يركز على تصميم التدخل البشري بعد اختيار عملية للأتمتة. أما قرار ما الذي يجب أن يظل بيد الإنسان من البداية، فتجده في مقال ما الذي لا يجب أتمتته في عمليات العمل.
1. افصل أنواع الاستثناءات
لا تضع كل المشكلات داخل نفس حلقة إعادة المحاولة. انقطاع مقدم خدمة مؤقتًا، ونقص بيانات العميل، والحاجة إلى قرار إداري، حالات تحتاج أفعالًا مختلفة.
- فشل تقني مؤقت: انتهاء مهلة الطلب أو خطأ مؤقت من مقدم الخدمة. قد تناسبه محاولات محدودة بعد التحقق مما إذا كان الإجراء الأصلي نُفذ بالفعل.
- بيانات ناقصة أو غير صالحة: مثل غياب مرجع المنتج أو معلومة مطلوبة. تكرار نفس الطلب الناقص لن يصلحه.
- قرار تجاري يحتاج مراجعة: طلب خارج القواعد المتفق عليها أو يحتاج موافقة لا يملك النظام صلاحية اتخاذها.
ضع اسم حالة واضحًا لكل مسار. لا تستخدم علامة نجاح عامة تخفي الفرق بين تم الاستقبال، وتم الحفظ، وبانتظار المراجعة، واكتمل التنفيذ.
2. احفظ سجلًا يبقى حتى عند الفشل
أنشئ مرجعًا ثابتًا للطلب قبل تنفيذ إجراءات لاحقة يصعب التراجع عنها. يتضمن السجل المرحلة الحالية والمرجع الخارجي وآخر نتيجة مؤكدة وعدد المحاولات والمسؤول عن المراجعة. حدّد البيانات اللازمة ومدة الاحتفاظ بها حسب نشاطك.
في مثال ربط واتساب بطلبات WooCommerce، استقبال الرسالة وإنشاء الطلب حدثان منفصلان. غياب تفاصيل المنتج يحتاج استكمالًا، ولا يبرر اختراع بند داخل الطلب.
3. اجعل المحاولات محدودة مع منع التكرار
حدد عدد المحاولات والفاصل بينها حسب مقدم الخدمة وأهمية العملية وتكلفتها. انتهاء المهلة لا يثبت أن الإجراء لم يحدث؛ فقد يكون النظام الآخر قبل الطلب ثم ضاع الرد في الطريق.
استخدم مرجعًا ثابتًا واستراتيجية موثقة لمنع التكرار تدعمها الأنظمة المتصلة. افحص آخر حالة مؤكدة قبل الإعادة عندما يكون ذلك ممكنًا. وعند الوصول للحد المتفق عليه، أوقف المحاولات الآلية وانقل الطلب إلى قائمة مراجعة واضحة.
4. أرسل تنبيهًا يمكن التصرف بناء عليه
التنبيه المفيد يوضح ما الذي فشل، وأي طلب تأثر، وما الذي نعرف أنه تم، ومن المسؤول، وأين يفتح سجل المراجعة. يكفي تصنيف مختصر للخطأ ورابط مناسب بدل تكرار بيانات العميل الخاصة داخل كل رسالة.
حدد المستلم وفاصلًا يمنع إغراق الفريق بتنبيهات نفس الحادثة. اتفق أيضًا على توقع للاستجابة وشخص للتصعيد؛ وصول الرسالة إلى صندوق لا يتابعه أحد لا يعني اكتمال تسليم المسؤولية.
5. صمّم استعادة مضبوطة للعمل
يحتاج المراجع إلى خيارات واضحة: تصحيح البيانات، أو رفض الطلب غير المناسب، أو استكمال التنفيذ من نقطة آمنة معروفة. سجّل من اتخذ الإجراء وما الذي تغير. لا تعِد تشغيل كل الخطوات إذا كانت مراحل سابقة قد أنشأت طلبًا أو أرسلت رسالة بالفعل.
افصل حالة طلب العميل عن حالة الإشعار. يمكن أن يكون الاستفسار محفوظًا بينما فشل إرسال بريده؛ عندها تصلح الإشعار دون إنشاء استفسار جديد. هذا الفصل يمنع تحول إصلاح التواصل إلى تكرار في السجلات.
6. اختبر المسارات غير المعتادة قبل التسليم
اختبر نقص الحقول، وتعطل مقدم الخدمة، وضياع الرد بعد قبول الإجراء، ووصول نفس الطلب مرتين، واستنفاد المحاولات. تأكد أن لكل حالة نتيجة مفهومة ومسؤولًا ظاهرًا، واستخدم بيانات ووجهة اختبار متفقًا عليهما.
وثّق حالات النظام وحدود الإعادة ومستلمي التنبيهات وخطوات الاستعادة ومسؤول المتابعة. حدّث الوثيقة عندما تتغير القواعد أو مقدم الخدمة. الأتمتة الموثوقة هي التي يستطيع الفريق فهمها واستعادتها عندما يتوقف المسار المعتاد.
اطّلع على حلول أتمتة الأعمال أو اطلب مراجعة نقطة انتقال تتكرر أعطالها.