Disponibilidad en Aplicaciones Digitales

Todas las empresas grandes, medianas, pequeñas o startup, quieren que sus sistemas siempre estén disponibles para sus clientes, la Disponibilidad hace referencia al tiempo al que está operable un sistema o aplicación para realizar la tarea para la que fue diseñada y construida, en pocas palabras, es el tiempo que la aplicación está funcionando. Teóricamente un sistema debe de ser capaz de responder una solicitud en cualquier momento,  podría recibir aleatoriamente cualquier número de peticiones en cualquier minuto, hora o día y el sistema debería de responder de forma exitosa, sin embargo, esto no es así en el mundo real, pues lo que estamos en TI sabemos que TODO SISTEMA FALLA por diversos motivos, por muy bien diseñado y construido que esté, por más que siga los mejores patrones, framework o estándares del mercado, todo sistema se ha caído en algún momento, como es el caso de Whatsapp, Netflix, Google, Amazon o Facebook, todas las empresas en algún momento de su vida han fallado y seguirán fallando, pues las fallas son inevitables.

Partiendo de esta premisa, y para dar confianza a nuestros usuarios/clientes, la disponibilidad se debe de indicar en términos reales, cuanto tiempo estará disponible nuestra aplicación en un determinado periodo de tiempo, por ejemplo, “la aplicación tendrá una disponibilidad del 98% al año”, esto quiere decir que tenemos considerado que la aplicación fallará un promedio de 7.3 días por año, o a la inversa estará disponible por 357.7días por año.

Ahora el nivel de disponibilidad que necesites dependerá del tipo de aplicación y su criticidad para el negocio en el que te encuentres, lo importante es saber dónde estás, dónde quieres llegar y ver qué medidas tomar para llegar a esa meta deseada.

Pero… ¿Cómo podemos medir la disponibilidad?

Es importante que al momento de diseñar nuestra aplicación evaluemos junto con el negocio que tanta disponibilidad debe de tener nuestro sistema, por experiencia casi siempre que le pregunto a un usuario sobre la disponibilidad de un sistema, me dice: Hanz que este 100% disponible 7x24x365, ahí es dónde me toca ponerme mi sombrero de arquitecto de negocio para entender junto con el usuario la real necesidad de disponibilidad.

Pues si bien una disponibilidad muy baja puede ser un grave problema para los usuarios, mientras que una disponibilidad innecesariamente alta puede solo representar gastos y derroche de recursos que podrían ser utilizados para otras iniciativas.

Un nivel de disponibilidad alto muchas veces es difícil de lograr, pues necesitamos que nuestra aplicación haya sido diseñada para escalar desde el inicio, ya que hacerlo sobre la marcha puede tener un impacto grande sobre el sistema y muchas veces no es posible.

Acá les dejo algunas estrategias a considerar parar conseguir nuestros objetivos de disponibilidad.

Balanceo de cargas: consiste en tener múltiples instancias de la aplicación corriendo en diferentes servidores o contenedores según el estilo arquitectónico, con la finalidad de que la carga de trabajo se pueda dividir entre estos.

Redundancia: la redundancia es la capacidad de replicar los datos, software o hardware crítico, de tal forma que pueda soportar la carga en caso de que otro componente fallara.

Monitoreo: es una herramienta preventiva que nos puede arrojar advertencias antes de que el sistema falle por completo, muchas veces no bien explotada, esto le da tiempo a los administradores del sistema para realizar las acciones correctivas.

Desarrollo (App): no todas las fallas son por la infraestructura, muchas veces la lógica de programación o los algoritmos no son los adecuados, provocando la saturación del sistema y un eventual colapso. Debemos asegurar siempre el desarrollo y ser consciente de su importancia.

Minimizar el impacto de mantenimiento: Todos los sistemas requieren mantenimiento, sin embargo, es indispensable planear correctamente nuestras ventanas de mantenimiento en las fechas y horarios menos críticos, así como juntar la mayor cantidad de parches a aplicar en una sola ventana. Otra alternativa es, diseñar nuestra aplicación para que permita el mantenimiento sin necesidad de detener la operación, es más complicado, pero posible.

Una recomendación final; la mayor parte del tiempo que un sistema está fuera de servicio es por fallas humanas, porque no fue probada correctamente o una configuración incorrecta, etc. Es importante tener una buena fase de pruebas, al mismo tiempo, es importante reducir el riesgo humano, automatizando la mayor cantidad de tareas.

La disponibilidad está directamente relacionado a la experiencia de usuario (UX) que le estamos brindando a los usuarios.