الانتقال إلى مساحات عمل أكبر دون أن ينتظر أحد

لكل مشروع في Mythex مساحة عمل خاصة به: حاسوب سحابي صغير يكتب فيه الوكيل الكود وتعمل فيه معاينة تطبيقك. كنا قد رفعنا الذاكرة في مساحات العمل الجديدة من 1 GB إلى 2 GB، لكن المساحات القديمة بقيت عند 1 GB، وفي اليوم الذي فحصنا فيه كانت نحو ربعها كذلك. نقل إصلاحنا الأول المشروع إلى مساحة عمل أكبر عند فتحه في المرة التالية. وفي أول يوم له في الإنتاج، جعل ذلك شخصاً واحداً ينتظر سبع دقائق. فوضعنا عليه حداً صارماً للوقت، ثم أخرجنا النقل من عملية فتح المشروع تماماً.

لماذا بقيت مساحات العمل القديمة صغيرة

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

وكان ذلك مهماً. فإحدى المساحات الصغيرة نفدت ذاكرتها أثناء git push بينما كانت معاينتها تبدأ، وتوقفت عن الاستجابة 11 دقيقة. وفشل نشر بسبب ذلك.

المحاولة الأولى: انقل المشروع عند إيقاظه

تتوقف مساحات العمل مؤقتاً عندما لا يستخدمها أحد، وتستيقظ عند فتح المشروع. بدا الاستيقاظ اللحظة المناسبة لنقل المشروع، لأن أحداً لم يعمل فيه بعد.

عمل النقل على النحو التالي:

1. افحص الحجم. إذا كانت مساحة العمل أصغر من 2 GB فانقلها. وإذا كان حجمها غير معروف فلا تفعل شيئاً.
2. لا تعطّل النشر. يقرأ النشر ملفات مساحة العمل، لذلك إذا كان هناك نشر يعمل فتخطَّ النقل.
3. ضغط المشروع. أرشِف كل ما في المشروع، بما في ذلك تاريخ git، أي كل نقطة تحقق يملكها المشروع، وملف .env الخاص بالتطبيق الذي يخص صاحبه، لكن استثنِ الاعتماديات المثبتة (node_modules) لأنه يمكن إعادة تثبيتها.
4. انسخه مباشرة. ابث الأرشيف من مساحة العمل القديمة إلى مساحة جديدة بحجم 2 GB، حتى لا يضطر إلى الدخول في ذاكرة خادمنا نفسه.
5. قارن قبل التبديل. عُدّ الملفات، واقرأ آخر نقطة تحقق، وعُدّ نقاط التحقق، في المساحتين كلتيهما. بدّل فقط إذا تطابقت الثلاثة.
6. أبقِ القديمة عند أي فشل. أي خطأ أو أي عدم تطابق يتخلص من مساحة العمل الجديدة ويفتح المشروع في القديمة كما كان.

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

ما الذي حدث في اليوم الأول

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

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

المحاولة الثانية: ميزانية صارمة

في اليوم نفسه غيّرنا أربعة أشياء:

• دقيقة واحدة للنقل كله. كل خطوة، من فحص الحجم والضغط وإنشاء المساحة الجديدة والنسخ والفك والمقارنة، تتشارك ميزانية واحدة مدتها 60 ثانية. عندما تنفد، يُفتح المشروع في مساحة العمل القديمة.
• أوقف العمل نفسه، لا الانتظار فقط. لا يكفي أن نتوقف نحن عن الانتظار إذا كان الأرشفة ما زالت تعمل داخل مساحة العمل التي سيستخدمها صاحب المشروع. أصبح كل أمر أرشفة يُقتل داخل مساحة العمل نفسها قبل انتهاء الميزانية بقليل. وإذا وصلت المساحة الجديدة بعد أن توقفنا، تُتلف.
• لا تجعل صاحب المشروع ينتظر التنظيف. حذف الأرشيف المؤقت يحدث الآن في الخلفية.
• لا تحاول مرة أخرى عند كل فتح. المشروع الذي تعذر نقله يُترك وشأنه 24 ساعة، فالفشل يكلّف تأخيراً واحداً في اليوم على الأكثر، لا تأخيراً عند كل فتح.

المحاولة الثالثة: أخرجه من الاستيقاظ

جعل ذلك أسوأ حالة دقيقة واحدة. لكن الدقيقة تبقى دقيقة، وأدركنا أن النقل لا يحتاج إلى أن يكون في طريق أحد أصلاً.

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

لذلك أزلنا النقل من الاستيقاظ تماماً. فتح المشروع يفعل ما كان يفعله من قبل. أما مساحات العمل الصغيرة المتبقية فتُعالَج الآن كدفعة مُشرَف عليها: لا أحد ينتظرها، وأي مساحة لا تُنقل تظهر في تقرير الدفعة، حيث يمكننا النظر فيها، بدلاً من أن تظهر أمام صاحب المشروع.

ما استخلصناه

• تغيير الحجم ليس ممكناً دائماً. عندما تثبّت المنصة الحجم عند الإنشاء، فإن رفع القيمة الافتراضية يفيد الأشياء الجديدة فقط. فخطّط للقديمة.
• «لا أحد يستخدمه بعد» ما زال يعني أن أحداً ينتظر. العمل الذي يُنجز في طريق الدخول إلى المنتج هو عمل يراقبه شخص.
• ضع ميزانية على أي شيء في مسار المستخدم، وأوقف العمل عندما تنفد. مهلة من جهتنا بينما يستمر الأمر في مكان آخر لا تحل المشكلة، بل تنقلها.
• الترحيل لمرة واحدة ينتمي إلى مهمة لمرة واحدة. إخفاؤه داخل الإجراءات اليومية يجعل كتابته أرخص وتشغيله أغلى.
• اختبر فحوص الأمان. مقارنة لا تقارن شيئاً تبدو تماماً مثل مقارنة نجحت.

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