APRENDER. PRATICAR. EVOLUIR.Distinguir revisão de tempo de negócio
Uma revisão identifica a ordem lógica de alterações em etcd; não é uma hora de negócio nem uma contagem de segundos. No laboratório, o snapshot tem uma revisão inferior à observada após as escritas adicionais. O restauro normal regressa ao ponto capturado. Uma leitura que pede explicitamente a revisão superior da origem recebe uma rejeição de revisão futura no destino. Regista os três valores: revisão do snapshot, observação posterior e revisão restaurada. A diferença explica o comportamento do pedido, mas não calcula RPO em minutos. Esse cálculo exige ligar os dados recuperáveis a tempos e operações do serviço.
Aumentar a revisão sem inventar dados
O segundo restauro usa o mesmo artefacto, bump-revision=1000 e mark-compacted. A revisão passa a ultrapassar a maior observação do pequeno conjunto de teste, mas os valores continuam no ponto do snapshot. A chave criada depois permanece ausente. O incremento foi escolhido para este exercício limitado e não deve ser copiado como constante de produção. Num plano real, estima o avanço possível desde a captura, considera a idade do snapshot e justifica a margem. Se a revisão capturada for 400 e a maior observação 950, um incremento de 551 ultrapassa esse valor por uma unidade; isso é apenas o limite aritmético, sem margem operacional.
Interpretar compaction e reconstruir consumidores
No destino ajustado, o laboratório pede uma revisão antiga através de uma leitura histórica e de um watch. Ambos reportam compaction. Esse sinal permite demonstrar que o historial pedido deixou de estar disponível; não demonstra que uma aplicação reconstruiu a sua cache. Um consumidor precisa de tratar o resultado segundo o seu contrato: obter estado consistente, reconciliar inclusões e exclusões e retomar a observação numa posição adequada. O ensaio não executa informers Kubernetes e não valida esse processo para qualquer framework. Na aceitação da aplicação, compara o estado reconstruído e introduz uma alteração controlada posterior para observar a continuidade.
Observar a continuação e conservar o artefacto
Após o restauro com incremento, o script grava outra chave de teste. Verifica que a revisão avança e que os três membros devolvem esse valor. Confirma também que o digest do snapshot original não mudou. São verificações diferentes: a primeira observa progresso, a segunda concordância numa leitura delimitada e a terceira preservação do artefacto. Nenhuma prova que dados posteriores perdidos foram recuperados. As garantias de watches também não estabelecem um limite universal de latência de entrega. Se um consumidor tiver um objetivo de atraso, define a medição e ensaia as condições representativas, conservando a distinção entre garantia da API e objetivo do serviço.
Medir RPO e RTO com a função acordada
Considera um incidente fictício às 09:00, fim do comando de restauro às 09:07 e aceitação da função às 09:24. Se o RTO acordado for vinte minutos e a função só ficar disponível na aceitação, a recuperação demora vinte e quatro minutos. Regista o desvio e os tempos intermédios para localizar melhorias. Para RPO, usa o último ponto de negócio recuperável, incluindo dependências e fontes adicionais realmente disponíveis. Aumentar a revisão não torna esse ponto mais recente. Não alteres o objetivo após veres o resultado; uma exceção aprovada pode permitir operação temporária, mas deve preservar a medição original e os riscos aceites.
Oficina de decisão e comunicação em inglês
Reserva quarenta e cinco minutos: dez para prever os resultados, quinze para executar e comparar evidência, dez para decidir a retoma e dez para apresentar o estado em inglês. Distribui os papéis de APS, responsável da aplicação e sponsor. Usa um caso em que o cluster recuperou, a cache ainda contém uma regra antiga e o agendador aponta para endpoints anteriores. Entrega uma decisão com evidência passada, condições em falta, responsável e prazo de nova avaliação. No briefing, distingue resultados locais, hipótese operacional e aprovação. O laboratório usa até três processos simultâneos no mesmo host Darwin ARM64, classificado como tier 3 na documentação consultada; não qualifica uma arquitetura de produção.
# After running the self-contained lab from the preceding lesson:
python3 - <<'PYCODE'
import json
from pathlib import Path
result = json.loads(Path('evidence.json').read_text())
assert result['passed'] == 10 and result['failed'] == 0
for check in result['checks']:
print(check['name'], check['observations'])
# This reads local exercise evidence. It does not query a production service.
PYCODEO cluster recuperado apresenta revisão maior, mas a cache continua desatualizada. A equipa mantém o consumidor suspenso, reconcilia o estado e verifica uma alteração posterior antes de aceitar a retoma.
Armadilhas comuns
Tratar bump como recuperação de dados; repetir cursores compactados sem tratar o resultado; medir RTO só pelo comando; atribuir a um informer uma reação que o laboratório não executou.
Tópicos relacionados: Objetivos e dependências · Restauro: ponto recuperado e integridade · Retoma: replay e aceitação operacional
Revisão, conteúdo e estado do consumidor precisam de evidência própria. A recuperação termina na função acordada, com o ponto de dados conhecido e os riscos da retoma explicitamente decididos.
Referência: Disaster recovery · DR recovery 2026-09; PostgreSQL 18, etcd 3.6 and selected AWS/Azure behavior