Mühendislik

Mühendislik

Mythex nasıl geliştiriliyor ve işletiliyor; neyin bozulduğu ve nasıl düzelttiğimiz dahil.

• Başarısız Bir Yeniden Yayın, Çalışan Bir Arka Ucu Asla Silmez — Başarısız bir yeniden yayın, uygulamanın canlı API'sini silebilir ya da bozuk sürümünü çalışır bırakabilir. Mythex'in hatalı yayınları geri alma biçimindeki üç düzeltme.
• Sunucu Başına Değil, Bir Kez Tetiklenen Uyarılar — Bir uyarı bir öğleden sonra beş kez geldi. Bellek içi tekilleştirme iki sunucuda ve dağıtımlarda neden bozulur, paylaşılan durum bunu nasıl düzeltti.
• Kimseyi Beklettirmeden Daha Büyük Çalışma Alanlarına Geçiş — Çalışma alanlarının dörtte biri 2 GB'a geçmedi. İlk düzeltmemiz bir kişiyi yedi dakika bekletti. Neyi değiştirdik ve neden yeniden değiştirdik.
• Veritabanlarını Gerçekte Kullandıkları Kadar Faturalandırmak — Her uygulamanın veritabanı maliyetini tahmin ediyorduk ve tahmin iki yönde de yanlıştı. Artık her veritabanı, saat saat ölçülen kullanımdan faturalandırılıyor.
• Yayınlandıktan Hemen Sonra Çöken Uygulamaları Yakalamak — Üç yayın, API'leri her açılışta birkaç saniye içinde çöktüğü hâlde sağlık kontrolünden geçti. Neden: çökmeleri en fazla beş girdi tutan bir listede saymak.
• Görsel Yoğun Agent Turlarını Bellek İçinde Tutmak — Katalog taramalarını inceleyen bir agent turu 952 MB’da bellek taşmasıyla çöktü. Görselleri çok uzun tutan üç ayrı neden vardı ve üçünü de düzelttik.
• Uzun Agent Turlarını Bağlam Penceresi İçinde Tutmak — Alt agentlerimiz modelin reddedene kadar büyüyor, yer kalmadığını sanıp erken duruyor ya da Rusça token sayısını yanlış hesaplıyordu. Üç düzeltme.
• Telefon Uyuduğunda Sohbeti Canlı Tutmak — Telefonlar uyur, sekme değiştirir ve ağı kaybeder. Sohbeti takılı bırakan ya da yarım yanıt gösteren iki hatayı nasıl bulup düzelttik.
• Tek Bir Ağır Sohbet API’mizi Nasıl Çökertebilirdi — 28 Eylül’de iki API sunucumuz aynı anda bellekleri tükendi. İlk düzeltme daha fazla bellek oldu; asıl düzeltme sohbet geçmişini sayıya değil boyuta göre yüklemekti.
• Publish’e İki Kez Basmak Artık Tek Yayınlıyor — Aynı uygulama için üç yayın isteği 84 ms arayla geldi ve her biri tam dağıtım çalıştırdı. Kilidi veritabanına nasıl verdik ve diğerlerine gerçeği nasıl söyledik.
• Kendi Sitemizi Düzeltirken Öğrendiğimiz SEO Dersleri — Çift SSS işaretlemesi, yanlış küçük resim, tıklanmayan şablon sayfaları ve kenar sunucusunun engellediği bir yol: mythex.ai'de bulup düzelttiklerimiz.
• Statik Siteler Artık Yeniden Yayınlanırken de Ayakta Kalıyor — Statik siteyi yeniden yayınlamak artık siteyi boşaltmaz. Yeni derleme yerine oturana kadar eski site sunulur ve değişiklikler saniyeler içinde görünür.
• Bir İlerleme Etiketinde Gizli Bellek Taşması Çökmesi — Yapay zeka agent'ımız büyük bir dosyayı yazarken bellek tükendi. Sebep model ya da paralel alt agent'lar değildi; 41.000 kez yeniden gönderilen bir durum etiketiydi.
• Sunucularımızı Donduran Eksik Takas Dosyası — Üretim sunucusu çökmeden yanıt vermeyi bıraktı: bellek kill'i yoktu, takassız makinede sayfa önbelleği sürekli yer değiştirdi. Ne oldu, neyi değiştirdik?
• Ölü Bağlantılar Olmadan Veritabanlarını Uyandırmak — Uykudan uyanan yayınlanmış bir uygulama, uyku sırasında ölen veritabanı bağlantılarında ilk isteği 10-12 saniye tuttu. Bunu 2,3 saniyeye nasıl indirdik?
• Kendi Servislerimizi Kendimiz Sınırlıyorduk — API'mizin adres başına hız sınırı, kendi servislerimizi de meşgul bir kişi gibi ele alıyordu ve üretimde 429 almaya başladılar. Bunu nasıl bulduk ve nasıl düzelttik?
• Mythex'in Sunucularını Neden ARM'e Taşıdık? — Ağır işler sandbox'lara taşındıktan sonra sunucularımız belleğinin üçte birini kullanıyordu. Daha küçük ARM makineleri sunucu faturasını yaklaşık %30 düşürdü.
• Dağıtımları Sıfır 502 Hatasına Nasıl İndirdik — Dağıtımlarımızla yarışan bir bekçi ve çok geç fark eden bir yük dengeleyici: ikisini nasıl bulduk, düzelttik ve dağıtımları 10 adet 502'den sıfıra indirdiğimizi nasıl ölçtük.