Расписание и алерты в парсинге: как превратить сбор данных в процесс

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

Частота запуска

Частота зависит от бизнес-ценности изменения:

Слишком частый сбор увеличивает стоимость и нагрузку. Слишком редкий — делает данные запоздалыми.

Окна сбора

Иногда важна не только частота, но и время:

• до начала рабочего дня;
• перед обновлением цен;
• после публикации тендеров;
• вечером для сводки;
• в тихие часы, чтобы не мешать источнику.

Окна сбора помогают синхронизировать данные с рабочим процессом команды.

Ретраи

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

Пример политики:

1-я ошибка: повтор через 10 минут
2-я ошибка: повтор через 30 минут
3-я ошибка: алерт ответственному

Что отправлять в алерт

Алерт должен быть коротким:

• что случилось;
• источник;
• объект;
• старое значение;
• новое значение;
• ссылка;
• время;
• приоритет.

Плохой алерт: “ошибка парсинга”.

Хороший алерт: “Источник example.ru вернул 0 товаров вместо обычных 1200, третий сбой подряд, нужна проверка”.

Webhooks

Webhook нужен, когда результат должен запустить следующий шаг:

• создать задачу в CRM;
• обновить BI;
• отправить сообщение в Telegram;
• записать результат в базу;
• запустить переоценку;
• уведомить менеджера.

История запусков

Храните:

• статус;
• время начала и завершения;
• количество строк;
• ошибки;
• предупреждения;
• ссылку на результат;
• версию схемы.

История превращает парсинг из “скрипт упал” в управляемый процесс.

Итог

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