În sarcinile web executate de un Agent, erorile apar frecvent în patru zone: localizarea elementelor, așteptări și timeout-uri, persistarea stării și blocaje ale mediului. Pașii idempotenți, reîncercările selective, starea persistentă și izolarea mediului pe sarcină stabilizează mult rata de succes.
La începutul automatizării web, abordarea pare de obicei simplă: definești fluxul și pornești scriptul. Logica pare corectă, dar sarcinile continuă să eșueze sporadic, iar starea conturilor devine uneori anormală. Primul instinct este să verifici codul, însă o analiză mai atentă arată de regulă că problemele se concentrează în patru zone.
O modificare a paginii invalidează localizarea
Majoritatea scripturilor găsesc elemente cu ajutorul selectorilor. Când un selector este fixat rigid, aproape orice schimbare a paginii îl poate rupe: un buton primește alt nume de clasă, se schimbă un cuvânt din text, o secțiune trece de la randare pe server la încărcare asincronă sau un element este introdus într-un container nou. Într-un test A/B, aceeași pagină poate avea chiar structuri diferite pentru conturi diferite.
Simptomele obișnuite sunt un element care nu poate fi găsit, un clic care ajunge în locul greșit sau activarea unui control cu același nume, dar aflat în altă poziție. Acest tip de eroare nu este o fluctuație de rețea și nu dispare după câteva reîncercări.
O abordare practică este să depinzi mai puțin de căi absolute. Folosește cu prioritate atribute de accesibilitate, ID-uri de business stabile sau relații relative între elemente; pregătește selectori alternativi pentru același tip de pagină, astfel încât sistemul să poată comuta automat dacă selectorul principal eșuează. Dacă pagina conține un iframe sau Shadow DOM, trebuie mai întâi schimbat contextul corect, altfel localizarea va eșua.
Așteptările și timeout-urile sunt stabilite greșit
Dacă așteptarea este prea scurtă, elementul poate fi declarat eșuat înainte de a termina randarea, ceea ce pare un bug de script. Dacă este prea lungă, durata unei singure sarcini crește inutil, debitul scade, iar timeout-urile lungi pot ascunde eroarea reală.
Așteptările explicite sunt mai fiabile decât un sleep fix: așteaptă o condiție concretă, cum ar fi apariția elementului țintă, răspunsul unei cereri sau dispariția animației de încărcare. Bugetele de timeout trebuie stabilite pe niveluri, separat pentru un pas, o pagină și întreaga sarcină, apoi restrânse progresiv în loc să se folosească aceeași valoare peste tot.
Trebuie diferențiată și așteptarea până când pagina devine utilizabilă de așteptarea până când rezultatul de business este produs. Pentru prima situație, de obicei este suficient ca DOM-ul să fie gata; pentru a doua poate fi necesar un callback API sau o modificare a textului de stare din pagină. Așteptarea semnalului greșit poate face ca operațiunea să pară reușită, deși datele nu au fost scrise.
Progresul se pierde la jumătatea unei sarcini cu mai mulți pași
Sarcini precum înregistrarea, plasarea unei comenzi sau publicarea pot ajunge ușor la peste zece pași. Dacă procesul se închide la jumătate din cauza unui timeout, a unui crash al browserului sau a repornirii gazdei, iar starea există doar în memorie, următoarea rulare trebuie fie să înceapă de la zero, fie să retrimită pasul anterior.
Efectele unei execuții duplicate pot fi mai greu de diagnosticat decât un simplu eșec: aceeași operațiune rulează de două ori, sistemul din amonte primește o înregistrare în plus, iar sursa este greu de urmărit.
Soluția este ca fiecare pas să aibă un punct de persistență. După fiecare pas finalizat, scrie progresul într-o zonă persistentă împreună cu identificatorul unic al sarcinii; după repornire, continuă de la ultimul punct reușit. Nu este nevoie de un framework complex: un fișier sau o singură înregistrare de stare este suficientă.
Blocarea la nivelul mediului arată ca o eroare de cod
Primele trei categorii apar în interiorul sarcinii, dar o alta vine din mediu. Un site poate combina caracteristicile browserului, comportamentul de acces și originea rețelei pentru a evalua sursa traficului. Dacă îl consideră suspect, poate returna o pagină de verificare, conținut gol sau pur și simplu un timeout. În logurile sarcinii, acest lucru poate arăta aproape identic cu o eroare de execuție.
Declanșatori obișnuiți includ:
- Locația IP-ului de ieșire, fusul orar și limba nu sunt aliniate
- Toate sarcinile trimit cereri din același mediu de browser, iar densitatea cererilor pe unitate de timp este clar mai mare decât la utilizatorii reali
- Mediul se schimbă frecvent sau contul se autentifică din nou în mod repetat
Patru măsuri care cresc rata de succes
- Fă fiecare pas idempotent. Înainte de execuție, verifică dacă precondiția este deja îndeplinită, astfel încât repetarea acțiunii să nu producă efecte secundare suplimentare. Operațiunile de citire sunt idempotente în mod natural; cele de scriere au nevoie de un identificator unic sau de o cheie de deduplicare.
- Clasifică eșecurile. Cele temporare, precum un element încă nerandat, fluctuații de rețea sau un API care întoarce 5xx, pot fi reîncercate cu backoff. Cele deterministe, precum un cont restricționat, parametri nevalizi sau o resursă țintă inexistentă, nu se vor îmbunătăți cu mai multe încercări; marchează-le ca terminate pentru a nu ocupa constant capacitatea de concurență.
- Persistă starea periodic. Salvează progresul, rezultatele intermediare și pasul curent, astfel încât după repornire sarcina să continue de unde s-a oprit, nu de la primul pas.
- Izolează mediul de rulare pe sarcină. Fiecare cont sau sarcină trebuie să aibă propriul mediu de browser, fără a partaja Cookies și stocarea locală, cu caracteristici de fingerprint diferențiate rezonabil și cu fusul orar și limba aliniate regiunii IP-ului de ieșire.
A patra măsură devine deosebit de importantă pe măsură ce crește volumul sarcinilor. Când zeci sau sute de sarcini rulează în paralel, stratul de mediu stabilește limita superioară a stabilității și determină cât de mare este aria de impact atunci când apare o problemă. În astfel de scenarii, PurpleMark oferă posibilitatea de a crea medii izolate la cerere și de a le recupera în lot, fiecare cont având propriul mediu, astfel încât stările sarcinilor să nu se contamineze între ele.
Acest conținut este destinat exclusiv cercetării tehnice și schimbului de practici de dezvoltare. Folosiți tehnologiile relevante legal și conform cerințelor aplicabile și respectați termenii de utilizare ai platformei țintă.
