Monitorización de SLA: cómo medir y demostrar el uptime
La monitorización de SLA es la práctica de comprobar de forma independiente la disponibilidad de un servicio, para tener evidencia con marca de tiempo de si cumplió el porcentaje de uptime que promete un acuerdo de nivel de servicio. Esa evidencia importa sobre todo en una disputa, porque el panel del propio proveedor no es un testigo neutral de su propia indisponibilidad.
¿Qué es la monitorización de SLA?
Un SLA (acuerdo de nivel de servicio) es un contrato que fija un objetivo de disponibilidad concreto, normalmente un porcentaje mensual de uptime como el 99,9%, y establece qué ocurre si el proveedor no lo cumple: por lo general un crédito de servicio, a veces el derecho a cancelar. La monitorización de SLA es el trabajo de medición continuo que sostiene ese contrato: comprobar el endpoint prometido desde fuera de la red del propio proveedor, registrar cada caída con una marca de tiempo y consolidar el resultado en el porcentaje que importa según el contrato. Sin ese registro independiente, si un SLA se cumplió o no depende de en qué números confíes.
Las dos partes tienen motivos para hacerlo. El cliente quiere pruebas antes de presentar una reclamación de crédito. El proveedor quiere tener su propio número honesto antes de que la monitorización del cliente detecte un problema primero.
SLA frente a SLO frente a SLI
Los tres términos se usan a menudo de forma imprecisa, pero describen tres cosas distintas, en este orden: medida, objetivo, promesa.
| Término | Qué es | Ejemplo |
|---|---|---|
| SLI (Service Level Indicator) | La medición real, un número calculado a partir de verificaciones reales | Uptime medido desde puntos de verificación externos durante los últimos 30 días |
| SLO (Service Level Objective) | Un objetivo interno para ese indicador, sin ninguna consecuencia contractual asociada | "Aspiramos a un 99,95% de uptime este trimestre" |
| SLA (Service Level Agreement) | Una promesa contractual construida sobre uno o más SLO, con una consecuencia declarada si no se cumple | "99,9% de uptime mensual, o un crédito de servicio proporcional" |
La prueba práctica: si no alcanzar el número no tiene ninguna consecuencia por escrito en ningún sitio, es un SLO, no un SLA.
Lo que un SLA de uptime permite en realidad
Cada décima de punto porcentual importa más de lo que parece. Esto es lo que permite cada nivel habitual de SLA antes de incumplirse, para un mes continuo de 30 días y un año de 365 días:
| Objetivo de SLA | Indisponibilidad permitida por mes (30 días) | Indisponibilidad permitida por año |
|---|---|---|
| 99% | 7 h 12 min | 3 días 15 h 36 min |
| 99,5% | 3 h 36 min | 1 día 19 h 48 min |
| 99,9% | 43 min 12 s | 8 h 45 min 36 s |
| 99,95% | 21 min 36 s | 4 h 22 min 48 s |
| 99,99% | ~4 min 19 s | ~52 min 34 s |
El salto del 99,9% al 99,99% recorta la indisponibilidad permitida en un 90%, de unos 43 minutos al mes a unos 4 minutos. Consulta cómo calcular el uptime para ver la fórmula subyacente y el razonamiento de cada nivel.
Qué medir para que el número resista una disputa
- Comprueba desde fuera de la red del proveedor, y desde más de una ubicación. Una verificación que empieza y termina en la infraestructura que está probando no puede ver una caída de red que aísle esa infraestructura de internet.
- Ajusta el intervalo de verificación al nivel del SLA. Un intervalo de 5 minutos no puede probar ni refutar de forma fiable un objetivo del 99,99%, porque todo el margen mensual permitido es menor que un solo ciclo de verificación.
- Exige confirmación desde una segunda ubicación antes de contar la indisponibilidad. Un fallo puntual en la red de una sola ubicación no es una caída del proveedor; un incidente que solo se abre cuando varias ubicaciones coinciden mantiene ese ruido fuera del número.
- Excluye únicamente las ventanas de mantenimiento que el SLA documenta de verdad. El mantenimiento no anunciado sigue contando como indisponibilidad; una ventana acordada de antemano por ambas partes no cuenta.
- Mide exactamente el endpoint que nombra el contrato, no una ruta de health-check que responde 200 sin importar si el servicio real funciona.
- Aplica el umbral de tiempo de respuesta del SLA, si lo tiene. Algunos acuerdos definen "caído" como más lento que un tiempo de respuesta declarado, no solo como inalcanzable.
- Conserva el registro bruto de verificaciones, no solo el porcentaje consolidado. Una disputa necesita marcas de tiempo, códigos de respuesta y duraciones, no un único número sacado de una hoja de cálculo.
Cómo configurar la monitorización de SLA paso a paso
- Anota el endpoint exacto, la métrica (uptime, tiempo de respuesta, o ambos) y la ventana de medición que especifica el SLA. Una verificación contra la URL equivocada o la zona horaria equivocada produce un número que nadie puede usar.
- Fija un intervalo de verificación lo bastante corto para el nivel que estás demostrando. Como regla general, mantenlo muy por debajo de la caída más pequeña que permite el objetivo, así que un objetivo del 99,9% necesita un intervalo medido en minutos, no en decenas de minutos.
- Ejecuta las verificaciones desde varias ubicaciones independientes fuera de la propia infraestructura del proveedor, repartidas por las regiones que importan. HostTracker verifica desde más de 300 puntos de verificación en 158 ciudades, así que puedes elegir ubicaciones cercanas a donde están tus usuarios reales.
- Activa una regla de reverificación o confirmación para que el fallo de una ubicación tenga que confirmarlo otra antes de contar como indisponibilidad.
- Si el SLA fija un umbral de tiempo de respuesta, configúralo como una condición de fallo, no solo como un resultado lento pero aprobado.
- Añade a la configuración de la monitorización las ventanas de mantenimiento que ambas partes acordaron, para que queden excluidas automáticamente de la cifra de uptime en lugar de a mano al generar el informe.
- Programa un informe de uptime recurrente con la misma periodicidad con la que se mide el SLA, semanal o mensual, para que el número nunca se monte por primera vez durante una disputa.
Cómo informar sobre un SLA
Un informe programado cierra el ciclo entre medir y demostrar. Un informe de uptime semanal o mensual, enviado automáticamente a quien gestiona la relación en ambos lados, convierte el registro bruto de verificaciones en el número contra el que está escrito el SLA antes de que nadie tenga que pedirlo. Una página de estado pública hace el mismo trabajo para cualquiera fuera de esa lista de distribución: un registro compartido y con marca de tiempo de uptime e incidentes que ninguna de las dos partes tiene que aceptar solo de palabra. Consulta qué muestra realmente una página de estado si todavía no has configurado una. Una vez que tengas los resultados de verificación de un periodo, pasarlos por una calculadora de uptime te da el porcentaje sin hacer la cuenta a mano.
Errores habituales
- Medir desde dentro de tu propia red. Una verificación que empieza y termina en infraestructura que controlas no puede ver una caída que solo afecta a cómo te alcanza el mundo exterior.
- Promediar el uptime entre varios servicios o regiones. Un único número combinado puede esconder un servicio que incumplió el SLA mientras otros elevaban la media de vuelta.
- Contar solo las caídas completas. Si el SLA tiene una cláusula de tiempo de respuesta, un servicio que responde pero va mucho más lento que el umbral también está incumpliendo, aunque nunca haya llegado a caer del todo.
- Usar un intervalo de verificación de 5 minutos contra un objetivo del 99,99%. Las cuentas no salen: el 99,99% permite unos 4 minutos de indisponibilidad al mes, menos que un solo ciclo de verificación, así que el intervalo no puede determinar si se cumplió el objetivo.
Preguntas frecuentes
¿Cómo se calcula el uptime de un SLA?
De la misma forma que se calcula cualquier porcentaje de uptime: (tiempo total menos indisponibilidad) dividido entre tiempo total, multiplicado por 100. La parte específica del SLA es qué indisponibilidad cuenta: solo las caídas contra el endpoint y la ventana exactos que nombra el contrato, con el mantenimiento acordado excluido. Consulta cómo calcular el uptime para ver la fórmula completa y ejemplos resueltos.
¿El mantenimiento cuenta contra un SLA?
Solo si no se acordó de antemano. La mayoría de los SLA excluyen el mantenimiento programado que ambas partes documentaron con antelación, pero la indisponibilidad por un cambio no anunciado, o una corrección de emergencia etiquetada como "mantenimiento" después de ocurrida, sigue contando. La exclusión es para la ventana divulgada, no para la palabra en sí.
¿Qué es un buen SLA de uptime?
El 99,9% es un piso habitual para un servicio comercial, y permite unos 43 minutos de indisponibilidad al mes. El 99,95% es un compromiso razonable de nivel medio, y el 99,99% es un compromiso serio que deja solo unos minutos al mes, difícil de alcanzar sin infraestructura redundante y un mantenimiento disciplinado. Trata cualquier promesa de 100% como una afirmación de marketing y no de ingeniería; la tabla de arriba muestra por qué.
¿Cómo reclamo créditos de SLA?
El planteamiento general es parecido entre proveedores: reúne tu propia evidencia de monitorización del periodo afectado (marcas de tiempo, el endpoint comprobado, la indisponibilidad confirmada), compárala con la página de estado o el registro de incidentes del propio proveedor, y presenta una reclamación por el canal de soporte del proveedor dentro del plazo que fija su contrato, a menudo un número concreto de días tras el incidente. Consulta el documento de SLA del proveedor específico para su plazo exacto y la evidencia requerida, ya que estos detalles varían y pueden caducar rápido.
¿Puede una sola ubicación de monitorización demostrar por sí sola el cumplimiento de un SLA?
No de forma fiable. Una sola ubicación no puede distinguir una caída real de un problema en su propia ruta de red hasta el proveedor, que es exactamente el tipo de falso positivo que una disputa de SLA no puede permitirse. La confirmación desde más de una ubicación independiente antes de contar una caída es lo que hace defendible el número resultante.