Defina e teste RTO e RPO

Defina dois objetivos separados

O Recovery Time Objective (RTO), ou objetivo de tempo de recuperação, define a interrupção máxima aceitável até o retorno do serviço útil. O Recovery Point Objective (RPO), ou objetivo de ponto de recuperação, define a perda máxima aceitável de dados medida em tempo. Acorde esses objetivos com o responsável de negócio para um serviço e um cenário de falha definidos.

Uma meta de disponibilidade descreve o desempenho do serviço ao longo de um período. RTO e RPO descrevem expectativas de recuperação. Eles respondem a perguntas diferentes.

Para um serviço fictício de pedidos, o responsável define RTO de 60 minutos e RPO de 15 minutos. São valores de exemplo, não recomendações gerais. Outro serviço pode precisar de limites diferentes porque pedidos perdidos e relatórios atrasados têm consequências diferentes.

Meça a recuperação completa

O serviço para às 10:00. A equipe registra este exercício:

O tempo decorrido de recuperação é de 55 minutos. O exercício atende ao RTO de 60 minutos. Contar apenas os 25 minutos da operação de restauração esconderia a maior parte da interrupção.

O ponto utilizável de recuperação mais recente é 09:40. O intervalo até a interrupção às 10:00 é de 20 minutos. Isso excede o RPO de 15 minutos em 5 minutos. Restaurar os mesmos dados mais rápido não eliminaria esse intervalo.

Inspecione os registros realmente ausentes ou inconsistentes. Um intervalo de tempo descreve a exposição; não conta os pedidos afetados. Reconcilie registros externos de pagamento e atendimento dos pedidos antes de retomar o processamento normal. Experimente premissas diferentes no exercício de recuperação.

Escolha uma estratégia de recuperação

Uma estratégia deve cobrir o serviço, os dados e as dependências necessários. Compare estes padrões com objetivos medidos:

Não há tempos universais de recuperação para esses padrões. Implementação, volume de dados, dependências e condições de teste determinam o resultado. Inclua o custo operacional e a capacidade da equipe na decisão.

Proteja-se contra mais que uma indisponibilidade

Uma réplica pode copiar uma exclusão indesejada ou um registro corrompido. Mantenha versões recuperáveis ou recuperação para um ponto no tempo quando necessário. Verifique retenção, permissões de restauração e acesso às chaves de criptografia. Ajuste o isolamento dos backups ao cenário, incluindo a perda de acesso à conta principal.

Para recuperação regional, verifique o local permitido dos dados e toda a cadeia de dependências. Inclua identidade, DNS, certificados, segredos, artefatos de deployment, cotas e acesso à rede. Um ambiente de recuperação sem uma única chave necessária pode ser inutilizável.

Defina quem pode declarar o evento, quem executa a recuperação e quem aceita o serviço restaurado. Planeje o retorno ao ambiente original ou a operação continuada no ambiente de recuperação. Impeça escritas conflitantes e reconcilie os dados antes de mudar novamente.

Transforme o plano em evidência

Escreva um runbook e exercite-o em condições controladas. Registre cenário, tamanho do conjunto de dados, horários de início e fim, ponto de recuperação dos dados, etapas que falharam e responsáveis. Verifique uma operação real de negócio com registros seguros de teste.

Repita o exercício após alterações relevantes e na periodicidade acordada. Uma mudança de schema, uma nova dependência externa ou outro volume de dados pode invalidar resultados anteriores. Vincule as evidências do exercício ao release e às responsabilidades operacionais.