Yarob | يعرُب 💻
Yarob | يعرُب 💻

@YarHmm

16 تغريدة 9 قراءة Sep 07, 2021
و من الأعياد اللي أتينا بها في البرودكشن هو فعلتنا النكراء البارحة في @qosoorSA بأنا كتبنا سطرا يقوم بحذف كل مستخدم يبدأ بإنشاء حجز جديد. نعم.. كتبنا سطرا يحذف مستخدمينا بأيدينا و رفعناه للبرودكشن بكل ثقة و غرور ثم خلدنا إلى النوم.
هنا قصة (سطر الكارثة) نقصها للعظة و العبرة..
في يوم الإثنين التاسع و العشرون من محرم مرت ساعات دون ملاحظة ظهور تنبيهات لحجوزات جديدة في (slack).. فقررنا تجربة عملية الحجز للتأكد، عملية الحجز تتم بعدة خطوات في قصور، تمت معي الخطوة الأولى بنجاح.. أما الخطوة التالية أظهرت رسالة خطأ..
فبدأت بعملية إزالة الحشرة لمعرفة الخطأ و المعروفة بال(debugging) فوجدت أن الكود الذي يرجعه ال api هو 401 - Unauthenticated و بعد التفحص و التدقيق اكتشفت أن كل ال api requests التالية لأول خطوة في الحجز لا تعمل و ترجع نفس الكود 401 مع أن الheader token يتم إرساله دون مشاكل
و مع زيادة الديبقنق بدأنا نفهم أن ال backend لا يتعرف على المستخدم و أن آخر عهد له به هو خطوة الحجز الأولى التي بدأنا نفهم الكارثة التي كانت تخفيها بين سطور أكوادها، تلك الدالة الخبيثة التي كانت تتعرض لكل مستخدم يمر بها و تمحوه من الوجود ثم ترجع ال 200 بكل بجاحة و كأن شيئا لم يكن
هنا أدركنا الكارثة التي اقترفتها أيدينا في تلك الدالة سيئة الذكر، حيث كنا نعمل على ميزة تسمح بإنشاء حجز دون تسجيل الدخول عن طريق إنشاء مستخدم افتراضي، ثم نقوم بمسح ذلك المستخدم، لماذا؟ هي الطريقة الأسرع و الأفضل التي اخترناها لذلك.. و ليتنا ما.. ولا بلاش.
بعد استيعابنا لما جلبناه من عيد.. بكينا بعض الشيء على اللبن المسكوب ثم توجهنا لإيقاف النزيف بشكل عاجل حيث قمنا برفع النسخة السابقة من الكود عالبرودكشن لإيقاف تلك اللعنة التي أودت بحسابات بعض المستخدمين الأعزاء 💔
ثم توجهت إلى أكواد ال User و في طريقي كنت أدعو الله أن ألقى ال soft delete مفعلا للمستخدمين، حيث أنه الطريقة الأسرع لاسترجاع حساباتهم الغالية على قلوبنا. ثم وجدت كود الحذف الناعم مكتوبا لكنه سُبق بشرطتين كانتا كالرصاصتين على قلبي.إنها سلاشات الكومنت التي عطلت الكود و حسبنا الله..
يبدو أنني سألجأ لحلول صعبة كمقارنة نسخة قاعدة البيانات الحالية مع آخر نسخة احتياطية قبل حلول اللعنة على البرودكشن، ثم إعادة المستخدمين بهذه الطريقة. نظرا لصعوبة الحل.. عدنا للبكاء على اللبن المسكوب بعض الشيء ثم توجهنا للبحث عن أفكار أخرى
تذكرت أننا نحفظ بيانات الحاجز في جدول الحجز، حيث يقوم بتعبئتها كجزء من عملية الحجز، و أن الحجوزات لا يتم حذفها حتى لو حُذف أصحابها فقاعدة الحذف التي وضعناها كانت set null و ليس cascade، هنا تغشت نفسي الطمأنينة و نزلت على قلبي السكينة و شربت بقية اللبن
فاتجهنا لجلب الحجوزات اليتيمة في البرودكشن التي لم يعد لها أصحابا و لم يبق من أثرهم الحسن إلا أسماؤهم و أرقامهم المخزنة في الحجز ذاته و هو الأمر الذي مكننا من معرفة ضحايا تلك الكارثة التي حلت حيث كنا نياما.
لحسن الحظ كان عدد الحسابات المحذوفة ١٠ فقط خلال ١٥ ساعة كانت أغلبها ساعات ركود (فترة الليل إلى الصباح) و قد قمنا بالتواصل معهم و طمأنتهم أنا نقف معهم في تلك الظروف الصعبة و أن الحياة لا تستحق الحزن على حسابات رقمية حتى و إن كانت في تطبيق عظيم سهل سلس يجهز مناسبتك ببضعة ضغطات.
الدروس المستفادة:
- لا تؤجل تفعيل الحذف الناعم إلى الغد و قم بحل المشاكل التي تواجهك فيه - مو تسويه comment و تأجل موضوعه مثل بعض الناس-.
- أنا شخصيا قمت بعمل review للكود مبدئيا، لكن الخطأ أني تسرعت بالموافقة عليه دون review بعد إضافة commits إضافية كان من ضمنها سطر الكارثة
- لا تتسرع بالرفع إلى البرودكشن ولا تعامل ال staging معاملة المزهرية حتى لو كنت بحاجة شديدة لاختبار جزئية معينة في البرودكشن كما كان الحال لدينا.
- تنبيهات سلاك و ال chat-ops و مراقبة الأنظمة لها دور كبير في اكتشاف مشاكل و أخطاء قد لا تعلمها أبد الدهر دون تلك الأدوات.
- النسخة الاحتياطية اليومية - نصف - ربع اليومية مهمة جدا، و كانت لي كمخدر الألم الذي أستحضره كلما انغلقت أبواب الحلول في وجهي.
كان معكم أبطال قصة سطر الكارثة:
@bsaqqa_ : الكاتب الفعلي لذلك السطر، و هو مبرمج رهيب فنان خبير كتب ذلك السطر ليذكرنا بطبيعته البشرية و أن الكمال لله وحده.
@YarHmm: مبرمج يدّعي أنه reviewer، يرفع للبرودكشن بلا مراجعة، يلغي الحذف الناعم، ثم يخلد إلى النوم.
رأيت الدهر مختلفا يدورُ
فلا حزنٌ يدوم و لا سرورُ
و قد بنت الملوك به قصورا
فلم تبقَ الملوك ولا ال(قصورُ)

جاري تحميل الاقتراحات...