Laboratório de Troubleshooting: Configure blob versioning
Cenários de Diagnóstico
Cenário 1 — Causa Raiz
Uma equipe de operações mantém uma conta de armazenamento do tipo StorageV2 na região East US. O versionamento de blobs está listado como habilitado no portal do Azure. A conta possui um container chamado documentos com acesso privado, e os blobs são gravados por uma aplicação via SDK .NET.
Após uma atualização incorreta de um arquivo crítico chamado relatorio-mensal.xlsx, o time tenta listar as versões anteriores do blob para recuperar o conteúdo original. O comando abaixo é executado:
az storage blob list \
--account-name storageops01 \
--container-name documentos \
--include v \
--output table
A saída retorna apenas a versão atual do blob, sem nenhuma versão anterior listada. O time confirma que o arquivo foi sobrescrito há cerca de 20 minutos. A conta de armazenamento utiliza a camada de acesso Hot e possui lifecycle management configurado com a seguinte regra ativa:
{
"rules": [
{
"name": "move-to-cool",
"enabled": true,
"definition": {
"filters": { "blobTypes": ["blockBlob"] },
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 }
}
}
}
}
]
}
Qual é a causa raiz da ausência de versões anteriores na listagem?
A) A regra de lifecycle management excluiu a versão anterior ao mover o blob para a camada Cool logo após a sobrescrita.
B) O versionamento foi habilitado após a sobrescrita ter ocorrido, portanto nenhuma versão anterior foi registrada para esse evento.
C) O parâmetro --include v não é suficiente para listar versões; é necessário também informar --prefix com o nome exato do blob.
D) A operação de escrita via SDK .NET utilizou uma chamada que não aciona o mecanismo de versionamento, como Put Block sem Put Block List.
Cenário 2 — Decisão de Ação
A causa do problema foi identificada: o versionamento de blobs estava desabilitado no momento em que o arquivo foi sobrescrito. Um administrador acabou de habilitar o versionamento com sucesso. O container documentos armazena aproximadamente 4.000 blobs ativos, todos em produção e acessados continuamente por uma aplicação crítica. Não há janela de manutenção disponível nas próximas 8 horas.
O administrador precisa garantir que os blobs existentes passem a ter versões registradas a partir de agora, sem interromper o acesso da aplicação e sem duplicar dados desnecessariamente.
Qual é a ação correta a tomar neste momento?
A) Copiar todos os blobs do container documentos para um novo container com o mesmo nome em outra conta de armazenamento que já tinha versionamento habilitado antes, e redirecionar a aplicação para a nova conta.
B) Nenhuma ação adicional é necessária: com o versionamento agora habilitado, qualquer operação de escrita futura sobre os blobs existentes criará automaticamente a primeira versão anterior a partir desse ponto.
C) Executar um script que realize uma operação de cópia de cada blob sobre si mesmo (Copy Blob com origem e destino iguais) para forçar o registro imediato de uma versão baseline para todos os 4.000 blobs.
D) Desabilitar e reabilitar o versionamento duas vezes seguidas para forçar o serviço a reindexar os blobs existentes e criar versões iniciais para cada um.
Cenário 3 — Causa Raiz
Um engenheiro de dados reporta que está conseguindo listar versões de um blob específico chamado pipeline-config.json, mas ao tentar baixar uma versão anterior para validação, recebe o seguinte erro:
BlobAccessTierNotSupported: The operation is not supported for this version of the blob.
O ambiente possui as seguintes características:
- Conta do tipo StorageV2 com hierarquia de namespace desabilitada
- Versionamento habilitado há 45 dias
- A versão que o engenheiro tenta acessar foi criada há 38 dias
- A conta possui integração com Microsoft Entra ID para autenticação via RBAC, e o engenheiro possui a role Storage Blob Data Reader no escopo da conta
- Uma regra de lifecycle management moveu versões anteriores com mais de 30 dias para a camada Archive
Qual é a causa raiz do erro recebido?
A) A role Storage Blob Data Reader não possui permissão para acessar versões de blobs, apenas o blob base.
B) A versão foi movida para a camada Archive pela regra de lifecycle management, e blobs nessa camada não podem ser lidos diretamente sem reidratação prévia.
C) A hierarquia de namespace desabilitada impede o acesso a versões individuais de blobs em contas StorageV2.
D) O versionamento habilitado há 45 dias ainda está em período de propagação para blobs criados antes da habilitação, e versões com mais de 30 dias ainda não estão disponíveis.
Cenário 4 — Sequência de Diagnóstico
Um operador recebe um chamado relatando que versões antigas de blobs em um container estão acumulando e gerando custos inesperados, mesmo com uma política de lifecycle management configurada para excluir versões anteriores com mais de 60 dias. Ele precisa investigar por que as versões não estão sendo excluídas conforme esperado.
Os passos de investigação disponíveis são:
- Verificar se a propriedade
enabledda regra de lifecycle está definida comotrue - Confirmar que o tipo de ação configurado é
version.deletee nãobaseBlob.delete - Listar as versões do blob afetado e verificar a data de criação de cada versão
- Verificar se o versionamento está de fato habilitado na conta de armazenamento
- Checar o log de execuções da política de lifecycle no Azure Monitor para identificar se a regra foi avaliada e se houve erros
Qual sequência representa o raciocínio diagnóstico mais eficiente?
A) 4 → 1 → 2 → 3 → 5
B) 3 → 5 → 4 → 2 → 1
C) 1 → 4 → 2 → 5 → 3
D) 5 → 3 → 1 → 4 → 2
Gabarito e Explicações
Gabarito — Cenário 1
Resposta: B
A pista decisiva está no enunciado: o versionamento está listado como habilitado no portal, mas nenhuma versão anterior existe para um blob que foi sobrescrito 20 minutos atrás. O versionamento é prospectivo por definição: ele começa a registrar versões apenas a partir do momento em que é habilitado. Se o blob existia antes da habilitação e nunca foi modificado após ela, não há versão anterior registrada.
A informação sobre a regra de lifecycle management (distrator A) é propositalmente irrelevante: a regra move blobs para Cool após 30 dias, e o evento ocorreu há apenas 20 minutos. Essa regra não poderia ter excluído nenhuma versão nesse intervalo.
O distrator C representa um erro de sintaxe que não existe: --include v é o parâmetro correto para incluir versões na listagem. O distrator D descreve um cenário técnico plausível, mas Put Block sem Put Block List deixa o blob em estado de bloco não comprometido, e o cenário não indica nenhuma anomalia no processo de escrita.
O erro de diagnóstico mais perigoso seria o distrator A: agir sobre a regra de lifecycle modificando-a não resolveria o problema, e o time perderia tempo investigando uma causa incorreta enquanto a janela de recuperação (caso houvesse backup) se fecha.
Gabarito — Cenário 2
Resposta: B
Com o versionamento habilitado, o comportamento padrão do serviço garante que qualquer operação de escrita futura sobre um blob existente criará automaticamente uma versão anterior com o conteúdo atual antes da modificação. Nenhuma ação adicional é necessária para que os blobs existentes comecem a ter seu histórico rastreado a partir desse ponto.
O distrator C (copiar cada blob sobre si mesmo) é tecnicamente uma estratégia válida para criar um baseline de versão imediato, mas o enunciado apresenta uma restrição crítica: 4.000 blobs em produção com acesso contínuo e sem janela de manutenção. Executar 4.000 operações de cópia sobre blobs ativos introduz risco de conflito de concorrência, latência adicional e custo de transação desnecessário. A restrição operacional torna essa ação incorreta neste contexto específico.
O distrator A propõe uma migração de conta inteira, que viola diretamente a restrição de continuidade do serviço. O distrator D descreve um comportamento que não existe: desabilitar e reabilitar o versionamento não força reindexação de nenhum tipo.
Gabarito — Cenário 3
Resposta: B
A causa raiz está na combinação de dois fatos objetivos fornecidos no enunciado: a versão em questão foi criada há 38 dias, e existe uma regra de lifecycle management que move versões anteriores com mais de 30 dias para a camada Archive. Blobs na camada Archive estão offline e não podem ser lidos diretamente. Qualquer tentativa de acesso retorna erro até que o blob seja reidratado para Hot ou Cool, o que pode levar horas.
A informação sobre autenticação via Microsoft Entra ID e a role Storage Blob Data Reader é propositalmente irrelevante: essa role possui permissão de leitura sobre versões de blobs, e o engenheiro consegue inclusive listar as versões sem erro, o que prova que a autenticação e autorização funcionam corretamente.
O distrator A é o mais perigoso: ele direcionaria o administrador a revisar permissões RBAC e abrir tickets de acesso, enquanto o problema real é de camada de armazenamento e pode ser resolvido iniciando uma operação de reidratação imediatamente.
Gabarito — Cenário 4
Resposta: A
A sequência correta é 4 → 1 → 2 → 3 → 5, que representa uma progressão do mais simples ao mais específico:
Primeiro confirmar que o versionamento está habilitado (passo 4), pois sem isso nenhuma versão existe para ser gerenciada pela política. Em seguida, verificar se a regra está ativa (passo 1), já que uma regra com enabled: false é ignorada completamente. Depois, confirmar que a ação configurada é version.delete e não uma ação sobre o blob base (passo 2), pois esse é o equívoco de configuração mais comum. Com a configuração validada, verificar os dados reais das versões listadas (passo 3) para confirmar se as datas excedem o threshold da regra. Por fim, consultar o Azure Monitor (passo 5) para verificar se a regra foi avaliada e se houve erros de execução, o que é o passo mais custoso em tempo e deve ser feito apenas quando os anteriores não revelam a causa.
A sequência B (distrator) começa pelos dados observáveis antes de validar a configuração, o que pode levar a conclusões incorretas. A sequência C inverte a lógica ao verificar a configuração antes de confirmar o pré-requisito (versionamento habilitado). A sequência D começa pelo recurso mais avançado de diagnóstico sem antes validar os pré-requisitos mais simples.
Árvore de Troubleshooting: Configure blob versioning
Legenda de cores:
| Cor | Tipo de nó |
|---|---|
| Azul escuro | Sintoma inicial (ponto de entrada) |
| Azul | Pergunta de diagnóstico |
| Vermelho | Causa identificada |
| Verde | Ação recomendada ou resolução |
| Laranja | Validação ou estado correto confirmado |
Para usar esta árvore diante de um problema real, comece pelo nó raiz descrevendo o sintoma geral. Responda cada pergunta de diagnóstico com base no que você pode verificar diretamente no ambiente, seguindo o caminho correspondente à sua resposta. Cada bifurcação elimina hipóteses progressivamente até que você chegue a um nó vermelho que nomeia a causa raiz, seguido de um nó verde com a ação corretiva precisa. Nunca pule perguntas: a ordem das bifurcações reflete dependências reais entre os pré-requisitos do serviço.