Todo CFO faz a mesma pergunta: “por que a cloud não tem previsibilidade?”. E todo CTO responde com um mix de culpa e resignação. Parece conversa de gente de áreas diferentes, mas na prática é o mesmo problema: ninguém consegue explicar a fatura como um produto.

Quando isso acontece, a planilha vira uma tentativa de adivinhar arquitetura. E aí ela sempre erra.

TL;DR
FinOps não é uma planilha e nem um cargo. É um jeito de operar: engenharia e finanças olham custo como métrica de produto, com owner, ritual e decisão. A planilha erra quando tenta prever o que a arquitetura vai fazer sozinha.

O que FinOps é (e por que a palavra confunde)

A FinOps Foundation define FinOps como uma prática cultural de gestão e otimização de valor, com responsabilidade distribuída e um grupo central de boas práticas. Não é “corte de custo”, é controle e trade-off. Definição oficial aqui: What is FinOps?.

Traduzindo pro mundo real de um SaaS B2B: FinOps é o momento em que você para de discutir “cloud é cara” e passa a discutir custo por serviço, custo por cliente e custo por feature. E isso vira rotina, não incidente.

Por que a planilha do CFO sempre erra

Ela erra por bons motivos. Ela não tem as variáveis que importam.

O CFO coloca na planilhaO que muda no mundo realResultado
número de usuáriospadrão de tráfego e cachecusto explode “sem motivo”
crescimento do MRRcardinalidade de métricas e logsobservabilidade vira linha gigante
“vamos otimizar EC2”rede/egress/NAT entra como impostovocê corta compute e a fatura não mexe
um total por timeserviços sem owner e custo “shared”ninguém sente, ninguém muda
O ponto
A planilha não está errada por ser burra. Ela está errada porque custo em cloud é uma propriedade emergente da arquitetura. Se você não amarra custo em serviço e owner, vira superstição.

O que muda quando FinOps funciona

Você não precisa virar uma empresa “financeira”. Você precisa de três coisas bem pé no chão: owner, métrica e ritual.

1) Owner por serviço

Todo serviço com impacto em produção tem um dono técnico. Esse dono não “paga a conta”, mas ele consegue responder por que aquele custo existe. Sem isso, custo vira ruído.

2) Custo como métrica

Não é “quanto custou a AWS”. É custo por unidade de negócio. Exemplo:

  • Custo por 1.000 requests (API)
  • Custo por tenant ativo (B2B)
  • Custo por GB processado (pipeline)

Quando você mede assim, dá pra comparar versão A vs versão B, feature nova vs feature antiga, e investimento vs retorno sem brigar por ideologia.

3) Ritual mensal com top 10

Uma vez por mês, um comitê pequeno olha o top 10 drivers e decide: corta, corrige, aceita. Sem drama, sem caça às bruxas.

Regra de ouro
Se você não consegue listar o top 10 drivers do mês em 5 minutos, você não tem FinOps. Você tem um boleto com narrativa.

Ferramentas que ajudam (mas não resolvem sozinhas)

Ferramenta boa é a que deixa você fazer perguntas sem virar projeto de BI.

  • Cost Explorer ajuda a enxergar tendências e drivers por agrupamento/filtragem. Overview: AWS Cost Explorer.
  • CUR (Cost & Usage Reports) é o dataset mais completo para detalhar por linha e cruzar com inventário. O básico do CUR está aqui: What is CUR.
  • Cost allocation tags são o mínimo pra custo parar de ser “shared”. Docs: cost allocation tags.

Ferramenta sem owner vira dashboard que ninguém abre. Owner sem ferramenta vira discussão no feeling. Você precisa dos dois.

O playbook Fixx (o jeito simples de começar)

Se você quer sair do zero sem criar um “projeto FinOps” de seis meses, aqui vai um caminho que funciona pra times pequenos e médios.

SemanaO que fazerResultado
1criar 6 categorias (compute, banco, storage, egress, rede, observabilidade)você para de discutir total e começa a discutir causa
2ativar tags mínimas (app, owner, env) e corrigir os “shared” grandescusto ganha dono
3definir 2 métricas de unidade (ex: custo por tenant, por 1.000 req)custo vira métrica de produto
4rodar o primeiro ritual do top 10 drivers e escolher 2 açõesvocê cria tração e não vira teatro
Dica de sobrevivência
Não comece pelo perfeito. Comece pelo visível. O primeiro mês serve pra você parar de se surpreender. O segundo mês serve pra você decidir com calma.

Onde repatriação entra nessa história

FinOps maduro não te prende na cloud. Ele te dá uma linguagem pra decidir. Se a sua carga é previsível e o custo virou risco de orçamento, repatriar parte do stack pode ser a decisão mais “financeira” que você toma.

A Fixx não é religiosa sobre on-prem. A gente é religiosa sobre controle: previsibilidade, opção de mudar, e um plano que não depende de herói.

FAÇA EM CASA
Pegue a fatura do mês e responda duas perguntas: (1) quais 3 linhas somam mais de 40% do custo? (2) quem é o dono técnico de cada uma? Se você travou na segunda, você achou o seu primeiro trabalho.

Se você quiser ajuda

A gente pode começar pelo básico: uma auditoria em 48h, com top 10 drivers e plano 30/60/90. Sem hype, sem “transformação”, só decisão e execução.

contato@fixx.com.br