Un servicio puede emitir métricas y mostrar gráficas mientras su equipo no tiene una definición común de qué significa que funcione bien. La pregunta no es cuántos datos se pueden recolectar, sino qué comportamiento importa, qué señal lo representa y qué decisión se tomará al observarla. Sin esas definiciones, una métrica disponible puede convertirse en un objetivo por comodidad, no por pertinencia.
Partir de la experiencia que interesa
El libro de Google sobre ingeniería de confiabilidad define un indicador de nivel de servicio (SLI) como una medida cuantitativa cuidadosamente definida de algún aspecto del nivel de servicio proporcionado. Un objetivo de nivel de servicio (SLO) expresa un valor o rango objetivo para ese indicador, mientras que un acuerdo de nivel de servicio (SLA) contiene un compromiso con consecuencias asociadas (Service Level Objectives). Son piezas relacionadas, pero cumplen papeles distintos.
Antes de elegir el SLI, describa la experiencia o resultado que debe observarse. Una señal del servidor puede servir como aproximación si la experiencia directa no está disponible, pero su alcance debe quedar claro. El indicador podría representar solo una parte de un recorrido o una población particular. Documente qué eventos entran en la medición, cuáles se excluyen y de dónde proceden los datos.
Ejemplo hipotético: para un servicio que recibe solicitudes, el equipo podría estudiar si la respuesta permite completar la tarea prevista. Antes de contar resultados, tendría que definir qué solicitudes son válidas, qué salida se considera correcta y qué periodo de observación responde a la decisión. El ejemplo no propone umbrales y no describe un servicio real.
Definir el indicador y el objetivo
Una ficha útil distingue la especificación del indicador de su implementación técnica. La primera explica qué resultado importa; la segunda, cómo se obtiene la medida. Si ambas se mezclan, cambiar una herramienta puede alterar silenciosamente el significado del objetivo. Como criterio de trabajo, registre fórmula, unidad, población, fuente, ventana, exclusiones, lagunas conocidas y responsable de revisar la definición.
El SLO necesita un objetivo que las partes pertinentes comprendan y consideren adecuado para el producto. El Workbook de Google presenta los SLO como base para tomar decisiones sobre confiabilidad y ofrece orientación para ir ajustándolos de forma iterativa (Implementing SLOs). Copiar el porcentaje de otra organización no sustituye ese trabajo, y por eso conviene explicar qué experiencia informa el objetivo y qué incertidumbre permanece. Un umbral apropiado depende del servicio, sus usuarios, la calidad de datos y el propósito de la medición.
Un SLA tiene otra implicación: el texto del SRE Book lo caracteriza como un acuerdo explícito o implícito con usuarios que incluye consecuencias por cumplir o no cumplir los SLO que contiene. No todo objetivo interno es un SLA. La distinción importa al comunicar niveles de servicio: no debe presentarse una meta de ingeniería como promesa contractual si no hay un acuerdo que la respalde.
Relacionar señal con acción
La monitorización puede recopilar, procesar, agregar y mostrar datos cuantitativos; un tablero resume métricas seleccionadas; una alerta comunica una condición que requiere atención humana. El capítulo de Google sobre monitorización distribuida advierte que no hay vocabulario compartido de manera uniforme para todos estos conceptos, por lo que una organización debe definirlos al usarlos (Monitoring Distributed Systems).
Como criterio de trabajo, vincule cada alerta a un síntoma, una persona o equipo responsable y una primera acción clara. Un gráfico puede ayudar a investigar una tendencia sin requerir una notificación inmediata. Una alerta que no permite responder qué se observó o quién debe actuar merece revisión. No existe un umbral universal que convierta una variación en incidente; esa decisión depende del impacto, el servicio y el acuerdo operativo.
Distinguir el objetivo de la alerta evita que la notificación se convierta en una copia automática de todas las métricas. También permite revisar si la señal elegida representa un riesgo para el usuario o solo un detalle interno. Los criterios de urgencia deben ser comprensibles para quien recibe el aviso y compatibles con las responsabilidades reales del equipo.
Revisar supuestos y límites
Un indicador no cubre automáticamente toda la calidad del servicio. Puede omitir pasos, usuarios, dependencias o condiciones que no recoge su fuente de datos. Un periodo histórico tampoco predice sin más el comportamiento futuro. Registre límites conocidos y revise el modelo cuando cambien el producto, los recorridos o los instrumentos de medición.
Tampoco conviene confundir una medición con una explicación causal. Si una señal se desvía, puede señalar dónde investigar, pero por sí sola no identifica el origen. Mantenga la hipótesis separada del dato observado y documente qué comprobación permitiría distinguir causas posibles. Esta disciplina reduce el riesgo de convertir una correlación en una conclusión sobre el sistema.
Mantener una ficha operativa
Un registro conciso puede contener: resultado de interés, definición del SLI, SLO acordado, ventana, origen de datos, límites, alerta relacionada, responsable y fecha de revisión. Añada qué acción se espera al acercarse o exceder el objetivo y quién decide si debe cambiarse. Si el dato no está disponible o la definición está en disputa, deje explícita esa brecha en vez de rellenarla con un valor sin fundamento.
El propósito no es acumular siglas. Es hacer trazable la relación entre una experiencia, una medida y una expectativa, y aclarar cómo se responderá a la evidencia. La utilidad del esquema depende del contexto del servicio y de que las personas implicadas entiendan los términos con el mismo alcance.
Qué no cubre este artículo
Esta introducción no fija objetivos numéricos, no recomienda una herramienta y no crea compromisos de servicio. No sustituye el análisis de datos, la definición contractual ni la revisión de las necesidades particulares de un sistema.
