Opiniones | Opinions | Editoriales | Editorials

Cinco trampas comunes en la planeación y recuperación de desastres que debe evitar

 
Picture of System Administrator
Cinco trampas comunes en la planeación y recuperación de desastres que debe evitar
by System Administrator - Thursday, 24 July 2014, 8:19 PM
Colaboradores y Partners

Cinco trampas comunes en la planeación y recuperación de desastres que debe evitar

por Emily McLaughlin

Fuente: http://searchdatacenter.techtarget.com/

Cómo mejorar su proceso de recuperación de desastres con pruebas actualizadas

 

Las pruebas de recuperación de desastres evalúan la eficacia de los planes de continuidad de negocio (BC) y recuperación de desastres (DR) con el fin de ayudar a las organizaciones a rechazar  amenazas ambientales, humanas o técnicas. Probar un proceso o procesos de recuperación de desastres permite a las organizaciones evaluar si se requiere personal adicional, formación o mantenimiento del sistema antes de que ocurra un desastre en vivo.

En una reciente conversación vía Twitter de SearchCIO, los seguidores de Twitter del sitio –una mezcla de profesionales y expertos, incluidos expertos destacados como Paul Kirvan, consultor independiente y auditor de TI con más de 20 años de experiencia en DR y BC– compartieron sus mejores consejos para una mejor planificación de desastres y recuperación, tales como la forma de programar una prueba de DR.

Cuando se les preguntó: “¿Cuál es la trampa Nº 1 a evitar cuando se hace una prueba de recuperación de desastres?”, los encuestados descubrieron una serie de problemas comunes. Revise esta presentación para aprender los cinco consejos que Kirvan y otros proporcionaron los CIO y los equipos de planificación de DR al probar los procesos de recuperación de desastres de sus organizaciones.

Con un plan de pruebas de DR, falle en planear y planee fallar

 

De acuerdo con el experto en recuperación de desastres (DR) y continuidad de negocio (BC) Paul Kirvan, si usted no planea, planea fallar.

Las estrategias de DR y BC dependen de que TI y el negocio trabajen juntos para poner a prueba los procesos y procedimientos de DR, asegurando que los sistemas más críticos puedan volver a funcionar lo antes posible. Las pruebas de DR se pueden programar con semanas, meses o incluso un año de antelación, dependiendo de los sistemas o procesos a mano. Kirvan destaca la falta de preparación y que no se implique a los actores relevantes como los principales errores en un plan de pruebas de DR.

Si bien las organizaciones no pueden anticipar el desastre exacto que pueden verse obligados a enfrentar, asegurarse de que los principales actores son conscientes de la ejecución de una prueba de recuperación de desastres les da la oportunidad de documentar qué tan bien –o mal– se ha llevado a cabo. Añade Kirvan:

 

Para más consejos de Kirvan, visite las páginas hermanas SearchCIO y SearchDisasterRecovery.

No haga suposiciones acerca de la interrupción del servicio

 

 

Ya sabe lo que dicen de los que asumen.

Bob Egan, director general y fundador de The Sepharim Group, una empresa de investigación de la industria móvil y consultoría empresarial, advierte a los estrategas de DR: No hagan suposiciones sobre las causas conocidas o desconocidas de una interrupción del servicio, ya que hacerlo podría traer consecuencias.

Hay una larga lista de posibles razones de las interrupciones, que van desde el error humano básico a problemas técnicos, hasta pobres correcciones de codificación y crisis ambientales. Durante la discusión por Twitter de SearchCIO sobre las pruebas del plan de recuperación de desastres, Egan sugirió que las organizaciones no pueden mejorar las pruebas de DR si no están llegando a conclusiones basadas en la evidencia sobre las causas de las interrupciones del servicio. Por ejemplo, solo porque un hacker interrumpió sus servidores el mes pasado, no quiere decir que un hacker es la causa de la interrupción de este mes.

Los participantes Andi Mann y Edward Haletky (aka Texiwill) también sopesaron los peligros de saltarse las pruebas y análisis que pueden soportar –o disipar– supuestos:

 

Las pruebas no se ejecutarán sin problemas 100% del tiempo. Es importante que las organizaciones sigan con precisión el quién, qué, cuándo, dónde y por qué de las interrupciones en el servicio –y luego planifiquen el tiempo para volver a probarlos.

Evite apilar la programación de pruebas en un plan de DR de negocios

 

Los participantes del #CIOChat de SearchCIO dicen que la preparación es esencial para la ejecución de una prueba adecuada para un plan de recuperación de desastres de negocios. El experto en recuperación de desastres, Paul Kirvan, advirtió que si TI falla en planificar, podría también planear fallar, y, posteriormente, hizo hincapié en la necesidad de una atenta planificación de las pruebas de DR –un tema que nuestro sitio hermano SearchDisasterRecovery ha cubierto ampliamente.

"Un plan de prueba es preparado y presentado a la dirección para que los recursos puedan ser pre-asignados para la próxima serie de actividades de prueba. Luego, se hace planes discretos para cada uno de los eventos de prueba programados para los próximos 12 meses", explicó el experto Jon Toigo en una columna reciente. "Cada caso de prueba se ejecuta según el calendario, con las tareas y los procedimientos de recuperación representados en una forma no lineal para optimizar el tiempo de prueba”.

Kirvan y Toigo recomendaron examinar tareas interdependientes por separado para evitar que el fallo de un procedimiento de prueba afecte a todo el evento. El no alinear la planificación de las pruebas con antelación y de manera consciente –o inconscientemente– superponer las pruebas podría ser improductivo y demostrar resultados falsos.

No olvide documentar los resultados de las pruebas de DR con una revisión posterior

 

Documentar la ejecución de pruebas de los planes de recuperación de desastres (DR) con una revisión después de la acción no solo mejorará las pruebas futuras, sino que preparará a su organización para el éxito cuando ocurra un desastre real.

La participante del # CIOChat y alumna de Forrester, Rachel Dines, ahora gerente de marketing de producto en Riverbed Technology, fue la primera en abogar por la importancia de un examen posterior a la acción durante la conversación por Twitter de SearchCIO sobre recuperación de desastres. Dines fue respaldada rápidamente por otros tuiteros que estuvieron de acuerdo en que, al no hacer seguimiento, las organizaciones están aumentando la probabilidad de dificultades en DR en el futuro:

 

Hacer de la documentación un procedimiento estándar, como Andi Mann sugirió, asegurará que su organización está aprendiendo lo que funciona y lo que no en su plan de DR. A fin de obtener la documentación adecuada, los actores clave deben participar en la prueba de DR y deben tratarla como si fuera un desastre verdadero.

Use ejemplos de DR basados en escenarios reales, no conjeturas

 

De acuerdo con el tuitero Ant Stanley, la trampa N º 1 a evitar cuando se hace una prueba de recuperación de desastres (DR) es una falta de urgencia y exhaustividad. Otros participantes de la conversación de SearchCIO coincidieron en la importancia de fundamentar ejemplos de recuperación de desastres en escenarios del mundo real:

 

Andi Mann podría haberlo dicho mejor. Los tuiteros sugirieron que la simulación de escenarios de desastres reales ayuda a las organizaciones a crecer a partir de las pruebas de DR, y con el fin de probar con éxito ejemplos de recuperación de desastres, deberá involucrar al negocio:

 

Para prepararse para un ataque real, las organizaciones y sus CIO deben tratar las pruebas de DR como un ataque real. Otros puntos clave de nuestros tuiteros del #CIOChat –como planificar el fracaso, programar las pruebas con antelación y documentar todo, desde el principio al fin– también pueden orientar su estrategia de DR.

Para más información sobre el #CIOChat de SearchCIO, busque el hashtag en Twitter.

 

1228 words