Definindo RTO, RPO e níveis de recuperação

O planejamento de continuidade dos negócios (BCP) é o processo de garantir que funções empresariais críticas possam continuar durante e após um desastre. Na computação em nuvem, isso significa projetar sistemas capazes de se recuperar de falhas dentro de limites aceitáveis de tempo e perda de dados. Duas métricas fundamentais — RTO e RPO — definem o que é “aceitável” para cada carga de trabalho.

O Recovery Time Objective (RTO) é o período máximo aceitável durante o qual um sistema pode permanecer offline após um desastre. Ele responde à pergunta: “Por quanto tempo a empresa pode tolerar que esta aplicação fique indisponível?”. O RTO é expresso em tempo — horas, minutos ou segundos. Um sistema de processamento de pagamentos pode ter um RTO de 15 minutos, enquanto um portal interno de RH pode ter um RTO de 24 horas.

O Recovery Point Objective (RPO) é a quantidade máxima aceitável de perda de dados, medida em tempo. Ele responde à pergunta: “Quanta perda de dados a empresa consegue suportar?”. Se o RPO for de 1 hora, a empresa aceita perder até 1 hora de transações. O RPO determina com que frequência você deve fazer backup ou replicar os dados. Um RPO de 0 exige replicação síncrona, que é cara e pode afetar o desempenho de gravação.

É importante não confundir RTO e RPO:

• RTO diz respeito ao tempo — por quanto tempo o sistema fica indisponível
• RPO diz respeito aos dados — quantos dados são perdidos

Um sistema pode ter um RTO curto (recuperação rápida), mas um RPO longo (aceitando uma perda significativa de dados), ou o contrário. O ideal é que ambos sejam curtos, mas alcançar isso exige um investimento significativo em replicação e capacidade de espera ativa.

Nem todas as cargas de trabalho têm a mesma criticidade. Uma abordagem comum é classificar as cargas de trabalho em níveis de Recovery, com base no impacto para os negócios:

• Nível 1 (crítico para a missão) — RTO/RPO rigorosos, custo mais alto (por exemplo, pagamentos e plataformas de negociação)
• Nível 2 (crítico para os negócios) — RTO/RPO moderados (por exemplo, CRM e ERP)
• Nível 3 (não crítico) — RTO/RPO flexíveis, custo mais baixo (por exemplo, ambientes de desenvolvimento e arquivos)

Diferentes níveis de Recovery correspondem a diferentes recursos do Azure:

• Nível 1 — gravações em várias regiões do Cosmos DB, grupos de failover automático do SQL, arquitetura ativa-ativa e Traffic Manager
• Nível 2 — Azure Site Recovery para uma região secundária, replicação geográfica do SQL (réplica de leitura) e backups diários com retenção de 30 dias
• Nível 3 — Azure Backup com agendamentos semanais, sem replicação, restauração a partir de um instantâneo

Para justificar o investimento em uma arquitetura com RTO baixo, calcule o custo do tempo de indisponibilidade da carga de trabalho. Isso inclui perda de Revenue, penalidades de SLA para clientes, perda de produtividade da equipe e danos à reputação. Se o custo de 1 hora de indisponibilidade for de US$ 500.000, gastar US$ 50.000 por mês em uma configuração ativa-ativa será facilmente justificável. Use esses números para elaborar uma justificativa comercial para o nível de Recovery adequado.

O Azure Site Recovery (ASR) é o principal serviço para alcançar as metas de RTO/RPO do nível 2 no Azure. O ASR replica continuamente as VMs para uma região secundária e pode iniciar um failover em poucos minutos. A frequência de replicação das VMs do Azure é de 30 segundos (consistente com falhas) ou de 1 a 4 horas (consistente com a aplicação), resultando normalmente em um RPO dentro desse intervalo, dependendo da configuração.

Para cargas de trabalho cujo RPO é medido em horas, o Azure Backup com um agendamento adequado é suficiente. Por exemplo, um RPO de 4 horas exige um intervalo de backup de, no máximo, 4 horas. O Azure Backup é compatível com políticas aprimoradas que permitem agendamentos de backup a cada hora para VMs do Azure. Para bancos de dados, a restauração em um ponto no tempo (PITR), com backups do log de transações, pode alcançar um RPO inferior a 1 hora a um custo menor que o ASR.

As metas de RTO e RPO devem ser documentadas formalmente em uma Análise de Impacto nos Negócios (BIA) e revisadas pelas partes interessadas técnicas e empresariais. A BIA associa cada aplicação ao seu nível de Recovery, documenta as metas de RTO/RPO, identifica os serviços do Azure que fornecerão essas metas e especifica o cronograma de testes (com que frequência o plano de DR é validado por meio de simulações).

As metas de RTO e RPO são apenas aspiracionais até serem validadas por meio de testes de DR. Durante um teste de DR, meça o tempo real de recuperação (ele atende ao RTO declarado?) e a perda real de dados no ponto de recuperação (ela atende ao RPO declarado?). Se o teste revelar lacunas, atualize a arquitetura ou os procedimentos até que as metas sejam alcançadas de forma consistente. Documente os resultados dos testes para auditorias de conformidade.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) abordados nesta lição.

Nesta lição, você aprendeu que: RTO é o tempo máximo aceitável de indisponibilidade, enquanto RPO é a perda máxima aceitável de dados medida em tempo; as cargas de trabalho são classificadas em níveis de Recovery associados a serviços específicos do Azure; e os testes são essenciais para validar se as metas de RTO/RPO podem ser alcançadas. A seguir, exploraremos planos de Recovery e failover automatizado com o Azure Site Recovery.