Um agente que observa a frota, propõe o ajuste e executa com guardrails — com piloto pronto até 30 de novembro.
No fim, uma pergunta só: aprovamos o piloto do agente de otimização com data de 30/11?
Custo virou restrição de arquitetura, não só de orçamento.
Quatro decisões que a operação toma sem feedback.
O que já temos e o que falta para fechar o ciclo.
Telemetria, modelo, ferramentas, guardrails e trilha.
Quatro semanas, um domínio piloto, um relatório com número antes e depois.
Números do briefing da conta — a ordem de grandeza é o argumento.
clusters OpenShift
em dois sites (CCT1/CCT2) e nuvem governada.
cores consumidos
contra 30k contratados no ciclo anterior.
namespaces e apps
com donos e ciclos de vida desiguais.
pods observados
— e cada um com requests e limits.
“Coloca 4 CPU pra garantir.” O cluster reserva; a aplicação usa 15%. A diferença é capacidade que não atende ninguém.
Sem visão de uso real, o scheduler espalha em vez de densificar. Paga-se por nó, não por workload.
Ambientes de teste e namespaces esquecidos seguem ligados 24×7 porque desligar exige alguém decidindo.
A mudança é feita, ninguém mede depois. Sem medir, a próxima decisão repete o erro com outro nome.
Tudo roda na plataforma que já existe — OpenShift, observabilidade e GitOps.
Métricas de uso, requests, limits, ociosidade e histórico de mudanças — por namespace e por workload.
Donos, criticidade, janela de mudança e SLO. Sem isso, “otimizar” é chute com dashboard.
LLM com ferramentas: lê a frota, cruza sinais e escreve a proposta em linguagem de engenharia.
API do Kubernetes e MCP: consultar, simular, abrir PR. O agente age por ferramenta, não por acesso solto.
Escopo, dry-run, limite de mudança por janela, aprovação humana e rollback automático.
Cada decisão vira registro: sinal, hipótese, ação, resultado. Auditável e reproduzível.
Uso real × request, tendência de 30 dias, ociosidade e violação de política.
Mudança específica, com ganho estimado, risco e plano de reversão.
Dry-run, aprovação quando exigido, execução via GitOps — nunca por SSH.
Compara antes e depois, registra o desvio e ajusta o modelo de recomendação.
Começa por namespaces e workloads escolhidos. Fora do escopo, o agente só lê.
Toda ação tem simulação com o diff de requests/limits antes de existir.
Mudança só em horário definido, com teto por rodada e por dia.
O que toca criticidade alta pede aprovação nominal. O resto segue automático.
Rollback automático se SLO ou erro piorar depois da mudança.
Guardrails versionados no Git — auditáveis e revisáveis como qualquer código.
Referências de mercado para frota com baixa higiene de requests. O baseline do BB entra na semana 1 do piloto.
CPU request
right-sizing com base no p95 de uso e não no pico do primeiro dia.
Memória
limites coerentes com o consumo real reduzem reserva ociosa e OOM evitable.
Ociosidade
desligamento programado de ambientes sem uso, com retorno sob demanda.
Escolher 2–3 squads, extrair 90 dias de telemetria, calcular o custo ocioso atual.
Rodar em modo observador: recomenda, não age. Calibrar proposta com os donos.
Mudanças reais com aprovação, janela e rollback. Medir desvio entre previsto e realizado.
Fechar números antes/depois, lições e proposta de expansão. Apresentação em 30/11.
Alguém com autoridade para aprovar mudança em produção e destravar acesso.
Times com dor real de custo e disposição para revisar recomendação semanalmente.
Métricas de uso, requests e limites — leitura, sem acesso de escrita.
Um horário por semana em que o agente pode aplicar o que foi aprovado.
Mitigação: escopo por namespace, dry-run, teto de mudança, rollback por SLO.
Mitigação: p95 e tendência, não pico; dono do workload valida antes de aplicar.
Mitigação: o sucesso é mudança aplicada e medida, não relatório bonito.
Mitigação: escopo de 2–3 squads, uma decisão por semana e gate explícito em 30/11.
Sponsor, squads e domínio do piloto definidos nesta reunião.
Baseline de custo ocioso com 90 dias de telemetria.
Ganho medido, zero incidente atribuído ao agente, plano de expansão.
Obrigado. Vamos fechar a data?