Situație inițială: departamentul de achiziții monitorizează zilnic noile licitații pe 6 platforme electronice de tranzacționare (ETP). În prezent, acest lucru se face manual într-un browser cu filtre, motiv pentru care unele achiziții relevante sunt ratate, iar datele de la diferite ETP-uri nu sunt aduse într-o singură formă. Mediu tehnic și limitări: server Linux (Ubuntu 22.04), acces prin SSH. Permis să utilizeze Python 3.11, Playwright sau Selenium, solicitări/httpx, PostgreSQL 14 (baza de date există deja). Docker este posibil, dar nu este necesar. Nu puteți utiliza servicii anti-captcha plătite și nu puteți stoca acreditările din conturile personale în text clar. Acces la ETP doar ca invitat, fără autorizație. Unele site-uri încarcă conținut cu JavaScript, au protecție anti-bot și limitează frecvența solicitărilor. Domeniul subiect: licitații/achiziții. Este necesar să colectați carduri de achiziție și loturi, să normalizați categoriile și sumele și să salvați un istoric al modificărilor. Ce ar trebui să se întâmple: un parser autonom care colectează date într-un program de la 6 ETP-uri specificate (voi furniza o listă de domenii și exemple de link-uri către rezultatele căutării), le aduce la o schemă comună și le adaugă la PostgreSQL și, de asemenea, trimite notificări către Telegram când apar noi achiziții relevante. Etape și cerințe cheie: 1) Analiza surselor - pentru fiecare ETP, determinați metoda de încărcare (XHR/GraphQL/HTML/JS-render), punctele de intrare pentru emitere și carduri, un set de câmpuri, limite de viteză. 2) Implementarea asamblatorului - module adaptoare separate pentru fiecare sursă cu o singură interfață. Trebuie acceptate reluări, backoff-uri, timeout-uri, limitarea concurenței, rotația User-Agent, lucrul printr-un proxy (voi furniza un proxy) și rezistența la eșecurile parțiale. 3) Normalizarea datelor - un singur model în baza de date: achiziție, lot, client, regiune, date (publicare/sfârșit), NMC/monedă, stare, link, site, descriere text, CPV/OKPD2 (dacă există), precum și un câmp de relevanță calculat pentru cuvintele cheie și cuvintele de excludere (voi oferi o listă). Reduceți sumele la numere, datele la UTC, eliminați reclamele duplicate între ETP-uri folosind un set de euristici (NUM-ul clientului + suma + datele + asemănarea numelui). 4) Stocare istorică - atunci când starea sau data de încheiere se schimbă, ar trebui să fie înregistrată o nouă intrare în tabelul istoric cu un marcaj de timp și câmpuri modificate. 5) Notificări - Telegram bot trimite un mesaj despre noile achiziții relevante, nu mai mult de 1 notificare per achiziție, cu câmpuri scurte și un link. Comanda /health returnează, de asemenea, statistici ale ultimei rulări (cât a fost colectat de sursă, câte erori, timp). 6) Operare - lansare prin cron sau cronometru systemd, logare la un fișier, mesaje de eroare clare pentru fiecare sursă. Ieșire specifică: un depozit cu cod sursă, configurație (env/ini/yaml), migrări de schemă SQL, instrucțiuni pentru rularea pe Ubuntu și un exemplu de configurare a filtrului de relevanță. Criterii de acceptare măsurabile: - În timpul unui test de rulare, în decurs de 24 de ore, analizatorul colectează cel puțin 95% din anunțurile din rezultatele căutării pentru fiecare sursă în primele 3 pagini (verificat prin calcul manual pe un eșantion de 30 de anunțuri per sursă). - Duplicatele din baza de date nu depășesc 2% din numărul total de înregistrări per rulare (verificați folosind o cheie unică și euristica de deduplicare). - Lansarea repetată pe aceleași filtre nu creează noi înregistrări de achiziție dacă nu există modificări în surse, iar istoricul este actualizat doar atunci când câmpurile sunt modificate efectiv. - Timpul complet de rulare pentru toate sursele nu depășește 45 de minute pe un server de 2 vCPU/4 GB RAM, cu o limită de până la 3 sarcini paralele. - Jurnalele conțin statistici separate în funcție de sursă și coduri de motiv de eroare (timeout, blocare, analizare, structura schimbată). În plus: voi furniza o listă de ETP-uri, exemple de URL-uri, cuvinte cheie și acces la baza de date de testare după ce am convenit asupra abordării și structurii datelor.