La fiabilidad y la disponibilidad son las grandes características olvidadas. Siempre pasan a un segundo plano cuando se habla de cómo tiene que ser cualquier aplicación, software o infraestructura. Sin embargo, ambas son esenciales: de nada sirve ofrecer un buen diseño si nuestro desarrollo presenta fallos de disponibilidad o no es fiable. 

De ambos conceptos, su definición e importancia, tratamos en este post. Igualmente ofreceremos algunas recomendaciones para alcanzar una Alta Disponibilidad –de la que luego hablaremos– y una óptima fiabilidad.

¿Qué es la fiabilidad?

La fiabilidad es una característica que, en el contexto del software y las aplicaciones, está relacionada con la probabilidad de que dicha solución funcione sin fallos en un entorno concreto durante un periodo de tiempo determinado. Un software fiable es aquel que no tiene ningún defecto, ni genera tiempos de inactividad y funciona correctamente en todos los casos.

Por ello, la fiabilidad (reliability) es la característica más importante de cualquier aplicación. Si un software no es fiable, los usuarios se acabarán marchando por lo que el resto de características dejarán de tener relevancia.

Para referirse a estas cuestiones, en Google acuñaron el concepto Site Reliability Engineering (SRE). Este modelo permite determinar qué características nuevas lanzar y en qué momento gracias a:

• Service Level Agreement (SLA) o Acuerdos de Nivel de Servicio, establecidos entre proveedor y cliente, sobre parámetros cuantificables como las responsabilidades, el tiempo de actividad o la capacidad de respuesta.
• Service Level Objectives (SLOs) o Acuerdos de Nivel de Objetivos. Se trata de un acuerdo concreto, enmarcado en un SLA, que se mide con una métrica específica (SLI).
• Service Level Indicator (SLIs) o Indicadores de Nivel de Servicio. Se trata de una medida directa del comportamiento de un servicio.

Los registros y las entradas de rastreo son nuestros mejores aliados para encontrar problemas y activar alarmas con el fin de mantener nuestro sistema en funcionamiento. Por ello, se recomienda auditar de forma periódica la monitorización y borrar cuadros de mando, alertas, trazas y registros que no se utilicen. Esto mitigará el desorden y asegurará que la monitorización sea la adecuada.

Asegurar la Alta Disponibilidad (HA)

El concepto de fiabilidad no se entiende sin el de “disponibilidad”. La disponibilidad hace referencia al porcentaje de tiempo que una infraestructura, sistema o solución permanece operativo para cumplir con su propósito en circunstancias normales. Los problemas de disponibilidad de un sistema repercuten directamente en su fiabilidad.

Conseguir una fiabilidad alta (High Availability) no es nada sencillo, aunque pueda parecer lo contrario. Es una cuestión que debe analizarse desde antes de diseñar nuestra solución.

Por ejemplo, si un servicio necesita estar en funcionamiento incluso cuando se caiga una región entera, es importante diseñarlos utilizando grupos de recursos repartidos por diferentes regiones. A ello habrá que añadirse una conmutación por error automática que se active por caída en alguna región. Es decir, habría que eliminar los puntos únicos de fallo, como una base de datos maestra en una región ya que puede causar una interrupción global cuando no se puede acceder a ella.

Este punto no se resuelve siempre de la misma manera porque depende de dónde despleguemos nuestras aplicaciones (App Engine, GKE, Cloud Run...). La recomendación general es que cualquier solución de infraestructura se diseñe siempre pensando en este punto.

Otro aspecto a tener en cuenta son los cuellos de botella de escalado. Si, por ejemplo, usamos más núcleos de CPU de los que tenemos en cada núcleo en un escalado vertical, nunca conseguiremos una HA.

Ejemplo de un cluster de HA en GKE

RTO para una Alta Disponibilidad

Otro valor indispensable para que una infraestructura pueda ser considerada de Alta Disponibilidad es el de “restablecimiento”. Por ello es importante calcular el tiempo en que un sistema puede estar caído sin que sea crítico para el negocio. A este lapso se conoce como Tiempo Objetivo de Recuperación o RTO (Recovery Time Objective). 

Con este valor se expresa 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 sin que ello afecte a la continuidad del negocio.

Siempre que se produce una caída del sistema hay un volumen determinado de datos que se pierden. Se trata, en concreto, de toda la información que haya circulado desde la última copia de seguridad hasta la caída. Conocer qué volumen de datos estamos dispuestos a perder o a tener que reintroducir al sistema, influirá de forma indirecta en la disponibilidad del mismo. A este valor se le conoce como RPO (Recovery Point Objective) y a diferencia del RTO no tiene que ver con el tiempo de recuperación, sino con la cantidad de datos a restablecer.

Preparar los eventos

Si prevemos que nuestro sistema tendrá picos de tráfico en periodos concretos, es necesario preparar nuestra aplicación. Invertir tiempo en esta preparación ahorrará pérdidas significativas de visitas e ingresos. 

Para proyectos que ya tengan cierto recorrido puede ser más fácil prever cómo será ese aumento puntual. En nuevos proyectos, deberá ser una estimación. En cualquier caso es imprescindible asegurarse de que el sistema tiene suficiente capacidad de cálculo para soportar ese pico.

Además de añadir un búfer, se recomienda probar la carga del sistema con la combinación prevista de solicitudes de los usuarios. El objetivo es asegurarse de que su capacidad estimada de gestión coincide con la real.

Realice ejercicios en los que su equipo de operaciones lleve a cabo simulacros de interrupción, ensayando sus procedimientos de respuesta y ejercitando los procedimientos de gestión de incidentes de colaboración entre equipos.

Prever los incidentes

La última de las épicas a tener en cuenta en lo que a fiabilidad se refiere es en lo referente a la recuperación de desastres. Cuando hablamos de Alta Disponibilidad, es imprescindible tener una estrategia de recuperación, ya que los incidentes ocurren. Por ello no solo es necesario estar preparado, sino también disponer de buenos procedimientos para que el tiempo de recuperación (RTO) sea bajo.

Para asegurar que el sistema está bien diseñado se requiere:

• Determinar puntos de recuperación (RP)
• Establecer un buen plan de pruebas de desastre, para simular este tipo de situaciones con frecuencia y estresar al sistema.

Para conseguirlo, se necesita tener un buen diseño de puntos de recuperación (RP), así como un plan de pruebas. 

Como pieza central se encuentra el buen diseño de los pipelines CI/CD (Integración Continua / Desarrollo Continuo) para construir estrategias automatizadas de desarrollo, despliegue y pruebas de lanzamiento con herramientas como Cloud Build que es una solución serverless con un alto Service Level Agreement (SLA).

Automatizar para mejorar la Disponibilidad

La disponibilidad de un sistema puede abordarse desde diferentes perspectivas: tráfico, casos de uso, plataformas donde se despliega… Pero, en cualquier caso, si hay que centrarse en algo esto sería: reducir el trabajo y automatizar al máximo. En ese orden.

En efecto, automatizar es útil, pero no es la panacea. Conlleva costes iniciales de desarrollo y configuración y, posteriormente, también otros de mantenimiento. Además puede suponer riesgos para la fiabilidad de un sistema. Por eso, antes de llevar a cabo la automatización de procesos conviene eliminar determinadas tareas y trabajos. Hay algunas áreas principales identificadas en las que se puede hacer esto con la automatización configurable proporcionada por Google:

Además existe AutoML para el entrenamiento automático de modelos de Machine Learning. Por último jMeter y Locust para pruebas de carga con las que garantizar el rendimiento.