Feature flags как микрополитика

Feature flag выглядит как самая безобидная вещь в кодовой базе. Логическое значение, переключатель, строчка в конфиге. Включено — пользователь видит новую кнопку. Выключено — не видит. Инженеры относятся к флагам как к гигиене: они позволяют выкатывать код, не выкатывая функциональность, гасить сбойную фичу за секунды, раскатывать изменение на один процент аудитории. Все это правда. Но за технической рутиной прячется кое-что большее.

01Решение, оформленное как настройка

Флаг — это решение о том, что и кому показать. У одних пользователей продукт один, у других — другой, и граница проходит не по случайности, а по чьему-то выбору. Этот выбор делается не на собрании и не в публичном документе. Он делается в интерфейсе для своих — в панели управления, куда имеют доступ несколько человек.

Назвать это «настройкой» — значит снять с решения его вес. Настройка звучит технически, нейтрально, обратимо. Но между «мы решили показать эту цену только этому сегменту» и «мы выставили флаг» нет разницы по существу — есть разница по тону. Второе звучит так, будто никто ничего не решал.

Чем удобнее инструмент, тем незаметнее выбор, который он оформляет.

02Микрополитика раската

Постепенный раскат — gradual rollout — обычно объясняют через риск: выкатим на 1%, посмотрим на метрики, если все хорошо, пойдем дальше. Это разумно. Но обратите внимание на то, что здесь происходит с пользователем. Он становится частью выборки, не зная об этом. Его опыт — это замер. Его поведение на новой версии — данные, на основании которых решат, увидят ли новую версию остальные.

Это не злоупотребление. Это нормальная инженерная практика, и я сам строил инструменты, которые ее обеспечивают. Но стоит назвать вещи своими именами: продукт постоянно проводит над своей аудиторией небольшие, незаметные эксперименты, и инфраструктура флагов — это то, что делает такие эксперименты дешевыми и рутинными.

03Власть, распределенная по коду

Самое интересное — где именно живет это решение. Оно не в голове менеджера и не в стратегии компании. Оно распределено: часть в коде, часть в конфигурации, часть в правах доступа к панели, часть в негласном соглашении о том, кто может трогать какие флаги. Власть здесь не сосредоточена — она размазана по инфраструктуре, и именно поэтому ее трудно увидеть.

Когда власть выглядит как инфраструктура, она перестает восприниматься как власть. Никто не отдает приказ — просто система так устроена. Это и есть микрополитика: не громкие решения, а тысячи мелких, технически оформленных выборов, которые в сумме определяют, каким продукт является для каждого конкретного человека.

04Зачем это инженеру

Можно сказать: ну и что, это просто работа, флаги полезны. Да. Я не предлагаю от них отказаться — это было бы абсурдно. Я предлагаю другое: видеть в флаге не только техническую абстракцию, но и слепок решения. Кто его принял. На каком основании. Кто об этом знает.

Инженер, который держит это в голове, проектирует иначе. Он спрашивает, кто получит доступ к панели и почему. Он документирует не только то, что флаг делает, но и то, зачем он введен. Он замечает, когда «временный» флаг живет второй год и тихо превращается в постоянную, никем не отрефлексированную политику продукта.

Это и есть мостик между инженерией и социальной теорией. Не в том, чтобы добавить к коду философию, а в том, чтобы увидеть: код уже содержит решения о власти и поведении. Вопрос только в том, замечаем мы их или нет.