Agent karar verir, Playwright tarayıcıyı çalıştırır; ancak ortam katmanı çoğu zaman gözden kaçar. Uzun süre çalışan veri toplama görevlerinde hatalar genellikle bu katmanda yoğunlaşır.
Bir Agent framework tarayıcıyı veri toplamak için yönettiğinde mimari genellikle üç katmandan oluşur: Agent planlama ve karar vermeyi üstlenir, Playwright tıklama, giriş ve veri çıkarma işlerini yürütür, akışın sonunda da hedef siteyle etkileşim kurulur. Kısa görevler çoğu zaman sorunsuz çalışır ve yerel testleri de geçer. Ancak çalışma süresi uzadıkça ve görev sayısı arttıkça, hatalar yeterince ciddiye alınmayan bir yerde, yani tarayıcı ortamında yoğunlaşmaya başlar.
Pratikte karşılaşılan sorunlara bakıldığında, ortam katmanındaki hatalar kabaca üç biçimde görülür.
Ortam anormal kabul edilir ve tüm pipeline durur
Bir durumda platform doğrudan ortamın kendisine müdahale eder. Bu çoğu zaman açık bir engelleme şeklinde değil, bir bozulma şeklinde görülür: sadeleştirilmiş sayfalar, boş sonuçlar veya doğrulama talepleri. Script hata vermez, ancak dönen veriler artık anlamlı değildir. Sonraki adımlar normal şekilde çalışmaya devam eder ve sorunlu veri en son tabloya kadar taşınır.
Zorluk, bu tür ortamların çoğu zaman birden fazla görev tarafından paylaşılmasıdır. Bir ortam sorun yaşadığında, ona bağlı tüm görevler durabilir. Yeniden denemek de çözüm olmaz çünkü asıl neden script içinde değildir.
Birkaç görev aynı ortamı paylaşınca oturum durumları birbirine karışır
Görevler aynı browser instance içinde eşzamanlı çalışırsa Cookie, localStorage ve IndexedDB birbirinin verilerini ezebilir ve giriş durumlarını değiştirebilir. Kısa sürede fark edilmeyebilir, ancak birkaç gün sonra açıklanması zor yeniden giriş istekleri görülebilir.
Daha gizli bir drift de vardır. Uzun süre çalışan bir tarayıcıda cache, storage ve hatta WebGL rendering state zaman içinde yavaş yavaş değişir. Aynı ortam bugün ve üç gün sonra farklı özellikler gösterebilir. Çoğu zaman Cookie süresinin dolduğu sanılır, oysa aslında ortamın kendisi artık önceki ortam değildir. Bu nedenle ortamları kalıcı ve yeniden kullanılabilir nesneler olarak yönetmek, her seferinde yeni bir tarayıcı başlatmaktan daha verimlidir.
Checkpoint'ten devam ederken eski ortam artık kullanılamaz durumda olabilir
Veri toplama görevleri nadiren tek çalıştırmada tamamlanır. Kesintiden sonra checkpoint'ten devam etmek yaygındır, ancak burada emek kolayca boşa gidebilir: script yeniden başlatılırken yeni bir browser instance oluşturulabilir ve giriş durumu kaybolabilir; ya da eski ortam kullanılmaya devam edilir fakat platform onu zaten işaretlemiştir, dolayısıyla devam etmek yalnızca kaynak tüketir.
Buradaki asıl konu yeniden deneme sayısı değil, kurtarmanın granülerliğidir. Görevin hangi adımda olduğu, hangi verilerin zaten alındığı ve hangi ortamın kullanıldığı script dışında kaydedilmiyorsa, yeniden başlatıldığında baştan başlamak gerekir.
Ortam katmanında neler yapılabilir
Bu üç sorunu birlikte ele alınca yaklaşım üç temel fikre indirgenebilir.
Ortamları göreve göre gruplayın. Her göreve kendi ortam grubu verilmeli, birden fazla görev aynı instance içine sıkıştırılmamalıdır. Gruplamadan sonra her görev için ayrı network egress, time zone ve language ayarlanabilir. Bu parametreleri birbiriyle uyumlu bir set olarak tutmak, tek tek elle ayarlamaktan daha güvenilirdir. Bu mimaride PurpleMark ortam katmanında yer alır: browser environment'ları toplu olarak oluşturur, her birini bağımsız bir network egress ile eşler ve API üzerinden task-orchestration katmanına planlama için aktarır.
Hataları izole edin. Bir ortam anormal olarak değerlendirilirse yalnızca ona bağlı görevler etkilenmelidir. Yaygın yöntem, her ortam için bir health status tutmak, bunu düzenli olarak kontrol etmek ve sorun bulunduğunda ortamı devreden çıkarıp yedek bir ortamla değiştirmektir. Üst katman script'lerinin aynı bozuk ortamı tekrar tekrar denemesine izin verilmez. Böylece sorunun ortamdan mı yoksa sayfa yapısındaki bir değişiklikten mi kaynaklandığı da daha net anlaşılır.
Durumu kurtarılabilir hale getirin. İlerleme, deduplication fingerprint'leri ve ortam kimlikleri script dışında kalıcı olarak saklanmalıdır. Yeniden başlatmada önce bu kayıtlar okunur, ardından nereden devam edileceğine ve hangi ortamın kullanılacağına karar verilir. Görevi discovery, loading ve extraction gibi aşamalara bölmek ve her aşamada hataları ayrı ele almak, tek bir hatanın tüm çalıştırmayı boşa çıkarmasını önler. Kaynaklar da izlenmelidir: uzun süre çalışan instance'larda memory leak, donmuş sayfalar ve connection timeout görülebilir, bu nedenle geçersiz session'lar düzenli olarak recycle edilmelidir.
Net tutulması gereken sınırlar
Ortamın kararlı olması ile veri toplamaya izin verilmesi farklı konulardır. Önce hedef sitenin robots kuralları ve hizmet şartları incelenmelidir; birçok site otomatik erişimi açıkça sınırlar. Request rate, karşı tarafın hizmetini etkilemeyecek düzeyde tutulmalı; kişisel bilgi toplanmamalı; teknik koruma önlemleriyle karşılaşıldığında bunları aşmaya çalışmak yerine strateji değiştirilmeli veya izin alınmalıdır. Teknik kararlılık, uyumluluk değerlendirmesinin yerini tutmaz.
Bu içerik yalnızca teknik araştırma ve geliştirme pratiği paylaşımı içindir. Hedef sitenin koşullarına ve bulunduğunuz yerde geçerli yasalara uyun.
