APRENDER. PRATICAR. EVOLUIR.Definir o que precisa de regressar
Um backup válido é uma entrada para recuperação. O objetivo do ensaio é demonstrar que o serviço volta a produzir resultados aceites dentro dos limites acordados. Num exemplo fictício de pagamentos, um volume restaurado pode conter dados íntegros enquanto DNS, segredos e rotas ainda apontam para recursos indisponíveis. Faz um inventário dessas dependências e identifica quais são reconstruídas, restauradas ou alteradas. Define quem aceita dados, desempenho e operação degradada. A presença de um recurso na consola não é o critério de sucesso do negócio. Guarda uma linha temporal desde a falha até à validação e distingue etapas técnicas concluídas de dependências que continuam pendentes.
Medir RPO no ponto utilizável
Se a origem falha às 12:17 e o último ponto consistente disponível no destino corresponde a 12:04, a exposição é de treze minutos. Um backup de 12:15 que ainda não está utilizável nesse destino não reduz automaticamente essa exposição. Compara o resultado com o RPO acordado e analisa o intervalo dos dados que exigem reconciliação. A existência de replicação também não é prova universal: importa saber o que foi efetivamente replicado e se o ponto é consistente para o conjunto necessário. Usa dados fictícios ou adequadamente controlados no exercício. O relatório deve identificar o ponto escolhido, a justificação e a evidência de leitura, além do nome do job.
Isolar efeitos e preparar autorização
Uma aplicação restaurada pode arrancar jobs e contactar destinos reais usando configuração antiga. Antes de a iniciar, revê rede, credenciais, schedulers e destinos. Uma conta de teste ajuda a separar recursos, mas não demonstra isolamento de todas as integrações. Define resultados de validação que não submetam pagamentos reais. Em AWS Backup, separa autorização do operador para passar uma role e permissões da role usada pelo serviço para restaurar. A role precisa das ações concretas do recurso, incluindo configuração aplicável. Aceitar o pedido não prova que todas as chamadas posteriores serão autorizadas. O ensaio deve expor permissões em falta enquanto ainda existe tempo para as corrigir de forma controlada.
Ligar validação ao recurso certo
Restore testing permite iniciar um workflow quando o job atinge COMPLETED. Filtra os eventos pelo âmbito pretendido, como tipo de recurso e ARN do plano, e usa a identidade do recurso criado. Um endpoint fixo de produção pode responder bem enquanto o restauro está inutilizável. Define verificações de leitura, consistência e funcionalidade antes de publicar o resultado. Um estado de validação já definido não pode ser alterado; não envies SUCCESSFUL como placeholder. Conserva logs que liguem job, recurso e verificações. A conclusão da validação ou o fim da janela inicia limpeza, que depende do recurso e pode não ser imediata. Recolhe evidência e acompanha pendências de limpeza.
Respeitar retenção e semântica do restauro
Vault Lock governance permite remoção por utilizadores autorizados; compliance torna o bloqueio imutável após o período de alteração. Essa decisão exige compreender retenção e correção de configuração. Novos jobs com retenção incompatível podem falhar em vez de receber ajuste automático. Verifica o resultado, não apenas a existência do plano. Para uma instância RDS, point-in-time restore cria outra instância sem modificar a origem. Revê configuração e acessos e planeia o cutover dos clientes. O estado available pode coexistir com carregamento de blocos em segundo plano e desempenho ainda em estabilização. Valida a carga necessária antes de declarar recuperada a capacidade que suporta o fecho.
Calcular o caminho crítico e aceitar o resultado
O modelo local soma oito minutos de deteção e decisão, o maior de dois ramos paralelos de dezoito e doze minutos, e sete minutos de validação: trinta e três minutos. Não somes trabalho paralelo como se fosse sequencial, nem omitas etapas que fazem parte do intervalo acordado. O código declara as dependências e rejeita ciclos; não executa um restauro real. Usa-o para discutir onde uma melhoria reduz o total: acelerar o ramo de doze minutos não altera o resultado enquanto o de dezoito dominar. No ensaio, substitui estimativas por observações e documenta limitações. A aceitação final combina tempo, perda de dados, funcionalidade, capacidade e pendências com responsáveis.
Controlar impacto num ensaio de falha
Um ensaio FIS deve começar com hipótese, alvos, estado estável e limites de impacto definidos. Liga uma stop condition a um alarme CloudWatch que represente degradação relevante para o serviço. Um experimento Running não prova que a experiência do cliente continua aceitável. A paragem termina o experimento e não permite retomar a mesma execução; post actions pendentes são tratadas antes de parar, mas a equipa continua responsável por verificar o estado funcional obtido e o trabalho de recuperação necessário. Planeia quem decide, quem observa e quem pode executar recuperação. Não alteres o limite durante a degradação apenas para manter o ensaio a decorrer. Regista o momento de violação e a resposta observada para avaliar o desenho.
Aceitar apenas a cobertura realmente ensaiada
O target preview com skip-all ajuda a inspecionar seleção, logging e certas configurações de contas, mas não aplica falhas nem valida todas as permissões de ação. Os alvos podem mudar entre preview e execução por alterações de recursos ou amostragem. Com emptyTargetResolutionMode=skip, ações sem recursos resolvidos por filtros podem ser ignoradas; isso não demonstra que os recursos pretendidos recuperam. No relatório, separa o que foi planeado, selecionado, efetivamente afetado e validado. O modelo local abaixo recusa uma alegação de ensaio completo quando só existe preview, há alvos por exercitar ou falta validação funcional. Não chama FIS nem injeta falhas. Usa-o para preparar a revisão de evidência do projeto antes da passagem a RUN.
# Original local dependency model, no AWS calls or resource changes.
def completion_times(tasks):
done, visiting = {}, set()
def finish(name):
if name in done:
return done[name]
if name in visiting:
raise ValueError("Dependency cycle")
if name not in tasks:
raise ValueError("Unknown dependency")
duration, dependencies = tasks[name]
if type(duration) is not int or duration < 0:
raise ValueError("Invalid duration")
visiting.add(name)
done[name] = max((finish(d) for d in dependencies), default=0) + duration
visiting.remove(name)
return done[name]
for name in tasks:
finish(name)
return done
plan = {"decision": (8, []), "database": (18, ["decision"]),
"compute": (12, ["decision"]), "validation": (7, ["database", "compute"])}
assert completion_times(plan)["validation"] == 33
assert completion_times({**plan, "compute": (5, ["decision"])})["validation"] == 33
assert completion_times({**plan, "database": (10, ["decision"])})["validation"] == 27
try:
completion_times({"a": (1, ["b"]), "b": (1, ["a"])})
raise AssertionError("Cycle accepted")
except ValueError:
pass
# Original local coverage exercise; not an FIS executor or recovery guarantee.
def rehearsal_evidence(expected, exercised, validated, preview_only):
if not expected:
return "scope missing"
if preview_only:
return "configuration evidence only"
if expected - exercised:
return "fault coverage incomplete"
if expected - validated:
return "functional validation incomplete"
return "recorded scope exercised and validated; review residual risk"
scope = {"worker-a", "worker-b"}
assert rehearsal_evidence(scope, set(), set(), True) == "configuration evidence only"
assert rehearsal_evidence(scope, {"worker-a"}, scope, False) == "fault coverage incomplete"
assert rehearsal_evidence(scope, scope, {"worker-a"}, False) == "functional validation incomplete"
assert rehearsal_evidence(scope, scope, scope, False).startswith("recorded scope")
assert rehearsal_evidence(set(), set(), set(), False) == "scope missing"
O job RDS acaba em 18 minutos, mas o serviço só regressa após alterar ligações, validar dados e atingir capacidade. O relatório conserva ambos os tempos e compara o segundo com o objetivo acordado.
Armadilhas comuns
Validar produção em vez do restauro; publicar sucesso antes das verificações; assumir que PITR altera a origem; medir apenas o job; ignorar integrações reativadas.
Tópicos relacionados: Prontidão, escala e saída controlada
Recuperação demonstrada liga ponto de dados, recurso, dependências, tempo e aceitação funcional. Um estado isolado do job não cobre esse conjunto.
Referência: AWS Backup restore testing validation · DOP-C02