Estratégias de continuidade de negócios e recuperação de desastres

Nesta postagem, analisamos algumas considerações importantes para o planejamento da continuidade dos negócios (BC) e da recuperação de desastres (DR).

A continuidade dos negócios precisa ser considerada com cuidado ao usar o Couchbase como um serviço comercial principal. O foco de hoje é a camada de aplicativos e os motivos e as implicações dos impactos nos serviços.

Ao usar o Couchbase como um sistema persistente de registro, Alta disponibilidade (HA), DR e BC precisam ser cuidadosamente compreendidos para garantir que atendam aos níveis de serviço acordados (SLAs).

Em um mundo em que as interrupções de serviço e o tempo de inatividade podem afetar gravemente os negócios, as empresas precisam garantir uma proteção robusta para minimizar o impacto sobre os negócios, seja para as partes interessadas e os clientes internos ou externos.

Além disso, os bancos de dados geralmente são essenciais para o funcionamento dos negócios e centrais para a ecosfera de aplicativos de uma empresa. Se o banco de dados estiver inativo, sua falha afetará outros serviços. A importância desse impacto reforça o motivo pelo qual você deve se proteger contra interrupções inesperadas do serviço.

Historicamente, as empresas ficavam satisfeitas com um tempo de atividade de serviço de 99,9. Agora, as organizações estão buscando seis noves ou mais (99,9999 ou 31 segundos por ano). Anteriormente, as empresas podiam tolerar interrupções de várias horas, mas esse não é mais o caso, portanto, é fundamental entender os requisitos comerciais.

Antes de projetar uma estratégia para atender a um requisito comercial, primeiro precisamos entender os SLAs (Service Level Agreements, acordos de nível de serviço) e como eles são medidos.

Um SLA é um compromisso com o cliente de colocar os serviços em funcionamento em um prazo acordado.

Medição de SLAs em relação ao que é importante

Também precisamos entender as métricas pelas quais a disponibilidade e os SLAs são geralmente medidos, e existem basicamente duas:

Objetivo do ponto de recuperação (RPO)

"Quantos dados posso me dar ao luxo de perder?"

• •   Expressa retroativamente no tempo a partir do instante em que ocorre uma falha.
  •   Pode ser especificado em segundos, minutos, horas ou dias.

Objetivo de tempo de recuperação (RTO)

"Por quanto tempo posso permitir que o serviço fique indisponível?"

• •   Quanto tempo levará para os dados ficarem disponíveis novamente?
  •   Função da extensão em que a interrupção interrompe as operações normais e o valor da receita perdida por unidade de tempo como resultado do desastre.
  •   Pode ser especificado em segundos, minutos, horas ou dias.

Então, quando falamos de HA/DR e BC, o que estamos buscando alcançar? A capacidade de restaurar as operações comerciais normais (ou quase normais), de uma perspectiva de aplicativos comerciais críticos, após a ocorrência de um incidente que interrompa as operações comerciais. Essencialmente, atender aos requisitos desejados de RPO/RTO.

Entenda por que um serviço falha

Além disso, a anatomia do motivo pelo qual um serviço falha precisa ser considerada, pois isso afetará a forma como os serviços precisam de proteção.

Cada um dos motivos citados (abaixo) para a falha do aplicativo/serviço tem impactos e conotações diferentes e, com frequência, eles exigem outras soluções, considerações e construções para garantir a proteção completa.

Outra consideração importante a ser analisada é o equívoco de que as interrupções de serviço afetam apenas a perda direta de receita; normalmente, esse não é o caso, pois muitos sistemas não são geradores de receita. Se ampliarmos esse conceito, há muitos outros motivos para implementar soluções de continuidade de negócios:

• • Danos à reputação ou à marca
  • Perda de negócios para empresas ou fornecedores rivais
  • Perda de produtividade - equipes incapazes de cumprir suas funções e serviços internamente
  • Penalidades financeiras dos conselhos reguladores - possibilidade de não ter permissão para operar
  • Morte! Falha nos sistemas hospitalares/médicos, causando cancelamentos de operações/tratamentos
  • Impacto em outros serviços internos

Opções de mitigação

Então, quais são as opções de proteção e mitigação contra uma interrupção do serviço de aplicativos?

• • Clustering - vários nós para evitar um único ponto de falha
  • Replicação - garantir que os aplicativos e dados estejam disponíveis em vários locais e regiões geográficas
  • Backup - para se recuperar de incidentes catastróficos

Cada uma dessas opções pode ajudar a proteger contra a interrupção do serviço e a recuperação dos serviços comerciais normais. E cada uma delas tem implicações diferentes de RPO e RTO que precisam ser consideradas nos SLAs exigidos pela empresa.

Um dos princípios fundamentais do Couchbase, nosso DNA, se preferir, é que fomos projetados para ter alta disponibilidade, oferecer resiliência e garantir que os SLAs sejam cumpridos.

O Couchbase oferece todas essas três soluções (clustering, replicação, backups), que são totalmente arquitetadas e integradas para reduzir as interrupções de serviço e minimizar o tempo de inatividade.

Disponibilidade estratégica 

Lembre-se de que a escolha da estratégia de disponibilidade correta terá um grande impacto sobre a disponibilidade e o cumprimento dos SLAs. É fundamental entender e definir os SLAs necessários. 

É melhor ter a estratégia inicial correta do que revisá-la após uma interrupção de serviço.

Você precisará ser realista em relação aos prazos de recuperação e, ao mesmo tempo, considerar as implicações de custo e quem financiará isso.

A primeira etapa é entender os objetivos comerciais e as necessidades dos aplicativos. A partir daí, investigue o que atenderá a seus SLAs e às metas da empresa.

Na próxima vez, veremos como o Couchbase pode tornar as soluções altamente disponíveis com o clustering.