La adopción de los planes de recuperación ante desastres (#DRP por sus siglas en inglés Disaster Recovery Plan) son una necesidad sin discusiones en el ámbito de las grandes compañías, pero gradualmente muchas empresas de tamaño medio y pequeño planean Planes de Continuidad de Negocio (#BCP) a través de herramientas que le permitan el recupero operativo de sus aplicaciones ante una falla crítica.
Debido a la creciente oferta de servicios #Cloud es que la posibilidad de contar con un sitio de contingencia es algo cada día más sencillo y accesible.
¿Qué necesito para planificar un plan de recuperación?
Fundamentalmente conocer cuáles son los objetivos del plan. Una vez estipulado el alcance es necesario contar con un inventario físico y aplicativo. Toda esta información es importante para el proceso de planning.
De ser posible se debe crear un mapa de arquitectura que contenga la relación de las aplicaciones, dependencias, resguardos, el flujograma de comunicaciones y que tenga un mapeo relacionado entre cada servicio y cada servidor, de manera de conocer que corre cada equipo.
Entrando en el plan se debe conocer previamente dos ítems fundamentales: RTO y RPO.
- El #RTO (recovery time objective) es ni más ni menos que el tiempo máximo definido para una aplicación para que la misma pueda estar fuera de línea.
- El #RPO (recovery point objective) tiene que ver con la cantidad de datos que se pueden perder en determinado tiempo.
Es de esperar que los costos aumenten a medida que los tiempos de recuperación solicitados sean más cortos. De manera que -a modo de ejemplo- un sistema de ventas, cobranzas y/o facturación, puede tener un tiempo de RTO y RPO menor que un sistema de mensajería y colaboración; dado que su organización puede tolerar más tiempo sin email o perder los emails de las últimas horas, pero no puede tolerar estar sin facturar o perder la facturación de una hora atrás.
Basados en las definiciones tomadas en cuenta para incorporar en el plan de continuidad operativa, el siguiente paso es dimensionar el sitio de contingencia para lo que sea fundamental la información técnica mencionada anteriormente y que conformará la fase de planning.
Planning
El planning determinará las características del sitio secundario. Y esas características deben contener información importante:
- ¿Se procesa el 100% o solo partes críticas de la plataforma?
- ¿El sitio secundario soporta toda la carga o será limitado en potencia? Como paso adicional, se deben considerar factores de red y seguridad.
- ¿Cómo se harán las réplicas?
- ¿Cómo se aseguran las copias de información?
- ¿Cuánto ancho de banda consumirá?
- ¿Se mantendrán las direcciones IP?
Dependiendo de la respuesta el plan puede tener infinitas combinaciones de ejecución acordes a los requerimientos de su negocio.
Y no está de más mencionar que existen cuestiones políticas.
- ¿Quién determina el RTO/RPO?
- ¿Quién determina la pérdida total del sitio primario y da la orden de ejecutar el lanzamiento de la plataforma desde el sitio secundario?
- ¿Qué cambios aplicativos deben realizarse?
- ¿Qué cambios en los accesos (ej DNS) deben realizarse?
DRP
Así como el proceso paso a paso de la ejecución del DRP debe ser debidamente documentado también dentro del listado de tareas es importante tener el detalle del rollback, y determinar en qué momento y como se ejecutará el proceso de “devolución” de los servicios al sitio primario. Todos estos pasos deben ser documentados a detalle, y el plan debe ser probado en su funcionamiento (se recomienda un test anual) para confirmar que ningún paso sea erróneo.
Obviamente cada negocio tiene reglamentaciones como #SOX, #ISO, Bancos, u otros casos que complejizan la operatoria. Técnicamente cada aplicación tiene un funcionamiento que genera el análisis puntual de cada una y en muchos casos tareas previas de adecuación antes del armado del sitio de resguardo. Cada caso es una situación especial que amerita algo mucho más profundo que este pequeño artículo.
[popup_anything id=”2076″]