RTO, RPO e MTTR: Definição de Objetivos de Recuperação

Sem objetivos de recuperação específicos e mensuráveis, é impossível projetar estratégias de backup apropriadas, escolher o nível correto do site de DR ou avaliar se os investimentos em tecnologia de recuperação são justificáveis. RTO, RPO e MTTR traduzem os requisitos de disponibilidade do negócio em metas precisas de engenharia. Essas métricas permitem que as equipes de segurança e IT tenham conversas baseadas em evidências com os executivos sobre o custo do downtime em comparação com o custo dos investimentos em DR, tornando os casos de negócio concretos em vez de abstratos.

O Objetivo de Time de Recuperação (RTO) é o tempo máximo aceitável entre o início de uma interrupção e a restauração do serviço normal. Se um sistema crítico de pagamentos falhar às 10:00 AM e a empresa puder tolerar no máximo 2 Hours de downtime antes de perder receita inaceitável ou violar SLAs, o RTO será de 2 Hours — o sistema deverá ser restaurado até as 12:00 PM, no máximo. O RTO orienta as escolhas sobre o nível do site de DR (site Hot para RTO de 15 Minutes em comparação com site Cold para RTO de 48 Hours), a frequência de replicação e a automação do failover.

O Objetivo de Ponto de Recuperação (RPO) é a perda máxima de dados aceitável, medida em Time — isto é, quanta perda de dados é tolerável se ocorrer um desastre. Um RPO de 1 hour significa que, quando os sistemas forem restaurados, eles deverão conter dados de no máximo 1 hour antes da ocorrência do desastre. O RPO orienta a frequência dos backups: um RPO de 1 hour exige pelo menos backups hourly (ou replicação contínua). Um RPO de 4 Hours pode tolerar intervalos de backup de 4 Hours. O RPO trata da recuperação de dados, enquanto o RTO trata da restauração da disponibilidade do Service.

RTO e RPO tratam de aspectos diferentes da recuperação e devem ser definidos de forma independente. Um sistema pode ter um RPO rigoroso (1 hour, significando que os dados são replicados frequentemente), mas um RTO flexível (4 Hours, significando que é necessário Time para iniciar o ambiente de DR, mesmo que os dados estejam atualizados). Por outro lado, um sistema pode ter um RPO flexível (24 Hours, um backup Nightly é suficiente), mas um RTO rigoroso (é necessário failover em 1 hour, portanto deve existir um ambiente de DR provisioned previamente, pronto para ser ativado). Ambas as métricas vêm da Análise de Impacto nos Negócios.

O Tempo Médio de Recuperação (MTTR) é o tempo médio real necessário para restaurar o Service após um Incident — a medição operacional do desempenho da recuperação. Enquanto o RTO é o downtime máximo tolerável (meta/requisito), o MTTR é a média observada (desempenho real). As organizações medem o MTTR ao longo do Time, considerando diversos Incidents, e o comparam ao RTO para avaliar sua capacidade de recuperação. Um MTTR que excede consistentemente o RTO indica que os recursos de DR são insuficientes e que são necessários investimentos em automação, pessoal ou infraestrutura.

O Tempo Médio Entre Falhas (MTBF) mede a confiabilidade do sistema — o Time médio que um sistema opera entre falhas. Um MTBF Higher indica melhor confiabilidade. MTBF e MTTR determinam juntos a porcentagem de Availability: Availability = MTBF / (MTBF + MTTR). Um sistema com MTBF de 2000 Hours e MTTR de 2 Hours tem Availability de 2000/2002 = 99,9%. Entender o MTBF ajuda a prever quando as falhas provavelmente ocorrerão e a planejar adequadamente as janelas de manutenção — equipamentos com MTBF em declínio estão se aproximando do fim da vida útil e devem ser substituídos de forma proativa.

O Tempo Máximo de Indisponibilidade Tolerável (MTD) é o Time máximo absoluto em que um sistema pode ficar indisponível antes que o negócio sofra danos irreversíveis — perda de clientes, penalidades regulatórias ou incapacidade de cumprir obrigações contratuais. O MTD é sempre maior ou igual ao RTO. A relação é: MTD é o limite do negócio; RTO é a meta de IT. Se um contrato permitir uma violação de SLA de 4 Hours antes da aplicação de penalidades, o MTD poderá ser de 4 Hours. A equipe de IT projeta um RTO de 1–2 Hours para proporcionar uma margem de segurança antes de atingir o MTD.

Os Service Level Agreements (SLAs) definem compromissos contratuais com os clientes que orientam diretamente os requisitos de RTO e RPO. Um SLA de provedor de Cloud que promete 99,95% de Uptime permite aproximadamente 4,4 Hours de downtime por ano. A violação do SLA aciona créditos de Service ou direitos de rescisão contratual. Os SLAs internos entre IT e as unidades de negócio funcionam de forma semelhante. O RTO e o RPO devem ser projetados para manter o downtime real dentro dos compromissos do SLA, e o MTTR deve ser medido e reportado para demonstrar conformidade.

As escolhas tecnológicas são determinadas diretamente pelos requisitos de RTO e RPO. Um RTO de 15 Minutes com RPO zero exige clusterização ativa-ativa com replicação Synchronous — nenhuma perda de dados e failover automático. Um RTO de 4 Hours com RPO de 1 hour pode utilizar envio de logs ou replicação assíncrona para um standby Warm. Um RTO de 24 Hours com RPO de 24 Hours pode utilizar backups Daily em armazenamento Cold. Projetar uma resiliência maior do que a necessária desperdiça o orçamento; projetar menos cria um risco de negócio inaceitável durante os Incidents.

Os objetivos de recuperação só são válidos quando são validados regularmente por meio de testes. As organizações devem realizar testes de recuperação que meçam o MTTR real e verifiquem o ponto de recuperação de dados real (qual é a idade dos dados quando restaurados?). Se um teste revelar que o MTTR é consistentemente de 3 horas, enquanto o RTO é de 1 hora, a lacuna deve ser resolvida — seja melhorando a infraestrutura de DR (automatização, pré-provisionamento), seja reajustando as expectativas do negócio por meio de uma BIA atualizada. A frequência dos testes deve corresponder à criticidade: sistemas críticos trimestralmente e os demais anualmente.

Os relatórios de RTO, RPO e MTTR devem ser comunicados às partes interessadas do negócio em termos que elas compreendam. Em vez de dizer “nosso MTTR para sistemas de nível 1 é de 47 minutos”, diga: “quando nossos sistemas mais críticos falham, restauramos o serviço em menos de uma hora, em média — dentro da janela de 2 horas permitida por nossos contratos”. Relatórios regulares aumentam a confiança das partes interessadas e criam um entendimento compartilhado sobre a resiliência da organização. Relatórios em painéis sobre as tendências do MTTR ao longo do tempo demonstram a melhoria do programa e ajudam a justificar o orçamento para investimentos em DR.

Teste sua compreensão dos conceitos do CompTIA Security+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu que: o RTO é o tempo máximo durante o qual o serviço pode ficar indisponível e determina os requisitos de velocidade do failover; o RPO é a perda máxima de dados aceitável e determina a frequência de backup e replicação; e o MTTR é o tempo médio real de recuperação medido, comparado ao RTO para avaliar a eficácia do programa de DR. A seguir, exploraremos estratégias de backup — a regra 3-2-1 e os backups imutáveis que o ransomware não consegue destruir.