Síguenos:
Cloud
19 de Abril de 2017

“El coloso en llamas”: ¿la continuidad del negocio primero?

“El coloso en llamas”: ¿la continuidad del negocio primero?

“El coloso en llamas”: ¿la continuidad del negocio primero?

Escrito por , 19/04/2017

Seguro que muchos recordaréis la película protagonizada por Paul Newman y Steve McQueen rodada en los 70, y enmarcada dentro de la categoría de “catástrofes” que se puso tan de moda. “El coloso en llamas” nos cuenta la lucha por sobrevivir de un grupo de personas en el incendio que se produce en la inauguración de un rascacielos de 138 plantas. Vamos, ¡todo un reto!

Pero, ¿y si además de por su vida estas personas tuvieran que preocuparse por la salvaguarda de sus activos TI, tanto datos como procesos?

Imaginad que Paul Newman fuera un CEO que, después de estar trabajando en la transformación digital de su empresa durante los últimos cinco años, en el momento del incendio le preguntara a su CIO, en este caso Steve McQueen:

  • “Steve, me dijiste que ya habíamos arrancado el proyecto de disaster recovery de nuestra sala TI, ¿verdad?”
  • “Uf, Paul, nos comentaste que eso lo dejábamos para el tercer cuatrimestre del próximo año. Igual hay suerte y podemos recuperar las cintas del backup de hace una semana, pero perdona un momento que se me está quemando la chaqueta…”
  • “Es verdad, Steve. Y además todavía no habíamos terminado de definir la criticidad de las aplicaciones y los valores de RPO y RTO de nuestros servicios. Bueno, creo que elegí un mal día para dejar de fumar” (esto último no sé si era de esta película o de “Aterriza como puedas”).

Situaciones como ésta, que parecen de ficción, suceden y, en algún caso, más cerca de lo que podríamos esperar, como cuando se produjo el incendio de la Torre Windsor en Madrid.

Por ello es recomendable que los centros de datos de las empresas estén situados en data centers especializados y que cuenten con las máximas medidas de seguridad. Pero, además, cuando la criticidad de los datos es alta, conviene que esos datos estén replicados en un centro de datos alternativo.

Toda esta problemática se trata de forma específica dentro de ITIL (Information Technology Infrastructure Library), en la gestión de la continuidad del servicio TI. Prometo profundizar en ello más adelante, pero lo importante es entender que cada negocio debe analizar qué medidas de continuidad son necesarias para sus servicios TI en función de la criticidad de los mismos. Este análisis de impacto sobre el negocio determina dos acrónimos, de los que ya ha escrito algún compañero, aunque si os lo perdisteis os pueden parecer los nombres de dos robots de “La guerra de las galaxias”, pero que realmente nos permiten determinar las soluciones tecnológicas que hay que aplicar a cada servicio TI para conseguir la continuidad requerida por el negocio.

Las siglas son las estelares RPO y RTO:

  • RPO quiere decir Recover Point Objective y determina el punto en el tiempo en el cual el negocio se puede permitir la pérdida de datos. Cuando el RPO tiende a cero quiere decir que los datos se tienen que replicar de forma casi instantánea en un segundo datacenter. Un ejemplo: una empresa que llamaremos “Inferno Towering” dispone de una intranet para gestionar la actividad de sus empleados pero en caso de desastre le basta con disponer de los datos de las 24 horas anteriores, el último backup generado (RPO= 24 horas). También dispone de un sistema de gestión de pedidos que se tienen que provisionar y facturar y, en este caso, no se puede permitir perder los datos que vayan más allá de los generados en los últimos cinco minutos (RPO= 5 minutos).
  • RTO quiere decir Recover Time Objective y marca el tiempo en el cual se requiere que el servicio TI vuelva a estar disponible; es decir, el tiempo durante el cual una organización puede tolerar la falta de funcionamiento de sus aplicaciones y la caída de nivel de servicio asociada. Si este valor es pequeño, obliga a disponer en el segundo datacenter de casi todas las infraestructuras preparadas para levantar el servicio en el menor tiempo posible. Veamos el ejemplo con “Inferno Towering”: lo más probable es que para la intranet se pueda permitir varias horas sin servicio sin que afecte al negocio (RTO= 12 horas). Sin embargo, el sistema de tramitación de pedidos deberá reanudarse en minutos, ya que si no el negocio estaría parado, con las consiguientes pérdidas (RPO= 10 minutos).

El siguiente gráfico refleja el significado de RPO y RTO que acabo de explicar.

Como podéis imaginar, cuanto más pequeños sean los valores de RPO y RTO más costosas serán las medidas tecnológicas para conseguirlo. Pero, por muy costosas que sean, siempre serán más rentables que tener el negocio parado más tiempo del que demandan los clientes o que la pérdida de datos en el tiempo repercuta en muchas transacciones de negocio.

Si Paul y Steve hubieran tenido todo esto claro, el diálogo podría haber sido éste:

  • “Steve, estoy tranquilo, con el plan de continuidad que tenemos implementado, sé que los datos de nuestra aplicación core ya están funcionando en el centro de respaldo”
  • “Sí, Paul, yo también, así que ahora corramos o nos vamos a quedar aquí achicharrados”

Telefónica dispone de Centros de Datos y soluciones tecnológicas (como Replicación síncrona, Disaster recovery as a service o Backup cruzado) que permiten que los servicios TI de sus clientes cuenten con el respaldo que demandan sus negocios. Pero todo esto será objeto de otra película…

Imagen: lance robotson

Sobre el autor

Julio Mestre Valdés

Julio Mestre Valdés

Ingeniero Superior de Telecomunicaciones por la Universidad Politécnica de Valencia y proyecto de fin de carrera en el Politécnico de Torino. Actualmente lidero ofertas de externalización TIC para los grandes clientes de Telefónica. Entre mis aficiones están el deporte, la lectura y ver series de televisión (cómo no en Movistar+).
Ver todos sus artículos »