Cuando se trata de asegurar la disponibilidad del centro de datos para la continuidad de la operación de la empresa, se abre una brecha entre los requisitos del Always-On Enterprise y la capacidad del área de TI para satisfacer de forma efectiva dichos requisitos en la recuperación ante desastres.
Suelen haber brechas en las capacidades de la infraestructura tecnológica, pero también en la manera en que se abordan las situaciones de crisis. En este artículo identificaremos algunas omisiones comunes que pueden crear esas brechas en la estrategia de disponibilidad de los negocios.
1. Las aplicaciones son más de lo que aparentan. Por ejemplo, un servidor de correo electrónico por sí solo no es una aplicación. Un sistema de correo electrónico como Microsoft Exchange es un conjunto de muchas cosas en el centro de datos, esto incluye servicios de red (DNS y otra infraestructura), Active Directory (mecanismo de autenticación) y usuarios con terminales que se conectan al servicio. La omisión común es tener datos fuera del sitio en una situación de recuperación ante desastres, aunque las compañías pueden determinar que no son completamente utilizables cuando se consideran todos los requisitos.
2. La comunicación es necesaria. Cuando las compañías necesitan recuperarse después de un incidente, contar con comunicaciones disponibles es lo primero. Los empleados tendrán dificultades para operar en caso de fallas sin su principal medio de comunicación (los sistemas de correo electrónico de la compañía). Esta situación empeora si se desarrollaron otras aplicaciones sobre el correo electrónico para mejorar su flujo de trabajo. Aquí la omisión común es no asegurar una completa experiencia de disponibilidad en una situación de falla de los sistemas de comunicación.
3. La práctica es crítica. Muchas empresas practican la recuperación ante desastres, pero no aprovechan esa oportunidad para involucrar por completo a los equipos de aplicaciones. Los simulacros de desastre benefician tanto a los equipos de aplicaciones como a los equipos de infraestructura. Los equipos de aplicaciones pueden estar más conscientes de cuánto dependen de sus aplicaciones en una situación de falla, lo cual puede ayudarles a mejorar los diseños y los cambios a las aplicaciones en el futuro. En este caso, la omisión común consiste en realizar ejercicios de recuperación ante desastres únicamente con los equipos de infraestructura.
4. Dar prioridad a la red. Algo que las compañías descubren sobre la recuperación ante desastres es que redes diferentes pueden interferir en la recuperación exitosa en caso de fallas. Existen tecnologías modernas para llevar una red de un sitio al otro, así como tecnología que permiten a los sistemas y las aplicaciones cambiar la configuración de la red de sitio a sitio. La omisión común es no asegurar que la experiencia de red sea fluida para las aplicaciones en una situación de recuperación ante desastres.
5. Determinar cómo las decisiones serán tomadas. Decidir practicar un plan de recuperación ante desastres es una cosa, pero tomar la decisión de aplicarlo en una situación real de desastre puede ser difícil. Por lo general, las empresas pueden dudar ante la idea de utilizar una tecnología de recuperación ante desastres debido a la falta de una toma de decisiones adecuada, lo cual afecta todo, desde el árbol de decisión hasta el tiempo de respuesta. La omisión común es no contar con una autoridad en el lugar para manejar las decisiones en situaciones de desastre.
6. Se necesitan soluciones adecuadas de recuperación de desastres y una buena orquestación para hacerlo correctamente. Hubo una época en que bastaba contar con guiones personalizados, listas de control y herramientas a la medida para una recuperación ante desastres. La expectativa del centro de datos es alta actualmente y una estrategia anticuada no producirá un buen resultado. La omisión común es depender demasiado de una estrategia manual para la recuperación ante desastres.
Habrá otras oportunidades de aprender más sobre la recuperación ante desastres, sin embargo, esta lista muestra el camino hacia una continuidad exitosa de los negocios en caso de un incidente.
____________
El autor de este artículo, Rick Vanover, es Director Ejecutivo de Estrategia de Producto en Veeam Software. Puede contactarle en Twitter @RickVanover.
