A revisão que não olha para a conta
Uma mudança de infraestrutura revê-se por segurança, por nomes, por estilo. Quase nunca pelo seu efeito na fatura. E, no entanto, uma mudança de tamanho de instância, uma réplica adicional ou um armazenamento mais rápido podem somar centenas de euros por mês com uma linha de código.
Esse custo aparece semanas depois, num relatório que já ninguém relaciona com a mudança que o provocou.
A estimativa no mesmo lugar que o plano
Como o plano já sabe que recursos se criam, modificam ou eliminam, e com que tamanho, pode calcular-se com preços públicos quanto custará cada um. A estimativa acrescenta-se à revisão da mudança:
- Custo mensal antes e depois, e a diferença.
- Desdobramento por recurso, para ver o que explica a subida.
- Pressupostos de utilização quando o custo depende do tráfego ou do volume.
O que muda na prática
Decide-se com a cifra à frente. «Esta réplica acrescenta 300 euros por mês» abre uma conversa útil: precisamos dela já?, basta uma mais pequena?
Fixam-se limiares. Uma mudança que sobe o custo acima de certa quantia exige uma aprovação adicional, tal como uma destrutiva.
Fecha-se o círculo com FinOps. A estimativa de cada mudança é o orçamento esperado; o pipeline de custos mede depois o real. Se a diferença for grande, algum pressuposto estava errado e aprende-se (é a mesma ideia que em o custo como requisito de desenho).
O que não é
A estimativa não é a fatura. Não conhece descontos negociados nem compromissos, e a utilização real pode ser outra. O seu valor não é a exatidão, mas que o custo se vê no momento em que ainda se pode decidir.
Com o código da infraestrutura sob controlo, falta a outra metade do problema: que cada servidor, uma vez criado, continue a ser o que deve ser.
Como o aplicamos: Automação e IaC.