El SLA de un broker MQTT es el compromiso por escrito de un proveedor sobre la disponibilidad, y la letra pequeña importa tanto como el porcentaje del titular. Este artículo traduce los objetivos de disponibilidad habituales a minutos reales de caída, explica qué suelen cubrir y excluir los SLA y muestra cómo diseñar tus dispositivos y aplicaciones para que afronten con soltura la caída que cualquier SLA sigue permitiendo.
Qué es un SLA y qué no es
Un acuerdo de nivel de servicio es un documento contractual. Define un objetivo medible, normalmente la disponibilidad mensual, cómo se mide esa disponibilidad y qué te debe el proveedor si no se alcanza. Hay tres términos relacionados que a menudo se confunden:
- SLI (service level indicator): el valor medido, como el porcentaje de intentos de conexión correctos.
- SLO (service level objective): el objetivo interno al que aspira un equipo, a menudo más estricto que el SLA.
- SLA (service level agreement): la promesa externa y contractual con consecuencias, normalmente créditos de servicio.
El punto clave: un SLA no evita las caídas. Define cuánta indisponibilidad es aceptable y cómo se te compensa cuando hay más. Tu sistema sigue teniendo que gestionar la caída que el SLA permite.
Porcentajes de disponibilidad en minutos de caída
Las diferencias entre "nueves" son mayores de lo que parecen. La tabla usa un mes medio de unos 30,4 días y un año de 365 días.
| Disponibilidad | Caída al mes | Caída al año |
|---|---|---|
| 99 % | unas 7 horas y 18 minutos | unos 3 días y 15,6 horas |
| 99,5 % | unas 3 horas y 39 minutos | 1 día y 19,8 horas aprox. |
| 99,9 % | unos 43,8 minutos | unas 8,8 horas |
| 99,95 % | unos 21,9 minutos | unas 4,4 horas |
| 99,99 % | unos 4,4 minutos | unos 52,6 minutos |
| 99,999 % | unos 26 segundos | unos 5,3 minutos |
Pasar del 99,9 % al 99,99 % divide por diez la caída permitida. Lograrlo exige redundancia entre dominios de fallo, failover automatizado y una gestión de cambios cuidadosa, por eso los niveles más altos suelen ir ligados a infraestructura dedicada y acuerdos enterprise.
Puedes calcular estos valores tú mismo:
def allowed_downtime(availability_pct, period_minutes):
return period_minutes * (1 - availability_pct / 100)
MONTH = 30.44 * 24 * 60
YEAR = 365 * 24 * 60
for a in (99.0, 99.5, 99.9, 99.95, 99.99, 99.999):
print(f"{a}%: {allowed_downtime(a, MONTH):.1f} min/month, "
f"{allowed_downtime(a, YEAR) / 60:.2f} h/year")
Qué suele cubrir el SLA de un broker MQTT
Definición de caída
Lee cómo se define "no disponible". Para un broker, puede significar que el endpoint no acepta nuevas conexiones, que falla un porcentaje de los intentos de conexión o que los mensajes no se entregan. Algunos acuerdos solo cuentan las caídas que duran más de unos minutos consecutivos, lo que significa que los cortes breves no cuentan en absoluto.
Método de medición
¿Quién mide y desde dónde? La monitorización del proveedor puede ver el broker sano mientras tus dispositivos en una red concreta no pueden alcanzarlo. Pregunta si puedes aportar tus propios datos de monitorización al reclamar créditos.
Alcance
Comprueba qué componentes están cubiertos: endpoints de conexión, listeners TLS y WebSocket, el portal de gestión y las API usadas para el aprovisionamiento. Los portales y las API suelen cubrirse de forma distinta al plano de datos, o no cubrirse en absoluto.
Créditos de servicio
Cuando no se alcanza el objetivo, el remedio habitual es un crédito: un porcentaje de la cuota mensual, a menudo escalonado según cuánto haya caído la disponibilidad. Los créditos suelen tener que reclamarse dentro de un plazo y rara vez son proporcionales al impacto de una caída en el negocio. Considera los créditos un incentivo para el proveedor, no un seguro para ti.
Exclusiones habituales
Casi todos los SLA excluyen algunos eventos. Las exclusiones típicas incluyen:
- El mantenimiento programado anunciado con antelación.
- Los problemas causados por los propios dispositivos, redes o errores de configuración del cliente.
- Superar los límites del plan, como las cuotas de conexiones o mensajes.
- Los casos de fuerza mayor.
- Los niveles gratuitos, de prueba o beta.
- Los problemas en redes de terceros entre tus dispositivos y el proveedor.
Los niveles gratuitos, en particular, rara vez incluyen un SLA contractual. Es razonable para desarrollo y pilotos, pero los compromisos de producción con tus propios clientes deben apoyarse en un plan con condiciones explícitas.
Disponibilidad compuesta: tu sistema es una cadena
Tu disponibilidad de extremo a extremo no es la disponibilidad del broker. Un mensaje de un sensor pasa por el dispositivo, la red local, el proveedor móvil o de internet, el broker, tu backend y tu base de datos. Cuando los componentes están en serie, las disponibilidades se multiplican.
Por ejemplo, si la red de un dispositivo tiene un 99,5 % de disponibilidad, el broker un 99,9 % y tu backend un 99,9 %, la cadena queda aproximadamente en 0,995 x 0,999 x 0,999, en torno al 99,3 %. El eslabón más débil manda. Invertir mucho en los nueves del broker mientras tu backend corre en un único servidor aporta poco. Para patrones de arquitectura, consulta alta disponibilidad de un broker MQTT.
Diseñar para la caída que permite un SLA
Incluso con un 99,99 %, un broker será inalcanzable de vez en cuando. Construye clientes que lo toleren:
- Reconecta con backoff exponencial y jitter, para que miles de dispositivos no se reconecten en el mismo instante.
- Almacena en búfer localmente en dispositivos y gateways, y publica cuando vuelva la conexión.
- Usa sesiones persistentes con una expiración de sesión adecuada, para que los mensajes QoS 1 y 2 destinados a suscriptores desconectados queden en cola.
- Usa retained messages para el estado, de modo que los paneles vean el último valor conocido justo después de reconectar.
- Configura un Last Will para que tu backend sepa cuándo se ha caído un dispositivo de forma inesperada.
- Monitoriza desde fuera con un cliente sintético que publique y reciba un heartbeat.
La guía sobre la caída de un broker MQTT cubre el lado de los incidentes, y el checklist de MQTT en producción convierte estos puntos en tareas previas al lanzamiento.
Disponibilidad no es lo mismo que durabilidad
Un objetivo de disponibilidad indica si el broker acepta conexiones y enruta mensajes. No dice nada sobre si cada mensaje se conserva durante un incidente. Pregunta por separado cómo se comportan las sesiones, los mensajes en cola y los retained messages cuando un nodo del broker se reinicia o hace failover, y diseña en función de la respuesta. Si perder un mensaje saliera caro, mantén la fuente de verdad en el dispositivo o en tu backend y haz del broker un transporte, no un almacén. Los tiempos de respuesta del soporte son un tercer compromiso, independiente, que merece una lectura atenta.
Preguntas antes de firmar
| Pregunta | Por qué importa |
|---|---|
| ¿Cómo se mide la disponibilidad y quién la mide? | Determina qué cuenta como caída |
| ¿Cuál es la duración mínima de caída que se contabiliza? | Las caídas cortas pueden quedar excluidas |
| ¿Se excluye el mantenimiento programado y con cuánta antelación se avisa? | La caída planificada sigue afectando a los dispositivos |
| ¿Qué componentes están cubiertos? | El portal y las API pueden diferir de los endpoints |
| ¿Cómo se calculan y reclaman los créditos? | Se aplican plazos y topes |
| ¿Hay una página de estado e historial de incidentes? | Muestra el historial real |
| ¿Qué tiempos de respuesta de soporte se aplican? | La disponibilidad y el soporte son compromisos distintos |
Los SLA y ConnectMQ
ConnectMQ ofrece varios planes, desde un nivel Serverless gratuito en un clúster compartido hasta clústeres aislados Dedicated, BYOC en tu propia cuenta de nube gestionado por ConnectMQ y Self Managed Enterprise. Si tu proyecto necesita condiciones contractuales de disponibilidad, coméntalas con el equipo de ConnectMQ para las opciones Dedicated, BYOC o enterprise, y usa las preguntas anteriores para revisar lo que se ofrece. Sean cuales sean las condiciones, las prácticas del lado del cliente de este artículo son las que mantienen sana tu flota cuando cualquier broker tiene un mal día.
Empieza con ConnectMQ
Construye y prueba tu lógica de reconexión y búfer en un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, o experimenta primero en el servidor MQTT público gratuito. Para hacerte una idea de lo que te quita de encima un broker MQTT gestionado y de cómo se comparan los modelos de alojamiento, lee la guía de broker MQTT en la nube.
Preguntas frecuentes
¿Cuánta caída permite un SLA del 99,9 %?
Unos 43,8 minutos al mes, o aproximadamente 8,8 horas al año.
¿Garantiza un SLA que mis dispositivos seguirán conectados?
No. Define un objetivo de disponibilidad y la compensación si no se cumple. Tus dispositivos siguen necesitando lógica de reconexión, búfer y monitorización.
¿Incluyen SLA los planes gratuitos de broker MQTT?
Los niveles gratuitos no suelen incluir SLA contractuales. Úsalos para desarrollo y pilotos, y elige un plan con condiciones explícitas para los compromisos de producción.
¿Es siempre mejor un 99,99 % que un 99,9 %?
Permite diez veces menos caída, pero tu disponibilidad de extremo a extremo depende de cada componente de la cadena. Mejora primero el eslabón más débil.
