FinOps e observabilidade: otimizando custos em clusters Kubernetes com IA

Observabilidade e FinOps na prática - Introdução

Apresentando o curso

Bem-vindas e bem-vindos ao curso de FinOps com IA. Eu sou Júlia e vou ministrar este curso.

Nesta primeira aula, vamos entender por que otimizar custos vai muito além de analisar a fatura da nuvem.

Contextualizando a eficiência na nuvem

Em ambientes modernos e distribuídos, lidamos com múltiplos serviços, que utilizam recursos escaláveis. Os custos são o resultado do comportamento desse sistema.

Por isso, antes de falar sobre redução de custos, precisamos entender como esses sistemas se comportam e como consomem recursos.

Vamos começar analisando os principais desafios da eficiência operacional na nuvem.

Analisando os desafios da otimização de custos

Quando pensamos em reduzir custos, nossa primeira reação costuma ser olhar a fatura. Porém, a fatura mostra apenas o custo mensal. Ela não indica por que houve um aumento específico em determinado horário, nem traz detalhes de comportamento.

Assim, os recursos podem crescer para atender a uma demanda, mas nem sempre retornam a um tamanho ideal depois que a carga diminui. Isso é o que chamamos aqui de crescimento invisível.

Além disso, o custo normalmente é consequência de decisões operacionais, como a configuração de recursos, a política de autoescalonamento ou a escolha de arquitetura.

Há ainda um terceiro desafio: a falta de contexto. Saber que houve um aumento de custo não explica o motivo. Precisamos correlacionar métricas técnicas e métricas financeiras para entender se esse aumento foi esperado, necessário ou simplesmente resultado de desperdício. Sem esse contexto, otimizar custos torna-se uma tarefa muito mais difícil.

Conectando complexidade e observabilidade de finops

Mas por que a gestão de custos se tornou tão complexa? Isso ocorre porque os sistemas modernos também se tornaram mais complexos. Hoje, uma única aplicação pode depender de diversos serviços, de bancos de dados, de APIs e de componentes compartilhados. Além disso, cada aplicação tem um padrão de consumo diferente e normalmente convivemos com múltiplos ambientes, como desenvolvimento, homologação e produção. Cada ambiente terá um comportamento diferente porque haverá demandas distintas.

À medida que essa complexidade cresce, entender apenas o valor da fatura deixa de ser suficiente. É precisamente nesse ponto que a observabilidade de FinOps se conecta. No próximo vídeo, nós vamos explorar essa relação em muito mais detalhes.

Observabilidade e FinOps na prática - Como Observabilidade e FinOps trabalham juntos

Relacionando observabilidade e FinOps

Durante muito tempo, a observabilidade e a gestão de custos foram tratadas como disciplinas separadas. De um lado, existem equipes de operações focadas em disponibilidade e desempenho; de outro, está FinOps, concentrada em consumo, orçamento e eficiência financeira. O problema é que ambas analisam o mesmo ambiente a partir de perspectivas diferentes.

A observabilidade nos ajuda a responder perguntas como: o sistema está saudável? Existe risco de saturação? Onde estão os gargalos? Por sua vez, FinOps responde quanto custa operar esse ambiente, se há desperdício e se o consumo está alinhado ao valor entregue. Ao correlacionarmos essas duas visões, conseguimos tomar decisões melhores. Por exemplo, um serviço pode estar estável e saudável, mas utilizar apenas uma pequena parte do recurso provisionado; nesse caso, há uma oportunidade clara de otimização. O objetivo não é apenas observar métricas, e sim transformar dados em decisões. Esse é exatamente o enfoque que vamos utilizar ao longo do curso.

Apresentando o laboratório com Kubernetes

Até aqui, tratamos a relação entre observabilidade e FinOps de forma mais conceitual. Agora, vamos trazer uma discussão mais concreta. Ao longo do curso, nós vamos utilizar um ambiente local baseado em Kubernetes. Em Kubernetes, as cargas de trabalho influenciam diretamente o consumo e o custo. Primeiro, trabalharemos com os requests (solicitações) e os limits (limites), que definem quanto recurso reservamos para cada aplicação. Em seguida, abordaremos o autoescalonamento, responsável por aumentar ou reduzir recursos conforme a demanda.

E, por fim, os namespaces (espaços de nomes), que ajudam a organizar aplicações e atribuir responsabilidades sobre o consumo. Esses três conceitos serão fundamentais para entendermos o cenário do laboratório.

Neste momento, nosso objetivo não é nos aprofundar em Kubernetes, e sim compreender como as decisões operacionais afetam a utilização, a eficiência e o custo. Trazer Kubernetes para este curso serve para ilustrar um sistema distribuído.

Atualmente, muitas empresas utilizam Kubernetes, por isso consideramos uma boa ideia incluir um laboratório local executando Kubernetes, para visualizarmos melhor o comportamento dos sistemas.

Exemplificando o autoescalonamento e seus efeitos no custo

Assim, podemos observar, por exemplo, algo que ocorre com frequência em ambientes cloud (nuvem). Nesse cenário, o tráfego da aplicação aumenta ao longo do dia e a autoescala reage corretamente, criando novas réplicas para suportar a carga. Até aqui, tudo funciona perfeitamente.

O problema aparece quando essa demanda diminui. Observamos que a linha azul mostra o tráfego retornando ao nível normal; porém, as réplicas, representadas pela linha verde, permanecem elevadas. Isso significa que continuamos mantendo recursos provisionados mesmo sem necessidade e, como consequência, o consumo e o custo se mantêm altos, apesar da redução da carga.

Este é um exemplo clássico de como o comportamento operacional e o custo estão diretamente relacionados. Em FinOps, não basta saber que o custo aumentou; precisamos entender por que esses recursos não retornaram ao estado esperado e se existe aqui uma oportunidade de otimização.

Ao longo do curso, aprenderemos a identificar exatamente esse tipo de comportamento.

[♪]

Observabilidade e FinOps na prática - Identificando tendências de crescimento operacional

Contextualizando visibilidade e objetivos em finops

Ter métricas disponíveis não significa necessariamente ter visibilidade. Muitas organizações possuem dashboards (painéis) e alertas, mas ainda têm dificuldade para responder perguntas simples sobre consumo e eficiência. Em FinOps, o objetivo não é gerar mais dados, e sim fornecer contexto para embasar nossas decisões.

Um exemplo são os alertas de anomalia, que ajudam a identificar comportamentos fora do normal, como um aumento repentino no consumo ou um custo elevado devido a um spike (pico) ou a algum problema ocorrido. Também podemos usar alertas para identificar crescimento gradual e antecipar risco de saturação ou de extrapolação do orçamento. Às vezes, temos uma demanda que, no início, parece rotineira, mas acaba se tornando a nova normalidade — seja por aumento de tráfego ou mais pessoas usuárias. Precisamos analisar para afirmar: houve crescimento porque conquistamos mais clientes ou por outro motivo, e é o momento de aumentar recursos para não perder disponibilidade nem desempenho.

Outro aspecto é segmentar a visibilidade, isto é, ter dashboards (painéis) realmente claros. Podemos organizá-los por domínio, aplicação e equipe, o que traz mais clareza ao nosso dia a dia. Isso nos permite analisar tendências, avaliar a eficiência do sistema e os custos, e apoiar a operação cotidiana em caso de problemas.

Por fim, é importante criar relatórios de eficiência. Eles ajudam a identificar desperdícios e priorizar oportunidades de otimização. O objetivo não é criar mais dashboards (painéis) ou mais alertas, e sim integrá-los melhor para entregar a informação correta à pessoa adequada no momento oportuno.

Monitorando padrões no ambiente local e intervalos de tempo

No ambiente local que estamos utilizando, criamos alguns dashboards (painéis). Nos próximos vídeos, abordaremos em mais detalhes esse ambiente. Neles, acompanhamos tanto as CPUs (processadores) do cluster (cluster) quanto a memória utilizada desse cluster (cluster). Também analisamos, por exemplo, a CPU (processador) por namespace (espaço de nomes), como payments, users e stable. Em um caso, observamos uma subida, uma descida e, em seguida, estabilização. Em outro, ocorre uma queda, depois uma alta e novamente estabilização. Em outro cenário, há vários picos pequenos que retornam à normalidade.

No recorte dos últimos 15 minutos, esses padrões ficam claros; ao ampliar para a última meia hora, os picos aparecem de forma mais nítida. Isso indica prováveis mudanças nesses horários, e é importante analisá-las para estudar as tendências. Quando a curva se aproxima de um patamar plano, entendemos que está estável; por alguma razão, surgem picos e, com o tempo, a métrica volta a maior estabilidade. Em cada namespace (espaço de nomes), podemos observar picos com manutenção de certa estabilidade. O mesmo ocorre na memória: picos seguidos de estabilidade, com maior ou menor frequência conforme o namespace (espaço de nomes).

Esses padrões sugerem que os eventos ocorrem em horários comuns, possivelmente devido a maior tráfego nos fins de semana, em determinados momentos do dia ou no horário comercial. Assim, monitoramos nossas aplicações e verificamos por que esses comportamentos se produzem.

Ao ampliar para 24 horas, obtemos uma visão mais nítida. Na memória do ambiente de stage (homologação), por exemplo, a linha permanece praticamente plana, quase sem variação. Já na CPU (processador), observamos maior variação.

A utilização ainda é bastante baixa em comparação com outros namespaces (espaços de nomes). Por isso, é importante trabalharmos também com intervalos de tempo. Podemos alterar o fuso horário; aqui usamos Espanha, porque estamos na Espanha, mas podemos mudar para o fuso horário desejado. Também podemos definir um intervalo personalizado, por exemplo, usar yesterday (ontem), escolher a semana passada e assim por diante. Outra opção é configurar um intervalo de tempo absoluto, especificando de quanto até quanto. Isso é essencial para entendermos como nossas aplicações se comportam e, além disso, identificarmos onde há espaço para otimização.

Aplicando ia para analisar dashboards e identificar perfis por namespace

Criamos uma captura de tela da tela e do dashboard (painel) e pedimos à IA algumas análises. Solicitamos que analisasse os dashboards e indicasse quais alertas poderíamos criar e que tipo de sazonalidade poderia estar ocorrendo. Obtivemos a resposta de que já é possível identificar alguns padrões interessantes, embora seja importante lembrar que este ambiente está usando um gerador de carga acelerada: configuramos para que um dia inteiro seja executado em 12 minutos. Em produção, analisaríamos ao menos de 7 a 30 dias.

A IA aponta que, em payment, há um consumo de CPU muito maior do que nos demais; o medidor está em vermelho, indicando que provavelmente está próximo do limite; o gráfico apresenta oscilações frequentes e relativamente irregulares. Portanto, esse namespace parece representar uma aplicação crítica e de uso constante. Há sinais de carga contínua, possíveis picos recorrentes, possível overprovisioning (superalocação) e possibilidade de saturação futura caso a demanda cresça. Essa conclusão é baseada no comportamento observado do namespace.

No users, o consumo de CPU está baixo e bastante instável, apresentando ainda assim um comportamento previsível. Já em staging, o ambiente está praticamente inativo, sem atividade relevante. Dessa forma, ele permanece ligado, consumindo recursos sem uso — um caso clássico de ambiente pouco utilizado, com desperdício estrutural e oportunidade de desligamento automático.

Embora o período observado seja pequeno, por se tratar de um ambiente local de demonstração, há um padrão claramente repetitivo: alto, baixo, alto e baixo. Isso sugere ciclos de uso previsíveis, alternando entre períodos de pico e de baixa utilização, simulando horário comercial versus fora do expediente, como comentado anteriormente.

Cada namespace apresenta um perfil diferente: payment tem atividade alta e contínua, users apresenta um consumo mais estável e staging permanece quase sempre inativo. A IA complementa com mais análises nesse sentido.

Definindo alertas e recorrendo ao suporte da ia

Em relação a alertas, podemos criar alertas de utilização para disparar se a CPU ficar acima de 80% por mais de 15 minutos, definidos por namespace. Também podemos configurar um alerta de crescimento anormal, por exemplo, comparando o uso atual com a média das últimas 24 horas: podemos solicitar a criação de um alerta quando o uso atual estiver maior que 150% da média histórica. O objetivo é detectar vazamentos, regressões ou mudanças de comportamento, entre outras possibilidades.

Com nosso conhecimento do sistema, podemos fornecer mais informações à IA e solicitar uma análise mais detalhada, ou até pedir ajuda para criar esses alertas no Grafana, se necessário. Isso ilustra como podemos usar a IA para nos apoiar no dia a dia com FinOps (operações financeiras em nuvem).

Sobre o curso FinOps e observabilidade: otimizando custos em clusters Kubernetes com IA

O curso FinOps e observabilidade: otimizando custos em clusters Kubernetes com IA possui 211 minutos de vídeos, em um total de 53 atividades. Gostou? Conheça nossos outros cursos de FinOps em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Observabilidade e FinOps na prática
• Otimização de recursos e eficiência operacional
• Detecção de anomalias e planejamento de capacidade
• Governança de custos e otimização em Kubernetes
• Eficiência operacional em nuvem com IA