Выбор оператора прокси неизмерим: прогон не связан с узлом, а история банов стирается успешной ротацией #3404

Open
opened 2026-09-06 09:19:51 +00:00 by lekss361 · 0 comments
Owner

Что не так

Мы выбираем оператора мобильного прокси (МегаФон / Tele2 / Билайн / МТС) по счётчику банов в scrape_proxy_source_bans. Обе опоры этого решения ненадёжны.

1. Прогон не связан с узлом. Колонка proxy_id есть только в scrape_proxy_source_bans и scrape_proxy_rotations. В scrape_runs её нет — то есть «через какой узел шёл прогон, который обогатил 5 карточек из 21» не выясняется ни одним запросом. Доля отказов по узлу, латентность по источнику, выгорание карточек на оператора — всё это сейчас не считается в принципе.

2. История банов стирается. clear_source_bans (proxy_pool.py:1078) делает DELETE FROM scrape_proxy_source_bans, а зовётся он после КАЖДОЙ успешной ротации exit-IP (proxy_rotation.py:469 и :601). У узла #540723 (МегаФон) 23 успешные ротации с 31.08 — и ноль строк банов. У #540722 (Tele2) ротаций почти не было — и 7 банов avito. Сравнение «7 против 0» читается как «Tele2 хуже МегаФона», хотя это в той же мере «у МегаФона историю стёрли 23 раза».

Замер 31.08 (research/Avito_Ip_Burnout_Operator_Matters_0831.md) сравнивал МегаФон с Билайном на стенде 39 карточек. По Tele2 контролируемого замера нет вообще — только этот счётчик.

Что сделать

  • scrape_runs.proxy_id — узел, через который шёл прогон (+ список узлов в counters, если за прогон была пересадка). Тогда исход прогона привязывается к оператору и гео.
  • clear_source_bans — гасить бан (banned_until = now(), ban_count = 0), а не удалять строку. Семантика эскалации сохраняется 1:1 (следующий бан снова стартует с базовых 6 ч), но строка доживает до штатного purge через SOURCE_BAN_PURGE_DAYS, и история пригодна для замера. Добавить cleared_at / cleared_reason, чтобы снятый бан отличался от истёкшего сам собой.

Зачем

Прямо сейчас на этих числах принимается решение о деньгах: какие порты mobileproxy пересаживать на другого оператора и сколько докупать. Аренда обоих живых портов (#540722, #540723) истекает 2026-09-30 10:26 одномоментно.

## Что не так Мы выбираем оператора мобильного прокси (МегаФон / Tele2 / Билайн / МТС) по счётчику банов в `scrape_proxy_source_bans`. Обе опоры этого решения ненадёжны. **1. Прогон не связан с узлом.** Колонка `proxy_id` есть только в `scrape_proxy_source_bans` и `scrape_proxy_rotations`. В `scrape_runs` её нет — то есть «через какой узел шёл прогон, который обогатил 5 карточек из 21» не выясняется ни одним запросом. Доля отказов по узлу, латентность по источнику, выгорание карточек на оператора — всё это сейчас не считается в принципе. **2. История банов стирается.** `clear_source_bans` (`proxy_pool.py:1078`) делает `DELETE FROM scrape_proxy_source_bans`, а зовётся он после КАЖДОЙ успешной ротации exit-IP (`proxy_rotation.py:469` и `:601`). У узла #540723 (МегаФон) 23 успешные ротации с 31.08 — и ноль строк банов. У #540722 (Tele2) ротаций почти не было — и 7 банов avito. Сравнение «7 против 0» читается как «Tele2 хуже МегаФона», хотя это в той же мере «у МегаФона историю стёрли 23 раза». Замер 31.08 (`research/Avito_Ip_Burnout_Operator_Matters_0831.md`) сравнивал МегаФон с Билайном на стенде 39 карточек. По Tele2 контролируемого замера нет вообще — только этот счётчик. ## Что сделать - `scrape_runs.proxy_id` — узел, через который шёл прогон (+ список узлов в `counters`, если за прогон была пересадка). Тогда исход прогона привязывается к оператору и гео. - `clear_source_bans` — гасить бан (`banned_until = now()`, `ban_count = 0`), а не удалять строку. Семантика эскалации сохраняется 1:1 (следующий бан снова стартует с базовых 6 ч), но строка доживает до штатного purge через `SOURCE_BAN_PURGE_DAYS`, и история пригодна для замера. Добавить `cleared_at` / `cleared_reason`, чтобы снятый бан отличался от истёкшего сам собой. ## Зачем Прямо сейчас на этих числах принимается решение о деньгах: какие порты mobileproxy пересаживать на другого оператора и сколько докупать. Аренда обоих живых портов (#540722, #540723) истекает 2026-09-30 10:26 одномоментно.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lekss361/gendesign#3404
No description provided.