Заповнення форм на зовнішніх вебпорталах для тисяч записів забирало в співробітників місяці ручної роботи - близько 3 хвилин на профіль і 2-3 хвилини на документ, понад 2000 людино-годин на потік із ~5000 профілів і десятків тисяч документів - і накопичувало помилки до кінця черги.
Браузерний робот на Python і Playwright працює поверх фонової черги задач: заповнює форми у фоні, автоматично повторює тимчасові збої до трьох спроб і зберігає повний запис кожного прогону, передаючи фахівцю лише стійкі або нові помилки.
Потік приблизно з 5000 профілів і десятків тисяч документів закрився за лічені дні замість місяців ручної роботи, а оператор підключається лише до розбору спірних випадків і сайтів, що змінилися.
На сотій формі увага вже не така, як на першій
У зовнішньому вебпорталі потрібно відкрити кабінет, заповнити десяток полів, дочекатися перевірки, завантажити документ і перенести відповідь назад. Рішення тут майже немає: одні й ті самі дії повторюються для кожного запису.
Одна форма займає кілька хвилин. Коли профілів тисячі, а документів десятки тисяч, ручна робота розтягується на місяці. Наприкінці довгої черги з'являються описки, пропущені поля й розбіжності між системами. Наймати людину лише для копіювання даних між вікнами браузера означало б масштабувати саму рутину.
Ми передали цей маршрут керованому браузеру на Python і Playwright. Дані подаються один раз, робот заходить на зовнішній сайт, заповнює форму, отримує результат і повертає статус. Один запис і тисяча проходять один сценарій, але за великим обсягом не сидить оператор, який вручну натискає "далі".
Один запит проходить без людини біля екрана
Запит надходить через інтерфейс замовника. До запуску браузера система перевіряє обов'язкові поля, формати й дати: незаповнений або явно хибний запис немає сенсу надсилати на чужий портал.
Після перевірки завдання потрапляє в чергу Celery і Redis. Воркери забирають завдання в міру готовності й виконують їх у фоні. Користувачеві не потрібно тримати сторінку відкритою чи стежити за кожним кроком; він передає дані й отримує результат.
Черга відділяє вхідний потік від швидкості зовнішніх майданчиків. Якщо портал відповідає повільно, завдання чекають своєї обробки, не займаючи робоче місце й не блокуючи приймання наступних записів. Уповільнення зовнішнього сервісу не призводить до втрати запису: він лишається в черзі до запуску. Робот може йти пачками, вночі й без перерв, підлаштовуючись під темп сервісу, який ми не контролюємо.
Найпростіший крок - заповнити відомі поля
Опис рівного сценарію виглядає коротко: відкрити сторінку, знайти поле, ввести значення, натиснути кнопку, прочитати відповідь. Проблема починається після надсилання форми.
Чужий сайт може довго домальовувати сторінку, показати несподіване вікно, повернути помилку, нічого не повернути або змінити структуру інтерфейсу без попередження. Два сусідні запити іноді отримують різні відповіді, хоча робот виконує однакові дії.
Тому сценарій описує не лише щасливий шлях. Для кожного очікуваного стану задається реакція: дочекатися елемента, витягнути потрібний результат, розпізнати відому помилку, повторити тимчасовий збій або зупинити завдання для розбору. Перед виходом на великий обсяг ці гілки перевіряються безліччю прогонів.
Живий зовнішній сайт усе одно здатний показати варіант, якого раніше не було. Мета системи не в обіцянці "ніколи не падає", а в тому, щоб поодинока нестандартна відповідь не втратила завдання й не зупинила решту записів.
Тимчасовий збій отримує три спроби
Якщо прогін не завершився, завдання запускається повторно. Після другого збою робот пробує третій раз. Це закриває тимчасові проблеми: сторінка не встигла завантажитися, сервіс на хвилину завис або відповідь надійшла із затримкою. Найчастіше другий чи третій запуск проходить без втручання, бо на цей момент зовнішній майданчик знову відповідає нормально.
До ручного розбору доходить рідко. Але саме цей вихід не дає автоматизації перетворити помилку на мовчазну втрату запису: завдання не зникає й не висить у черзі нескінченно.
Кожен прогін зберігається цілком. Команда відкриває його історію й бачить, на якому кроці, полі та стані сторінки зупинився робот. Наступне виправлення спирається на запис реального збою, а не на спробу відтворити проблему з переказу користувача.
| Результат прогону | Дія системи | Хто підключається |
|---|---|---|
| Успішна відповідь | Зберігає результат і повертає статус | Ніхто |
| Тимчасова помилка | Повторює той самий сценарій до трьох спроб | Ніхто |
| Стійкий або новий збій | Зберігає прогін і надсилає на розбір | Спеціаліст |
| Змінена сторінка | За записом оновлюється зламаний крок | Розробник сценарію |
Якщо майданчик перебудував сторінку, сценарій зазвичай адаптується протягом одного дня. Запис показує місце поломки, тому не доводиться переписувати всю систему чи вгадувати, де змінився інтерфейс.
Новий портал отримує свій сценарій, але не нову платформу
Браузерна рутина складається з повторюваних операцій: створити запис, оновити дані, прикласти документ, отримати результат, синхронізувати статус, розібрати розбіжність. Ці операції працюють поверх спільної основи з чергою, перевіркою даних, повторами й записом прогонів.
Для наступного майданчика описується його послідовність сторінок і полів. Термін залежить від складності сценарію: простий майданчик з кількома передбачуваними екранами робот освоює за кілька днів. Загальну обробку завдань і повернення результату будувати заново не потрібно.
Підхід застосовний там, де ручну роботу можна розкласти на стійкі кроки. Якщо процес вимагає фахового рішення на кожному екрані, робот не має вдавати людину: спірний випадок лишається за спеціалістом.
П'ять тисяч профілів показують різницю краще за демонстрацію
Рішення пройшло через живий потік приблизно з 5000 профілів і десятків тисяч документів із супровідними даними, не зупиняючи основний процес. Потоки різних замовників при цьому ізольовані й не змішуються.
Оновити й перевірити один профіль вручну займає близько трьох хвилин. Завантажити документ разом зі статусом - ще дві-три. На всьому обсязі це понад 2000 людино-годин: більше року одного оператора або кілька місяців невеликої команди.
Робот витрачає на одну операцію не мить: зовнішній сайт усе одно задає швидкість. Профіль обробляється приблизно за дві хвилини, документ - приблизно за одну. Виграш з'являється завдяки фоновій роботі, паралельному потоку, відсутності перерв і однаковій увазі до першого й тисячного запису. Увесь обсяг закривається за лічені дні.
| Операція | Вручну | Роботом |
|---|---|---|
| Оновити й перевірити профіль | Близько 3 хвилин | Близько 2 хвилин |
| Завантажити документ зі статусом | Близько 2-3 хвилин | Близько 1 хвилини |
Різницю видно не на одній операції, а на всьому обсязі:
Оператор перестає переносити дані між вікнами й підключається там, де потрібен розбір нової відповіді, спірного результату або зміненого сайту.
Чутливі дані розділені між замовниками
В обробці перебувають персональні дані, тому потоки мають окремі області видимості. Кожен замовник отримує доступ лише до своїх записів, а дані різних проєктів не змішуються.
Система також не зберігає зайвого. У завдання й запис прогону потрапляє інформація, яка потрібна для конкретного сценарію та подальшого розбору. Замовнику не показують внутрішню чергу й технічні повтори: його інтерфейс лишається навмисно простим - надіслати дані й отримати результат. Спостереження за ходом прогонів лишається внутрішньою роботою команди.
Чужий сайт лишається чужим
Сценарій потрібно супроводжувати, бо власник порталу може змінити сторінку без узгодження. Така адаптація закладена в експлуатацію, а не вважається несподіваним дефектом робота.
Підхід розрахований на майданчики без капчі й антибот-захисту. Якщо сайт вимагає довести, що перед ним людина, коректна автоматизація не має обіцяти обхід цього обмеження.
Робот також не гарантує доступність зовнішнього сервісу. Черга й повтори переживають тимчасовий збій, але не можуть змусити чужий майданчик відповісти чи зберегти попередню розмітку. Після стійкої помилки рішення все одно ухвалює людина.
Межа проєкту тому ясна: машина виконує формалізовану браузерну рутину, однаково обробляє великий обсяг і лишає докладний слід. Людина лишається там, де зовнішній сайт змінив правила або відповідь не можна витлумачити наперед заданим способом.
Олександр
Це реальний проєкт, поданий знеособлено. Впізнавані деталі - галузь, конкретику, усе, за чим можна визначити замовника, - ми навмисно змінюємо; ім'я та комерційні таємниці замовника не розкриваємо. Незмінною лишається суть: яке завдання розв'язували і яким інженерним підходом. Кейс написано, щоб показати проблему та її вирішення - що і як ми робимо.