Инженерная практика
Feature flags: выкатить тёмным, раскатать и вывести из эксплуатации
Читать про флаги — не то же самое, что прожить полный жизненный цикл. Соберите маленький сервис с флагами, выкатите фичу тёмной, раскатайте её sticky-процентом с готовым kill switch, затем сделайте то, что большинство команд пропускает — выведите флаг из эксплуатации и удалите его мёртвую ветку, доказывая каждый шаг.
Превратите ментальную модель юнита в воспроизводимый цикл: выкатить тёмным, раскатать sticky, включить kill switch по требованию и провести флаг через полный жизненный цикл до вывода из эксплуатации — чтобы дисциплина, предотвращающая flag debt, стала мышечной памятью.
Соберите маленький HTTP-сервис с минимальным слоем feature flags, выкатите одну фичу тёмной, проведите её через sticky percentage rollout с рабочим kill switch, затем пройдите полный жизненный цикл вывода из эксплуатации — доказывая разделение deploy/release, stickiness, fail-open вычисление и чистое удаление с доказательствами на каждом шаге.
- Лог/таблица раскатки, показывающая отданную долю на 1/5/25/100%, совпадающую с целью, плюс доказательство, что фиксированная выборка пользователей оставалась на одном варианте между запросами (доказывая stickiness, а не порозыгрышную случайность).
- Демонстрация kill switch: подсистема выключается за секунды после переключения, а принудительный сбой источника флагов показывает, что сервис всё ещё отдаёт по последнему известному конфигу, а не падает (fail-open проверен, а не предположен).
- Запись реестра флагов на каждый флаг с типом, владельцем и сроком/тикетом на удаление для release-флага.
- Diff (или PR), удаляющий release-флаг и его мёртвую ветку, с grep/поиском, показывающим ноль оставшихся ссылок, и закрытым тикетом на чистку — жизненный цикл завершён, а не оставлен на 100%.
- Добавьте слоистые/атрибутные правила targeting (plan == enterprise, betaOptIn == true, затем sticky-rollout) и продемонстрируйте приоритет first-match short-circuit на тест-кейсах.
- Добавьте детектор застойных флагов: скрипт, перечисляющий флаги, отдающие одно значение более ~30 дней, и пропускающий типизированные как постоянные ops/kill switch — ваш Piranha-lite.
- Добавьте CI-гейт, роняющий сборку, когда release-флаг просрочил срок или не имеет тикета на удаление, чтобы flag debt не накапливался молча.
- Добавьте авто-остановку по метрикам: подключите раскатку к чтению error rate и автоматически выключайте флаг, если шаг ramp пробивает порог, затем опишите, как это превращает откат из человеческого решения в гардрейл.
Это цикл, который вы прогоняете на каждом флаговом релизе: выкатить тёмным, чтобы deploy и release были разными событиями, раскатать sticky по стабильному хешу, чтобы пользователи не мигали, держать kill switch подключённым к локальному конфигу с безопасным дефолтом, чтобы источник флагов никогда не был жёсткой зависимостью, типизировать каждый флаг с владельцем и сроком, и завершить жизненный цикл, удалив release-флаг и его мёртвую ветку на 100%. Один проход end-to-end на игрушечном сервисе делает продовую дисциплину — ту самую, что спасла бы Knight Capital, — автоматической.