Es un desastre la planificación de recuperación para dummies

Utilice un análisis de impacto en el negocio para ayudar a determinar qué procesos y sistemas justifiquen los gastos y esfuerzos relacionados con el desarrollo de su plan de recuperación de desastres de TI. LA business yompact lanálisis (BIA) es un inventario detallado de los principales procesos, sistemas, bienes, personas y proveedores que están asociados con actividades comerciales principales de una organización.

El propósito central de un Análisis de Impacto en el Negocio es identificar qué procesos y sistemas son los más críticos para la supervivencia de una organización.

Siga estos pasos para completar el análisis de impacto en el negocio:

1. Establecer el equipo del proyecto, el alcance y presupuesto- nombrar un director de proyecto.

2. Obtener el apoyo ejecutivo.

3. Inventario de sus elementos clave del negocio:

4. Procesos de negocios

5. Sistemas de información / aplicaciones

6. Activos

7. Personal

8. Proveedores

Desarrollar formularios de admisión que se pueden utilizar para recopilar información consistente. Entrevistar a los principales expertos en todo el negocio. Obtener información de los inventarios.

9. Tabular los resultados en una hoja de cálculo o un documento.

10. Para cada proceso de negocio, determinar el tiempo de inactividad máximo tolerable (MTD)

    MTD es el tiempo más largo el proceso puede permanecer desactivada antes de que pone en peligro la supervivencia de la organización.

11. Para cada proceso de negocio, determinar un objetivo razonable de tiempo de recuperación (RTO) y Punto de Recuperación Objetivo (RPO).

12. Clasificar la lista de procesos de negocio en MTD u orden RTO.

    Los procesos con el MTD o RTO más corto son los procesos de negocio más críticos. Obtener el acuerdo de la alta dirección.

13. Realizar un análisis de riesgos en cada proceso crítico para identificar las vulnerabilidades que existen, junto con medidas para mitigar esas vulnerabilidades.

Mientras se prepara para desarrollar y documentar los planes de recuperación de desastres de TI para los componentes que soportan los procesos de negocio críticos, usted debe saber lo que pasa exactamente en un plan de DR, cómo estructurar, y la forma de gestionar el contenido del plan.

Planes de recuperación de desastres deben contener

• Procedimientos de declaración de desastre.

• Listas de contactos de emergencia.

• El liderazgo de emergencia y selección de papel.

• Procedimientos de evaluación de daños.

• Recuperación del sistema y los procedimientos de reinicio.

• Procedimiento sobre cómo hacer la transición a las operaciones normales.

Mantenga los documentos del plan bajo control de versiones, utilice un formato coherente, tienen expertos en la materia revisar el plan, probar la eficacia del plan, y distribuir los documentos a todo el personal del equipo de recuperación de desastres probables.

Después de escribir el plan de DR, publicarlo en formas que la hacen disponible para el personal de recuperación: Distribuir en múltiples formas (incluyendo copia en papel, CD-ROM, memoria USB, etc.) por lo que el personal de respuesta de emergencia en realidad puede acceder a esos planes de dondequiera que se encuentren, sin tener que depender de los mismos sistemas de TI que puedan ser espera que se recupere.

Las pruebas son una parte natural del ciclo de vida de muchos esfuerzos de desarrollo de la tecnología: software, procesos, y - sí - planificación de recuperación de desastres. Los desastres no ocurren muy a menudo por lo que rara vez se puede decir claramente si esos planes de DR en realidad trabajar. Y teniendo en cuenta la naturaleza de los desastres, si su plan de DR falla, la organización no puede sobrevivir al desastre.

Éstos son los cinco tipos de pruebas de recuperación de desastres:

• Prueba de papel: Las personas que leen y anotan los planes de recuperación.

• Tutorial de prueba: Grupos a pie a través de planes para identificar los problemas y cambios.

• Simulación: Grupos pasan por una catástrofe simulada para identificar si los planes de respuesta de emergencia son las adecuadas.

• Prueba en paralelo: Sistemas de recuperación se construyen / configurar y probados para ver si pueden realizar transacciones comerciales reales para apoyar los procesos clave. Los sistemas primarios todavía llevan la carga de trabajo de producción.

• Prueba de corte y cambio: Sistemas de recuperación se construyen / configurados para asumir la carga de trabajo de producción. Desconecte los sistemas primarios.

Estructure su prueba DR de la misma manera que la estructura de otras empresas complicadas, como el desarrollo de software y pruebas asociado. Sólo tienes que seguir estos pasos:

1. Determinar la frecuencia con que debe realizar cada tipo de prueba.

2. Pon a prueba los componentes individuales.

   Nota cualquier discrepancia, y luego pasar el plan de vuelta a la gente que escribió cada sección para que puedan actualizarlo. Este proceso mejora la calidad y la exactitud del plan de DR, lo que aumenta la probabilidad de que la organización realmente sobrevivir a un desastre si se da.

3. Realizar pruebas más amplias de componentes combinados.

4. Pon a prueba todo el plan.

Mediante la realización de estos cuatro pasos, se puede identificar muchos errores durante las pruebas individuales y corregir los errores antes de hacer las pruebas más exhaustivas. Este proceso ahorra tiempo al evitar pequeños errores de interrumpir las pruebas integrales que involucran una gran cantidad de personas.