menu_superior

Protección frente a desastres: El testing de resiliencia (continuidad del servicio)

El titulo del post suena un poco extraño por que resiliencia no es un palabra que usemos muy a menudo en nuestro vocabulario. Resiliencia viene del latín resilio, resilere y significa algo así como rebotar. En castellano se usa en varias disciplinas profesionales aunque a mí me parece que la definición que se ajusta más a la idea de testing de resiliencia es la que hace la psicología: “El término resiliencia se refiere a la capacidad de los sujetos para sobreponerse a períodos de dolor emocional y traumas. Cuando un sujeto o grupo es capaz de hacerlo, se dice que tiene una resiliencia adecuada, y puede sobreponerse a contratiempos o incluso resultar fortalecido por éstos. ” (Fuente: Wikipedia).

Pruebas de resilienciaAplicado nuestro campo, el testing de resiliencia tiene por objetivo evaluar la capacidad de un sistema de prestar el servicio cuando se da una circunstancia adversa e inesperada: pérdida de comunicación con otros sistemas (internos o externos), caída de servidores (de aplicaciones, de base de datos, etc), fallos en cachés, indices o sistemas de archivos, etc. Este tipo de testing aporta un valor muy importante ya que nos permite conocer en detalle el comportamiento de los elementos críticos de nuestro sistema en escenarios muy adversos. Es más, tal vez ni siquiera sepamos antes de la prueba qué elementos de nuestro sistema son verdaderamente críticos y la ejecución de las pruebas nos aporte información que permitirá identificar cuales son estos elementos.

Planteamiento de las pruebas

La responsabilidad de la continuidad del servicio en un sistema de negocio obliga a conocer qué componentes del sistema son vitales para que el negocio siga funcionando y cuanto tiempo pasará hasta que dicho sistema vuelva a estar en funcionamiento. Las pruebas de resiliencia se puede plantear de tal manera que aporten información de la continuidad del servicio en circunstancias adversas así como del tiempo de recuperación y puesta en funcionamiento del sistema después de una caída. Los planteamientos en detalle serían los siguientes:

  • Continuidad del servicio. Para verificar que el sistema es robusto y que se mantiene el servicio hay que sacar componentes del sistema. Dependiendo de lo grande que sea nuestro sistema, esta retirada de componentes se podrá hacer con varias combinaciones o simulando distintos escenarios (por ejemplo: escenario sin comunicaciones, escenario de eliminación de sistemas primarios y paso a backup, etc.). La principal premisa para este tipo de pruebas es tener un conocimiento muy amplio y detallado de los componentes de la instalación y de la funcionalidad de cada uno.  El procedimiento es relativamente sencillo: se lanza una prueba que mantenga un nivel de carga de trabajo sostenido durante un periodo de tiempo y se monitoriza la respuesta del sistema desde el principio hasta el final. A medida que se retiren componentes (simulación de averías o fuera de servicio) se observará claramente el impacto que tiene la carencia de componentes en la operatividad del servicio y en los tiempos de respuesta.
  • Recuperación del servicio. En este caso el objetivo es conocer el tiempo que tarda el sistema en volver a estar productivo. Es importante aclarar que tanto si la parada ha sido planificada como si ha sido abrupta, tenemos que conocer el tiempo de recuperación del servicio. En el caso de la parada planificada por que conocer el tiempo nos permite, precisamente, planificar dicha parada y en caso de caída abrupta por que es vital tener algo que decirle a los clientes, saber cuándo volverá a estar en servicio y qué pasa con las transacciones que estaban en marcha cuando se produjo la caída. El mecanismo para realizar esta prueba es similar al anterior: generar carga de trabajo para el sistema y arrancar el sistema con distintas secuencias de componentes (si es posible) para obsevar cuando se recupera totalmente el servicio y en qué estado quedan (perdidas, inconsistentes, realizadas) las transacciones que llegan.

Toda esta teoría que suena tan retórica y tan académica se vuelve imprescindible cuando pensamos en un caso real: una tienda online que trabaja con una pasarela de tarjetas de crédito. En realidad, la caída de la pasarela no depende de los responsables de la tienda pero puede ralentizar o paralizar su negocio por que en una tienda en la red no se puede pagar en metálico. Si el cliente no dispone de medios de pago no comprará, así que es necesario verificar el comportamiento del sistema con el timeout de la pasarela, la entrada de medios de pago auxiliares, si se pueden hacer transacciones offline (sin verificar el pago) para cargarlas cuando se recupere la pasarela… Todas éstas decisiones marcan la estrategia del negocio en la red y la mejor información para tomarlas la proporcionan las pruebas de resiliencia.

, , ,

Comments are closed.