APRENDER. PRATICAR. EVOLUIR.Definir o que significa recuperar
Uma plataforma fictícia recebe instruções, guarda documentos em S3 e atualiza uma base de dados. No ensaio de recuperação, a equipa consegue ler documentos antigos, mas nenhuma instrução nova é processada. O resultado mostra por que motivo restaurar dados é apenas parte da aceitação. Define operações críticas, perda de dados tolerável, prazo de recuperação e autoridade de decisão antes da janela. Inclui versões da aplicação, configuração, permissões e integrações no inventário de dependências. Regista quem valida cada resultado e quando o serviço pode receber tráfego. Um teste de leitura pode ser necessário sem ser suficiente: a escrita, a emissão de eventos e a reconciliação do intervalo interrompido também podem ser obrigatórias.
Escolher o papel de cada cópia RDS
Distingue uma read replica de uma standby de uma implantação Multi-AZ DB instance. A primeira recebe replicação assíncrona e pode servir leituras; a segunda suporta disponibilidade e não é um destino de consultas de leitura nessa arquitetura. Não generalizes esta restrição a Multi-AZ DB clusters, que têm outro desenho. Numa aplicação que exige ler imediatamente uma escrita confirmada, uma réplica com lag pode devolver um estado anterior. Define quais consultas toleram essa diferença. Num failover Multi-AZ, o endpoint é atualizado por DNS e as ligações existentes precisam de recuperação. Uma JVM que conserva o endereço anterior pode falhar enquanto clientes novos ligam, pelo que o runbook deve incluir cache DNS, pools e reconexão.
Preparar uma promoção planeada
No exemplo RDS PostgreSQL, a origem continua acessível e o requisito é não perder escritas confirmadas. Antes da promoção, controla novas escritas e confirma que a réplica recebeu as alterações pendentes. A promoção interrompe a replicação dessa réplica e cria uma instância autónoma; não mantém dois writers sincronizados. Planeia a alteração de encaminhamento, permissões, backups e topologia posterior. Valida operações funcionais antes de declarar a mudança concluída. Se houver perda da origem e lag desconhecido, a decisão terá outras incertezas: não reutilizes a promessa deste ensaio planeado. O responsável de mudança deve registar a evidência, o risco residual e a condição que impede continuar. Uma pressão de calendário não altera as propriedades da replicação.
Provar o estado do destino S3
Uma regra nova de live replication não resolve automaticamente todos os objetos anteriores. Usa Batch Replication quando adequado, com manifesto e relatório por objeto e versão. Um job Complete pode conter tarefas falhadas; compara resultados com o conjunto esperado. Com vários destinos, uma cópia observada não prova sucesso em todos. Se a replicação falhou por permissões KMS, corrigir a permissão não basta para assumir repetição automática dos objetos FAILED. Confirma também a chave do destino: a aceitação de PutBucketReplication não valida a chave indicada. Finalmente, configuração do bucket, como notificações, não acompanha a replicação de objetos. A eliminação explícita de uma versão na origem também não é propagada dessa forma, o que exige uma política própria de conservação e limpeza.
Restaurar DynamoDB e as dependências
PITR restaura para uma tabela nova. As operações na origem podem continuar, por isso define o instante pretendido e reconcilia alterações posteriores antes do cutover. Consulta o intervalo realmente recuperável; aumentar hoje a retenção não cria retroativamente dias que não foram conservados. ContinuousBackupsStatus e PointInTimeRecoveryStatus têm significados diferentes e não devem ser confundidos. Depois do restore, verifica configurações que precisam de ser repostas, incluindo Streams, TTL, autoscaling, alarmes, tags e PITR. Se excluíres um índice para reduzir o trabalho de recuperação, testa as consultas que dependiam dele. Uma tabela Active pode estar disponível sem satisfazer o contrato da aplicação. Usa a identidade da tabela e do stream novos ao validar permissões e consumidores, evitando referências antigas no deployment.
Exercício: controlar a sequência de cutover
O modelo local representa uma mudança planeada através de estados: autorização, controlo de escritas, sincronização, promoção, dependências e validação funcional. Recusa passos fora de ordem e só aceita tráfego após concluir a sequência. Não consulta RDS, não mede lag, não garante isolamento e não implementa failover real. Executa os casos, tenta promover antes de sincronizar e descreve que evidência real sustentaria cada passo. Depois acrescenta uma condição de interrupção se a validação funcional falhar. No relatório do ensaio, regista os instantes observados e compara-os com o objetivo interno, sem transformar a duração de um exercício numa garantia do fornecedor. A passagem de turno deve indicar a topologia final, trabalho pendente e dono da reconciliação.
# Original local ordering exercise, not an RDS failover engine or atomic cutover guarantee.
STEPS = ("authorized", "writes_controlled", "caught_up", "promoted", "dependencies_ready", "function_validated")
def advance(done, step, evidence):
if tuple(done) != STEPS[:len(done)] or len(done) >= len(STEPS):
raise ValueError("invalid or finished sequence")
if step != STEPS[len(done)] or evidence is not True:
raise ValueError("order or evidence missing")
return done + [step]
def may_accept_traffic(done):
return tuple(done) == STEPS
done = []
for step in STEPS:
assert not may_accept_traffic(done)
done = advance(done, step, True)
assert may_accept_traffic(done)
for previous, step, evidence in [([], "promoted", True), (["authorized"], "writes_controlled", False), (["promoted"], "dependencies_ready", True)]:
try:
advance(previous, step, evidence)
except ValueError:
pass
else:
raise AssertionError("unsafe sequence accepted")
Exemplo fictício: documentos estão no destino, mas as notificações não existem. A equipa repõe a integração e reconcilia os ficheiros recebidos durante a interrupção antes de aceitar o serviço.
Armadilhas comuns
Armadilhas: confundir standby e read replica, promover com escritas não reconciliadas, aceitar Complete sem resultados por objeto e assumir que restore repõe todas as integrações.
Tópicos relacionados: Cobertura de segurança e evidência de conformidade
Recuperação aceite exige dados adequados ao objetivo, dependências repostas e uma operação funcional demonstrada no destino.
Referência: DOP-C02 resilient cloud solutions objectives · DOP-C02