بعد المشاكل التي ظهرت مع التحديث الأخير لتطبيق بنكيلي، قررت إدارة بنكيلي العودة إلى النسخة السابقة عبر Rollback (الرجوع إلى إصدار سابق ومستقر)، من خلال نشر إصدار جديد على App Store وPlay Store يعيد التطبيق إلى الوضع السابق. الموضوع يستحق التوقف عنده من زاوية تقنية، ليس بهدف انتقاد فرق بنكيلي، وإنما لاستخلاص بعض الدروس من تجربة يمكن أن تحدث لأي تطبيق كبير. بنكيلي يسجل أكثر من مليون عملية يومياً. وعندما نتحدث عن تطبيق بهذا الحجم، فإن أي مشكلة في Production (البيئة الفعلية التي يستخدم فيها العملاء التطبيق) قد تؤثر على عدد كبير من المستخدمين. وهذا لا يخص البنوك فقط، بل أي تطبيق يستخدمه مئات الآلاف من الأشخاص يومياً. المشكلة أن الـ Rollback في تطبيقات Mobile ليس دائماً سهلاً. في الـ Backend (الأنظمة التي تعمل خلف التطبيق على الخوادم)، يمكن غالباً الرجوع إلى إصدار سابق بسرعة. أما إذا قام المستخدم بتحديث التطبيق على هاتفه، فقد تتطلب العودة نشر إصدار آخر على الـ Stores وانتظار توفره للمستخدمين. وهنا يمكن استخلاص بعض الدروس: أولاً، نقوم باختبار النسخة مع مجموعة محدودة قبل الإطلاق العام، وهو ما يعرف بـ Beta Testing. يمكن تجربة التحديث أولاً مع موظفي المؤسسة، ثم مع مجموعة صغيرة من المستخدمين في ظروف حقيقية. الهدف ليس منع كل الأخطاء، وإنما اكتشافها قبل أن تصل إلى عدد كبير من الناس. ثانياً، نقوم بنشر التحديث بشكل تدريجي، أو ما يعرف بـ Progressive Rollout. بدل نشر التحديث للجميع مباشرة، نقوم بإتاحته في البداية لنسبة صغيرة من المستخدمين، مثلاً 1%، ثم 5%، ثم 20%، وبعد التأكد من استقرار النسخة نقوم بتوسيع النسبة تدريجياً حتى تصل إلى الجميع. خلال كل مرحلة، تتم مراقبة الأعطال، تسجيل الدخول، التحويلات، عمليات الدفع والأداء بشكل عام. وإذا ظهرت مشكلة، يمكن إيقاف التوسع مبكراً قبل أن يتأثر عدد أكبر من المستخدمين. ثالثاً، يمكن الاعتماد على Feature Flags، وهي آلية تسمح بتفعيل أو تعطيل بعض الميزات عن بُعد. مثلاً، عند إطلاق طريقة جديدة لتنفيذ خدمة معينة، يمكن الاحتفاظ مؤقتاً بالطريقة القديمة والجديدة. وإذا ظهرت مشكلة في الجديدة، نقوم بتعطيلها والعودة إلى الطريقة المستقرة، دون انتظار إصدار جديد على الـ Store، عندما يسمح تصميم التطبيق بذلك. رابعاً، يجب الحفاظ على Backward Compatibility، أي التوافق مع الإصدارات السابقة. عند إطلاق إصدار جديد، يجب أن نتذكر أن النسخة القديمة والجديدة ستبقيان مستخدمتين معاً لفترة. لذلك من المهم أن يستطيع الـ Backend والـ API (الواجهة التي تربط التطبيق بالأنظمة الخلفية) التعامل مع أكثر من إصدار خلال مرحلة الانتقال. هذه الإجراءات لا تعني أن المشاكل لن تحدث. لا يوجد نظام بدون أخطاء، ولا تحديث بدون مخاطر. ولا يمكن الحكم على الخيارات التقنية لفرق بنكيلي دون معرفة تفاصيل أنظمتهم والقيود الموجودة لديهم. لكن مثل هذه الحالات تبقى فرصة جيدة لاستخلاص الدروس. عندما يستخدم تطبيق ما مئات الآلاف من الأشخاص، فإن أي عطل تقني قد يتحول بسرعة إلى مشكلة تمس شريحة كبيرة من المستخدمين. لذلك، يجب أن تكون خطة العودة جزءاً من خطة إطلاق التحديث نفسها: Beta Testing، ثم Progressive Rollout، ثم Feature Flags، مع Backward Compatibility وخطة واضحة للـ Rollback. وفي النهاية، قبل أي تحديث مهم، لا يكفي أن نسأل: هل نحن جاهزون لإطلاق الإصدار الجديد؟