Toda plataforma se cae en algún momento. La tuya, la de tu competidor, la del hyperscaler que hay debajo de ambas: la disponibilidad es un porcentaje, no una promesa de inmortalidad, y un proveedor de servicios gestionados que no ha planificado la mala hora está apostando la relación con el cliente a la suerte. La posición del revendedor tiene una estructura incómoda: cuando la plataforma falla, el cliente te llama a ti, no al proveedor, porque el logotipo del portal es el tuyo. Pero una caída bien gestionada no es solo contención de daños. Los MSP que ejecutan una rutina disciplinada de incidentes salen de los cortes con más confianza del cliente de la que tenían al entrar, porque el corte es el único momento en el que el cliente te ve trabajar de verdad.
La rutina de abajo va desde antes del incidente hasta después.
Antes: entérate tú primero, y sabe qué significa “caído”
La versión imperdonable de una caída es enterarte por un cliente. La monitorización independiente es el remedio: una comprobación externa que ejercita el camino real del cliente, dato que entra, lectura de API, carga del portal, desde fuera de la infraestructura de la propia plataforma, además de una suscripción a la página de estado del proveedor. TagoIO publica su estado en status.tago.io, y tu monitorización debería referenciarlo automáticamente. La capa de detección es también donde te ayudan Analytics y las comprobaciones de salud de la propia plataforma: la detección de anomalías a nivel de flota distingue “el gateway de una sede se quedó sin corriente” de “la ingesta se detuvo en todas partes a la vez”, que son incidentes distintos con primeras acciones distintas.
Igual de importante es saber qué significa caído para tu servicio en concreto. Una pila IoT falla por capas, sensores, conectividad, network server, plataforma, integraciones, y las cláusulas de alcance de tu SLA ya deberían mapear quién es dueño de cada capa. Vimos cómo cambian esos documentos al pasar a servicios recurrentes. La mayoría de los tickets de “plataforma caída” son en realidad conectividad o hardware, y diagnosticar la capa en los primeros diez minutos decide si comunicas un corte o envías una visita a la instalación.
Durante: usa buffer donde puedas, comunica en serio
Dos propiedades del IoT amortiguan la mayoría de las caídas de plataforma, y tu arquitectura debería aprovechar ambas.
Primero, los network servers LoRaWAN y la mayoría de los gateways hacen buffer o reintentan los uplinks, y los dispositivos siguen midiendo de todos modos, así que una caída de la capa de almacenamiento suele significar dato retrasado, no dato perdido. Conocer el comportamiento real de buffer de tu pila, cuánto tiempo y en qué capa, convierte “¿se han perdido mis datos?” en una pregunta que puedes responder con precisión, y es una pregunta que hace todo cliente.
Segundo, los componentes de borde mantienen viva la lógica local: cuando un caso de uso no tolera de verdad los huecos de nube, una capa en las instalaciones como TagoCore mantiene funcionando alertas y control locales durante un incidente en la nube, y eso pertenece a la conversación de diseño para despliegues críticos, no a la disculpa posterior.
Luego la parte que los MSP subestiman: la cadencia de comunicación vale más que el contenido de la comunicación. La rutina que funciona es fija y aburrida. Avisa a todos los clientes afectados en los primeros 30 minutos, antes de que abran tickets, con lo que sabes, lo que sigue funcionando y cuándo llega la siguiente actualización. Actualiza en el horario prometido incluso cuando la actualización es “sin cambios”. Nunca especules con un plazo de arreglo que no controlas; traslada la estimación del proveedor, etiquetada como tal. Los clientes perdonan las caídas con una consistencia sorprendente. No perdonan el silencio.
Durante: para qué servía tu SLA
El incidente es donde el papeleo demuestra su valor. Los niveles de severidad encaminan la respuesta, las cláusulas de alcance evitan que te disculpes por una caída de la operadora, y la alineación entre tu SLA con el cliente y el SLA de tu proveedor decide si un mes malo te cuesta margen o solo créditos que se compensan aguas arriba. Si un incidente revela un hueco entre los dos documentos, eso es un arreglo contractual, no solo una lección operativa.
Después: la rutina que convierte cortes en renovaciones
Cuando el servicio vuelve, tres pasos cierran el círculo como es debido.
Verifica la integridad de los datos antes de cantar victoria: comprueba que llegaron los uplinks en buffer, rellena los huecos donde la pila lo permita y dile a los clientes qué muestra realmente el registro de datos para la ventana del corte. Envía una nota breve posterior al incidente en 48 horas, qué pasó, cuál fue el impacto, qué cambia, en lenguaje claro y sin que la pidan. Aplica los créditos de servicio de forma proactiva si el SLA los activa; que la factura llegue ya corregida vale más voluntad que el crédito en sí.
Después devuelve el incidente a la máquina: ¿necesita la monitorización una comprobación nueva?, ¿necesita un cliente crítico un componente de borde?, ¿refleja el precio de los niveles de soporte quién consumió de verdad las horas del incidente?
La conclusión silenciosa
Un MSP no puede prometer que una plataforma nunca falle. Lo que un MSP sí puede prometer, y cobrar por ello, es que el fallo se detecta en minutos, se diagnostica en la capa correcta, se comunica según un calendario, se amortigua donde la arquitectura lo permite y se cierra con una rendición de cuentas honesta. Eso es un producto, y es uno de los diferenciadores más fuertes que un servicio gestionado puede vender, precisamente porque la mayoría de los competidores lo improvisa.
También empieza con un proveedor en cuya base puedas confiar: estado publicado, SLA publicado, operación auditada. TagoIO da a los revendedores ese cimiento. Agenda una demo o empieza gratis.
