TRES CONSEJOS RÁPIDOS PARA UN EXITOSO RUNBOOK DE RECUPERACIÓN ANTE DESASTRES

12 Feb 2020

Un sinnúmero de escenarios puede traer abajo un negocio, generando riesgo de daños a la reputación, multas regulatorias y pérdida de datos. Es clave tener un plan de recuperación de desastres de TI, vinculado a la respuesta a incidentes de seguridad y al plan macro de Continuidad de Negocios de la organización. Pero ¿qué debería implicar exactamente un sólido plan de recuperación ante desastres (DR)?

Como mínimo, cada plan de DR debe tener una vía para los failover y la failback, las aplicaciones escalonadas por orden de importancia, las pruebas regulares e integrales y un runbook (Manual de ejecución/ Representaciones visuales de los procedimientos) de DR. De estas áreas, el runbook es con lo que la mayoría de las empresas suelen tener dificultades. Aquí hay tres consejos rápidos para ayudarlo a fortalecer su runbook de DR y, en consecuencia, su plan DR general.

 

  • Planifique el espectro completo de eventos

Antes de escribir su runbook de DR, piense qué tipos de eventos podrían desencadenar una declaración. Claro, hay huracanes, tornados, inundaciones, etc. Piense más allá de los desastres naturales. También es común ver interrupciones resultantes de errores humanos, incendios, cortes de energía, ataques cibernéticos y fallas de hardware. Al construir su documentación para un runbook, la clave es permitir a aquellos que leen, una variedad de vías para la recuperación exitosa de sus sistemas de TI. Si tiene una buena idea de los tipos de escenarios probables que su empresa podría enfrentar, esto ayudará a enmarcar la base del contenido del runbook. Considere qué sistemas en cada escenario deben recuperarse primero y tenga en cuenta las fallas completas del centro de datos, las fallas parciales y la recuperación de una sola aplicación.

Puede parecer abrumador tratar de dar cuenta de cada escenario posible. Si este será el primer runbook de DR documentado de su empresa, comience con una falla completa del centro de datos. Puede parecer contradictorio comenzar con los más complejos y luego pasar a otros escenarios, pero su tarea número 1 en este punto es proteger la mayor cantidad posible de los activos digitales de su empresa. Comenzar con una falla completa del centro de datos le permitirá cubrir el panorama más amplio. A medida que pruebe su plan, podrá completar los detalles.

Después de desarrollar su runbook para un failover completo, tome otro escenario probable, tal vez una falla de la matriz de almacenamiento, y pregúntese: «¿Qué partes del runbook ejecutaríamos en este caso?» ¿Qué otros pasos necesitarías tomar? Para ayudar a organizar su runbook, use el concepto de listas de verificación. Para un failover completo, necesitaría una lista de verificación que cubra todas las tareas y actividades. Esta lista de verificación haría referencia a las instrucciones detalladas necesarias para completar ese elemento. A medida que crea otros escenarios, continúe con el concepto de lista de verificación. ¿Cuáles son los pasos por seguir en este caso? Nuevamente, consulte las instrucciones detalladas, que en la mayoría de los casos serán las mismas instrucciones detalladas que ya ha escrito.

El uso de este enfoque hará que su plan IT-DR sea modular. La lista de verificación servirá como guía para los pasos apropiados en cada escenario. Otra ventaja de usar una lista de verificación es que hace que sea más fácil agregar, cambiar o eliminar pasos a medida que cambia su panorama de TI.

El proceso de identificación de escenarios puede incluso ser gamificado. Organice un concurso y haga que los empleados envíen ideas. Seleccione su escenario y ejecute una prueba de continuidad de negocios a gran escala, incluido su runbook DR. Las empresas han hecho de todo, desde «estándar», como incendios o tornados hasta derrames de materiales peligrosos, tiradores activos (desafortunadamente, tenemos que estar preparados para esto) y ataques cibernéticos.

  • Detallar todo y en términos simplificados

Es importante tener en cuenta al escribir su runbook de DR que su personal de TI no puede siempre estar presente para realizar el proceso de recuperación. En escenarios de desastres naturales, probablemente estarán más preocupados por la seguridad de sus familias. Por esta razón, su runbook debe estar escrito para que cualquiera pueda tomarlo y ejecutar el failover. Si el lector no tiene un conocimiento complejo de sus sistemas de TI, ¿qué necesitará saber? Incluya información sobre contactos internos y externos clave, roles y responsabilidades, y rutas de escalación. Evitar el uso de jergas que solo su equipo interno de TI conoce.

Escribir un runbook de DR que cualquiera pueda ejecutar puede ser extremadamente difícil. En cierto modo, debe olvidar lo que sabe y comenzar con los pasos más básicos. No puede suponer que el lector será alguien familiarizado con los sistemas que está recuperando. Una excelente manera de lograr esto es definir un proceso para construir y refinar su runbook. Comience con un chequeo de escritorio por un par o grupo de pares. Al igual que una revisión por pares del código, una revisión por pares de un runbook de DR puede ser invaluable para garantizar la exhaustividad de su plan.

Después de la revisión por pares, haga que alguien de otra área de TI revise el plan. Tal vez pueda hacerlo alguien del área de desarrollo de softwares o de help desk. Pídales que documenten cada pregunta que tengan mientras leen el plan. Cuando terminen, conteste cada una de sus preguntas en el plan mismo.

Después de este proceso de revisión en dos etapas, está listo para probar su plan. La primera vez que realice la prueba, ejecute el plan usted mismo, tomando nota cada vez que haya necesitado desviarse del plan escrito o que el plan no estaba claro. La próxima vez que pruebe el runbook, haga que una persona menor ejecute el plan. Nuevamente, documente cada pregunta o cada lugar en el que el texto no fue claro para ellos. Después de algunas pruebas, sea valiente y pídale a su director financiero que ejecute el plan. Él o ella podría sorprenderlo. Nuevamente, documente las preguntas que hacen y actualice su runbook.

 

  • Repita su Runbook de DR después de la prueba

Una vez que haya completado el primer borrador de su runbook de DR, pruébelo. Luego, reúna a su equipo de TI después de la prueba y discuta los éxitos y las dificultades. Documente todo y actualice su runbook en consecuencia. ¿Por qué probar un plan DR y no aprender de él? La clave es mantener el runbook siempre actualizado con las prácticas, procesos e información más actuales para que, cuando ocurra un evento, no dependa de información desactualizada para recuperar sus sistemas y datos. Piense que tiene un mapa del tesoro que no fue revisado después de que el tesoro fue movido. Estará destinado a la confusión y la frustración si su runbook de DR no se ajusta después de cada prueba. Además, establezca una ubicación confiable para la última versión publicada de su runbook, una única fuente de la verdad. Y mantenga un archivo de las versiones anteriores también, en caso de que necesite volver a consultarlas.

Muchos equipos miran hacia atrás en una prueba IT-DR que no fue 100 por ciento exitosa como un fracaso. En cambio, mírelos como experiencias de aprendizaje, una forma de mejorar y mejorar. Este proceso iterativo es vital para su capacidad de recuperar sus sistemas de TI cuando se encuentra con un problema. Cuanto más documente, más valide, más itera, más confianza tendrá en su capacidad para recuperar sus sistemas.

IT-DR debe ser parte de su proceso de gestión de cambios. Cada cambio debe ser evaluado por su impacto en el runbook. Si se necesita un cambio, actualícelo inmediatamente, no durante su próxima prueba cuando no esté seguro de cuál fue el cambio. Marque el cambio para que, cuando realice la prueba, sepa prestar atención específica a esos pasos. Si se producen desafíos debido al cambio, documente lo que se hizo para superar el desafío y luego actualice el plan IT-DR en consecuencia.

 

Su negocio depende de la capacidad de recuperación

Es parte de la responsabilidad de su departamento de TI garantizar el buen funcionamiento del negocio y la protección de sus activos digitales más importantes. Tener un runbook de DR que esté bien probado y listo para usar en cualquier momento cumple en parte esta obligación. Si necesita ayuda para construir o delinear las complejidades de su plan de recuperación ante desastres, busque ayuda de un consultor especializado, un proveedor de recuperación de desastres como servicio (DRaaS) o un proveedor de servicios estratégicos, ya que tendrán una visión holística del panorama de TI. Es mejor tener una segunda opinión que brechas de riesgo en la protección de su negocio.

Perfil_Jeff_Ton

Jeff Ton es vicepresidente senior de desarrollo de productos y alianzas estratégicas en InterVision y autor de «Amplifique su valor: Liderando TI con visión estratégica».

Si quieres conocer más acerca de este curso haz clic en este enlace o comunícate con nosotros

COMPARTIR

ÚLTIMOS ARTÍCULOS

Herramientas de Ciberseguridad a aplicar para cada función de la nueva versión de NIST CSF 2 y recomendaciones para maximizar la inversión

Durante el punto álgido de la pandemia, la mayoría de las organizaciones dejaron de realizar viajes de negocios por completo. Otros elevaron la autorización para viajes relacionados con negocios a los niveles más altos de C-Suite, asegurando una visión de arriba hacia abajo de los costos y las posibles ramificaciones reputacionales de viajar cuando otros no lo hacían.

Leer Más >>

De reactivo a proactivo: Elaboración de una estrategia de recuperación ante desastres preparada para el futuro

Durante el punto álgido de la pandemia, la mayoría de las organizaciones dejaron de realizar viajes de negocios por completo. Otros elevaron la autorización para viajes relacionados con negocios a los niveles más altos de C-Suite, asegurando una visión de arriba hacia abajo de los costos y las posibles ramificaciones reputacionales de viajar cuando otros no lo hacían.

Leer Más >>

Terremotos: predecir lo impredecible

Durante el punto álgido de la pandemia, la mayoría de las organizaciones dejaron de realizar viajes de negocios por completo. Otros elevaron la autorización para viajes relacionados con negocios a los niveles más altos de C-Suite, asegurando una visión de arriba hacia abajo de los costos y las posibles ramificaciones reputacionales de viajar cuando otros no lo hacían.

Leer Más >>

Desinformación sobre desastres

Durante el punto álgido de la pandemia, la mayoría de las organizaciones dejaron de realizar viajes de negocios por completo. Otros elevaron la autorización para viajes relacionados con negocios a los niveles más altos de C-Suite, asegurando una visión de arriba hacia abajo de los costos y las posibles ramificaciones reputacionales de viajar cuando otros no lo hacían.

Leer Más >>

Predicciones de seguridad y ciberseguridad para 2024

Durante el punto álgido de la pandemia, la mayoría de las organizaciones dejaron de realizar viajes de negocios por completo. Otros elevaron la autorización para viajes relacionados con negocios a los niveles más altos de C-Suite, asegurando una visión de arriba hacia abajo de los costos y las posibles ramificaciones reputacionales de viajar cuando otros no lo hacían.

Leer Más >>

Lecciones posteriores al desastre: qué se debe aprender y cómo

Durante el punto álgido de la pandemia, la mayoría de las organizaciones dejaron de realizar viajes de negocios por completo. Otros elevaron la autorización para viajes relacionados con negocios a los niveles más altos de C-Suite, asegurando una visión de arriba hacia abajo de los costos y las posibles ramificaciones reputacionales de viajar cuando otros no lo hacían.

Leer Más >>