Módulo 2: Slis Slos And The Error Budget
2. Eligiendo un buen SLI: las cuatro señales doradas
Descripción
La lección anterior prometió una herramienta. Antes de construirla, hace falta contestar una pregunta más básica, que ninguna calculadora puede resolver por ti: de todo lo que un sistema hace, ¿qué es lo que vale la pena medir? process-shipment-manifest tiene docenas de métricas posibles —memoria usada, tiempo de arranque en frío, tamaño del payload, número de líneas de log por invocación—, pero un SLI no es "cualquier número que el sistema produce". Google SRE resolvió este problema hace más de una década con una lista corta, deliberadamente pequeña: las cuatro señales doradas. Esta lección las presenta, citadas directo de la fuente, cada una con un ejemplo concreto sobre el Lambda que ya conoces.
Conexión con el módulo
La lección 1 dejó claro que un SLI real requiere criterio, no solo aritmética. Las cuatro señales doradas son ese criterio, formalizado: la lista de candidatos serios para cualquier SLI, antes de decidir cuál de ellos usar. La lección 3 va a tomar una de estas cuatro señales —errores— y convertirla en la primera definición formal de SLI de esta guía, con la fórmula exacta de eventos buenos y válidos. Esta lección es el filtro que hace posible esa elección con criterio, en vez de al azar.
Analogía: el tablero de un carro, no cada sensor del motor
Un carro moderno tiene, fácilmente, cientos de sensores —temperatura del aceite, presión de cada neumático, voltaje de la batería, docenas más—. El tablero, sin embargo, no te muestra todos: te muestra un puñado de indicadores diseñados para contestar la pregunta que de verdad importa mientras manejas —¿voy bien, o tengo que parar?—. Velocímetro, tacómetro, indicador de temperatura, medidor de combustible. Cuatro señales, no doscientas, elegidas porque cada una contesta una pregunta distinta y ninguna es redundante con las otras. Las cuatro señales doradas de Google SRE funcionan igual: no son las únicas métricas que un sistema produce, son las cuatro que, juntas, contestan casi cualquier pregunta real sobre si un servicio está funcionando bien, sin necesidad de mirar los otros doscientos sensores.
Las cuatro señales, citadas de la fuente
"If you can only measure four metrics of your user-facing system, focus on these four."
— Google SRE Book, Capítulo 6 — Monitoring Distributed Systems
1. Latencia (latency)
"The time it takes to service a request."
Cuánto tarda una solicitud en resolverse. La fuente agrega un matiz importante: hay que distinguir la latencia de las solicitudes exitosas de la latencia de las solicitudes que fallan —una solicitud que falla instantáneamente (un error de validación rápido) y una que falla después de agotar un timeout completo son, para efectos de latencia, dos historias completamente distintas, aunque ambas cuenten como "error" para la señal siguiente.
Sobre process-shipment-manifest: el Timeout: 10 que la lección 4 del Módulo 1 ya identificó en la configuración real del Lambda es, literalmente, el límite duro de esta señal. La latencia de este Lambda es cuánto tarda en procesar un manifiesto completo —parsear el archivo, validar los datos, escribir a Shipments— desde que S3 dispara el evento hasta que la función termina. Una invocación que tarda 9 segundos técnicamente "funcionó", pero está peligrosamente cerca del límite; una que tarda 11 se corta a la fuerza, sin importar cuán cerca estuviera de terminar. Medir la latencia real, no solo si hubo timeout o no, es lo que permitiría detectar ese deterioro antes de que cruce la línea.
2. Tráfico (traffic)
"A measure of how much demand is being placed on your system, measured in a high-level system-specific metric."
Cuánta demanda recibe el sistema, en la unidad que tenga sentido para ese sistema específico —solicitudes HTTP por segundo para una API, transacciones por segundo para un sistema de base de datos—. La fuente es explícita en que la unidad correcta depende del sistema, no hay una sola métrica universal de tráfico.
Sobre process-shipment-manifest: la unidad natural es invocaciones por día —cuántos manifiestos entran al sistema en una ventana de tiempo—. Esta es, exactamente, la columna de "eventos válidos" que vas a ver en el dataset de la lección 4: cada fila del dataset fijo de 30 días es, en el fondo, una medición de tráfico diario. El techo de ReservedConcurrentExecutions: 5 que el Módulo 1 ya identificó convierte esta señal en algo más urgente que "cuánta demanda hay" — también es la respuesta a "¿cuánta demanda puede este sistema absorber antes de empezar a regular solicitudes?".
3. Errores (errors)
"The rate of requests that fail, either explicitly (e.g., HTTP 500s), implicitly (for example, an HTTP 200 success response, but coupled with the wrong content), or by policy (for example, if you've agreed to return a 400 error state)."
La tasa de solicitudes que fallan — y la fuente insiste en tres formas distintas de fallar, no solo una. Un error explícito es fácil de detectar (un código de estado de error). Un error implícito es más peligroso precisamente porque no se ve como error: el sistema responde "éxito", pero con contenido incorrecto.
Sobre process-shipment-manifest: un error explícito es una excepción no manejada durante el procesamiento —una invocación que termina con estado de fallo, visible en los logs y en la métrica Errors de CloudWatch—. Un error implícito es más sutil y es exactamente el tipo de riesgo que la lección 4 del Módulo 1 ya nombró sin resolver: una invocación que termina "exitosamente" (sin excepción, sin timeout) pero escribe un registro incompleto o corrupto en Shipments — el Lambda reporta éxito, pero el dato real está mal. Esta guía retoma esta distinción con precisión en la lección 3, al decidir qué cuenta exactamente como "bueno" para el SLI de disponibilidad de este Lambda.
4. Saturación (saturation)
"How 'full' your service is. A measure of your system fraction, emphasizing the resources that are most constrained (e.g., in a memory-constrained system, show memory; in an I/O-constrained system, show I/O)."
Qué tan lleno está el sistema — no en general, sino específicamente en el recurso que más limita su capacidad. La fuente aclara que saturación no es solo "¿está al 100%?": para sistemas complejos, el momento en que el desempeño empieza a degradarse suele llegar antes del 100% de utilización, así que un buen indicador de saturación incluye una noción de a partir de qué punto la degradación empieza a notarse.
Sobre process-shipment-manifest: el recurso más restringido de este Lambda, según su propia configuración, no es memoria (MemorySize: 128 es generoso para un procesador de manifiestos) — es concurrencia. ReservedConcurrentExecutions: 5 significa que la saturación de este sistema se mide como "¿cuántas de las 5 ranuras de concurrencia están ocupadas ahora mismo?". La sexta invocación simultánea no es un error del código ni una falla de latencia — es saturación pura: el sistema está, literalmente, lleno, y la solicitud se regula (throttling) antes de siquiera intentar ejecutarse.
Las cuatro señales, aplicadas a process-shipment-manifest: la tabla completa
| Señal | Qué mide, en la fuente | En process-shipment-manifest | Dato de configuración que ya conoces (Módulo 1) |
|---|---|---|---|
| Latencia | Tiempo para resolver una solicitud | Segundos desde el trigger de S3 hasta que la invocación termina | Timeout: 10 |
| Tráfico | Demanda sobre el sistema | Invocaciones por día (la columna base del dataset de la lección 4) | ReservedConcurrentExecutions: 5 (el techo de demanda absorbible) |
| Errores | Tasa de solicitudes que fallan (explícita, implícita, o por política) | Excepciones no manejadas (explícito); escritura corrupta a Shipments (implícito) | Sin DLQ confirmada en esta ruta (Módulo 1, lección 4) |
| Saturación | Qué tan lleno está el recurso más restringido | Ranuras de concurrencia ocupadas, de 5 disponibles | ReservedConcurrentExecutions: 5 |
Por qué esta guía elige errores, no las cuatro, para el SLI de disponibilidad
Las cuatro señales son candidatas serias — no significa que todas se conviertan, automáticamente, en el SLI que esta guía va a definir formalmente en la lección 3. La razón es de enfoque, no de jerarquía: la pregunta central de RELIABILITY-CHARTER.md es "¿qué significa 'confiable' para este sistema?", y para un procesador asíncrono de manifiestos, "confiable" se traduce, ante todo, en "¿el manifiesto se procesó correctamente?" — la señal de errores, medida con la fórmula exacta de eventos buenos ÷ eventos válidos, es la que responde esa pregunta de forma más directa. Latencia, tráfico y saturación no desaparecen de esta guía: la latencia reaparece como una señal complementaria en el Módulo 3 (medida con datos reales de CloudWatch); la saturación es, literalmente, uno de los seis riesgos que el inventario de la lección 4 del Módulo 1 ya nombró, sin resolver todavía. Pero el SLI primario de Andes Cargo —el que SLO.md va a fijar en la lección 8 de este módulo— se construye sobre errores, la señal que más directamente contesta la pregunta que le importa al negocio.
Errores comunes
Tratar las cuatro señales como si tuvieran que convertirse, todas, en SLIs formales (de sobre-ingeniería). Qué pasa: alguien, después de esta lección, intenta definir cuatro SLIs distintos para process-shipment-manifest —uno por señal— antes de avanzar. Cómo detectarlo: si tu plan para la lección 3 es escribir cuatro fórmulas de SLI en vez de una. Cómo corregirlo: la propia fuente de Google SRE presenta las cuatro señales como candidatas a considerar, no como una obligación de instrumentar las cuatro con el mismo rigor. Esta guía elige errores como el SLI primario de Andes Cargo por una razón de negocio explícita (arriba); las otras tres siguen siendo relevantes —aparecen en el Módulo 3 como datos de observabilidad—, pero no todas necesitan convertirse en un SLI formal con su propio SLO.
Confundir "tráfico" con "SLI" (de categoría equivocada). Qué pasa: alguien propone "el número de invocaciones diarias" como un SLI en sí mismo. Cómo detectarlo: si tu propuesta de SLI no tiene ninguna noción de "bueno" frente a "malo" — solo un conteo. Cómo corregirlo: el tráfico es, casi siempre, el denominador de un SLI (los "eventos válidos" de la fórmula que la lección 3 va a formalizar), no el SLI en sí mismo. Un SLI necesita una proporción —algo dividido entre algo—, y "cuántas invocaciones hubo" es solo una de las dos partes de esa proporción.
Ignorar la saturación porque "el sistema no se ha quedado sin memoria nunca" (de mirar el recurso equivocado). Qué pasa: alguien descarta la saturación como una señal relevante para process-shipment-manifest, razonando que la memoria (128 MB) nunca ha sido un problema. Cómo detectarlo: si tu análisis de saturación solo considera memoria o CPU. Cómo corregirlo: la fuente es explícita en enfocarse en el recurso más restringido, no en cualquier recurso disponible — para este Lambda específico, ese recurso es la concurrencia reservada (5 ranuras), no la memoria. Medir memoria cuando el cuello de botella real es concurrencia es medir la señal equivocada con precisión perfecta.
Ejercicios
Ejercicio 1 — Clasifica un síntoma hipotético en la señal correcta. Un cliente de Andes Cargo reporta que, durante una hora, ningún manifiesto nuevo se procesó, aunque el Lambda seguía "activo" según la consola. Investigando, encuentras que las cinco ranuras de concurrencia estaban ocupadas de forma continua por invocaciones que tardaban 9,8 segundos cada una, muy cerca del Timeout: 10. ¿Qué señal (o señales) de las cuatro doradas explica este síntoma, y por qué más de una podría aplicar?
Ver solución
Aplican dos señales a la vez, y vale la pena nombrar ambas: saturación (las cinco ranuras de concurrencia estaban ocupadas de forma continua, el sistema literalmente lleno) y latencia (9,8 segundos por invocación, peligrosamente cerca del límite de 10, es la causa raíz de por qué las ranuras tardaban tanto en liberarse). La relación entre ambas es directa: una latencia alta prolonga cuánto tiempo cada invocación ocupa una ranura de concurrencia, lo que hace que la saturación llegue más rápido con el mismo volumen de tráfico. Este es exactamente el tipo de conexión entre señales que hace que las cuatro, juntas, cuenten una historia más completa que cualquiera por separado — la saturación por sí sola diría "el sistema está lleno"; sumarle la latencia explica por qué se llenó.
Ejercicio 2 — Explica por qué un error "implícito" es más peligroso que uno "explícito" para process-shipment-manifest, con un ejemplo concreto. Usa la definición citada en esta lección.
Ver solución
Un error explícito —una excepción no manejada, un Timeout— deja evidencia automática: aparece en los logs, incrementa la métrica Errors de CloudWatch, es visible sin que nadie tenga que buscarlo con cuidado. Un error implícito, según la definición citada ("an HTTP 200 success response, but coupled with the wrong content"), es peligroso precisamente porque no genera ninguna de esas señales — el Lambda termina, reporta éxito, la métrica Errors no se mueve. Un ejemplo concreto para process-shipment-manifest: una invocación que procesa el manifiesto del envío 4471 pero, por un error de mapeo de campos, escribe el estado de ese envío en el registro de Shipments correspondiente al envío 4472 —el Lambda "funcionó" desde la perspectiva de CloudWatch, pero el dato real de dos envíos distintos ahora está corrupto—. Este tipo de error solo se detecta con validación de contenido, nunca con una métrica de tasa de fallos técnicos, que es exactamente la distinción que la lección 3 de este módulo tiene que resolver al decidir qué cuenta como "bueno".
Ejercicio 3 — Argumenta por qué esta guía elige errores, y no saturación, como el SLI primario de Andes Cargo, aunque saturación sea un riesgo real ya identificado. Un compañero sugiere que, dado que la saturación (concurrencia) es "el riesgo más visible" del Módulo 1, debería ser la base del SLI principal en vez de errores.
Ver solución
La visibilidad de un riesgo en un inventario (Módulo 1, lección 4) no es lo mismo que su relevancia directa para la pregunta central de RELIABILITY-CHARTER.md: "¿qué significa 'confiable' para este sistema?". Para un cliente de Andes Cargo, lo que importa no es si el sistema estuvo "lleno" en algún momento —eso es una causa raíz posible—, sino si su manifiesto se procesó correctamente o no, que es exactamente lo que la señal de errores mide de forma directa. La saturación es, de hecho, una de las causas más probables de un error (una invocación regulada por falta de concurrencia termina, para el cliente, siendo una invocación fallida) — pero el SLI se define sobre el síntoma que le importa al usuario final (¿funcionó?), no sobre la causa técnica interna (¿por qué no funcionó?). Esta distinción —el SLI mide la experiencia del usuario, no el mecanismo interno— es la misma que separa "qué mide un SLI" de "qué explica un postmortem", y la guía la aplica consistentemente desde esta lección.
Resumen y siguiente paso
En esta lección conociste las cuatro señales doradas de Google SRE —latencia, tráfico, errores, saturación—, cada una citada de la fuente original y aplicada con un ejemplo concreto sobre process-shipment-manifest, usando datos de configuración reales que ya conocías del Módulo 1 (Timeout: 10, ReservedConcurrentExecutions: 5). Viste, además, por qué esta guía elige errores como la base del SLI primario de Andes Cargo: no porque las otras tres señales no importen, sino porque errores es la que más directamente contesta la pregunta de negocio que RELIABILITY-CHARTER.md planteó.
Antes de avanzar deberías poder: nombrar las cuatro señales de memoria, con su cita exacta; explicar la diferencia entre un error explícito y uno implícito, con un ejemplo propio de process-shipment-manifest; y defender por qué errores, no saturación ni latencia, es la señal elegida para el SLI primario de esta guía.
La lección 3 toma la señal de errores y la convierte, por escrito, en la primera definición formal de SLI de esta guía: qué cuenta exactamente como "bueno", qué cuenta exactamente como "válido" — la decisión de criterio que ninguna calculadora puede tomar por ti.
Recursos
- Google SRE Book, Capítulo 6 — Monitoring Distributed Systems — fuente exacta de las cuatro señales doradas, citadas en esta lección.
- Este mismo repositorio, Módulo 1, lección 4 (
04-hands-on-reading-andes-cargo-like-an-sre.md) — el inventario real deprocess-shipment-manifest(Timeout: 10,ReservedConcurrentExecutions: 5) que esta lección reutiliza para cada señal. - Google SRE Book, Capítulo 4 — Service Level Objectives — el marco de SLI/SLO que la lección 3 de este módulo formaliza con la señal de errores.