Recommendations

Depois de feita a exportação de dados, nosso sistema processará todos os recursos de seu provedor cloud. Um job roda diariamente para garantir a cobertura de recursos novos ou atualizados. Guardamos essas informações em nosso banco de dados, em uma tabela chamada Resource Records. Nesta tabela armazenamos informações como: nome do recurso, ID do provedor, snapshot, tags, ID da sub account, custo, tamanho e região, além das nossas formas de vinculá-los à organizações e cloud accounts.

Os recursos processados são filtrados por tipo e enviados por filas para serem examinados por regras cuidadosamente desenvolvidas, que avaliam métricas específicas (utilizando Amazon CloudWatch, Azure Monitor e Google Cloud Monitoring). Essas regras verificam, por exemplo, o baixo uso de CPU em instâncias EC2 na AWS, a presença de IPs públicos órfãos no Azure, ou uma baixa taxa de IOPS em Cloud Storage no GCP. O objetivo é identificar recursos fora dos padrões de otimização.

Se um recurso for considerado fora do padrão, um Work Item do tipo Recommendation é gerado. Este Work Item pode ser recusado caso haja uma razão específica que impeça sua alteração, aceito e resolvido manualmente, ou ainda encaminhado para o board de preferência, permitindo que um squad interno faça a atualização de forma mais cautelosa, especialmente para recursos que não possam lidar com um Start/Stop em determinados horários.

Ciclo de vida de uma recomendação

Uma recomendação aberta é atualizada a cada execução diária enquanto a situação continuar válida: a economia estimada, a ação sugerida e as métricas que a justificam passam a refletir a última medição, em vez de ficarem congeladas no dia em que ela apareceu.

Quando você dispensa uma recomendação, ela não volta para aquele mesmo recurso e aquela mesma regra. Se preferir silenciar uma regra inteira para um recurso específico, use a tag kura-disabled-optimization-rules no próprio recurso.

Concluir

Quando você aplica a mudança, clique em Concluir. A economia potencial mensal da recomendação é registrada como Economia no Cost Avoidance, creditada a você. O comentário é opcional — use-o para o ID do seu chamado e o que foi feito (ex.: CHG-1234).

Fechamento automático

O Kura fecha sozinho uma recomendação aberta quando o motivo dela deixa de existir:

• O problema foi resolvido. Na execução diária, a regra verifica o recurso de novo e, com dados suficientes, conclui que o problema não está mais lá. Por exemplo: o uso de CPU voltou a ficar acima do limite ao longo de toda a janela medida, o benefício híbrido do Azure já foi aplicado, ou o IP público passou a estar associado a um recurso.
• O recurso não existe mais. Quando um recurso deixa de ser encontrado pela descoberta durante o período de retenção de recursos da organização, ele é removido do Kura, e as recomendações abertas dele são fechadas.

A recomendação fechada assim aparece com o status Resolvida, sem usuário responsável (o Kura é quem fecha), e com um comentário de fechamento em inglês: "Closed automatically: the problem is no longer found" ou "Closed automatically: the resource no longer exists". Sozinha, ela não conta como economia realizada: o Kura só viu que o problema sumiu, não que alguém agiu a partir da recomendação. Se foi você quem corrigiu, abra a recomendação e clique em Concluir — assim a economia é registrada em seu nome, como em qualquer recomendação concluída. Se o problema voltar, uma nova recomendação é aberta normalmente.

Nem toda regra consegue afirmar que o problema sumiu — quando faltam métricas ou um dado não pôde ser lido, ela não fecha nada. Nesses casos, a recomendação segue aberta até ser concluída, dispensada ou expirar.

Expiração e período de espera

Recomendações expiram depois de um número configurável de dias (padrão: 30). A expiração existe para manter a lista atual e preservar o senso de urgência, limpando o que o fechamento automático não alcança. Você recebe um aviso por e-mail alguns dias antes disso acontecer.

Depois que uma recomendação expira, a mesma constatação fica retida por um período (padrão: 60 dias) antes de poder ser aberta novamente. Sem essa espera, ela reapareceria na manhã seguinte — e, se você usa um conector de chamados, abriria um novo ticket a cada dia. Passado o período, se o desperdício continuar existindo, uma nova recomendação é aberta (com um novo chamado), justamente para trazer o assunto de volta.

Onde ajustar

Em Operações → Configurações, na seção Ciclo de vida das recomendações:

• Expirar recomendações abertas após (dias) — entre 7 e 365.
• Após expirar, não reabrir a mesma recomendação por (dias) — entre 0 e 365. Use 0 se quiser que a recomendação volte já na próxima execução.

Apenas usuários FinOps ou administradores da organização podem alterar esses valores; os demais visualizam as configurações sem poder editá-las.

O que cada recomendação diz

Toda recomendação traz, além do texto da ação, a medição que a justifica e de onde vem a economia estimada — para que você possa conferir o raciocínio em vez de ter que confiar nele.

A ação é escrita a partir do tipo de mudança que a regra identificou:

Tipo de ação	O que fazer
Redimensionar	Trocar o recurso por um tamanho menor da mesma família. O recurso continua existindo, com menos capacidade — e menos custo.
Liberar	Remover um recurso que não está associado a nada (um IP reservado, um disco desanexado). Nada depende dele; o custo é desperdício integral.
Mudar classe de armazenamento	Manter o mesmo dado em um tipo de disco mais barato, adequado ao uso observado.
Mudar modelo de licença	Passar a usar uma licença que sua empresa já possui (Azure Hybrid Benefit), em vez de alugá-la por hora do provedor.
Definir retenção	Configurar por quanto tempo dados são guardados (logs, imagens de container). Sem retenção, esses dados só crescem.
Migrar	Mover para uma geração mais nova ou um serviço equivalente que custa menos pela mesma capacidade.

A linha de evidência

Abaixo da ação aparece o que foi medido, por exemplo:

Medimos Percentage CPU em 9%, contra um limite de 40%, ao longo de 7 dias (36 pontos de dados).

São os números que a regra usou para decidir: a métrica, o valor observado, o limite da regra, a janela analisada e quantas leituras existiam nela. Quando uma regra avalia mais de uma métrica — um cache só é considerado superdimensionado se CPU e memória estiverem ociosas — aparece uma linha por métrica.

Se não houver medições suficientes na janela, nenhuma recomendação é criada. Ausência de dado não é o mesmo que recurso ocioso.

A base da economia

A economia estimada é sempre apresentada com a sua base, por exemplo:

A economia estimada é 50% do custo mensal corrente de BRL 640,00 deste recurso.

O percentual é o quanto a mudança tende a economizar; o valor é o custo mensal corrente do recurso — o que ele custou nos últimos 7 dias completos, projetado para o mês, na moeda da conta cloud em que ele é cobrado (não necessariamente a moeda base da organização). Para um recurso criado dentro desses 7 dias, o dia da criação fica de fora — ele só cobra as horas em que o recurso existiu e subestimaria o mês —, e a média usa os dias seguintes. Enquanto não houver um dia completo depois da criação, a recomendação aparece como Não estimada.

Em alguns casos a base é mais estreita que o recurso inteiro. A economia de uma licença Windows, por exemplo, é uma fração do que o medidor de computação cobra, e não de tudo que a máquina virtual gera — discos e tráfego não têm relação com a licença. Nesses casos o medidor aparece na frase.

Quando o recurso ainda não tem custo mensal corrente apurado, a recomendação informa que a economia não pôde ser estimada — em vez de mostrar R$ 0,00, que seria lido como "não vale nada".

Referências

Quando a regra tem material de apoio do provedor, os links aparecem no fim da recomendação, para você conferir a orientação oficial antes de aplicar a mudança.

Economia potencial ao longo do tempo

A página Economia Potencial soma o que as recomendações em aberto dizem que pode ser economizado por mês, na moeda base da organização. Recomendações de contas cobradas em outra moeda são convertidas pelas taxas configuradas; as que não têm taxa ficam fora do total, em vez de aparecerem com a moeda errada.

A Tendência de Economia registra esse total uma vez por dia. Ela mostra o que estava em aberto em cada dia — não é uma projeção. O histórico começa no dia em que o registro diário foi ativado, sem dados retroativos; por isso, nos primeiros dias o gráfico avisa que ainda está acumulando pontos.

Economia por Centro de Custo mostra quanto dessa economia está em cada centro de custo. Recomendações que ainda não pertencem a nenhum centro de custo aparecem como Sem centro de custo.