La sustentación de un plan de recuperación de desastre (DRP – Disaster Recovery Plan) 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 de que ocurra un desastre, pero siempre a la espera de que éste suceda. Es por esto que las empresas deben repensar su estrategia proteccionista por una 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 esté cercano a cero, y aquí vemos el primer problema: si usted no consideró el circuito de proveedores, y cómo sus clientes adquieren sus productos o servicios luego de un desastre, seguramente tendrá a su empresa funcionando y sin clientes a quien vender sus productos, o bien carezca de recursos donde abastecerse luego de esta contingencia.
En el anecdótico párrafo anterior ilustramos 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.
Pensar en función de procesos y servicios
La Biblioteca de Infraestructura de TI versión 2 (ITIL v2) nos proponía una serie de documentos que estaban 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
1. Gestión de la infraestructura de TI.
2. Gestión de la seguridad.
3. Perspectiva de negocio.
4. Gestión de aplicaciones.
5. 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 pretendía adquirir un mayor vínculo de la tecnología con el negocio de la organización y por esta razón se redactaron cinco guías pensando en los servicios que TI ofrece a ésta:
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 la primera pregunta de la composición de un plan de recuperación de desastres, que es: ¿Conoce el tiempo máximo que puede estar sin que se ejecute 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 estas preguntas estaremos en condiciones de proponer la conformación de un BIA (Business Impact Analysis). El BIA es un documento que identificará los eventos que afectan la continuidad de los procesos de la organización e incluirá un análisis profundo.
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.
Comencé este artículo mencionando que uno debería empezar a trabajar en su plan de recuperación de desastres con la convicción de que éste 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 generarse tras un desastre que ocurra durante esta planificación. Es por esto que se debe comenzar con un plan provisorio de emergencia.
Al momento de destinar fondos para la conformación de éste, se debe justificar que los elementos que se adquieran durante el mismo serán flexibles y escalables a la solución final.
Muchas veces los clientes adquieren soluciones para responder a necesidades inmediatas y emergentes durante estos planes provisorios de emergencia y luego descubren que estas herramientas comienzan a recolectar información de los servicios que nos serán vitales al momento de la conformación del BIA. Desde ya algunas soluciones pretenderán responder de forma automática ante un desastre habilitando los servicios en el sitio de contingencia, ya sea que esté próximo al sitio del desastre, a miles de kilómetros o en la nube.
Como analistas 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 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:
• Obtener información por medio de entrevistas o encuestas.
• Obtener información financiera del impacto en caso de afectarse un proceso de negocio.
• Estudio detallado de la información obtenida.
• Determinar tiempos críticos de aplicaciones, procesos de negocio y recursos o servicios.
• Calcular los MTD.
• Priorizar las operaciones de recuperación con base en la anterior información recolectada.
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. Hoy usted puede comenzar a preparar a su compañía para pensar en su DRP, tal vez hoy sólo pueda alcanzar la conformación de un plan provisorio de emergencia; pero seguramente debe incorporar soluciones de recuperación que sean flexibles, permitan actualizaciones dinámicas, y que no condenen a su organización a trabajar con un único proveedor de hardware, etc.
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 correcta de abordar este problema es pensar en los métodos de recuperación de los procesos.
