Si le preguntas a la dirección de AlpinaShop qué nivel de servicio espera de la tienda, la respuesta será "que no se caiga nunca". Es una respuesta comprensible y completamente inútil, por tres motivos: no se puede cumplir, no se puede medir, y no permite decidir nada.

No se puede cumplir porque el 100 % de disponibilidad no existe: falla el hardware, falla la red del cliente, falla el proveedor de DNS, falla un despliegue, se equivoca una persona. No se puede medir porque nadie ha definido qué cuenta como "caída". Y no permite decidir nada porque si el objetivo es la perfección, cualquier inversión en fiabilidad está justificada y ninguna es suficiente, lo cual en la práctica significa que las decisiones se toman por intuición.

La lección anterior terminó señalando exactamente eso: AlpinaShop paga la alta disponibilidad de Cloud SQL, ha duplicado los túneles VPN y mantiene el balanceador global sin ningún objetivo declarado que justifique esas tres decisiones con números. Y arrastra desde 07-04 una deuda calificada de crítica: nadie ha comprobado nunca que las copias de seguridad se puedan restaurar.

Esta lección convierte la fiabilidad en ingeniería. Al terminar sabrás definir SLI, SLO y SLA con precisión, calcular y usar un presupuesto de error para decidir cuándo se despliega y cuándo se para, crear SLO y alertas por consumo de presupuesto en Cloud Monitoring, elegir el nivel de alta disponibilidad de cada componente sabiendo lo que cuesta y lo que aporta, diseñar contra los modos de fallo reales, y tener un plan de recuperación ante desastres con RTO y RPO — ensayado, no escrito.

1. Qué significa fiabilidad y por qué la perfección no es un objetivo
2. SLI, SLO y SLA: las tres siglas que todo el mundo confunde
3. Elegir buenos SLI para AlpinaShop
4. Los SLO de AlpinaShop, con sus consultas reales
5. Presupuesto de error: qué es y para qué sirve de verdad
6. SLO en Cloud Monitoring y alertas por consumo de presupuesto
7. Arquitecturas de alta disponibilidad por niveles
8. Modos de fallo y su mitigación
9. Recuperación ante desastres: RTO, RPO y estrategias
10. El plan de recuperación de AlpinaShop
11. Backups que no se han probado no existen
12. Práctica operativa: guardias, runbooks y post-mortem
13. Pruebas de caos a escala razonable

Fiabilidad es la probabilidad de que un sistema haga lo que se espera de él durante un periodo determinado. No es una propiedad binaria: es una magnitud continua que se elige, se paga y se gestiona.

La curva que hay que tener en la cabeza:

Cada nueve adicional multiplica el coste, y no de forma lineal. Pasar de 99 % a 99,9 % suele ser cuestión de buenas prácticas. Pasar de 99,99 % a 99,999 % requiere multirregión activo-activo, guardias 24×7, ingeniería dedicada y aceptar que despliegas mucho más despacio.

Y la otra mitad de la ecuación, la que casi nunca se calcula:

Con 1.200 pedidos al mes y un ticket medio de 65 €, pasar de 99,9 % a 99,99 % le ahorraría a AlpinaShop unos 70 € al mes en pedidos no perdidos — y le costaría multirregión activo-activo, es decir, varios cientos de euros mensuales más el trabajo de ingeniería.

La conclusión incómoda y correcta: para AlpinaShop, 99,99 % sería una mala inversión. Y saber decir eso con números en la mano, en lugar de perseguir nueves por inercia, es de lo más valioso que puede aportar un ingeniero.

Con dos matices que hay que hacer explícitos:

1. No todo el tiempo vale igual. Cuarenta minutos de caída de madrugada en febrero cuestan casi nada; cuarenta minutos el viernes de la campaña de otoño pueden costar veinte veces más. La disponibilidad importa ponderada por tráfico.
2. Hay costes que no son pedidos perdidos: reputación, clientes que no vuelven, soporte, y —en un incidente largo— el desgaste del equipo.

La relación entre los tres, que es lo que hay que interiorizar:

Tres reglas que evitan casi todos los errores:

1. El SLO siempre es más exigente que el SLA. Si prometes 99,5 % y tu objetivo interno es 99,5 %, incumplirás el contrato la mitad de las veces. La práctica habitual es un margen holgado: SLA 99,5 %, SLO 99,9 %.
2. El SLI se mide desde donde está el usuario, no desde donde es cómodo. Un servidor que responde perfectamente mientras el balanceador devuelve 502 tiene un SLI del 100 % y un usuario furioso.
3. Un SLO sin consecuencia es un adorno. Si al incumplirlo no cambia nada, no es un objetivo: es un número en un panel.

Y una definición precisa de SLI que resuelve la mayoría de las dudas:

SLI = eventos buenos / eventos válidos

Todo lo difícil está en definir esos dos términos. ¿Cuenta como "malo" un 404? (No: el usuario pidió algo que no existe.) ¿Y un 429 del limitador de tasa? (Depende: si es un ataque, no; si es un cliente legítimo, sí.) ¿Y una petición de un robot rastreador? (Probablemente no debería ser un evento válido.) Esas decisiones son el 80 % del trabajo de definir un SLI, y hay que tomarlas por escrito.

Un buen SLI cumple cuatro condiciones:

El error más común es medir lo fácil en lugar de lo importante. La CPU es facilísima de medir y no le importa a ningún cliente. Los "cuatro señales de oro" —latencia, tráfico, errores y saturación— son un buen punto de partida, pero solo las dos primeras y la tercera son candidatas a SLI; la saturación es una causa, no una experiencia.

Los cuatro SLI de AlpinaShop, elegidos recorriendo el viaje del cliente:

Eventos válidos: peticiones HTTP al balanceador con rutas de la tienda, excluyendo rastreadores conocidos. Eventos buenos: las que devuelven código < 500.

Decisiones tomadas y anotadas:

Eventos válidos: las mismas peticiones que en el SLI 1. Eventos buenos: las que se sirven en menos de 800 ms.

Ojo con el error clásico: un SLI de latencia no es "el p95 es menor que X". Es la proporción de peticiones más rápidas que X. La diferencia importa: un percentil no se puede combinar con un presupuesto de error, y una proporción sí.

El umbral de 800 ms no se elige por intuición: se mide la distribución actual, se comprueba dónde está el punto a partir del cual los usuarios abandonan, y se elige un valor que hoy se cumpla holgadamente pero que detecte una degradación real.

El más importante de los cuatro, porque es el que toca el dinero.

Eventos válidos: intentos de pago iniciados. Eventos buenos: los que terminan en confirmación o en un rechazo legítimo de la pasarela (fondos insuficientes, tarjeta caducada).

El matiz que lo hace correcto: un rechazo de la pasarela por fondos insuficientes no es un fallo nuestro. Contarlo como error haría que el SLI dependiera de la solvencia de los clientes, no de la calidad del sistema. Lo que sí cuenta como malo: tiempos de espera, errores 5xx, excepciones y transacciones que quedan en estado indeterminado.

Distinto de los anteriores porque no es una petición: es un proceso.

Eventos válidos: ejecuciones programadas del pipeline de pedidos. Eventos buenos: las que dejan los datos en BigQuery con menos de 2 horas de retraso.

Nótese que no hay SLI de CPU, memoria, número de instancias ni tamaño de la cola. Todo eso se monitoriza —hace falta para diagnosticar— pero no es un objetivo de nivel de servicio, porque a ningún cliente le importa.

Por qué 28 días y no un mes natural: una ventana móvil de 28 días contiene exactamente cuatro semanas, así que siempre incluye el mismo número de fines de semana y de lunes. Con meses naturales, febrero y marzo no son comparables, y el presupuesto se "reinicia" el día 1, lo que crea el incentivo perverso de esperar al cambio de mes para desplegar lo arriesgado.

Las consultas reales, sobre las métricas de 06-04, en PromQL —que es el lenguaje que Cloud Monitoring admite hoy junto a MQL:

Para el pago, se usa la métrica personalizada que la aplicación ya emite desde 06-04:

La separación entre rechazado_legitimo y error_tecnico es una decisión de instrumentación que hay que tomar en el código, y es exactamente donde se ve si alguien ha pensado el SLI o lo ha copiado. Si la aplicación solo registra "éxito" y "fallo", el SLI de pago es irreparablemente ambiguo.

Presupuesto de error = 100 % − SLO

Con un SLO del 99,9 % en 28 días, el presupuesto es del 0,1 %: 40 minutos y 19 segundos de indisponibilidad, o su equivalente en peticiones fallidas.

La tabla de "nueves" traducida a tiempo, que conviene tener a mano:

Aquí está la parte que transforma el concepto de curiosidad en herramienta de gestión. El presupuesto de error resuelve la tensión permanente entre desarrollo y operaciones:

Sin un criterio objetivo, esa tensión se resuelve por autoridad, por cansancio o por quién grita más. Con presupuesto de error, se resuelve con un número:

Mientras quede presupuesto, se despliega. Cuando se agota, se para y se estabiliza.

Y esto convierte la fiabilidad en algo que desarrollo también quiere, porque un sistema frágil consume el presupuesto y le impide entregar funcionalidades. El incentivo deja de estar enfrentado.

Escrita, acordada y en el README de alpinashop-infra:

Y la cláusula que hace que la política sea creíble:

Si el presupuesto se agota por un fallo de la plataforma de Google y no por nuestros cambios, se documenta y no se congela. El objetivo es corregir lo que está en nuestra mano, no castigar al equipo por lo que no controla.

Sin esa cláusula, la primera caída regional de Google convertiría la política en algo que el equipo dejaría de respetar — y una política que se ignora es peor que no tenerla.

El presupuesto de error no es un objetivo que minimizar. Si al final de los 28 días has consumido el 5 %, no has ganado: probablemente estabas siendo demasiado conservador y podías haber entregado más rápido, o tu SLO es demasiado laxo y no refleja lo que los usuarios notan.

Un presupuesto que nunca se toca es tan mala señal como uno que siempre se agota. El consumo sano ronda el 50-80 %.

Cloud Monitoring tiene soporte nativo para SLO, y merece la pena usarlo en lugar de construirlo a mano.

Y en Terraform, que es donde debe vivir:

Dos tipos de SLI que hay que distinguir:

Para AlpinaShop, basado en peticiones. Con un matiz honesto: de madrugada, con tres peticiones por minuto, un solo error es el 33 % de ese minuto. Los SLI basados en peticiones son ruidosos con tráfico bajo, y por eso las alertas del apartado siguiente exigen ventanas largas para los umbrales suaves.

Esta es la parte más valiosa del apartado, y sustituye a las alertas de umbral fijo de 06-04.

La tasa de consumo (burn rate) es cuántas veces más rápido de lo sostenible se está gastando el presupuesto:

• Tasa 1 = a este ritmo, el presupuesto se agota exactamente al final de los 28 días. Es el ritmo sostenible.
• Tasa 14,4 = se agota en 2 días.
• Tasa 6 = se agota en poco menos de 5 días.

El problema de alertar sobre un umbral fijo de errores es conocido: si el umbral es sensible, hay falsas alarmas; si es laxo, no detecta degradaciones lentas. Las alertas de tasa de consumo resuelven las dos cosas con dos alertas complementarias.

Por qué dos ventanas por alerta. La ventana larga (1 h) evita falsas alarmas por un pico de treinta segundos. La ventana corta (5 min) hace que la alerta se apague rápido cuando el problema se resuelve — sin ella, una alerta con ventana de una hora seguiría sonando cincuenta minutos después de arreglado el fallo. Es un detalle pequeño con un impacto enorme en la vida del que está de guardia.

El bloque documentation es lo más importante de la política, y lo que casi todo el mundo deja vacío. Una alerta que llega al móvil a las 3 de la madrugada con el texto "Umbral superado" obliga a la persona a reconstruir el contexto medio dormida. Una que llega con los tres primeros pasos y el enlace al runbook convierte quince minutos de desorientación en dos de acción. Se desarrolla en el apartado 12.

La alta disponibilidad se construye eliminando puntos únicos de fallo, y se hace por niveles, cada uno con su precio.

La frecuencia relativa de cada evento es lo que debería guiar la decisión, y rara vez se mira:

La última fila es la que cambia las prioridades: la mayoría de las caídas no las provoca la infraestructura, sino un cambio. Invertir en multirregión mientras no tienes despliegue canario ni reversión rápida es blindar la puerta y dejar la ventana abierta. AlpinaShop hizo lo correcto: primero pipeline y reversión (módulo 6 y 07-02), después arquitectura.

Observación importante: una parte grande de la arquitectura de AlpinaShop ya es multirregión sin esfuerzo, porque los servicios globales de Google lo son por diseño. El balanceador, DNS, CDN, Armor, Firestore, BigQuery y Secret Manager no requieren ninguna decisión. Los dos componentes que sí son regionales y críticos son Cloud Run y Cloud SQL.

Merece detalle porque se paga el doble y mucha gente no sabe qué compra.

La última fila es la que hay que subrayar. HA regional protege contra fallos de infraestructura. No protege contra un DELETE FROM pedidos sin WHERE, que se replica al instante en la instancia en espera. Para eso están las copias de seguridad y la recuperación a un punto en el tiempo — apartado 11.

Documentado en alpinashop-infra como diseño listo para activar:

Tres comandos. El balanceador global envía cada petición a la región más cercana con capacidad, y si una región falla, deja de enviarle tráfico automáticamente.

Lo que impide activarlo hoy no es Cloud Run: es Cloud SQL. Con la base de datos solo en europe-west1, las instancias de Madrid tendrían que cruzar región en cada consulta —latencia y coste de tráfico— y si cae europe-west1, la base de datos cae igual. La alta disponibilidad la determina el componente menos disponible, y en AlpinaShop ese es Cloud SQL.

Los sistemas distribuidos fallan de formas concretas y conocidas. Diseñar contra ellas es más rentable que añadir redundancia.

Lo primero es distinguir dos tipos, porque el tratamiento es opuesto:

El fallo de diseño más común es tratar una dependencia blanda como si fuera dura. Un recomendador que tarda 5 segundos no debe hacer que la página de producto tarde 5 segundos: debe desaparecer de la página.

Toda llamada de red debe tener un tiempo de espera. Sin excepciones.

Un tiempo de espera ausente o demasiado largo es el mecanismo por el que un fallo pequeño se convierte en una caída total: las peticiones se acumulan esperando, se agotan los hilos, y el servicio deja de responder a todo, incluido lo que no dependía del sistema lento.

Regla de oro: el tiempo de espera de una llamada siempre debe ser menor que el tiempo de espera del que llama. Si Cloud Run corta a los 60 s y tu consulta espera 90 s, ese código nunca se ejecuta.

Reintentar está bien. Reintentar mal empeora el fallo:

Los cuatro elementos, y por qué cada uno:

1. Retroceso exponencial: dar tiempo a que el otro se recupere.
2. Jitter: sin él, mil clientes que fallaron a la vez reintentan a la vez, creando una onda sincronizada que vuelve a tumbar el servicio justo cuando se estaba levantando. Es un fallo real y frecuente, y el jitter cuesta una línea.
3. Límite de intentos: reintentar indefinidamente convierte un fallo en un ataque a tu propio sistema.
4. Solo errores transitorios: reintentar un 400 o un 403 no lo va a arreglar nunca; solo gasta tiempo y recursos.

Cuando un servicio lleva fallando un rato, deja de llamarlo:

El beneficio doble: el que llama deja de esperar (falla en microsegundos en vez de en segundos) y el que falla deja de recibir carga, lo que le permite recuperarse.

El principio que hace que un fallo parcial sea invisible:

La tienda sigue vendiendo aunque el recomendador falle.

Los tres niveles son la clave del patrón: plan A el recomendador; plan B algo simple y local —los más vendidos de la categoría, que casi nadie distinguirá—; plan C nada, y la página se sirve igual. Un cliente puede comprar en los tres casos, que es lo único que importa.

Y el detalle que hace posible medirlo: el log lleva "degradado": true. Sin esa marca, el servicio funciona degradado durante semanas y nadie se entera, porque el SLI de disponibilidad sigue en verde. Una alerta sobre el porcentaje de peticiones degradadas es lo que evita que la degradación elegante se convierta en degradación silenciosa.

Cuando la demanda supera la capacidad, hay dos opciones: degradar para todos o rechazar a algunos y servir bien al resto. La segunda es casi siempre mejor.

El último es el más sofisticado y el más útil: cuando hay saturación, no todas las peticiones valen lo mismo. Un usuario en el proceso de pago vale mucho más que un rastreador indexando la página 47 del catálogo.

Alta disponibilidad y recuperación ante desastres no son lo mismo, y confundirlos lleva a arquitecturas caras que no protegen de lo que de verdad pasa:

Un dato que reordena prioridades: la causa más frecuente de pérdida de datos no es un desastre natural ni un ataque. Es alguien ejecutando algo en el entorno equivocado. Y contra eso, la alta disponibilidad no sirve de nada: replica el error fielmente.

Con copias diarias a las 3:00 y un desastre a las 10:15, el RPO real son 7 horas y 15 minutos de datos perdidos. Para AlpinaShop, eso serían los pedidos de toda una mañana: inaceptable.

Cómo se elige, y no es por la tecnología: se calcula el coste de una hora de caída y se compara con el coste mensual de cada estrategia. Para AlpinaShop, una hora de caída en un día normal son unos 100 € de pedidos; en campaña, quizá 800 €. Con esos números, activo-activo —varios cientos de euros al mes, todos los meses— no se justifica.

Escrito, con responsables, y guardado también fuera de Google Cloud (porque si el desastre es de acceso a Google Cloud, el plan tiene que ser accesible).

El escenario 2 es el más probable con diferencia, y su RTO de 5 minutos ya está resuelto desde 07-02. Es un buen recordatorio de que el trabajo de fiabilidad más rentable ya estaba hecho antes de esta lección.

Las cuatro líneas que hacen el trabajo:

• point_in_time_recovery_enabled = true es lo que convierte un RPO de 24 horas en un RPO de minutos. Sin ella, solo se puede restaurar al momento de la última copia; con ella, a cualquier instante dentro de la ventana de logs de transacciones.
• location = "eu" guarda las copias fuera de la región. Copias en la misma región que muere con la región no son copias: son una ilusión.
• transaction_log_retention_days = 7 define la ventana de recuperación puntual. Siete días cubre el caso "alguien borró algo el lunes y nos dimos cuenta el jueves".
• deletion_protection impide el borrado accidental de la instancia entera.

Los datos no son lo único que hay que poder reconstruir:

Aquí se paga la deuda que 07-04 marcó como crítica.

Una copia de seguridad no probada no es una copia de seguridad: es una esperanza con nombre técnico.

Los motivos por los que una restauración falla el día que hace falta, todos reales y todos frecuentes:

Procedimiento completo, ejecutado trimestralmente por Marta, y cronometrado.

Paso 1 — Preparar y anotar la hora de inicio.

Paso 2 — Restaurar a una instancia NUEVA.

Nunca sobre la de producción. La restauración crea una instancia aparte, lo que hace el ensayo totalmente seguro:

Paso 3 — Verificar la integridad, que es lo que casi nadie hace.

Restaurar sin verificar solo demuestra que el comando funciona:

Paso 4 — Arrancar la aplicación contra la copia restaurada.

Este es el paso que descubre los problemas de verdad:

Paso 5 — Cronometrar, limpiar y documentar.

Y aquí está el valor del ejercicio, porque el primer ensayo nunca sale bien:

Cinco problemas que habrían convertido una restauración de 1 hora en una de 3 horas, con la tienda parada y todo el mundo mirando. Y ninguno era detectable sin ensayar.

Las cinco correcciones se escribieron en un runbook, se automatizó la creación del usuario y el reajuste de secuencias en un script de post-restauración, y se ajustó el RTO del escenario 3 de 1 hora a 90 minutos, que es un número honesto.

El ensayo no sirve para confirmar que las copias funcionan. Sirve para encontrar los cinco problemas que impiden que funcionen.

La fiabilidad la sostienen personas, y un equipo quemado es el mayor riesgo de fiabilidad que existe. Con tres personas técnicas, una guardia 24×7 tradicional es inviable: serían dos semanas de cada tres de disponibilidad permanente.

El modelo realista de AlpinaShop:

Y las reglas que lo hacen sostenible, que importan tanto como el calendario:

1. Solo despierta lo que hay que arreglar ya. Si una alerta llega de madrugada y la acción es "mirarlo mañana", esa alerta no debe sonar de noche. Es la regla que más reduce el desgaste.
2. Compensación real. Horas o dinero, acordado por escrito. La guardia no remunerada dura hasta que alguien se harta.
3. Máximo dos noches interrumpidas seguidas. Si pasa, se releva.
4. Toda alerta nocturna se revisa el día siguiente: ¿era necesaria? Si no, se ajusta o se elimina.
5. Menos alertas es mejor. La fatiga de alertas (06-04) es un problema de fiabilidad: una persona que ha aprendido a ignorar el móvil ignorará también la que importaba.

Un runbook es el documento que dice qué hacer ante una alerta concreta. Vive en alpinashop-infra/runbooks/ y se enlaza desde el campo documentation de la política de alerta.

gcloud run revisions list --service=alpinashop-web --region=europe-west1 --limit=5

gcloud run services update-traffic alpinashop-web --region=europe-west1
--to-revisions=REVISION_ANTERIOR=100

Las tres propiedades de un runbook útil: empieza por confirmar (no por diagnosticar), pone primero la causa más probable —un despliegue reciente, en el 70 % de los casos—, y dice explícitamente cuándo escalar, para que la persona de guardia no se quede sola dando vueltas a las 4 de la mañana.

Y una cuarta que se ve en la cabecera: "Probado en simulacro: sí". Un runbook que nadie ha ejecutado nunca es una hipótesis.

Tras un incidente significativo, un documento con estructura fija:

Sin culpables (blameless) no significa que no haya responsabilidades. Significa una cosa muy concreta:

Si la respuesta a "por qué pasó" es el nombre de una persona, el análisis se ha detenido demasiado pronto.

Ejemplo aplicado:

La razón práctica —no moral— de la ausencia de culpa: en una cultura donde se busca al culpable, la gente oculta los errores, y los errores ocultos no se corrigen. En una cultura sin culpa, la gente cuenta lo que pasó y el sistema mejora. Es una decisión de eficacia.

Todos los post-mortem en un sitio, con etiquetas. Al cabo de un año permite ver patrones que ningún incidente aislado revela: "el 60 % de nuestros incidentes son despliegues" es una frase que cambia las prioridades de un equipo entero.

Ingeniería del caos es provocar fallos a propósito para verificar que el sistema los tolera. Netflix popularizó la idea matando instancias en producción; una pyme no necesita eso, pero sí necesita algo.

Todo sistema tiene pruebas de recuperación ante desastres. Unos las hacen a propósito; otros esperan a que ocurran.

Los experimentos de AlpinaShop, ordenados de menos a más agresivo:

Las reglas que hacen esto responsable en lugar de temerario:

1. Hipótesis escrita antes. Si no sabes qué esperas, no es un experimento: es romper cosas.
2. Empezar en desarrollo.
3. Radio de explosión pequeño, y ampliarlo solo cuando el anterior salió bien.
4. Un botón de parada y la capacidad de abortar en cualquier momento.
5. Nunca en campaña. Ni el viernes por la tarde.
6. Avisar al equipo. El caos no anunciado con guardias reales es una broma pesada.

El experimento 3 merece un comentario, porque asusta y no debería: la conmutación de Cloud SQL va a ocurrir algún día, elegida por Google y en el peor momento. Provocarla un martes a las 10 de la mañana, con todo el mundo delante y con la posibilidad de arreglarlo, es infinitamente mejor que descubrir un viernes de campaña que la aplicación no reconecta porque le falta pool_pre_ping (07-02).

Y el experimento 7 es el más subestimado: que solo Marta sepa revertir un despliegue es un punto único de fallo humano. Que Dani y Lucía lo hayan hecho al menos una vez cada uno vale más que cualquier redundancia de infraestructura.

• Poner como objetivo "que no se caiga nunca". No se puede cumplir, medir ni usar para decidir. Elige un número y págalo.
• Confundir SLO y SLA. El SLO siempre más exigente que el SLA, con margen holgado.
• Medir el SLI desde el servidor. Se mide desde donde está el usuario: el balanceador o una comprobación externa.
• Definir el SLI de latencia como "el p95 < X". Es "la proporción de peticiones < X". Un percentil no se combina con un presupuesto de error.
• Contar los rechazos legítimos de la pasarela como errores. El SLI pasaría a depender de la solvencia de los clientes.
• SLO sobre CPU o memoria. No son experiencia de usuario. Se monitorizan, no se convierten en objetivo.
• Ventanas de mes natural. Crean el incentivo de esperar al día 1 para desplegar lo arriesgado. Ventana móvil de 28 días.
• Un SLO sin política asociada. Si al incumplirlo no cambia nada, es un adorno.
• Congelar por agotar el presupuesto cuando la culpa fue de la plataforma. La política pierde credibilidad y el equipo deja de respetarla.
• Perseguir un presupuesto consumido al 5 %. Señal de exceso de conservadurismo o de un SLO demasiado laxo.
• Alertas de umbral fijo sobre errores. O son ruidosas o no detectan degradaciones lentas. Usa tasa de consumo con dos ventanas.
• Dejar vacío el campo documentation de la alerta. A las 3 de la madrugada, ese texto vale más que la propia alerta.
• Llamadas de red sin tiempo de espera. Es el mecanismo por el que un fallo pequeño se convierte en caída total.
• Reintentos sin jitter. Mil clientes reintentando a la vez tumban el servicio justo cuando se recuperaba.
• Reintentar errores permanentes. Un 403 no mejora por insistir.
• Tratar una dependencia blanda como dura. El recomendador no debe poder tumbar la ficha de producto.
• Degradar sin marcarlo en los logs. El servicio funciona a medias durante semanas y el SLI sigue verde.
• Copias en la misma región. No son copias: son una ilusión.
• Creer que HA protege de un borrado accidental. Lo replica al instante en la instancia en espera.
• No probar la restauración. Es la deuda más peligrosa porque es invisible hasta el día que importa.
• Guardias sin compensación. Duran hasta que alguien se harta, y entonces te quedas sin guardias y sin persona.
• Buscar culpables en un post-mortem. Los errores se ocultan, y los errores ocultos no se corrigen.
• Consejo: empieza por un SLO de disponibilidad y nada más. Cuatro SLO desde el primer día es demasiado. Uno bueno vale más que cuatro copiados.
• Consejo: la reversión rápida vale más que la redundancia. La causa más frecuente de caída es un cambio, no un fallo de hardware.
• Consejo: que todo el equipo sepa revertir un despliegue. Es la redundancia más barata que existe.
• Consejo: cronometra el ensayo de restauración. El número real siempre sorprende, y es el que da un RTO honesto.

Dani va a lanzar alpinashop-buscador (el servicio del ejercicio de 07-02). Define su SLI y su SLO completos:

1. Qué eventos son válidos y cuáles buenos, resolviendo explícitamente al menos seis casos límite.
2. El SLO y la ventana, justificados.
3. El presupuesto de error resultante en minutos y en peticiones.
4. Las dos alertas de tasa de consumo con sus umbrales.
5. La política de qué se hace en cada estado del presupuesto.

Considera que el buscador es una dependencia blanda del catálogo: si falla, se puede mostrar un enlace a la navegación por categorías.

AlpinaShop lanza AlpinaPro, un servicio de suscripción para clubes de montaña: cuota mensual, contenido exclusivo y reservas de material. Datos:

• 400 suscriptores, 25 €/mes cada uno: 10.000 €/mes de ingreso recurrente.
• Base de datos propia alpinapro-suscripciones (PostgreSQL).
• Integración con la pasarela para cobros recurrentes el día 1 de cada mes.
• Los clubes reservan material con 48 h de antelación; una reserva perdida es una queja seria.
• Dirección dice que "no se puede caer nunca", pero el presupuesto adicional es de 150 €/mes.

Diseña: los SLI y SLO del servicio, el RTO y RPO justificados con números de negocio, la estrategia de recuperación elegida dentro del presupuesto, y la configuración concreta de copias. Explica qué le respondes a dirección sobre el "no se puede caer nunca".

Los hechos. Martes, 18:42. Salta la alerta de consumo rápido. Cronología reconstruida:

• 18:30 — Cloud Build despliega la revisión alpinashop-web-00051 con canario al 10 %. Las pruebas de humo pasan.
• 18:38 — Marta aprueba el paso al 100 % (llevaba prisa, se iba a las 18:45).
• 18:42 — Alerta: tasa de consumo 22×. Errores 500 en el 35 % de las peticiones.
• 18:44 — Marta ve la alerta ya en el coche. No puede actuar.
• 18:51 — Dani, avisado por Marta, se conecta y revierte a la revisión 00050.
• 18:53 — Los errores desaparecen.
• Impacto: 11 minutos, ~230 peticiones fallidas, 4 pedidos perdidos, 27 % del presupuesto mensual consumido.
• Causa técnica: la revisión nueva leía una variable de entorno TARIFA_ENVIO que solo estaba definida en alpinashop-dev.

Escribe el post-mortem completo siguiendo la estructura del apartado 12, con los cinco porqués llevados hasta una causa sistémica, y al menos cinco acciones concretas con responsable. Señala también qué hizo bien el equipo.

Solución 1 — Definir el SLO de alpinashop-buscador

1. Definición del SLI.

SLI de disponibilidad = peticiones de búsqueda con respuesta útil / peticiones de búsqueda válidas

Casos límite, resueltos y anotados:

El caso "0 resultados" es el que más discusión genera y es importante acertarlo. Contarlo como malo haría que el SLI midiera la calidad del catálogo en lugar de la fiabilidad del servicio, y bajaría cada vez que alguien busca algo que no vendemos. La calidad de la búsqueda se mide aparte, con métricas de producto —tasa de búsquedas sin resultado, tasa de clic— que no son un SLO.

SLI de latencia = búsquedas servidas en < 500 ms / búsquedas válidas

500 ms y no 800 ms como el catálogo, porque un buscador es interactivo: el usuario escribe y espera. La percepción de lentitud aparece antes.

2. SLO y ventana.

La justificación del 99,5 % es la parte interesante del ejercicio. El buscador es una dependencia blanda: si falla, el catálogo muestra un enlace a la navegación por categorías y el cliente puede seguir comprando. Un servicio blando no necesita el mismo objetivo que uno crítico, y ponerle 99,9 % significaría gastar dinero e ingeniería en una fiabilidad que no cambia el resultado de negocio.

Este es el razonamiento que hay que llevarse: el SLO se deriva del impacto de negocio del fallo, no del cariño que se le tenga al servicio.

3. Presupuesto de error.

Con 99,5 % sobre 28 días: 0,5 % = 3 h 21 min 36 s.

En peticiones: si el buscador recibe unas 150.000 búsquedas válidas en 28 días, el presupuesto son 750 búsquedas fallidas.

Es cómodo, y a propósito: permite desplegar mejoras del buscador con frecuencia sin que un fallo puntual bloquee al equipo.

4. Las dos alertas.

Ninguna de las dos despierta a nadie, y esa es la consecuencia lógica de ser una dependencia blanda con SLO del 99,5 %. Levantarse a las 4 de la mañana porque el buscador falla, cuando la tienda sigue vendiendo, es exactamente el tipo de alerta que produce fatiga y hace que se ignore la que sí importa.

La excepción que hay que prever: si el buscador cae y además el catálogo empieza a fallar —porque el tiempo de espera no cortaba y se agotaron los hilos—, la alerta que sonará es la del catálogo, que sí es de página. El diseño de alertas debe reflejar el diseño de dependencias.

5. Política de presupuesto.

La fila roja es la clave del ejercicio. Cuando un servicio blando agota su presupuesto, la pregunta prioritaria no es "cómo lo hago más fiable" sino "¿está bien aislado?". Un buscador que falla el 2 % del tiempo sin afectar a nadie es un problema menor; un buscador que falla el 0,5 % del tiempo y cada fallo degrada la ficha de producto es un problema grave.

Solución 2 — Diseñar un plan de recuperación para AlpinaPro

Punto de partida: traducir el negocio a números.

Y aquí está el matiz que distingue un análisis bueno de uno superficial: en un servicio de suscripción, el ingreso no se pierde por estar caído. Los 400 suscriptores pagan igual. Lo que se pierde es otra cosa, y es peor:

Conclusión: una caída de 4 horas que provoque 5 bajas cuesta 3.000 €, no 55 €. El análisis por ingreso prorrateado subestima el impacto en más de un orden de magnitud, y es un error muy común en servicios de suscripción.

SLI y SLO propuestos.

El tercero es el más interesante y el que se suele olvidar. El cobro recurrente no es un servicio continuo: es un proceso que se ejecuta un día al mes. Un SLO mensual sobre él no tiene sentido; lo que hace falta es un objetivo distinto: "el 99,99 % de los cobros programados se ejecutan correctamente dentro de las 24 horas siguientes", con reintentos. Y un tratamiento arquitectónico específico: cola con reintentos y DLQ, no una ejecución única que o funciona o se pierde.

RTO y RPO justificados.

Estrategia dentro de 150 €/mes.

Presupuesto muy ajustado. Reparto:

Estrategia elegida: luz piloto. La base de datos replicada en la segunda región es lo único que se mantiene encendido; el cómputo en Cloud Run se levanta con tres comandos (apartado 7) porque la imagen ya existe y Cloud Run escala desde cero. RTO estimado: 30-60 minutos, mejor que el objetivo de 6 h.

Lo que no se hace y por qué: activo-activo costaría 400-600 €/mes para cubrir un evento de probabilidad muy baja, cuando el presupuesto entero son 150 €.

Configuración de copias.

Dos decisiones a señalar: la ventana de mantenimiento el miércoles, deliberadamente lejos del día 1 —un mantenimiento de Google durante el ciclo de cobros sería el peor momento posible—, y la réplica de DR en modo ZONAL, porque pagar HA para una réplica que solo se usa en un desastre es duplicar el coste de un seguro.

Qué se le responde a dirección.

"No podemos garantizar que no se caiga nunca, y quien lo prometa no está diciendo la verdad. Lo que sí podemos hacer es decidir cuánto estamos dispuestos a que se caiga y pagarlo.

Con los 150 € al mes que tenemos, el compromiso es este: si falla una máquina o un centro de datos concreto, se recupera solo en cinco minutos y sin perder ningún dato. Si alguien borra algo por error, lo recuperamos en dos horas perdiendo como mucho cinco minutos de reservas. Y si cayera una región entera de Google —algo muy poco frecuente pero posible—, estaríamos funcionando en menos de una hora desde Madrid.

Para el proceso de cobro del día 1 tenemos un tratamiento aparte, porque es el momento crítico del mes: si algo falla, se reintenta automáticamente durante 24 horas y ningún cobro se pierde.

Lo que no cubrimos con este presupuesto es la caída simultánea de dos regiones o un problema global de Google. Cubrirlo costaría entre tres y cuatro veces más, todos los meses, para un escenario que quizá no ocurra nunca.

Y hay algo que quiero pedir además del presupuesto: probar todo esto cada trimestre. Un plan de recuperación que no se ensaya no funciona el día que hace falta, y lo sabemos porque nos pasó con la tienda: la primera vez que probamos restaurar la base de datos encontramos cinco problemas que habrían triplicado el tiempo de recuperación."

Solución 3 — Post-mortem del incidente del 18:42

Post-mortem: errores 500 en el catálogo tras el despliegue 00051

Fecha del incidente: martes 2026-08-04, 18:42-18:53 Autor: Marta Ruiz · Revisado por: Dani, Lucía Estado: acciones en curso · Clasificación: sin culpables

Resumen. Un despliegue promocionado al 100 % del tráfico contenía código que dependía de una variable de entorno inexistente en producción, provocando errores 500 en el 35 % de las peticiones durante 11 minutos.

Impacto.

Cronología.

Causa raíz — los cinco porqués.

1. ¿Por qué fallaron las peticiones? El código leía os.environ["TARIFA_ENVIO"], que no existía en producción, lanzando KeyError.
2. ¿Por qué no existía? Se añadió a alpinashop-dev durante el desarrollo y no se propagó a producción.
3. ¿Por qué no se propagó? Las variables de entorno de producción se gestionan en Terraform, pero el desarrollo las configura con gcloud a mano. No hay un mecanismo que garantice la paridad.
4. ¿Por qué no lo detectó el canario? Las pruebas de humo solo comprueban /salud y /producto/1, y ninguna de esas rutas usa TARIFA_ENVIO (solo la del carrito). Además el canario duró 8 minutos con tráfico bajo.
5. ¿Por qué se promocionó al 100 % con esa cobertura? Porque el proceso permite aprobar manualmente sin ninguna comprobación automática de la revisión candidata, y la aprobación se dio con prisa al final de la jornada.

Causa raíz sistémica: no existe verificación automática de que una revisión candidata tenga toda su configuración presente en el entorno de destino, ni una comprobación objetiva que deba pasar antes de la promoción al 100 %. La aprobación manual es el único control y depende del estado y la disponibilidad de una persona.

Qué fue bien — y esta sección importa tanto como la anterior:

• La alerta funcionó: 4 minutos desde el primer error hasta la notificación. Exactamente lo que 06-04 y las alertas de tasa de consumo prometían.
• La reversión fue trivial: un comando, 2 minutos, sin reconstruir nada. El trabajo de 07-02 se pagó solo en este incidente.
• La escalada funcionó: Marta, sin poder actuar, avisó a Dani en 3 minutos en lugar de intentar arreglarlo conduciendo.
• El presupuesto de error hizo su trabajo: convirtió "11 minutos, no fue para tanto" en "el 27 % del presupuesto mensual", que es un dato que obliga a actuar.
• Nadie buscó culpables durante el incidente. Se arregló primero y se analizó después.

Acciones.

Nota sobre la acción 5. Podría parecer una regla burocrática que ralentiza al equipo, y merece justificarse: no se prohíbe desplegar por la tarde —el canario puede correr toda la noche al 10 %— sino promocionar al 100 % cuando no queda nadie disponible para reaccionar. La restricción no es sobre el riesgo del cambio, sino sobre la capacidad de respuesta. Esa distinción es la que hace que el equipo acepte la regla en lugar de saltársela.

Lo que este incidente NO fue. No fue un error de Dani por escribir código que lee una variable, ni de Marta por aprobar con prisa. Fue un sistema que permitía promocionar al 100 % del tráfico un cambio cuya configuración nadie había verificado, en un momento en el que nadie podía reaccionar. Cualquiera de los tres habría hecho lo mismo, y por eso las siete acciones son sobre el sistema y ninguna sobre las personas.

AlpinaShop ha dejado de aspirar a "que no se caiga nunca" y ha empezado a gestionar la fiabilidad con números.

Sabes que cada nueve multiplica el coste y has hecho la cuenta que casi nadie hace: pasar de 99,9 % a 99,99 % le ahorraría a AlpinaShop unos 70 € al mes en pedidos y le costaría varios cientos. Decir "99,99 % sería una mala inversión" con la tabla delante es una de las aportaciones más valiosas de un ingeniero, y requiere haber calculado también los dos matices: que no todo el tiempo caído vale igual y que hay costes que no son pedidos perdidos.

Distingues SLI, SLO y SLA con precisión, con las tres reglas que evitan casi todos los errores —el SLO siempre más exigente que el SLA, el SLI medido desde donde está el usuario, y un SLO sin consecuencia no es un objetivo— y con la definición operativa que resuelve las dudas: eventos buenos / eventos válidos, donde el trabajo de verdad está en decidir qué es cada cosa.

Has elegido cuatro SLI recorriendo el viaje del cliente —disponibilidad, latencia, éxito del pago y frescura analítica— resolviendo por escrito los casos límite: el 404 es bueno, el 429 a un atacante ni siquiera es válido, y un rechazo por fondos insuficientes no es un fallo nuestro, decisión que hay que tomar en el código instrumentando rechazado_legitimo frente a error_tecnico. Y sabes por qué no hay SLI de CPU: porque a ningún cliente le importa.

Dominas el presupuesto de error: la tabla de nueves traducida a minutos, la ventana móvil de 28 días que evita el incentivo perverso del mes natural, y sobre todo para qué sirve de verdad — resolver con un número la tensión entre desplegar rápido y no romper nada, con una política de cuatro estados y la cláusula de credibilidad de no congelar cuando el fallo fue de la plataforma. Con el uso que casi nadie hace: un presupuesto consumido al 5 % es tan mala señal como uno agotado.

Sabes crear SLO en Cloud Monitoring desde Terraform, distinguir SLI basados en peticiones de basados en ventanas, y montar alertas de tasa de consumo con dos umbrales y dos ventanas cada uno — la larga para evitar falsas alarmas, la corta para que la alerta se apague cuando el problema se arregla. Y sabes que el campo documentation, que casi todo el mundo deja vacío, vale más a las 3 de la madrugada que la alerta misma.

Tienes las arquitecturas de alta disponibilidad por niveles con la tabla componente a componente de AlpinaShop, la observación de que buena parte de la plataforma ya es multirregión sin esfuerzo porque los servicios globales de Google lo son, y las dos piezas que sí son regionales y críticas. Sabes exactamente qué compras con la HA de Cloud SQL —replicación síncrona de disco, otra zona, conmutación en 1-2 minutos— y qué no cubre: un DELETE sin WHERE se replica al instante. Y sabes que Cloud Run multirregión son tres comandos, pero que no se activa porque la disponibilidad la determina el componente menos disponible.

Diseñas contra los modos de fallo: dependencias duras y blandas —con el fallo de diseño más común, tratar una blanda como dura—, tiempos de espera en toda llamada de red con la regla de que el interno siempre sea menor que el externo, reintentos con retroceso exponencial y jitter para no crear ondas sincronizadas, interruptores de circuito, degradación elegante en tres niveles con la marca "degradado": true sin la cual la degradación se vuelve silenciosa, y limitación de carga con vertido por prioridad.

Sabes que alta disponibilidad y recuperación ante desastres no son lo mismo, y el dato que reordena prioridades: la causa más frecuente de pérdida de datos es alguien ejecutando algo en el entorno equivocado, y contra eso la HA no sirve porque replica el error. Manejas RTO y RPO y las cuatro estrategias con su coste, eligiendo por comparación con el coste real de una hora de caída.

Tienes el plan de AlpinaShop con siete escenarios —donde el más probable, un despliegue defectuoso, ya estaba resuelto desde 07-02—, la configuración de copias con las cuatro líneas que hacen el trabajo (point_in_time_recovery, location = "eu", retención de logs y deletion_protection) y la exportación de configuración, incluido el plan de DR guardado fuera de Google Cloud.

Y has pagado la deuda crítica de 07-04: el ensayo de restauración, cronometrado, con verificación de integridad y con la aplicación arrancada contra la copia. Con el resultado que importa: cinco problemas encontrados —47 minutos en lugar de "unos minutos", el usuario de la aplicación inexistente, permisos que faltaban, secuencias desincronizadas y ningún procedimiento escrito— que habrían triplicado el tiempo de recuperación real. El ensayo no confirma que las copias funcionan: encuentra los cinco problemas que impiden que funcionen.

Por último, tienes la práctica operativa: guardias sostenibles para tres personas con la regla que más desgaste evita —si la acción es "mirarlo mañana", esa alerta no suena de noche—, runbooks enlazados desde las alertas que empiezan por la causa más probable y dicen cuándo escalar, post-mortem sin culpables con la razón práctica y no moral de esa cultura, y pruebas de caos a escala razonable con sus seis reglas, donde el experimento más subestimado es que todo el equipo sepa revertir un despliegue.

Todo lo de esta lección funciona porque hay tres personas que lo sostienen. Y ahí está el límite: los SLO viven en un panel que alguien mantiene, la política de presupuesto de error se respeta porque el equipo la acordó, los runbooks se actualizan porque Marta se acuerda, y nada impide técnicamente que mañana alguien cree una VM con IP pública en una región de Estados Unidos, o desactive un log de auditoría, o borre por error un proyecto entero.

Eso ya no es fiabilidad: es gobierno. Y es lo único que queda por construir. La organización de AlpinaShop tiene hoy cinco proyectos, tres carpetas, decenas de cuentas de servicio, cuatro repositorios, un perímetro a medias y ninguna política que gobierne el conjunto — más una lista de deudas de 07-04 que empieza por "políticas de organización sin aplicar" y "logs de auditoría sin retención inmutable".

La última lección del módulo cierra el círculo: estructura de la organización, políticas que se heredan y se aplican solas, inventario de todo lo que existe, auditoría de verdad con retención inmutable, y zonas de aterrizaje desplegadas con Terraform — para que lo que se ha construido siguiendo a AlpinaShop no dependa de que tres personas se acuerden.