Plano de recuperação de desastres: melhores práticas ou recursos? [fechadas]

Fui encarregado de liderar um projeto referente à atualização de um plano de recuperação de desastres antigo e um tanto unilateral. Por enquanto, estamos apenas procurando resolver o lado de TI do DR. Na última vez em que fizeram isso, definiram seu escopo, criando um único desastre (o data center inundado) e planejando-o com exclusão de todos os outros tipos de desastre. Eu gostaria de ter uma abordagem mais bem-arredondada. Sei que este é um problema resolvido, outras organizações elaboraram planos de recuperação de desastres.

Nosso plano é levar o nosso plano de DR de TI e prosseguir com ele e dizer "Ei, é isso que queremos em um plano de DR para TI, ele se encaixa no que o resto da Universidade está fazendo? gostaria de mudar? " Temos uma boa idéia do que é o resto do plano e esperamos que isso termine bem.

O que estou procurando é orientação sobre como definir um plano de recuperação de desastres e quais perguntas devo estar pensando. Você tem recursos, livros, treinamentos favoritos relacionados ao desenvolvimento do plano de recuperação de desastres?

Uma excelente fonte de informações é o Disaster Recovery Journal ( sobre ).

Os recursos da comunidade disponíveis incluem o rascunho atual do documento de práticas geralmente aceitas (GAP) , que fornece um excelente esboço do processo e dos resultados que constituem um sólido plano e processo de continuidade de negócios. Também estão disponíveis vários documentos técnicos que cobrem vários tópicos de DR / BC.

O processo parece assustador, mas se abordado sistematicamente com um bom esboço de onde você gostaria de terminar (como o documento DRJ GAP), pode garantir que você otimize o tempo investido e maximize o valor do produto final.

Acho que a publicação trimestral também é interessante e informativa ( assine ).

Verifique se você tem uma lista de contatos de emergência. aka uma lista de recall

Deve parecer uma árvore e mostrar quem entra em contato com quem. No final de uma filial, a última pessoa deve ligar para a primeira e denunciar qualquer pessoa que não possa ser contatada.

(Isso pode ser coordenado pelo RH e usado para qualquer tipo de desastre)

Se adicionarmos nossas idéias, poderemos criar um bom wiki a partir deste post, uma vez que todos tenham adicionado suas próprias idéias. Entendo que há muitos grupos a seguir, mas alguns de nós têm prioridades específicas quando se trata de recuperação. Para começar, aqui está o meu:

Verifique se você possui documentação off-line / remota da sua rede

Com o DR, o básico são seus RTOs (Objetivos do Tempo de Recuperação) e RPOs (Objetivos do Ponto de Recuperação), que traduzem aproximadamente como "quanto tempo é aceitável gastar para recuperá-lo e quantos dados podemos perder". Em um mundo ideal, as respostas seriam "nenhuma e nenhuma", mas um cenário de DR é uma circunstância excepcional. Eles realmente devem ser orientados por seus clientes, mas, como você está começando do ponto de vista da TI, é possível adivinhar, mas esteja preparado para ajustar para cima ou para baixo, conforme necessário. Buscar o mais próximo possível de "nenhum e nenhum" é bom, mas você precisará reconhecer quando chegar o ponto de diminuir os retornos.

Esses dois fatores podem ser diferentes em diferentes épocas do ano e diferentes em diferentes sistemas.

Eu gosto da abordagem mais abrangente; é tentador listar os eventos que podem levar a um cenário de recuperação de desastres, mas esses realmente pertencem mais a um exercício de análise / mitigação de riscos. Com a DR, o incidente já aconteceu e as especificidades do que foi são menos relevantes (exceto talvez em termos de afetar a disponibilidade das instalações de DR). Se você perder um servidor, precisará recuperá-lo, independentemente de ter sido atingido por um raio, formatado acidentalmente ou qualquer outra coisa. É mais provável que uma abordagem focada em escala e expansão do desastre produza resultados.

Uma abordagem a ser usada nos clientes, se você achar que eles estão relutantes em se envolver, é fazer perguntas de DR a partir de um ângulo que não seja de TI. Perguntar quais são seus planos se todos os arquivos em papel pegarem fogo é um exemplo aqui. Isso pode ajudar a envolvê-los no assunto mais amplo de DR e pode alimentar informações úteis em seus próprios planos.

Finalmente, testar seu plano regularmente é crucial para o sucesso. Não é bom ter um belo plano de recuperação de desastres que pareça ótimo no papel, mas que não atenda aos seus objetivos.

Na verdade, o modelo de desenvolvimento "incidente único" é uma boa idéia, como o primeiro passo. Uma razão é que isso torna o exercício de planejamento mais realista e focado. Planeje a inundação, todo o caminho. Suponha então um incidente diferente (por exemplo, falta de energia a longo prazo), aplique esse plano a ele e corrija o que quebra. Após algumas iterações, o plano deve ser relativamente robusto.

Alguns pensamentos ... - certifique-se de prestar contas de pessoas indisponíveis. Se houver uma inundação, você não pode assumir que toda a equipe relevante esteja disponível. Alguém pode estar de férias, ferido ou lidando com a família.
- planejar problemas de comunicação e fraquezas. Tem vários números e vários modos.
- o plano de DR precisa de uma cadeia de comando. Saber quem toma decisões é fundamental.
- o plano precisa ser amplamente distribuído, incluindo fora do local e fora da rede. Ele precisa estar acessível durante o desastre!

Onde trabalho, estive envolvido na execução de um teste de DR em larga escala nos últimos dois anos. Descobrimos que testar nossos serviços, pessoas e processos em situações "realistas" tem sido útil. Algumas lições aprendidas (talvez óbvias), na esperança de que sejam úteis:

• Serviços não testados, apesar do que eles escreveram em sua documentação de DR, geralmente têm dependências implícitas e indutoras de catástrofes. Agitá-los com um teste realista ou dois é uma saída útil e mensurável de um processo de preparação para DR.
• Pessoas não testadas tendem a pensar que seus sistemas estão bem e "saberão o que fazer" em uma situação de desastre. Sacudindo- se com um teste realista ou dois é grande.
• Os processos não testados desmoronam rapidamente em situações de emergência reais. Em particular, processos complexos de escalação focados principalmente em informar a quebra da alta gerência de maneiras espetaculares. Processos leves, focados nas necessidades da equipe de operações e de outros respondedores, fontes centrais de informações sobre a emergência que se desenrola, transferência explícita de responsabilidades e procedimentos de resposta a emergências 'cotidianos' funcionam melhor.

Acho que estou entendendo que você deve tentar não tornar tudo sobre seu processo de planejamento de DR teórico. Peça permissão para realmente quebrar as coisas e, assim, obter dados concretos sobre a preparação da sua organização. Isso exigirá algum apoio sério da gerência, é claro, mas pode ser um foco maravilhoso para a empresa passar alguns dias realmente treinando para o pior.

Cian

Existem vários padrões do British Standards Institute (BSi) que se concentram no gerenciamento de continuidade e recuperação de desastres.

• BS 25999-1: 2006 Gerenciamento de continuidade de negócios, Parte 1: Código de prática
• BS 25999-2: 2007 Gerenciamento de continuidade de negócios. Especificação
• BS 25777: 2008 Gerenciamento de continuidade da tecnologia da informação e comunicação. Código de prática

Pode parecer óbvio, mas, para acompanhar a documentação externa acima, verifique se você possui backups externos (de preferência fora da região). Pode ser um serviço de armazenamento on-line ou um local para gravar fitas.

Digo preferencialmente fora da região porque venho de uma área onde não temos muitos desastres naturais anualmente, mas, se / quando o temos, é em escala regional com destruição em massa (terremotos, vulcões). É muito bom ter seu backup em um cofre no banco, até que ele esteja sob magma líquido quente (/ Dr. Evil Voice).

Algo que eu li sobre agências compartilhando o custo de manutenção de um hot site para quando o grande acontece. Eles promulgam planos para restaurar a missão de ambas as empresas, essenciais para o hot site, usando virtualização e outros e, em seguida, compartilham a equipe no nível de certificar-se de que todas as luzes estão piscando. Apenas um pensamento.

Para livros, há o Disaster Recovery Planning de Jon William Toigo, agora em sua 3ª edição, com um blook da 4ª edição (blog + livro) no horizonte.

Laura,

Aqui está um link do SQLServerPedia que fornece os conceitos básicos de DR.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Leia também sobre "Continuidade de negócios"