الأتمتة اللي تفشل بصمت أخطر من عدمها: كيف تعالج الأخطاء في سير العمل؟

الموظف لو نسي يرسل فاتورة، غالباً أحد ينتبه. الأتمتة لو فشلت، ما أحد ينتبه — لأن الكل مطمئن إن «النظام يسويها». وتكتشف بعد أسبوعين إن الطلبات ما كانت توصل للمحاسبة، وإن العملاء ما استلموا تأكيداً. الأتمتة الجيدة مو اللي ما تفشل أبداً، هي اللي لما تفشل تقول لك فوراً وتعرف ترجع.

أنواع الأخطاء اللي بتواجهها

• أخطاء مؤقتة: الخدمة الخارجية بطيئة أو متوقفة دقائق.
• حدود الاستخدام: أرسلت طلبات كثيرة للـ API في وقت قصير.
• انتهاء الصلاحية: توكن أو كلمة مرور تغيرت.
• بيانات غير متوقعة: حقل فاضي، رقم جوال بصيغة غريبة، نص بدل رقم.
• تغيير من الطرف الآخر: الخدمة غيّرت شكل البيانات أو أوقفت نسخة API.

١. إعادة المحاولة للأخطاء المؤقتة

في n8n تقدر تفعّل إعادة المحاولة على مستوى العقدة مع فاصل زمني بين المحاولات. استخدمها مع طلبات الشبكة والخدمات الخارجية. لكن لا تعيد المحاولة على أخطاء البيانات؛ رقم جوال خاطئ بيبقى خاطئاً مهما كررت.

٢. سير عمل مخصص للأخطاء

n8n يسمح بتعيين Error Workflow يشتغل تلقائياً لما يفشل أي سير عمل. خلّه يرسل تنبيهاً فيه: اسم التدفق، العقدة اللي فشلت، رسالة الخطأ، ورابط التنفيذ. والأهم إن التنبيه يوصل لقناة يشوفها شخص محدد مسؤول، مو إيميل مشترك ما أحد يفتحه.

٣. لا تضيّع البيانات

• لو فشلت معالجة طلب، احفظه في جدول أو قائمة «معلّقات» مع سبب الفشل بدل ما يختفي.
• ابنِ طريقة لإعادة معالجة المعلقات بعد إصلاح المشكلة.
• لما يستقبل Webhook بيانات، رد بسرعة بالاستلام ثم عالج، عشان الطرف الآخر ما يعتبرها فشلاً ويعيد الإرسال مرات.

٤. امنع التكرار

إعادة المحاولة وإعادة الإرسال تفتح باباً لمشكلة معاكسة: فاتورة تنشأ مرتين، أو رسالة توصل العميل ثلاث مرات. الحل مفهوم اسمه Idempotency: كل عملية لها معرّف فريد (رقم الطلب مثلاً)، وقبل التنفيذ تتحقق هل نُفّذت سابقاً.

٥. تحقق من البيانات مبكراً

ضع خطوة تحقق في بداية التدفق: الحقول المطلوبة موجودة؟ الصيغ صحيحة؟ وحّد الصيغ (أرقام الجوال، التواريخ، الأرقام العربية والإنجليزية) قبل ما تمررها. الفشل عند البوابة أوضح وأرخص من الفشل في منتصف التدفق بعد ما أُرسلت نصف الرسائل.

٦. احترم حدود الخدمات

• قسّم العناصر الكثيرة إلى دفعات مع انتظار بينها.
• خزّن النتائج اللي ما تتغير بدل طلبها كل مرة.
• اقرأ حدود كل API قبل بناء تدفق يعالج آلاف السجلات.

قائمة فحص قبل تشغيل أي أتمتة

• هل يوجد تنبيه عند الفشل يوصل لشخص مسؤول؟
• هل البيانات الفاشلة تُحفظ للمعالجة لاحقاً؟
• هل تنفيذ نفس الحدث مرتين آمن؟
• هل جرّبت التدفق ببيانات ناقصة وغريبة، مو فقط بالمثال المثالي؟
• هل فيه شخص يعرف كيف يوقف التدفق بسرعة لو صار خطأ جماعي؟

مثال: تدفق طلبات المتجر بعد إضافة الحماية

تخيل تدفقاً يستقبل الطلبات من المتجر ويرسلها للمحاسبة ويرسل تأكيداً للعميل على واتساب. بعد تطبيق المبادئ السابقة يصير شكله كذا:

• الـ Webhook يستقبل الطلب ويرد بالاستلام فوراً.
• خطوة تحقق: رقم الطلب والمبلغ ورقم الجوال موجودة وصيغها صحيحة، وإلا يُحفظ الطلب في «المعلّقات» مع السبب.
• فحص تكرار: هل رقم الطلب هذا عولج قبل؟ إذا نعم، يتوقف التدفق بهدوء.
• إنشاء الفاتورة في المحاسبة مع إعادة محاولة عند أخطاء الشبكة.
• إرسال واتساب في فرع مستقل: لو فشل، ما يُلغى تسجيل الفاتورة، بل يُسجَّل فشل الرسالة لإعادة إرسالها.
• تسجيل رقم الطلب كمُعالَج بعد نجاح الخطوات الأساسية.
• أي فشل غير متوقع يشغّل سير عمل الأخطاء ويرسل تنبيهاً للمسؤول.

لاحظ فكرة الفصل: فشل خطوة ثانوية مثل الرسالة ما يلزم يوقف خطوة أساسية مثل الفاتورة. حدد لكل تدفق وش الخطوات اللي «لازم تنجح كلها مع بعض» ووش الخطوات اللي تقدر تفشل وتُعاد لاحقاً. هذا القرار وحده يفرق بين أتمتة هشة وأتمتة تتحمل الأيام السيئة.

في منصة أزهل الرقمية معالجة الأخطاء جزء من تسليم أي أتمتة، مو إضافة اختيارية. ولو عندك تدفقات قائمة تشك إنها تفشل بصمت، راسلنا على واتساب ونراجعها معك.