Quando chega a ordem de reduzir custo de infraestrutura, existe uma sequência previsível de decisões ruins. Alguém desliga a réplica do banco, encurta a retenção de backup, corta a ferramenta de monitoramento. São os itens mais fáceis de cortar porque não produzem efeito visível — até o dia em que produzem, e o custo daquele dia supera todo o economizado. O desperdício de verdade está em outro lugar, e ele é maior do que parece.

Sem alocação, não há gestão

O primeiro trabalho não é cortar: é saber para onde o dinheiro vai. Enquanto a fatura é um número único, qualquer discussão é opinião.

Alocar significa conseguir responder três perguntas: qual ambiente — produção, homologação, desenvolvimento; qual serviço ou produto; e qual time responsável. Isso se faz com etiquetagem consistente em todos os recursos, e a palavra importante é consistente. Etiqueta em 60% dos recursos produz um relatório com uma fatia enorme de "não classificado", que é exatamente onde o desperdício se esconde.

Duas medidas tornam isso viável: etiqueta obrigatória na criação, imposta pela ferramenta de infraestrutura como código, e um relatório periódico do que está sem etiqueta, tratado como pendência. Recurso sem dono é candidato natural a ser desperdício — frequentemente é algo que alguém criou para um teste e esqueceu.

O desperdício previsível

A boa notícia é que o desperdício é notavelmente repetitivo entre empresas diferentes. Esta lista cobre a maior parte do que costumamos encontrar:

A primeira linha é quase sempre a maior oportunidade e a mais simples. Ambiente que só é usado em horário comercial e fica ligado o tempo todo desperdiça cerca de dois terços do próprio custo. Desligar fora do horário é um agendamento, não um projeto — e nenhuma pessoa é afetada, porque ninguém está usando às três da manhã de domingo.

Dimensionar pelo uso, não pelo medo

Superdimensionamento é o desperdício mais difundido, e tem origem compreensível: dimensionar pelo pico imaginado, com margem generosa, porque a consequência de faltar recurso é visível e a de sobrar não é.

Fazer isso com método pede alguns cuidados:

1. Meça por percentil ao longo de semanas, não pelo pico absoluto. Um pico de trinta segundos por mês não justifica dobrar a máquina no mês inteiro.
2. Olhe CPU e memória separadamente. É comum a memória ser o limite real e a CPU estar ociosa — e a solução ser um tipo de recurso diferente, não um maior.
3. Considere o comportamento sob carga. Serviço com rajadas legítimas precisa de folga; serviço com carga estável não.
4. Reduza em degraus, observando o efeito, em vez de cortar ao valor mínimo teórico de uma vez.
5. Não dimensione o banco de dados pela média. Ele é o componente onde o custo de errar para baixo é mais alto, e onde a folga é mais defensável.

Compromisso de longo prazo só depois de ajustar

Descontos por compromisso de uso — reserva, plano de economia, contrato anual — são reais e valem a pena. E existe uma ordem que precisa ser respeitada: primeiro ajuste o tamanho, depois comprometa.

Comprometer-se com um ano de um recurso superdimensionado é congelar o desperdício por doze meses, com desconto. Você vai economizar sobre um valor que não deveria estar pagando.

A sequência correta: elimine o ocioso, dimensione pelo uso real, observe por algumas semanas para confirmar a estabilidade e só então feche compromisso sobre a base que restou — e comprometa uma parcela conservadora dela, não o total.

A métrica que muda a conversa: custo por unidade

Custo absoluto é uma métrica ruim para uma empresa que cresce. Se a fatura subiu 30% e a base de clientes subiu 50%, você ficou mais eficiente — e um relatório que só mostra o total vai gerar uma discussão sobre corte exatamente no momento em que o negócio vai bem.

A métrica que orienta decisão é o custo por unidade de negócio: por cliente ativo, por transação processada, por VM vendida, por gigabyte armazenado. Ela permite três coisas que o número absoluto não permite: saber se a eficiência está melhorando ou piorando, precificar com margem conhecida e identificar o cliente ou produto que consome desproporcionalmente.

Para provedor de cloud, isso é ainda mais direto: sem custo por VM entregue, não há como saber se um plano dá lucro. E é comum descobrir que o plano de entrada, vendido em volume, opera com margem negativa.

Torne o custo visível para quem o gera

Custo é decidido por quem escolhe o tamanho da máquina e a retenção do log — ou seja, por engenharia. Se a fatura só chega ao financeiro, quem tem a mão no volante não tem o painel.

O mecanismo mais eficaz é também o mais simples: relatório periódico de custo por time e por serviço, visível para todos, sem cobrança agressiva. A visibilidade sozinha muda comportamento; ninguém quer aparecer como o dono do ambiente de teste mais caro da empresa.

Vale acrescentar duas práticas leves: estimativa de custo na revisão de mudança de infraestrutura, para a decisão ser tomada com o número na frente, e alerta de anomalia, que avisa quando o gasto sai do padrão — o que pega tanto engano de configuração quanto uso indevido.

O que não cortar

Sendo explícito, porque é aqui que os cortes costumam começar e é o pior lugar para começar:

• Backup e retenção. É o item cuja falta só é sentida no pior dia possível, e nesse dia o custo supera anos de economia.
• Redundância que sustenta compromisso assumido. Se você prometeu disponibilidade em contrato, cortar a redundância é assumir risco financeiro, não economizar.
• Monitoramento. Sem ele você perde justamente a capacidade de encontrar desperdício — e de detectar incidente.
• Ambiente de homologação. Testar em produção sai muito mais caro que manter um ambiente de teste, desde que ele seja desligado fora do horário.

Se for necessário mexer nesses itens, que seja como decisão consciente de aceitar risco, registrada e comunicada a quem responde pelo negócio — não como economia técnica silenciosa.

Um primeiro ciclo de trinta dias

Uma sequência realista que produz resultado no primeiro mês:

1. Semana 1: etiquetagem e relatório de alocação. Descubra o que não tem dono.
2. Semana 2: elimine o ocioso — disco órfão, snapshot antigo, endereço não usado, recurso esquecido.
3. Semana 3: agende desligamento dos ambientes que não são de produção fora do horário comercial.
4. Semana 4: meça o uso real e comece o ajuste de tamanho pelos maiores itens.
5. Depois: custo por unidade de negócio, alerta de anomalia e, por último, compromissos de longo prazo.

As três primeiras semanas geralmente entregam a maior parte da economia, e nenhuma delas exige decidir sobre risco.

Erros comuns

• Começar o corte por backup, redundância e monitoramento.
• Discutir custo sem alocação por ambiente, serviço e time.
• Comprometer-se com reserva antes de ajustar o tamanho.
• Dimensionar pelo pico absoluto em vez de percentil.
• Ambiente de teste ligado 24 horas por sete dias.
• Retenção de log e de backup no máximo, por inércia.
• Acompanhar só custo absoluto, sem custo por unidade.
• Fatura visível apenas para o financeiro.
• Cortar ambiente de homologação e testar em produção.
• Nenhum alerta de anomalia de gasto.

Onde a Solvefy/Cloud entra

Em consultoria DevOps, fazemos esse trabalho na ordem que economiza sem assumir risco: alocação, eliminação de ocioso, agendamento de ambientes e ajuste de tamanho baseado em uso medido. Depois, ajudamos a construir o custo por unidade de negócio — que, para provedores de cloud, é a base para precificar com margem conhecida. E somos explícitos sobre o que não recomendamos cortar, porque a economia que remove backup ou redundância é, na prática, um empréstimo com juros altos.

Quer saber onde está o desperdício na sua infraestrutura? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.