Photo by panumas nikhomkhai from Pexels
En los últimos años han ido incrementándose los proveedores de servicios de respaldo en la nube (Cloud Computing), esto es, las copias de seguridad y/o el acceso al sistema remoto que contiene la réplica en tiempo real de sus datos se ubica físicamente en un centro de datos externo (data center) de un proveedor. Un paso más avanzado en esta estrategia, es el de además contratar la plataforma de aplicaciones y sistemas mínima necesaria en este data center para que sus empleados puedan pasar a trabajar con normalidad contra el data center, de manera transparente a los mismos, en el caso de una contingencia o desastre en las propias instalaciones de la empresa. Este servicio se está dando a conocer como RaaS (Recovery as a Service) o DRaaS (Disaster Recovery as a Service) y se presta bajo la modalidad de una cuota mensual o anual razonable, sobre todo si la comparamos con el perjuicio económico que la indisponibilidad prolongada de sus sistemas informáticos puede provocarle a la empresa.
Evidentemente para que un servicio de recuperación ante desastres esté adecuadamente diseñado y dimensionado, es necesario un riguroso proceso previo de análisis, cuyas claves describimos a continuación:
- Detallar la arquitectura actual: hardware, software, comunicaciones, centros de trabajo, centros de procesamiento de datos (CPD), redundancia de equipos y líneas de comunicación.
- Analizar y valorar los riesgos: identificar las posibles contingencias que se pueden llegar a producir, evaluando la probabilidad de las mismas y su impacto.
- Inventariar los puestos de trabajo, usuarios, aplicaciones y periféricos actuales que son críticos para un nivel mínimo de continuidad de negocio.
Tras este análisis, podemos empezar a realizar la propuesta de nuestro:
- Plan de respaldo: descripción de las acciones preventivas recomendables para disminuir la probabilidad de que se produzca la incidencia.
- Plan de emergencia: contramedidas a adoptar mientras persiste la incidencia o sus consecuencias posteriores para paliar los efectos negativos.
- Plan de recuperación: procedimientos a seguir una vez se ha estabilizado y controlado la situación para poder volver a la normalidad.
Y diseñar las características de nuestro servicio RaaS:
- Arquitectura mínima necesaria (hardware, software, comunicaciones) y escalabilidad de la misma.
- Escenarios de desastre considerados: en función del tipo de fallo y los posibles tiempos de parada requeridos.
- Protocolos de actuación y mantenimiento: ¿quién/es y en qué plazo toma/n la decisión de solicitar la activación del servicio para pasar a trabajar contra el entorno de respaldo? ¿cómo aseguramos la compatibilidad y actualización entre el entorno principal local y el de respaldo en el data center? ¿qué procedimiento seguimos para volver a trabajar contra el entorno principal una vez restablecido?
Para asegurar que nuestros planes, protocolos y servicio de respaldo siguen siendo adecuados y operativos, es necesario implementar también los procedimientos de revisión periódica, lo que implica:
- Pruebas reales de los distintos escenarios de desastre considerados.
- Ejecución de los planes y protocolos previstos.
- Documentación y difusión de las conclusiones y cambios aprobados.
Como siempre ocurre en la informática, no hay que olvidar nunca la criticidad del componente humano, debemos asegurarnos de que tanto el personal propio de la empresa, como el personal del proveedor del servicio RaaS:
- Conocen los protocolos a seguir.
- Disponen de las copias actualizadas de los documentos.
- Han recibido la formación necesaria para poder desenvolverse adecuadamente cuando el escenario de desastre se materializa.
Es aconsejable disponer de una aplicación informática de flujo de trabajo (workflow) donde implementar los protocolos previstos, y desde donde interactúen los distintos participantes durante las pruebas y casos reales de contingencia.
Sergio Álvarez Clau
Consultor de Negocio -DATADEC-