Laboratório de Troubleshooting: Create an App Service
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de desenvolvimento implantou uma aplicação Node.js 18 em um App Service recém-criado no Azure. O App Service Plan utilizado é o tier Standard S2, rodando em Linux. A aplicação foi publicada via GitHub Actions com sucesso, e o pipeline reportou status 200 na etapa de deploy.
Ao acessar a URL pública da aplicação, o navegador retorna consistentemente o seguinte erro:
Application Error
An error occurred while starting the application.
O time verifica os logs de diagnóstico no portal e encontra:
[2025-10-14 13:42:01] INFO Deployment successful
[2025-10-14 13:42:03] ERROR Failed to find a matching page for route: /
[2025-10-14 13:42:03] ERROR npm ERR! missing script: start
[2025-10-14 13:42:04] INFO Container exited with code 1
Informações adicionais coletadas pelo time:
- O App Service Plan tem 3 instâncias ativas configuradas para autoscale
- O Application Insights está habilitado e mostrando latência de 0ms (sem requisições chegando ao app)
- O repositório no GitHub está público
- O arquivo
package.jsonda aplicação não contém a propriedadescripts.start
Qual é a causa raiz do erro observado?
A) O autoscale com 3 instâncias está causando conflito de estado durante a inicialização da aplicação.
B) O App Service não consegue iniciar o processo da aplicação porque o script de entrada não está definido no package.json.
C) O Application Insights está interceptando as requisições antes de chegarem à aplicação, causando falha silenciosa.
D) O repositório público no GitHub está expondo variáveis de ambiente sensíveis que o App Service rejeita por política de segurança.
Cenário 2 — Decisão de Ação
Uma aplicação crítica de e-commerce está rodando no slot de produção de um App Service (tier Premium P2v3, Windows). O time de desenvolvimento realizou um swap entre o slot de staging e o slot de produção às 14h. Às 14h08, começaram a chegar alertas de que a taxa de erros HTTP 500 subiu de 0,2% para 38%.
A causa já foi identificada: uma variável de ambiente chamada CONNECTION_STRING_DB foi configurada no slot de staging com um valor de teste apontando para um banco de dados de homologação. Após o swap, essa variável foi promovida para produção junto com o código, substituindo a string de conexão do banco de dados real.
O contexto atual é:
- São 14h11 e o tráfego em produção está degradado
- A aplicação anterior (antes do swap) ainda está disponível no slot de staging
- O time de banco de dados está em reunião e não pode ser contatado nos próximos 20 minutos
- O valor correto da
CONNECTION_STRING_DBde produção não está documentado em nenhum runbook acessível no momento
Qual é a ação correta a tomar neste momento?
A) Executar um novo swap imediato para reverter o slot de staging de volta para produção, restaurando o ambiente anterior incluindo suas variáveis de ambiente.
B) Acessar o painel de configurações do App Service em produção e atualizar manualmente a CONNECTION_STRING_DB com o valor correto consultando o time de banco de dados.
C) Escalar horizontalmente o App Service para 10 instâncias para distribuir a carga e reduzir o impacto dos erros enquanto a correção é preparada.
D) Desabilitar temporariamente o Application Insights para evitar que os alertas continuem sendo disparados durante a investigação.
Cenário 3 — Causa Raiz
Um administrador criou um App Service para hospedar uma API REST desenvolvida em .NET 8. O App Service Plan é Basic B2, rodando em Windows. A aplicação funciona corretamente em desenvolvimento local.
Após o deploy, a equipe de QA reporta que ao acessar o endpoint /health, a resposta demora mais de 30 segundos na primeira chamada após um período de inatividade, mas responde normalmente em chamadas subsequentes.
O administrador acessa as configurações e observa:
Always On: Off
ARR Affinity: On
HTTP version: 1.1
TLS minimum version: 1.2
Informações adicionais:
- O App Service está em uma região diferente da equipe de QA (Brasil South vs East US)
- Os testes de QA são sempre feitos a partir de um script automatizado que aguarda 45 minutos entre cada execução
- O App Service Plan tem 2 instâncias configuradas manualmente
- O deployment foi feito via Visual Studio Publish e o status final foi
Publish succeeded
Qual é a causa raiz do comportamento observado?
A) A latência geográfica entre Brasil South e East US está causando timeout na primeira requisição após inatividade. B) O App Service está descarregando o processo da aplicação após inatividade e a configuração que manteria o processo ativo está desabilitada. C) O ARR Affinity habilitado está redirecionando a primeira requisição para uma instância fria enquanto a outra instância está ativa. D) O HTTP 1.1 configurado está causando overhead de handshake na primeira conexão após o idle timeout do load balancer.
Cenário 4 — Sequência de Diagnóstico
Um App Service em produção passou a retornar erro HTTP 503 para todas as requisições após uma atualização de configuração realizada pelo time de operações. O time precisa diagnosticar a causa antes de agir.
Os seguintes passos de investigação estão disponíveis, fora de ordem:
- Passo P: Verificar o status do App Service Plan e confirmar se o tier atual suporta a quantidade de instâncias configuradas
- Passo Q: Acessar o Kudu (SCM) do App Service e verificar se o processo da aplicação está em execução em
Process Explorer - Passo R: Confirmar se as alterações de configuração recentes incluíram mudança de tier do App Service Plan para um tier inferior
- Passo S: Verificar os logs de aplicação em
Log Streampara identificar se há exceções no startup da aplicação - Passo T: Checar o painel de
Health Checkno App Service para validar se o endpoint de health está respondendo internamente
Qual sequência representa o raciocínio diagnóstico correto, partindo do mais amplo para o mais específico?
A) R, P, Q, T, S B) Q, S, T, R, P C) S, T, Q, P, R D) T, Q, S, R, P
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O log é explícito na sequência causal: npm ERR! missing script: start seguido de Container exited with code 1. O runtime do App Service para Node.js no Linux tenta executar npm start como ponto de entrada padrão. Quando o package.json não define essa propriedade, o processo não consegue iniciar e o container encerra imediatamente com código de erro 1, resultando no "Application Error" exibido ao usuário.
Informação irrelevante: O número de instâncias com autoscale (3 instâncias ativas) não tem qualquer relação com falha de startup. O autoscale não interfere no processo de inicialização de um runtime de aplicação. Essa informação foi incluída para induzir o diagnóstico na direção errada, simulando um problema de infraestrutura quando o problema é de configuração de código.
O distrator mais perigoso é A, pois conflito de estado em múltiplas instâncias é um problema real em App Services, porém ele se manifestaria como comportamento inconsistente entre requisições, não como falha total e imediata de startup. O distrator C é implausível: Application Insights opera como SDK dentro da aplicação ou como agente passivo, nunca como interceptor que impede a inicialização. O distrator D descreve um comportamento inexistente no Azure.
Agir com base em A levaria o time a reduzir instâncias ou desabilitar autoscale, o que não resolveria nada e consumiria tempo de incidente desnecessariamente.
Gabarito — Cenário 2
Resposta: A
O swap reverso é a única ação que restaura o ambiente de produção ao estado funcional anterior em menos de 2 minutos, sem necessidade de conhecer o valor correto da string de conexão. Quando um swap é executado, o Azure troca os slots incluindo suas variáveis de ambiente não marcadas como slot settings. O slot de staging ainda contém o ambiente anterior de produção (com a string de conexão correta), pois o swap não destrói o conteúdo do slot de origem.
O distrator B é correto como solução definitiva, mas é inviável no contexto dado: o time de banco de dados está indisponível por 20 minutos e o valor correto não está documentado. Executar B significaria deixar 38% de erros HTTP 500 em produção por no mínimo 20 minutos sem garantia de resolução.
O distrator C é o mais perigoso: escalar horizontalmente um App Service que está falhando por configuração incorreta apenas multiplica as instâncias com erro, aumentando o consumo de recursos sem reduzir a taxa de falha em nenhuma proporção. O distrator D é operacionalmente incorreto pois desabilitar Application Insights não resolve o problema subjacente e ainda remove visibilidade do incidente.
A lição central deste cenário é que swap reverso é um mecanismo de rollback real e imediato, e deve ser a primeira ação quando a causa do problema é o próprio swap.
Gabarito — Cenário 3
Resposta: B
O sintoma descrito (primeira resposta lenta após período de inatividade, respostas subsequentes normais) é o padrão clássico de cold start causado pelo descarregamento do processo de aplicação. A configuração que previne esse comportamento é o Always On, que aparece explicitamente como Off nas configurações mostradas no enunciado. Com Always On desabilitado, o App Service descarrega o worker process após um período sem requisições e precisa reiniciá-lo na próxima chamada.
Informação irrelevante: A diferença geográfica entre Brasil South e East US é um dado propositalmente inserido para induzir o diagnóstico a focar em latência de rede. Porém, latência geográfica seria constante em todas as chamadas, não apenas na primeira após inatividade. O padrão de 45 minutos entre execuções do script de QA confirma que o período de ociosidade é o gatilho, não a distância.
O distrator C (ARR Affinity) é o mais sofisticado: ARR Affinity pode sim causar roteamento inconsistente entre instâncias, mas seu efeito seria direcionar usuários diferentes para instâncias diferentes de forma persistente, não causar lentidão na primeira requisição de forma reproduzível. O distrator D (HTTP 1.1) descreve um overhead real em outros contextos, mas não é específico para o padrão de "lento apenas após inatividade".
Gabarito — Cenário 4
Resposta: A
A sequência correta é R, P, Q, T, S, que segue a lógica de diagnóstico do mais amplo (infraestrutura) para o mais específico (processo interno da aplicação):
- R — Confirmar se houve mudança de tier é o primeiro passo porque a atualização de configuração mencionada no enunciado é o evento desencadeador. Verificar o que mudou é sempre o ponto de partida em incidentes pós-change.
- P — Validar se o tier atual suporta as instâncias configuradas elimina ou confirma uma causa de infraestrutura antes de investigar a aplicação.
- Q — Verificar se o processo está em execução no Kudu confirma se o problema é de plataforma ou de aplicação.
- T — O Health Check valida se a aplicação responde internamente, separando falha de roteamento de falha de aplicação.
- S — Log Stream é o passo mais demorado e específico; deve ser usado para confirmar a causa após eliminar hipóteses de infraestrutura.
A sequência B começa pelo Kudu (Q), que é um diagnóstico de processo antes de validar a infraestrutura, invertendo a ordem correta. A sequência C começa por logs de aplicação (S), que é o nível mais profundo e mais custoso de investigação, sem antes eliminar causas de infraestrutura. A sequência D começa por Health Check (T), que pressupõe que a aplicação está rodando antes de confirmar isso.
O erro de raciocínio mais comum neste tipo de cenário é ir direto para o Log Stream por ser o recurso mais familiar, ignorando que causas de plataforma (tier incorreto, instâncias acima do limite) produzem HTTP 503 sem gerar logs de aplicação significativos.
Árvore de Troubleshooting: Create an App Service
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta diagnóstica (decisão binária ou verificável) |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Verificação ou validaçã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 diretamente no portal, no Kudu ou nos logs. Responda sempre com o que você observou, não com o que você suspeita. Cada nó laranja representa um ponto onde você precisa coletar evidências antes de continuar. Ao atingir um nó vermelho, você identificou a causa; ao atingir um nó verde, você tem a ação a executar.