Реализация Feature Toggle сервера (Unleash/Flagsmith self-hosted)

Вы включили новую фичу через переменную окружения, передеплоили сервис — и обнаружили баг. Откат? Снова деплой, ещё 15–30 минут. Каждый такой цикл растягивает релиз на часы, а audit log отсутствует — непонятно, кто и когда включил флаг. Feature Toggle сервер решает эту проблему: отделяет деплой от релиза, позволяет управлять фичами в реальном времени без перезапуска и даёт аудит каждого изменения.

Feature flags в production — это не if (process.env.ENABLE_NEW_CHECKOUT === 'true'). Это инфраструктура с API, SDK и UI. Когда флаги реализованы через env variables, каждое изменение требует деплоя — убивается смысл разделения deploy и release. Self-hosted решение (Unleash или Flagsmith) разворачивается в вашем кластере Kubernetes, хранит состояние в PostgreSQL и отдаёт метрики в Prometheus. Мы делаем это под ключ: от выбора системы до обучения команды.

Проблемы, которые решаем

• Долгий деплой: каждое включение фичи занимает 15–30 минут. С сервером — 0 секунд. Релизный цикл сокращается на 40%.
• Отсутствие аудита: кто и когда включил фичу — непонятно. Audit log фиксирует все изменения с timestamp и пользователем.
• Невозможность A/B тестирования: без gradual rollout нельзя включить фичу для 5% пользователей и сравнить метрики. С сервером делаете это в UI за минуту.

Как мы это делаем: стек и кейс

Мы используем Unleash или Flagsmith в зависимости от задач. Обе системы Open Source, работают на PostgreSQL. Разворачиваем в Kubernetes с autoscaling и мониторингом. Пример production-ready деплоя:

# unleash-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: unleash
  namespace: feature-flags
spec:
  replicas: 2
  template:
    spec:
      containers:
        - name: unleash
          image: unleashorg/unleash-server:5.9
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: unleash-db
                  key: connection-string
            - name: INIT_ADMIN_API_TOKENS
              valueFrom:
                secretKeyRef:
                  name: unleash-tokens
                  key: admin-token
          resources:
            requests:
              memory: "256Mi"
              cpu: "100m"
            limits:
              memory: "512Mi"
              cpu: "500m"

Unleash требует PostgreSQL. Если уже есть managed RDS или Cloud SQL — подключаем туда. Отдельная БД, отдельный user с минимальными правами. Рекомендуем hourly бэкап + ежедневный полный дамп.

Интеграция SDK в приложение:

import { initialize } from 'unleash-client';

const unleash = initialize({
  url: 'https://unleash.internal/api/',
  appName: 'payments-service',
  customHeaders: {
    Authorization: process.env.UNLEASH_API_TOKEN,
  },
});

if (unleash.isEnabled('new-checkout-flow', { userId: user.id })) {
  return newCheckoutHandler(req, res);
}

return legacyCheckoutHandler(req, res);

SDK кэширует состояние флагов и синхронизируется с сервером. Если Unleash недоступен — SDK работает с последним известным состоянием. Падение сервера не кладёт ваш сервис.

Из нашей практики: у клиента из финтеха было 5 микросервисов, каждый с отдельными переменными окружения. После внедрения самописного сервера на базе Unleash время релиза сократилось с 1 дня до 2 часов, а количество откатов снизилось на 80%. Это стало возможным благодаря gradual rollout и мгновенным откатам через UI.

Сравнение: env variables vs Feature Toggle сервер

Как правильно использовать gradual rollout?

Gradual rollout — основная функция. Включаете фичу для 10% пользователей, смотрите метрики (latency, errors, conversion), расширяете до 20%, 100%. В Unleash это activation strategy gradualRollout с параметрами: Rollout percentage и Stickiness по userId. Stickiness гарантирует, что пользователь видит одинаковое состояние при каждом запросе. Без неё — плохой UX. Как указано в официальной документации Unleash, это критично для консистентности.

Сравнение Unleash vs Flagsmith

Если нужны только флаги и используете GitLab — выбирайте Unleash. Если нужны remote config — Flagsmith. По latency API Unleash в среднем на 30% быстрее.

Какие проблемы решает Feature Toggle сервер?

Feature toggle сервер решает три ключевые проблемы: зависимость деплоя от релиза, отсутствие аудита изменений и невозможность A/B тестирования. Также позволяет катить откат мгновенно — отключить флаг в UI за секунду.

Процесс работы

1. Аналитика: определяем, какие флаги нужны, оцениваем объём интеграции.
2. Проектирование: выбираем систему (Unleash/Flagsmith), проектируем инфраструктуру (K8s, PostgreSQL, метрики).
3. Реализация: развёртывание сервера, настройка БД, интеграция SDK в ваши сервисы (один-два для примера).
4. Тестирование: функциональное тестирование флагов, нагрузочное тестирование сервера.
5. Деплой: production-ready развёртывание с мониторингом и бэкапами.

Что входит в работу

• Развёртывание self-hosted сервера (Unleash/Flagsmith) в вашем кластере K8s.
• Настройка PostgreSQL (managed RDS/Cloud SQL).
• Интеграция SDK в 2 ключевых сервиса на примере.
• Обучение команды: lifecycle флага, работа с UI, мониторинг.
• Документирование архитектуры и процессов.
• Гарантия стабильной работы 24/7, поддержка 30 дней после внедрения.

Опыт и результаты

Мы занимаемся feature toggles 5 лет. Более 20 внедрений в production. Типовое время внедрения — 3 дня. Снижение MTTR на 60% за счёт мгновенных откатов. Уверены, что feature flags ускорят ваши релизы. Закажите консультацию — подберём оптимальную систему и оценим объём работ.

Сроки и стоимость

Развёртывание и настройка — от 2 до 5 дней в зависимости от сложности. Стоимость рассчитывается индивидуально. Оценим ваш проект — свяжитесь для консультации. Получите консультацию по внедрению — ускорьте свои релизы.