Findings

A tela Findings lista achados que o CloudBroker detecta sozinho na sua conta, sem você precisar perguntar nada ao FinOps Advisor: um pico de custo, um recurso que cobra por existir mas quase não trabalha, um app perto de estourar o orçamento.

A detecção é determinística: regras fixas sobre os seus dados de custo. Nenhum modelo de IA decide se algo é um achado, qual é a causa ou qual ação sugerir. Título, detalhe e ação sugerida vêm de template e das regras verificadas do rulebook.

Escopo atual

Hoje os findings são gerados só para contas com AWS conectada. Contas só com Azure não passam pelo scan.

Quando o scan roda

• Uma vez por dia, por volta das 07:15 (horário de Brasília), para toda conta com AWS conectada. Roda depois da ingestão diária de custo, porque o pico de custo depende do dado do dia.
• Junto com o e-mail diário de billing, para quem recebe esse e-mail.

No topo da tela, um aviso mostra quando o último scan rodou e o resultado de cada fonte. Se passarem mais de 26 horas sem scan, o aviso fica amarelo. O ambiente desliga à noite e no fim de semana, então na segunda de manhã isso é esperado. Num dia útil, indica que o agendamento não disparou.

Tipos de finding

Tipo	Quando aparece	De onde vem o dado
Pico de custo	O custo de um dos últimos 3 dias passou de 1,5× a média dos 7 dias anteriores. É preciso ter pelo menos 3 dias de histórico para comparar. Acima de +200% o finding é Crítico; abaixo disso, Atenção.	Série diária de custo (a mesma do card "Custo Diário do Mês")
Recurso ocioso	NAT Gateway ou Load Balancer com custo por hora de existência nos últimos 3 meses e custo de uso (tráfego processado / LCU) abaixo de 1% desse valor. O custo por hora precisa ter aparecido também nos últimos 14 dias, para não apontar recurso já removido.	Cost Explorer, por usage type
Orçamento	Um App com budget mensal configurado chegou ao percentual de alerta (Atenção) ou passou de 100% (Crítico).	Cache de custo por App do mês

Detalhes que mudam a leitura

• Pico compara uso com uso. Cobranças de ciclo — imposto (Tax), AWS Support e a taxa mensal do Route 53 cobrada no dia 1 — saem da conta antes de comparar com a média, para o início do mês não virar pico. O finding cita o serviço que mais subiu contra a própria média, não o maior do dia, e mostra as cobranças de ciclo separadas.
• Deploys perto do pico. O finding lista os deploys registrados nas 48 horas antes do dia do pico e no próprio dia (repositório, ambiente, commit), e o que eles mudaram (ex.: "1 mexeu em infra"). É coincidência de janela, não causa. Sem deploy registrado, o texto lembra que o registro só cobre repositórios com o passo de CI.
• Pico sem aumento de consumo. Quando o custo sobe e a quantidade consumida não acompanha, o finding diz isso: pode ser erro de medição do lado do provedor, não aumento de uso. Nesse caso, vale abrir chamado com o provedor antes de procurar causa na sua operação.
• Recurso ocioso é calculado na conta inteira. O Cost Explorer soma o custo de todos os NAT Gateways (ou Load Balancers) da conta. Com mais de um na mesma região, o sinal pode ficar diluído entre eles. O próprio finding traz esse aviso: confirme qual recurso específico está ocioso antes de agir. A ação sugerida é a da regra do rulebook ("investigar", "avaliar"), nunca "pode remover", e o card tem o link Ver fonte para a referência de preço da AWS.
• Orçamento depende do cache do mês. Esse cache é gravado quando alguém abre Custos por negócio com o mês corrente selecionado. Sem isso, o scan não tem dado de orçamento. O aviso do scan mostra essa fonte como sem cache, e isso não quer dizer "0% usado". O texto cita só o percentual, nunca o valor em moeda.

Identidade e retenção

Cada finding tem um id fixo, calculado a partir do tipo e do que foi detectado: o dia do pico, a regra do recurso ocioso, ou o App e o mês do orçamento. Se o scan encontra o mesmo achado de novo, ele só atualiza a data "Visto pela última vez", sem criar um finding duplicado. O scan nunca muda o status que você definiu: um finding marcado como resolvido ou ignorado não é reaberto sozinho.

Os findings são da organização: qualquer membro convidado vê os mesmos. Cada finding é guardado por 90 dias.

Resumo gerado por IA

Alguns cards mostram um bloco ✨ Resumo (gerado por IA a partir do achado abaixo). Ele reescreve o achado num tom mais direto e é gerado uma única vez, quando o finding é criado. Quando o mesmo achado volta em scans seguintes, o resumo não é gerado de novo.

O resumo não substitui o detalhe: o texto determinístico sempre aparece logo abaixo dele e é a fonte de verdade. Se a geração falhar, o card aparece sem resumo, e nada mais muda.

Status e ações

Status	O que significa
Aberto	Achado novo, ninguém agiu ainda
Reconhecido	Alguém viu e vai tratar
Implementado	Você aplicou a ação sugerida (botão Implementei a ação)
Revertido	Você aplicou a ação e depois desfez (botão Reverti a ação, só disponível a partir de Implementado)
Resolvido	O problema sumiu sem ação (botão Resolveu sem ação)
Falso positivo / ignorado	Não era um problema real (botão Ignorar (falso positivo))

Só administradores mudam status e fazem a revisão abaixo. Os demais papéis veem a lista, os filtros e os resumos, sem os botões. Pelo filtro no topo da tela, dá para ver só um status.

Revisão "teria recomendado?" (shadow mode)

No card, o administrador responde uma pergunta: olhando para trás, você teria recomendado agir sobre isso? As opções são Sim, teria recomendado e Não, seria ruído, com um motivo opcional. Essa revisão é separada do status: um finding pode estar resolvido e ainda assim ser avaliado como ruído.

O resumo no topo da tela mostra:

• Revisados: quantos findings já foram avaliados, do total.
• Teria recomendado: percentual de "sim" entre os revisados. Enquanto nenhum finding foi avaliado, aparece "sem revisão ainda", e não 0%. Mostrar 0% afirmaria que nada vale a pena, e o que existe de fato é que ninguém avaliou ainda.
• Resultados rotulados: quantos findings já têm um desfecho conhecido. Contam como positivos os implementados. Contam como negativos os revertidos, os ignorados e os avaliados como ruído.

Economia realizada

Quando um finding é marcado como Implementado, o CloudBroker passa a medir quanto o custo daquela linha caiu depois da ação.

• Só para Recurso ocioso. É o único tipo com uma linha de custo própria para comparar antes e depois (o par hora + uso do NAT Gateway ou Load Balancer). Em pico de custo e orçamento, o card mostra "não se aplica", nunca R$ 0.
• Janelas de 30 dias. A janela antes são os 30 dias que antecedem o dia da ação. A janela depois começa 2 dias após a ação, porque no dia da ação e no seguinte o recurso ainda pode ter cobrado parte do dia.
• Conta: (média diária antes − média diária depois) × 30, em US$/mês.
• Medida uma vez e congelada. Cada janela é medida cerca de 3 dias depois de fechar, quando o Cost Explorer já consolidou os dias. O resultado é gravado com a data da medição e não é recalculado depois. Se a AWS ainda marcar algum dia como estimado, a medição espera até 15 dias após o fechamento. Depois disso, congela e informa quantos dias eram estimados.
• Cobertura mínima de 90%. Se o Cost Explorer devolver menos de 90% dos dias (27 de 30) em qualquer uma das janelas, o card mostra "não mensurável", sem número.
• Aumento aparece como aumento. Se o custo subiu depois da ação, o card diz "Custo aumentou US$ X/mês depois da ação". O valor não é truncado para zero.
• Enquanto a janela está aberta, o card mostra "em medição — N de 30 dias". O primeiro número aparece cerca de 35 dias depois da ação.
• Ação revertida: o número continua sendo exibido, com a observação de que mede o período em que a ação esteve aplicada.

O número vale para a conta inteira naquele tipo de recurso, pelo mesmo motivo do aviso de recurso ocioso. O resumo no topo mostra só contagens (medidos, em medição, não mensuráveis). Os valores não são somados num total.

Marque "Implementado" só quando agiu de verdade

O status Implementado dispara a medição e entra nos resultados rotulados. Usá-lo para testar a tela produz um número de economia sem ação por trás.

Onde mais os findings aparecem

• E-mail diário de billing: os findings de pico de custo entram na seção de anomalias do e-mail, com o serviço dominante e o excesso sobre a média do dia. Recurso ocioso e orçamento não entram no e-mail.
• MCP: as tools list_findings, review_finding (administrador) e get_shadow_report dão acesso aos findings pelo seu assistente de IA.