FinOps: controlando o custo de nuvem em times de engenharia

Quando uma equipe migra para a nuvem, o modelo de consumo muda de forma profunda: em vez de comprar servidores uma vez por ano, cada chamada de API, cada cluster e cada gigabyte trafegado vira uma decisão de gasto contínuo. O problema é que quem toma essas decisões — engenheiros e SREs — raramente vê a fatura, e quem paga a fatura — finanças — raramente entende a arquitetura. FinOps existe para fechar essa lacuna. É uma prática de gestão financeira de nuvem que trata custo como uma responsabilidade compartilhada entre engenharia, finanças e negócio, em vez de um problema a ser empurrado para o fim do trimestre.

O que é FinOps (e o que não é)

FinOps não é "cortar custo a qualquer preço". É a disciplina de levar dados de custo para perto de quem cria valor, para que cada time tome decisões informadas sobre o trade-off entre velocidade, custo e qualidade. A prática é organizada de forma aberta pela FinOps Foundation, um projeto da Linux Foundation que mantém um framework público de princípios, capacidades e fases. Vale a pena ler a definição oficial em vez de confiar na minha paráfrase — o material é gratuito e mantido pela comunidade.

A ideia central é que decisões de engenharia são decisões financeiras. Escolher entre uma instância maior e duas menores, ligar autoscaling ou deixar um ambiente de staging rodando no fim de semana — tudo isso tem preço. FinOps não tira essa decisão do engenheiro; ela dá ao engenheiro a informação para decidir bem.

Visibilidade: você não otimiza o que não enxerga

O primeiro princípio é tornar o custo visível e atribuível. Sem isso, qualquer conversa sobre economia vira chute. Na prática, visibilidade começa com tagging consistente: todo recurso precisa carregar quem é o dono, qual o ambiente e qual o produto ou centro de custo.

# Exemplo de tags padronizadas em Terraform
locals {
  common_tags = {
    team        = "checkout"
    environment = "production"
    cost_center = "cc-1042"
    managed_by  = "terraform"
  }
}

resource "aws_instance" "api" {
  instance_type = "m6i.large"
  tags          = local.common_tags
}

Com tags confiáveis, dá para fazer showback (mostrar a cada time quanto ele consome) e, num estágio mais maduro, chargeback (efetivamente alocar o custo no orçamento do time). Showback costuma ser o ponto de partida certo: ele cria consciência sem o atrito político de cobrar de cada equipe. Ferramentas nativas dos provedores — AWS Cost Explorer, GCP Billing, Azure Cost Management — e o formato aberto FOCUS, também mantido pela FinOps Foundation, ajudam a normalizar esses dados entre nuvens.

Otimização: onde a engenharia atua

Visibilidade aponta o problema; otimização resolve. As alavancas mais comuns são:

• Rightsizing. Muitos recursos são provisionados com folga "por garantia" e nunca revisados. Comparar uso real (CPU, memória, IOPS) com o tamanho provisionado e ajustar costuma ser o ganho mais fácil. Vale para VMs, mas também para requests/limits no Kubernetes.
• Desligar o que está ocioso. Ambientes de desenvolvimento e homologação raramente precisam rodar 24/7. Agendar shutdown fora do horário comercial é uma economia direta e de baixo risco.
• Autoscaling. Em vez de provisionar para o pico, escale conforme a demanda. No Kubernetes, isso significa HPA/VPA e cluster autoscaler bem configurados; em filas, escalar workers pelo tamanho da fila.
• Compromissos de capacidade. Para uso estável e previsível, os provedores oferecem descontos significativos em troca de compromisso — Reserved Instances e Savings Plans na AWS, Committed Use Discounts no GCP, Reservations no Azure. A regra prática é cobrir a base estável com compromissos e absorver o pico com on-demand ou spot.

# Exemplo: limites de recursos num Deployment Kubernetes
resources:
  requests:
    cpu: '250m'
    memory: '256Mi'
  limits:
    cpu: '500m'
    memory: '512Mi'

Um detalhe importante: defina requests com base em uso medido, não em chute. Requests inflados reservam capacidade no cluster que ninguém usa — e capacidade reservada é capacidade paga.

Accountability: cultura antes de ferramenta

A parte mais difícil de FinOps não é técnica. É fazer com que cada time se sinta dono do próprio custo. Isso exige que a informação chegue no lugar certo, na hora certa: um alerta de anomalia de custo no canal do time que provocou o gasto vale mais do que um relatório mensal que ninguém abre.

Algumas práticas que ajudam a criar essa cultura:

• Custo como métrica de SRE. Assim como acompanhamos latência e erro, dá para acompanhar custo por requisição ou por usuário ativo. Custo unitário é mais honesto que custo absoluto — a conta pode crescer porque o produto cresceu, e isso é saudável.
• Alertas de anomalia. Detectar um salto inesperado de gasto em horas, não no fechamento da fatura, evita surpresas caras (um ambiente esquecido ligado, um loop de retry gerando tráfego).
• Revisão recorrente. Trazer custo para retrospectivas e revisões de arquitetura normaliza o assunto. A pergunta "quanto isso vai custar para operar?" deveria fazer parte de todo design review.

A FinOps Foundation descreve a prática em três fases iterativas — Inform, Optimize e Operate — justamente para reforçar que isso não é um projeto com fim, e sim um ciclo contínuo. Você ganha visibilidade, otimiza, opera com disciplina, e volta a olhar os dados.

Por onde começar

Não tente implantar tudo de uma vez. Um caminho pragmático para um time de engenharia:

1. Garanta tagging consistente — sem isso, nada mais funciona.
2. Coloque um dashboard de showback por time, mesmo que simples.
3. Ligue alertas de anomalia de custo nos canais dos times.
4. Ataque os ganhos óbvios: recursos ociosos e rightsizing.
5. Só então parta para compromissos de capacidade, que exigem previsão de uso.

FinOps não substitui a responsabilidade de engenharia; ela a estende. O mesmo cuidado que temos com confiabilidade e segurança passa a valer para custo. Quando o engenheiro que provisiona o recurso enxerga o preço daquela escolha, a otimização deixa de ser uma força-tarefa anual e vira parte do trabalho do dia a dia.