Браузерный робот для тысяч записей на чужих меняющихся сайтах

На сотой форме внимание уже не такое, как на первой

Во внешнем веб-портале нужно открыть кабинет, заполнить десяток полей, дождаться проверки, загрузить документ и перенести ответ обратно. Решения здесь почти нет: одни и те же действия повторяются для каждой записи.

Одна форма занимает несколько минут. Когда профилей тысячи, а документов десятки тысяч, ручная работа растягивается на месяцы. К концу длинной очереди появляются опечатки, пропущенные поля и расхождения между системами. Нанимать человека только для копирования данных между окнами браузера означало бы масштабировать саму рутину.

Мы передали этот маршрут управляемому браузеру на Python и Playwright. Данные подаются один раз, робот заходит на внешний сайт, заполняет форму, получает результат и возвращает статус. Одна запись и тысяча проходят один сценарий, но за большим объёмом не сидит оператор, который вручную нажимает "дальше".

Один запрос проходит без человека у экрана

Запрос приходит через интерфейс заказчика. До запуска браузера система проверяет обязательные поля, форматы и даты: незаполненную или явно неверную запись нет смысла отправлять на чужой портал.

После проверки задача попадает в очередь Celery и Redis. Воркеры забирают задания по мере готовности и исполняют их в фоне. Пользователю не нужно держать страницу открытой или наблюдать за каждым шагом; он передаёт данные и получает результат.

Очередь отделяет входящий поток от скорости внешних площадок. Если портал отвечает медленно, задания ждут своей обработки, не занимая рабочее место и не блокируя приём следующих записей. Замедление внешнего сервиса не приводит к потере записи: она остаётся в очереди до запуска. Робот может идти пачками, ночью и без перерывов, подстраиваясь под темп сервиса, который мы не контролируем.

Самый простой шаг - заполнить известные поля

Описание ровного сценария выглядит коротко: открыть страницу, найти поле, ввести значение, нажать кнопку, прочитать ответ. Проблема начинается после отправки формы.

Чужой сайт может долго дорисовывать страницу, показать неожиданное окно, вернуть ошибку, ничего не вернуть или изменить структуру интерфейса без предупреждения. Два соседних запроса иногда получают разные ответы, хотя робот выполняет одинаковые действия.

Поэтому сценарий описывает не только счастливый путь. Для каждого ожидаемого состояния задаётся реакция: дождаться элемента, извлечь нужный результат, распознать известную ошибку, повторить временный сбой или остановить задачу для разбора. Перед выходом на большой объём эти ветки проверяются множеством прогонов.

Живой внешний сайт всё равно способен показать вариант, которого раньше не было. Цель системы не в обещании "никогда не падает", а в том, чтобы единичный нестандартный ответ не потерял задачу и не остановил остальные записи.

Временный сбой получает три попытки

Если прогон не завершился, задача запускается повторно. После второго сбоя робот пробует третий раз. Это закрывает временные проблемы: страница не успела загрузиться, сервис на минуту завис или ответ пришёл с задержкой. Чаще всего второй или третий запуск проходит без вмешательства, потому что к этому моменту внешняя площадка снова отвечает нормально.

До ручного разбора доходит редко. Но именно этот выход не даёт автоматизации превратить ошибку в молчаливую потерю записи: задача не исчезает и не висит в очереди бесконечно.

Каждый прогон сохраняется целиком. Команда открывает его историю и видит, на каком шаге, поле и состоянии страницы остановился робот. Следующее исправление опирается на запись реального сбоя, а не на попытку воспроизвести проблему по пересказу пользователя.

Исход прогона	Действие системы	Кто подключается
Успешный ответ	Сохраняет результат и возвращает статус	Никто
Временная ошибка	Повторяет тот же сценарий до трёх попыток	Никто
Устойчивый или новый сбой	Сохраняет прогон и отправляет на разбор	Специалист
Изменившаяся страница	По записи обновляется сломавшийся шаг	Разработчик сценария

Если площадка перестроила страницу, сценарий обычно адаптируется в пределах одного дня. Запись показывает место поломки, поэтому не приходится переписывать всю систему или гадать, где изменился интерфейс.

Новый портал получает свой сценарий, но не новую платформу

Браузерная рутина состоит из повторяющихся операций: создать запись, обновить данные, приложить документ, получить результат, синхронизировать статус, разобрать расхождение. Эти операции работают поверх общей основы с очередью, проверкой данных, повторами и записью прогонов.

Для следующей площадки описывается её последовательность страниц и полей. Срок зависит от сложности сценария: простую площадку с несколькими предсказуемыми экранами робот осваивает за несколько дней. Общую обработку задач и возврат результата строить заново не требуется.

Подход применим там, где ручную работу можно разложить на устойчивые шаги. Если процесс требует профессионального решения на каждом экране, робот не должен изображать человека: спорный случай остаётся за специалистом.

Пять тысяч профилей показывают разницу лучше демонстрации

Решение прошло через живой поток примерно из 5000 профилей и десятков тысяч документов с сопроводительными данными, не останавливая основной процесс. Потоки разных заказчиков при этом изолированы и не смешиваются.

Обновить и проверить один профиль вручную занимает около трёх минут. Загрузить документ вместе со статусом - ещё две-три. На всём объёме это более 2000 человеко-часов: больше года одного оператора или несколько месяцев небольшой команды.

Робот тратит на одну операцию не мгновение: внешний сайт всё равно задаёт скорость. Профиль обрабатывается примерно за две минуты, документ - примерно за одну. Выигрыш появляется за счёт фоновой работы, параллельного потока, отсутствия перерывов и одинакового внимания к первой и тысячной записи. Весь объём закрывается за считанные дни.

Операция	Вручную	Роботом
Обновить и проверить профиль	Около 3 минут	Около 2 минут
Загрузить документ со статусом	Около 2-3 минут	Около 1 минуты

Разница видна не на одной операции, а на всём объёме:

Оператор перестаёт переносить данные между окнами и подключается там, где нужен разбор нового ответа, спорного результата или изменившегося сайта.

Чувствительные данные разделены между заказчиками

В обработке находятся персональные данные, поэтому потоки имеют отдельные области видимости. Каждый заказчик получает доступ только к своим записям, а данные разных проектов не смешиваются.

Система также не хранит лишнее. В задачу и запись прогона попадает информация, которая нужна для конкретного сценария и последующего разбора. Заказчику не показывают внутреннюю очередь и технические повторы: его интерфейс остаётся намеренно простым - отправить данные и получить результат. Наблюдение за ходом прогонов остаётся внутренней работой команды.

Чужой сайт остаётся чужим

Сценарий нужно сопровождать, потому что владелец портала может изменить страницу без согласования. Такая адаптация заложена в эксплуатацию, а не считается неожиданным дефектом робота.

Робот также не гарантирует доступность внешнего сервиса. Очередь и повторы переживают временный сбой, но не могут заставить чужую площадку ответить или сохранить прежнюю разметку. После устойчивой ошибки решение всё равно принимает человек.

Граница проекта поэтому ясна: машина исполняет формализованную браузерную рутину, одинаково обрабатывает большой объём и оставляет подробный след. Человек остаётся там, где внешний сайт изменил правила или ответ нельзя интерпретировать заранее заданным способом.