Ya hemos hablado anteriormente en este blog de Business Continuity y Disaster Recovery (BCDR), y de productos que nos pueden ayudar a diseñar/implantar una solución BCDR.
Tengo en mente, empezar con este “Basics” una serie de posts para ordenar todas esas ideas y soluciones que podemos utilizar.
No veo mejor forma de empezar esta serie de posts, que hablando de lo mas básico cuando se nos plantea el reto de diseñar/implantar una solución BCDR.
Ya sea un “Business” grande o pequeño, nos facilitara mucho saber explicar al cliente y tener nosotros mismos claros los 4 conceptos que vamos a ver en este post y que hacen referencia a DR.
En una primera toma de contacto con el cliente, probablemente le preguntemos, que RPO y RTO exige el negocio, y también es muy probable que el cliente no sepa que contestar porque no sabe que significan estos términos en relación a su negocio. Tal vez algún cliente con un departamento IT mas o menos grande, seguramente si pueda darnos este dato después de consultarlo.
También deberíamos preguntar sobre el WRT y MTD que el negocio espera y aquí es cuando el cliente seguramente se pierda totalmente, incluso nosotros en ocasiones lo pasemos por alto.
Dejamos las siglas, y pasamos a ver como explicar esto a quien nos pide la solución de BCDR.
Supongamos que la empresa CloudVM nos pide diseñar su solución BCDR y es hora de CloudVM entienda unos conceptos que no se ha parado a pensar o nunca le han preguntado.
CloudVM explota sus sistemas cada día “as usual”.
Pero un día tiene un fallo en uno de sus Datacenter.
Explicamos a CloudVM que Recovery Point Objective, significa, la cantidad de datos máxima que el negocio puede tolerar perder, midiendo esta cantidad de datos en tiempo.
CloudVM decide una vez asimilado el concepto que solo puede permitirse perder datos de sus pedidos, visitas, etc… de los 5 minutos anteriores al fallo de su Datacenter. RPO queda establecido por lo tanto en 5 minutos.
Una vez acordado el RPO, explicamos a CloudVM que Recovery Time Objective, representa, el tiempo máximo necesario para que sus sistemas críticos vuelvan a estar online. Independientemente de la clase de fallo que sufra su Datacenter, ya sea necesario restaurar de backup, un problema de networking, computo, etc.
En la mayoría de casos las acciones necesarias para devolver los sistemas online son tarea de los administradores de infraestructura, almacenamiento, redes, virtualización…
CloudVM decide que todos sus sistemas críticos deben estar online en 4 horas máximo. Por lo tanto se acuerda un objetivo de RTO de 4 horas.
Acordados RPO y RTO, parece que esta todo definido, y aquí se suelen quedar muchos diseños, pero realmente solo con RPO y RTO no esta todo definido. Es necesario acordar dos conceptos mas para evitar falsas expectativas o mal entendidos.
Recuperar sus sistemas críticos con 5 minutos de perdida máxima de datos en un máximo de 4 horas no quiere decir que CloudVM retome el trabajo trabajo normal en 4 horas.
Y aquí es cuando explicamos a CloudVM que significa Work Recovery Time.
Tiempo que se necesita para verificar la integridad de los sistemas o datos, asegurándose de que las aplicaciones, servicios o BBDD estén disponibles. El procedimiento de estas validaciones normalmente deben establecerlo los administradores de la capa de aplicación y BBDD.
CloudVM entiende que devolver sus sistemas online no quiere decir que sean de nuevo 100% funcionales, establece por lo tanto en 60 min su WRT, tiempo necesario para validar que todos sus servicios pueden ofrecerse de nuevo sin comprometer el negocio y son totalmente funcionales.
Finalmente después de establecer el RPO-RTO-WRT, nos queda por explicar a CloudVM el ultimo concepto de este post, Maximum Tolerable Downtime.
MTD es el tiempo máximo de caída que el negocio puede permitirse sin consecuencias inaceptables para el mismo. MTD = RTO+WRT, el MTD debe ser aceptado/definido por la unidad de negocio, o bien por figuras del negocio como el CTO, CIO o IT manager.
Después de presentar al negocio la pregunta e informarles que según el RTO y WRT establecido su MTD sera de 5 horas, el negocio acepta este MTD, si no fuese aceptado deberíamos replantearnos los tiempos de RTO y WRT.
Se suele cometer el error de evaluar estos tiempos solo en ciertas partes de la infraestructura y eso da lugar a tiempos dispares dependiendo del tipo de fallo. Por ejemplo, se suele dar un control muy estricto del lado de la virtualización o el computo y un control menor de los tiempos ante necesidad de restores desde backup o en tiempos de WRT exagerados por no tener bien definidos los procesos de validación ante recuperación de fallo. ERROR!
También por error, se tiende a pensar, “tenemos un plan de DR para IT, nuestro BCDR es OK”, y aquí aparece la pieza que nos falta en este post, el Business Continuity. Un plan de BC, necesita ir mas allá y tener definidos procesos esenciales para el negocio, como por ejemplo:
- Un plan para personal critico
- Procesos comerciales clave
- Identificación de proveedores o clientes clave
- Identificar los procesos básicos para la continuidad de negocio, ante desastre desde fuego en una sede de negocio hasta un cyberataque en sus sistemas IT
Esto, como indica el titulo del post, seria lo básico en un BIA (Business Impact Analysis), de cara a diseñar una solución BCDR y la posterior infraestructura que debe soportar estos tiempos.
En futuros posts de esta serie intentaremos ordenar que herramientas nos pueden ayudar a cumplir estos tiempos y como.
Gracias por compartir 🙂
Post muy interesante , crack.