Azure usa ML e telemetria para prever falhas de hardware antes que derrubem workloads críticos

O AFPD (Azure Failure Prediction and Detection) troca o ciclo clássico de falha de hardware (componente degrada, workload cai, engenheiro investiga, reboot ou troca de peça) por três fases: predict and detect, mitigate e remediate. Modelos de ML e regras de detecção olham telemetria da frota, comportamento dos nós e sinais de componentes, como a saúde de SSDs. Segundo a Microsoft, o sistema está totalmente operacional desde 2024.

Na mitigação, o nó sinalizado fica não alocável e, quando elegível, as VMs passam por live migration sem reboot, com pausa de poucos segundos. Isso vale para muitas VMs da série M, mas não todas. Quando não dá, o aviso com prazo de redeploy e ação recomendada aparece no Resource Health e em Scheduled Events. Para o operador, o ponto prático são os quatro canais de notificação: Resource Health (uma VM), Resource Graph (consulta em escala), Event Grid (automação por push, com Azure Functions, webhooks ou REST) e Scheduled Events via IMDS. O conteúdo da notificação é o mesmo nos três primeiros. A Microsoft recomenda preparar a automação para eventos com NotBefore de até sete dias e, em clusters SAP HA, configurar o agente Pacemaker azure-events-az. Os números citados: 36% a mais na prevenção de interrupções de VMs por hardware, 80% a mais na taxa mensal de reparo de nós e mais de 36% menos reboots de hardware.

Para quem opera workloads sensíveis a downtime no Azure, o AFPD não exige configuração na camada de infraestrutura, mas o ganho só chega até você se sua automação ouvir os eventos. Se o seu runbook ainda depende de alguém notar um reboot, vale revisar o consumo de Scheduled Events e Event Grid. A leitura é nossa: o padrão de detectar cedo, drenar o nó e reparar com peça já posicionada é o mesmo que equipes de GPU em Kubernetes vêm montando por conta própria.