Na continuidade do negócio e na recuperação de desastres de TI, os termos RTO e RPO são frequentemente utilizados em conversas sobre requisitos de recuperação.

 

Embora os termos estejam intimamente relacionados, têm significados e utilizações distintos.

 

Este blogue irá definir RTOs e RPOs com uma análise mais detalhada da forma como estes termos são utilizados na continuidade do negócio e nos programas de recuperação de desastres de TI.

 

O que é o objetivo de tempo de recuperação (RTO)?

 

De acordo com a ISO 22300:2021um objetivo de tempo de recuperação (RTO) é o “período de tempo após um incidente no qual um produto ou serviço ou uma atividade é retomada, ou os recursos são recuperados”.

 

Nas conversas sobre continuidade do negócio e resiliência operacional, o RTO define um período de tempo específico e é geralmente indicado como um número definido de horas, dias, semanas, etc.

 

Em termos simples, um RTO inicia o relógio para marcar o período de tempo em que a sua organização pode sobreviver ao tempo de inatividade e regressar às operações normais, mantendo a continuidade. Podes utilizar o termo RTO tanto para funções empresariais como para recursos. É importante notar que isto não é o mesmo para o RPO.

 

As RTOs variam de organização para organização, mas aqui estão alguns dos factores que podem influenciar a tua RTO:

 

  • Qual a receita que a tua organização perderá por cada hora de inatividade

  • Qual a perda que a tua organização pode absorver/ suportar

  • Recursos necessários para restabelecer a normalidade das operações

  • Tolerância do cliente ao tempo de inatividade

 

Ao discutir a continuidade do negócio, os seus recursos podem abranger uma série de categorias, incluindo aplicações, fornecedores, instalações, pessoas e equipamento. Cada recurso pode ter um RTO exclusivo que indica o período de tempo em que um recurso específico deve retomar as operações após uma interrupção.

 

De acordo com a Federal Emergency Management Agency (FEMA), cerca de 25% das empresas não reabrem após desastres. E, de acordo com outro relatório, cerca de 16% dos executivos de pequenas e médias empresas (PME) não conhecem os RTOs da sua organização. Outro quarto diz que, em caso de catástrofe, pensa que pode recuperar os dados em 10 minutos ou menos, com cerca de 30% a dizer que isso pode ser feito em menos de uma hora.

 

Infelizmente, concetualizar e identificar RTOs é complicado. É por isso que é importante analisar mais detalhadamente o âmbito das RTOs para garantir que defines sempre prazos de RTO adequados para os teus recursos – especialmente os mais críticos para as tuas operações principais.

 

A realidade é que um RTO se baseia em muitos factores e, para alguns, um RTO pode variar entre horas e semanas/meses. Para identificar RTOs apropriados para as suas funções comerciais, considera o impacto do tempo de inatividade, incluindo vários tipos de impacto, tais como financeiro, legal, operacional e de reputação.

 

Como é que identificas um RTO?

 

Para identificar um RTO, considera estas duas questões:

 

  • Em que momento, após uma perturbação, a minha organização sofreria impactos negativos significativos?

  • Quais seriam esses impactos?

 

As respostas a estas perguntas podem ajudar a alinhar os “impactos significativos e negativos” com a apetência pelo risco da tua organização.

 

É importante notar que se a tua equipa de liderança executiva aceita uma certa tolerância ao risco, os teus RTOs devem estar alinhados com esses níveis de tolerância.

 

Para te ajudar a identificar melhor as RTOs de recursos, alinha os teus recursos com as funções empresariais que suportam.

 

Pensa da seguinte forma: Se uma função empresarial pode estar em baixo durante um determinado período de tempo, os recursos necessários para executar essa função também podem estar em baixo durante esse período de tempo. (Claro que há sempre excepções, como as ferramentas de segurança da informação que devem estar sempre a funcionar).

 

Também deves considerar quaisquer soluções manuais que a tua equipa possa utilizar. Se existirem soluções manuais viáveis, o recurso em si pode ter um RTO mais longo porque o tempo de inatividade não teria um impacto tão grande na resiliência operacional.

 

Quais são alguns exemplos de RTO?

 

As RTOs variam de organização para organização. No entanto, aqui estão alguns exemplos de RTOs. Como seriam estas mesmas RTOs para a tua organização?

 

  • Envia o pedido por e-mail: 4 horas

  • Sistemas e serviços financeiros: 1-2 dias

  • Sistema de gestão da relação com o cliente (CRM): 1 dia

 

 

 

O que é o Objetivo do Ponto de Recuperação (RPO)?

 

De acordo com a ISO 22300:2021um Objetivo de Ponto de Recuperação (RPO) é o “ponto até ao qual a informação utilizada por uma atividade é restaurada para permitir que a atividade funcione quando for retomada; também pode ser referido como ‘perda máxima de dados'”.

 

O termo RPO aplica-se geralmente a um sistema ou aplicação que armazena dados. Os RPOs são métricas para determinar a quantidade de dados que estás disposto a perder (ou a quantidade de dados que estás disposto a reintroduzir) desde o backup até à recuperação de desastres.

 

Existem diferentes formas de pensar sobre a perda de dados. Por exemplo, podes pensar de forma holística – perder uma base de dados inteira – ou podes pensar na perda de dados do ponto de vista da transação – perder o [period of time] anterior de actualizações, ficheiros, transacções, etc.

 

Quando falas de RPOs, deves referir-te a dados transaccionais em vez de dados arquivados. Por exemplo, um repositório de contratos jurídicos. O teu RPO aplicar-se-ia a ficheiros novos ou actualizados, não a dados históricos.

 

Por outras palavras, um RPO de um dia ou tolerância à perda de dados significa que podes perder um dia de actualizações ou carregamentos no sistema.

 

Ao determinar os RPO, considera fontes alternativas de dados, incluindo a recriação de dados ou trabalho perdidos. Se tiveres uma fonte de cópia de segurança para os dados – ou se puderes recriar facilmente os dados – poderá haver uma maior tolerância à perda de dados.

 

Eis alguns factores que podem influenciar o teu RPO:

 

  • Número de aplicações e sistemas críticos

  • Complexidade destas aplicações e sistemas

  • Volume de dados

  • Métodos de cópia de segurança dos dados

  • Com que frequência os dados são alterados

  • Frequência da cópia de segurança dos dados

  • Armazenamento de dados e acessibilidade

  • Recursos internos

 

É de salientar que, ao falar de RPO, a frequência de cópias de segurança da sua organização pode ter o maior impacto no seu RPO, mas a frequência é por vezes negligenciada no planeamento da resiliência.

 

Embora muitas (espero que a maioria) organizações tenham backups de rotina de dados e sistemas, esses backups podem não ocorrer com a frequência que uma organização realmente precisa, algo que muitas vezes só é descoberto depois de um desastre ou de uma interrupção significativa.

 

Então, se estas cópias de segurança são tão importantes, porque é que as organizações não as fazem com mais frequência?

 

Em muitos casos, as cópias de segurança frequentes têm um custo proibitivo. Quanto mais dados a sua organização tiver, e quanto mais frequentemente forem replicados e armazenados, mais espaço de armazenamento necessita, o que aumenta rapidamente os custos.

 

Porque é que isto é importante?

 

Porque, se sofrer uma catástrofe ou perturbação, pode antecipar a possibilidade de perda de dados. O seu RPO ajuda a determinar a quantidade de dados que pode arriscar perder, com base no período de tempo que decorre desde a cópia de segurança mais frequente até ao regresso à normalidade.

 

 

 

Diferenças entre RTO e RPO

 

Embora os RTOs e os RPOs estejam relacionados, existem diferenças. Enquanto os RTOs olham para a frente no tempo (o tempo que tens para recuperar), os RPOs olham para trás (quando foi a tua última melhor cópia de segurança de dados e quanto tempo precisas para a restaurar?)

 

Os RPOs variam de tempo sem perda de dados (0 horas) a alguns dias, dependendo de uma variedade de factores.

 

Os RTOs e RPOs são factores importantes no planeamento da recuperação de desastres e da continuidade do negócio. Se não conheceres as tuas métricas de RTO e RPO, a maior parte do teu planeamento de resiliência pode ser em vão – especialmente se subestimares o tempo que a tua organização pode sobreviver ao tempo de inatividade ou o volume de dados que a tua organização pode perder e ainda assim sobreviver.

 

E, embora algumas organizações conheçam suas próprias métricas relacionadas ao tempo, o feedback do setor sugere que, como um todo, não fazemos um bom trabalho explorando os RTOs de nossos fornecedores e vendedores. Os RTOs de fornecedores e vendedores podem ter um impacto direto e distorcer as tuas próprias métricas de recuperação.

 

 

 

Como é que os termos RTO e RPO são utilizados nos programas de continuidade do negócio/recuperação de desastres de TI?

 

Os RTOs e RPOs são normalmente utilizados:

 

  • Para dar prioridade às funções empresariais em caso de perturbação, permitindo que os líderes saibam quais as funções que devem ser activadas quando

  • Efetuar uma análise das lacunas em relação aos tempos de recuperação previstos para identificar os riscos de continuidade da atividade e de recuperação de catástrofes informáticas

  • Selecionar estratégias adequadas de recuperação e cópia de segurança para recursos/dados, incluindo quanto é que a tua organização vai gastar em soluções alternativas

 

 

 

RTOs e RPOs: Como Castellan pode ajudar a tua organização com a continuidade do negócio

 

Os RTOs e RPOs definem os requisitos fundamentais para os seus programas de continuidade de negócios e recuperação de desastres de TI. É importante entender e definir esses termos no início do programa e reavaliar rotineiramente seus RTOs e RPOs à medida que sua organização evolui.

 

Precisas de ajuda para compreender melhor os RTOs e RPOs e o papel que desempenham na resiliência da tua organização? Contacta um consultor Castellan hoje e teremos todo o gosto em ajudá-lo a esclarecer todas as suas dúvidas.