Continuidade de Negócios (BC – Business Continuity) visa minimizar a disrupção das atividades de negócio quando alguma coisa não prevista acontecer. Em outras palavras, reduzir ao máximo o impacto de um evento imprevisto como a queda de um sistema, de um banco de dados, de um servidor, ou até mesmo de um data-center inteiro.
Já a Recuperação de Desastres (DR – Disaster Recovery) diz respeito a como se responder a um evento que ameaça a continuidade de negócios.
“Tudo falha, todo o tempo”
Werner Vogals
Como diz o CTO da Amazon, Werner Vogals, tudo vai falhar em algum momento e precisamos mais do que nunca estar preparados para isso. A boa notícia com provedores de nuvem como a AWS isso tem se tornado cada vez mais fácil e econômico.
Os sistemas cada vez requerem alta disponibilidade (HA – High Availability), isso é, precisam ser desenhados com redundância para reduzir as hipóteses de ficarem indisponíveis. Isso requer, por exemplo, que cada servidor de aplicação ou banco de dados de suas aplicações sejam executadas em pelo menos dois data-centers diferentes para que se um falhar o outro assuma.
Também é importante que os sistemas sejam pensados e desenhados com Tolerância a Falhas (Fault Tolerance), de forma que tenham a habilidade de absorver problemas sem impactar a disponibilidade. Por exemplo, se um componente estiver fora do ar, ou falhar, os demais podem continuar funcionando, mesmo que parcialmente.
No caso Netflix, por exemplo, que utiliza microsserviços, se o serviço de avaliação de filmes estiver fora do ar, você não vai conseguir fazer avaliações, mas conseguirá utilizar todas as outras funções, como login, navegar pelo catálogo, e ver um filme ou uma série.
Nível de Serviço (SLA)
Outro conceito importante no contexto de Continuidade de Negócios é o SLA (Service Level Agreement) que em português, chamados de Nível de Serviço. Um SLA geralmente diz respeito a um objetivo acordado de desempenho ou disponibilidade de um sistema.
Um SLA de 99%, por exemplo, significa que o sistema deve estar no ar 99% dentro de um determinado período como mensal, por exemplo.
Naturalmente, hoje em dia, os SLAs são mais agressivos em contém múltiplos noves depois da vírgula, o SLA do S3, por exemplo, um serviço de storage (armazenamento de dados) da Amazon é de 99,999999999%.
Métricas de Continuidade de Negócios
Às duas métricas importantes em se tratando de Continuidade de Negócios e Recuperação de Desastres são RTO e RPO.
Objetivo de tempo de recuperação (RTO – Recovery Time Objective) mede o tempo depois de um desastre para que tudo volte ao normal
Objetivo de ponto de recuperação (RPO – Recovery Point Objective) mede a quantidade aceitável de perda de dados em um determinado período tempo.
Se um servidor falhar, por exemplo, você poderá precisar de um certo tempo para recuperar um backup e torná-lo disponível de novo (RTO), e por estar estabelecendo um backup, pode ter perdido alguns dados (RPO) entre o momento em que o backup foi feito e a hora que o servidor caiu.
Tipo Comuns de Desastres
- Falha de Hardware (ex: fonte de energia falhou)
- Falha de Deployment (ex: erro ao aplicar um patch em um sistema)
- Carga Induzida (Ataque DDoS)
- Expiração de Credenciais
- Falha de Dependência (ex: banco de dados falhar, ou sistema externo)
- Infra-estrutura (ex: fibra, cabeamento)
- Falta de Capacidade (ex: servidores insuficientes para escalar horizontalmente)
- Erros Humanos
Estratégias para Continuidade de Negócios
Backup e Restauração
Sem dúvida uma das práticas mais essenciais, comuns e conhecida por todos, basicamente você deve ter cópias de seus dados, e testar com frequência a eficácia do processo de restauração.
O esforço de configuração de backups em provedores de nuvem como a AWS é quase nulo. Porém, apesar de essencial para muitos cenários apenas backups serão insuficientes e será preciso combinar os backups com outras práticas para garantir a segurança do serviço.
Isso porque ter apenas backups pode exigir um tempo de recuperação muito alto, e há grande risco de perda de dados.
Redundancia e Replicação
Para cada servidor que você tiver rodando em um data-center A precisará ter uma réplica num data-center B.
Há formas diferentes de fazer isso, algumas mais baratas em que você deixa os servidores preparados mais desligados e só ativa quando precisar deles (em serviços de nuvem como AWS, você não pagaria pelos servidores que não estiverem sendo executados).
Essa estratégia é chamada de Pilot Light e apesar de mais barata do que outras, requer o chaveamento manual de ambiente e que o ativamente dos servidores que estavam desligados, então pode aumentar o tempo de indisponibilidade.
Já na estragégia Warm Standby, você mantém os dois ambientes sempre funcionando um principal e outro de standby (espera). O ambiente que está em standby fica rodando com menos servidores do que o principal (podendo utilizar um auto-scaling group para aumentar a capacidade dinamicamente quando necessário).
Na estratégia Multi-site (conhecida no mundo AWS como Multi-AZ), você mantém recursos executando em dois data-centers e está sempre pronto para que se um data-center falhar o outro assuma a operação.
Num caso de falha, a troca de AZ acontece idealmente sem perda de dados, e nem indisponibilidade e os endpoints de acesso geralmente são redirecionados automaticamente. Essa é a estratégia um pouco mais cara, porém, bem mais segura.
Alta Disponibilidade na AWS
A Amazon Web Services (AWS) oferece uma série de recursos interessantes para que você possa ser o maior nível de disponibilidade possível em seus serviços.
Boas Práticas para Storage
Os discos (EBS) que podem ser acoplados a servidores virtuais (EC2), por exemplo, tem uma taxa de falha inferior a 0,2% (os discos normais têm 4%), oferecem disponibilidade de 99,999%, e são replicados automaticamente dentro de uma mesma zona de disponibilidade (AZ) da AWS. Além disso, é fácil de se configurar backups automáticos, snapshots, e também pode-ser usar configurações RAID.
Já o S3, que é um dos serviços mais usados para armazenamento de objetos em nuvem (arquivos, fotos, vídeos, documentos, etc.), possui durabilidade até onze noves depois da vírgula (99,99999999999%), e você pode escolher diferentes níveis de disponibilidade de acordo com sua necessidade.
Boas Práticas para Bancos de Dados
Se não for essencial usar um banco relacional, dê preferência ao DynamoDB por ser serverless naturalmente vai garantir maior disponibilidade.
Se precisar de um banco de dados relacional, dê preferência para usar Aurora, ou RDS com MultiAZ em vez de instalar o SGBD manualmente em máquinas EC2, assim você terá redundância e poderá agendar os backups e snapshots de forma automática.
Snapshots e AMIs (imagens para criar servidores) além de estarem em diferentes zonas de disponibilidade podem ser copiadas em regiões distintas.
Boas Práticas para Servidores
Arquiteturas de Escalabilidade Horizontal são mais recomendadas do que as de Escalabilidade Vertical porque o risco de falha é espalhado entre múltiplas máquinas menores em vez de estarem concentrados em uma única máquina.
Reserve sempre suas instâncias essa é única forma de ter total garantia que os recursos estarão disponíveis quando você precisar deles.
Utilize Autoscaling e Load Balancers em conjunto para certificar-se de que um número mínimo de servidores estará operando e em caso de falha será reestabelecido sem intervenção manual.
Use HealthChecks do Route53 (Serviço de DNS da AWS) para redirecionar trafego automaticamente em caso de falhas.
Boas Práticas para Network (Redes)
Crie Subnets em diferentes zonas de disponibilidade.
Use no mínimo 2 túneis de VPN no seu Virtual Private Gateway.
Use no mínimo duas conexões de Direct Connect.
Conclusão
Neste artigo você foi apresentado aos conceitos de Continuidade de Negócios, Recuperação de Desastres, Alta Disponibilidade e Tolerância a Falhas.
Atualmente para a vasta maioria das empresas garantir que os sistemas de informação tenham essas características já é essencial para a boa saúde dos negócios.
A boa notícia é que Cloud Providers como a AWS tornam essa missão cada vez mais fácil, acessível e possível.
Agora é com você.
Mãos à obra!
