¿Hace falta un Blog de Continuidad de Negocios?

Hace casi 14 años, en 1996, empezamos nuestra colaboración con Vision Solutions. Entonces en nuestra empresa, fundada en el año 1992, apenas éramos 8 personas. 

Nuestro proveedor Vision Solutions tuvo en este tiempo un crecimiento importante y hoy es un conglomerado creado por la unión de varias empresas: Vision Solutions, iTERA, Lakeview Technology y (sujeto a la aprobación final del accionariado) Double-Take Software. El parque total supera las 30.000 licencias. Ahora usamos 5 productos diferentes de Continuidad de Negocios para implantar soluciones en las distintas plataformas. Éstos a su vez, tienen módulos diversificados para adaptarse a las necesidades de las instalaciones que son increíblemente variadas.

Hay que manejar e intercambiar una gran cantidad de información. La evolución genera muchas situaciones nuevas que a su vez generan dudas. Los canales tradicionales de intercambio de información no dan abasto para este intercambio…  Y de allí surge la idea de empezar un blog. Nos prometemos de este nuevo medio –menos formal y mucho más dinámico e interactivo que los que usamos ahora– que nos permita estar más cerca de las inquietudes de los usuarios actuales y futuros.

Hemos tenido que aprender muchas cosas sobre Alta Disponibilidad, Recuperación de Desastres y más recientemente sobre Protección Continuada de Datos, todo lo que en su conjunto se denomina Continuidad de Negocios. Mucho de ello lo aprendimos de nuestros proveedores –Vision Solutions y Double-Take Software–, otro tanto de nuestros Partners, de nuestros competidores, de la prensa y de muchas otras fuentes. Pero pensamos que  donde más se aprende es en el diálogo con los usuarios.

Esperamos que sepamos generar un buen diálogo y que sea fructífero para todos.

Una respuesta a «¿Hace falta un Blog de Continuidad de Negocios?»

  1. En primer lugar decir que la idea de crear un bloc para poder opinar sobre continuidad de negocio es magnífica. Creo que este espacio permitirá clarificar el significado de cada uno de los conceptos que comentas y las necesidades que actualmente hay en este ámbito.

    Como punto de partida quisiera describir brevemente el significado que para mi tiene cada uno de los puntos que has mencionado y algún otro.

    Protección del sistema base:

    Es una copia del sistema en un soporte externo que se realiza al finalizar la configuración inicial del sistema y posteriormente en cada actualización de este.

    En caso de desastre se utiliza para recuperar el sistema base con la customización realizada.

    —————————–

    Protección periódica de datos:

    Es una copia de datos en un soporte externo que se realiza periódicamente dependiendo de la política de seguridad de cada sistema.

    En caso de desastre se recupera del soporte externo con pérdida de datos desde la realización de la última copia, normalmente suele ser de medio día.

    —————————–

    Alta disponibilidad de datos:

    Es una réplica de datos entre dos o más servidores que pueden estar ubicados en local o en remoto.

    En caso de desastre no hay pérdida de datos, sólo de las transacciones que estaban en curso.

    —————————–

    Protección continuada de datos:

    Es una réplica de datos entre dos o más servidores que pueden estar ubicados en local o en remoto con la posibilidad de posicionarte en cualquier momento del pasado.

    En caso de desastre no hay pérdida de datos pero además tiene la flexibilidad de posicionarse en cualquier tiempo del pasado dependiendo de las necesidades de recuperación.

    —————————–

    Plan de recuperación de desastres (DRP): (individual, parcial y global)

    Para mí este concepto es más amplio que lo anteriores, es decir, es un plan de recuperación de todos los sistemas/procesos informáticos ubicados en un centro de proceso de datos debido a un incidente mayor “inundaciones, tormentas eléctricas, fuego, etc.” que puede afectar a uno, varios o todos los sistemas/procesos. Este plan tiene que dar respuesta a cualquier casuística.

    En caso desastre la recuperación de los sistemas/procesos debería ser en una ubicación remota. Si la ubicación no es remota la recuperación puede ser inviable dependiendo del desastre ocurrido.

    Lógicamente este plan de recuperación de desastres puede estar compuesto de sistemas con alta disponibilidad, con protección continuada de datos, con la copia diaria, etc. El plan de recuperación debe indicar el orden de recuperación de cada sistema/procesos para poner en funcionamiento los procesos más críticos de la compañía lo antes posible.

    El problema más típico al implementar un plan de recuperación de desastres es disponer de soluciones de recuperación aisladas sin haber pensado en procesos. Un plan de recuperación de desastres se debe pensar por procesos por el siguiente motivo:

    Ejemplo de recuperación de un proceso de facturación compuesto con la siguiente infraestructura:

    • 1 servidor ISERIES (SAP R/3),
    • 1 servidores XSERIES (SAP SRM),
    • 1 servidor virtual vmware en disco SAN (Domino – Salida de correo al exterior)

    • Si el ISERIES (SAP R/3) dispone de ALTA DISPONIBILIDAD lo arrancamos en 5 min.
    • Si el XSERIES dispone sólo de recuperación de datos externa del día anterior lo arrancaremos en un plazo de 4 horas con los datos de la noche anterior.
    • Si el vmware dispone de recuperación de disco FLASH COPY del día anterior lo recuperaremos en 1 hora con los datos de la noche anterior.

    Está claro que el proceso completo no funcionará hasta después de 4 horas por mucha alta disponibilidad que tengamos en el SAP R/3 y lo peor de todo es que se deberá cuadrar manualmente el estado de las facturas en cada sistema, pues el SAP R/3 estarán en situación optima pero en el SRM y en el software de salida de facturas por correo estarán en situación de la noche anterior, cuadrar puede suponer 1 día dependiendo de la experiencia de los administradores y desarrolladores.

    La conclusión es que tardaremos 1,5 días para que el proceso de facturas funcione correctamente.

    Hay que ser consciente de que cada día son más los sistemas interconectados que gestionan un proceso completo y esto hay que analizarlo e implementar las tecnologías necesarias para disponer de un buen plan de recuperación de desastres.

    Es en este punto donde se agradece que compañías como Greenhouse facilite al mercado las tecnologías necesarias para poder abordar un buen plan de recuperación de desastres y en consecuencia un apoyo muy importante a la continuidad del negocio.

    En el caso comentado lo óptimo hubiera sido que los tres sistemas tuvieran el mismo método de recuperación, es decir: alta disponibilidad para los tres sistemas.

    Otra alternativa que se suele plantear en el caso anterior es analizar la viabilidad de realizar una optimización de sistemas pensando en procesos.

    Por ejemplo: en este caso podrían ubicarse los tres sistemas en un ISERIES y aprovechar la alta disponibilidad de la cual ya se dispone. Otra opción sería pasar el SAP R/3 en un XSERIES e implementar soluciones de alta disponibilidad para esta plataforma. La mejor opción dependerá del plan de sistemas tecnológico acorde con la estrategia del negocio.

    Para finalizar este punto comentar que el responsable máximo de que este plan funcione correctamente es del director de sistemas de información.

    —————————–

    Gestión del plan de recuperación de desastres (DRM).

    Es evidente que una vez realizado el plan de recuperación de desastres es necesario mantenerlo. Esta es la parte más difícil, pues llegar es difícil pero mantenerse aun lo es más. Esto requiere de una metodología y sistemática de cómo proceder.
    Ejemplo:
    • Revisión en las nuevas implementaciones de procesos.
    • Revisión en los cambios de los procesos.
    • Pruebas anuales de recuperación parcial.
    • Pruebas anuales de recuperación total.
    • Plan de comunicación.
    • Mantenimiento de la documentación.
    • Etc.

    —————————–

    Plan de continuidad del negocio (BCP).

    Podemos decir que es como un plan de recuperación de desastres pero de TODAS LAS FUNCIONES CRITICAS de la compañía estén o no automatizadas y contemplando aspectos como la adecuación de los puestos de trabajo, los teléfono, los PC’S de sobremesa, etc. Pues si tenemos todos los procesos críticos redundados en otra ubicación remota y dependiendo del desastre no disponemos de espacio para que los empleados puedan trabajar tampoco acabaremos de solucionar el problema.

    Un buen plan de recuperación de desastres pensado por procesos en SI facilita mucho trabajo al extenderlo a un plan de continuidad.

    El máximo responsable de que funcione un plan de continuidad del negocio es de alta dirección.

    —————————–

    Gestión del plan de continuidad del negocio (BCM).

    Este punto también es idéntico a la gestión del plan de recuperación de desastres pero abarcando todas las FUNCIONES CRITICAS de la compañía estén o no automatizadas y pensando en otros aspectos que no contempla la gestión de recuperación de desastres.

    Ejemplo: Si la entrada de pedidos se considera función crítica y se ha ampliado con 2 puestos de trabajo. Este cambio debe contemplarse en la gestión del plan de continuidad de negocio realizando las acciones oportunas.

    —————————–

    Para finalizar decir que lo comentado anteriormente son mis criterios a raíz de la experiencia de 15 años trabajando como IT Manager. Sé que alguien puede sorprenderse cuando estoy ubicando el concepto de plan de recuperación de desastres como algo sólo del departamento de sistemas de información pero la realidad histórica en mi caso es esta. Agradecería cualquier comentario con el fin de ir unificando criterios e ideas relacionadas en el mundo de continuidad de negocio.

    Aprovecho para decir que en otra ocasión sería interesante hablar también de las metodologías y normativas de un plan de continuidad de negocio y hasta qué punto ciertas entidades están obligadas a implementarlo.

Responder a Joan Ventura Cancelar la respuesta

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

Información básica sobre protección de datos Ver más

  • Responsable: Software Greenhouse, S.A..
  • Finalidad:  Moderar los comentarios.
  • Legitimación:  Por consentimiento del interesado.
  • Destinatarios y encargados de tratamiento:  No se ceden o comunican datos a terceros para prestar este servicio.
  • Derechos: Acceder, rectificar y suprimir los datos.
  • Información Adicional: Puede consultar la información detallada en la Política de Privacidad.