Recuperación de desastres informáticos: Diseñe deseando lo mejor, en función de esperar lo peor

Escrito por: Randall Cruz, Partner Systems Engineer, CCA

Dado que el tema de desastres informáticos y sus acciones preventivas es en extremo amplio, he decidido abordarlo en dos partes. Esta primera entrega tiene como objetivo dar un visión general de cómo mitigar las omisiones más frecuentes en este tipo de proyectos, así como aclarar varios conceptos que se siguen empleando de forma errónea tanto del lado de la organización como del proveedor de la solución.

Definición de Desastre

Para los propósitos de este artículo, definiéremos un desastre como un evento no planificado que inhabilita el centro de datos de la organización, a prestar los servicios necesarios para seguir operando de forma normal. Condiciones que podrían ser declaradas como desastres incluyen eventos de la naturaleza  como huracanes, inundaciones, terremotos, incendios y otros. O eventos causados por el hombre como sabotaje, fraude, terrorismo y ataques maliciosos, entre otros, que al final causen daños a la infraestructura de cómputo.

Según los datos reportados en Grupo Albe, algunas de las causas de las pérdidas de datos son debido a:

Otra estadística por la Boston Computing Network  menciona lo siguiente:

• 6% las PC’s sufren algún evento de pérdida de datos en cualquier año.
• 30% de todas las empresas que tienen un gran incendio se queden fuera del mercado en un año.
• 34% de las empresas no logran probar sus copias de seguridad en cinta, y de las que sí lo hacen, el 77% han encontrado problemas en éstas.
• 60% de las empresas que pierden sus datos cerrarán dentro de los siguientes 6 meses después del desastre.
• Las empresas que no son capaces de reanudar sus operaciones dentro de los diez días siguientes de un desastre, no es probable que sobrevivan.
• Cada semana 140,000 discos duros dejan de funcionar en los Estados Unidos.

Para reducir estos eventos y controlarlos hasta cierto grado, se hace necesaria la intervención del Equipo de Evaluación de Desastres o en su efecto de un Comité de Riesgos: esta entidad interna será la que evaluará los daños de los activos físicos y de las capacidades funcionales del centro de datos en la eventualidad de un desastre, para posteriormente emitir un reporte al Equipo Ejecutivo, el cual en conjunto con otra información disponible tomará la decisión respecto a la declaratoria formal del desastre.

Cuestión Multidisciplinaria

Muchos altos ejecutivos consideran que la continuidad de una organización es responsabilidad del departamento de TI. Sin embargo, ya no es suficiente ni práctico que la responsabilidad recaiga sólo en TI. Un plan de recuperación no es un proceso estrictamente técnico, sino todo lo contrario, ya que hay un alto componente de procesos humanos involucrados en él. Por lo tanto, todos los ejecutivos, directores y empleados deben participar en el desarrollo, implantación y soporte permanente de la evaluación y planificación de la continuidad.

Los directivos de la organización deben tomar la decisión de emprender el plan de recuperación como un proyecto en sí mismo, previo a decidir qué estrategia van emplear, para así poder satisfacer los siguientes pre-requisitos de carácter mandatorio:

1. Determinar la vulnerabilidad a las interrupciones del servicio importantes en el centro de datos e instalaciones de la organización a fin de definir las medidas preventivas que se pueden tomar para reducir al mínimo la probabilidad y el impacto de una interrupción en el servicio.
2. Identificar y analizar el costo e impacto en la imagen pública así como otras consecuencias de las interrupciones prolongadas del servicio en el centro de datos y otras instalaciones empresariales.
3. Determinar las necesidades inmediatas, a medio y largo plazo, de recuperación y los recursos necesarios.
4. Identificar las alternativas  y seleccionar los métodos más rentables para proporcionar la función de las operaciones de copia de seguridad y la restauración de un servicio a tiempo.
5. Desarrollar e implementar planes de contingencia que se ocupan de las necesidades inmediatas y de largo plazo para el centro de datos y otros servicios empresariales.

Algo importante de tener en mente, es que TI es el ejecutor de la estrategias y procedimientos definidos por el ente interno, en pro de aplacar los efectos inmediatos de un fortuito que esté impactando las operaciones normales de la organización. Por consiguiente debe quedar claro que sólo el Equipo Ejecutivo tiene la autoridad de declarar un desastre.

RTO / RPO y su rol en un plan de desastres informáticos

En muchas ocasiones, durante el desarrollo del procesos de consultoría pude evidenciar la falta de claridad en estos dos conceptos, que en términos prácticos lo que buscan es minimizar el tiempo de inactividad y la pérdida significativa de las aplicaciones de misión crítica. RPO y RTO son conceptos fundamentales fáciles de entender y con base en ellos se puede planificar y decidir qué tipo de soluciones son necesarias para cada organización:

• Objetivo de Tiempo de Recuperación (RTO, Recovery Time Objective) es el tiempo en el que los procesos, servicios y aplicaciones deben estar restaurados después de un incidente grave, con el fin de evitar consecuencias inaceptables derivadas de una ruptura en la continuidad del negocio. En pro de reducir el valor de RTO lo más cercano a cero, se requiere que la Infraestructura tecnológica, logística, humana y física esté disponible en el menor tiempo posible pasado el evento de interrupción.

• Objetivo de Punto de Recuperación (RPO, Recovery Point Objective) es la cantidad y vigencia de la información que se deben recuperar del almacenamiento alterno, copia de cinta, copia de seguridad, etc. tras un incidente grave. El RPO se expresa hacia atrás en el tiempo desde el momento en que el incidente se produce, y puede ser especificado en segundos, minutos, horas o días, por lo tanto, es la cantidad máxima aceptable de pérdida de los datos medidos en el tiempo. Para reducir ese valor lo más cercano a cero es necesario aumentar el sincronismo en la réplica de datos. Ejemplo: La replicación a nivel de los sistemas de almacenamiento es capaz de ofrecer un RTO cercano o igual a cero.

El siguiente gráfico muestra la relación entre el RTO / RPO en un función del tiempo donde se hace la declaratoria de una emergencia informática o desastre.

Diagrama – RTO / RPO

El RTO / RPO por sí solos no indican nada. Estos umbrales tienen que ser extrapolados a las aplicaciones que realmente son vitales y críticas para la organización. De allí nace la necesidad de contar con un procedimiento que permita filtrar y perfilar qué servicios se ven directamente impactados por estas variables, que de paso permitirán definir los diferentes niveles o Tiers de las aplicaciones de la organización. Esos niveles van definidos del Tier 1 al Tier 4, siendo el Tier 1 el que contiene las aplicaciones que deben tener la prioridad de parte de los entes internos encargados de diseñar el proyecto. La correcta clasificación de los servicios y aplicaciones finalmente darán forma a los procesos de failolver y failback, típicos de un plan de desastres informáticos.

La siguiente tabla es una herramienta que permite de una forma simple y precisa clasificar las aplicaciones y servicios en función de las variables de RTO y RPO de las organizaciones para así dar forma al borrador inicial del plan a ser revisado, evaluado y aprobado por el Comité de Riegos de la organización:

1. Nivel #1: Apps responsables de forma directa de la generación de ingresos de la organización (Color Verde). Impacto alto.
2. Nivel #2: Apps que poseen importancia, sin embargo no impactan de forma sensible las operaciones empresariales (Color Morado). Impacto moderado.
3. Nivel #3: Apps de monitoreo y administración de la plataforma de TI (Color Amarillo). Impacto leve.
4. Nivel #4: Apps de ambientes de QA, desarrollo y pruebas (Color Celeste). Impacto bajo.

Diferencias entre plan de recuperación ante desastres (DRP), plan de recuperación de negocio (BRP) y plan de continuidad de negocio (BCP)

Me he encontrado en numerosas ocasiones con que se tiende a confundir estos tres conceptos y se manejan indistintamente como uno sólo, pero en realidad existen aspectos que los diferencian entre sí:

• Partamos por el Plan de Recuperación ante Desastres o DRP por sus siglas en inglés, el cual establece las acciones que deberán ejecutarse para recuperar las operaciones fundamentales de una organización tras un desastre. Este plan debe incluir también las medidas para evitar determinados riesgos, mitigarlos o transferirlos a terceras partes. El DRP por lo general suele enfocarse primariamente en la recuperación de las operaciones relacionadas con el procesamiento de información.

• El Plan de Recuperación de Negocio o BRP es una extensión del Plan de Recuperación ante Desastres porque además de lo antes mencionado, incluye las acciones necesarias relacionadas con proveedores y clientes que el DRP no aborda.
• El Plan de Continuidad de Negocio o BCP es el más global y se compone a su vez de múltiples planes que describen cómo la organización puede operar de manera total o de forma degradada durante o inmediatamente después de un desastre. El BCP debe describir cómo gestionar cualquier incidencia que afecte a la organización y que interrumpa o detenga su desempeño normal; no sólo grandes desastres.

Aspectos adicionales como por ejemplo, una falla en el enfriamiento del centro de datos, fallas en los UPS u otros elementos, pueden ser eventos importantes pero no podemos pretender que el BCP defina el paso a paso de cómo resolver cada eventualidad. Sin embargo sí deberá dar las pautas de cómo proceder mientras se escala el problema a quien le corresponda resolverlo.

Conclusiones

A manera de conclusión de esta primera parte, podemos destacar los grandes beneficios que se pueden obtener a partir de la elaboración de un apropiado plan de recuperación de desastres informáticos. Es de carácter vital para todas las organizaciones el poder impleméntalo para así amortiguar y minimizar los efectos nefastos que a nivel operativo, financiero y de imagen se pueden llegar a experimentar.

Por otra parte del componente tecnológico en el proyecto no es suficiente, el verdadero éxito en la implementación de un plan de recuperación lo determina el nivel de apoyo y compromiso del Comité de Riesgos y de Equipo Ejecutivo para cumplir con las prácticas aplicables del Código de Mejores Prácticas Corporativas. Ha quedado claro que la creación de un plan es una tarea muy amplia y en extremo compleja, más de lo que la mayoría imagina.

Como conclusión final, debemos tener en mente que cuando una organización va creciendo gracias al apoyo de la tecnología y va tomando las medidas necesarias para proteger su información (su bien más preciado) y establece las estrategias pertinentes mediante un plan de recuperación en caso de alguna contingencia, podrá asegurar la continuidad de sus servicios y asegurar la atención de sus clientes, manteniéndose al día con la exigencia de su mercado.

Para obtener más información acerca de VMware, visite nuestros sitios web de Argentina, Chile, Colombia, México, Perú, Venezuela y otros países. También puede seguirnos en Facebook, Twitter y Youtube para enterarse de las últimas novedades.

Contacte VMware aquí.