Módulo 1: What Is Sre And Reliability As A Feature
3. Confiabilidad como feature, no como accidente
Descripción
Es intuitivo pensar que la meta de cualquier sistema en producción es "que nunca falle" — 100% de disponibilidad, todo el tiempo, sin excepción. Google SRE, con dos décadas de datos reales detrás, llegó a la conclusión contraria, y la documentó con la misma precisión con la que documentaría cualquier otro resultado de ingeniería: perseguir el 100% no solo es imposible, es una mala decisión de negocio. Esta lección explica por qué, con las cifras exactas del libro de Google SRE, y presenta la herramienta que convierte esa idea abstracta en algo que un equipo puede usar todos los días para decidir: el error budget.
Conexión con el módulo
La lección 2 estableció que SRE mide la confiabilidad en vez de prometerla. Esta lección le pone el número exacto a esa medición: cuánta falla es aceptable, por qué ese número casi nunca es cero, y qué mecanismo convierte "cuánta falla es aceptable" en una decisión operativa real, todos los días, sobre cuándo lanzar algo nuevo y cuándo frenar. La lección 6 va a tomar exactamente este vocabulario y aplicarlo, por primera vez con un número real, al incidente Claude Code.
Analogía: la tarjeta prepaga de "caídas permitidas"
Un error budget funciona exactamente como el saldo de una tarjeta prepaga que alguien carga una vez al mes, con un límite fijo. No es una línea de crédito que crece si la necesitas más — es un saldo cerrado. Puedes gastarlo rápido, de una sola vez, en algo que valga la pena (un lanzamiento grande, un experimento arriesgado); puedes repartirlo con cuidado durante todo el mes; o puedes casi no tocarlo. Pero una vez que el saldo llega a cero, se acabó — no se repone antes de tiempo, sin importar cuán urgente parezca la próxima cosa en la que querrías gastarlo. Perseguir el 100% de disponibilidad es el equivalente de decidir que la tarjeta nunca se puede usar, ni un centavo, nunca — lo cual suena responsable hasta que te das cuenta de que una tarjeta que nadie puede usar tampoco sirve para nada: ningún experimento, ningún lanzamiento riesgoso mide su costo real, porque el costo de fallar se trató siempre como si fuera infinito.
Por qué el 100% casi nunca es el objetivo correcto
La fuente es explícita, y contradice la intuición de forma directa:
"You might expect Google to try to build 100% reliable services—ones that never fail. It turns out that past a certain point, however, increasing reliability is worse for a service (and its users) rather than better!"
Y, de forma todavía más directa, en la sección de conclusiones del mismo capítulo:
"100% is probably never the right reliability target: not only is it impossible to achieve, it's typically more reliability than a service's users want or notice."
Dos ideas separadas en esa segunda cita, y vale la pena no fusionarlas:
- Es imposible de lograr. Ningún sistema real —ni siquiera la infraestructura de Google— controla el 100% de las variables entre el servidor y el usuario final: la conexión del usuario, su proveedor de internet, el hardware de su dispositivo, todos tienen su propia tasa de falla, fuera del control de cualquier equipo de ingeniería. Perseguir el 100% del lado del servidor no mueve la experiencia real del usuario si el 0,3% de falla que percibe viene, de todos modos, de su propia red.
- Aunque fuera posible, casi nadie lo necesita ni lo nota. La diferencia entre 99,99% y 100% de disponibilidad —52,6 minutos de indisponibilidad al año contra cero— es, para la enorme mayoría de los sistemas, invisible para el usuario final frente a la variabilidad que ya existe en su propia conexión.
El costo marginal de cada nueve adicional
La razón por la que "simplemente apunta más alto" no es un consejo gratuito: el costo de mejorar confiabilidad no crece de forma lineal. La fuente lo dice con precisión:
"As we build systems, cost does not increase linearly as reliability increments—an incremental improvement in reliability may cost 100x more than the previous increment."
Traducido a minutos reales, sobre una ventana de un año (365 días = 525.600 minutos), así se ve la escalera de "nueves" que vas a usar durante el resto de esta guía:
| SLO (disponibilidad) | Indisponibilidad permitida / año | Indisponibilidad permitida / mes (30 días) | Lo que suele costar llegar ahí |
|---|---|---|---|
| 99% ("dos nueves") | ~3,65 días | ~7,3 horas | Redundancia básica, reinicio manual aceptable |
| 99,9% ("tres nueves") | ~8,76 horas | ~43,2 minutos | Automatización de recuperación, monitoreo activo |
| 99,99% ("cuatro nueves") | ~52,6 minutos | ~4,3 minutos | Redundancia multi-zona, failover automático, on-call serio |
| 99,999% ("cinco nueves") | ~5,26 minutos | ~26 segundos | Multi-región activa/activa, ingeniería de guardia dedicada, presupuesto de infraestructura mucho mayor |
Cada fila hacia abajo no cuesta "un poco más" que la anterior — cuesta, según la fuente, un orden de magnitud más. Pasar de 99% a 99,9% (de 7,3 horas de indisponibilidad al mes a 43 minutos) puede lograrse con disciplina de ingeniería razonable. Pasar de 99,99% a 99,999% (de 4,3 minutos al mes a 26 segundos) típicamente exige arquitectura multi-región activa, un equipo de guardia mucho más grande, y un presupuesto que la mayoría de los productos —incluido Andes Cargo, un sistema de tracking de envíos, no un sistema de pagos en tiempo real ni soporte de vida— no necesita ni puede justificar.
La pregunta correcta nunca es "¿cuánto más confiable podemos ser?" — es "¿cuánta confiabilidad adicional pagaría, de verdad, alguien que usa este sistema?".
El error budget: el mecanismo que convierte esta idea en una decisión diaria
Si 100% no es la meta, y cada nueve adicional cuesta más que el anterior, entonces alguien tiene que elegir un número específico —el SLO— y, más importante todavía, alguien tiene que decidir qué hacer cuando ese número se está por incumplir. Ese "qué hacer" es exactamente el problema que el error budget resuelve, y la fuente es explícita sobre por qué funciona:
"The main benefit of an error budget is that it provides a common incentive that allows both product development and SRE to focus on finding the right balance between innovation and reliability."
"An error budget aligns incentives and emphasizes joint ownership between SRE and product development."
El mecanismo, en su forma más simple: si el SLO es 99,9% de disponibilidad mensual, el error budget es el 0,1% restante — el equivalente al saldo de la tarjeta prepaga de la analogía de arriba, esta vez medido en minutos concretos (43,2 minutos al mes, según la tabla de arriba). Mientras el presupuesto tenga saldo, el equipo de producto tiene, literalmente, permiso de tomar riesgo: lanzar una función nueva sin probarla exhaustivamente, hacer un experimento agresivo, desplegar más seguido. Cuando el presupuesto se agota, la conversación deja de ser una opinión ("creo que deberíamos frenar") y se vuelve un hecho verificable con un número: no quedan minutos de indisponibilidad disponibles este mes, así que los lanzamientos nuevos esperan hasta que el sistema se estabilice o hasta que empiece la siguiente ventana. Ningún equipo tiene que ganar una discusión — el presupuesto ya decidió.
Este es el "mecanismo de negociación entre velocidad y estabilidad" que el título de esta sección promete: no es una negociación de opiniones cada semana, es un número compartido que ambos equipos —el que quiere lanzar rápido y el que responde cuando algo se rompe— pueden consultar y confiar por igual, exactamente la respuesta al problema de incentivos divididos que la lección 2 ya identificó en el modelo de operaciones tradicionales.
Errores comunes
Elegir el SLO más alto posible "porque suena mejor" (el error más común de esta guía completa). Qué pasa: alguien, al momento de definir un SLO para un servicio nuevo, elige 99,99% o 99,999% sin ninguna justificación de negocio, solo porque un número más alto se siente más responsable. Cómo detectarlo: si tu justificación para un SLO es "queremos ser lo más confiables posible" en vez de "nuestros usuarios notarían/pagarían por esta diferencia específica". Cómo corregirlo: usa la tabla de nueves de esta lección al revés — antes de elegir un SLO, pregunta qué pasaría de verdad si el sistema estuviera indisponible la cantidad de minutos que ese SLO permite. Para process-shipment-manifest, un sistema de procesamiento asíncrono de manifiestos, 43 minutos de indisponibilidad al mes (99,9%) probablemente no cuesta nada real —un manifiesto que llega 43 minutos tarde en su procesamiento no es una crisis—; 26 segundos al mes (99,999%) exigiría una inversión de arquitectura completamente injustificada para ese mismo sistema. El Módulo 2 de esta guía retoma esta decisión con la calculadora real.
Tratar el error budget como un castigo cuando se agota (de cultura, el error más costoso). Qué pasa: cuando el presupuesto de error se agota, alguien busca a quién culpar por "gastarlo", en vez de tratarlo como información operativa neutral. Cómo detectarlo: si la reacción de tu equipo a un presupuesto agotado incluye la pregunta "¿quién causó esto?" antes de la pregunta "¿qué decisión toma esto por nosotros ahora?". Cómo corregirlo: el error budget no es una calificación de desempeño — es, literalmente, la herramienta descrita en la fuente para alinear incentivos, no para repartir culpa. Un presupuesto agotado significa una sola cosa, operacionalmente: pausar el riesgo nuevo hasta recuperar margen. El Módulo 7 de esta guía construye la misma idea, con el mismo espíritu, para el postmortem sin culpa.
Confundir "cero incidentes este mes" con el objetivo real de esta disciplina. Qué pasa: alguien celebra un mes sin ningún incidente como si fuera la meta máxima de SRE, y trata cualquier incidente futuro como un fracaso del proceso. Cómo detectarlo: si tu métrica de éxito personal es "cero incidentes" en vez de "el presupuesto de error se respetó, y cuando no se respetó, aprendimos algo sistémico de eso". Cómo corregirlo: un mes sin ningún incidente, con un SLO de 99,9%, puede significar que el equipo fue demasiado conservador y dejó presupuesto sin gastar —presupuesto que, según la propia lógica de esta lección, existe precisamente para tomar riesgo razonable—. La meta no es cero incidentes; es que la cantidad de indisponibilidad, sea cual sea, se mantenga dentro del presupuesto acordado, y que cada vez que se exceda, el sistema —no una persona— sea el foco de la corrección.
Ejercicios
Ejercicio 1 — Explica, con tus propias palabras, por qué 99,99% no es automáticamente "mejor" que 99,9% para todos los sistemas. Usando la tabla de nueves de esta lección, argumenta por qué elegir el SLO más alto disponible no es, por defecto, la decisión correcta.
Ver solución
Una respuesta completa: "99,99% permite solo 4,3 minutos de indisponibilidad al mes, contra 43,2 minutos en 99,9% — una diferencia de un orden de magnitud, no un ajuste menor—. Según la fuente de Google SRE, ese salto no cuesta 'un poco más'; puede costar cien veces más en ingeniería (redundancia multi-zona, automatización de recuperación, on-call más agresivo). Si el sistema en cuestión no tiene un costo de negocio real asociado a esos 39 minutos adicionales de diferencia —por ejemplo, un sistema de procesamiento asíncrono donde nadie nota si un dato llega unos minutos tarde—, ese costo de ingeniería adicional se estaría pagando sin ningún beneficio real para el usuario. La decisión correcta depende del costo real de fallar para ese sistema específico, no de un instinto de 'más alto es más responsable'."
Ejercicio 2 — Aplica la analogía de la tarjeta prepaga a una situación concreta. Un equipo tiene un SLO de 99,9% mensual (43,2 minutos de presupuesto) y ya usó 40 de esos 43,2 minutos a mitad de mes, en un incidente ya resuelto. Alguien propone lanzar una función experimental, arriesgada, esa misma tarde. Usando la analogía de esta lección, ¿qué deberías responder?
Ver solución
Con la tarjeta prepaga casi vacía —solo quedan 3,2 minutos de saldo para el resto del mes—, lanzar algo arriesgado esa misma tarde es exactamente el equivalente de intentar una compra grande con una tarjeta que casi no tiene fondos: cualquier problema nuevo, por pequeño que sea, agota el presupuesto restante y deja al equipo sin ningún margen para el resto del mes, incluidos incidentes que no tienen nada que ver con el lanzamiento experimental. La respuesta correcta, siguiendo la lógica del error budget: pausar el lanzamiento arriesgado hasta que el presupuesto se recupere en la siguiente ventana, o hasta que el equipo decida, con conocimiento explícito del riesgo, gastar el poco saldo restante en algo que valga esa apuesta — nunca lanzarlo sin haber mirado el saldo primero.
Ejercicio 3 — Explica la diferencia entre "el error budget se agotó" y "alguien cometió un error". Un compañero, después de que el equipo agota su presupuesto de error en un incidente, sugiere que la persona que aprobó el cambio que lo causó debería recibir una amonestación formal. ¿Qué le respondes, usando el vocabulario de esta lección?
Ver solución
El error budget existe, según la fuente citada en esta lección, para alinear incentivos entre desarrollo y confiabilidad — no para asignar culpa individual. Agotar el presupuesto es información operativa (pausar riesgo nuevo hasta recuperarlo), no un veredicto sobre una persona. Tratar el consumo del presupuesto como base para una amonestación individual reintroduce exactamente el problema que esta disciplina fue diseñada para evitar —una cultura donde la gente oculta o minimiza problemas por miedo a la consecuencia personal, en vez de reportarlos con precisión para que el sistema se corrija—. La respuesta correcta es tratar el evento como un dato de entrada al proceso, la misma filosofía que el Módulo 7 de esta guía formaliza con el postmortem sin culpa.
Resumen y siguiente paso
En esta lección estableciste, con las citas exactas de Google SRE, por qué el 100% de disponibilidad casi nunca es el objetivo correcto —es imposible de lograr, y típicamente es más confiabilidad de la que los usuarios notan o necesitan—; por qué el costo de cada nueve adicional crece de forma no lineal, con una tabla concreta de minutos de indisponibilidad permitida por cada nivel de SLO; y qué es el error budget —el mecanismo, no la promesa, que convierte esa decisión en algo operativo todos los días, alineando los incentivos entre quien quiere lanzar rápido y quien responde cuando algo se rompe.
Antes de avanzar deberías poder: explicar por qué 100% es imposible y, además, indeseable; calcular de memoria cuántos minutos de presupuesto da un SLO de 99,9% mensual; y explicar, sin usar la palabra "castigo", qué significa realmente que un error budget se agote.
La lección 4 pone este vocabulario a trabajar sobre la infraestructura real de Andes Cargo, leída por primera vez con la pregunta específica de un SRE: no "¿es seguro?", no "¿es barato?" — "¿qué puede fallar aquí?".
Recursos
- Google SRE Book, Capítulo 3 — Embracing Risk — fuente primaria de todas las citas de esta lección: por qué 100% es la meta equivocada, el costo no lineal de cada nueve, y el error budget como mecanismo de alineación de incentivos.
- Google SRE Workbook — Implementing SLOs — la fórmula completa de error budget (1 − SLO) con el ejemplo numérico sobre volumen real de solicitudes, retomada con la calculadora del Módulo 2.
- Google SRE Book, Capítulo 4 — Service Level Objectives — las definiciones formales de SLI/SLO/SLA, retomadas en la lección 7 de este módulo.