Quando um serviço digital é interrompido, nem todos os processos sofrem as mesmas consequências nem podem esperar o mesmo tempo pela recuperação. Também não é igual perder alguns minutos de informação ou um dia de operações. Por isso, definir objetivos de recuperação exige relacionar as necessidades do negócio com as capacidades técnicas, em vez de atribuir um valor uniforme a todas as aplicações.
Duas medidas ajudam a expressar essas necessidades: o RTO, que estabelece durante quanto tempo um processo pode permanecer interrompido antes de o impacto se tornar inaceitável, e o RPO, que define quanta perda de dados, expressa em tempo, é tolerável. São objetivos acordados, não garantias automáticas. Para serem úteis, têm de ser compreensíveis, viáveis e verificáveis.
RTO e RPO respondem a perguntas diferentes
O RTO, ou objetivo de tempo de recuperação, responde à pergunta: durante quanto tempo podemos ficar sem este processo? Mede-se desde a interrupção até o processo voltar a um nível operacional acordado. Não basta um servidor arrancar: o serviço tem de conseguir realizar as funções que justificam a sua recuperação.
O RPO, ou objetivo de ponto de recuperação, responde à pergunta: até que momento têm de estar disponíveis os dados recuperados? Se o RPO acordado for de uma hora, o negócio aceita, no máximo, recuperar dados cujo estado corresponda a uma hora antes do incidente. O RPO não indica quanto tempo demora a reposição; isso corresponde ao RTO.
As duas medidas complementam-se, mas não se substituem. Um sistema pode recuperar rapidamente uma cópia com dados demasiado antigos ou conservar dados recentes e demorar demasiado a retomar a operação. A decisão deve considerar ambos os cenários e definir o que significa «recuperado»: que utilizadores, transações ou funções têm de estar disponíveis.
Definir objetivos por processo, não por aplicação
Uma aplicação pode dar suporte a vários processos com impactos diferentes. Por outro lado, um processo costuma depender de várias aplicações, dados, fornecedores e tarefas operacionais. Por isso, começar pela lista de sistemas e atribuir-lhes uma prioridade técnica pode ocultar aquilo de que o negócio realmente precisa.
Convém começar por identificar processos concretos, como aceitar encomendas, registar pagamentos ou responder a pedidos. Para cada um, o responsável de negócio deve descrever as consequências de uma interrupção e da perda de dados. Depois, a equipa de tecnologia pode identificar as aplicações e dependências necessárias para o sustentar. Se uma plataforma servir processos com objetivos diferentes, é preciso verificar se podem ser recuperados separadamente ou se partilham uma limitação que deve ser explicitada.
Esta perspetiva também ajuda a identificar dependências esquecidas: identidade e acesso, comunicações, integrações, bases de dados, informação de configuração, pessoal com conhecimentos específicos e fornecedores externos. Recuperar a aplicação principal não restabelece o processo se uma dependência crítica continuar indisponível.
Estimar o impacto ao longo do tempo
O impacto nem sempre surge de imediato. Uma interrupção breve pode ter consequências aceitáveis e, depois de ultrapassado certo limite, provocar acumulação de trabalho, incumprimento de compromissos ou perda de capacidade operacional. A análise deve descrever como os danos evoluem com o tempo, em vez de se limitar a classificar um sistema como «crítico».
Para o fazer de forma prática, a equipa pode perguntar:
- O que fica parado: operações, canais ou decisões que dependem do processo.
- Quem é afetado: clientes, colaboradores, parceiros ou outras equipas.
- O que se acumula: encomendas pendentes, casos por tratar ou informação que deixa de ser registada.
- Quando deixa de ser tolerável: o momento em que o impacto ultrapassa o limite aceite pelo negócio.
- Que dados podem perder-se: a sua importância, frequência de atualização e possibilidade de reconstrução.
As estimativas devem incluir condições relevantes, como períodos de maior atividade ou fechos operacionais. Se não houver dados suficientes, é preferível documentar a incerteza e acordar uma hipótese a rever, em vez de apresentar um valor aparentemente exato sem fundamento.
Acordar objetivos que possam ser executados
O responsável de negócio propõe que perda e que atraso são toleráveis; a equipa de tecnologia avalia os meios e procedimentos necessários para cumprir esses limites. A equipa de operações contribui com informação sobre a deteção do incidente, quem decide ativar a recuperação e as tarefas a executar. A decisão final exige diálogo entre estas funções: definir um RTO ambicioso sem recursos nem capacidade comprovada não reduz o risco.
Um acordo útil define, no mínimo, o processo, o RTO, o RPO, o âmbito da recuperação, as dependências, os responsáveis e as evidências que demonstrarão o cumprimento. Especifica também os pressupostos: por exemplo, que funções são recuperadas primeiro ou que procedimentos manuais podem manter temporariamente a atividade. Uma alternativa manual pode reduzir o impacto, mas tem de ter responsáveis, instruções e limites claros; não se deve presumir que está disponível por defeito.
Ao comparar a necessidade com a capacidade atual, podem surgir lacunas. A resposta nem sempre passa por adquirir tecnologia. Pode implicar simplificar dependências, melhorar procedimentos, reforçar a recolha de dados, dar prioridade a uma função essencial ou aceitar formalmente um nível de risco diferente. A escolha depende do impacto e das opções operacionais reais.
Verificar dependências, arquitetura e operação
O objetivo acordado deve ser comparado com todo o percurso de recuperação. Para o RTO, consideram-se a deteção, a tomada de decisões, o acesso a pessoas e sistemas, a reposição, a verificação e o regresso do processo à atividade. Se alguma etapa ficar fora do plano, o tempo previsto pode não ser realista.
Para o RPO, é preciso analisar como os dados recuperáveis são gerados e conservados, com que frequência são atualizados e que informação fica fora desse mecanismo. Uma cópia de segurança é uma componente da estratégia, não uma prova de que é possível recuperar dentro dos objetivos. É necessário confirmar que os dados podem ser utilizados e que o procedimento não depende de pressupostos por validar.
Também é importante identificar dependências partilhadas. Se vários processos precisarem da mesma identidade, rede ou fornecedor, a recuperação em paralelo pode competir por recursos ou exigir uma ordem específica. Registar essas relações permite definir prioridades de reposição e compreender que objetivos podem ser alcançados em diferentes condições.
Testar, rever e corrigir os objetivos
Os testes transformam os objetivos em evidências. Um exercício pode percorrer o procedimento de ponta a ponta, medir o tempo até recuperar as funções acordadas e verificar o estado dos dados repostos. Não basta confirmar que existe uma cópia ou que uma instância inicia: o responsável pelo processo tem de confirmar que o resultado permite retomar a operação.
Os exercícios podem começar pela revisão dos procedimentos e avançar para cenários técnicos mais completos, consoante o risco e a capacidade da equipa. Em cada teste, convém registar:
- Que processo, cenário e dependências foram testados.
- Quando começou a interrupção e quando foram recuperadas as funções acordadas.
- Que ponto dos dados foi recuperado e que perda foi observada.
- Que etapas falharam, que pressupostos não se confirmaram e quem corrigirá cada lacuna.
Se o resultado ultrapassar o RTO ou o RPO, é necessário decidir se se melhora a capacidade, se altera o processo ou se revê o objetivo com o negócio. Repetir um teste sem resolver os problemas identificados não aumenta a confiança. Os objetivos também devem ser revistos quando mudam o processo, a arquitetura, o volume de atividade ou as dependências.
Erros frequentes e modelo de decisão
Entre os erros mais comuns estão atribuir o mesmo objetivo a todo o inventário, confundir RTO com RPO, assumir que uma cópia de segurança equivale a recuperação e definir metas sem a participação do negócio. Também é arriscado medir apenas a disponibilidade técnica, ignorar as tarefas de coordenação ou considerar um teste bem-sucedido sem validar os dados e as funções do processo.
Uma ficha simples ajuda a manter as decisões rastreáveis. Pode incluir os seguintes campos:
- Processo e responsável de negócio: que atividade é protegida e quem aceita o impacto.
- Impacto da duração e da perda de dados: consequências e limites toleráveis.
- RTO e RPO acordados: objetivos e âmbito da recuperação.
- Aplicações e dependências: componentes, equipas e fornecedores necessários.
- Procedimento e alternativa manual: etapas, prioridades, responsáveis e limites.
- Último teste e evidências: resultado observado, lacunas e ações pendentes.
Definir RTO e RPO por processo não consiste em escolher números ideais, mas em acordar limites que reflitam o impacto, verificar se a organização consegue cumpri-los e agir sobre as lacunas. A revisão periódica mantém esses objetivos alinhados com o serviço real e evita confundir uma expectativa documentada com uma capacidade demonstrada.