A perspetiva da Cyber Academy
O RTO é a duração máxima aceitável durante a qual um processo de negócio pode estar indisponível antes de causar danos inaceitáveis. O RPO é a perda máxima de dados medida em tempo antes da perturbação. Ambos resultam da BIA. Os números que o CIO insere no BCP sem consultar o negócio são os que falham sob pressão.
Dois relógios que medem coisas diferentes
O RTO e o RPO são os dois objetivos de recuperação que transformam uma promessa vaga de resiliência em números verificáveis. É fácil confundi-los porque ambos são expressos em unidades de tempo, mas medem coisas diferentes e apontam para soluções diferentes. O recovery time objective trata de quanto tempo você pode ficar inativo. O recovery point objective trata de quantos dados você pode se permitir perder. Confunda-os e comprará a arquitetura de recuperação errada.
Imagine a interrupção como um único instante numa linha do tempo. O RTO olha para a frente a partir desse instante: é a janela máxima entre a falha e o momento em que o processo volta a ser utilizável, antes que o dano se torne inaceitável. O RPO olha para trás a partir desse instante: é a idade máxima da última cópia válida de dados para a qual você pode recuperar, o que equivale aos dados mais recentes que você está disposto a perder. Um RTO de quatro horas com um RPO de quinze minutos significa que o serviço deve ser restabelecido em menos de quatro horas e não pode perder mais de quinze minutos de transações.
| RTO | RPO | |
|---|---|---|
| Mede | Tempo de inatividade aceitável | Perda de dados aceitável |
| Direção na linha do tempo | Para a frente a partir da interrupção | Para trás a partir da interrupção |
| Pergunta que responde | Com que rapidez devemos voltar a funcionar? | Quantos dados podemos perder? |
| Principalmente determinado por | Processo de recuperação, failover, equipe | Frequência de backup e replicação |
| Fonte | Análise de impacto no negócio | Análise de impacto no negócio |
De onde vêm os números e por que a responsabilidade importa
Ambos os objetivos são resultados da análise de impacto no negócio, não suposições feitas na sala de servidores. A BIA estuda cada atividade crítica, mede como o dano de uma falha cresce ao longo do tempo e produz objetivos de recuperação que o responsável pelo processo valida. Essa responsabilidade é justamente o ponto central. Um RTO e um RPO que uma equipe técnica define de forma isolada descrevem o que a infraestrutura consegue fazer, não o que o negócio precisa, e a lacuna entre os dois só aparece durante um incidente real, que é o pior momento para descobri-la.
Os objetivos também precisam ser conciliados com o custo. Levar um RPO em direção a zero implica replicação contínua ou síncrona. Levar um RTO em direção a minutos implica capacidade de standby a quente que permanece ociosa. Ambos são caros, portanto a BIA força uma conversa honesta sobre quais processos realmente justificam esse gasto e quais podem tolerar uma janela mais longa. Escalonar as atividades por níveis é normal: o motor de pagamentos e o site de marketing raramente merecem os mesmos objetivos.
Como o RTO e o RPO se encaixam nas normas
Esses objetivos são vocabulário central nos frameworks de continuidade e resiliência. A ISO 22301, a norma internacional para sistemas de gestão de continuidade de negócio, trata os recovery time e recovery point objectives como resultados da análise de impacto que orientam a estratégia e as soluções de continuidade. Eles fluem diretamente para o desenho da recuperação de desastres, os cronogramas de backup e a escolha dos sites de recuperação. Em setores regulados, eles são cada vez mais examinados em vez de presumidos: o Regulamento de Resiliência Operacional Digital da UE (DORA) estabelece expectativas de continuidade e de teste para as entidades financeiras, e a Diretiva NIS 2 exige medidas de continuidade de negócio e de backup das entidades essenciais e importantes.
Os profissionais fazem três coisas com esses números. Eles os derivam da BIA junto com os responsáveis pelo negócio. Projetam backup, replicação e failover para que a arquitetura realmente consiga cumpri-los. Depois provam isso por meio de testes, porque um RTO não testado é uma aspiração. O objetivo só conquista confiança depois que um exercício de recuperação mostrou que a equipe consegue atingi-lo em condições realistas.
Frequently asked questions
01Qual é a diferença entre o RTO e o RPO?
O RTO é o tempo máximo que um processo pode ficar inativo antes que o dano se torne inaceitável, medido para a frente a partir da interrupção. O RPO é a perda máxima de dados que você pode tolerar, medida para trás a partir da interrupção como a idade da última cópia recuperável. Um determina a velocidade de recuperação, o outro a frequência de backup.
02De onde vêm os valores de RTO e RPO?
São resultados da análise de impacto no negócio. A BIA classifica cada atividade conforme o dano de uma interrupção cresce ao longo do tempo e produz objetivos que o responsável pelo processo valida, em vez de números definidos pela TI de forma isolada.
03Um RPO baixo exige backups contínuos?
Geralmente sim. O RPO não pode ser mais curto que o intervalo entre cópias recuperáveis, portanto um RPO próximo de zero precisa de replicação frequente ou contínua. Reduzir o RPO aumenta, assim, o custo, razão pela qual a BIA reserva os objetivos mais rigorosos para as atividades que os justificam.
04O que acontece se a nossa recuperação demorar mais do que o RTO?
Você tem uma lacuna de resiliência. O RTO é a meta tolerável; o tempo que a recuperação realmente leva é o recovery time achieved, medido em um teste. Se o tempo alcançado exceder o objetivo, você fecha a lacuna melhorando o processo de recuperação ou aceita um risco documentado, mas não afrouxa a meta em silêncio.
05O RTO e o RPO dizem respeito apenas a sistemas de TI?
Eles são aplicados com mais frequência a dados e serviços de TI, mas pertencem aos processos de negócio. Um processo pode ter seus sistemas restabelecidos dentro do RTO e ainda assim ser incapaz de operar se faltarem pessoas, instalações ou um fornecedor crítico, razão pela qual os objetivos são validados em relação à atividade como um todo, e não apenas à aplicação.