Módulo 1: What Is Sre And Reliability As A Feature
7. El vocabulario que vas a usar toda la guía
Descripción
Ya usaste, sin definirlos formalmente todavía, la mayoría de los términos centrales de esta guía: error budget en las lecciones 3 y 6, SLO en la 3, radio de explosión heredado de guías anteriores. Esta lección los reúne en un glosario corto y preciso, cada uno citado directamente de la fuente oficial de Google SRE —nunca inventado, nunca "más o menos correcto"— para que tengas, antes de entrar al Módulo 2, la base terminológica exacta que el resto de esta guía asume que ya conoces.
Conexión con el módulo
Esta es la última pieza de vocabulario antes del entregable de la lección 8. Cada término de este glosario reaparece, con más profundidad, en un módulo específico —SLI y SLO en el Módulo 2, toil aquí y en Módulo 5 (on-call), on-call formalmente en el Módulo 5, postmortem en el Módulo 7—, así que esta lección funciona como un mapa de referencia rápida, no como el desarrollo completo de cada idea.
SLI — Service Level Indicator (indicador de nivel de servicio)
"An SLI is a service level indicator—a carefully defined quantitative measure of some aspect of the level of service that is provided."
En español: un SLI es una medida cuantitativa, cuidadosamente definida, de algún aspecto del nivel de servicio que se entrega. La palabra clave es "cuidadosamente definida" — no cualquier métrica cruda es un SLI; un SLI típico es una razón (eventos buenos ÷ eventos totales), con un criterio explícito de qué cuenta como "bueno". Ejemplo, sobre process-shipment-manifest: la proporción de invocaciones que terminan sin error, sobre el total de invocaciones válidas — el Módulo 2 construye esta definición con precisión completa.
SLO — Service Level Objective (objetivo de nivel de servicio)
"An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI."
Un SLO es el número objetivo —o rango— que un SLI debería alcanzar. Si el SLI es "porcentaje de invocaciones exitosas", el SLO es el número específico, como 99,9%, que ese SLI debería cumplir. Ya usaste un SLO hipotético en la lección 6 de este módulo; el Módulo 2 elige el SLO real de Andes Cargo, con su propia justificación.
SLA — Service Level Agreement (acuerdo de nivel de servicio)
"SLAs are service level agreements: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain."
Un SLA es un contrato —explícito o implícito— con consecuencias reales, casi siempre financieras (créditos, reembolsos), si el SLO que contiene no se cumple. La distinción con un SLO es exactamente esa: un SLO es un objetivo interno de ingeniería; un SLA es una promesa externa con consecuencias contractuales. Esta guía no construye ningún SLA para Andes Cargo —fuera de su alcance, un sistema interno sin clientes externos pagando por un contrato de disponibilidad— pero necesitas la distinción para no confundir los tres términos en una conversación real.
Error budget
"The error budget is 100% minus the SLO."
Ya lo calculaste dos veces, en las lecciones 3 y 6 de este módulo: la porción del SLO que se permite "perder" antes de que el objetivo se incumpla, expresada en minutos concretos sobre una ventana de tiempo. Con 99,9% mensual, 43,2 minutos. Es el mecanismo, no solo la fórmula, que convierte una meta abstracta en una decisión operativa diaria.
Toil
"[Toil is] the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows."
Toil es trabajo operativo que cumple, total o parcialmente, seis características: manual, repetitivo, automatizable, táctico (reactivo, no estratégico), sin valor duradero, y que crece linealmente con el tamaño del servicio. No es "cualquier trabajo aburrido" — es, específicamente, trabajo que un ingeniero de software, siguiendo la definición de Treynor de la lección 2, resolvería con automatización en vez de seguir absorbiendo a mano. Google SRE es explícito sobre el límite que se auto-impone: "Our SRE organization has an advertised goal of keeping operational work (i.e., toil) below 50% of each SRE's time." — menos del 50% del tiempo de cada ingeniero, nunca la mayoría de su trabajo.
Radio de explosión (blast radius)
Ya conocido de terraform-and-iac-guide y cloud-security-and-guardrails-guide: el alcance real de lo que un cambio o una falla puede afectar, medido por qué recursos dependen de qué —nunca por la intención de quien lo causó—. El incidente Claude Code tuvo un radio de explosión tan grande, según esas mismas guías, precisamente porque un solo state de Terraform gestionaba toda la infraestructura de producción de DataTalks.Club sin separación. Esta guía no vuelve a construir el concepto —ya lo tienes— pero lo usa activamente en el Módulo 6, al operar el mismo incidente.
On-call
"[On-call means] being available for calls during both working and nonworking hours" para mantener servicios confiables — específicamente, un ingeniero disponible para operar sobre sistemas de producción dentro de minutos, según los tiempos de respuesta de alerta que el equipo haya acordado.
On-call no es "estar pendiente del celular por si acaso" — es un compromiso formal, con un tiempo de respuesta acordado. Google SRE impone, además, un límite duro sobre cuánto tiempo del trabajo total de un ingeniero puede ser guardia: "no more than 25% can be spent on-call" — nunca la mayoría del tiempo de nadie. El Módulo 5 de esta guía construye una rotación real, determinista, con esta misma honestidad sobre el costo humano del on-call.
Postmortem
"A postmortem is a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring."
Un postmortem es un documento —no una conversación informal ni una reunión sin registro— con cinco piezas obligatorias: qué pasó, qué impacto tuvo, qué se hizo para mitigarlo, cuál fue la causa raíz, y qué acciones de seguimiento previenen que se repita. La palabra "sin culpa" (blameless) no es un adjetivo decorativo — la propia fuente lo precisa: "For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior", asumiendo que "everyone involved in an incident had good intentions and did the right thing with the information they had". El Módulo 7 de esta guía escribe el postmortem real del incidente Claude Code, siguiendo exactamente esta estructura.
El glosario, en una tabla de referencia rápida
| Término | Qué mide/hace | Dónde se construye a fondo en esta guía |
|---|---|---|
| SLI | Una medida cuantitativa del nivel de servicio | Módulo 2 |
| SLO | El objetivo numérico que un SLI debería cumplir | Módulo 2 |
| SLA | Un contrato externo con consecuencias por incumplir un SLO | Nombrado aquí, no construido (fuera de alcance) |
| Error budget | 1 − SLO, en minutos concretos | Módulos 2, 4 y 6 |
| Toil | Trabajo operativo manual, repetitivo y sin valor duradero | Nombrado aquí; límite del 50% citado |
| Radio de explosión | El alcance real de un cambio o falla | Ya conocido; reutilizado en el Módulo 6 |
| On-call | Disponibilidad comprometida para responder incidentes | Módulo 5 |
| Postmortem | El documento estructurado que registra un incidente | Módulo 7 |
Errores comunes
Usar "SLA" cuando en realidad se quiere decir "SLO" (el error de vocabulario más común del mercado). Qué pasa: alguien dice "nuestro SLA es 99,9%" para referirse a un objetivo interno de ingeniería, sin ningún contrato externo con consecuencias reales de por medio. Cómo detectarlo: si el "SLA" que mencionas no tiene, en los hechos, ninguna consecuencia contractual (créditos, reembolsos, penalidades) si se incumple. Cómo corregirlo: si no hay un contrato externo con consecuencias, es un SLO, no un SLA — la distinción de esta lección, citada directo de la fuente, es exactamente sobre esto. Confundir los dos términos en una entrevista técnica es una de las señales más rápidas de que alguien memorizó las siglas sin entender la diferencia real.
Tratar toil como sinónimo de "cualquier tarea operativa" (de sobregeneralización). Qué pasa: alguien clasifica cualquier trabajo de operaciones —incluido trabajo estratégico, como diseñar una nueva alerta— como toil. Cómo detectarlo: si tu definición de toil no menciona ninguna de las seis características específicas (manual, repetitivo, automatizable, táctico, sin valor duradero, escala linealmente). Cómo corregirlo: diseñar la alerta de burn rate del Módulo 4 de esta guía es trabajo de ingeniería con valor duradero —una vez construida, sigue funcionando sin repetir el esfuerzo—; responder manualmente, cada vez, a la misma alerta sin automatizar nada es toil. La distinción no es "operaciones sí, desarrollo no" — es si el trabajo se repite sin acumular ningún valor permanente.
Asumir que el límite del 50% de toil o del 25% de on-call son reglas arbitrarias de Google, sin aplicación fuera de esa empresa (de escepticismo mal dirigido). Qué pasa: alguien descarta estos límites como "cultura corporativa específica de Google", sin ningún valor para un equipo pequeño como el que operaría Andes Cargo. Cómo detectarlo: si tu razonamiento es "eso es para empresas grandes, no aplica aquí". Cómo corregirlo: el principio detrás del límite —que el trabajo repetitivo sin automatizar, sin control, se come todo el tiempo disponible de ingeniería— no depende del tamaño del equipo; de hecho, es más urgente en un equipo pequeño, donde no hay margen de gente adicional para absorber toil sin límite. El número exacto (50%, 25%) es de Google; el principio de poner algún límite explícito, medido, es universal, y el Módulo 5 de esta guía lo aplica a la rotación de on-call de Andes Cargo con la misma honestidad.
Ejercicios
Ejercicio 1 — Clasifica cada término en la frase correcta. Completa: "Nuestro ___ es que el 99,9% de las invocaciones de process-shipment-manifest terminen sin error (medido con nuestro ___ de tasa de éxito). Si algún cliente externo nos pagara por garantizar ese número con penalidades por incumplimiento, eso sería nuestro ___."
Ver solución
"Nuestro SLO es que el 99,9% de las invocaciones de process-shipment-manifest terminen sin error (medido con nuestro SLI de tasa de éxito). Si algún cliente externo nos pagara por garantizar ese número con penalidades por incumplimiento, eso sería nuestro SLA." El SLI es la medida (la razón concreta); el SLO es el objetivo interno sobre esa medida; el SLA es el contrato externo con consecuencias, que Andes Cargo, sin clientes externos pagando por disponibilidad, no tiene ni necesita en esta guía.
Ejercicio 2 — Identifica si una tarea específica es toil, usando las seis características. Un ingeniero de Andes Cargo revisa manualmente, cada mañana, los logs de CloudWatch de process-shipment-manifest en busca de errores, durante quince minutos, todos los días, sin ningún script que lo haga por él. ¿Es toil? Justifica con al menos tres de las seis características.
Ver solución
Sí, es toil — cumple, cómodamente, cuatro de las seis características: es manual (una persona lo hace a mano, cada vez), repetitivo (todos los días, sin variación), automatizable (una alerta basada en la tasa de error, exactamente lo que el Módulo 4 de esta guía construye, reemplaza esta revisión manual por completo), y sin valor duradero (revisar los logs de ayer no deja ningún artefacto que reduzca el trabajo de revisar los de mañana). No es necesariamente táctico en el sentido de "interrumpe otro trabajo" si está agendado —pero cumplir cuatro de las seis características ya es suficiente para clasificarlo como toil, según la propia fuente: no hace falta cumplir las seis.
Ejercicio 3 — Explica por qué un postmortem "sin culpa" no significa "sin causa raíz". Un colega argumenta que un postmortem sin culpa es, en la práctica, evitar decir qué pasó realmente para no incomodar a nadie. ¿Estás de acuerdo, usando la definición citada en esta lección?
Ver solución
En desacuerdo. La definición citada es explícita en que un postmortem —sin culpa o no— debe identificar "the contributing causes of the incident" (las causas que contribuyeron al incidente) con precisión completa; lo que cambia con "sin culpa" no es la precisión sobre qué pasó, sino el marco con el que se interpreta el rol de las personas involucradas: se asume que actuaron de buena fe, con la información que tenían en ese momento, en vez de buscar a quién "indictar" (acusar formalmente) por mal comportamiento. Un postmortem sin culpa del incidente Claude Code, por ejemplo, sí nombra con precisión que un humano aprobó el destroy sin leer el plan completo —esa es la causa contribuyente real, y omitirla haría el postmortem inútil— pero lo hace sin tratar a esa persona como culpable de mala fe, exactamente la distinción que el Módulo 7 de esta guía va a aplicar al escribir el postmortem real de ese incidente.
Resumen y siguiente paso
En esta lección reuniste el glosario completo de esta guía —SLI, SLO, SLA, error budget, toil, radio de explosión, on-call, postmortem—, cada término citado directamente de la fuente oficial de Google SRE, con la distinción precisa entre los que se parecen (SLI/SLO/SLA) y el límite explícito que Google se auto-impone sobre dos de ellos (menos del 50% de tiempo en toil, no más del 25% en on-call).
Antes de avanzar deberías poder: distinguir SLI de SLO de SLA sin dudar; nombrar las seis características de toil y el límite del 50%; y explicar por qué "sin culpa" en un postmortem no significa "sin causa raíz identificada".
La lección 8, el cierre de este módulo, convierte todo el vocabulario de este módulo —confiabilidad como medición, error budget, el incidente Claude Code medido con un número real— en el primer documento formal de esta guía: RELIABILITY-CHARTER.md.
Recursos
- Google SRE Book, Capítulo 4 — Service Level Objectives — definiciones exactas de SLI, SLO y SLA.
- Google SRE Workbook — Implementing SLOs — la fórmula exacta de error budget.
- Google SRE Book, Capítulo 5 — Eliminating Toil — la definición completa de toil y el límite del 50%.
- Google SRE Book, Capítulo 11 — Being On-Call — la definición de on-call y el límite del 25%.
- Google SRE Book, Capítulo 15 — Postmortem Culture — la definición de postmortem y el principio de "sin culpa".