Laboratório de Troubleshooting: Manage costs by using alerts, budgets, and Azure Advisor recommendations
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de FinOps de uma empresa configurou um budget mensal de USD 5.000 para uma subscription de produção. Foram definidos três alertas com as seguintes configurações:
Budget name: prod-monthly-budget
Amount: 5000 USD
Reset period: Monthly
Start date: 2024-01-01
Alert 1: Type=Actual, Threshold=80%, Recipients=finops@empresa.com
Alert 2: Type=Actual, Threshold=100%, Recipients=finops@empresa.com
Alert 3: Type=Forecasted, Threshold=110%, Recipients=finops@empresa.com
No dia 18 do mês corrente, o Azure Cost Management exibe custo acumulado de USD 4.320, representando 86,4% do budget. O analista responsável não recebeu nenhuma notificação por e-mail até o momento.
Informações adicionais coletadas pelo analista:
- A subscription está ativa e os recursos estão gerando cobranças normalmente
- O analista confirmou que consegue acessar o portal do Azure sem problemas
- O endereço finops@empresa.com está ativo e recebeu outros e-mails corporativos hoje
- O budget foi criado há 3 dias, com data de início retroativa a 2024-01-01
Qual é a causa raiz da ausência de notificações?
A) O endereço de e-mail do destinatário foi rejeitado pelo servidor de e-mail da Microsoft porque pertence a um domínio corporativo externo.
B) O budget foi criado após o custo já ter ultrapassado o threshold de 80%, e alertas do tipo Actual não disparam retroativamente para custos já incorridos antes da criação do budget.
C) O tipo de alerta Forecasted está em conflito com os alertas do tipo Actual no mesmo budget, bloqueando o envio de todas as notificações.
D) O período de reset mensal reiniciou o acumulado no dia da criação do budget, zerando os custos considerados para o cálculo do threshold.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: um conjunto de VMs de desenvolvimento foi deixado em execução durante o fim de semana por engano, gerando USD 1.200 em cobranças não planejadas em 48 horas. O budget mensal da subscription de desenvolvimento é de USD 3.000, e o custo acumulado no mês já está em USD 2.850, representando 95% do limite.
O gerente de infraestrutura determinou que o time deve agir imediatamente. As seguintes restrições se aplicam ao momento:
- São 23h de domingo; o time de aprovações não está disponível
- As VMs de desenvolvimento não têm cargas de trabalho ativas no momento
- A subscription tem uma política corporativa que exige aprovação formal para exclusão permanente de recursos
- O time tem permissão de Contributor na subscription, sem acesso a billing
Qual é a ação correta a tomar neste momento?
A) Excluir as VMs imediatamente para cessar as cobranças, dado que não há carga de trabalho ativa e o custo está próximo do limite.
B) Desligar (deallocate) as VMs para interromper as cobranças de computação, sem excluir os recursos, respeitando a política de aprovação para exclusão.
C) Criar um Azure Policy de negação para bloquear a criação de novos recursos na subscription até o próximo ciclo de cobrança.
D) Aguardar até segunda-feira para acionar o processo formal de aprovação antes de qualquer ação, evitando violar a política corporativa.
Cenário 3 — Causa Raiz
Um administrador revisa o Azure Advisor e encontra a seguinte recomendação na categoria de custo:
Recommendation: Resize or shutdown underutilized virtual machines
Resource: vm-analytics-prod (Standard_E16s_v3)
Savings: ~USD 890/month
Confidence: High
Observation: Average CPU utilization: 4.2% over 14 days
Max CPU utilization: 11.7% over 14 days
Average memory: 18% over 14 days
O administrador decide agir na recomendação e redimensiona a VM para Standard_E4s_v3 às 10h de uma terça-feira. Às 14h do mesmo dia, ele retorna ao Azure Advisor esperando ver a recomendação removida da lista, mas ela ainda aparece com os mesmos dados.
O administrador conclui que o redimensionamento falhou silenciosamente e abre um chamado de suporte. O portal do Azure, no entanto, confirma que a VM está em execução com o SKU Standard_E4s_v3.
Informações adicionais:
- A VM está em execução contínua e saudável no novo SKU desde o redimensionamento
- Nenhum alerta do Azure Monitor foi disparado para a VM
- O administrador tem role de Owner na subscription
- A região da VM suporta o SKU Standard_E4s_v3 sem restrições
Qual é a causa raiz do comportamento observado no Azure Advisor?
A) O redimensionamento foi aplicado mas gerou um novo recurso com ID diferente, fazendo o Advisor continuar monitorando o recurso original.
B) O Azure Advisor não atualiza recomendações em tempo real; há uma defasagem no ciclo de atualização, e a recomendação ainda reflete dados coletados antes da ação.
C) A recomendação persiste porque o SKU Standard_E4s_v3 também está sendo sinalizado como subutilizado com base nos mesmos dados históricos.
D) O Azure Advisor exige que o administrador marque manualmente a recomendação como "Implementada" para que ela seja removida da lista após a ação.
Cenário 4 — Sequência de Diagnóstico
Um analista recebe o seguinte relato: "Configurei um budget na semana passada, mas os alertas nunca chegam. Já gastamos 110% do valor do budget este mês e não recebi nada."
O analista precisa investigar o problema. Os seguintes passos de investigação estão disponíveis, apresentados fora de ordem:
[P] Verificar se o budget tem alertas configurados com destinatários válidos
[Q] Confirmar o custo acumulado atual no Azure Cost Management
[R] Verificar se o tipo de alerta é Actual ou Forecasted e qual o threshold definido
[S] Checar se o endereço de e-mail do destinatário está na lista de supressão do Azure
[T] Confirmar se a data de início do budget abrange o período de custo atual
Qual é a sequência correta de investigação?
A) Q -> T -> P -> R -> S
B) P -> R -> Q -> S -> T
C) T -> Q -> P -> S -> R
D) Q -> P -> R -> T -> S
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O ponto central do diagnóstico está na combinação de dois fatos: o budget foi criado há apenas 3 dias e o custo já estava em 86,4% no momento da criação. Alertas do tipo Actual são disparados quando o custo cruzar o threshold durante o ciclo de monitoramento ativo. Se o custo já havia ultrapassado 80% antes de o budget existir, a transição que dispararia o alerta já ocorreu no passado, e o sistema não emite notificação retroativa.
A informação sobre o e-mail estar funcional e recebendo outras mensagens é a informação irrelevante incluída propositalmente. Ela pode induzir o analista a suspeitar de problema de entrega de e-mail, que é uma hipótese válida em outros contextos, mas aqui não é a causa. O endereço está operacional; o alerta simplesmente nunca foi gerado.
A alternativa C descreve um conflito entre tipos de alerta que não existe na plataforma. A alternativa D confunde o comportamento do reset period com o comportamento de detecção de threshold. A consequência de agir com base no distrator A seria escalar para suporte de e-mail, perdendo tempo sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
O cenário impõe três restrições simultâneas que eliminam as demais alternativas: é fora do horário comercial, a política corporativa proíbe exclusão sem aprovação, e o time tem permissão de Contributor (suficiente para desligar VMs, mas a exclusão exigiria violar a política).
Desligar (deallocate) as VMs resolve o problema imediato, que é a geração de cobranças de computação, sem violar nenhuma restrição. VMs no estado deallocated não geram custo de CPU/RAM, apenas custo de disco gerenciado, que é significativamente menor.
A alternativa A viola diretamente a política corporativa de aprovação para exclusão, independentemente de não haver carga ativa. A alternativa C não resolve o problema de custo imediato, pois as VMs já existentes continuariam acumulando cobranças. A alternativa D ignora a urgência e aceita passivamente que o budget seja ultrapassado enquanto o time dorme. O distrator mais perigoso é A: tecnicamente eficaz, mas cria um risco de compliance que pode ter consequências mais custosas do que o próprio gasto extra.
Gabarito — Cenário 3
Resposta: B
O Azure Advisor processa dados históricos de utilização e atualiza suas recomendações periodicamente, não em tempo real. O redimensionamento foi aplicado com sucesso às 10h, mas às 14h do mesmo dia o ciclo de atualização do Advisor ainda não havia sido executado para incluir o novo estado do recurso. A recomendação continua exibindo os dados que levaram à sugestão original.
O portal confirmando o SKU correto é a pista definitiva de que a ação foi bem-sucedida. O fato de o administrador ter role Owner e a região suportar o SKU são informações irrelevantes para o diagnóstico: elas confirmam que não há impedimento técnico, mas não explicam o comportamento observado.
A alternativa D representa um erro de diagnóstico comum: assumir que o sistema exige confirmação manual quando, na realidade, o problema é simplesmente temporal. A consequência de agir com base nessa alternativa seria marcar a recomendação como implementada manualmente, o que poderia mascarar uma recomendação legítima se o Advisor detectasse subutilização no novo SKU no futuro.
Gabarito — Cenário 4
Resposta: A
A sequência correta de investigação segue a lógica de eliminação progressiva, do mais fundamental ao mais específico:
| Passo | Ação | Motivo |
|---|---|---|
| Q | Confirmar custo acumulado | Validar o sintoma relatado com dados objetivos |
| T | Verificar data de início do budget | Garantir que o período de cobrança está coberto |
| P | Verificar alertas e destinatários | Confirmar que a estrutura do alerta existe |
| R | Verificar tipo e threshold | Confirmar se o alerta deveria ter disparado |
| S | Checar lista de supressão de e-mail | Investigar problema de entrega como último recurso |
Começar por P ou R antes de confirmar que o custo realmente ultrapassou o threshold (Q) e que o budget cobre o período correto (T) representa um erro de sequência: o analista estaria investigando a configuração do alerta sem ter validado os pré-requisitos para que ele disparasse. A lista de supressão de e-mail (S) é a hipótese mais externa ao sistema de budget e deve ser investigada por último, apenas se todos os outros elementos estiverem corretos.
Árvore de Troubleshooting: Manage costs by using alerts, budgets, and Azure Advisor recommendations
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigação
- Azul: nó de pergunta diagnóstica, decisão binária ou de estado
- Vermelho: causa identificada, origem confirmada do problema
- Verde: ação recomendada ou resolução aplicável
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado e siga as ramificações respondendo cada pergunta com base no que você consegue verificar diretamente no portal ou via CLI. O objetivo é chegar a um nó vermelho o mais rápido possível, confirmando a causa, antes de executar qualquer ação corretiva indicada pelo nó verde correspondente. Nunca pule etapas de validação intermediária: diagnosticar errado e agir rápido é mais custoso do que diagnosticar devagar e agir certo.