Я думаю, все и так достаточно рассосали падение Гугла, поэтому давайте расскажу в нескольких постах подробнее про feature flag’и, и какие у них есть полезности.
Из очевидного - безопасность сервиса. Представьте себе мечту
Если в релизный цикл попадет баг, и нужно будет откатиться, то вы откатите не только свое изменение, но и другие (а там могли быть критические фиксы!), и будете делать это долго: плохие экземпляры потуши, старые релизные подними, трафик перенаправь, а если это делается глобально, то и сам релиз откатываться начнет не сразу (смотря как быстро алерт сработает), да и возвращаться будет долго.
В целом запуск бинаря в контейнере даже в самых современных оркестрациях занимает десятки секунд, что непростительно много, а даже самый чуткий алерт выстрелит в лучшем случае через минуту.
С флагами вы можете спокойно донести баговое решение до прода и спать крепко - до тех пор, пока флаг неактивен, плохой код исполняться не будет.
Более того, выкатку флага тоже можно и нужно контролировать с таким же усердием, как и сам релиз. Например, повесить на флаг те же алерты, что и на сервис, включить флаг для 1% запросов в canary, и смотреть как та пищит. Если у нас выстрелил алерт по SLO доступности, то дело скорее всего в фиче, и система выкатки так же умно его откатит назад.
Инженеру остается проанализировать логи, написать фикс и повторить итерацию.
Позже расскажу про как флаги позволяют контролировать выполнение кода, но пока поспекулирую, что флаги пропускают либо когда очень спешат (а в нынешней экономике все очень спешат), либо когда риск изменения низкий. А ваш покорный прилично инцидентов просмотрел, триггерами которых являлись «низкорисковые» изменения. :)