APRENDER. PRATICAR. EVOLUIR.Definir o marco que será aceite
O fim de um comando de restore é um marco técnico. O requisito do serviço pode exigir que os resultados do ciclo estejam completos, corretos e utilizáveis dentro de vinte minutos. Escreve esse marco antes do ensaio para evitar mudar o critério conforme o resultado observado. Distingue receção de ficheiro, reconciliação pelo consumidor e disponibilidade ao negócio. Um acknowledgement de receção não cobre automaticamente as etapas seguintes. Inclui ainda o âmbito do serviço e as dependências que sustentam o prazo. Se uma equipa apenas reconhece pedidos em trinta minutos, esse compromisso não demonstra capacidade de recuperar o serviço em quinze. A incompatibilidade precisa de decisão explícita.
Reconciliar o conteúdo do snapshot
O laboratório cria oito resultados locais, faz um snapshot com a API de backup e só depois acrescenta os resultados 9 e 10 à origem. Restaura o snapshot noutra base temporária. integrity_check devolve ok, mas a comparação com o conjunto esperado encontra apenas oito resultados. Um diário fictício retido contém 9:90 e 10:100. A recuperação local verifica identidades e valores antes de inserir; duas aplicações desse diário deixam dez resultados e 550 unidades. O ensaio demonstra o efeito nesse conjunto local. Não executa replay externo, valida a origem real de um diário ou prova que esta estratégia é adequada a qualquer contrato de processamento.
Separar estrutura, relações e aplicação
Na fixture de compatibilidade, o snapshot antecede a coluna status. A aplicação nova tenta consultá-la e recebe no such column: status, apesar do resultado ok de integrity_check. Noutra fixture independente, foreign_keys foi desligado deliberadamente antes de inserir uma linha ligada ao batch 99 inexistente. O controlo estrutural continua a devolver ok, enquanto foreign_key_check identifica a relação inválida. São exemplos de âmbitos diferentes de validação. Não concluas que ligar enforcement corrige automaticamente os dados antigos. Reconcilia o significado da relação e confirma a combinação de aplicação, schema e dados. Eliminar linhas indiscriminadamente pode produzir uma base aparentemente limpa e um resultado funcional incompleto.
Associar evidência ao contexto efetivo
O modelo de prontidão compara artefacto, configuração, runbook e papel operacional. A evidência refere build-a, cfg-3, revisão 4 e aps-run. O candidato conserva o binário mas muda configuração e runbook; o modelo identifica as duas diferenças. Um caso com todos os campos iguais passa a correspondência. Este controlo sintético não autentica aprovadores nem substitui revisão técnica. Serve para perguntar se a evidência se aplica ao que será executado. Uma alteração de configuração pode mudar ligações ou limites sem tocar no binário. Uma mudança de papel pode alterar permissões. Analisa o impacto e define os ensaios necessários para o candidato efetivo antes da decisão de aceitação.
Gerir exceções e coordenação durante a recuperação
A política fictícia do exercício define uma exceção válida apenas enquanto a hora atual é anterior às 12:00 UTC. O modelo aceita 11:59 e rejeita 12:00. A fronteira é explícita; não representa uma política universal. Se a lacuna continua aberta, obter uma nova decisão é diferente de editar a data para prolongar a anterior. Durante um incidente, coordena também propostas de mudança com quem gere a recuperação. Um projeto que altera configuração enquanto outra equipa testa hipóteses pode invalidar evidência ou produzir efeitos incompatíveis. Conserva a cronologia, os responsáveis e o âmbito autorizado. Urgência exige clareza sobre a decisão, não uma presunção de que qualquer ação está aprovada.
Preparar um pacote de aceitação utilizável
Entrega uma síntese com requisitos, conjunto testado, resultado, lacunas, responsáveis e condições de revisão. Para o fornecedor, inclui versão, passos reproduzíveis e evidência mínima relevante por um canal autorizado. Protege dados desnecessários ao diagnóstico; retirar informação sensível não significa eliminar horários ou contexto técnico útil. Identifica o que foi realmente executado e o que continua a ser modelo ou proposta. Neste laboratório, quatro grupos usam SQLite real em ficheiros descartáveis; os controlos de prontidão são comparações fictícias. Não houve restore de produção, teste de permissões reais ou decisão humana. A oficina termina com um pacote argumentado para revisão, não com certificação oficial nem autorização de operação.
python3 content/labs/aps-readiness/run.py
# Disposable SQLite fixtures; no application database or network
# Recorded: CPython 3.13.1 / SQLite 3.53.4
# integrity_check = ok; restored rows = 8; expected rows = 10
# Old snapshot + new reader: no such column: status
# Separate fixture: integrity_check = ok; foreign_key_check reports a violation
# Eleven groups distinguish actual SQL from synthetic decision models.Um snapshot é estruturalmente válido, mas faltam resultados do ciclo atual. A equipa precisa de reconciliar o conjunto e confirmar compatibilidade com a aplicação que será operada.
Armadilhas comuns
Aceitar apenas por um comando verde, reutilizar evidência após mudanças materiais ou tratar um modelo automático como decisão humana autorizada.
Tópicos relacionados: Disaster Recovery · Gestão de mudanças · SQL
A aceitação liga requisitos a observações no contexto que será operado. Regista lacunas, validade da decisão e responsabilidade pelo trabalho restante.
Referência: Consistent review of operational readiness · DR APS professional curriculum 2026-09; vendor-neutral operational guidance reviewed 2026-09-30