Иностранный государственный реестр сертификации ничего вам не должен. Сегодня он отдаёт данные, завтра меняет URL, закрывает публичный список, ставит геоблокировку, обновляет формат или банит все ваши машины разом — и предупреждать никто не будет. У внутренней аналитической платформы выбор простой: либо устойчивый парсер на очередях, с ротацией прокси и инкрементальной сборкой, либо аналитика по этому реестру встаёт через неделю, и узнаёте вы об этом по тишине в логах.
Сводка
| Отрасль конечного клиента | Сертификация продукции, B2B-аналитика рынка |
| Конечный клиент | «Аналитика сертификатов» — внутренняя платформа группы компаний |
| Формат сотрудничества | Регулярное сопровождение — поток заказов по мере появления новых реестров и изменения старых источников |
| Тип проекта | Длительная серия работ по парсингу иностранных государственных реестров сертификации (Киргизия, Казахстан, Беларусь) |
| Объём работ | Девять заказов по парсингу, плюс поддержка существующих парсеров и панель управления сбором |
| Дата проекта | ноябрь 2022 — продолжается, больше трёх лет активной работы |
| Трудозатраты | около 260 часов по согласованным сметам; фактический объём выше за счёт мелких доработок без отдельной сметы |
| Команда | Антон Херсун (руководитель проекта; принял парсинг как легаси, разобрал и перевёл на современную архитектуру руками сам), затем передал разработчику виджетов и парсеров, который ведёт направление с тех пор |
| Технологический стек | Laravel 5.5.50 · Laravel Horizon · очереди и задания · Redis · Docker · ClickHouse · собственная система ротации HTTPS-прокси со случайными User-Agent |
| Сдано | Парсеры трёх национальных реестров (KG/KZ/BY), панель управления сбором, автоматическая инкрементальная сборка по расписанию и по требованию |
Постановка задачи
Платформа работает с государственными реестрами сертификации соответствия продукции: публичные данные о выданных декларациях и сертификатах. Источники находятся на государственных сайтах Киргизии, Казахстана и Беларуси, параллельно идёт сбор по российскому реестру. Полноценного публичного API нет ни у одного. Где-то API с авторизацией по токену неизвестного времени жизни, где-то только веб-интерфейс с порядковым перебором номеров, где-то источник регулярно меняет структуру ответа или вовсе закрывает публичный доступ.
У клиента уже работал старый парсер, написанный до нас. Часть работала, часть нет, и понять, где именно падало, было невозможно: логов почти не было, сбор по Казахстану держался «на коленке» и при каждом бане его нагоняли вручную. Антон сел за исходники, разобрался, что сохранять и что переписывать, и постепенно перевёл всё на единую архитектуру: задания Laravel, очереди под Horizon, собственная ротация прокси. Только после этого передал направление коллеге.
Заказчик ставил последовательные заказы по мере появления новых источников или изменения старых:
- ноябрь 2022: ферма парсинга из трёх серверов, обход блокировок Казахстана, автоматический перепарсинг
- начало 2024: парсинг киргизских деклараций перебором после закрытия публичного реестра, затем сертификаты КГ по матрице вероятностей стран
- 2024: переписанный белорусский реестр, доработки парсера KZ
- 2025: панель управления сбором и подключение общего реестра ЕАЭС, переход на новый казахстанский реестр через API
- конец 2025: буферная таблица для документов без номера, доработка полей KZ, акты идентификации
Что в этом сложного. Источник меняется без предупреждения, и каждое изменение стоит платформе данных. Киргизия закрыла публичный список — пришлось переходить на перебор номеров. ФСА в пятницу вечером забанил все парсер-машины разом; за выходные систему переписали в несколько потоков через прокси и догнали стопроцентную актуальность месяца. Казахстан переехал на новый реестр с токенной авторизацией, и старый парсер по веб-странице больше не работал. Беларусь ввела геоблокировку, под которую попал даже белорусский прокси. Российский реестр выставил лимит в 20 страниц на запрос. И так каждый год. Поэтому архитектуру с самого начала строили под смену источника: способ получения данных может меняться сколько угодно, а схема хранения и накопленные данные остаются.
Как мы это сделали
1. Парсер не cron-скрипт, а очередь Laravel под Horizon.
Bash с cron отвергли сразу: нет retry, нет мониторинга, нельзя запустить сбор конкретного органа по запросу. Собственная job-система на Python тоже отпала — дубль уже существующего Laravel-стека. Логику сбора вынесли в задания Laravel; поверх работает Horizon как менеджер очередей, под ним Redis. Очередь даёт перезапуск при падении воркера, постановку парсера конкретного органа по требованию, не дожидаясь расписания, и общую панель Horizon вместо разрозненного мониторинга. Новый парсер — это один новый job-класс.
2. Инкрементальность через «следующий ожидаемый номер», а не пересканирование диапазона.
Структура номера киргизской декларации фиксирована: ЕАЭС KG417/049.Д.0006245, где KG417/049.Д. задаёт статический код органа сертификации, а 0006245 отсчитывает порядковый номер с шагом 1. Сканировать весь диапазон каждый день незачем: по каждому органу храним последний собранный номер и проверяем только следующие 10–20 значений, величина шага настраиваемая. Число запросов к источнику падает на два порядка — а с ним и риск бана. Если у органа случается разрыв нумерации или меняется формат, в панели можно вручную задать номер для старта перебора.
3. Сертификаты: перебор по номеру и по стране.
С декларациями всё линейно, а у сертификатов КГ в номер зашит код страны производства (ЕАЭС KG417/044.CN.02.02191, где CN обозначает Китай), и его не вычислить по порядку. Поэтому по каждому из 28 органов считаем отдельную матрицу вероятностей стран и сортируем от самой частой к редкой. От последнего известного номера парсер пробегает страны по матрице; если не нашёл, увеличивает номер на единицу и повторяет — до десяти раз. До конца списка стран дело доходит редко, так что лишних запросов почти нет. Часть органов ведёт номера неаккуратно: то точка, то слеш, то пропадает пробел после KG. Таких собираем в общем порядке без матрицы, а мусорные документы отбраковываем.
4. Собственная система ротации HTTPS-прокси со случайными User-Agent.
Сторонние прокси-сервисы отвергли: дорого, зависимость от поставщика и нестабильность на российских источниках. Сделали внутреннюю систему: пул HTTPS-прокси с проверкой работоспособности, случайный прокси на каждый запрос, временное исключение «токсичных» (получивших 403 или 429), периодическая ротация User-Agent. Эту систему переиспользуют все парсеры KG, KZ, BY. Когда в конце 2023-го ФСА забанил все машины, именно на ней за выходные подняли схему из четырёх машин по два потока через прокси и вернули полную актуальность декабря. Когда позже понадобилась авторизация через прокси для нового казахстанского API — система подхватила без правок.
5. Адаптация под смену API без переписывания приёмника.
Казахстан перешёл на новый реестр с API techreg.gov.kz/Synergy/rest/api/ и авторизацией по токену в заголовке. Доступ оказался защищён слабо: публичные документы отдавались при простой проверке роли. Этим мы и воспользовались: объём работ оценили в 50 часов. Поля нового источника легли в существующую таблицу базы без миграции схемы; обёртка задания осталась прежней, менялся только источник внутри. На старте сбор по 46 источникам прошёл за десяток секунд, в очередь встало около 32 тысяч документов. Старый парсер KZ работал параллельно — дедупликация не давала задвоить документы. А вот отладка нового источника растянулась на несколько месяцев: путаница БИН и кода ОКПО (различали по длине строки), дубли, форматы дат, поля НПА.
6. Отложенная обработка документов без номера (14 ч).
Бывает, что документ опубликован в реестре, а поле номера пустое: номер появляется через несколько часов или дней. Сохранять такой документ без номера нельзя — потом его не связать с реальной декларацией. Сделали буферную таблицу: документ без номера лежит до 5 дней с проверкой каждые 12 часов; если за 5 дней номер не появился, переносим в основную таблицу с пометкой. Требование неочевидное, но для качества данных критичное.
7. Пропуск уже собранных номеров при переборе.
Эту тонкость заметили уже в эксплуатации: дубликат считался «ненайденным» документом, и десять дублей подряд ошибочно обрывали перебор. Логику поправили: если номер уже есть в базе, поиск по нему не запускаем и сразу переходим к следующему, а счётчик «пустых» на уже известных документах не растёт.
Результаты
| Метрика | Значение |
|---|---|
| Объём работ по согласованным сметам | около 260 часов |
| Реестры в эксплуатации | 3 страны (KG, KZ, BY), параллельно — российский реестр |
| Архитектурный стек парсеров | Laravel 5.5.50 · Horizon · Redis · Docker · ClickHouse · собственная ротация HTTPS-прокси |
| Эффект новой системы по КГ | +6400 сертификатов с 1 января 2025, 72.6% найдено через общий реестр ЕАЭС |
| Запуск нового KZ-реестра | 46 источников, ~32 тыс. документов в очереди на старте |
| Ритм сбора | по расписанию (от ежечасного до раз в несколько часов) плюс запуск по требованию |
| Календарь работ | ноябрь 2022 → продолжается, больше трёх лет |
Три национальных парсера, общая Laravel-обёртка над Horizon, буферная таблица для документов без номера и панель, где заказчик включает страны и органы. Никакой обвязки сверх этого нет. У каждого парсера своя логика получения данных: порядковый перебор номеров, перебор с матрицей стран, API с токеном, классический скрейпинг с прокси-ротацией. За три года ни один парсер не переписали с нуля — каждый дорос до сегодняшнего вида через цепочку заказов, на инфраструктуре предыдущих.
Процесс и хронология
| Этап | Период | Результат |
|---|---|---|
| Ферма парсинга и обход блокировок | ноябрь 2022 | три VPS, автоперепарсинг, мониторинг; парсинг полностью на стороне команды |
| Переход КГ на перебор номеров | начало 2024 | Декларации каждые 4 часа через 10 прокси (~7300 шт.); затем сертификаты по матрице стран, 28 органов |
| Разовые и расширения | 2024 | Разовый сбор по eokno.gov.kz; переписанный белорусский реестр (30 ч), доработки KZ |
| Панель управления и общий реестр ЕАЭС | первая половина 2025 | панель управления сбором, общий реестр как источник номеров |
| Новый KZ-источник через API | вторая половина 2025 | переход на API techreg.gov.kz с авторизацией по токену |
| Доработка качества данных | конец 2025 | поля KZ, буфер отложенных номеров, акты идентификации |
| Обход блокировок и лимитов | конец 2025 — 2026 | Беларусь ввела блокировку (обошли за два дня, досбор с 1 ноября); РФ-реестр ввёл лимит 20 страниц (перешли на почасовой сбор с добором) |
Все заказы соединены через общую базу и общую систему ротации прокси. Каждый новый заказ переиспользует инфраструктуру предыдущих.
Команда
- Антон Херсун, Xaver Pro, руководитель проекта, формализация ТЗ, архитектурные решения по парсерам. Парсинг разбирал руками сам: принял частично работающий легаси без единого подхода, изучил, переработал и перевёл на современную архитектуру — задания Laravel под Horizon, инкрементальный перебор номеров, собственная ротация прокси. Случай для нас редкий, когда руководитель проекта закрывает сборку руками, но без этого передавать кому-то спутанный легаси было нельзя.
- Разработчик виджетов и парсеров принял уже переработанное направление от Антона и ведёт его с тех пор. На нём парсеры KG/KZ/BY на новой архитектуре, панель управления сбором, переход на новый KZ-источник через API, буферная таблица отложенных номеров, акты идентификации. Преемственность внутри направления сохраняется: любой парсер, написанный год назад, дорабатывается тем же человеком.
Скриншоты и материалы
Будут добавлены отдельным проходом. Возможные кандидаты: интерфейс панели управления сбором (статистика по странам производства, флажок «активен для перебора», предполагаемый следующий номер), панель очередей, упрощённая схема архитектуры задания-парсера.
Если ваш парсер вчера встал и об этом узнали по тишине в логах, пришлите код. Скажем, где он течёт, какие куски стоит вынести в очередь и какой минимальный мониторинг ставить, чтобы тишина не повторилась. Смотрим бесплатно.