Aivorab

confiabilidad de API · SLA explicado · SLO vs SLA · cálculos de uptime · dependencias de terceros · presupuesto de errores

SLA de Uptime en APIs Explicado: Qué Significa Realmente el 99.9% para tu Stack

Una guía práctica para leer SLAs de uptime, entender la diferencia entre SLO y SLA, descifrar exclusiones y créditos, y por qué las garantías de confiabilidad de terceros se multiplican de formas que la mayoría de desarrolladores pasa por alto.

Publicado:

El Número en la Página No es el Número en tus Registros

Cuando eliges una API de terceros, lo primero que notas es el porcentaje de uptime. 99.9%. 99.95%. 99.99%. Parece un sello de confianza. Pero la brecha entre lo que ese número promete y lo que tu aplicación realmente experimenta es donde comienzan la mayoría de los problemas de confiabilidad.

Este artículo explica qué miden realmente los SLAs de uptime, cómo los SLOs difieren de los SLAs en la práctica, cómo leer las cláusulas de exclusiones y créditos que determinan si una garantía es real, y por qué las matemáticas de combinar múltiples dependencias de API son casi siempre peores de lo que cualquier proveedor anuncia.

Qué Significa Realmente el 99.9 Por Ciento de Uptime

Un SLA de uptime del 99.9% permite aproximadamente 43 minutos y 49 segundos de tiempo fuera de servicio por mes, o roughly 8 horas y 46 minutos por año. Un SLA del 99.95% permite cerca de 21 minutos y 54 segundos por mes. Un SLA del 99.99% permite poco más de 4 minutos y 22 segundos por mes.

Estos son máximos teóricos calculados contra un ciclo de facturación estándar. No consideran ventanas de mantenimiento programado que pueden estar excluidas, interrupciones parciales que afectan solo algunas solicitudes, ni el efecto acumulativo cuando tu aplicación depende de más de un servicio.

La diferencia entre 99.9% y 99.99% no es incremental. Es la diferencia entre roughly 8 horas de tiempo fuera de servicio anual y roughly 52 minutos. Para una API que tu aplicación llama en cada acción del usuario, esa brecha es la diferencia entre un servicio que se siente confiable y uno que frustra a los usuarios regularmente.

SLO versus SLA: Dos Promesas Diferentes

Los términos se usan indistintamente en conversaciones casuales, pero cumplen funciones diferentes y tienen distinto peso.

Un SLO, u Objetivo de Nivel de Servicio, es una meta interna. Es el nivel de confiabilidad que tu equipo se compromete a entregar a tus usuarios. La práctica de Google SRE define un SLO como un objetivo numérico preciso para la disponibilidad del sistema que enmarca cada discusión sobre si el sistema funciona con suficiente confiabilidad. El principio clave es que defines el nivel más bajo de confiabilidad con el que puedes salirte con la tuya para cada servicio. Mayor confiabilidad cuesta más operar, por lo que el SLO es un compromiso deliberado, no una meta aspiracional.

Un SLA, o Acuerdo de Nivel de Servicio, es un contrato externo. Es la promesa que un proveedor te hace, usualmente con consecuencias financieras si se rompe. Los SLAs se expresan típicamente como porcentajes de uptime con niveles de crédito definidos. AWS, por ejemplo, ofrece un SLA a Nivel de Región del 99.99% para EC2 desplegado en múltiples zonas de disponibilidad y un SLA a Nivel de Instancia del 99.5% para instancias individuales. La estructura de créditos es escalonada: caer por debajo del 99.99% pero por encima del 99.0% genera un crédito del 10%, por debajo del 99.0% genera 30%, y por debajo del 95.0% genera 100%.

La distinción práctica importa porque tu SLO interno y el SLA externo de un proveedor no son lo mismo. Tu SLO debe establecerse basándose en lo que tus usuarios experimentan. El SLA del proveedor es una garantía base que puede incluir exclusiones, metodologías de medición que favorecen al proveedor, y compensaciones que rara vez cubren el costo real del tiempo fuera de servicio para tu negocio.

Leyendo Exclusiones y Créditos del SLA

La letra pequeña en un SLA es donde viven los términos reales. La mayoría de los proveedores excluyen mantenimiento programado, eventos de fuerza mayor, y a veces incluso la degradación parcial de sus cálculos de uptime. Un servicio que devuelve errores 503 para la mitad de tus solicitudes durante un incidente aún puede contar como disponible bajo ciertas definiciones de medición.

Al evaluar un SLA, busca estos elementos específicos:

Cómo se mide la disponibilidad. ¿Es tasa de éxito de solicitudes del lado del servidor, donde el proveedor cuenta respuestas exitosas desde su infraestructura? ¿O es del lado del cliente, donde los fallos para alcanzar el servicio se incluyen? Las métricas del lado del servidor omiten fallos a nivel de red, problemas de DNS y tiempos de espera del cliente. Las mediciones del lado del cliente, a veces llamadas verificaciones canario, simulan tráfico real de usuario y capturan la experiencia completa.

Qué está excluido. El mantenimiento programado es la exclusión más común. Algunos proveedores excluyen completamente las ventanas de mantenimiento del cálculo de disponibilidad. Otros los cuentan como tiempo fuera de servicio. La distinción determina si un proveedor puede programar interrupciones extendidas sin activar créditos.

La estructura de créditos. Los créditos son típicamente un porcentaje de tu factura mensual por el servicio afectado. Casi nunca son reembolsos en efectivo. Se aplican como créditos de servicio futuros. Un crédito del 10% en una factura mensual de $500 son $50 en créditos, no $50 de vuelta en tu cuenta bancaria. Para un equipo pequeño, eso puede sentirse como un gesto significativo. Para una interrupción que cuesta a tu negocio miles en ingresos perdidos, es cuando mucho simbólico.

El proceso de reclamo. Algunos proveedores requieren que solicites créditos dentro de una ventana estrecha. Otros los aplican automáticamente. AWS indica que las instancias no disponibles por más de seis minutos en una hora del reloj se acreditan automáticamente, pero la mayoría de los SLAs requieren reclamos proactivos.

Las Matemáticas Compuestas de las Dependencias de Terceros

Aquí es donde la mayoría de los desarrolladores se llevan sorpresas. La disponibilidad de la aplicación sigue reglas de probabilidad. Cuando tu aplicación depende de múltiples servicios, todos ellos necesitan estar operativos para que tu aplicación funcione. Esto crea un efecto multiplicativo en los cálculos de disponibilidad.

Considera una aplicación que depende de dos servicios: uno con un SLA del 99.95% y otro con un SLA del 99.99%. La disponibilidad general no es el promedio. Es 0.9995 multiplicado por 0.9999, lo que iguala 99.94%. Ya has perdido 0.05% de disponibilidad comparado con tu eslabón más débil.

El efecto se compone rápidamente al agregar dependencias:

Diez dependencias, cada una calificada individualmente al 99.9%, producen una disponibilidad de aplicación del 99.0%. Eso son casi 9 horas de tiempo fuera de servicio por año en lugar de las 8.8 horas que permitiría cualquier servicio individual. Las matemáticas no se preocupan por tus decisiones de arquitectura. Solo se preocupan por cuántos puntos independientes de falla existen en tu ruta de solicitudes.

Por eso los despliegues multi-región y las estrategias de respaldo no son extras opcionales. Son la única forma de romper la cadena multiplicativa. Si una región de API falla, una región secundaria puede seguir sirviendo solicitudes y preservar la disponibilidad de todo el sistema.

Fallo Parcial: El Problema Oculto de Confiabilidad

La disponibilidad a menudo se trata como una condición binaria. El servicio está arriba o no lo está. Pero el fallo real rara vez es tan limpio. Un servicio puede estar parcialmente degradado, sirviendo solo algunas solicitudes, respondiendo lentamente a otras, o fallando solo para usuarios en ciertas regiones.

La práctica de Google SRE enfatiza que el fallo tiene un grado de impacto y a menudo se experimenta en algún subconjunto de la carga de trabajo. Puede afectar un porcentaje de usuarios, un porcentaje de solicitudes, un porcentaje de ubicaciones, o un percentil de latencia. Estos son modos de fallo parcial, y son la fuente más común de problemas de confiabilidad visibles para el usuario.

Un SLA que mide la disponibilidad como tasa de éxito de solicitudes del lado del servidor no capturará fallos parciales que ocurren antes de que las solicitudes alcancen la infraestructura del proveedor. Una medición del lado del cliente usando sondas canario capturará más de estos casos, pero incluso ese enfoque tiene puntos ciegos. Mide desde la ubicación de la sonda, no desde la ubicación de cada usuario.

Al evaluar una API de terceros, pregunta cómo mide el proveedor la disponibilidad y si su definición coincide con la experiencia que tus usuarios realmente tienen. Un proveedor que reporta 99.99% de disponibilidad basada en métricas del lado del servidor puede estar experimentando fallos parciales que tus usuarios sienten agudamente.

Diseñando tus Propios SLOs Antes de Elegir Proveedores

El paso más práctico que puedes dar es definir tus propios SLOs antes de evaluar garantías de terceros. La guía de Google SRE recomienda reunir a los equipos de producto, desarrollo y confiabilidad para lograr una comprensión común de la carga de trabajo, particularmente sus flujos críticos de usuario. Escribe diagramas de secuencia detallados para estos flujos. Identifica dónde los usuarios pueden elegir no tomar una acción, qué partes puedes medir, y qué partes dependen de terceros que no puedes controlar.

Enmarca el diseño de tus SLOs alrededor de la pregunta: qué es lo que mis usuarios realmente valoran. Esto te previene de optimizar métricas que se ven bien en papel pero que no reflejan la experiencia real del usuario. También te obliga a confrontar las dependencias que no puedes medir directamente.

Una vez que tienes tus SLOs definidos, puedes evaluar APIs de terceros contra ellos. Pide a los proveedores cómo miden la disponibilidad, qué está excluido, cómo funcionan los créditos, y si soportan arquitecturas multi-región o de respaldo. El número de SLA en la primera página es el punto de partida, no la respuesta.

FAQ

¿Es un SLA del 99.9% suficiente para una API en producción? Depende de tu SLO. El 99.9% permite cerca de 43 minutos de tiempo fuera de servicio por mes. Si tu aplicación no puede funcionar durante una interrupción, y la interrupción te cuesta más de lo que el crédito que recibirías, necesitas una garantía más alta o una estrategia de respaldo. Ningún número de SLA es universalmente suficiente.

¿Los créditos de servicio realmente compensan el tiempo fuera de servicio? Casi nunca. Los créditos son típicamente un pequeño porcentaje de tu factura mensual y se aplican como créditos de servicio futuros, no reembolsos en efectivo. El costo real del tiempo fuera de servicio para tu negocio es casi siempre muy superior al crédito que recibirías.

¿Debo confiar en las métricas de disponibilidad del lado del servidor de un proveedor? Úsalas como un dato más, no como la palabra final. Las métricas del lado del servidor omiten fallos del lado del cliente, problemas de red y degradación parcial. Si es posible, mide la disponibilidad desde tu propia infraestructura usando verificaciones canario o monitoreo del lado del cliente.

¿Cómo me protejo contra fallos de APIs de terceros? Implementa lógica de reintentos con retroalimentación exponencial, almacena en caché respuestas cuando sea apropiado, diseña rutas de respaldo que degraduen gracefulmente, y considera estrategias multi-región o multi-proveedor para dependencias críticas. Ninguna API de terceros es infinitamente confiable, y tu arquitectura debe reflejar esa realidad.

Fuentes