A fatura de cloud costuma crescer em silêncio. Cada equipa cria um ambiente, testa um serviço novo, aumenta uma instância para resolver um pico, e ninguém volta atrás para a desligar. Quando a fatura chega à administração, a reação mais comum é cortar às cegas: congelar projetos, limitar acessos, exigir aprovação para tudo. O custo desce durante um mês e a engenharia perde velocidade durante um ano. O FinOps existe precisamente para evitar este dilema.
Primeiro, ver
Não se consegue otimizar o que não se vê. O ponto de partida é uma política de etiquetagem (tagging) aplicada de forma consistente: produto, equipa, ambiente e centro de custo em cada recurso. Os recursos sem etiqueta devem ser a exceção, detetados automaticamente e corrigidos depressa. Assim, o relatório deixa de ser uma fatura única e passa a mostrar quem gasta, em quê e para entregar que valor.
Custo com responsável
Visibilidade sem responsabilidade é apenas mais um painel. Cada equipa precisa de conhecer o seu consumo, ter um orçamento de referência e receber alertas quando sai da curva. A ideia não é penalizar, mas sim aproximar a decisão de custo de quem toma a decisão técnica. Quem escolhe a arquitetura é quem melhor sabe onde se pode poupar sem comprometer o serviço.
Onde estão os ganhos rápidos
- Rightsizing: instâncias, bases de dados e clusters dimensionados para o pico de há um ano. Rever a utilização real e ajustar o tamanho é, em regra, a poupança mais simples de capturar.
- Ambientes inativos: desenvolvimento e testes ligados durante a noite e ao fim de semana. Agendar o encerramento e criar ambientes efémeros a pedido resolve boa parte do desperdício.
- Reservas e savings plans: para a carga de base, que corre permanentemente, os compromissos de utilização reduzem o preço unitário. O cuidado está em comprometer apenas o que é previsível, depois do rightsizing e não antes.
FinOps não é gastar menos. É saber porque é que cada euro gasto está lá.
O custo como métrica de arquitetura
O passo mais maduro é tratar o custo como um requisito não funcional, ao lado da disponibilidade, da latência e da segurança. Isto significa estimar o custo de uma solução logo no desenho, acompanhar o custo por transação ou por cliente e discutir esse número nas revisões de arquitetura. Em plataformas de grande volume, como as de meios de pagamento, uma pequena alteração no custo unitário faz uma enorme diferença no fim do mês.
Sem travar a engenharia
O erro clássico é centralizar tudo num comité que aprova cada recurso. Funciona melhor dar autonomia com limites claros: guardrails automáticos, orçamentos por equipa, padrões de infraestrutura como código já otimizados e uma rotina mensal curta de revisão entre engenharia, finanças e produto. A engenharia continua a experimentar, mas com o custo visível desde o primeiro dia.
Com esta base, a conversa sobre cloud muda de tom. Em vez de "porque é que a fatura subiu?", a pergunta passa a ser "este custo está a gerar o valor que esperávamos?". E essa é uma pergunta a que a engenharia sabe responder.
Quer conversar sobre isto?
Conte-nos o seu desafio. A conversa é direta e sem compromisso.