# O que são feature flags e como proteger deploys em produção

URL: https://upstreamapi.com/pt/journal/o-que-sao-feature-flags
Type: blog
Locale: pt
Published: 2026-08-29
Updated: 2026-08-31

---

> Feature flags separam o deploy do release, reduzem o blast radius e permitem kill switches testados antes do incidente. Guia técnico para SREs e platform engineers em escala.

O que são feature flags? São verificações condicionais no código da aplicação que controlam quais caminhos de execução ficam ativos para um determinado usuário, sessão ou ambiente, sem necessidade de um novo build. Uma flag chamada `new_checkout_flow` definida como `false` para 99% da base de usuários significa que o código foi deployado há duas semanas. Você simplesmente ainda não ativou. O contrato que isso estabelece é preciso: deploy e release se tornam dois eventos separados. Para qualquer equipe que faz continuous deployment em escala, esse contrato é estrutural.

## Deploy e Release Não São o Mesmo Evento

A maioria das equipes aprende essa distinção depois de um rollout problemático. Uma feature é shipada na tarde de terça, algo no trace de requisições começa a se comportar de forma diferente na manhã de quarta, e quando alguém abre uma investigação o diff cobre quatro commits e dois limites de serviço. Atribuir causalidade nesse cenário é genuinamente difícil.

Feature flags forçam precisão. Quando o código por trás de uma flag é merged e deployado, ele fica inerte em produção. Você confirma que o deploy foi bem-sucedido, observa as métricas de baseline por algumas horas ou dias, e verifica que nada degradou. Aí você liga a flag para 1% do tráfego. Agora você tem uma única variável atribuível. Se a taxa de erro sobe no caminho com a flag ativa, você não está debugando um diff de código. Você está alternando um valor de configuração.

Essa separação não é primariamente um argumento de velocidade. É um argumento de blast radius. Um release que afeta 1% das sessões e dá errado é recuperável em minutos. Um release que afeta 100% das sessões e dá errado é um incidente maior.

O mecanismo em si é direto. Em TypeScript, uma avaliação de flag fica mais ou menos assim:

`const showNewCheckoutFlow = flagClient.variation(
  'new_checkout_flow',
  { userKey: session.userId, custom: { plan: user.plan } },
  false // default se o serviço de flags estiver indisponível
);

if (showNewCheckoutFlow) {
  return renderNewFlow(cart);
}
return renderLegacyFlow(cart);`O `false` como default não é formalidade. É o comportamento que seus usuários recebem se o serviço de avaliação de flags tiver uma partição de rede. Defina deliberadamente, não por acidente.

## Os Quatro Tipos de Flag que Importam em Produção

Nem todas as feature flags servem ao mesmo propósito operacional. Tratá-las de forma idêntica no seu codebase e nas ferramentas de gestão é um caminho confiável para confusão durante incidentes e acumulação de flag debt.

**Flags de release** protegem novas features durante o desenvolvimento e o rollout. São temporárias: criadas quando o trabalho começa em uma feature branch, removidas assim que a feature chega a 100% dos usuários e a equipe confirma estabilidade. Flags de release sem data de remoção e sem responsável definido viram mobília permanente no codebase.

**Flags de experimento** alimentam testes A/B e experimentos multivariados. Estão associadas a identificadores de coorte de analytics e seu ciclo de vida é delimitado pelo experimento. Quando o experimento termina, a flag vai junto. O erro comum: manter o variante vencedor por trás da flag indefinidamente, com a justificativa de que a remoção "não é urgente". Dois anos depois, a flag de experimento faz parte do caminho crítico e ninguém lembra qual variante está ativa.

**Flags de ops** são kill switches e circuit breakers. Ao contrário das flags de release, são infraestrutura permanente por design. Uma flag `disable_ml_recommendations` que permite contornar uma camada de inferência ML lenta quando seu SLO degrada é algo que você quer disponível às 3h da manhã sem precisar ler documentação. Essas flags devem avaliar localmente, ter um fallback bem documentado, e ser testadas regularmente em operações normais, não descobertas sob pressão.

**Flags de permissão** controlam acesso por tier de usuário, plano de conta, ou coorte beta. São de longa duração por design. O risco de confusão: flags de permissão frequentemente parecem flags de release para quem não conhece o histórico. Uma convenção de nomenclatura clara importa mais aqui do que em qualquer outro lugar.

![Visualização de rollout progressivo mostrando roteamento de tráfego por percentual com círculos de nós concêntricos](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/e28abc-inline1.webp)

## Rollout por Percentual Sem SLO Gate É Apenas Deploy Lento

É aqui que a maioria das implementações de feature flags para no meio do caminho. A equipe de plataforma monta um cronograma de rollout: 1% na segunda, 5% na terça, 25% na quarta, 100% na sexta. Documenta, compartilha com stakeholders, e chama de progressive delivery.

Mas "progressivo" sem uma condição de validação em cada etapa é risco diferido, não risco reduzido. O percentual controla exposição. Não valida segurança.

O que torna um rollout faseado operacionalmente significativo é o SLO gate entre cada estágio. Antes de avançar de 5% para 25%, algo deve responder: a taxa de erro no caminho com a flag está dentro do orçamento de SLO? A latência p99 está dentro da mesma faixa do grupo de controle? O error budget está sendo consumido mais rápido do que o baseline?

Se nenhuma dessas perguntas está instrumentada, o cronograma de rollout é uma linha do tempo, não um loop de validação.

Uma configuração que funciona em produção: defina duas janelas de avaliação de SLO. Uma janela curta (15 minutos) captura falhas rápidas: uma query ruim no banco, um mismatch de schema, uma regressão em um caminho crítico. Uma janela mais longa (24 horas ou um ciclo completo de tráfego) captura degradações graduais: memory leaks, pressão em cache, edge cases em segmentos de tráfego de baixa frequência. Exija que ambas as janelas mostrem verde antes de qualquer avanço. Se alguma janela for violada, interrompa o rollout e acione o on-call.

O percentual é um dial. A janela de SLO é o gate. Os dois são necessários.

## Kill Switch: Desenhe Antes de Precisar

O kill switch não é um fallback. É uma decisão de design de primeira classe que deve existir antes da primeira linha de código da feature ser escrita.

Um kill switch desenhado sob pressão é um kill switch com premissas não examinadas. Você o está testando pela primeira vez durante um incidente ativo, dentro de uma sessão de terminal aberta a partir de uma notificação do PagerDuty, com cinco pessoas acompanhando uma thread no Slack. Esse é o pior momento possível para descobrir que sua flag de ops faz targeting de usuários por session ID e que seu serviço de sessão está atualmente degradado.

![Dashboard de monitoramento de SLO com gráficos de taxa de consumo do error budget e indicador de kill switch para controle de rollout](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-08/dd1477-inline2.webp)

Três propriedades inegociáveis para qualquer kill switch destinado ao uso em produção:

- 
**Avaliação local sub-50ms**: a verificação de flag não pode ser uma chamada de rede para um serviço de avaliação remoto. Se a avaliação depende de um serviço que pode estar degradado, você criou uma dependência circular no seu caminho de resposta a incidentes.

- 
**Valor de fallback explícito**: o que a flag retorna quando o serviço de flags está inacessível? Isso deve ser documentado, definido em código, e testado. "Seja lá o que o SDK usar como padrão" não é uma resposta.

- 
**Testado sob falha de dependências**: kill switches devem fazer parte da sua rotina de chaos engineering. Valide-os contra cenários em que a autenticação está degradada, em que o próprio serviço de flags está fora, e em que a latência de rede para o endpoint de avaliação ultrapassa 2 segundos.

As equipes que executam a resposta a incidentes de forma limpa são as que ensaiaram. O kill switch faz parte do runbook. Torne-o chato.

## Flag Debt: A Dívida Técnica que Ninguém Coloca no Roadmap

Equipes que adotam feature flags de forma agressiva frequentemente acumulam o que se chama de flag debt: flags que cumpriram seu propósito mas nunca foram removidas. A feature foi shipada, o experimento terminou, o beta acabou. A flag ficou.

Com 50 flags, é um incômodo menor. Com 500 flags distribuídas em um sistema distribuído, é um risco operacional ativo. Cada flag é um branch de código que exige manutenção, testes, e compreensão durante a investigação de incidentes. Um desenvolvedor tentando entender uma falha às 2h da manhã não quer rastrear 40 branches condicionais para encontrar o relevante.

Um padrão observado em múltiplas equipes de plataforma: middleware de avaliação de flags aparecendo entre os cinco primeiros stack frames para latência p99. A causa na maioria dos casos são flags obsoletas com regras de targeting complexas que avaliam dezenas de condições por requisição, carregando o peso de decisões tomadas dois anos antes que ninguém se sentiu confortável em deletar.

A contramedida é organizacional, não técnica. Toda flag criada deve ter três atributos: um responsável, um tipo (release, experimento, ops, permissão), e uma data esperada de remoção. Flags de release devem ser removidas dentro de dois sprints do rollout completo. Flags de experimento devem ser removidas quando o experimento termina, não "quando alguém tiver tempo". O inventário de flags deve ser auditável sob demanda e visível nos dashboards de saúde de engenharia.

## Granularidade de Targeting: A Dimensão que Quebra em Escala Enterprise

A maioria das plataformas de feature flags suporta rollouts por percentual e targeting básico por atributo de usuário. A lacuna que aparece em escala enterprise é a granularidade de targeting: a capacidade de expressar regras de rollout específicas o suficiente para serem úteis, sem se tornarem complexas demais para manter.

Uma hierarquia de targeting útil para rollouts em produção no nível de equipe de plataforma:

- 
**Nível de ambiente**: produção, staging, preview. O primeiro gate, não o único.

- 
**Segmento de infraestrutura**: data center, availability zone, ou cluster Kubernetes. Útil para isolar o blast radius geográfico.

- 
**Conta ou tenant**: para plataformas SaaS B2B, fazer rollout por conta frequentemente é mais seguro do que por percentual de usuários, porque você pode observar o padrão de tráfego de uma conta inteira em vez de uma amostra estatística.

- 
**Coorte de usuários**: usuários beta, usuários internos, power users por tier de atividade.

- 
**Atributo de sessão**: útil para flags de experimento, perigoso para flags de ops.

As plataformas que implementam isso bem, como LaunchDarkly e Statsig (as mais citadas por equipes de SRE que operam nessa escala), permitem composição complexa de regras sem exigir tempo de engenharia para modificar a lógica de targeting durante um rollout ativo. Essa capacidade de self-service é a diferença entre uma pausa de 30 segundos no rollout e um ticket para a equipe de plataforma.

As plataformas que implementam isso mal forçam uma escolha entre granularidade de targeting e simplicidade operacional. Esse tradeoff vai aparecer às 3h da manhã.

## O que o Post-Mortem Continua Encontrando

Todo post-mortem de um incidente em produção relacionado a features faz o mesmo conjunto de perguntas. A feature estava protegida por uma flag? O rollout foi progressivo? Havia uma condição de validação entre as etapas? O kill switch foi testado antes do incidente?

Se todas as quatro respostas forem sim, o incidente é um problema de calibração: thresholds definidos de forma muito ampla, regras de targeting com um edge case, comportamento de avaliação do SDK sob partição de rede que não foi levado em conta. São problemas resolvíveis com mudanças de configuração e atualizações de runbook.

Se alguma resposta for não, o incidente é um problema de arquitetura. Feature flags não são uma conveniência de debugging. São uma decisão de arquitetura de deploy. Essa decisão existe antes da feature ser shipada, ou não existe.

A pergunta que vale responder antes do próximo release: o que o post-mortem diria sobre esse rollout se algo der errado hoje à noite?

## FAQ

### O que são feature flags em termos práticos?

Feature flags são verificações condicionais no código da aplicação que controlam quais caminhos de execução ficam ativos para um usuário, sessão ou ambiente, sem necessidade de um novo build. Elas separam o ato de deployar o código do ato de ativar a feature para os usuários.

### Qual é a diferença entre deploy e release com feature flags?

Com feature flags, o deploy coloca o código em produção em estado inerte, enquanto o release é o ato de ativar a flag para os usuários. Esses dois eventos podem ocorrer com dias ou semanas de diferença, permitindo observar o baseline antes de expor usuários a qualquer mudança.

### Quais são os quatro tipos de feature flags usados em produção?

Os quatro tipos são: flags de release (temporárias, para rollout de features), flags de experimento (ligadas a testes A/B com ciclo de vida delimitado), flags de ops (kill switches e circuit breakers, infraestrutura permanente), e flags de permissão (controle de acesso por tier ou plano de conta).

### Como funciona um SLO gate em um rollout progressivo?

Um SLO gate é uma condição de validação entre cada estágio do rollout. Antes de avançar de um percentual para outro, o sistema avalia janelas de SLO: uma curta (15 minutos) para falhas rápidas e uma longa (24 horas) para degradações graduais. Se alguma janela for violada, o rollout é interrompido automaticamente.

### O que é flag debt e como evitar?

Flag debt é o acúmulo de flags que cumpriram seu propósito mas nunca foram removidas. Em sistemas com 500 ou mais flags, pode se tornar um dos cinco maiores contribuintes para latência p99. Para evitar: toda flag deve ter um responsável, um tipo definido e uma data esperada de remoção.

### Quais plataformas de feature flags são mais usadas por equipes de SRE?

LaunchDarkly e Statsig são as mais citadas por equipes de SRE que operam em escala enterprise. LaunchDarkly destaca-se em governança e targeting complexo; Statsig unifica flags, experimentação e analytics. ConfigCat é preferido por simplicidade e custo. Flagsmith oferece a alternativa open-source.

### Como testar um kill switch antes de um incidente real?

Kill switches devem fazer parte da rotina de chaos engineering. Valide-os contra cenários em que a autenticação está degradada, em que o próprio serviço de flags está fora, e em que a latência de rede ultrapassa 2 segundos. O kill switch testado sob pressão simulada é o que funciona sob pressão real.