хотим запускать гипотезы в продакшн за часа, но при этом уметь быстро откатиться. Обсуждаем архитектуру фич-флагов, хранение флагов, rollout по % пользователей, Canary vs dark-launch, как тестировать флаги и как избегать технического долга.
Автоматизация: CI проверяет, что нет «stale flags» в ветке перед merge. Метрики и alert на p50/p95 и error rate при rollout — обязательно.
Внутри команды держите короткие описания флагов: что включает, почему, как проверить
Не делайте секретный выпуск через флаги без проверки прав доступа. Флаг может открыть небезопасный функционал для внешнего мира.
Для маркетинга делайте эксперименты только с контролем каналов - не смешивайте несколько тестов на один сегмент
Фич-флаги - это не просто переключатели. Надо делить на типы: экспериментальные (A/B), операционные (on/off для безопасности), постоянные (product toggles). Храните конфиг отдельно от кода, используйте versioning и audit-log. Rollout - сначала internal → 1% → 10% → 50% → 100% с мониторингом. Anti-pattern - оставлять флаги навсегда. План удаления флага должен быть частью задачи.
Не храните флаги только в памяти - используйте центральный store с кешем (Redis) и fallback. Проверьте latency и разрешите локальные overrides для debug.
Feature flag + healthcheck = must. Если фича падает - автоматический откат.
Удаляйте флаги как только гипотеза принята/отклонена. 