Laboratório de Troubleshooting: Choose between manual and autoscale
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Um Azure Application Gateway v2 está em produção com autoscale configurado conforme abaixo. O ambiente foi recentemente migrado de v1 para v2 e a equipe de operações está monitorando o comportamento nas primeiras semanas.
{
"sku": {
"name": "WAF_v2",
"tier": "WAF_v2"
},
"autoscaleConfiguration": {
"minCapacity": 2,
"maxCapacity": 5
}
}
Durante um evento de carga elevada na tarde de uma sexta-feira, o time de monitoramento observa os seguintes dados no Azure Monitor:
Metric: ComputeUnits
Timestamp Value
14:32:00 4.8
14:33:00 4.9
14:34:00 5.0
14:35:00 5.0
14:36:00 5.0
Metric: FailedRequests
Timestamp Value
14:35:00 312
14:36:00 489
14:37:00 601
A equipe nota que a região em uso tem disponibilidade normal e que o certificado TLS do listener foi renovado com sucesso dois dias antes. O gateway está associado a um WAF policy no modo Prevention com ruleset OWASP 3.2, sem alterações recentes nas regras.
Qual é a causa raiz do aumento de FailedRequests observado a partir de 14:35?
A) O WAF policy em modo Prevention está bloqueando requisições legítimas após uma atualização automática do ruleset OWASP
B) O maxCapacity: 5 foi atingido e o gateway não consegue provisionar novas instâncias para absorver a carga adicional
C) O certificado TLS recém-renovado possui algoritmo incompatível com parte dos clientes, gerando falhas de handshake
D) A região está enfrentando degradação silenciosa não refletida no painel de disponibilidade
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que um Azure Application Gateway v2 em produção está configurado com manual scaling com capacity: 3. O sistema é usado por uma aplicação financeira com SLA de 99,9%, que processa transações durante horário comercial de segunda a sexta. Às 17h45 de uma quinta-feira, o on-call recebe alertas indicando que o gateway está próximo da capacidade máxima das 3 instâncias configuradas, com pico esperado ainda nos próximos 20 minutos.
A causa foi confirmada: o volume de transações está acima do previsto devido a um fechamento de mês antecipado solicitado pelo negócio. A mudança não foi comunicada ao time de infraestrutura com antecedência.
Não há uma janela de mudança aprovada para essa tarde. A política interna exige aprovação prévia para alterações em produção, mas admite exceções documentadas em caso de risco iminente de SLA.
Qual é a ação correta a tomar neste momento?
A) Aguardar a aprovação formal de uma janela de mudança antes de qualquer alteração, pois modificar produção sem janela viola a política independentemente do risco
B) Aumentar capacity de 3 para 8 imediatamente via portal, sem registro, para restabelecer margem de capacidade antes do pico
C) Acionar o processo de exceção documentada, registrar o risco iminente de SLA e executar o aumento de capacity com aprovação emergencial
D) Migrar o gateway de manual scaling para autoscale imediatamente para evitar o problema de forma definitiva
Cenário 3 — Causa Raiz
Um engenheiro está revisando os logs de um Azure Application Gateway v2 recentemente provisionado em ambiente de desenvolvimento. A equipe relatou que, após um período sem tráfego durante o fim de semana, as primeiras requisições de segunda-feira pela manhã apresentam tempo de resposta acima de 30 segundos, normalizando após alguns minutos.
O engenheiro coleta as seguintes informações do ambiente:
SKU: Standard_v2
autoscaleConfiguration:
minCapacity: 0
maxCapacity: 4
Backend pool: 2 VMs (status: healthy)
Health probe interval: 30s
Health probe threshold: 3
Ultimo log de instancia ativa:
Friday 18:47:22 - Instance count: 1
Friday 20:03:11 - Instance count: 0
Monday 08:01:44 - Instance count: 0
Monday 08:02:31 - Instance count: 1
Monday 08:02:58 - Request served successfully
O engenheiro verifica adicionalmente que o backend pool está saudável, que não houve alteração de configuração no fim de semana e que o NSG associado à subnet do gateway não foi modificado.
Qual é a causa raiz da alta latência nas primeiras requisições de segunda-feira?
A) O health probe com intervalo de 30 segundos e threshold de 3 está marcando os backends como unhealthy após o fim de semana
B) As VMs do backend pool entram em modo de hibernação durante períodos sem tráfego, aumentando o tempo de resposta inicial
C) Com minCapacity: 0, o gateway escala para zero instâncias e precisa de tempo para provisionar ao receber as primeiras requisições
D) A configuração do NSG na subnet bloqueia temporariamente o tráfego após períodos prolongados de inatividade
Cenário 4 — Impacto Colateral
Um time de operações identificou que um Azure Application Gateway v2 configurado com minCapacity: 0 e maxCapacity: 8 estava causando latência elevada nas primeiras requisições após períodos de inatividade. Para resolver o problema, o time aumentou minCapacity de 0 para 2, garantindo que pelo menos duas instâncias permaneçam sempre ativas.
A ação resolveu o problema de latência inicial e foi considerada bem-sucedida pelo time.
Qual consequência secundária essa mudança introduz no ambiente?
A) O gateway passa a rejeitar conexões TLS quando operar com exatamente 2 instâncias, exigindo um mínimo de 3 para estabilidade
B) O custo fixo mensal do gateway aumenta, pois as 2 instâncias do minCapacity são cobradas continuamente mesmo sem tráfego
C) O maxCapacity: 8 deixa de ser respeitado, pois o autoscale não opera corretamente quando minCapacity é maior que zero
D) O Azure Monitor deixa de emitir alertas de escalonamento, pois interpreta o minCapacity: 2 como capacidade suficiente permanente
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na métrica ComputeUnits, que atinge exatamente 5.0 e permanece nesse valor nos minutos seguintes, coincidindo com o início do aumento de FailedRequests. O valor 5.0 corresponde ao maxCapacity configurado. Quando o gateway atinge o limite máximo de instâncias, ele não consegue escalar além desse ponto e passa a rejeitar ou falhar requisições que excedem a capacidade disponível.
As informações sobre a renovação do certificado TLS e a política WAF são propositalmente incluídas como distrações. O certificado foi renovado dois dias antes sem incidentes, e o WAF policy não teve alterações recentes. A causa mais óbvia que um diagnóstico apressado seguiria seria o WAF (alternativa A), pois está em modo Prevention. Porém, os logs de ComputeUnits saturam exatamente no teto configurado antes das falhas, o que é a evidência determinante.
O distrator mais perigoso é a alternativa A: agir sobre o WAF policy com base nessa hipótese poderia resultar em desativação indevida de regras de segurança sem resolver o problema real.
Gabarito — Cenário 2
Resposta: C
A causa já está identificada e confirmada no enunciado. O que está em jogo é a decisão correta dentro das restrições descritas: sem janela aprovada, com SLA em risco iminente e com política que admite exceção documentada.
A alternativa C é a única que respeita simultaneamente as duas dimensões do problema: o risco técnico real (SLA em risco) e a restrição organizacional (política de mudança). O processo de exceção existe precisamente para esses casos.
A alternativa A ignora o risco iminente de SLA e aplica a política de forma rígida onde ela própria prevê flexibilidade. A alternativa B executa a ação correta de forma incorreta, violando a política sem registro e criando risco de auditoria. A alternativa D é a pior escolha possível nesse momento: migrar de manual para autoscale em produção sem janela, durante uma crise ativa, é uma mudança arquitetural que pode introduzir novos problemas em um momento crítico. Mesmo que autoscale seja a solução de longo prazo, o momento e o método estão completamente errados.
Gabarito — Cenário 3
Resposta: C
O log de instâncias é a evidência direta e suficiente para o diagnóstico. A sequência mostra claramente que o gateway foi para Instance count: 0 na sexta à noite e permaneceu assim até a segunda de manhã. O intervalo entre a primeira requisição (08:01:44) e o atendimento bem-sucedido (08:02:58) representa exatamente o tempo de provisionamento de uma nova instância a partir de zero.
As informações sobre o backend pool saudável e a ausência de alterações no NSG são irrelevantes para esse diagnóstico e foram incluídas para simular o ruído informacional real de uma investigação. O distrator mais tentador é a alternativa A, pois o health probe com intervalo de 30 segundos e threshold de 3 poderia, em teoria, marcar backends como unhealthy. No entanto, o enunciado declara explicitamente que o backend pool está saudável, eliminando essa hipótese. A alternativa B descreve um comportamento que não existe no Application Gateway: o gateway não controla o estado de energia das VMs do backend.
Gabarito — Cenário 4
Resposta: B
Aumentar minCapacity de 0 para 2 resolve o problema de cold start porque garante que duas instâncias estejam sempre prontas. No entanto, essa decisão tem um custo direto e imediato: as instâncias correspondentes ao minCapacity são sempre provisionadas e cobradas, independentemente do volume de tráfego. Em um ambiente de desenvolvimento com longos períodos de inatividade, isso representa uma mudança significativa no perfil de custo mensal.
As demais alternativas descrevem comportamentos que não existem no Application Gateway. O TLS não tem restrição de instâncias mínimas (alternativa A). O maxCapacity continua sendo respeitado normalmente com qualquer valor de minCapacity menor que ele (alternativa C). O Azure Monitor não altera seu comportamento de alertas com base no valor de minCapacity (alternativa D).
O ponto central deste cenário é desenvolver a consciência de que toda ação corretiva em escalonamento tem um impacto no modelo de custo, e esse impacto deve ser avaliado antes da implementação, não depois.
Árvore de Troubleshooting: Choose between manual and autoscale
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou decisão de resolução |
| Laranja | Validação ou verificação intermediária |
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ê pode verificar no Azure Monitor, nos logs do gateway ou na configuração atual. Cada caminho termina em uma causa nomeada ou em uma ação concreta. Se o diagnóstico chegar a um nó de validação em laranja, colete a evidência indicada antes de avançar para a próxima ramificação.