¿Desarrollo de planes de recuperación ante desastres mejores prácticas o recursos? [cerrado]

Se me ha encomendado la tarea de liderar un proyecto con respecto a la actualización de un plan de recuperación ante desastres antiguo y unilateral Por ahora solo estamos buscando solucionar el lado de TI de DR. La última vez que hicieron esto, establecieron su alcance inventando un solo desastre (el centro de datos se inundó) y planificando para ello con exclusión de todos los demás tipos de desastres. Me gustaría adoptar un enfoque más completo. Sé que este es un problema resuelto, otras organizaciones han escrito planes DR.

Nuestro plan es tomar nuestro plan de DR de TI y seguir adelante y decir "Oye, esto es lo que queremos en un plan de DR para TI, ¿encaja con lo que está haciendo el resto de la Universidad? ¿Hay servicios de restauración restaurados? ¿Te gustaría cambiar? Tenemos una idea bastante buena de lo que es el resto del plan y esperamos que todo salga bien.

Lo que estoy buscando es orientación sobre cómo abarcar un plan de recuperación ante desastres y qué preguntas debería tener en cuenta. ¿Tiene recursos favoritos, libros, capacitación relacionados con el desarrollo del plan DR?

Una excelente fuente de información es Disaster Recovery Journal ( about ).

Los recursos de la comunidad disponibles incluyen el borrador actual de su documento de Prácticas generalmente aceptadas (GAP) , que proporciona un excelente resumen del proceso y los resultados que constituyen un sólido plan y proceso de continuidad del negocio. También hay disponibles varios documentos que cubren varios temas de DR / BC.

El proceso parece desalentador, pero si se aborda sistemáticamente con un buen resumen de dónde le gustaría terminar (como el documento DRJ GAP), puede asegurarse de optimizar el tiempo invertido y maximizar el valor del producto final.

También encuentro que su publicación trimestral es interesante e informativa ( suscribirse ).

Asegúrese de tener una lista de contactos de emergencia. también conocido como Lista de retiro

Debe verse como un árbol y mostrar quién contacta a quién. Al final de una sucursal, la última persona debe llamar a la primera e informar a cualquier persona que no pudo ser contactada.

(Esto se puede coordinar a través de RRHH y usarse para cualquier tipo de desastre)

Si agregamos nuestras ideas, podríamos crear un buen wiki a partir de esta publicación una vez que todos hayan agregado sus propias ideas. Entiendo que hay muchos por seguir, pero algunos de nosotros tenemos prioridades específicas en lo que respecta a la recuperación. Para empezar, aquí está el mío:

Asegúrese de tener documentación fuera de línea / remota de su red

Con DR, las cosas básicas son sus RTO (objetivos de tiempo de recuperación) y RPO (objetivos de punto de recuperación), que se traducen aproximadamente como "cuánto tiempo es aceptable tener que gastar para recuperarlo y cuántos datos podemos perder". En un mundo ideal, las respuestas serían "ninguna y ninguna", pero un escenario DR es una circunstancia excepcional. Estos realmente deberían ser impulsados ​​por sus clientes, pero dado que está comenzando desde el ángulo de TI, puede hacer las mejores conjeturas, pero esté preparado para ajustar hacia arriba o hacia abajo según sea necesario. Apuntar a lo más cercano a "ninguno y ninguno" que pueda obtener razonablemente es bueno, pero deberá ser capaz de reconocer cuándo llega el punto de rendimientos decrecientes.

Estos dos factores pueden ser diferentes en diferentes épocas del año y diferentes en diferentes sistemas.

Me gusta el enfoque más completo; Es tentador enumerar los eventos que pueden conducir a un escenario de DR, pero estos realmente pertenecen más a un ejercicio de análisis / mitigación de riesgos. Con DR, el incidente ya ha sucedido, y los detalles de lo que fue son menos relevantes (excepto quizás en términos de afectar la disponibilidad de las instalaciones de DR). Si pierde un servidor, necesita recuperarlo, independientemente de si fue alcanzado por un rayo, formateado accidentalmente o lo que sea. Un enfoque centrado en la escala y la propagación del desastre es más probable que produzca resultados.

Un enfoque para usar en los clientes, si encuentra que son reacios a involucrarse, es hacerles preguntas de DR desde un ángulo que no sea de TI. Preguntar cuáles son sus planes si todos sus archivos en papel se incendian es un ejemplo aquí. Esto puede ayudar a que participen más en el asunto más amplio de DR, y puede alimentar información útil en sus propios planes.

Finalmente probar su plan regularmente es crucial para el éxito. No es bueno tener un hermoso plan de recuperación de desastres que se ve muy bien en el papel pero que no cumple con sus objetivos.

En realidad, el modelo de desarrollo de "incidente único" es una buena idea, como primer paso. Una razón es que hace que el ejercicio de planificación sea más realista y centrado. Planifique la inundación, hasta el final. Luego, suponga un incidente diferente (por ejemplo, corte de energía a largo plazo), aplique ese plan y arregle lo que se rompe. Después de algunas iteraciones, el plan debería ser relativamente robusto.

Algunos pensamientos ... - asegúrese de tener en cuenta a las personas no disponibles. Si hay una inundación, no puede asumir que todo el personal relevante está disponible. Alguien podría estar de vacaciones, lesionado o tratar con su familia.
- planificar problemas de comunicación y debilidades. Tener múltiples números y múltiples modos.
- El plan DR necesita una cadena de mando. Saber quién toma las decisiones es fundamental.
- el plan debe estar ampliamente distribuido, incluso fuera del sitio y fuera de la red. ¡Debe ser accesible durante el desastre!

Donde trabajo, he participado en la realización de una prueba de DR a gran escala en cada uno de los últimos dos años. Hemos descubierto que probar nuestros servicios, personas y procesos en situaciones "realistas" ha sido útil. Algunas lecciones aprendidas (quizás obvias), con la esperanza de que las encuentre útiles:

• Los servicios no probados, a pesar de lo que han escrito en su documentación de DR, generalmente tienen dependencias implícitas que inducen catástrofes. Sacudirlos con una prueba realista o dos es un resultado útil y medible de un proceso de preparación de DR.
• Las personas no probadas tienden a pensar que sus sistemas están bien y que "sabrán qué hacer" en una situación de desastre. Agitarlos hasta con una prueba realista o dos es grande.
• Los procesos no probados se desmoronan rápidamente en situaciones de emergencia reales. En particular, los complejos procesos de escalado se centraron principalmente en informar la ruptura de la alta dirección de manera espectacular. Los procesos livianos enfocados en las necesidades del personal de operaciones y otros respondedores, las fuentes centrales de información sobre la emergencia que se desarrolla, la transferencia explícita de responsabilidad y los procedimientos de respuesta de emergencia 'cotidianos' funcionan mejor.

Supongo que lo que quiero decir es que debes tratar de no hacer que todo lo relacionado con el proceso de planificación de DR sea teórico. Solicite permiso para realmente romper cosas y así obtener datos sólidos sobre la preparación de su organización. Eso requerirá un apoyo serio de la gerencia, por supuesto, pero puede estar maravillosamente enfocado para que el negocio pase un par de días realmente ensayando para lo peor.

Cian

Existen varios estándares del British Standards Institute (BSi) que se centran en la gestión de continuidad y la recuperación ante desastres.

• BS 25999-1: 2006 Gestión de continuidad del negocio, Parte 1: Código de práctica
• BS 25999-2: 2007 Gestión de continuidad del negocio. Especificación
• BS 25777: 2008 Gestión de la continuidad de la tecnología de la información y las comunicaciones. Código de Prácticas

Puede parecer obvio, pero para seguir la documentación anterior fuera del sitio, asegúrese de tener copias de seguridad externas (preferiblemente fuera de la región). Esto podría ser un servicio de almacenamiento en línea o un lugar para llevar cintas.

Digo preferiblemente fuera de la región porque vengo de un área donde no tenemos muchos desastres naturales anualmente, pero, si tenemos uno, es a escala regional con destrucción masiva (terremotos, volcanes). Es bueno tener su respaldo en una caja de seguridad en el banco, hasta que su banco esté bajo magma líquido caliente (/ Dr. Evil Voice).

Algo sobre lo que he leído es sobre las agencias que comparten el costo de mantener un sitio caliente para cuando el grande golpea. Adoptan planes para restaurar la misión de ambas compañías, crítica para el sitio caliente, utilizando la virtualización y demás, y luego comparten el personal en el nivel de asegurarse de que todas las luces parpadeen. Solo un pensamiento.

Para los libros, está la planificación de recuperación ante desastres de Jon William Toigo, ahora en su tercera edición, con un blook de cuarta edición (blog + libro) en el horizonte.

Laura

Aquí hay un enlace de SQLServerPedia que brinda información básica sobre DR.

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

Lea también sobre "Continuidad del negocio"