إعادة البناء التي خفّضت زمن الاستجابة 90%

يصبح الـ Backend بطيئًا بطريقتين: إما أن شيئًا فيه يؤدي عملًا أكثر مما ينبغي، أو أنه يؤدي القدر الصحيح من العمل في المكان الخطأ. وهذا النظام كان يفعل الاثنين معًا، وكان كلٌّ منهما يحجب الآخر.

السياق

تدير كلين لايف عملياتها الميدانية عبر منصة متكاملة مع Zoho FSM: تُرسَل المهام إلى الفنيين، وتعود السجلات التي تنتجها تلك المهام. وأنا أعمل على الـ Backend الذي يقف خلفها: طبقة البيانات، وتكامل المدفوعات، وكل ما يجري خارج دورة الطلب.

بُنيت المنصة بسرعة، وكانت تعمل. وهذه عادةً هي اللحظة التي يبدأ فيها نموذج البيانات بتحصيل فوائد القرارات التي مكّنت من إطلاقه.

المشكلة

صارت عمليات القراءة هي عنق الزجاجة. فجلب البيانات — وهو العمل الذي ينتظره أحدهم دائمًا — كان أبطأ ما يفعله النظام.

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

أين كان يذهب الوقت

أربعة أسباب، وكانت تتراكم فوق بعضها:

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

التشخيص

حين تتراكم أربعة أسباب، يصبح ترتيب العمل هو المنهج كله. فإن غيّرت أشياء عدة دفعة واحدة، لم يعد القياس يخبرك بشيء: يتحرك الرقم، ولا تستطيع أن تقول أيُّ تغيير حرّكه — ولا إن كان أحدها قد أساء بينما غطّى عليه غيره.

لذلك: القراءات أولًا، لأنها الموضع الذي جاءت منه الشكوى. ثم السؤال الذي يشطر المشكلة نصفين: هل يُنفَق الوقت داخل قاعدة البيانات أم حولها؟ وكل ما بعد ذلك استبعادٌ متدرج: تغيير واحد، ثم قياس، ثم إبقاؤه أو التراجع عنه.

القيود

ما الذي تغيّر

والترتيب ليس عرضيًا. فالتخزين المؤقت لاستعلام سيئ يخفيه لا يصلحه، وفهرسة مخطط أنت على وشك تغييره عملٌ ضائع.

القرارات الأساسية

1. 01

   تغيير نموذج البيانات قبل الكود

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

   المقايضةتغيير المخطط يعني migration على بيانات حيّة، وهو ما جعله أخطر أجزاء المشروع. اشترى أكبر تحسين وحمل أكبر مخاطرة، وكلاهما كان القرار نفسه.

2. 02

   تخزين مؤقت انتقائي، بمفاتيح موحّدة

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

   المقايضةكل قيمة مخزَّنة مؤقتًا هي وعدٌ بإبطالها في وقتها الصحيح. والبيانات المتقادمة حين كان يجب أن تكون حديثة خللٌ أصعب في الاكتشاف بكثير من استعلام بطيء.

3. 03

   إخراج العمل من الطلب بدل تسريعه في مكانه

   العمل الذي لا ينتظره أحد لا ينبغي أن يقع في المسار الذي ينتظره الناس. والعمل الموضوع في طابور ينال أيضًا ما لا يناله الاستدعاء المتزامن أبدًا: فرصة إعادة المحاولة.

   المقايضةصارت الواجهة تعود قبل اكتمال العمل، فوجب على المنتج أن يعبّر بصدق عن حالة “قيد التنفيذ”. كما انتقل الفشل من شاشة المستخدم إلى طابور يحتاج من يراقبه.

4. 04

   قفل وحدة العمل، لا مسار الكود

   أقفال موزعة مفاتيحها مبنية على العمل نفسه، وتتبع اتفاق التسمية ذاته المستخدم في التخزين المؤقت، فلا يمكن التقاط الوحدة نفسها مرتين مهما بلغ عدد العمال.

   المقايضةالقفل رهانٌ على مدة صلاحيته. إن كانت قصيرة عادت الازدواجية، وإن كانت طويلة احتجز عاملٌ متعطل المهمة إلى أن تنتهي المدة.

الأداء

المقايضات

النتيجة

ما خرجت به