الهندسة

الهندسة

كيف نبني Mythex ونشغّله، بما في ذلك ما تعطّل وكيف أصلحناه.

• إعادة النشر الفاشلة لا تحذف خلفية تعمل أبداً — قد تحذف إعادة نشر فاشلة واجهة البرمجة الحية لتطبيق، أو تترك نسخته الجديدة المعطلة تعمل. ثلاثة إصلاحات في طريقة تراجع Mythex عن نشر خاطئ.
• تنبيهات تُرسل مرة واحدة، لا مرة لكل خادم — تنبيه يومي واحد وصلنا خمس مرات في عصر واحد. لماذا يفشل إزالة التكرار في الذاكرة مع خادمين ونشر، وكيف أصلحته الحالة المشتركة.
• الانتقال إلى مساحات عمل أكبر دون أن ينتظر أحد — ربع مساحات العمل لدينا بقيت عند 1 GB بعد أن انتقلنا إلى 2 GB. أول إصلاح لنا جعل شخصاً واحداً ينتظر سبع دقائق. ما الذي غيّرناه، ثم غيّرناه مجدداً.
• فوترة قواعد البيانات حسب ما تستخدمه فعلاً — كنا نقدّر تكلفة قاعدة بيانات كل تطبيق، وكان التقدير خاطئاً في الاتجاهين. الآن تُحتسب كل قاعدة بيانات من الاستخدام المقاس، ساعة بساعة.
• التقاط التطبيقات التي تنهار مباشرة بعد النشر — نجحت ثلاث عمليات نشر في فحص الصحة بينما كانت واجهة برمجتها تنهار بعد ثوانٍ من كل إقلاع. السبب: حساب الانهيارات في قائمة محدودة بخمسة مدخلات.
• إبقاء جولات الوكيل كثيفة الصور ضمن الذاكرة — جولة وكيل كانت تفحص مسحات كتالوج نفدت ذاكرتها عند 952 ميغابايت. ثلاثة أسباب منفصلة، كل منها يحتفظ بالصور أطول من اللازم، وكيف أصلحناها.
• إبقاء جولات الوكيل الطويلة داخل نافذة السياق — كان الوكلاء الفرعيون يتضخمون حتى يرفضهم النموذج، أو يتوقفون مبكراً لتوفير المساحة، أو يخطئون في عدّ الرموز بالروسية. ثلاثة إصلاحات تُتم العمل الطويل.
• إبقاء المحادثة حية عندما ينام الهاتف — تنام الهواتف وتبدّل التطبيقات وتفقد الشبكة أثناء البناء. خطآن جعلا محادثة Mythex تتوقف، أو تعرض جزءاً فقط من الرد لاحقاً. كيف وجدناهما وأصلحناهما.
• كيف يمكن لمحادثة واحدة ثقيلة أن تُسقط واجهة البرمجة لدينا — في 28 سبتمبر نفدت الذاكرة في خادمي واجهة البرمجة معاً. كان الإصلاح الأول ذاكرة أكبر، أما الحقيقي فهو تحميل السجل بحسب الحجم لا العدد.
• الضغط على نشر مرتين أصبح ينشر مرة واحدة — وصلت ثلاثة طلبات نشر لتطبيق واحد بفارق 84 ملّي ثانية، وشغّل كل منها نشراً كاملاً. كيف جعلنا قاعدة البيانات هي من يقرر من ينشر، وأخبرنا الآخرين بالحقيقة.
• دروس في تحسين محركات البحث من إصلاح موقعنا — عناصر FAQ مكررة، والصورة الخاطئة في نتائج Google، وصفحات قوالب لم ينقر عليها أحد، ومسار رفضته حافتنا: ما وجدناه على mythex.ai وما أصلحناه.
• المواقع الثابتة تبقى متاحة أثناء إعادة نشرها — كانت إعادة نشر موقع ثابت تُفرغه قبل رفع البناء الجديد. الآن يبقى الموقع القديم متاحاً حتى يصبح الجديد في مكانه، وتظهر التغييرات خلال ثوانٍ.
• انهيار نفاد الذاكرة المختبئ في تسمية تقدم — نفدت الذاكرة لوكيلنا الذكي أثناء كتابة ملف كبير واحد. السبب لم يكن النموذج ولا الوكلاء الفرعيون المتوازون، بل تسمية حالة أُعيد إرسالها 41,000 مرة.
• ملف swap المفقود الذي جمّد خوادمنا — توقف خادم إنتاج عن الاستجابة دون أن ينهار: لا قتل بسبب نفاد الذاكرة، بل تخبط في ذاكرة التخزين المؤقت على جهاز بلا swap. ما الذي حدث وما الذي غيّرناه.
• إيقاظ قواعد البيانات دون اتصالات ميتة — تطبيق منشور يستيقظ من السكون احتفظ بأول طلب له 10 إلى 12 ثانية على اتصالات قاعدة بيانات ماتت أثناء نومه. كيف خفّضناه إلى 2.3 ثانية.
• كنا نحدّ من معدل طلبات خدماتنا نفسها — حد المعدل لكل عنوان في واجهتنا البرمجية عامل خدماتنا كشخص واحد مشغول، فبدأت تتلقى ردود 429 في الإنتاج. كيف وجدنا ذلك وأصلحناه.
• لماذا نقلنا خوادم Mythex إلى ARM — بعد نقل العمل الثقيل إلى بيئات معزولة لكل مشروع، لم تعد خوادمنا تستخدم سوى ثلث ذاكرتها. خوادم ARM الأصغر خفّضت التكلفة بنحو 30%. كيف فعلنا ذلك.
• كيف وصلنا إلى نشر بلا أي خطأ 502 — مراقب ذاتي يتسابق مع نشراتنا وموازن حمل يلاحظ متأخراً: كيف وجدنا كليهما وأصلحناهما، وقسنا النشر من 10 أخطاء 502 إلى صفر.