مهندسی

مهندسی

Mythex چطور ساخته و اجرا می‌شود، از جمله آنچه خراب شد و چطور درستش کردیم.

• یک انتشار مجدد ناموفق هرگز بک‌اِند سالم را حذف نمی‌کند — یک انتشار مجدد ناموفق می‌توانست API زنده یک اپ را حذف کند یا نسخه خراب جدیدش را در حال اجرا نگه دارد. سه اصلاح در نحوه برگرداندن انتشاری که مشکل پیدا می‌کند.
• هشدارهایی که یک بار فعال می‌شوند، نه یک بار برای هر سرور — یک هشدار روزانه در یک بعدازظهر پنج بار به ما رسید. چرا حافظه‌ی محلی وقتی دو سرور و یک دیپلوی داریم خراب می‌شود، و چطور یک وضعیت مشترک مشکل را حل کرد.
• رفتن به فضای کاری بزرگ‌تر، بدون اینکه کسی را منتظر بگذاریم — یک‌چهارم فضای کاری‌ها پس از ارتقا به ۲ گیگابایت روی ۱ گیگابایت ماندند. اصلاح اول یک نفر را هفت دقیقه منتظر گذاشت. چه تغییر دادیم و دوباره چه تغییر دادیم.
• صورتحساب پایگاه‌داده بر اساس میزان واقعی استفاده — قبلاً هزینه‌ی پایگاه‌داده‌ی هر اپ را تخمین می‌زدیم، و تخمین از دو طرف اشتباه بود. حالا هر پایگاه‌داده بر اساس مصرف اندازه‌گیری‌شده، ساعت به ساعت، صورتحساب می‌شود.
• گرفتن اپ‌هایی که درست بعد از انتشار کرش می‌کنند — سه انتشار از بررسی سلامت ما گذشتند در حالی که API آن‌ها چند ثانیه بعد از هر بوت کرش می‌کرد. علت: شمردن کرش‌ها در فهرستی که فقط پنج مورد را نگه می‌دارد.
• نگه داشتن نوبت‌های پرتصویر عامل در محدوده‌ی حافظه — یک نوبت عامل که به اسکن‌های کاتالوگ نگاه می‌کرد در ۹۵۲ مگابایت از حافظه تمام شد. سه علت جداگانه که هر کدام تصاویر را بیش از حد نگه می‌داشتند، و نحوه‌ی رفعشان.
• نگه داشتن نوبت‌های طولانی عامل در پنجره‌ی متن — زیرعامل‌ها آن‌قدر بزرگ می‌شدند که مدل رد می‌کرد، زود متوقف می‌شدند و توکن‌های روسی را غلط می‌شمردند. سه رفعی که کار طولانی عامل را تمام کرد.
• زنده نگه داشتن چت وقتی گوشی به خواب می‌رود — گوشی‌ها به خواب می‌روند و شبکه عوض می‌کنند. دو باگ باعث می‌شد چت Mythex متوقف شود یا فقط نیمی از پاسخ را نشان دهد. نحوه‌ی پیدا کردن و رفع هر دو.
• چطور یک چت سنگین می‌توانست API ما را از کار بیندازد — در ۲۸ سپتامبر هر دو سرور API ما همزمان از حافظه تمام شدند. اولین رفع حافظه‌ی بیشتر بود؛ رفع واقعی بارگذاری تاریخچه‌ی چت بر اساس حجم بود، نه تعداد.
• فشردن دوباره‌ی Publish حالا فقط یک بار منتشر می‌کند — سه درخواست انتشار برای یک برنامه با فاصله‌ی ۸۴ میلی‌ثانیه رسیدند و هر کدام یک استقرار کامل راه انداختند. چطور پایگاه داده را تصمیم‌گیرنده کردیم و به بقیه حقیقت را گفتیم.
• درس‌های سئو از اصلاح سایت خودمان — برچسب FAQ تکراری، تصویر اشتباه در گوگل، صفحات قالبی که کلیک نمی‌گرفتند و مسیری که لبه‌مان رد می‌کرد: آنچه در mythex.ai پیدا و درست کردیم.
• سایت‌های استاتیک حالا هنگام انتشار مجدد هم بالا می‌مانند — انتشار مجدد سایت استاتیک قبلاً سایت زنده را خالی می‌کرد. حالا سایت قدیمی تا جایگزینی کامل سرو می‌شود و تغییرات در چند ثانیه دیده می‌شوند.
• خطای کمبود حافظه‌ای که پشت یک برچسب پیشرفت پنهان بود — عامل هوش مصنوعی ما هنگام نوشتن یک فایل بزرگ کمبود حافظه داشت. علت نه مدل بود و نه زیرعامل‌های موازی — یک برچسب وضعیت بود که ۴۱٬۰۰۰ بار دوباره ارسال شد.
• فایل swap که نبود و سرورهای ما را فلج کرد — یک سرور production پاسخ نمی‌داد، بدون کرش یا کشته شدن برای حافظه؛ فقط thrash در page cache روی ماشینی بدون swap. ماجرا و تغییرات.
• بیدار کردن پایگاه‌داده‌ها بدون اتصال‌های مرده — اپ منتشرشده‌ی بیدارشده، اولین درخواستش را ۱۰ تا ۱۲ ثانیه روی اتصال‌های پایگاه‌داده‌ی مرده نگه می‌داشت. ما آن را به ۲٫۳ ثانیه رساندیم.
• خودمان سرویس‌های خودمان را محدود می‌کردیم — محدودیت نرخ هر آدرس در API ما، سرویس‌های خودمان را مثل یک کاربر پرمشغله حساب می‌کرد و در production آن‌ها خطای 429 گرفتند. نحوه‌ی پیدا کردن و رفع آن.
• چرا سرورهای Mythex را به ARM بردیم — وقتی کارهای سنگین به ساندباکس‌ها منتقل شدند، سرورهای اصلی یک‌سوم حافظه‌شان را مصرف می‌کردند. نمونه‌های ARM حدود ۳۰٪ هزینه را کم کردند.
• چطور استقرارها را به صفر خطای ۵۰۲ رساندیم — یک watchdog که با استقرار رقابت می‌کرد و load balancerی که دیر متوجه شد: چطور پیدا و رفع کردیم و استقرارها را از ۱۰ خطای ۵۰۲ به صفر رساندیم.