Sua empresa tornou-se tão dependente dos sistemas de informação que passa a cobrar por ações quando a aplicação fica fora do ar. Cálculos com prejuízos, tanto de imagem quanto financeiros são apresentados e você precisa planejar suas ações em contingência. Segundo a Agência Federal Americana de Gestão de Emergências (FEMA), o potencial de receita, reputação e perda de clientes por indisponibilidade dos sistemas e perdas de dados pode ser grave e até mesmo permanente. Conforme relata:
50% das empresas que perderam seus dados por 10 dias ou mais pediram falência imediatamente;
93% das empresas que perderam seus dados por 10 dias ou mais pediram falência dentro de um ano do desastre;
20% das pequenas e médias empresas sofrerão uma grande perda de dados críticos, causando um grande desastre, a cada cinco anos, no mínimo;
Cerca de 70% das empresas experimentaram perda de dados devido a exclusão acidental, disco ou falha do sistema; vírus; fogo; ou algum outro desastre;
40% das pequenas e médias empresas que gerenciam sua própria rede e usam a Internet terão sua rede acessada por hackers, e mais de 50 por cento nem saberão que foram atacados.
Em paralelo, um artigo de 2017 publicado no The Disaster Recovery Journal, elencou, através de seu time editorial, os principais causadores de indisponibilidade dos sistemas e perdas de dados. São eles:
Responsáveis pela Perda de Dados
Independentemente de quem possa causar tamanho problema, quando chega ao banco de dados você precisa atender a, pelo menos, esses dois princípios básicos:
As principais tecnologias de banco de dados possuem, incluídas em seu software, algum tipo de configuração para aumento da disponbilidade do produto, entre eles: o Oracle, com RAC e o Data Guard, o SQL, com o AlwaysOn e o Log Shipping, o MySQL, o MySQL Cluster e Mirror, no PostGreSQL o Logshipping e replicação multimaster, o sharding no Mongodb, backup de todas elas, entre tantas outras. Também existem tecnologias no sistema operacional e ferramentas de terceiros que integram diversos equipamentos em um cluster ativo/passivo ou balanceando a carga de dados, funcionando como se fossem um único componente.
Essas diversas tecnologias, porém, precisam ser ajustadas à questões mais complexas que sua mera configuração, tais como:
Quanto tempo posso ficar com os sistemas fora do ar?
Quais são as janelas possíveis de manutenção com sistemas fora do ar?
Quanto custa ficar fora do ar?
Quanto pode ser perdido de informação em caso de falhas inesperadas?
Quanto custa perder os dados?
Quanto está previsto para ser investido em alta disponibilidade?
Outro conceito relacionado é a disponibilidade do dado em si, não somente do banco de dados, ou seja, o grau em que os sistemas de bancos de dados registram e relatam fielmente suas transações, por exemplo, você tenta pagar um conta pelo seu aplicativo bancário e naquele momento o sistema está fora do ar. Não é o ideal, mas você aceita e não reclama, sabendo que poderá pagar até o final do dia. Mas jamais você aceitará uma conta que não foi paga e mesmo assim descontada do seu saldo bancário. Comento isso pois tal preocupação acarreta na escolha da tecnologia do seu banco de dados.
Algumas das tecnologias de banco de dados disponíveis, por definição, não foram feitas para tanta fidelidade e não devem ser utilizadas caso sua aplicação necessite de tal disponibilidade.
Finalmente, para um bom plano de alta disponibilidade, é necessário pensar em estruturas locais e remotas de atividade, continuidade de negócio, tempo médio de recuperação, em caso de desastre, e tempo médio de vida útil dos componentes, caso seu banco de dados esteja, de alguma forma, instalado em uma estrutura física de sua responsabilidade.