Laboratório de Troubleshooting: Configure deployment slots for an App Service
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
A equipe de operações realiza um swap entre o slot staging e o slot production de um App Service hospedado em um plano Standard S2. O swap é concluído sem erros no portal do Azure. Minutos depois, o time de banco de dados reporta que a aplicação em production está tentando conectar ao banco de dados de staging, causando falhas nas transações dos usuários finais.
O administrador verifica o histórico de deploys e confirma que nenhum deploy foi feito diretamente no slot production nas últimas 24 horas. O App Service está com Always On habilitado e o Health Check configurado para verificar /health a cada 30 segundos. A string de conexão com o banco é armazenada como uma Application Setting chamada DB_CONNECTION_STRING.
Estado das configurações antes do swap:
Slot: production
DB_CONNECTION_STRING = Server=prod-db.database.windows.net;...
Slot Setting: false
Slot: staging
DB_CONNECTION_STRING = Server=staging-db.database.windows.net;...
Slot Setting: false
Qual é a causa raiz do problema observado?
A. O Health Check não detectou a falha de conexão a tempo de reverter o swap automaticamente.
B. A configuração DB_CONNECTION_STRING não estava marcada como slot setting, portanto migrou junto com o código durante o swap.
C. O plano Standard S2 não suporta isolamento de configurações entre slots, exigindo o plano Premium.
D. O Always On manteve a conexão com o banco de staging ativa em cache antes que o swap pudesse atualizar as configurações.
Cenário 2 — Decisão de Ação
A causa já foi identificada: durante um swap entre staging e production, o administrador percebeu que executou o swap na direção errada, promovendo código de um slot de hotfix para staging em vez de para production. O erro foi identificado 4 minutos após o swap. O slot de production não foi afetado. O ambiente de staging agora contém o código do hotfix, e o código original de staging foi para o slot hotfix.
O time de QA está aguardando o ambiente de staging para iniciar uma bateria de testes agendados para os próximos 20 minutos. O plano do App Service é Premium P1v3. Não há janela de manutenção aberta para production no momento.
Qual é a ação correta a tomar neste momento?
A. Realizar um novo deploy do código original de staging diretamente no slot staging via pipeline de CI/CD.
B. Executar um swap entre o slot hotfix e o slot staging para restaurar o estado original de ambos os slots.
C. Excluir o slot staging e recriá-lo a partir do slot hotfix usando a opção de clonagem de slot.
D. Executar um swap entre o slot hotfix e o slot production para garantir que o hotfix chegue ao ambiente correto antes de corrigir o staging.
Cenário 3 — Causa Raiz
Um desenvolvedor reporta que, após habilitar o Auto Swap no slot staging apontando para production, todo commit que chega ao slot staging aciona um swap imediato, conforme esperado. No entanto, após cada swap, os usuários relatam cerca de 40 segundos de respostas HTTP 503 antes de a aplicação estabilizar.
O administrador verifica os logs do App Service e confirma que o slot de production retorna 503 durante esse intervalo. A aplicação utiliza um framework que realiza inicializações pesadas na primeira requisição, incluindo carregamento de cache em memória de aproximadamente 800 MB. O slot staging está configurado com 1 instância e o slot production com 3 instâncias. O plano é Premium P2v3. O Health Check está habilitado e configurado corretamente.
App Service Logs - slot: production
[INFO] 2026-03-15T14:02:11Z - Swap initiated from staging to production
[WARN] 2026-03-15T14:02:13Z - Instance prod-1: HTTP 503 on route /
[WARN] 2026-03-15T14:02:15Z - Instance prod-2: HTTP 503 on route /
[WARN] 2026-03-15T14:02:18Z - Instance prod-3: HTTP 503 on route /
[INFO] 2026-03-15T14:02:52Z - All instances healthy
Qual é a causa raiz do período de indisponibilidade observado?
A. O Health Check está demorando para detectar que as instâncias estão prontas, pois o intervalo de verificação está muito alto.
B. O Auto Swap não suporta aplicações com mais de uma instância em production, causando conflito durante a troca.
C. O slot staging possui apenas 1 instância aquecida, e as 3 instâncias de production recebem o código frio sem aquecimento prévio, pois o Auto Swap não executa warm-up por instância de destino.
D. O framework da aplicação está com um bug de inicialização que só se manifesta quando o código é promovido via swap, e não em deploys diretos.
Cenário 4 — Sequência de Diagnóstico
Um administrador recebe o seguinte alerta: o slot production de um App Service está retornando HTTP 500 para todas as requisições após um swap realizado há 15 minutos. O swap foi feito via Azure CLI pelo time de DevOps. O administrador precisa diagnosticar e resolver o problema com o menor impacto possível para os usuários.
Os seguintes passos de investigação estão disponíveis, mas foram listados fora de ordem:
[P] Verificar os logs de aplicação do slot production para identificar a exceção sendo lançada
[Q] Executar um swap reverso entre production e staging para restaurar o estado anterior
[R] Confirmar que o slot staging estava saudável antes do swap, verificando o histórico de Health Check
[S] Identificar se alguma Application Setting obrigatória está ausente ou com valor incorreto no slot production
[T] Comparar as configurações de slot settings entre production e staging no momento atual
Qual é a sequência correta de investigação?
A. R, P, T, S, Q
B. P, S, T, R, Q
C. T, P, R, S, Q
D. P, T, S, Q, R
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no estado das configurações antes do swap: DB_CONNECTION_STRING estava marcada como Slot Setting: false em ambos os slots. Isso significa que essa configuração não é tratada como pertencente ao slot, e portanto ela migra junto com o conteúdo da aplicação durante o swap.
Antes do swap, o slot staging tinha o valor apontando para staging-db. Após o swap, esse valor foi para o slot production, substituindo a string de conexão de produção.
Identificação das informações irrelevantes: o Always On e o Health Check são detalhes operacionais reais, mas não têm relação com o comportamento de migração de configurações durante o swap. Foram incluídos para induzir o leitor a focar nos mecanismos de saúde da aplicação em vez do mecanismo de configuração.
O principal erro de raciocínio dos distratores é confundir o plano de monitoramento (Health Check) com o plano de configuração (slot settings), ou atribuir a causa a uma limitação de plano que não existe.
A consequência de agir com base no distrator A seria tentar ajustar o intervalo do Health Check sem corrigir o problema real, e os erros de conexão continuariam indefinidamente.
Gabarito — Cenário 2
Resposta: B
A causa é conhecida: o swap ocorreu na direção errada entre hotfix e staging. O código original de staging foi para hotfix, e o código do hotfix foi para staging. Nenhum slot de production foi afetado.
A ação correta é executar um novo swap entre hotfix e staging, revertendo exatamente o que foi feito. Esse swap restaura o código original de staging no slot staging e devolve o código de hotfix ao seu slot de origem, sem nenhum impacto em production.
A restrição crítica que elimina os outros distratores:
- A é tecnicamente válida, mas leva tempo de pipeline e pode não estar pronta antes da janela de QA de 20 minutos.
- C é destrutiva e desnecessária; excluir e recriar um slot quando um swap simples resolve é uma ação de alto custo operacional sem justificativa.
- D promoveria o hotfix para production sem janela de manutenção aberta, violando a restrição explícita do cenário e causando um segundo problema.
O swap reverso entre hotfix e staging é a ação mais rápida, segura e alinhada com todas as restrições apresentadas.
Gabarito — Cenário 3
Resposta: C
O comportamento observado, 40 segundos de HTTP 503 após cada swap com Auto Swap, é consistente com o processo de aquecimento ausente nas instâncias de destino.
O mecanismo de aquecimento do App Service garante que o slot de origem seja aquecido antes da troca. No entanto, quando o slot staging tem 1 instância e o slot production tem 3 instâncias, apenas a instância do staging foi aquecida. As 3 instâncias do slot production recebem o código e precisam executar a inicialização pesada (carregamento de 800 MB em cache) ao receber as primeiras requisições reais, causando os 503 durante esse período.
A informação irrelevante neste cenário é o plano Premium P2v3. O tier do plano não influencia o comportamento de aquecimento por instância.
O distrator A é o mais perigoso: ajustar o Health Check não resolve o problema porque o 503 é causado pela inicialização da aplicação, não por um problema de detecção de saúde. Aumentar o intervalo do Health Check apenas atrasaria a detecção de instâncias realmente não saudáveis no futuro.
A solução real seria configurar applicationInitialization no web.config para forçar o aquecimento correto antes do swap concluir, ou usar Swap with Preview para controlar o processo.
Gabarito — Cenário 4
Resposta: A — R, P, T, S, Q
A sequência correta segue a lógica de diagnóstico progressivo: primeiro eliminar hipóteses antes de agir.
| Ordem | Passo | Justificativa |
|---|---|---|
| 1 | R | Confirmar se staging estava saudável antes do swap elimina a hipótese de que o problema existia antes da promoção |
| 2 | P | Verificar os logs do slot production revela a exceção real sendo lançada, direcionando o diagnóstico |
| 3 | T | Comparar slot settings entre os slots identifica se alguma configuração crítica está com valor errado após o swap |
| 4 | S | Verificar se alguma Application Setting obrigatória está ausente confirma ou descarta a hipótese de configuração faltante |
| 5 | Q | Somente após confirmar a causa e avaliar que não há correção rápida, o swap reverso é executado para restaurar production |
O erro de raciocínio central dos distratores é executar o swap reverso (Q) prematuramente, antes de entender a causa. Reverter sem diagnóstico pode mascarar o problema e resultar em nova falha no próximo deploy. A sequência B coloca P antes de R, ignorando a necessidade de estabelecer o estado de referência antes de analisar logs.
Árvore de Troubleshooting: Configure deployment slots for 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 verificação) |
| Laranja | Validação ou verificação intermediária |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma observado após o swap. A cada nó de pergunta, responda com base no que você pode observar diretamente no portal, nos logs ou via CLI. Siga o caminho correspondente à sua resposta até chegar a um nó vermelho de causa identificada. A partir da causa, o nó verde adjacente indica a ação corretiva precisa, sem necessidade de tentativas às cegas.