blue-abstract-glass-balls

Retos durante el desarrollo de Disaster Recovery Management

Este artículo se fundamenta en las actividades que he realizado a lo largo de mi experiencia profesional dedicada a gestionar el Proceso de Resiliencia, donde se incluyen proyectos de Continuidad de Negocio y proyectos de Recuperación de Desastres.

Existen teorías de lo que es Continuidad de Negocio y lo que es Recuperación de Desastres. Me he encontrado con algunas empresas de diversos sectores, en las que hay una confusión de lo que son esas teorías, entre un Proyecto de Continuidad de Negocio y lo que es un Proyecto de Recuperación de Desastres; no pretendo contradecir ningún concepto, sencillamente lo diferenciaré de acuerdo a la larga documentación que he generado y que pertenecen a mis Lecciones Aprendidas para actividades, para éste articulo en particular, como Disaster Recovery Manager.

Las experiencias aquí descritas, se mencionan pero no están limitadas, sencillamente comparto algunas que pueden coadyuvar a los lectores para sus propias actividades, y generar sus propias lecciones aprendidas.

Mis Lecciones Aprendidas – Actividades Post prueba de DRP

Una vez terminado el ejercicio de Recuperación de Desastres, con uno de nuestros clientes del sector de aseguradoras, se reportaba vía email el resultado de esta prueba al corporativo en New York y en México, donde personal ejecutivo por parte del Cliente y por parte de nosotros (en ése entonces, laboraba para IBM), con un reporte de resultados completo. La visibilidad del resultado era desde un alto nivel.

Las principales actividades que se realizaban durante esta etapa son las siguientes:

  1. Una vez terminado el ejercicio, debía de existir una notificación vía email, por parte del Cliente para realizar la desactivación del ambiente o en caso de aplicar, el Roll-Back a operación normal (como en el caso de Metlife Brasil).
  2. Una vez recibida la notificación del Cliente, el Disaster Recovery Manager proporcionaba la instrucción a las demás Líneas de Servicio Técnicas para realizar la actividad de desactivación de ambientes (me refiero a ambientes Unix, Wintel, o los que aplicasen de acuerdo a la infraestructura asociada), la cual debía estar acompañada, la evidencia del ambiente y el nombre del Ingeniero técnico que realizó la actividad.
  3. Toda ésta actividad coordinada, por medio del Disaster Recovery Manager debía completar el script de desactivación o Roll-Back según aplique (mismo que ya se había generado y que solo es completar los tiempos de desactivación y seguimiento del orden de actividades), hasta asegurar que todas las tareas estuvieran debidamente completadas y que no exista corrupción de ambientes entre Producción y el ambiente destinado para DRP (Disaster Recovery Program, por sus siglas en inglés).
  4. Ya terminado el evento, un punto fundamental que el Disaster Recovery Manager debía considerar para documentar las evidencias, era que si existió algún problema durante la ejecución y que se resolvió o quedó pendiente, en el reporte de resultados debe de estar muy bien documentado el problema y cómo se resolvió, además de lo que se hará para que no ocurra nuevamente. En caso de no resolverse, se abría un ticket con Mesa de Ayuda para que a su vez, por medio de gestión de Incidentes, se gestionara el seguimiento para la corrección completa del problema, se documente en las lecciones aprendidas, en el procedimiento de la Línea de Servicio que correspondiera en caso de aplicar y por supuesto, para que no volviese a ocurrir el mismo.
  5. La documentación de las Lecciones Aprendidas debe de ser parte fundamental para compartirlo con las Líneas de Servicio y que no volviera a ocurrir el problema, tener el antecedente documentado e identificado y en caso de volver a aparecer, solucionarlo.

Estos puntos mencionados, son algunas actividades que he incluido en éste artículo, los cuales ayudan a formar todo el reporte final de resultados que se entrega al cliente o en todo caso, al archivo de histórico de estas actividades que bien, sirven para futuras auditorías, como evidencia clara de que estamos ejercitando nuestro plan de Recuperación para Desastres.

Mis Lecciones Aprendidas – Actividades de documentación de Lecciones Aprendidas

Caso de otra empresa del mismo giro, de aseguradoras, en particular, la documentación de las lecciones aprendidas fueron divididas en dos secciones:

Temas que salieron bien:

  1. Recuperación los aplicativos dentro del RTO (Recovery Time Objective, por sus siglas en inglés) y RPO (Recovery Point Objective, por sus siglas en inglés) acordados
  2. Definir previamente alcances y matrices de prueba
  3. Involucrar activamente a los usuarios en la revisión de alcances
  4. Establecer al War Room como punto de contacto con los usuarios para canalizar dudas, hallazgos y seguimiento de la prueba
  5. Resolución adecuada de hallazgos menores

Temas que a considerar en el futuro:

  1. Se requiere depurar la lista de aplicaciones en el alcance del Plan de Recuperación en casos de Desastre debido a que:
    1. se identificaron aplicativos que ya están fuera de producción
    2. se identificaron aplicativos duplicados se identificaron aplicativos que están ubicados fuera de GNP Plaza
  2. Se requiere que los aplicativos dentro del alcance del plan inicial estén liberados a Producción; de otro modo no es posible recuperarlos.
  3. Los cambios de la fecha original de ejecución de la prueba de Recuperación para Desastres tuvieron impacto en la participación de los usuarios (cambios de usuarios de último momento, usuarios de vacaciones, etc.)
  4. Concentrar a los usuarios en un punto común para la ejecución de pruebas para mejorar la logística de ejecución
  5. Establecer un mecanismo de notificación al War Room para casos de cambios de participantes de último momento que permita realizar los ajustes requeridos al Grupo Coordinador
  6. Validar que los usuarios agregados por sus gerentes de último momento cuenten con los accesos adecuados a los sistemas alternos previo al inicio de pruebas
  7. Identificar a los usuarios participantes y hacer una validación
  8. Fijar una fecha límite para obtener retroalimentación de las matrices de prueba por parte de los usuarios
  9. GNP requiere reforzar la importancia del flujo de notificación (sólo el 47% de los usuarios se reportó a Service Desk)

Estas lecciones aprendidas, por supuesto que deben ser compartidas con los clientes internos y externos, según el caso, para que todos tengamos conciencia de lo que hacemos y que debemos mejorar.

Mis Lecciones Aprendidas – Consideraciones que no debemos pasar por alto

Como lo comenté anteriormente, el Disaster Recovery Manager deberá obtener las evidencias, issues encontrados y resueltos, issues encontrados y no resueltos, plan de acción de resolución de issues no resueltos, y todo ésto debe de incluirse en el reporte de resultados, el cual, adicional a evidenciar toda la actividad llevada a cabo, se debe de obtener las firmas de las personas que firmaron el plan de ejecución inicial: el Ejecutivo del Proyecto, el punto focal por parte del Cliente, y el Disaster Recovery Manager o Consultor que lideró la actividad.

Recordatorio importante: Si hubo issues abiertos, se da continuidad al Action Plan (Plan de acción) que se estableció en el reporte de resultados, abriendo el ticket correspondiente, en la mesa de ayuda,  hasta el cierre del mismo.

Parte fundamental para el Cliente, dependiendo de éste y del manejo del mismo, es documentar las conclusiones.

Mis Lecciones Aprendidas – Conclusiones en base a cada experiencia

El ejemplo siguiente, expongo algunos de los resultados obtenidos de la prueba del Plan de Recuperación en casos de Desastre (DRP) para uno de mis clientes, lo cual permitieron:

  1. Validar que el Proyecto de Recuperación para Desastres es funcional y está alineado a los objetivos de negocio de la empresa como parte de su programa de Administración de la Continuidad del Negocio.
  2. Validar la correcta funcionalidad de los aplicativos por parte de los usuarios dentro de los procesos de negocio
  3. Identificar aplicativos fuera del alcance y que son requeridos por los usuarios para mantener la operación del negocio

En mi caso, la especialización me ayuda a convertirme en un SME (Subject Matter Expert, Experto en el tema), lo cual indica que estoy especializado en el tema de Continuidad, pero que en mi perspectiva, nada está escrito, no hay verdad absoluta, en cualquier evento puede ocurrir lo inesperado, positivo o negativo. Lo único posible por hacer, es intentar mitigar la devastación del mismo.

Dado este comentario, con otros clientes he concluido lo siguiente – caso Servicio de Administración de Gobierno:

  1. Para la Estrategia de Recuperación y Respaldos, se utilizó la redefinición del Análisis de Impacto al Negocio definido por Modelo de Gobierno.
  2. Se utilizó como marco teórico el código de práctica del estándar británico BS 22301 y los criterios metodológicos que marca el DRII.org.
  3. Se hizo referencia a los servicios de administración y soporte a aplicaciones (Alcance del BIA para las 57 aplicaciones críticas del negocio).
  4. Se encontró que al momento, el Negocio no tiene un sitio de Recuperación definido – se tienen los sitios de Producción en Triara Querétaro y Triara Monterrey. Éstos a su vez, tienen ciertas limitantes si se desean utilizar como Centro de Datos alterno. Tomando en cuenta dos escenarios de recuperación:
    • Sitio Producción Monterrey no disponible, Producción direccionada a Querétaro.
    • Sitio Producción Querétaro no disponible, Producción direccionada a Monterrey.
      • Aplicativos que utilizan Procesamiento desde Monterrey y Querétaro, lo que haría complicada la recuperación si se realizara desde cualquier sitio mencionado.
      • Comunicaciones configuradas que actualmente no son capaces de realizar un Switcheo a una red de Recuperación que permita homologar las configuraciones IPs que actualmente los Aplicativos mantienen en su código interno (Hard Code) y dentro de las mismas Bases de datos (como usuarios y passwords de servicio)
      •  Enlace de Comunicaciones que es utilizado para únicamente comunicar los sitios de trabajo, pero no se cuenta con un enlace dedicado para los Servicios de Resiliencia.
      • Se requiere de espacio suficiente, así como las instalaciones eléctricas, de red, racks entre otros requerimientos físicos, para alojar la infraestructura requerida para recuperar los aplicativos críticos del negocio.
      • No se cuenta con infraestructura de respaldos y restauraciones homologadas en ambos sitios preparada para realizar este tipo de actividades de Resiliencia; además se debe implementar la estrategia de tal modo que se pueda realizar dicha actividad sea en Triara Monterrey o Triara Querétaro.
      • No se tiene un esquema de resguardo de cintas de respaldos de información crítica en un sitio alterno fuera de los centros de datos.
      • No se tiene un esquema de traslado de cintas de un sitio a otro con fines de recuperar datos en el sitio de producción diferente.
      • En caso de contar con Infraestructura en alguno de los sitios como Monterrey y Querétaro, se deberá considerar una administración distinta a la actual, con red distinta y deberá contar con el proceso de cambios implementado para hacer los ajustes que se requieran una vez aplicados en Producción y que estén alineados a la infraestructura que se utilizaría para Recuperación.
      •  No se cuenta con infraestructura dedicada, en línea para recuperarse, misma que deberá estar alineada al RTO establecido.
  5. No se cuenta con réplica de datos, por lo que la estrategia actual de respaldos se vería muy limitada para cumplir con los requerimientos que marca el negocio dentro de los tiempos de punto de recuperación (RPO´s) y el objetivo de recuperación (RTOs). Ello a su vez, comprometería la reputación de la empresa con la posibilidad de ocurrencia alta en los Impactos al Negocio que ya se mostraron en el BIA (Business Impact Analisys, por sus siglas en inglés).
  6. Se utilizó la información previamente validada del BIA, relacionada a los periodos de interrupción, prioridades de recuperación, usuarios responsables, impactos por la no disponibilidad; que son la base para el desarrollo de las mejores estrategias de recuperación; ésta información se deberá confirmar por parte del Negocio.
  7. El Negocio deberá contemplar los insumos requeridos mostrados dentro del Plan de Recuperación para Desastres, para que pueda contar con una recuperación real de servicios requerida por el Negocio. Deberá considerar:
    • Un sitio de Recuperación Alterno (Hot Site o Sitio Caliente)
    • Enlaces y comunicaciones configuradas para el Sitio e Infraestructura de Recuperación ante contingencias.
    • Réplica de Información crítica en modo síncrono que refleje cambios realizados desde el sitio de Producción, al Sitio de Recuperación; entre las que como SME identifico son en modo general:
      • Bases de datos críticas
      • Equipos o configuraciones virtuales
      •   File Systems o Repositorios que utilizan los aplicativos críticos para operar y funcionar correctamente (procesos temporales, localización de archivos de sistema, etc).
    • Infraestructura dedicada donde residan los Sistemas Operativos, Software, Configuraciones, así como accesos especiales como VPN, replica de LDAP y/o Directorio Activo.
    • Procesos de Cambios y Configuraciones que permita controlar por medio de proceso, los cambios que se realicen en Producción y afecten el Sitio e Infraestructura de Recuperación, para que ambos sitios se encuentren en perfecto mantenimiento. A su vez, monitoreo dedicado para la infraestructura de recuperación que complementará éste mantenimiento de tal forma que el sitio de recuperación esté listo para cuando el negocio lo requiera.
  8. Recomiendo tener el Sitio de Recuperación en Tiempo Real (Sitio Caliente), dado que el aplicativo a nivel Negocio y de acuerdo al BIA, demandan cumplir con los RTOs y RPOs definidos en ése análisis. Esta configuración permitirá al Negocio estar alineado con su estrategia de Continuidad, evitando las pérdidas que ya se evaluaron en el BIA, mismas que impactarán directamente al Negocio.
  9. Se debe considerar que no se puede diseñar un Plan de Recuperación en caso de Desastres, debido a los insumos que no se tienen y por ende, no pudiéramos documentarlo apropiadamente de modo que se lleguen a recuperar los requerimientos del Negocio establecidos en el BIA.
  10. Finalmente, se propone realizar un ejercicio de respaldos, el cual consistirá en tomar los tiempos reales que las bases de datos críticas identificadas en la Estrategia de Recuperación, así como los equipos con su información de aplicativo. Esta información será entregada al Negocio como evidencia del tiempo real que se toman a partir de los respaldos efectuados al momento y éstos sean comparados con los tiempos que el negocio requiere referenciados en el BIA.

Finalmente, confirmo que de estas experiencias vividas, es que nada está escrito. Cada profesional de Continuidad de Negocio generará sus propias experiencias, lo que hará más rico el contenido de lo que se vive en esta sorprendente carrera. Sin duda, siempre saldrán cosas nuevas que aprender, aunque el común denominador es, para las lecciones aprendidas, documentar todo ello y no dejar de revisarlas, puesto que algo nos servirá, para mitigar los riesgos de ejecución durante nuestras actividades de resiliencia.


Inline image 1Adrian Sanchez V holds the Informatics Degree with current Master of Managing e-Commerce in progress. Adrian is certified in the following specialties: ITIL, IT Specialist, ISO27001 LI and Business Continuity Professional, with more than 19 years of experience in the Information Technology industry. Adrian has worked for several Companies as Manager and Leader, such as Delivery Services, Assurance, Bank, Pharmaceutical and others sectors in the IT department and supporting complex projects.  Additionally, Adrian is working as Subject Matter Expert, building several solutions for customers, and Business Continuity and Disaster Recovery Consultant. Adrian’s goal is to keep all IT Services, using best practices, in a good shape of Work, Operations and Management, Providing and achieving all Business Targets and Objectives, aligned with the Mission and Company Values.


Image: “Risk down arrow” by Jagbirlehl – Own work. Licensed under CC BY-SA 3.0 via Wikimedia Commons -https://commons.wikimedia.org/wiki/File:Risk_down_arrow.png#/media/File:Risk_down_arrow.png

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s