ُعاني أنظمة المراسلة أحادية القناة من نقطة فشل واحدة. فقد يتعطل تطبيق WhatsApp، أو يتعذر الوصول إلى أحد المستخدمين عبر خدمة RCS، أو قد يتدهور أداء مسار الاتصال، أو قد يتم رفض قالب أثناء الحملة. أما استراتيجية تجاوز الفشل متعددة القنوات، فتعتبر "إيصال هذه الرسالة إلى هذا الشخص" هدفًا أساسيًا، والقناة وسيلة قابلة للتغيير. إليك كيفية تصميم استراتيجية فعّالة وموثوقة.
حدد سلم القنوات لكل نوع رسالة
لا يوجد ترتيب موحد، فالترتيب الأمثل يعتمد على نوع الرسالة. إليك بعض الخيارات المنطقية: للتحقق من الهوية، ابدأ بـ WhatsApp أو RCS (لأنهما يوفران تجربة غنية، وعلامة تجارية مميزة، وسرعة عالية)، ثم رسائل SMS، ثم رمز التحقق الصوتي. بالنسبة للإشعارات المتعلقة بالمعاملات، ابدأ بـ RCS أو WhatsApp لتوفير تجربة مميزة، مع اعتبار رسائل SMS خيارًا احتياطيًا مضمونًا. أما بالنسبة للتنبيهات العاجلة، فابدأ برسائل SMS لسهولة الوصول إليها، وأضف الرسائل الصوتية كخيار تصعيد. حدد ترتيبك بعناية، لكل نوع رسالة، ودوّنه.
يجب أن يكون التبديل التلقائي مشروطًا، وليس أعمى.
- عطل في الإمكانيات - لا يمكن الوصول إلى المستخدم عبر القناة (لا يوجد RCS مُفعّل، ولا يوجد حساب WhatsApp). قم بإلغاء الاتصال فورًا؛ لا تنتظر.
- فشل التسليم - استلمت القناة الرسالة، لكن سجل التسليم يُظهر أنها لم تُسلّم. فشل التسليم بسبب الإيصال السلبي.
- فشل المهلة الزمنية - لم يتم تلقي تأكيد استلام إيجابي خلال مهلة زمنية محددة لنوع الرسالة (مهلة ضيقة لرمز التحقق لمرة واحدة، وأكثر مرونة للإشعارات). يتم إلغاء العملية عند انتهاء المهلة.
- عطل في مزود الخدمة - القناة نفسها معطلة. يتم الكشف عن ذلك من خلال مراقبة معدل الخطأ، ويتم تحويل القناة بأكملها لجميع البيانات، وليس رسالة تلو الأخرى.
احذر من التسليم المزدوج
يكمن الخلل الدقيق في جميع أنظمة تجاوز الأعطال في إرسال الرسالة مرتين - مرة عبر القناة التي كانت بطيئة ولكنها لم تتعطل فعليًا، ومرة أخرى عبر القناة الاحتياطية. يُعد هذا الأمر بالغ الضرر بالنسبة لبروتوكول OTP، حيث يتلقى المستخدم رمزين مختلفين ولا يعرف أيهما يستخدم. يكمن الحل في وجود مصدر واحد موثوق لحالة التسليم لكل رسالة، وسجل لكل عملية إرسال (احتفظ بمعرّف الرسالة الذي تعيده واجهة API وتحقق من حالتها قبل أي إعادة إرسال) بحيث لا تؤدي إعادة المحاولة إلى إرسال ثانٍ، وبالنسبة لبروتوكول OTP، يتم توليد الرمز مرة واحدة وإعادة استخدامه عبر جميع القنوات في التسلسل الهرمي، بحيث تحمل أي رسالة تصل رمزًا صالحًا.
تنخفض التكلفة والخبرة على حد سواء.
لكل مستوى من مستويات النظام اقتصادياته الخاصة وتجربة المستخدم المختلفة. لا يُعدّ التحويل إلى المستوى التالي مجانيًا، فقد يعني ذلك رسالة أقل تميزًا أو تكلفة أعلى للوحدة. وهذا أمر طبيعي وصحيح: فرسالة نصية قصيرة (SMS) تصل بتكلفة أعلى قليلًا أفضل من رسالة WhatsApp مجانية لا تصل. لكن هذا يعني ضرورة مراقبة معدل التحويل. إذا كان 40% من حركة البيانات لا تصل إلى المستوى الأخير، فالمشكلة تكمن في المصدر - بيانات غير دقيقة، أو قناة رئيسية مُهيأة بشكل خاطئ - ويجب معالجة السبب بدلًا من دفع ثمن العرض.
تُنفّذ واجهة برمجة التطبيقات متعددة القنوات من BroadNet جميع مراحل العملية - فحص القدرات، والتحويل التلقائي المشروط، ورمز OTP المشترك، وتحليلات كل قناة - من خلال استدعاء واحد لواجهة برمجة التطبيقات، وتعيد معرّف رسالة لكل عملية إرسال حتى تتحقق إعادة المحاولة من الحالة بدلًا من الإرسال مرتين (راجع منع التكرار وإعادة المحاولة الآمنة). ما عليك سوى تحديد الرسالة والأولوية، وسيتولى النظام الأساسي عملية التنسيق.
اختبر مسارات الفشل
السبب الأكثر شيوعًا لعدم نجاح استراتيجية تجاوز الأعطال في بيئة الإنتاج هو عدم اختبار مسار تجاوز الأعطال مطلقًا؛ إذ يُكتب ويُنشر، ثم يُفعّل فقط عند حدوث انقطاع حقيقي. لذا، يُنصح بإنشاء اختبارات اصطناعية تُجبر على تنفيذ كل نمط من أنماط الأعطال (تعطيل القناة الأساسية، محاكاة مهلة زمنية، إدخال DLR سلبي) والتأكد من وصول الرسالة. فمسار تجاوز الأعطال الذي لم تختبره هو مسار غير موجود أصلًا.