Quando falamos sobre nuvem, é comum a conversa começar por custo, performance ou modernização. Mas existe uma pergunta que deveria aparecer muito antes:
O que acontece com a sua empresa se o ambiente principal ficar indisponível hoje?
Quanto tempo a operação consegue ficar parada? E quanto de informação a empresa pode perder sem causar um impacto significativo no negócio?
Essas perguntas estão diretamente relacionadas à contingência e à continuidade do negócio.
Backup não é a mesma coisa que contingência
Esse é um ponto que ainda gera bastante confusão.
Ter backup é fundamental, mas ele atende principalmente à necessidade de recuperar dados.
Uma estratégia de contingência vai além. Ela considera antecipadamente como a empresa poderá recuperar seus sistemas e retomar a operação diante de uma falha ou indisponibilidade.
Imagine uma empresa que mantém seus principais sistemas em servidores locais e realiza backups diariamente.
Os dados estão protegidos. Mas, se o servidor principal apresentar uma falha grave, algumas perguntas surgem:
Existe outro ambiente preparado para assumir a operação? Quanto tempo será necessário para restaurar os sistemas? Quais aplicações precisam voltar primeiro? Quanto de informação pode ser perdido entre o último ponto de recuperação e o incidente?
É nesse momento que percebemos que ter os dados protegidos e conseguir retomar a operação são coisas diferentes.
Onde a AWS entra nessa estratégia?
A AWS permite construir diferentes estratégias de Disaster Recovery (DR) de acordo com a criticidade das aplicações, os requisitos do negócio e o investimento adequado para cada cenário.
Não existe uma única estratégia que faça sentido para todas as empresas.
Algumas operações conseguem trabalhar com algumas horas de indisponibilidade. Em outras, poucos minutos podem representar impactos relevantes na operação, no atendimento aos clientes e nos resultados financeiros.
Por isso, dois conceitos são fundamentais para definir uma estratégia de recuperação:
RTO (Recovery Time Objective): representa o tempo máximo aceitável entre uma interrupção e a restauração do serviço.
RPO (Recovery Point Objective): representa o período máximo aceitável de perda de dados, medido em tempo a partir do último ponto de recuperação disponível.
RTO e RPO ajudam a definir os requisitos de recuperação e, consequentemente, qual estratégia é mais adequada para cada aplicação.
Estratégias de Disaster Recovery na AWS
A AWS apresenta quatro estratégias principais de Disaster Recovery, que variam de acordo com requisitos de recuperação, custo e complexidade.
Backup & Restore
Nessa estratégia, dados e recursos necessários são protegidos para permitir que o ambiente seja restaurado após um incidente.
É uma abordagem que pode exigir menos recursos permanentemente ativos para recuperação, mas normalmente apresenta um tempo de recuperação maior quando comparada às estratégias que mantêm parte ou todo o ambiente previamente disponível.
Pilot Light
No modelo Pilot Light, os componentes essenciais da workload, especialmente aqueles relacionados aos dados, permanecem disponíveis na região de recuperação.
Outros recursos necessários para executar a aplicação podem ser provisionados durante o processo de recuperação, permitindo reconstruir e escalar o ambiente quando necessário.
Warm Standby
No Warm Standby, uma versão reduzida, mas funcional, da workload permanece ativa na região de recuperação.
Em uma situação de desastre, essa infraestrutura pode ser escalada para atender à capacidade necessária da operação.
Multi-Site Active/Active
No modelo Multi-Site Active/Active, a workload opera simultaneamente em múltiplas regiões, atendendo tráfego a partir de mais de um ambiente.
Essa estratégia pode atender requisitos de recuperação mais rigorosos e proporcionar RTO e RPO muito baixos, mas também exige uma arquitetura mais robusta e maior complexidade operacional.
De maneira geral, quanto menor a tolerância à indisponibilidade e à perda de dados, mais exigente tende a ser a estratégia necessária em termos de arquitetura, operação e investimento.
Contingência também é uma decisão de negócio
Disaster Recovery não deveria ser uma discussão restrita à área de TI.
Quando um sistema crítico fica indisponível, os impactos podem alcançar atendimento, vendas, operação, logística, financeiro e, consequentemente, os clientes.
Por isso, antes de perguntar:
“Quanto custa ter um ambiente de contingência?”
Existe outra pergunta igualmente importante:
“Quanto pode custar para a empresa não ter um quando realmente precisar?”
Pensar em contingência não significa partir diretamente para a arquitetura mais complexa ou mais cara.
Significa identificar quais sistemas são realmente críticos, quanto tempo podem permanecer indisponíveis, quanto de informação pode ser perdido e qual nível de investimento é adequado à realidade do negócio.
A tecnologia entra a partir dessas respostas.
Como a KXC pode apoiar essa jornada
Uma estratégia de contingência eficiente começa pela compreensão do ambiente atual e das necessidades reais da operação.
Como parceira AWS, a KXC apoia empresas na avaliação de seus ambientes e na construção de estratégias de Backup e Disaster Recovery, considerando requisitos técnicos, criticidade das aplicações, RTO, RPO e necessidades do negócio.
O objetivo não é simplesmente criar uma segunda infraestrutura, mas desenvolver uma estratégia de recuperação coerente com o impacto que uma indisponibilidade pode representar para cada empresa.
E fica uma reflexão:
Sua empresa sabe hoje qual é o RTO e o RPO das aplicações mais críticas?
