SLA del 99,9%: qué falla puede esconderse detrás de una cifra bonita

El indicador general está en verde, pero un método de pago no funciona para nadie. Puede pasar incluso con una disponibilidad bien calculada: un método poco usado casi no influye en el promedio. Un SLA útil empieza por preguntarse qué problema mide el porcentaje y de quién, qué eventos entran en él y qué hace el equipo antes de que termine el mes.

Revise a quién oculta el denominador

Supongamos 100 000 solicitudes válidas en una ventana. El método principal produjo 99 900 resultados técnicos exitosos. Al segundo método le correspondieron 100 solicitudes, y todas terminaron con un error técnico. La disponibilidad total es del 99,9%; la del segundo método, del 0%. Es un ejemplo hipotético aislado, no datos de un servicio real.

Un informe así puede seguir con exactitud la fórmula general y aun así resultar insuficiente para el negocio. Defina de antemano los segmentos críticos: método, país, moneda o una ruta concreta. En muestras pequeñas, muestre la cantidad de operaciones afectadas y la secuencia de errores; un porcentaje con varios decimales da una impresión de precisión que no existe.

No agregue cientos de cortes sin responsables. Elija aquellos para los que el equipo realmente tomará decisiones distintas: revisar una integración concreta, avisar a soporte o modificar temporalmente el flujo que se ofrece al cliente dentro de los límites permitidos. Cada indicador debe tener un destinatario claro.

Primero, separe tres conceptos

El SLI es el indicador que se mide, el SLO fija su valor objetivo y el SLA formaliza el acuerdo y las consecuencias de incumplirlo. Google SRE también llama la atención sobre la distribución de la latencia: el promedio puede ocultar una pequeña proporción de respuestas muy lentas. Fuente: Google SRE, Service Level Objectives.

Para una integración de pagos, describa por separado tres intervalos: desde el envío de la solicitud hasta la respuesta de la API, desde la creación de la operación hasta el estado final elegido y desde que ocurre el evento hasta que su sistema recibe la notificación. Cada intervalo tiene sus propias causas de demora. El tiempo que el usuario dedica a confirmar en la app del banco debe mostrarse aparte del tiempo de procesamiento de la infraestructura.

La disponibilidad también necesita un denominador

Con una definición basada en tiempo, un 99,9% en 30 días hipotéticos equivale a 43,2 minutos sin servicio, si se cuenta todo el período sin excepciones. Con una definición basada en solicitudes, el mismo porcentaje significa otra cosa: de 100 000 solicitudes válidas, el presupuesto admisible es de 100 fallidas. No se puede convertir un enfoque en el otro sin datos de carga. Diez minutos de caída en hora pico pueden afectar a más operaciones que una hora de madrugada.

El Google SRE Workbook propone construir muchos indicadores como la relación entre los eventos válidos exitosos y todos los eventos contabilizados. El valor práctico de este enfoque está en definir de forma explícita el numerador, el denominador y el umbral. Fuente: Google SRE Workbook, Implementing SLOs.

Para la disponibilidad técnica, un rechazo del banco procesado correctamente puede contar como una respuesta exitosa del servicio. Para la conversión de pago, no será un éxito. Separe estos indicadores en los informes desde el principio. Acuerden también cómo contar los tiempos de espera agotados: si las solicitudes lentas desaparecen de la muestra antes de que se registre su duración, el gráfico de latencia puede mejorar justo durante la falla.

Por qué el tiempo promedio no basta

Tomemos 1 000 solicitudes hipotéticas: 980 terminaron en 0,2 segundos y las 20 restantes, en 10 segundos. El promedio es de 0,396 segundos. La cifra parece bastante tranquila, aunque veinte usuarios sufrieron una espera notable. Con el método del rango más cercano, aquí el p95 es de 0,2 segundos y el p99, de 10 segundos.

El percentil p99 describe el límite para aproximadamente el 99% de las observaciones de la muestra elegida. No fija un tiempo máximo ni garantiza el resultado de la siguiente solicitud. Muestre siempre el tamaño de la muestra y la ventana de medición. En un método de pago poco usado, el reducido número de operaciones vuelve inestables los percentiles altos; junto a ellos conviene ver la cantidad absoluta de casos lentos.

No promedie el p99 de distintos servidores o días para obtener un p99 general. Prometheus advierte de forma explícita que los cuantiles ya calculados no pueden agregarse así; los histogramas permiten combinar distribuciones si se cumplen los requisitos de su estructura. Fuente: Prometheus, Histograms and summaries.

El mes contractual es demasiado largo para la guardia

Separe el informe de cumplimiento del acuerdo de la señal que exige un análisis inmediato. La cifra mensual sirve para la evaluación contractual; al operador le importan los errores recientes, la cantidad de pagos pendientes y la antigüedad de la operación indeterminada más vieja. Configure umbrales internos según sus propias observaciones y el daño admisible, sin presentar un umbral universal inventado como estándar del sector.

Para reclamar al proveedor, conserve identificadores anonimizados, la ventana exacta con zona horaria, el resultado esperado, los códigos reales y el volumen del flujo afectado. Indique cómo se seleccionaron los ejemplos. Cinco pagos problemáticos sirven para el diagnóstico, pero sin el total no se puede evaluar la magnitud.

Defina aparte qué hacer cuando se pierden observaciones. Si un contador dejó de actualizarse, una tasa de errores nula no justifica declarar la recuperación. Contraste registros independientes y colas de trabajo. Es razonable cerrar el incidente después de confirmar que se recuperó el paso necesario para el cliente y de revisar los resultados desconocidos acumulados: que la API esté disponible no explica qué pasó con las solicitudes durante la falla.

Qué debe definirse antes de firmar

• La operación y los límites de la medición: API concreta, método de pago, región, estado del resultado.
• La ventana de cálculo, la zona horaria, la fuente de datos y el volumen mínimo de observaciones.
• Las reglas para contabilizar errores, tiempos de espera agotados, reintentos y eventos excluidos.
• Los umbrales de latencia y disponibilidad, alineados con el proceso real.
• El procedimiento de notificación, escalamiento, presentación de pruebas y revisión del incumplimiento.

Conserve también el indicador general de fallas que percibe el usuario, aunque el contrato excluya parte de las causas. El cliente igual tiene que esperar cuando el problema es de un participante externo. El reparto legal de responsabilidades y el diagnóstico de la experiencia del cliente resuelven tareas distintas y deben seguir visibles al mismo tiempo.

En la próxima revisión, tome el método más problemático y reconstruya su recorrido desde la solicitud hasta el resultado para el cliente. Compare ese recorrido con lo que el SLA cubre realmente. La diferencia entre ambos mostrará qué observación o condición del acuerdo conviene precisar primero.