Cloudמַעֲלוֹת
Maturidade de cloud com IA: de força em força, degrau por degrau
Um modelo de cinco níveis para maturidade de cloud, como medir pelos seis pilares, onde a IA encurta a subida e o que fazer nos primeiros 90 dias.
אֵלֶּה פְקוּדֵי הַמִּשְׁכָּן
eleh fekudei hamishkan · estas são as contas do Mishkan · Shemot 38:21
Blog/Artigos · Governança
FinOps com IA: estas são as contas do Mishkan
Informar, otimizar e operar o custo de cloud, com unit economics, anomalia detectada por modelo e o custo da própria IA na conta.
Quando o Mishkan ficou pronto, Moshe prestou contas de cada talento de ouro, de prata e de bronze, na frente de todos. Quem administrava a obra mais sagrada do povo também devia transparência sobre o material. FinOps começa exatamente aí: cada real gasto em cloud tem dono conhecido, finalidade declarada e relação visível com o valor que produziu. Na Compass UOL essa disciplina cortou de 20% a 35% da conta sem perder disponibilidade.
As contas do Mishkan: o ciclo do FinOps
O framework da FinOps Foundation organiza o trabalho em três fases que se repetem: informar, otimizar e operar. Informar é dar visibilidade e alocação, para cada time ver quanto gasta e com o quê. Otimizar é agir sobre o que a visibilidade mostrou. Operar é transformar a otimização em rotina, com meta, dono e revisão.
A fase mais subestimada é a primeira. Sem tag de dono e de centro de custo aplicada de forma consistente, a fatura vira um número único que ninguém sente como seu. Por isso eu começo qualquer programa de FinOps pela política de tag como guardrail: recurso sem tag obrigatória não sobe.
Figura 1Fases do FinOps, em ciclo contínuo
- Informar visibilidade, alocação por dono e custo por unidade de negócio.
- Otimizar rightsizing, compromisso de uso, arquitetura e desperdício eliminado.
- Operar meta por time, revisão recorrente, política e automação.
Unit economics: o custo que importa é o por unidade
Fatura que sobe pode ser ótima notícia, se o negócio cresceu mais rápido que ela. Fatura estável pode esconder desperdício, se o volume caiu. A métrica que resolve essa ambiguidade é o custo por unidade de negócio: por transação, por cliente ativo, por documento processado.
O gráfico abaixo mostra um modelo simples com custo fixo de plataforma e custo variável por volume. O custo por mil transações cai conforme o volume sobe, e a otimização desloca a curva inteira para baixo. É esse deslocamento que eu reporto para a diretoria, junto da fatura.
Figura 2Custo por mil transações conforme o volume diário, antes e depois da otimização
- antes: R$ 1.500 fixo por dia + R$ 12 por mil
- depois: R$ 900 fixo por dia + R$ 9 por mil
Ver os dados da figura
| volume (mil transações por dia) | antes: R$ 1.500 fixo por dia + R$ 12 por mil | depois: R$ 900 fixo por dia + R$ 9 por mil |
|---|---|---|
| 5 | 312 | 189 |
| 10 | 162 | 99 |
| 20 | 87 | 54 |
| 40 | 49,5 | 31,5 |
| 60 | 37 | 24 |
| 80 | 30,75 | 20,25 |
| 100 | 27 | 18 |
Onde o dinheiro escorre
Em quase toda conta de cloud que eu revisei, o desperdício estava nos mesmos lugares. Instância dimensionada para o pico que nunca veio, ambiente de teste ligado no fim de semana, volume de disco órfão, log guardado por mais tempo do que qualquer regra exige e tráfego entre zonas que ninguém desenhou de propósito.
A ordem de ataque segue a relação entre economia e risco. Recurso ocioso e retenção de log saem primeiro, porque o risco é quase zero. Compromisso de uso vem depois de o consumo estabilizar. Mudança de arquitetura, como trocar de família de instância ou mover para serverless, entra com teste de carga e rollback.
Figura 3Alavancas de economia em cloud, com o cuidado de cada uma
- OCIOSORecurso sem usovolume órfão, IP parado, snapshot antigo. Risco baixo, economia imediata.
- AGENDAAmbiente fora do horáriodesenvolvimento e teste desligados à noite e no fim de semana.
- LOGRetenção de logprazo alinhado à exigência regulatória, com camada fria para o resto.
- SIZERightsizingtamanho ajustado ao uso real, medido em semanas, com folga para pico.
- STORAGECiclo de vida do storageobjeto movido para classe mais barata conforme o acesso cai.
- REDETransferência de dadostráfego entre zonas e para fora revisado no desenho da arquitetura.
- COMPROMISSOSavings Plans e reservascompromisso só sobre a base estável de consumo, revisado a cada trimestre.
- SPOTCapacidade interrompívelcarga tolerante a interrupção, como lote e CI, com retomada automática.
IA no FinOps: anomalia detectada e explicada
Anomalia de custo descoberta no fechamento do mês já custou trinta dias. A detecção diária compara o gasto de cada serviço, conta e dono com o esperado para aquele dia da semana, e avisa quando o desvio passa de um limite. Até aqui é estatística, e funciona sem modelo de linguagem.
O modelo entra na explicação. Um alerta que diz que o gasto de uma conta subiu 38% é pouco acionável. Um alerta que diz que o aumento veio de um novo cluster criado ontem por um pipeline específico, com o link para a mudança, chega ao dono certo e vira ação no mesmo dia.
Figura 4Detecção e tratamento de anomalia de custo
- 01Dado de custorelatório detalhado do provedor, no formato FOCUS quando disponível
- 02Alocaçãocusto distribuído por dono, serviço e ambiente, via tag
- 03IADetecçãodesvio contra o esperado para o dia, por dono
- 04IAExplicaçãorecurso, mudança e pipeline que causaram o desvio
- 05Açãoalerta ao dono com link da mudança e sugestão
- 06Verificaçãoeconomia medida depois da correção e registrada
FinOps da própria IA
Uso de modelo de linguagem virou uma linha nova e crescente na conta. Ela tem uma característica diferente das outras: o custo depende do tamanho do texto, de entrada e de saída, e cresce silenciosamente quando alguém aumenta o contexto ou deixa o modelo responder mais longo.
Aplico o mesmo ciclo a essa linha. Informar é medir tokens e custo por funcionalidade e por requisição. Otimizar é usar cache de prompt, escolher modelo menor para rota simples, processar em lote o que não precisa ser imediato e limitar o contexto ao que a tarefa exige. Operar é orçamento por funcionalidade, com alerta quando o custo por requisição sobe.
Figura 5Custo de uma funcionalidade com LLM, e as alavancas sobre cada termo
custo_por_requisicao = tokens_de_entrada * preco_de_entrada
+ tokens_de_saida * preco_de_saida
custo_mensal = custo_por_requisicao * requisicoes_por_mes
alavancas
tokens_de_entrada limite de contexto, recuperacao mais precisa, cache de prompt
tokens_de_saida formato estruturado, limite de tamanho na resposta
preco modelo menor para rota simples, processamento em lote
requisicoes cache de resposta, deduplicacao, gatilho so quando precisoPara levar
FinOps é prestação de contas com engenharia: custo alocado a dono, medido por unidade de negócio, otimizado na ordem certa de risco e acompanhado todo dia. A IA acelera a alocação, explica a anomalia e entra ela mesma na conta. O objetivo continua sendo o mesmo das contas do Mishkan: cada unidade de material com destino conhecido.
Quem escreve: Juliano Vince de Campos
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
