Bir Agent web görevi yürütürken hatalar çoğunlukla dört alanda ortaya çıkar: öğe konumlandırma, bekleme ve zaman aşımı, durumun kalıcılaştırılması ve ortam kaynaklı engellemeler. Adımları idempotent yapmak, uygun hataları yeniden denemek, durumu kalıcılaştırmak ve ortamı görev bazında izole etmek başarı oranını çok daha istikrarlı hale getirir.
Web otomasyonuna ilk başlandığında yaklaşım genellikle basit görünür: akışı tanımla ve scripti çalıştır. Mantık doğru görünse de görevler yine de aralıklı olarak başarısız olur ve hesap durumlarında zaman zaman anormallikler görülür. İlk tepki kodu incelemektir, ancak ayrıntılı araştırmada sorunlar genellikle dört noktada toplanır.
Sayfa değişince öğe konumlandırma bozulur
Çoğu script öğeleri selector ile bulur. Bir selector sabit biçimde yazıldığında sayfadaki neredeyse her değişiklik onu geçersiz kılabilir: bir butonun class adı değişir, metindeki tek bir kelime değiştirilir, bir bölüm sunucu tarafı render'dan asenkron yüklemeye geçer veya öğe yeni bir container içine alınır. Bir A/B testinde aynı sayfa farklı hesaplara farklı yapılar bile gösterebilir.
Tipik belirtiler öğenin bulunamaması, tıklamanın yanlış yere gitmesi veya aynı isimli fakat farklı konumdaki bir kontrolün tıklanmasıdır. Bu tür hata ağ dalgalanmasından kaynaklanmaz; birkaç kez yeniden denemek de çözmez.
Uygulanabilir yaklaşım mutlak yollara daha az bağımlı olmaktır. Erişilebilirlik niteliklerini, kararlı iş ID'lerini veya öğeler arasındaki göreli ilişkileri tercih edin; aynı sayfa türü için alternatif selector'lar hazırlayın ve ana selector başarısız olduğunda otomatik geri dönüş yapın. Sayfada iframe veya Shadow DOM varsa önce doğru bağlama geçilmelidir, aksi halde öğe bulma başarısız olur.
Bekleme ve zaman aşımı aralığı yanlış ayarlanmıştır
Bekleme süresi çok kısaysa öğe render edilmeden başarısız sayılabilir ve bu bir script hatası gibi görünür. Çok uzunsa tek bir görevin süresi gereksiz yere büyür, throughput düşer ve uzun zaman aşımları gerçek hatayı gizleyebilir.
Sabit sleep yerine açık koşullu beklemeler daha güvenilirdir: hedef öğenin görünmesi, bir isteğin dönmesi veya yükleme animasyonunun kaybolması gibi belirli bir koşulu bekleyin. Zaman aşımı bütçeleri katmanlı olmalı; tek adım, tek sayfa ve tüm görev için ayrı sınırlar tanımlanmalı ve her yerde aynı değer kullanılmak yerine kademeli olarak daraltılmalıdır.
Ayrıca sayfanın kullanılabilir hale gelmesini beklemek ile iş sonucunun oluşmasını beklemek birbirinden ayrılmalıdır. İlkinde DOM'un hazır olması genellikle yeterlidir; ikincisinde API callback'i veya sayfadaki durum metninin değişmesi gerekebilir. Yanlış sinyali beklemek, veriler hiç yazılmamış olsa bile işlemi başarılı gösterir.
Çok adımlı görev yarıda kalınca ilerleme kaybolur
Kayıt, sipariş ve yayınlama gibi görevler kolayca ondan fazla adıma ulaşabilir. Süreç zaman aşımı, tarayıcı çökmesi veya ana makinenin yeniden başlatılması nedeniyle yarıda çıkarsa ve durum yalnızca bellekte tutuluyorsa bir sonraki çalıştırma ya baştan başlar ya da önceki adımı yeniden gönderir.
Çift çalıştırmanın sonucu basit bir hatadan daha zor teşhis edilebilir: aynı işlem iki kez yapılır, üst sistemde fazladan bir kayıt oluşur ve kaynağını bulmak zorlaşır.
Çözüm, her adım için bir kalıcılık noktası oluşturmaktır. Her adım tamamlandığında ilerlemeyi görevin benzersiz kimliğiyle birlikte kalıcı bir konuma yazın; yeniden başlatmadan sonra son başarılı noktadan devam edin. Bunun için karmaşık bir framework gerekmez; tek bir dosya veya durum kaydı yeterlidir.
Ortam kaynaklı engelleme kod hatası gibi görünür
İlk üç sorun görev içindedir, ancak başka bir sınıf ortamdan gelir. Bir site trafiğin kaynağını değerlendirmek için tarayıcı özelliklerini, erişim davranışını ve ağ kaynağını birlikte kullanabilir. Erişimi şüpheli bulursa doğrulama sayfası, boş içerik veya doğrudan zaman aşımı döndürebilir. Görev loglarında bu durum bir çalıştırma hatasıyla neredeyse aynı görünür.
Yaygın tetikleyiciler şunlardır:
- Çıkış IP'sinin konumu, saat dilimi ve dil birbiriyle uyumlu değildir
- Tüm görevler aynı tarayıcı ortamından istek gönderir ve birim zamandaki istek yoğunluğu gerçek kullanıcılardan belirgin biçimde yüksektir
- Ortam sık sık değişir veya hesap tekrar tekrar yeniden giriş yapar
Başarı oranını yükselten dört uygulama
- Her adımı idempotent yapın. Çalıştırmadan önce ön koşulun zaten karşılanıp karşılanmadığını kontrol edin; böylece aynı eylemin tekrar edilmesi ek yan etki üretmez. Okuma işlemleri doğal olarak idempotenttir; yazma işlemleri benzersiz kimlik veya deduplikasyon anahtarıyla korunmalıdır.
- Hataları sınıflandırın. Henüz render edilmemiş öğe, ağ dalgalanması veya API'nin 5xx döndürmesi gibi geçici hatalar backoff ile yeniden denenebilir. Hesap kısıtlaması, geçersiz parametre veya bulunmayan hedef kaynak gibi deterministik hatalar kaç kez denense de değişmez; concurrency kapasitesini sürekli tüketmemeleri için sonlandırılmalıdır.
- Durumu düzenli olarak kalıcılaştırın. İlerlemeyi, ara çıktıları ve mevcut adımı kaydedin; böylece görev yeniden başlatıldığında ilk adıma dönmek yerine kaldığı yerden devam eder.
- Çalışma ortamını görev bazında izole edin. Her hesap veya görev ayrı bir tarayıcı ortamına sahip olsun; Cookies ve yerel depolama paylaşılmasın, fingerprint özellikleri makul biçimde farklı olsun ve saat dilimi ile dil çıkış IP'sinin bölgesiyle uyumlu kalsın.
Dördüncü uygulama görev ölçeği büyüdüğünde özellikle önem kazanır. Onlarca veya yüzlerce görev paralel çalışırken ortam katmanı kararlılığın üst sınırını ve bir sorun olduğunda etki alanının ne kadar geniş olacağını belirler. PurpleMark bu tür senaryolarda izole ortamları ihtiyaç halinde oluşturma ve toplu olarak geri alma olanağı sağlar; her hesap kendi ortamına sahip olur ve görev durumları birbirini kirletmez.
Bu içerik yalnızca teknik araştırma ve geliştirme uygulamalarını paylaşma amacıyla sunulmuştur. İlgili teknolojileri yasalara ve kurallara uygun biçimde kullanın ve hedef platformun hizmet şartlarına uyun.
