Запуск 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 и других.
Результат
- Статистика стала точнее и актуальнее.
- Поддержка списков сервисов стала проще и удобнее.
- Появилась возможность гибко расширять логику за счёт обновления конфигов, без доработки кода.
Обновления в сервисе мониторинга
Проблема:
При добавлении новых пингов для сервисов, имеющих несколько контуров (серверов), требуется вручную дублировать одинаковые задачи мониторинга для каждого контура. Это усложняет настройку, увеличивает вероятность ошибок и повышает трудозатраты на сопровождение.
Задача:
Реализовать механизм управления серверами в рамках одного сервиса, позволяющий:
Решение:
Добавлена форма редактирования списка серверов для каждого пункта меню.
Проблема:
При добавлении новых пингов для сервисов, имеющих несколько контуров (серверов), требуется вручную дублировать одинаковые задачи мониторинга для каждого контура. Это усложняет настройку, увеличивает вероятность ошибок и повышает трудозатраты на сопровождение.
Задача:
Реализовать механизм управления серверами в рамках одного сервиса, позволяющий:
- задавать единый пинг для группы серверов;
- управлять списком серверов (добавление/удаление);
- настраивать индивидуальные параметры мониторинга для каждого сервера;
- сохранить обратную совместимость с уже существующими задачами.
Решение:
Добавлена форма редактирования списка серверов для каждого пункта меню.
При создании новой/редактировании задачи табами добавлен выбор типа источника (Static url/Server group) с отображением серверов в группе.
Изменено отображение графиков с учетом нового функционала.
Добавлена возможность выставлять персональные настройки задачи для каждого сервера в группе.
Результат:
Снижено количества дублирующих задач мониторинга.
Упрощен процесс настройки и сопровождения сервисов с несколькими контурами.
Улучшена читаемость и наглядность мониторинга.
Сокращено время на добавление новых сервисов.
Снижено количества дублирующих задач мониторинга.
Упрощен процесс настройки и сопровождения сервисов с несколькими контурами.
Улучшена читаемость и наглядность мониторинга.
Сокращено время на добавление новых сервисов.
Функционал по управлению ддос защитой Cloudflare из нашей админки
Проблема:
При добавлении новых серверов haproxy приходится вручную определять правила перенаправления на них с сервиса ддос защиты Cloudflare.
Поддержка и сопровождение большого количества связей через интерфейс Cloudflare неудобны, занимают значительное время и повышают риск ошибок.
Задача:
Используя Cloudflare API, реализовать механизм управления правилами ддос защиты Cloudflare внутри нашего сервиса HAProxy dashboard.
Решение:
Добавлена форма заведения новых связей Cloudflare-haproxy.
Проблема:
При добавлении новых серверов haproxy приходится вручную определять правила перенаправления на них с сервиса ддос защиты Cloudflare.
Поддержка и сопровождение большого количества связей через интерфейс Cloudflare неудобны, занимают значительное время и повышают риск ошибок.
Задача:
Используя Cloudflare API, реализовать механизм управления правилами ддос защиты Cloudflare внутри нашего сервиса HAProxy dashboard.
Решение:
Добавлена форма заведения новых связей Cloudflare-haproxy.
Добавлены два информационных экрана, позволяющих изменять веса и приоритеты haproxy внутри системы ддос защиты.
Результат:
Существенно сокращено время подключения новых HAProxy-серверов.
Снижено количество ошибок за счёт автоматизации и централизованного управления.
Повышена прозрачность и управляемость балансировки трафика в условиях DDoS-защиты.
Существенно сокращено время подключения новых HAProxy-серверов.
Снижено количество ошибок за счёт автоматизации и централизованного управления.
Повышена прозрачность и управляемость балансировки трафика в условиях DDoS-защиты.
