Laboratório de Troubleshooting: Configure an internal or public load balancer
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações reporta que uma aplicação web exposta via Azure Load Balancer Standard público parou de responder aos clientes externos às 14h32. As VMs do backend pool estão em execução, os NSGs permitem tráfego na porta 80, e o time confirma que nenhuma alteração foi feita nas regras de balanceamento ou no frontend IP nas últimas 48 horas.
O engenheiro de plantão coleta as seguintes informações:
Health probe status (portal Azure):
vm-web-01: Degraded
vm-web-02: Degraded
vm-web-03: Degraded
NSG associado à subnet do backend:
Regra 100 - Allow - TCP - Any - 80 - Inbound
Regra 200 - Allow - TCP - Any - 443 - Inbound
Regra 65000 - Allow - VirtualNetwork - Any - Any - Inbound
Regra 65001 - Allow - AzureLoadBalancer - Any - Any - Inbound
Verificação de conectividade direta (via Bastion):
curl http://localhost:80 -> HTTP 200 OK (em todas as VMs)
Evento recente no Activity Log:
14h28 - Modificação de NSG: subnet-backend
O IP público do Load Balancer permanece acessível via ping. A aplicação responde localmente em todas as VMs. O time menciona que a versão da aplicação foi atualizada na véspera, mas o deploy foi concluído sem erros.
Qual é a causa raiz do problema?
A) A atualização da aplicação introduziu um bug que faz as VMs responderem localmente mas rejeitar conexões externas B) Uma regra de NSG adicionada às 14h28 está bloqueando o tráfego do health probe do Azure Load Balancer, fazendo todas as instâncias serem marcadas como degradadas C) O frontend IP público foi dissociado do Load Balancer durante a janela de modificação do NSG D) O Load Balancer Standard requer que as VMs tenham IPs públicos individuais para funcionar corretamente com health probes HTTP
Cenário 2 — Decisão de Ação
A causa de uma falha foi identificada: o Internal Load Balancer que serve a camada de aplicação perdeu todas as instâncias do backend pool porque as VMs foram migradas para uma nova subnet durante uma reorganização de rede. A nova subnet pertence à mesma VNet. O serviço está totalmente indisponível para os usuários internos.
O contexto operacional é o seguinte:
- O ambiente é de produção e atende pedidos de e-commerce em tempo real
- A janela de manutenção oficial começa em 4 horas
- O time tem permissão de Contributor no Resource Group
- Recriar o Load Balancer do zero levaria aproximadamente 40 minutos
- Adicionar as VMs da nova subnet ao backend pool existente leva menos de 5 minutos e não requer downtime adicional
- O time de segurança deve ser notificado antes de qualquer alteração de topologia de rede
Qual é a ação correta a tomar neste momento?
A) Aguardar a janela de manutenção oficial em 4 horas e executar a correção com o processo completo de change management B) Recriar o Load Balancer do zero imediatamente para garantir uma configuração limpa e sem inconsistências C) Adicionar as VMs da nova subnet ao backend pool existente agora, notificando o time de segurança em paralelo, para restaurar o serviço com o menor impacto possível D) Reverter a migração das VMs para a subnet original e planejar a reorganização de rede para a próxima janela de manutenção
Cenário 3 — Causa Raiz
Um desenvolvedor relata que após criar um Azure Load Balancer Standard público para um novo ambiente de testes, as VMs do backend conseguem receber tráfego normalmente, mas qualquer tentativa de acesso externo a partir das próprias VMs (por exemplo, chamadas a APIs externas durante a execução da aplicação) falha com timeout.
Teste executado a partir de vm-test-01:
curl -v https://api.parceiro.com/health --max-time 10
* Trying 203.0.113.45:443...
* Connection timed out after 10001 milliseconds
curl: (28) Connection timed out after 10001 milliseconds
Teste executado a partir de vm-test-01 (DNS):
nslookup api.parceiro.com
Server: 168.63.129.16
Address: 168.63.129.16#53
Name: api.parceiro.com
Address: 203.0.113.45
Configuração do Load Balancer:
SKU: Standard
Frontend IP: 52.170.20.10 (Public)
Backend pool: vm-test-01, vm-test-02
Load balancing rule: TCP 80 -> 80
Outbound rules: nenhuma configurada
Health probe: TCP 80, intervalo 5s
O NSG da subnet permite todo o tráfego de saída. As VMs não possuem IPs públicos individuais. A resolução DNS funciona corretamente.
Qual é a causa raiz do problema?
A) O NSG está bloqueando o tráfego de saída apesar de indicar permissão, pois regras implícitas do Azure têm precedência sobre regras explícitas de allow B) O health probe TCP impede conexões de saída enquanto está em execução, pois consome a capacidade de SNAT disponível C) O Azure Load Balancer Standard não provisiona SNAT implícito para tráfego de saída, e sem uma outbound rule ou NAT Gateway, as VMs sem IP público não conseguem iniciar conexões externas D) O frontend IP do Load Balancer está configurado como estático, o que bloqueia o uso de SNAT dinâmico para tráfego de saída
Cenário 4 — Sequência de Diagnóstico
Um engenheiro recebe o seguinte alerta às 09h15:
"Clientes relatam intermitência no acesso à aplicação exposta pelo Load Balancer. Alguns usuários conseguem acessar, outros recebem timeout. O problema começou há cerca de 20 minutos."
O ambiente possui um Azure Load Balancer Standard público com quatro VMs no backend pool. O engenheiro tem acesso ao portal Azure e às VMs via Bastion.
Os passos de investigação disponíveis são:
- P1: Verificar o status do health probe de cada instância no portal Azure
- P2: Acessar uma das VMs via Bastion e testar a aplicação localmente com curl
- P3: Analisar os logs da aplicação nas VMs para identificar erros ou exceções recentes
- P4: Verificar o Activity Log do Load Balancer e dos NSGs para alterações recentes
- P5: Confirmar se o frontend IP público está respondendo a conexões TCP na porta correta
Qual é a sequência de diagnóstico mais eficiente para este sintoma?
A) P5 -> P1 -> P4 -> P2 -> P3 B) P2 -> P3 -> P1 -> P5 -> P4 C) P1 -> P2 -> P4 -> P5 -> P3 D) P4 -> P5 -> P1 -> P2 -> P3
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no Activity Log: uma modificação de NSG ocorreu às 14h28, quatro minutos antes do início da falha às 14h32. O health probe do Azure Load Balancer origina tráfego a partir do endereço especial 168.63.129.16, que pertence à tag de serviço AzureLoadBalancer. Se uma regra de NSG adicionada nesse momento bloqueou o tráfego dessa origem na porta do probe, todas as instâncias seriam marcadas como degradadas simultaneamente, e o Load Balancer pararia de encaminhar tráfego mesmo com as VMs funcionando.
A resposta A é o distrator mais perigoso: a atualização da aplicação na véspera cria uma narrativa plausível, mas a aplicação responde com HTTP 200 localmente em todas as VMs, o que contradiz diretamente a hipótese de bug de aplicação. A atualização é informação irrelevante neste contexto. A resposta C é falsa porque o Activity Log não registra dissociação de frontend IP, apenas modificação de NSG. A resposta D inventa um requisito que não existe no Load Balancer Standard.
O erro mais perigoso seria iniciar um rollback da aplicação baseado na correlação temporal com o deploy anterior, desperdiçando tempo enquanto a causa real permanece ativa.
Gabarito — Cenário 2
Resposta: C
O enunciado declara explicitamente a causa (VMs migradas para nova subnet) e apresenta as restrições do contexto. A correção correta é adicionar as VMs ao backend pool existente, pois essa ação leva menos de 5 minutos, não requer downtime adicional, e restaura o serviço de produção imediatamente. Notificar o time de segurança em paralelo respeita o processo sem sacrificar a disponibilidade do serviço.
A alternativa A ignora a criticidade do ambiente de produção ativo: aguardar 4 horas com o serviço totalmente indisponível é inaceitável quando existe uma correção rápida e segura disponível. A alternativa B é tecnicamente válida mas desproporcional ao problema e ao tempo disponível: recriar o Load Balancer levaria 40 minutos sem necessidade, pois a configuração existente está correta. A alternativa D reverteria uma mudança arquitetural planejada e causaria um segundo ciclo de indisponibilidade, tornando o problema maior do que era.
O ponto crítico deste cenário é distinguir entre a ação tecnicamente mais completa e a ação correta dado o contexto de restrições reais.
Gabarito — Cenário 3
Resposta: C
O conjunto de evidências aponta diretamente para ausência de SNAT. As VMs não têm IPs públicos individuais, não há outbound rules configuradas, e o SKU é Standard. Sem um caminho de saída configurado explicitamente, o tráfego originado nas VMs não tem como ser traduzido para um IP público roteável na internet. O timeout ocorre porque os pacotes saem da VM mas são descartados ao tentar atravessar a internet sem endereço de origem válido.
A alternativa A está incorreta: o NSG permite explicitamente todo o tráfego de saída, e regras implícitas do Azure só negam tráfego quando não há regra explícita correspondente. A resolução DNS funciona corretamente, o que também contradiz um bloqueio de NSG generalizado. A alternativa B é falsa: health probes são conexões de entrada no backend, não consomem SNAT. A alternativa D inventa uma restrição que não existe no Azure: a natureza estática ou dinâmica do frontend IP não interfere na disponibilidade de SNAT.
A informação irrelevante neste cenário é a resolução DNS funcionando corretamente. Ela confirma que o problema não é de DNS, mas não ajuda a identificar a causa raiz do timeout de conexão TCP.
Gabarito — Cenário 4
Resposta: A
A sequência correta é P5 -> P1 -> P4 -> P2 -> P3, pois segue a lógica de diagnóstico progressivo do ponto de entrada até a causa.
P5 primeiro: verificar se o frontend IP responde a conexões TCP confirma se o problema está no Load Balancer ou antes dele. Isso elimina ou confirma o componente de entrada com uma verificação rápida e sem acesso às VMs.
P1 em seguida: o status dos health probes revela imediatamente se o Load Balancer considera as instâncias saudáveis. Intermitência com algumas instâncias degradadas explica por que alguns usuários conseguem acesso e outros não.
P4 depois: o Activity Log revela se houve mudança recente que possa explicar o início do problema às 08h55, correlacionando tempo e alteração.
P2 em seguida: testar localmente nas VMs confirma se a aplicação está respondendo, separando problemas de rede de problemas de aplicação.
P3 por último: os logs de aplicação são a investigação mais demorada e são acessados somente após confirmar que o problema está na camada de aplicação, evitando trabalho desnecessário.
A alternativa B começa nas VMs antes de verificar o Load Balancer, ignorando que o sintoma pode estar no componente de entrada. A alternativa D começa pelo Activity Log, que é útil mas não confirma o estado atual do sistema. A alternativa C verifica o health probe antes de confirmar se o frontend está acessível, invertendo a prioridade.
Árvore de Troubleshooting: Configure an internal or public load balancer
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou verificação) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou estado resolvido |
| Laranja | Validação ou verificação intermediária |
Diante de um problema real, comece pelo nó raiz identificando o sintoma principal. Siga as ramificações respondendo cada pergunta com base no que você observa no ambiente, não no que você suspeita. Perguntas de cor azul são verificáveis diretamente no portal Azure, via CLI ou via Bastion, sem suposições. Quando chegar a um nó vermelho, você tem a causa raiz. Quando chegar a um nó verde, você tem a ação ou confirmação de resolução. Nós laranja indicam que é necessário coletar mais informação antes de prosseguir.