1. Educación

CÓMO SUSTENTAR UN PLAN DE RECUPERACIÓN DE DESASTRES
Por Diego Fernández, Solution Strategist de CA Technologies.
Fuente: Revista Gerencia
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.
PARTE I.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.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
1
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.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
2
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
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
3
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.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
4
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.
PARTE II.-
En el artículo anterior mencionamos que las organizaciones deben enfrentar la generación de
sus planes de recuperación de desastres con la certeza de que ocurrirá uno. Es por esto que las
empresas deben repensar su estrategia proteccionista y cambiarla por una dinámica con la
mirada puesta en la recuperación de sus procesos.
Para esto comenzamos a estudiar el desarrollo de la gestión de los planes de recuperación de
desastres a través de las perspectivas propuestas por ITIL versión 3. Mencionamos en el artículo
anterior que es necesario mantener una visión del área de TI que esté a la par de la gestión del
negocio, por este motivo observamos que en el segundo apartado de ITIL v3 se proponen guías
para el diseño del servicio desde una perspectiva de negocio.
Antes de comenzar enumeremos las cincos guías propuestas por ITIL v3:
1. Estrategia del Servicio.
2. Diseño del Servicio.
3. Transición del Servicio.
4. Operación del Servicio.
5. Mejora Continua del Servicio.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
5
DISEÑO DEL SERVICIO
En la definición de la estrategia del servicio comenzamos a analizar cuáles son los procesos
críticos de la organización y detectamos el correspondiente MTD (Maximun Tolerable Downtime)
para cada proceso.
Durante la etapa de “diseño del servicio” estaremos llevando a la práctica los distintos
procedimientos para la implementación y gestión del
plan de recuperación de desastres. En esta fase es
necesario ya contar con el “plan provisorio de
emergencia”, el cual comprenderá herramientas de
respaldo y continuidad de datos que permiten proteger,
provisoriamente, los sistemas que soportan los
procesos críticos de la organización. Estas nos deben permitir obtener información relevante de
la infraestructura, como así también deben tener la capacidad de escalar en la incorporación de
nuevos servicios a proteger.
Durante esta serie de artículos insistiré en la necesidad de tener una visión integral de la
organización y daremos respuestas que sean integradoras. Por ese motivo una vez que se haya
identificado un servicio a ofrecer debemos analizar la viabilidad tomando en cuenta factores
como la infraestructura, el personal, la cultura de la organización, y las distintas sub-culturas. En
el diseño estaremos optando por los distintos métodos de capacitación al personal en aspectos
como la seguridad y la prevención ante desastres.
Cuando se diseñen los servicios se debe tomar en cuenta el dinamismo actual que tienen las
organizaciones y por este motivo se debe comprender la eventual rotación de roles, despidos,
contrataciones, etc. Debemos entender el crecimiento y cambio de la infraestructura y del
software con el que trabajaremos.
Durante el diseño del servicio atravesaremos los siguientes procesos:
1. Gestión del Catálogo de Servicios: Este proporcionará una referencia estratégica y técnica
clave dentro de la organización. Como vimos en el artículo anterior utilizaremos la información
recolectada en el BIA (Business Impact Analisys) para construir un mapa que describa
detalladamente los servicios que se prestan y los recursos asignados para éstos.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
6
Este catálogo de servicios incluirá la información sobre todos los servicios que se hayan
prestado alguna vez o los que prestará la organización. Claramente servirá también para
delimitar las funciones y compromisos de TI.
2.Gestión de Niveles de Servicio: Las actividades y objetivos de los procesos de la Gestión del
Nivel de Servicios (SLM, Service Level Management) son esencialmente idénticos en ITIL V2 y
V3. ITIL V3 clasifica la SLM dentro del área de diseño del servicio, mientras que las actividades
de la revisión de servicios se encuentran en el perfeccionamiento continuo de éste.
El proceso ITIL V3 Gestión del Nivel de Servicio (SLM) abarca los siguientes subprocesos:
Mantenimiento de infraestructura de SLM.
Inscripción de clientes en servicios estándar.
Identificación de requisitos de servicio.
Descomposición del servicio de negocio en servicios de soporte.
Diseño técnico y organizativo del servicio.
Compilación y presentación de la solicitud de cambio.
Firma de acuerdos y activación del servicio.
Monitoreo e informes del nivel de servicio.
3. Gestión de la Disponibilidad: Este proceso es el responsable del monitoreo y optimización
de los servicios de TI para que funcionen ininterrumpidamente y de manera confiable según los
SLA establecidos. Los planes de disponibilidad deben ajustarse a los planes reales del negocio;
los niveles de disponibilidad que se establecerán aquí serán claramente superiores a los
establecidos en el plan provisorio de emergencia, pero es altamente recomendable utilizar la
misma herramienta de gestión en una u otra etapa.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
7
La gestión de la disponibilidad debe contar con indicadores que
sustenten el trabajo, es por esto que las herramientas elegidas para
realizar los procesos de continuidad de información deben contar
con la capacidad de generar reportes y análisis de tiempo real que
permitan ver:
Disponibilidad: Porcentaje de tiempo sobre el total acordado en que los servicios TI han
sido accesibles al usuario y han funcionado correctamente.
Fiabilidad: Medida del tiempo durante el cual los servicios han funcionado correctamente
de forma ininterrumpida.
Mantenibilidad: Capacidad de mantener el servicio operativo y recuperarlo en caso de
interrupción.
Capacidad de servicio: Determina la disponibilidad de los servicios internos y externos
contratados y su adecuación a los OLAs y UCs en vigor. Cuando un servicio TI es
subcontratado en su totalidad la disponibilidad y la capacidad de servicio son términos
equivalentes.
Queda mucho camino por recorrer en el proceso de conformación de un plan de recuperación de
desastres sustentable.
Está claro que es fundamental seleccionar herramientas de gestión de TI que permitan escalar
de manera flexible en la adopción de nuevos procesos y procedimientos según cambie el
negocio.
Adoptar sistemas continuidad de aplicaciones y respaldo de información es una tarea que debe
estar comprometida con el negocio y no sujeta al hardware existente. La historia indica que
quienes han adoptado soluciones de resguardo condicionadas por un hardware en particular
debieron descartar su plan de recuperación de desastres o el producto de respaldo o continuidad
elegido.
La clave está en la elección de software crossplatform, independientemente de hardware, que
permita gestionar los procesos y procedimientos mencionados en los párrafos anteriores.
¿Su organización está preparada para el siguiente desastre?
PARTE III.Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
8
Hemos revisado los primeros 2 puntos de las 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.
Es momento ahora de abordar algunos elementos de la “transición del servicio”, “operación del
servicio” y la “mejora continua del servicio”.
Aquí es donde vemos la necesidad clara de contar con herramientas para automatizar la
recuperación de diversos elementos, como aplicaciones, bases de datos o sistemas completos.
Durante la planificación de la transición del servicio se establece cómo se desea que se
recuperen las aplicaciones tras una caída, y también se deben preparar los planes de “rollback”
(reversión) junto con sus respectivas pruebas.
Es común contar con soluciones de backup que apoyen el resguardo de la información, pero en
esta etapa es recomendable analizar herramientas de replicación y alta disponibilidad que
puedan trabajar en distintas capas de los procesos a proteger. La transición del servicio no debe
contemplar solamente las fallas completas de los sistemas, sino también la respuesta ante fallas
particulares de distintos elementos de estos sistemas. Por ese motivo es correcto pensar que
cuando una organización se encuentra ante un proceso crítico, con un MTD (Maximun Tolerable
Downtime) igual a 0, se deben realizar tareas de replicación y alta disponibilidad del mismo. De
ser posible es necesario contar con un sitio de contingencia que permita ejecutar este proceso
frente a una caída del sitio principal.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
9
Analizando un ejemplo
Veamos el siguiente ejemplo: La organización “A” en el año 2010 adquiere dos dispositivos de
almacenamiento del fabricante “X” para que trabajen en redundancia replicando datos entre los
sitios remotos. En el año 2012 el fabricante “X” descontinúa estos equipos y cambia su estrategia
de negocio a otra línea por lo que deja de desarrollar estos equipos. En el año 2013 la
organización “A” sufre un desastre en su sitio principal por lo que comienza a operar en el sitio
de contingencia.
Hasta aquí podemos pensar que el plan de recuperación ha sido un éxito, sin embargo, un plan
de recuperación debe contemplar la transición al funcionamiento normal de las operaciones. Esto
quiere decir, recuperar el sitio principal.
En el ejemplo la organización “A” adquiere un hardware de un fabricante “X”, el cual ahora ya no
cuenta con equipos del mismo modelo. Aquí vemos el olvido más grande que suele existir en
este tipo de planes: manejo de proveedores, o sea flexibilidad. En el ejemplo, la organización “A”
quedó comprometida al trabajo con un único proveedor, no tiene flexibilidad y éste es un error
grave en la planificación de un plan de recuperación de desastres.
Cuando esté pensando en incorporar una solución de replicación debe contemplar que pueda
contar con la capacidad de trabajar con múltiples proveedores de hardware, software, etc.
A considerar
La implementación de una solución de replicación y alta disponibilidad deberá respetar los
siguientes ítems:
1) Integración con la aplicación a replicar: Optar por soluciones que trabajen a nivel de
aplicación permite manejar mejores estándares de seguridad y optimizar el tiempo y la velocidad
de replicación.
2) Flexibilidad ante el cambio: Todas las soluciones deben permitir realizar modificaciones de
manera de poder adaptarse a los cambios de la infraestructura y del negocio. Siempre se debe
tomar en cuenta la gestión centralizada y de la solución. Por este motivo no es recomendable
contar con múltiples herramientas de replicación y alta disponibilidad según la aplicación o
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
10
hardware. Tampoco podemos ajustarnos a soluciones de nicho. Tenga una mirada integral,
piense en el futuro, analice su historia y las tendencias. Y, por sobre todo, contemple la mayor
cantidad de situaciones inesperadas.
3) Gestión del conocimiento: Recuerde que un plan de recuperación de desastres debe tener
una mirada integral de la organización. Planifique y estructure según la cultura de quienes
componen la organización. Eduque y forme pensamiento nuevo. Seguramente usted está
pensando en realizar un curso o entrenamiento para los empleados… éste es el camino difícil,
primero, seleccione herramientas intuitivas, simples; luego de los conocimientos.
4) Planificación y apoyo a la transición: Recuerde que un DRP óptimo es aquél que le permita
automatizar la recuperación de los procesos más importantes de manera automática. Es muy
probable que hoy no esté evaluando una situación de replicación o alta disponibilidad porque
piensa que puede restaurar un servidor en unas pocas horas ante un problema. En el momento
en que ocurre un desastre es probable que múltiples equipos y aplicaciones sufran daños,
¿podrá usted realizar manualmente la recuperación de todos los equipos en el tiempo que ahora
prevé? Cuanto más automática sea la recuperación más tiempo para análisis y control tendrá;
con esto podrá realizar acciones mucho más eficaces.
5) Implementación: Recuerde que todo proceso automático debe ser factible de transformarse
en manual de manera fácil. Revise y organice todos los pasos previos a la recuperación de sus
sistemas.
6) Gestión de pruebas: Todos los procedimientos tienen que ser medibles. Establezca cómo
deberá testear sus herramientas, quién debe hacer las pruebas, y cuáles son los resultados que
se esperan. También debe establecer qué debe hacerse ante los distintos resultados.
Recuerde que las herramientas que soportan los planes de recuperación ante desastres deben
ser flexibles y poder adaptarse con comodidad a los cambios que las compañías sufren día a
día.
El último punto a tener en cuenta en la conformación de su DRP es la operación del servicio.
Aquí usted deberá trabajar sobre el monitoreo activo y pasivo de los servicios, el registro de
eventos, incidencias, problemas, y acceso al servicio.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
11
Para finalizar recuerde trabajar la planificación de un DRP con la certeza de que un desastre
sucederá, no planifique pensando que un desastre puede suceder. Esta forma de pensar lo
expondrá críticamente ante la problemática.
Marín N° 0586 – Providencia/ Mesa Central: +56 (2) 496 69 00 - Fax: +56 (2) 496 69 10
Ventas: [email protected] /Casilla de Reclamos: [email protected]
12