Laboratório de Troubleshooting: Configure blob lifecycle management
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações relata que blobs na conta de armazenamento prodlogs001 não estão sendo movidos para a camada Cool conforme esperado. A conta foi criada há dois anos e é do tipo General Purpose v2. O versionamento de blobs está desabilitado. A replicação configurada é LRS.
O administrador verifica a política ativa e encontra o seguinte:
{
"rules": [
{
"name": "moverParaCool",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["logs/"]
},
"actions": {
"baseBlob": {
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
}
}
}
]
}
O administrador confirma que os blobs em logs/ têm mais de 30 dias sem acesso. A conta tem 4 TB de dados e um total de 12 regras de ciclo de vida configuradas. O custo mensal subiu 18% no último mês.
Qual é a causa raiz do problema observado?
A) A conta possui 12 regras de ciclo de vida, excedendo o limite máximo permitido de 10 regras por conta, o que faz com que as regras mais recentes sejam ignoradas.
B) O rastreamento de último acesso não está habilitado na conta de armazenamento, portanto a condição daysAfterLastAccessTimeGreaterThan nunca é satisfeita.
C) A camada Cool não é um destino válido para blobs do tipo blockBlob em contas GPv2 com replicação LRS.
D) O prefixo logs/ está incorreto; políticas de ciclo de vida exigem que o prefixo inclua o nome do container completo no formato container/prefixo.
Cenário 2 — Decisão de Ação
A equipe de infraestrutura identificou que a política de ciclo de vida da conta archivestore02 está corretamente configurada e habilitada. A causa do problema já foi determinada: a conta é do tipo General Purpose v1 (GPv1) e as ações de movimentação de camadas não são executadas nesse tipo de conta.
A conta está em produção, processa aproximadamente 500 operações de gravação por hora e é utilizada por três aplicações críticas que não podem ter interrupção de serviço. A equipe tem uma janela de manutenção agendada para 48 horas a partir de agora. O time de desenvolvimento confirmou que as aplicações são compatíveis com contas GPv2.
Qual é a ação correta a tomar neste momento?
A) Recriar a conta como GPv2, atualizar as strings de conexão nas três aplicações e reativar a política de ciclo de vida, realizando tudo imediatamente para não acumular mais custo.
B) Aguardar a janela de manutenção e realizar o upgrade da conta de GPv1 para GPv2 pelo portal do Azure, sem necessidade de recriar a conta ou migrar dados.
C) Criar uma nova conta GPv2 em paralelo, configurar a política de ciclo de vida, migrar os dados usando AzCopy e redirecionar as aplicações durante a janela de manutenção.
D) Habilitar o nível de acesso Archive diretamente na conta GPv1 por meio do Azure CLI, o que permite que a política de ciclo de vida seja executada sem necessidade de migração.
Cenário 3 — Causa Raiz
Um administrador configura uma política de ciclo de vida para excluir automaticamente blobs após 180 dias. Após 200 dias, ao auditar a conta, ele encontra blobs que deveriam ter sido excluídos ainda presentes. A conta é GPv2, o tipo de blob é blockBlob e a regra está habilitada.
Ao investigar, ele coleta as seguintes informações:
Nome do container: backup-diario
Tipo de blob: blockBlob
Camada atual: Archive
Data da última modificação: 210 dias atrás
Política configurada:
- delete: daysAfterModificationGreaterThan: 180
- tierToArchive: daysAfterModificationGreaterThan: 90
Replicação: GRS
Região: Brazil South
Custo de armazenamento: dentro do esperado para Archive
O administrador nota que os blobs estão na camada Archive e suspeita que a replicação GRS esteja interferindo com a execução da política. O suporte da Microsoft confirma que não há incidentes na região Brazil South.
Qual é a causa raiz dos blobs não terem sido excluídos?
A) A replicação GRS impede a exclusão automática de blobs, pois a política de ciclo de vida aguarda a confirmação da réplica secundária antes de executar a ação.
B) Blobs na camada Archive precisam ser reidratados para Hot ou Cool antes que uma política de ciclo de vida possa executar a ação de exclusão.
C) A regra tierToArchive e a regra delete estão configuradas para o mesmo blob, e quando há conflito de ações na mesma política, apenas a ação de menor custo é executada.
D) Blobs na camada Archive com mais de 180 dias têm o clock de modificação reiniciado no momento da transição de camada, postergando o critério de exclusão.
Cenário 4 — Impacto Colateral
Um administrador percebe que blobs de snapshot acumulados estão gerando custo elevado. Para resolver o problema, ele adiciona a seguinte ação à política de ciclo de vida existente da conta:
"snapshot": {
"delete": {
"daysAfterCreationGreaterThan": 7
}
}
A política é salva e começa a ser executada no ciclo seguinte. O problema de custo é resolvido. Dois dias depois, a equipe de recuperação de desastres relata que não consegue restaurar um arquivo crítico corrompido há 5 dias a partir de um snapshot anterior.
Qual consequência secundária essa ação causou?
A) A política de exclusão de snapshots desabilitou automaticamente a funcionalidade de soft delete para snapshots, impedindo a recuperação mesmo dentro do período de retenção configurado.
B) Snapshots com menos de 7 dias de criação que existiam antes da ativação da política foram excluídos retroativamente no primeiro ciclo de execução, eliminando o snapshot criado 5 dias atrás antes que ele completasse 7 dias.
C) A regra de exclusão de snapshots removeu todos os snapshots com mais de 7 dias, e como o arquivo foi corrompido há 5 dias, o único snapshot útil seria um criado há menos de 7 dias, que ainda deveria existir, mas foi excluído por uma regra conflitante de baseBlob.
D) Ao adicionar a ação snapshot.delete, a política substituiu silenciosamente a configuração de soft delete da conta, reduzindo o período de retenção de soft delete de 14 dias para 7 dias.
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O rastreamento de último acesso é um recurso que precisa ser habilitado explicitamente na conta de armazenamento antes de ser usado como critério em políticas de ciclo de vida. Quando esse rastreamento não está ativo, o Azure não registra o timestamp de último acesso nos blobs, e a condição daysAfterLastAccessTimeGreaterThan nunca é avaliada como verdadeira, pois o campo permanece nulo ou desatualizado.
A pista no enunciado é a ausência de qualquer menção ao rastreamento de acesso estar habilitado, combinada com a escolha da condição baseada em acesso.
A informação irrelevante neste cenário é o volume de 4 TB e o aumento de 18% no custo: esses dados contextualizam a urgência do problema, mas não têm nenhuma relação com a causa da falha na política.
Os distratores representam erros diagnósticos comuns: a alternativa A confunde quantidade de regras com um limite inexistente (o limite real é 100 regras por política, não 10); a alternativa C inventa uma restrição que não existe entre blockBlob e a camada Cool em GPv2 com LRS; a alternativa D confunde o formato do prefixo, que pode ou não incluir o nome do container dependendo do escopo, mas logs/ é válido se os blobs estiverem num container chamado logs.
O distrator mais perigoso é o D: um administrador poderia perder tempo alterando prefixos sem resolver o problema real.
Gabarito — Cenário 2
Resposta: B
O upgrade de uma conta GPv1 para GPv2 é uma operação suportada diretamente pelo Azure e é irreversível, mas não destrutiva: os dados permanecem intactos, as strings de conexão não mudam e o serviço não é interrompido. Realizar esse upgrade durante a janela de manutenção é a ação correta porque respeita todas as restrições do cenário: sem interrupção de serviço, sem necessidade de migração de dados e alinhado ao prazo disponível.
A alternativa A ignora a restrição crítica de não interromper o serviço e antecipa desnecessariamente uma operação que pode ser feita de forma controlada. A alternativa C é tecnicamente válida em cenários onde o upgrade não é possível, mas introduz complexidade e risco de migração desnecessários quando o upgrade direto resolve o problema. A alternativa D descreve uma operação que não existe: não há como habilitar movimentação de camadas em GPv1 via CLI; o tipo de conta é o limitador arquitetural.
Gabarito — Cenário 3
Resposta: B
Blobs na camada Archive estão em estado offline. Para que qualquer operação seja executada sobre eles, incluindo exclusão por política de ciclo de vida, é necessário que o blob seja primeiro reidratado para uma camada online (Hot ou Cool). A política de ciclo de vida não executa a ação de exclusão sobre blobs em Archive diretamente.
A pista decisiva no enunciado é que os blobs estão na camada Archive e que o custo está dentro do esperado para Archive: isso confirma que a transição de camada ocorreu normalmente, mas a exclusão subsequente não foi executada.
A informação irrelevante é a suspeita do administrador sobre a replicação GRS e a confirmação de ausência de incidentes na região: esses elementos foram inseridos para desviar o diagnóstico para causas de infraestrutura quando o problema é de comportamento esperado da camada Archive.
O distrator mais perigoso é o A: a ideia de que a replicação GRS interfere com políticas é intuitivamente plausível, mas incorreta. Agir com base nessa hipótese levaria o administrador a alterar a replicação da conta sem resolver o problema real.
Gabarito — Cenário 4
Resposta: B
As políticas de ciclo de vida são avaliadas com base no estado atual dos objetos no momento da execução do ciclo. Quando uma regra de exclusão de snapshots com daysAfterCreationGreaterThan: 7 é ativada, o primeiro ciclo de execução avalia todos os snapshots existentes com base nesse critério. Um snapshot criado 5 dias antes da ativação da regra existia há 5 dias no momento da ativação, mas isso não o protege: na primeira execução da política após a ativação, se esse snapshot ainda tiver menos de 7 dias, ele será preservado. O problema real é que a regra foi aplicada e o snapshot criado há 5 dias foi excluído porque no momento em que o ciclo executou, ele já tinha mais de 7 dias (5 dias antes da ativação mais 2 dias após, totalizando 7 dias ou mais).
A alternativa A descreve um comportamento que não existe: políticas de ciclo de vida não interagem com a configuração de soft delete. A alternativa C introduz um conflito de regras que não foi configurado no cenário. A alternativa D descreve uma substituição silenciosa que também não ocorre: soft delete e lifecycle management são configurações independentes.
O aprendizado central deste cenário é que ao ativar uma política de exclusão, todos os objetos já existentes passam a ser elegíveis imediatamente com base nos critérios de tempo, e não apenas os criados após a ativação da regra.
Árvore de Troubleshooting: Configure blob lifecycle management
Legenda de cores:
- Azul escuro: sintoma inicial, ponto de entrada da investigacao
- Azul medio: pergunta diagnostica, ponto de decisao
- Vermelho: causa identificada
- Verde: acao recomendada ou resolucao
- Laranja: validacao ou verificacao intermediaria
Para usar esta arvore diante de um problema real, comece pelo no raiz descrevendo o sintoma observado e responda cada pergunta de decisao com base no que voce pode verificar diretamente na conta de armazenamento ou na configuracao da politica. Siga o caminho correspondente a cada resposta ate atingir um no de causa identificada ou acao recomendada. Nao pule niveis: cada pergunta filtra uma hipotese e reduz o espaco de causas possiveis antes de voce agir.