REL13-BP01 Definir objetivos de recuperação para tempo de inatividade e perda de dados

A carga de trabalho tem um objetivo de tempo de recuperação (RTO) e um objetivo de ponto de recuperação (RPO).

O objetivo de tempo de recuperação (RTO) é o atraso máximo aceitável entre a interrupção do serviço e a restauração do serviço. Ele determina o que é considerado uma janela de tempo aceitável quando o serviço não está disponível.

O objetivo do ponto de recuperação (RPO) é o tempo máximo aceitável desde o último ponto de recuperação de dados. Isso determina o que é considerado uma perda aceitável de dados entre o último ponto de recuperação e a interrupção do serviço.

RTOe RPO os valores são considerações importantes ao selecionar uma estratégia de recuperação de desastres (DR) apropriada para sua carga de trabalho. Esses objetivos são determinados pela empresa e, em seguida, usados pelas equipes técnicas para selecionar e implementar uma estratégia de DR.

Resultado desejado: 

Cada carga de trabalho tem uma atribuída RTO e RPO definida com base no impacto nos negócios. A carga de trabalho é atribuída a um nível predefinido, definindo a disponibilidade do serviço e a perda aceitável de dados, com um e associadoRTO. RPO Se essa hierarquização não for possível, ela poderá ser atribuída sob medida por workload, com a intenção de criar camadas posteriormente. RTOe RPO são usados como uma das principais considerações para a seleção de uma implementação de estratégia de recuperação de desastres para a carga de trabalho. Outras considerações ao escolher uma estratégia de DR são restrições de custo, dependências de workload e requisitos operacionais.

PoisRTO, entenda o impacto com base na duração de uma interrupção. Ele linear ou há implicações não lineares? (por exemplo, depois de quatro horas, você desliga uma linha de fabricação até o início do próximo turno).

Uma matriz de recuperação de desastres, como a mostrada a seguir, pode ajudar você a entender como a criticidade da workload se relaciona aos objetivos de recuperação. (Observe que os valores reais dos eixos X e Y devem ser personalizados de acordo com as necessidades da sua organização).

Figura 16: Matriz de recuperação de desastres

Práticas comuns que devem ser evitadas:

• Não há objetivos de recuperação definidos.

• Seleção de objetivos de recuperação arbitrários.

• Seleção de objetivos de recuperação que são muito permissivos e não atendem aos objetivos de negócios.

• Não entender o impacto do tempo de inatividade e da perda de dados.

• Selecionar objetivos de recuperação irreais, como tempo zero para recuperação e zero perda de dados, o que pode não ser possível para sua configuração de workload.

• Seleção de objetivos de recuperação mais rigorosos do que os objetivos de negócios reais. Isso força implementações de DR mais caras e complicadas do que as necessidades da workload.

• Selecionar objetivos de recuperação incompatíveis com os de uma workload dependente.

• Seus objetivos de recuperação não consideram os requisitos de conformidade regulatória.

• RTOe RPO definido para uma carga de trabalho, mas nunca testado.

Benefícios de implementar esta prática recomendada: os objetivos de recuperação referentes a tempo e perda de dados são necessários para orientar a implementação de DR.

Nível de risco exposto se esta prática recomendada não for estabelecida: Alto

Orientação para implementação

Para determinada workload, você deve entender o impacto do tempo de inatividade e da perda de dados em sua empresa. O impacto geralmente aumenta com maior tempo de inatividade ou perda de dados, mas a forma desse crescimento pode ser diferente com base no tipo de workload. Por exemplo, você pode tolerar o tempo de inatividade por até uma hora com pouco impacto, mas depois disso o impacto aumenta rapidamente. O impacto nos negócios se manifesta de várias formas, incluindo custo monetário (como perda de receita), confiança do cliente (e impacto na reputação), problemas operacionais (como ausência de folha de pagamento ou diminuição da produtividade) e risco regulatório. Use as etapas a seguir para entender esses impactos RTO e RPO definir sua carga de trabalho.

Etapas de implementação

1. Determine as partes interessadas da sua empresa para essa workload e interaja com elas para implementar essas etapas. Os objetivos de recuperação de uma workload são uma decisão comercial. As equipes técnicas então trabalham com as partes interessadas da empresa para usar esses objetivos para selecionar uma estratégia de DR.

   nota

   Para as etapas 2 e 3, você pode usar o Planilha de implementação.

2. Reúna as informações necessárias para tomar uma decisão respondendo às perguntas abaixo.

3. Você tem categorias ou níveis de criticidade para o impacto da workload em sua organização?

   1. Se sim, atribua essa workload a uma categoria

   2. Se não, estabeleça essas categorias. Crie cinco ou menos categorias e refine o alcance do seu objetivo de tempo de recuperação para cada uma. As categorias de exemplo incluem: crítica, alta, média e baixa. Para entender como as workloads são mapeadas em categorias, considere se a workload é essencial, importante para os negócios ou não.

   3. Defina a carga de trabalho RTO e RPO com base na categoria. Sempre escolha uma categoria mais restrita (menor RTO eRPO) do que os valores brutos calculados ao entrar nessa etapa. Se isso resultar em uma mudança de valor inadequadamente grande, considere criar uma nova categoria.

4. Com base nessas respostas, RTO atribua RPO valores à carga de trabalho. Isso pode ser feito diretamente ou atribuindo-se a workload a um nível predefinido de serviço.

5. Documente o plano de recuperação de desastres (DRP) para essa carga de trabalho, que faz parte do plano de continuidade de negócios da sua organização (BCP), em um local acessível à equipe de carga de trabalho e às partes interessadas

   1. RTORegistre o eRPO, e as informações usadas para determinar esses valores. Inclua a estratégia usada para avaliar o impacto da workload nos negócios

   2. Além disso, registre outras métricas RTO e você RPO está monitorando ou planeja monitorar os objetivos de recuperação de desastres?

   3. Você adicionará detalhes da sua estratégia de DR e do seu runbook a esse plano ao criá-los.

6. Ao examinar a criticidade da workload em uma matriz como a da Figura 15, você pode começar a estabelecer níveis predefinidos de serviço definidos para sua organização.

7. Depois de implementar uma estratégia de DR (ou uma prova de conceito para uma estratégia de DR)REL13-BP02 Use estratégias de recuperação definidas para atender aos objetivos de recuperação, teste essa estratégia para determinar a carga de trabalho real RTC (capacidade de tempo de recuperação) e RPC (capacidade de ponto de recuperação). Se eles não atenderem aos objetivos de recuperação desejados, trabalhe com as partes interessadas da empresa para ajustar esses objetivos ou faça alterações na estratégia de DR para atingir os objetivos desejados.

Perguntas primárias

1. Qual é o tempo máximo em que a workload pode permanecer inativa antes que um impacto severo nos negócios ocorra?

   1. Determine o custo monetário (impacto financeiro direto) para a empresa por minuto se a workload for interrompida.

   2. Considere que o impacto nem sempre é linear. O impacto pode ser limitado no início e depois aumentar rapidamente após um momento crítico.

2. Qual é a quantidade máxima de dados que podem ser perdidos antes que um impacto severo nos negócios ocorra?

   1. Considere esse valor para seu datastore mais importante. Identifique a respectiva criticidade para outros datastores.

   2. Os dados da workload podem ser recriados em caso de perda? Se isso for operacionalmente mais fácil do que fazer backup e restauração, escolha RPO com base na criticidade dos dados de origem usados para recriar os dados da carga de trabalho.

3. Quais são os objetivos de recuperação e as expectativas de disponibilidade das workloads das quais esta depende (downstream) ou das workloads que dependem dela (upstream)?

   1. Escolha objetivos de recuperação que permitam que essa workload atenda aos requisitos das dependências upstream

   2. Escolha objetivos de recuperação que sejam alcançáveis considerando os recursos de recuperação das dependências posteriores. Dependências downstream não críticas (aquelas que é possível "contornar") podem ser excluídas. Ou trabalhe com dependências downstream críticas para melhorar suas capacidades de recuperação quando necessário.

Alguma outra dúvida?

Considere essas questões e como elas podem se aplicar a essa workload:

4. Você tem uma interrupção diferente RTO e RPO depende do tipo de interrupção (região versus AZ, etc.)?

5. Existe um horário específico (sazonalidade, eventos de vendas, lançamentos de produtos) em que seu RTO RPO /pode mudar? Em caso afirmativo, quais são os diferentes limites de tempo e medições?

6. Quantos clientes serão afetados se a workload for interrompida?

7. Qual será o impacto na reputação se a workload for interrompida?

8. Que outros impactos operacionais poderão ocorrer se a workload for interrompida? Por exemplo, impacto na produtividade dos funcionários se os sistemas de e-mail não estiverem disponíveis ou se os sistemas de folha de pagamento não conseguirem enviar transações.

9. Como a carga de trabalho RTO se RPO alinha com a linha de negócios e a estratégia organizacional de DR?

10. Há alguma obrigação contratual interna para a prestação de um serviço? Há alguma penalidade por não cumpri-las?

11. Quais são as restrições regulatórias ou de conformidade com os dados?

Planilha de implementação

A planilha pode ser usada para as etapas de implementação 2 e 3. É possível ajustá-la para atender às suas necessidades específicas, como adicionar perguntas adicionais.

Planilha

Nível de esforço do plano de implementação: Baixo.

Recursos

Práticas recomendadas relacionadas:

• REL09-BP04 Execute a recuperação periódica dos dados para verificar a integridade e os processos de backup

• REL13-BP02 Use estratégias de recuperação definidas para atender aos objetivos de recuperação

• REL13-BP03 Teste a implementação da recuperação de desastres para validar a implementação

Documentos relacionados:

• Blog de arquitetura da AWS : série de recuperação de desastres

• Recuperação de cargas de trabalho em desastres em AWS: Recuperação na nuvem (AWS whitepaper)

• Gerenciando políticas de resiliência com o AWS Resilience Hub

• APNParceiro: parceiros que podem ajudar na recuperação de desastres

• AWS Marketplace: produtos que podem ser usados para recuperação de desastres

Vídeos relacionados:

• AWS re:Invent 2018: Padrões de arquitetura para aplicativos ativo-ativos em várias regiões (09-R2) ARC2

• Recuperação de desastres de cargas de trabalho em AWS