Um plano de recuperação de desastres bem projetado é fundamental para mitigar riscos, recuperar rapidamente de falhas e garantir a integridade dos seus dados e infraestrutura.
Há Mitos Relacionados ao DR em DevOps?
Algumas organizações ainda assumem erroneamente que ferramentas DevOps, como GitHub, GitLab, Bitbucket, Azure DevOps ou Jira, vêm com recuperação de desastres integrada e abrangente. No entanto, não devemos esquecer os modelos de responsabilidade compartilhada, que esclarecem explicitamente que, enquanto os provedores garantem a segurança de sua infraestrutura e a execução suave de seus serviços, os usuários devem proteger seus próprios dados de conta.
Por exemplo, vamos dar uma olhada na citação das Práticas de Segurança do Atlassian:
“Para o Bitbucket, os dados são replicados para uma região AWS diferente, e backups independentes são feitos diariamente em cada região. Não utilizamos esses backups para reverter alterações destrutivas iniciadas pelo cliente, como campos sobrescritos usando scripts, ou problemas, projetos ou sites excluídos. Para evitar perda de dados, recomendamos fazer backups regulares.”
Você pode encontrar os mesmos conselhos no modelo de responsabilidade compartilhada de qualquer provedor de SaaS. E equívocos nessa área podem levar a interrupções graves, incluindo perda de dados de código-fonte crítico ou metadados, danos à reputação e prejuízos financeiros.
Desafios Únicos para o Ecossistema DevOps
Ao desenvolver seu plano de recuperação de desastres para sua pilha DevOps, vale a pena considerar os desafios que o DevOps enfrenta nesse aspecto.
Ecossistemas DevOps sempre possuem arquitetura complexa, como pipelines e ambientes interconectados (por exemplo, integração entre GitHub e Jira). Assim, uma única falha, seja por um artefato corrompido ou um ataque de ransomware, pode se propagar por todo o sistema.
Além disso, o rápido desenvolvimento do DevOps gera mudanças constantes, o que pode complicar as verificações de consistência e integridade dos dados durante o processo de recuperação.
Outra questão são políticas de retenção de dados. Ferramentas SaaS frequentemente impõem períodos de retenção limitados – geralmente variando de 30 a 365 dias. Assim, por exemplo, se você deletar acidentalmente seu repositório sem ter uma cópia de backup, pode perdê-lo para sempre.
Por que a Recuperação de Desastres é um Imperativo para o DevOps
A criticidade dos dados é importante, mas não é a única razão para as organizações desenvolverem e melhorarem seus mecanismos de Recuperação de Desastres. Um plano eficaz de recuperação de desastres pode ajudar as organizações:
- Mitigar os riscos, já que interrupções de serviço, ciberataques e deleções acidentais podem resultar em tempo de inatividade prolongado e perda de dados.
— por exemplo, a ISO 20071, GDPR, ou NIS 2 exigem que as organizações tenham mecanismos robustos de proteção e recuperação de dados. Não cumprir pode resultar em multas pesadas e consequências legais.
<Nota: Em dezembro de 2024, o Ato de Resiliência Cibernética da UE entrou em vigor. Significa que até dezembro de 2027, as organizações que fornecem produtos e serviços digitais e operam na União Europeia devem adaptar suas proteções de dados e gerenciamento de incidentes dentro dos requisitos da legislação.
- Reduza ou elimine
, pois cada minuto deindisponibilidade do sistema equivale a perda de receita. O custo médio da inatividade pode exceder $ 9.000 por minuto, tornando a recuperação rápida essencial.
Práticas recomendadas para construir um Plano de Recuperação de Desastres Robusto
Não é crucial que seu
Avaliar Todos os Componentes Críticos
Você deve identificar os ativos DevOps mais críticos. Eles podem incluir repositórios de código-fonte, metadados, pipelines CI/CD, artefatos de compilação, arquivos de gerenciamento de configuração, etc. Você precisa saber quais dados têm prioridade para recuperação em caso de falha.
Implemente as Melhores Práticas de Backup
É impossível recuperar dados sem uma estratégia de backup bem organizada. Portanto, é importante seguir as melhores práticas de backup para garantir que você possa restaurar seus dados críticos em qualquer evento de falha, incluindo interrupção de serviço, tempo de inatividade de infraestrutura, ataque de ransomware, exclusão acidental, etc.
Por esse motivo, sua solução de backup deve permitir que você:
- Automatize seus backups, agendando-os com o intervalo mais apropriado entre as cópias de backup, para que nenhum dado seja perdido em caso de falha,
- Forneça retenção de longo prazo ou até mesmo ilimitada, o que ajudará você a restaurar dados de qualquer momento,
- Aplicar a regra de backup 3-2-1 e garantir a replicação entre todos os armazenamentos, para que, caso uma das localizações de backup falhe, você possa executar seu backup a partir de outra,
- Proteção contra ransomware, que inclui criptografia AES com sua própria chave de criptografia, backups imutáveis, restauração e capacidades de DR (restauração em um ponto no tempo, recuperação total e granular, restauração para vários destinos, como uma máquina local, a mesma ou nova conta, ou entre qualquer um dos GitHub, GitLab, Bitbucket e Azure DevOps).
Defina suas Métricas de Recuperação
É crítico para uma organização definir seus objetivos mensuráveis, como RTO ou RPO.
- O Objetivo de Tempo de Recuperação (RTO) refere-se a quão rapidamente os sistemas da sua empresa devem estar operando após a ocorrência de um desastre. Por exemplo, se a sua organização estabelece seu RTO como 8 horas, então, dentro dessas 8 horas, ela deve retomar seu fluxo de trabalho normal após um evento de desastre. Geralmente, quanto menor o RTO que a organização define, melhor preparada ela está para falhas.
- O Objetivo de Ponto de Recuperação (RPO) mostra a perda de dados aceitável medida no tempo que a empresa pode suportar. Por exemplo, se a empresa pode sobreviver facilmente sem dados de 3 horas, então seu RPO é de 3 horas. Quanto menor o RPO que você tiver, mais frequentes backups sua organização deve ter.
Teste e Valide Regularmente Suas Operações de Backup e Restauração
Com testes de restauração regulares, você pode garantir a integridade do seu backup e ter a tranquilidade de que, em caso de falha, poderá recuperar seus dados rapidamente.
Além disso, vale a pena simular falhas. Isso ajudará sua organização a avaliar a eficácia do seu DRP diante de interrupções simuladas, ataques de ransomware ou outros desastres.
Eduque Sua Equipe
A panicação é a pior reação em caso de um desastre. Assim, cada membro da sua equipe deve entender o que deve fazer em tal situação. Estabeleça responsabilidades e papéis sobre quem deve realizar as operações de restauração e quem deve comunicar sobre o desastre.
Sua organização deve ter um plano de comunicação para desastres bem elaborado que declare a estratégia de comunicação e as pessoas responsáveis por informar as partes interessadas e outros possíveis afetados, além de modelos para essa comunicação.
Estudos de Caso de DRP em DevOps
Vamos analisar estudos de caso de como um DRP pode ajudar a evitar as consequências devastadoras de desastres:
Interrupções de Serviço
Uma grande corporação digital depende totalmente do GitHub (pode ser qualquer outro provedor de serviço, como GitLab, Atlassian, ou Azure DevOps). De repente, a empresa percebe que o provedor de serviço está passando por uma interrupção… no entanto, a empresa precisa continuar suas operações o mais rápido possível — não esqueçamos que o custo médio de tempo de inatividade é de $9K por minuto.
Com um DRP abrangente, a organização restaura seus dados a partir da cópia de backup mais recente, usando a restauração no ponto no tempo, para o GitLab (ou Bitbucket ou Azure DevOps). Assim, a organização retoma suas operações rapidamente, elimina a perda de dados e garante um tempo de inatividade mínimo.
Dica: Em uma situação como essa, sua solução de backup também deve permitir que você restaure seus dados para sua máquina local para retomar a continuidade dos negócios o mais rápido possível.
Erro Humano vs. Tempo de Inatividade da Infraestrutura
Um desenvolvedor envia dados incorretos e sobrescreve acidentalmente arquivos críticos. A situação inteira paralisa o fluxo de trabalho da empresa e leva a um tempo de inatividade.
Felizmente, o DRP da organização prevê uma situação como essa, seguindo a regra de backup 3-2-1. Assim, a equipe de TI da empresa executa o backup a partir de outro armazenamento para garantir a continuidade dos negócios.
Ataque de Ransomware
Uma empresa de software de médio porte enfrenta um ataque de ransomware que criptografa seus repositórios Git principais. Ao implementar um DRP eficiente com backups automatizados e recursos à prova de ransomware, como backups imutáveis, a empresa consegue restaurar seus dados a partir do ponto no tempo em que seus dados não estavam corrompidos.
O resultado? A empresa recupera suas operações em questão de horas, evitando uma demanda de resgate de vários milhões de dólares e minimizando o tempo de inatividade.
Lições
Um plano de recuperação de desastres é uma necessidade estratégica para as organizações hoje em dia. Além de proteger os dados, ele ajuda as organizações a garantir conformidade, construir confiança do cliente e reduzir os riscos financeiros.
A estratégia de backup deve se tornar a base abrangente de qualquer DRP, mesmo a mais exigente. Portanto, você deve ser capaz de:
- Configurar políticas de backup para automatizar os processos de backup dentro dos RTOs e RPOs mais exigentes,
- Manter os dados em múltiplos locais, seguindo a regra de backup 3-2-1,
- Ter mecanismos seguros de proteção contra ransomware,
- Monitorar o desempenho do backup através de painéis baseados em dados, notificações por Slack/e-mail, SLA, relatórios de conformidade, etc.,
- Realizar testes de restauração,
- Restaurar dados em qualquer caso de falha, pois a solução prevê qualquer cenário de DR e fornece capacidades robustas de restauração, incluindo recuperação de dados completa, restauração granular, recuperação até um ponto no tempo, restauração para a mesma ou uma nova conta, restauração para sua instância local e
- Garantir conformidade e resiliência cibernética.
Source:
https://dzone.com/articles/disaster-recovery-plan-for-devops