Laboratório de Troubleshooting: Provision an App Service plan
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações relata que uma Web App em produção está respondendo com latência crescente nas últimas horas. O time informa que nenhuma alteração de código foi feita recentemente. O App Service plan utilizado é Standard S1, com duas instâncias configuradas via scale-out manual. A aplicação roda em um plano Windows na região East US.
Durante a investigação, o engenheiro executa o seguinte comando para verificar o estado do plano:
az appservice plan show \
--name plano-producao \
--resource-group rg-app \
--query "{sku:sku.name, workers:sku.capacity, status:status}" \
--output table
A saída retornada é:
Sku Workers Status
----- --------- --------
S1 2 Ready
Em seguida, o engenheiro verifica as métricas do plano no portal e observa o seguinte:
| Métrica | Valor observado |
|---|---|
| CPU Percentage | 94% |
| Memory Percentage | 41% |
| Disk Queue Length | 0 |
| HTTP Queue Length | 312 |
O engenheiro também nota que três outras Web Apps foram adicionadas ao mesmo App Service plan há dois dias, totalizando cinco aplicações no plano. A equipe de desenvolvimento menciona que a região East US teve uma instabilidade de rede registrada ontem, já resolvida.
Qual é a causa raiz da degradação de desempenho observada?
A) Instabilidade residual de rede na região East US afetando a conectividade da aplicação. B) Insuficiência de instâncias no plano para absorver a carga total gerada pelas cinco aplicações compartilhando os mesmos recursos. C) Vazamento de memória na aplicação, evidenciado pelo crescimento progressivo de latência. D) O tier S1 não suporta mais de duas instâncias simultâneas, criando um gargalo de capacidade.
Cenário 2 — Decisão de Ação
A causa do problema já foi identificada: o App Service plan de produção está no tier Free (F1) e atingiu o limite diário de minutos de CPU permitidos pelo tier. A aplicação retorna HTTP 403 com a mensagem abaixo para todos os usuários até o resetamento do contador no dia seguinte.
The Free plan has reached its quota.
Please upgrade your App Service plan.
O ambiente possui as seguintes restrições:
- A aplicação é um sistema de pedidos de uma rede de varejo, com operação crítica durante todo o dia
- O time de infraestrutura tem permissão para modificar recursos no Resource Group de produção
- Não há janela de manutenção programada disponível
- O time de desenvolvimento está indisponível neste momento
- A empresa possui um acordo de nível de serviço com os clientes que exige retomada do serviço em até 30 minutos
Qual é a ação correta a tomar neste momento?
A) Aguardar o resetamento automático do limite de CPU no dia seguinte, pois qualquer alteração de plano fora de janela de manutenção representa risco operacional. B) Excluir a Web App atual e recriar toda a aplicação em um novo App Service plan com tier Basic ou superior. C) Realizar o upgrade do App Service plan para um tier pago (Basic ou superior) diretamente pelo portal ou via CLI, sem necessidade de recriar a aplicação. D) Criar um novo App Service plan no tier Standard e mover a aplicação via clone para o novo plano, garantindo zero downtime.
Cenário 3 — Causa Raiz
Um engenheiro tenta executar o seguinte comando para criar uma nova Web App e associá-la a um App Service plan existente:
az webapp create \
--name minha-app-linux \
--resource-group rg-producao \
--plan plano-existente \
--runtime "NODE|18-lts"
O comando retorna o seguinte erro:
The plan 'plano-existente' is not a valid option.
WebApp 'minha-app-linux' requires a Linux App Service Plan.
(WebSpacesClient.CreateOrUpdateWebspace) ErrorCode=InvalidWebSpaceRequest
O engenheiro verifica o plano existente com o comando abaixo:
az appservice plan show \
--name plano-existente \
--resource-group rg-producao \
--query "{sku:sku.name, os:kind, region:location}" \
--output table
Saída:
Sku Os Region
----- -------- ----------
B2 app eastus
O engenheiro também informa que o Resource Group rg-producao já contém outro App Service plan Linux na mesma região, criado há três meses, atualmente sem aplicações associadas. O runtime NODE|18-lts é suportado no tier B2.
Qual é a causa raiz do erro?
A) O runtime NODE|18-lts requer um tier Standard ou superior e não é compatível com B2.
B) O plano plano-existente é um plano Windows e não pode hospedar aplicações que exigem runtime Linux.
C) Não é possível ter dois App Service plans Linux no mesmo Resource Group, gerando conflito.
D) O erro ocorre porque o Resource Group rg-producao está em uma região diferente da aplicação sendo criada.
Cenário 4 — Impacto Colateral
Um administrador identifica que o App Service plan de uma aplicação está no tier Standard S2 com 5 instâncias ativas, configuradas via autoscale com regras baseadas em CPU. Para reduzir custos imediatamente, o administrador faz o downgrade do plano para o tier Basic B2.
A operação é concluída com sucesso e a aplicação continua respondendo normalmente nos primeiros minutos após a mudança.
Qual consequência secundária esse downgrade pode causar?
A) As 5 instâncias existentes serão mantidas, mas o custo por instância do tier Basic será maior do que o Standard, não gerando economia real. B) As regras de autoscale configuradas no plano deixarão de funcionar, pois o tier Basic não suporta autoscale automático baseado em métricas. C) A aplicação perderá imediatamente todos os deployment slots configurados, causando indisponibilidade do ambiente de staging. D) O certificado SSL customizado associado à aplicação será revogado, pois custom domains com SSL requerem tier Standard ou superior.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está na combinação de duas informações: a adição de três novas Web Apps ao plano dois dias antes do início do problema, e as métricas mostrando CPU em 94% e HTTP Queue Length em 312. Todas as aplicações em um App Service plan compartilham os mesmos recursos computacionais. O crescimento do número de aplicações aumentou a demanda sobre a mesma capacidade de CPU, saturando o plano.
A informação sobre a instabilidade de rede na região East US é deliberadamente irrelevante: o evento já estava resolvido e não explicaria CPU persistentemente alta. Escolher A seria o erro de diagnosticar com base no evento mais recente visível, ignorando os dados de métrica.
A alternativa C é incorreta porque memória está em 41%, sem sinal de pressão. A alternativa D é tecnicamente falsa: o tier S1 suporta até 10 instâncias. O distrator mais perigoso é A, pois desvia a investigação para um evento externo já encerrado, atrasando a solução real.
Gabarito — Cenário 2
Resposta: C
O upgrade de um App Service plan é uma operação in-place que não exige recriação da aplicação nem downtime planejado. A Web App continua associada ao mesmo plano após o upgrade, retomando o serviço imediatamente após a mudança de tier. Dado o SLA de 30 minutos, essa é a única ação que resolve o problema dentro do prazo sem risco adicional.
A alternativa A ignora completamente a restrição de SLA, tornando-a inaceitável. A alternativa B descreve uma ação tecnicamente possível, mas desnecessariamente destrutiva e lenta, violando o SLA. A alternativa D é incorreta porque o "clone" de aplicação não é equivalente a um move e introduz complexidade e risco desnecessários quando o upgrade direto resolve o problema. O distrator mais perigoso é D, pois parece técnica e cuidadosa, mas ignora que a simplicidade e a velocidade são determinantes dado o contexto de SLA ativo.
Gabarito — Cenário 3
Resposta: B
A saída do comando az appservice plan show mostra kind: app, que identifica um plano Windows. O runtime NODE|18-lts em modo Linux requer um App Service plan Linux. Essa incompatibilidade de sistema operacional entre o plano e o runtime solicitado é a causa exata do erro descrito na mensagem.
A informação sobre o plano Linux já existente no Resource Group é deliberadamente irrelevante: a presença de outro plano Linux não causa nem impede a criação de um novo plano Linux, e não era a causa do erro. A alternativa C inverte a lógica real do Azure: múltiplos planos Linux podem coexistir no mesmo Resource Group. A alternativa A é falsa porque NODE|18-lts é compatível com B2. O distrator mais perigoso é C, pois o engenheiro poderia concluir erroneamente que o plano Linux existente está bloqueando a operação e deletá-lo desnecessariamente.
Gabarito — Cenário 4
Resposta: B
O tier Basic não suporta autoscale baseado em métricas. Ao fazer downgrade de Standard para Basic, as regras de autoscale configuradas no plano deixam de ser executadas. O plano passa a operar apenas com scale-out manual. Em um cenário de pico de tráfego futuro, o plano não escalará automaticamente, podendo causar degradação ou indisponibilidade que antes era tratada automaticamente.
A alternativa A é tecnicamente falsa: o custo por instância do Basic é inferior ao Standard. A alternativa D é incorreta porque custom domains com SSL continuam suportados no tier Basic. A alternativa C é o distrator mais perigoso: deployment slots realmente são removidos no downgrade do Standard para o Basic, mas o enunciado especifica que a aplicação "continua respondendo normalmente nos primeiros minutos", o que indica que não havia slots ativos em uso neste caso. O impacto real e imediato relevante ao cenário é a perda silenciosa do autoscale, que só se manifestará na próxima vez que a carga aumentar.
Árvore de Troubleshooting: Provision an App Service plan
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou de estado) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou verificação intermediária |
Para usar esta árvore diante de um problema real, comece sempre pelo nó raiz descrevendo o sintoma observado. A cada nó de pergunta, responda com base no que você pode verificar diretamente no portal, na CLI ou nas métricas do plano. Siga o caminho correspondente à sua observação até atingir um nó vermelho de causa identificada, e então execute a ação verde correspondente. Se o problema não se encaixar no caminho óbvio, retorne ao nó anterior e considere a hipótese alternativa antes de agir.