Запуск unblock.tilda.link
Проблема
В нашей инфраструктуре используются сервисы для защиты от нежелательного трафика
(loganalyzer → haproxy dashboard → haproxy agents).
Они эффективно блокируют ботов, парсеров и DDoS-агентов, но иногда в блокировки попадают и обычные пользователи.
Из-за этого возникали тикеты, а администраторам приходилось вручную снимать блокировки.
Задача
Нужно было разработать сервис, который позволит пользователям самостоятельно подтверждать, что они не бот, и автоматически снимать блокировку без участия администраторов.
Решение
Мы создали мини-сервис Tilda Unblock, который:
Как это работает
Результат
Проблема
В нашей инфраструктуре используются сервисы для защиты от нежелательного трафика
(loganalyzer → haproxy dashboard → haproxy agents).
Они эффективно блокируют ботов, парсеров и DDoS-агентов, но иногда в блокировки попадают и обычные пользователи.
Из-за этого возникали тикеты, а администраторам приходилось вручную снимать блокировки.
Задача
Нужно было разработать сервис, который позволит пользователям самостоятельно подтверждать, что они не бот, и автоматически снимать блокировку без участия администраторов.
Решение
Мы создали мини-сервис Tilda Unblock, который:
- Поддерживает 5 языков
- Работает с 3 провайдерами капч
- Определяет регион домена по DNS-записям и показывает локализованную капчу
Как это работает
- Пользователь попадает на страницу разблокировки. (https://unblock.tilda.link)
- Проходит капчу.
- При успешной проверке запускается таймер на 3 минуты для синхронизации разблокировки IP на всех балансировщиках HAProxy.
- После этого пользователь автоматически возвращается на исходный сайт.
Результат
- Автоматизирован процесс разблокировки
- Снижена нагрузка на администраторов
- Улучшен пользовательский опыт (UX)
Синхронизация данных на серверах geo
Проблема
У нас есть сервис, предоставляющий пользователям гео-данные населённых пунктов, улиц и домов разных стран.
Для обеспечения отказоустойчивости был создан второй сервис, полностью дублирующий функционал первого (копия приложения и базы данных Opensearch).
В случае сбоя первого сервиса всегда можно быстро переключить нагрузку на второй.
Однако база геосервиса постоянно обновляется — данные вносятся как из публичных справочников (ГАР), так и вручную.
Возникла потребность синхронизировать базы данных двух сервисов.
Задача
Обеспечить автоматическую синхронизацию данных между двумя независимыми БД Opensearch, несмотря на то, что встроенной мастер-слэйв репликации в Opensearch нет.
Решение
Мы разработали собственную схему синхронизации через внутренний Git-репозиторий.
Были реализованы следующие доработки:
вспомогательный сервис забирает обновления и применяет их к своей БД.
Как это работает
Результат
Проблема
У нас есть сервис, предоставляющий пользователям гео-данные населённых пунктов, улиц и домов разных стран.
Для обеспечения отказоустойчивости был создан второй сервис, полностью дублирующий функционал первого (копия приложения и базы данных Opensearch).
В случае сбоя первого сервиса всегда можно быстро переключить нагрузку на второй.
Однако база геосервиса постоянно обновляется — данные вносятся как из публичных справочников (ГАР), так и вручную.
Возникла потребность синхронизировать базы данных двух сервисов.
Задача
Обеспечить автоматическую синхронизацию данных между двумя независимыми БД Opensearch, несмотря на то, что встроенной мастер-слэйв репликации в Opensearch нет.
Решение
Мы разработали собственную схему синхронизации через внутренний Git-репозиторий.
Были реализованы следующие доработки:
- В базу данных добавлена временная метка последнего редактирования для каждого документа.
- Созданы shell/PHP cron-скрипты:
вспомогательный сервис забирает обновления и применяет их к своей БД.
Как это работает
- Пользователь или автоматическая система обновляет данные в мастер-сервисе.
- Изменения фиксируются во внутреннем Git-репозитории.
- Вспомогательный сервис периодически проверяет репозиторий и подтягивает новые данные.
- Его база данных обновляется синхронно с мастер-сервисом.
Результат
- Обеспечена синхронизация данных между двумя независимыми сервисами.
- Повышена отказоустойчивость геосервиса.
- Реализован удобный и прозрачный механизм обновления без необходимости ручной поддержки.
[stat] Исправили логику определения источника трафика
Проблема
У нас есть сервис статистики, который в том числе агрегирует данные по источникам переходов на сайт.
Для определения источника использовалась сложная внутренняя логика, основанная на анализе:
Внутри приложения были зашиты списки соответствий для социальных сетей, поисковых систем, рекламных источников и других сервисов.
Такая реализация усложняла поддержку и ограничивала актуальность данных.
Задача
Упростить поддержку логики определения источников трафика и повысить точность статистики.
Решение
Мы провели рефакторинг приложения:
Результат
Проблема
У нас есть сервис статистики, который в том числе агрегирует данные по источникам переходов на сайт.
Для определения источника использовалась сложная внутренняя логика, основанная на анализе:
- реферера,
- utm-меток,
- user-agent.
Внутри приложения были зашиты списки соответствий для социальных сетей, поисковых систем, рекламных источников и других сервисов.
Такая реализация усложняла поддержку и ограничивала актуальность данных.
Задача
Упростить поддержку логики определения источников трафика и повысить точность статистики.
Решение
Мы провели рефакторинг приложения:
- списки соответствий вынесли в конфигурационные файлы;
- добавили поддержку параметра utm_source;
- расширили логику — теперь фиксируются переходы из приложений Telegram, WhatsApp, VK Client и других.
Результат
- Статистика стала точнее и актуальнее.
- Поддержка списков сервисов стала проще и удобнее.
- Появилась возможность гибко расширять логику за счёт обновления конфигов, без доработки кода.
