Recuperación ante desastres 2.0 sin malograr el presupuesto TI

Susana Martínez Ferreiro    12 diciembre, 2013

Retomando la línea de mi primer post, hoy he decidido seguir hablando de los patrones de comportamiento en el mundo de la tecnología, y otro de los guiones que se repite cuando visito a un cliente que quiere abordar un proyecto de recuperación ante desastres es el siguiente:

Cliente: Necesito poder recuperar mis sistemas en caso de desastre

“Muy bien”, digo yo,  y pregunto: “¿Cuáles son los procesos críticos de tu negocio?”

Y aquí viene el comportamiento que se repite de forma mimética en todos y cada uno de los clientes con los que he tratado un proyecto de estas características: “Todos” responde el cliente.

“Vaya- pienso- menuda sorpresa”. Mi ceja se levanta escéptica, cual emoticono de Whatsapp pero, lejos de contradecirle, sigo con mis preguntas: ¿En cuánto tiempo necesitas recuperar todos los procesos de tu negocio?En cero segundos” contesta rotundo mi cliente y la última pregunta que tengo, aunque a estas alturas casi consigo adivinar la respuesta es “¿Cuánta información podrías perder desde que se produce el desastre?” La respuesta os la podéis imaginar: “Ninguna.

No debemos olvidar que cuando un cliente quiere abordar un proyecto de recuperación ante desastres, la analogía que subyace es la de la contratación de un seguro, en la que no resulte que el valor del bien que se asegura sea el mismo (y a veces incluso mayor) que el del bien asegurado. Para conseguir esto, el método tradicional que utilizaba era pasar por un proceso que me permitía separar los procesos de negocio que eran críticos de los que no lo eran y tipificarlos acorde al RTO (en cuánto tiempo quieres recuperar tu entorno) y RPO (desde qué momento quieres recuperar o cuánta información puedes perder). Este proceso requería una serie de entrevistas con todos los dueños de los procesos de negocio, realizada de forma iterativa,  de tal forma que por cada repetición valoraba el coste que suponía disponer de una infraestructura capaz de albergar los citados “procesos críticos”. Os podéis imaginar que cuantos más procesos críticos existan y más exigentes sean los objetivos de RTO y RPO, mayor es el coste asociado. Normalmente después de tres iteraciones, en las que se iban separando adecuadamente los procesos críticos de los que no lo eran, conseguíamos un mapa de procesos perfectamente tipificado (gracias al poder revelador, entre otros, que proporciona conocer lo que cuesta asegurar las cosas). Como decía Thomas Carlyle, “Con números se puede demostrar cualquier cosa”.

La realización de este tipo de análisis es un proceso bastante tedioso, en el que es necesaria una implicación activa por parte del cliente, además del coste asociado del grupo de consultores que deben realizarlo, lo que hace que el coste total  del estudio no sea siempre compatible con el presupuesto de nuestros clientes.

¿Cómo hacer para, de alguna forma, minimizar el proceso anterior? Antes que nada, siempre le  pregunto al cliente  si tiene bien redundado y asegurado su entorno de producción y, si no lo está, le recomiendo que desvíe parte del presupuesto a su entorno de producción. Si ya es así, mi recomendación pasa por contratar servicios en la nube pública, a través de una modalidad de pago por uso, que le permita pagar únicamente en caso de que active el entorno de recuperación ante desastres y pagar sólo por una pequeña disponibilidad del entorno. Además, gracias a las API (Interfaz de Programación de Aplicaciones) que proporciona la nube pública, se puede disponer de un catálogo de plantillas con las imágenes de producción, que pueden cargarse en el entono de contingencia de una forma ágil y bajo demanda ante un desastre. Por supuesto, será necesario realizar cargas periódicas de datos, para asegurar la consistencia de los mismos en el momento de la recuperación pero, gracias a los portales de auto-provisión, este tipo de tareas es cada vez más fácil y automatizada.

Como conclusión y citando una frase de Platón, en la que dice que “La pobreza no viene por la disminución de las riquezas, sino por la multiplicación de los deseos”, para optimizar el presupuesto TI, antes de abordar este tipo de proyectos es necesario revisar la producción, seleccionar los procesos críticos del negocio (para  así evitar la multiplicación de “deseos”) y asegurarlos utilizando los servicios de nube pública en modo pago por uso.

 

Comentarios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *