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

29

Eu fui encarregado de liderar um projeto sobre a atualização de um antigo plano de recuperação de desastres. Por enquanto estamos apenas olhando para obter o lado de TI do DR resolvido. A última vez que fizeram isso, definiram seu escopo criando um único desastre (o data center inundado) e planejando o mesmo com a exclusão de todos os outros tipos de desastre. Eu gostaria de ter uma abordagem mais completa. Eu sei que este é um problema resolvido, outras organizações escreveram planos de DR.

Nosso plano é pegar nosso plano de DR de TI e seguir em frente e dizer "Ei, isso é o que queremos em um plano de DR para TI, ele combina com o que o restante da Universidade está fazendo? Há restauração Priorties de serviço que você gostaria de mudar? " Temos uma boa ideia do que é o restante do plano e esperamos que isso aconteça bem.

O que estou procurando é orientação sobre como definir um plano de DR e em quais perguntas devo pensar. Você tem recursos, livros e treinamentos favoritos relacionados ao desenvolvimento de planos de DR?

    
por Laura Thomas 18.06.2009 / 18:32

11 respostas

12

Uma excelente fonte de informações é o Diário de recuperação de desastres ( sobre ).

Os recursos da comunidade disponíveis incluem o rascunho atual do documento Práticas Geralmente Aceitas (GAP) , que fornece um excelente esboço do processo e das entregas que constituem um sólido plano e processo de continuidade de negócios. Também estão disponíveis vários white papers cobrindo 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 acabar (como o documento DRJ GAP), você pode garantir que você otimize o tempo investido e maximize o valor do produto final.

Eu acho sua publicação trimestral interessante e informativa também ( assine ).

    
por 18.06.2009 / 20:02
12

Certifique-se de ter uma lista de contatos de emergência. também conhecido como Recall Roster

Deveria se parecer com uma árvore e mostrar quem contata quem. No final de uma filial, a última pessoa deve ligar para o primeiro e informar quem não pôde ser contatado.

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

    
por 18.06.2009 / 19:33
8

Se adicionarmos nossas ideias, poderemos criar um wiki interessante a partir deste post, assim que todos tiverem adicionado suas próprias ideias. Eu entendo que há bando 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ê tem documentação off-line / remota de sua rede

    
por 18.06.2009 / 18:44
8

Com o DR, as coisas básicas são seus RTOs (Objetivos do Tempo de Recuperação) e RPOs (Objetivos do Ponto de Recuperação), que traduzem aproximadamente "quanto tempo é aceitável para gastar, 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 devem ser orientados por seus clientes, mas, como você está começando pelo ângulo da TI, você pode adivinhar melhor, mas esteja preparado para se ajustar para cima ou para baixo conforme necessário. Apontar para o mais próximo de "nenhum e nenhum", como você pode razoavelmente obter é bom, mas você precisa ser capaz de reconhecer quando o ponto de retornos decrescentes entra.

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

Eu gosto da abordagem mais completa; É tentador listar os eventos que podem levar a um cenário de recuperação de desastres, mas eles realmente pertencem mais a um exercício de análise / mitigação de riscos. Com DR, o incidente já aconteceu, e detalhes do que ele é são menos relevantes (exceto talvez em termos de afetar a disponibilidade de instalações de DR). Se você perder um servidor, precisará recuperá-lo, independentemente de ter sido atingido por um raio, acidentalmente formatado ou o que for. Uma abordagem centrada na escala e disseminação do desastre tem maior probabilidade de produzir resultados.

Uma abordagem para usar nos clientes, se você achar que eles estão relutantes em se envolver, é perguntar-lhes sobre o DR de um ângulo que não seja de TI. Perguntar quais são seus planos, se todos os seus arquivos em papel ficarem em chamas é um exemplo aqui. Isso pode ajudar a envolvê-los mais com o DR, e pode fornecer informações úteis aos seus próprios planos.

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

    
por 18.06.2009 / 19:14
4

Na verdade, o modelo de desenvolvimento "único incidente" é uma boa ideia, como o primeiro passo. Uma razão é que isso torna o exercício de planejamento mais realista e focado. Plano para o dilúvio, todo o caminho. Então suponha um incidente diferente (digamos, falta de energia a longo prazo), aplique esse plano a ele e corrija o que quebra. Depois de algumas iterações, o plano deve ser relativamente robusto.

Alguns pensamentos ...  - não se esqueça de contabilizar pessoas indisponíveis. Se houver uma inundação, você não pode assumir que todos os funcionários relevantes estão disponíveis. Alguém pode estar de férias, ferido ou lidando com a família.
 - planejar problemas e fraquezas de comunicação. Tem vários números e vários modos.
 - o plano de DR precisa de uma cadeia de comando. Saber quem toma decisões é crítico.  - o plano precisa ser amplamente distribuído, incluindo fora do local e fora da rede. Precisa estar acessível durante o desastre!

    
por 18.06.2009 / 22:37
4

Onde eu trabalho, estive envolvido na execução de um teste de DR em larga escala em cada um dos dois últimos 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 você as ache úteis:

  • Os 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 realístico 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 "sabem o que fazer" em uma situação de desastre. Agitando-os up com um teste realista ou dois é ótimo.
  • Processos não testados desmoronam rapidamente em situações reais de emergência. Em particular, os processos complexos de encaminhamento se concentraram principalmente em informar a alta gerência a quebrar de maneiras espetaculares. Processos leves focados nas necessidades da equipe de operações e de outros profissionais de resposta, fontes centrais de informações sobre o desenrolar da emergência, transferência explícita de responsabilidades e procedimentos de resposta a emergências "cotidianas" funcionam melhor.

Eu acho que o que eu quero dizer é que você deve tentar não fazer tudo teórico sobre o seu processo de planejamento de DR. Peça permissão para realmente quebrar as coisas e, assim, obter dados concretos sobre a preparação da sua organização. Isso exigirá um apoio sério da gerência, é claro, mas pode ser maravilhoso para o negócio passar alguns dias realmente ensaiando para o pior.

Cian

    
por 05.07.2009 / 15:52
3

Existem vários padrões do Instituto Britânico de Normas (BSi) que enfocam o gerenciamento de continuidade e a recuperação de desastres.

  • BS 25999-1: 2006 Gestão 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 Tecnologia da informação e comunicação gerenciamento de continuidade. Código de prática
por 18.06.2009 / 19:29
3

Pode parecer óbvio, mas para acompanhar a documentação externa acima, certifique-se de ter backups externos (de preferência fora da região). Pode ser um serviço de armazenamento online ou um local para levar fitas para.

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

Algo sobre o qual eu li é que as agências compartilham o custo de manter um hotsite para quando o grande bate. Eles promovem a restauração da missão crítica de ambas as empresas para o hotsite, usando a virtualização e outras, e compartilham a equipe no nível de garantia de que todas as luzes estão piscando. Apenas um pensamento.

    
por 18.06.2009 / 21:05
2

Para livros, há Planejamento de Recuperação de Desastres de Jon William Toigo, agora na sua 3ª edição, com um 4ª edição blook (blog + livro) no horizonte.

    
por 19.06.2009 / 09:59
1

Laura,

Aqui está um link do SQLServerPedia que fornece os fundamentos do DR.

link

    
por 18.06.2009 / 19:00
1

Leia também em "Continuidade de Negócios"

    
por 18.06.2009 / 19:08