Juan Zúñiga
La sustentación de un Plan de Recuperación de Desastres (DRP) de una organización se obtiene mediante la aceptación de que los desastres ocurren. Esta afirmación nos permite comenzar a trabajar proactivamente en la mitigación del riesgo, pero siempre a la espera de que este suceda. Es por esto que las empresas deben repensar su estrategia proteccionista por una estrategia dinámica con la mirada puesta en la recuperación de sus procesos.
Los últimos años hemos transitado por una serie de eventos que permiten analizar con profundidad la ejecución de los planes de recuperación en Latinoamérica; pero más aún: hemos observado con claridad el desempeño de los negocios y su evolución posterior a los desastres. Seguramente usted esté pensando que las organizaciones deben procurar que su tiempo de recuperación ante un desastre debe estar cercano a cero; y aquí vemos el primer problema. Si usted no pensó en el circuito de proveedores y en cómo sus clientes adquieren sus productos o servicios luego de un desastre, seguramente tendrá su empresa funcionando, pero sin clientes a quien vender sus productos ni donde abastecerse de recursos luego del desastre.
En el anecdótico párrafo anterior ilustro cómo se debe realizar la correcta planificación de un Plan de Recuperación de Desastres; esto es, una planificación integral pensada en la ejecución de sus procesos.
La Biblioteca de Infraestructura de TI versión 2 (ITIL v2) nos propone una serie de documentos orientados a la ejecución de procesos propios de TI como detallo a continuación:
Gestión de Servicios de TI:
1.Mejores prácticas para la provisión de servicio.
2.Mejores prácticas para el soporte de servicio.
Otras guías operativas:
3.Gestión de la infraestructura de TI.
4.Gestión de la seguridad.
5.Perspectiva de negocio.
6.Gestión de aplicaciones.
7.Gestión de activos de software.
Sin embargo estas guías proponían, sin querer, la visión del área de TI un poco lejos de la gestión del negocio. Por este motivo, en la tercera revisión de ITIL se pretendió adquirir un mayor vínculo de TI con el negocio de la organización, redactándose 5 guías pensando en los servicios que TI ofrece a la organización:
1.Estrategia del servicio.
2.Diseño del servicio.
3.Transición del servicio.
4.Operación del servicio.
5.Mejora continua del servicio.
Con el estudio de estas guías obtendremos una mejor comprensión del área de TI y el negocio, y fundamentalmente comenzaremos a pensar en función de procesos y servicios.
Estrategia del servicio
Si comenzamos a analizar la estrategia de servicio nos toparemos con las primeras preguntas de la composición de un Plan de Recuperación de Desastres. Una de estas es: ¿Conoce el tiempo máximo que puede estar sin ejecutar un proceso determinado sin que su empresa sufra daños irreversibles?
Esta pregunta declara cuál es el foco de negocio, y delimita los procesos vitales de la organización. Este proceso se conoce como el cálculo del MTD (Maximun Tolerable Downtime), el mismo se debe obtener por cada proceso detectado en el párrafo anterior.
Si logramos avanzar en estos tipos de preguntas estaremos en condiciones de proponer la conformación de un BIA (Business Impact Analisis) para la organización, documento que identificará los eventos que afectan la continuidad de los procesos e incluirá un análisis profundo de estos.
Las normas ISO:27001, ISO:27002, ISO:27005, ISO:20000, Cobit 4.1, COSO, ITIL V3 y BS 25999, entre otras, nos permitirán establecer una ruta estratégica que ofrezca a la organización la capacidad para estar mejor preparada ante un entorno cambiante y de alto riesgo.
Plan Provisorio de Emergencia
Comencé este artículo mencionando que uno debería comenzar a trabajar en su Plan de Recuperación de Desastres con la convicción de que el desastre puede ocurrir. De esta manera, es fundamental que desde el minuto cero de la planificación del mismo, comencemos a trabajar en la reducción de la mitigación de los efectos que puedan ocurrir tras un desastre que suceda durante la planeación del propio DRP. Es por esto que se debe comenzar con un Plan Provisorio de Emergencia. Al momento de destinar fondos para la conformación de un Plan Provisorio de Emergencia se debe justificar que los elementos que se adquieran durante el mismo serán flexibles y escalables a la solución final.
Como analista de TI tenemos el deber de poner nuestra mirada en la continuidad del negocio, por eso es vital que se ponga en marcha el Plan Provisorio de Emergencia con una visión mucho más liviana de los puntos de recuperación y el tiempo de recuperación de los sistemas que en un DRP. En paralelo es posible continuar con el BIA, el cual actualizará dinámicamente el Plan Provisorio de Emergencia ajustándolo a recuperar los procesos que se van descubriendo como críticos.
Este proceso puede estar conformado por las siguientes tareas:
1.Obtener información por medio de entrevistas o encuestas.
2.Obtener información financiera del impacto en caso de afectarse un proceso de negocio.
3.Realizar un estudio detallado de la información obtenida.
4.Determinar tiempos críticos de aplicaciones, procesos de negocio y recursos o servicios.
5.Calcular los MTD.
6.Priorizar las operaciones de recuperación con base en la anterior información recolectada.
7.La anterior información recolectada debe ser documentada adecuadamente con el fin de ser parte del DRP.
Sin duda nos encontramos en un momento histórico del “management de TI”, donde las organizaciones han redescubierto la importancia de estas áreas gracias a que se ha repensado a TI como un sector que provee servicios concretos al negocio. Usted puede comenzar a preparar a su empresa para pensar en su DRP, tal vez hoy solo pueda alcanzar la conformación de un Plan Provisorio de Emergencia; pero seguramente debe incorporar soluciones de recuperación que sean flexibles y permitan actualizaciones dinámicas, que no condenen a su organización a trabajar con un único proveedor de hardware.
Sustentar un Plan de Recuperación de Desastres dentro de una organización depende del correcto planteamiento del problema: ocurrirá un desastre y la forma de abordar este problema es pensar en los métodos de recuperación de los procesos. Seguramente en futuros artículos podremos extendernos más en este tema. Ahora le propongo que revise su estrategia de backup y piense en su plan de recuperación. En arcserve estamos dispuestos a pensar junto a usted cómo deberían ser los caminos de implementación de estas estrategias, incorporando nuestras soluciones de recuperación según su RPO o RTO.
