Como definir RTO e RPO para uma aplicação empresarial: guia prático de planeamento

RTO e RPO respondem a diferentes questões de recuperação

O objetivo de tempo de recuperação (RTO) indica durante quanto tempo um sistema ou processo empresarial pode estar indisponível antes de o impacto se tornar inaceitável. O objetivo de ponto de recuperação (RPO) indica a quantidade de dados recentes que a empresa pode aceitar perder, expressa como um período de tempo.

Imagine que uma aplicação falha depois de a última cópia de segurança recuperável ter sido criada na noite anterior. O RPO descreve a quantidade de trabalho registado desde esse ponto de recuperação que poderá perder-se. O RTO descreve durante quanto tempo a empresa consegue tolerar a indisponibilidade da aplicação enquanto esta é restaurada e volta a estar utilizável.

Estes objetivos estão relacionados, mas um não determina o outro. Uma empresa pode precisar de recuperar rapidamente uma aplicação, embora consiga recriar alguns dados recentes; ou pode tolerar uma indisponibilidade mais prolongada, mas ter pouca tolerância à perda de transações.

Comece pelo fluxo de trabalho da empresa, não pelo servidor

Antes de discutir metas de recuperação, identifique o trabalho que a aplicação apoia. Um CRM pode apoiar as vendas e o serviço de apoio ao cliente; uma loja online pode permitir consultar produtos, fazer encomendas e processar pagamentos. A questão essencial é o que as pessoas deixam de conseguir fazer quando a aplicação está indisponível ou os seus dados estão desatualizados.

Para cada fluxo de trabalho, identifique quem é afetado, se o trabalho para por completo e que alternativas existem. Por exemplo, os colaboradores podem conseguir registar temporariamente os pedidos noutro sistema aprovado, mas essa solução pode ser lenta, limitada ou inadequada para determinados dados.

Um bom ponto de partida é uma avaliação breve do impacto na empresa: identifique os processos críticos, os sistemas de que dependem e as consequências de uma interrupção. Inclua as pessoas que executam o trabalho, não apenas quem é responsável pela aplicação.

• Indique o fluxo de trabalho e as funcionalidades da aplicação de que depende.
• Identifique os colaboradores, clientes ou parceiros afetados por uma interrupção.
• Registe qualquer processo manual ou alternativo, as suas limitações e quem pode autorizar a sua utilização.
• Assinale quais as atividades empresariais que têm de ser retomadas primeiro.

Estime o impacto da indisponibilidade em diferentes períodos

Não escolha um RTO só porque determinado valor parece tranquilizador. Estime o que uma interrupção representa ao longo de vários períodos, como uma interrupção breve, parte de um dia de trabalho e uma perturbação mais prolongada. Os intervalos adequados dependem da forma como a empresa opera.

Considere vendas perdidas, compromissos de serviço não cumpridos, colaboradores impossibilitados de trabalhar, decisões atrasadas e clientes que podem optar por outro fornecedor. Pergunte em que momento o impacto acumulado ultrapassa aquilo que a empresa consegue suportar. Esse ponto ajuda a definir uma meta de RTO; não prova que a recuperação ficará concluída até lá.

Distinga o tempo necessário para restabelecer o acesso técnico do tempo necessário para retomar o processo empresarial. A aplicação pode estar a funcionar, mas os colaboradores ainda poderão ter de verificar registos, confirmar o acesso ou resolver o trabalho acumulado.

• Descreva as consequências de uma indisponibilidade em cada intervalo de tempo escolhido.
• Inclua as perturbações operacionais, além dos efeitos financeiros diretos.
• Identifique o momento em que uma solução alternativa deixa de ser aceitável.
• Defina o que significa o fluxo de trabalho estar «recuperado», não apenas o servidor.

Escolha um RPO analisando quais os dados que podem ser recriados

Para cada fluxo de trabalho, identifique os registos criados ou alterados durante o trabalho normal e pergunte quanta dessa informação poderia ser reconstruída após uma interrupção. Um catálogo de produtos pode ser recuperável a partir de outra fonte, enquanto encomendas, pagamentos ou atualizações de clientes recentes podem ser difíceis ou impossíveis de recriar com exatidão.

O período de perda de dados aceitável pode variar entre diferentes partes da mesma aplicação. Considere o que aconteceria se a empresa tivesse de voltar a introduzir o trabalho recente e se essa reintrodução seria completa, atempada e segura. Inclua o risco de registos duplicados ou inconsistentes caso as pessoas utilizem uma solução alternativa durante uma interrupção.

Registe o RPO como uma tolerância da empresa, não como uma suposição sobre a frequência com que os dados são guardados. Em seguida, confirme se os mecanismos de recuperação correspondem a essa tolerância.

• Enumere os dados importantes por fluxo de trabalho, incluindo transações, ficheiros carregados e alterações a registos existentes.
• Classifique cada elemento como fácil, difícil ou impossível de recriar.
• Avalie quanto do trabalho recente poderia ser repetido sem custos, confusão ou riscos inaceitáveis.
• Registe a antiguidade aceitável dos dados recuperáveis para cada fluxo de trabalho.

Mapeie as dependências necessárias para a recuperação

Uma aplicação é apenas uma parte do serviço. O planeamento da recuperação deve incluir as tecnologias e os serviços de apoio que afetam o processo empresarial, mesmo que, normalmente, não sejam considerados críticos por si só.

Trace o percurso que um utilizador segue para concluir o trabalho. Consoante a aplicação, esse percurso pode envolver uma base de dados, ficheiros carregados, identidade ou autenticação, DNS, encaminhamento, certificados TLS, correio eletrónico ou outros serviços externos. Confirme quais as dependências essenciais, quem as gere e o que tem de acontecer antes de os utilizadores poderem voltar a trabalhar.

Considere também as integrações e os parceiros externos. Uma aplicação restaurada pode não permitir retomar o fluxo de trabalho se um serviço conectado essencial estiver indisponível ou se a respetiva ligação precisar de atenção.

• Enumere a aplicação, a base de dados e os ficheiros necessários para o fluxo de trabalho.
• Inclua as dependências de acesso, nomes de domínio e ligações, quando forem relevantes.
• Registe os serviços externos e parceiros de que a aplicação depende.
• Identifique um responsável ou contacto para cada dependência e indique a ordem de recuperação.

Defina metas distintas quando a criticidade empresarial variar

Um único RTO e RPO para todas as aplicações pode ocultar diferenças importantes. Defina objetivos para cada aplicação ou fluxo de trabalho de acordo com o impacto na empresa, a tolerância à perda de dados e as alternativas disponíveis.

Por exemplo, o fluxo de trabalho que recebe encomendas de clientes pode ter necessidades de recuperação diferentes das de um fluxo de trabalho interno de relatórios que utiliza a mesma aplicação. Documente a razão de cada diferença para que as metas reflitam as prioridades da empresa, em vez de uma classificação informal do software.

Quando vários fluxos de trabalho dependem de uma aplicação, indique qual deles determina a prioridade de recuperação. Confirme que as pessoas responsáveis por esses fluxos de trabalho concordam com os objetivos propostos.

• Agrupe as aplicações ou os fluxos de trabalho pelo impacto na empresa, e não apenas por conveniência técnica.
• Atribua um RTO e um RPO a cada grupo ou caso de utilização relevante.
• Explique a razão empresarial de cada meta.
• Analise eventuais conflitos quando uma aplicação suporta fluxos de trabalho com prioridades diferentes.

Confirme se os objetivos são exequíveis

Uma meta só é útil se a implementação e os mecanismos de recuperação escolhidos a puderem suportar de forma razoável. Compare cada objetivo com as formas efetivamente disponíveis para recuperar a aplicação e os respetivos dados. Considere as dependências, o tempo necessário para tomar decisões, o acesso ao processo de recuperação e o trabalho necessário para verificar o serviço restaurado.

Não presuma que a frequência das cópias de segurança equivale ao RPO, nem que a existência de uma cópia de segurança prova que o RTO pode ser cumprido. A organização tem de compreender o que está incluído na recuperação, como são repostos os dados e serviços necessários e como se confirma a prontidão operacional.

A Airbip gere implementações de aplicações do catálogo como cargas de trabalho Docker nos seus servidores cloud, automatiza o encaminhamento e os certificados TLS através do Traefik e do Let’s Encrypt, e disponibiliza verificações de DNS, gestão do ciclo de vida dos serviços e cópias de segurança diárias, semanais e mensais configuráveis. Estas capacidades não constituem uma promessa de que será alcançado um RTO ou RPO específico. Analise os detalhes do serviço em vigor e as necessidades de recuperação da sua aplicação específica antes de decidir se a solução é adequada.

Se os mecanismos de recuperação não puderem suportar as metas propostas, reveja os objetivos, a solução alternativa da empresa ou a abordagem de implementação. Não apresente uma meta não testada como garantia.

• Confirme quais os dados e as dependências abrangidos pelos mecanismos de recuperação.
• Verifique como se inicia a recuperação e quem tem acesso e autoridade para o fazer.
• Compare os horários das cópias de segurança e os procedimentos de restauro com os objetivos de RPO e RTO.
• Identifique lacunas, pressupostos e decisões que têm de ser validados antes de confiar nas metas.

Transforme as metas num plano de recuperação com responsáveis e testes

Documente mais do que o RTO e o RPO. Um plano prático identifica quem decide que a recuperação deve começar, quem executa cada passo, quem verifica se a aplicação está utilizável e quem comunica com colaboradores, clientes ou parceiros.

Defina pontos de decisão claros: como é reconhecido um incidente, quem está autorizado a declarar uma interrupção, quando deve ser utilizada uma solução alternativa e que verificações são necessárias antes de retomar o trabalho normal. Inclua a ordem de restauro das dependências e o processo para lidar com o trabalho criado durante a interrupção.

Teste o plano e registe o que aconteceu. Um objetivo de recuperação é uma meta a validar, não uma prova de que a recuperação o irá cumprir. Os exercícios podem revelar responsabilidades pouco claras, falta de acesso, dependências não identificadas ou uma diferença entre a meta declarada e o processo de recuperação.

Após um teste ou uma interrupção real, atualize os objetivos e os procedimentos, se necessário. Alterações aos fluxos de trabalho, à importância dos dados, às integrações ou aos mecanismos operacionais podem tornar desatualizado um plano de recuperação anterior.

• Identifique quem toma decisões, os responsáveis pela recuperação e os responsáveis pelas comunicações.
• Redija os passos de recuperação e a ordem das dependências numa linguagem que os responsáveis pela resposta consigam seguir.
• Defina as verificações que confirmam que o serviço e o fluxo de trabalho empresarial estão utilizáveis.
• Teste o plano, registe os resultados e acompanhe as lacunas por resolver.
• Reveja as metas quando os processos empresariais ou as dependências da aplicação mudarem.