Definir e testar RTO e RPO

Defina dois objetivos separados

O Recovery Time Objective (RTO) define a interrupção máxima aceitável, até ao fim da qual o serviço tem de voltar a ser utilizável. O Recovery Point Objective (RPO) define a perda máxima aceitável de dados, medida em tempo. Acorde estes objetivos com o responsável de negócio para um serviço e um cenário de falha definidos.

Um objetivo de disponibilidade descreve o desempenho do serviço ao longo de um período. O RTO e o RPO descrevem expectativas de recuperação. Respondem a perguntas diferentes.

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

Meça a recuperação completa

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

O tempo decorrido de recuperação é de 55 minutos. O exercício cumpre o RTO de 60 minutos. Contar apenas os 25 minutos da operação de restauro ocultaria a maior parte da interrupção.

O ponto de recuperação utilizável mais recente é das 09:40. O intervalo até à interrupção das 10:00 é de 20 minutos. Isto excede o RPO de 15 minutos em 5 minutos. Restaurar mais depressa os mesmos dados não reduziria esse intervalo.

Examine os registos realmente em falta ou inconsistentes. Um intervalo temporal descreve a exposição; não conta as encomendas afetadas. Reconcilie os registos externos de pagamento e de processamento das encomendas antes de retomar o processamento normal. Experimente pressupostos diferentes no exercício de recuperação.

Escolha uma estratégia de recuperação

Uma estratégia tem de abranger o serviço, os dados e as dependências necessários. Compare estes padrões face a objetivos medidos:

Não existem tempos de recuperação universais para estes padrões. A implementação, o volume de dados, as dependências e as condições de teste determinam o resultado. Inclua o custo operacional e a capacidade da equipa na decisão.

Proteja contra mais do que uma indisponibilidade

Uma réplica pode copiar uma eliminação indesejada ou um registo corrompido. Mantenha versões recuperáveis ou recuperação para um instante específico quando necessário. Verifique a retenção, as permissões de restauro e o acesso às chaves de cifra. Adeque o isolamento das cópias de segurança ao cenário, incluindo a perda de acesso à conta principal.

Para a recuperação regional, verifique a localização permitida dos dados e toda a cadeia de dependências. Inclua identidade, DNS, certificados, segredos, artefactos de deployment, quotas e acesso à rede. Um ambiente de recuperação a que falte uma 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. Planeie o regresso ao ambiente original ou a operação continuada no ambiente de recuperação. Impeça escritas em conflito e reconcilie os dados antes de voltar a mudar.

Transforme o plano em evidências

Escreva um runbook e execute-o em condições controladas. Registe o cenário, o tamanho do conjunto de dados, as horas de início e fim, o ponto dos dados recuperados, os passos falhados e os responsáveis. Verifique uma operação real do negócio com registos de teste seguros.

Repita o exercício após alterações relevantes e segundo o calendário acordado. Uma alteração de esquema, uma nova dependência externa ou um volume de dados diferente pode invalidar resultados anteriores. Ligue as evidências do exercício ao lançamento e às responsabilidades operacionais.