Laboratório de Troubleshooting: Configure Storage Tiers
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações configurou uma regra de ciclo de vida para mover blobs automaticamente para o tier Archive após 90 dias sem modificação. A conta de armazenamento é do tipo StorageV2 com redundância LRS, criada há seis meses. A regra foi criada há três semanas e aparece com status Succeeded no portal do Azure.
A equipe relata que blobs com mais de 90 dias continuam no tier Hot e não foram movidos. O time de infraestrutura já confirmou que não há bloqueio de rede ou firewall afetando a conta de armazenamento. A assinatura não tem políticas de bloqueio de recursos aplicadas.
A inspeção de um dos blobs afetados retorna:
az storage blob show \
--account-name stgprodlogs \
--container-name auditlogs \
--name app-log-2025-10-01.gz \
--query "{tier:properties.blobTier, lastModified:properties.lastModified, accessTier:properties.accessTier}"
{
"tier": "Hot",
"lastModified": "2025-10-03T14:22:10+00:00",
"accessTier": "Hot"
}
A data atual é 26 de março de 2026. A regra de ciclo de vida está configurada da seguinte forma:
{
"rules": [
{
"name": "archiveAfter90Days",
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": ["blockBlob"],
"prefixMatch": ["auditlogs/archive/"]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 90
}
}
}
}
}
]
}
Qual é a causa raiz do problema?
A) A conta de armazenamento usa redundância LRS, que não suporta regras de ciclo de vida com tier Archive
B) O filtro prefixMatch exige que os blobs estejam no caminho auditlogs/archive/, mas os blobs estão no container auditlogs sem esse prefixo adicional
C) A regra foi criada há apenas três semanas e o mecanismo de ciclo de vida ainda não processou o primeiro ciclo completo de 90 dias
D) O campo daysAfterModificationGreaterThan considera a data de criação do blob, não a data da última modificação, e os blobs foram modificados recentemente
Cenário 2 — Decisão de Ação
O sistema de relatórios financeiros de uma empresa acessa diariamente um conjunto de blobs no Azure Blob Storage. Na manhã de hoje, o sistema começou a retornar o seguinte erro para todos os blobs do container financial-reports:
BlobAccessTierNotSupported: The operation is not supported for this access tier.
A equipe verifica o tier dos blobs afetados:
az storage blob list \
--account-name stgfinancial \
--container-name financial-reports \
--query "[].{name:name, tier:properties.accessTier}" \
--output table
Name Tier
-------------------------- -------
report-2026-01.xlsx Archive
report-2026-02.xlsx Archive
report-2026-03.xlsx Archive
report-2026-q1-summary.pdf Hot
A conta de armazenamento é StorageV2. A equipe confirma que uma regra de ciclo de vida foi ativada ontem à noite por engano, movendo os blobs para Archive. O arquivo report-2026-q1-summary.pdf não foi afetado porque foi criado hoje. A empresa não possui cópias locais dos arquivos. O sistema de relatórios precisa estar operacional em no máximo 4 horas.
Qual é a ação correta a tomar neste momento?
A) Deletar os blobs em Archive e recarregar os arquivos originais a partir do backup, pois a reidratação pode demorar mais de 4 horas na prioridade Standard
B) Iniciar a reidratação dos blobs com prioridade High, que para blobs desse tipo costuma ser concluída em menos de 1 hora, respeitando a restrição de tempo e a ausência de cópias locais
C) Usar Copy Blob para copiar os blobs diretamente do Archive para um novo container no tier Hot, permitindo acesso imediato sem aguardar reidratação
D) Alterar a regra de ciclo de vida para excluir o container financial-reports e aguardar o próximo ciclo de processamento reverter o tier automaticamente
Cenário 3 — Causa Raiz
Um administrador recebe uma reclamação do time de desenvolvimento: um script de automação que lista e lê blobs de um container está falhando de forma intermitente. Cerca de 30% das chamadas retornam dados normalmente; os demais 70% retornam o seguinte erro:
The blob is currently in the Archive tier and cannot be read directly.
Please rehydrate the blob before attempting to access its content.
O administrador inspeciona a conta de armazenamento e confirma:
- Tipo de conta: StorageV2 General Purpose v2
- Replicação: GRS
- Todos os blobs no container têm mais de 180 dias sem modificação
- O container tem versionamento habilitado
- A política de imutabilidade está desabilitada
- Nenhuma regra de ciclo de vida está configurada atualmente na conta
O script usa o seguinte padrão de acesso:
blobs = container_client.list_blobs()
for blob in blobs:
data = container_client.download_blob(blob.name).readall()
Qual é a causa raiz dos erros intermitentes?
A) A replicação GRS interfere na leitura de blobs quando o endpoint secundário está sendo sincronizado, causando falhas intermitentes de acesso
B) O versionamento habilitado no container gera versões em tier Archive automaticamente após 180 dias, e o script acessa versões antigas em Archive em vez da versão atual
C) Alguns blobs foram movidos para Archive manualmente em algum momento anterior, e o script tenta ler todos os blobs listados sem verificar o tier antes do acesso
D) O tipo de conta StorageV2 com GRS limita operações de leitura simultânea, causando erros intermitentes quando múltiplos blobs são acessados em sequência
Cenário 4 — Impacto Colateral
Um administrador identifica que uma grande quantidade de blobs em um container foi movida para o tier Cold por uma regra de ciclo de vida configurada há 45 dias. Após revisão, a equipe decide que esses blobs precisam ser deletados imediatamente para liberar espaço e reduzir custos.
O administrador executa o seguinte comando para deletar todos os blobs do container:
az storage blob delete-batch \
--account-name stgarchivedata \
--source cold-data \
--pattern "*"
O comando é executado com sucesso e todos os blobs são removidos. O custo de armazenamento cai conforme esperado.
Qual consequência secundária essa ação pode causar?
A) A deleção de blobs no tier Cold antes de completar 90 dias de retenção mínima gera uma cobrança proporcional aos dias restantes do período mínimo, aumentando a fatura inesperadamente
B) Blobs deletados no tier Cold são automaticamente movidos para o tier Archive como medida de proteção, permanecendo faturados por mais 180 dias
C) A operação delete-batch em blobs Cold desabilita automaticamente a regra de ciclo de vida associada ao container, exigindo reconfiguração manual
D) A deleção em lote de blobs Cold aciona um alerta de segurança no Microsoft Defender for Storage, bloqueando operações de escrita na conta por 24 horas
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
O filtro prefixMatch da regra está configurado como auditlogs/archive/. No Azure Blob Storage, o prefixMatch combina o nome do container seguido do prefixo do nome do blob. Isso significa que a regra só se aplica a blobs cujo nome começa com archive/ dentro do container auditlogs. Os blobs afetados, como app-log-2025-10-01.gz, estão na raiz do container sem esse prefixo, portanto a regra nunca os seleciona.
A pista confirmadora está na saída do az storage blob show: o blob foi modificado em outubro de 2025, mais de 90 dias atrás, mas permanece em Hot. Se o problema fosse de tempo de processamento ou data de criação, ao menos alguns blobs já teriam sido movidos.
A informação irrelevante neste cenário é a ausência de bloqueio de rede e políticas de bloqueio de recursos. Esses fatores não têm nenhuma relação com o mecanismo de ciclo de vida, que opera internamente no plano de controle do Azure Storage.
O distrator mais perigoso é o C: acreditar que a regra ainda não processou o ciclo completo leva o administrador a aguardar indefinidamente sem investigar a configuração real. O distrator D é um equívoco técnico relevante, pois o campo daysAfterModificationGreaterThan usa exatamente a data de última modificação, mas os dados mostram que a modificação ocorreu há mais de 170 dias, eliminando essa hipótese.
Gabarito — Cenário 2
Resposta: B
A restrição crítica do cenário é a janela de 4 horas sem cópias locais disponíveis. Isso elimina a alternativa A, que pressupõe a existência de backup. A alternativa C representa um erro técnico comum: Copy Blob a partir de um blob em Archive não lê o conteúdo do blob de origem; o blob ainda está offline e a operação não produz uma cópia funcional com dados. A alternativa D é inviável porque o ciclo de vida não opera em sentido reverso; uma vez no Archive, o blob só retorna a um tier online por reidratação explícita.
A reidratação com prioridade High é a única ação que respeita simultaneamente a ausência de cópias locais e a janela de tempo disponível. Para blobs de tamanho típico de relatórios em formato XLSX e PDF, a reidratação com prioridade High costuma concluir em menos de 1 hora.
O distrator mais perigoso é o C, pois parece tecnicamente elegante e rápido, mas falha silenciosamente: a cópia será criada, o administrador acreditará que o problema está resolvido e o sistema de relatórios continuará com erro ao tentar ler os arquivos copiados.
Gabarito — Cenário 3
Resposta: C
O ponto central é a palavra "intermitente": 30% dos acessos funcionam e 70% falham. Isso descarta qualquer causa que afetaria todos os blobs igualmente. Se fosse um problema de replicação GRS ou limitação de leituras simultâneas, o comportamento seria generalizado ou aleatório sem correlação com o conteúdo dos blobs.
A confirmação está na combinação de dois fatos: não há regra de ciclo de vida ativa atualmente, mas blobs com mais de 180 dias estão presentes. Isso indica que uma regra anterior os moveu para Archive antes de ser removida ou que foram movidos manualmente. O script lista todos os blobs sem filtrar por tier e tenta ler cada um, resultando em sucesso para os blobs em Hot e falha para os que estão em Archive.
A informação irrelevante é a política de imutabilidade desabilitada. Imutabilidade afeta deleção e modificação, não leitura, e não tem relação com o problema descrito.
O distrator B é sofisticado e merece atenção: o versionamento habilitado não move versões para Archive automaticamente. Esse comportamento só ocorreria se uma regra de ciclo de vida fosse configurada explicitamente para versões, o que o enunciado confirma não existir.
Gabarito — Cenário 4
Resposta: A
O tier Cold aplica uma retenção mínima de 90 dias. Blobs deletados antes de completar esse período geram uma cobrança proporcional aos dias restantes, como se tivessem permanecido armazenados até o fim do período mínimo. Como a regra foi configurada há 45 dias e os blobs foram movidos nesse período, todos têm menos de 90 dias no tier Cold. A deleção imediata gerará cobrança pelos 45 dias restantes para cada blob deletado, podendo resultar em uma fatura significativamente mais alta do que o esperado.
Os outros distratores descrevem comportamentos que não existem na plataforma: blobs deletados não são movidos para Archive como proteção, a operação delete-batch não desabilita regras de ciclo de vida, e o Microsoft Defender for Storage não bloqueia operações de escrita como resposta automática a deleções em lote de tiers específicos.
A consequência real de ignorar esse impacto é financeira e imediata: a equipe que esperava reduzir custos descobrirá na próxima fatura que a deleção antecipada gerou cobranças inesperadas pelo período de retenção mínima não cumprido.
Árvore de Troubleshooting: Configure Storage Tiers
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 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 responda cada pergunta de diagnóstico com base no que você pode verificar diretamente na conta de armazenamento. Cada ramificação elimina hipóteses e estreita o caminho até a causa. Ao atingir um nó vermelho, você identificou a causa; ao atingir um nó verde, você tem a ação a executar. Se um caminho levar a um nó de validação laranja, verifique o estado atual antes de avançar para a próxima decisão.