Probabilidad para sistemas que fallan

En «Qué es un modelo» viste la probabilidad como lo que sale de un softmax: un número de 0 a 1 que dice qué tan seguro está el modelo. Aquí vamos a usar la misma idea desde el otro lado. No para decir qué cree un modelo, sino qué tan seguido le pasa algo a un sistema: que un request tarde de más, que un servidor se caiga, que un pago sea fraude.

A cada cosa que puede pasar o no se le llama evento. Su probabilidad se escribe con una P: P(lento) = 0.01 se lee «la probabilidad de que un request sea lento es 0.01». Hay tres formas de decir lo mismo, y conviene pasar de una a otra sin pensar:

La probabilidad como frecuencia

En producción, la forma más útil de pensar una probabilidad es como una frecuencia: si repites algo muchas veces, la fracción de veces que pasa se acerca a su probabilidad. Lanza una moneda 10 veces y puede salir sol 7 veces: 70 %, lejos de 50 %. Lánzala 10,000 veces y vas a quedar muy cerca de 50 %. Con pocas repeticiones manda la suerte; con muchas, la probabilidad.

Un sistema en producción repite muchísimas veces. C01 recibe ≈ 10 millones de fotos al día (≈ 2.5 M publicaciones nuevas con ≈ 3 fotos cada una, más lo que piden otros equipos), y cada foto es un request. Con ese volumen, las probabilidades dejan de ser abstractas y se vuelven conteos:

Por eso un equipo de producción casi nunca discute si algo va a pasar. Discute cuántas veces va a pasar y qué hace el sistema cuando pase.

También del tiempo

La probabilidad también describe tiempo. Si un servidor estuvo caído 43 minutos en un mes de 30 días (43,200 minutos), estuvo arriba 43,157 de 43,200: el 99.9 % del tiempo. Dicho como probabilidad: si eliges un instante al azar del mes, la probabilidad de encontrarlo caído es 0.1 %. Esa fracción del tiempo en que algo funciona es su disponibilidad, y tiene su propia sección más adelante.

¿De dónde salen estos números? Hay dos fuentes. Se miden: cuentas en los registros (logs) cuántos requests tardaron de más y lo divides entre el total. O se suponen para diseñar, y entonces se dicen como supuesto. En la Ronda, casi todas las disponibilidades de cada pieza son ilustrativas: en tu sistema se miden.

Las dos reglas de siempre

1. Una probabilidad va de 0 (no pasa nunca) a 1 (pasa siempre).
2. Si unas opciones cubren todos los casos y no pueden pasar a la vez, sus probabilidades suman 1. Un request es lento o no lo es: P(lento) + P(no lento) = 0.01 + 0.99 = 1.

La segunda regla parece obvia, pero de ella sale el truco más útil de la lección. Lo ves en la siguiente sección.

Imagina un request que necesita a dos servicios, A y B. Cada uno, de vez en cuando, tarda de más. Para que el dibujo se vea, supongamos que cada uno es lento 1 de cada 10 veces. En un sistema real sería mucho menos, pero la cuenta es la misma.

Independientes: uno no te dice nada del otro

Dos eventos son independientes si saber que pasó uno no cambia la probabilidad del otro. A esa propiedad se le llama independencia. Si A y B corren en máquinas distintas y se atoran por razones distintas, cada uno por su propio disco o su propia memoria, que A haya sido lento no te dice nada de B: B sigue siendo lento 1 de cada 10 veces.

Son independientes dos lanzamientos de una moneda, dos dados o dos servidores en edificios distintos que fallan por su propio hardware. No lo son «llueve» y «hay tráfico», ni dos servidores que recibieron la misma versión con el mismo error. Si sabes que llovió, el tráfico es más probable. Si sabes que uno de esos servidores falló, el otro casi seguro también.

En el caso C08 de «Qué es un modelo» apareció la notación P(contacto | click): la probabilidad de que alguien contacte al vendedor sabiendo que hizo clic. La barra se lee «dado». Con ella, la independencia se escribe corto: A y B son independientes cuando P(B | A) = P(B). Saber A no mueve nada.

La regla del producto

Si A y B son independientes, la probabilidad de que pasen los dos es el producto de sus probabilidades. Es la regla del producto:

P(A y B) = P(A) × P(B)

¿Por qué multiplicar? Piensa en 100 requests. A es rápido en 90. De esos 90, B es rápido en 9 de cada 10, o sea en 81. Los dos rápidos: 81 de 100, que es 0.9 × 0.9 = 0.81. Multiplicar es tomar una fracción de una fracción.

En general, P(A y B) = P(A) × P(B | A): primero la fracción en que pasa A, y luego, dentro de esos casos, la fracción en que también pasa B. La independencia es justo lo que permite cambiar P(B | A) por P(B), un número que puedes medir por separado.

El complemento: lo que no pasa

La probabilidad de que algo no pase es 1 menos la probabilidad de que pase. Es el complemento: P(no A) = 1 − P(A). Sale directo de la segunda regla de la sección anterior: «pasa» y «no pasa» cubren todo y suman 1.

Su gran uso es contestar preguntas de «al menos uno». ¿Qué probabilidad hay de que al menos uno de los dos servicios sea lento? Contar todas las formas en que eso pasa es engorroso: A lento, B lento, o los dos. Su contrario, en cambio, es una sola cosa: los dos rápidos. Entonces:

P(al menos uno lento) = 1 − P(los dos rápidos) = 1 − 0.81 = 0.19

Por qué no se suman

La tentación es sumar: 10 % + 10 % = 20 %. Está mal, y el dibujo dice por qué: el cuadrito naranja, donde los dos son lentos, se cuenta dos veces, una en la fila de A y otra en la columna de B. La suma correcta le resta lo que contó doble: 0.1 + 0.1 − 0.01 = 0.19.

Sumar probabilidades solo es correcto cuando los eventos no pueden pasar a la vez. Se llaman excluyentes: «el request tardó menos de 100 ms» y «tardó entre 100 y 200 ms» se suman sin problema. Para «al menos uno» de varios eventos que sí pueden coincidir, usa el complemento.

Con probabilidades chicas la suma casi atina. Con 1 % cada uno: 1 − 0.99 × 0.99 = 1.99 %, contra el 2 % de la suma. Por eso el error se esconde: con dos piezas «funciona», y con cien se vuelve un disparate. Con cien piezas de 1 %, la suma diría 100 %, y la cuenta correcta, 1 − 0.99¹⁰⁰, da ≈ 63 %: lo ves a fondo en la siguiente sección.

La disponibilidad (availability) es la fracción del tiempo, o de los requests, en que un servicio responde bien. Se mide de dos formas:

• Por tiempo: minutos arriba ÷ minutos totales. Es sencilla, pero trata igual un minuto de las 4 de la mañana que uno del pico.
• Por requests: requests buenos ÷ requests válidos. Es la que usa C01. Cada respuesta trae un código de tres cifras: los que empiezan con 5, como 500 o 503, son errores del servidor, y los que empiezan con 4, errores de quien llama. Un request bueno no termina en un error del servidor y responde en 300 ms o menos. Válidos son todos menos los que fallan por culpa de quien llama: una foto de 50 MB, que se rechaza por pesada, no cuenta ni como buena ni como mala. Esa medida es un SLI, y la meta que se le pone, 99.9 % en 30 días, es su SLO, como viste en la lección de percentiles. C01 tiene además otro SLO, el de latencia: p99 ≤ 200 ms, medido en su API.

Los nueves

Las disponibilidades se nombran por sus los nueves (the nines): 99.9 % son «tres nueves» y 99.99 %, «cuatro nueves». En la lección de unidades ya los convertiste en tiempo: un mes de 30 días tiene 30 × 24 × 60 = 43,200 minutos, y la caída permitida es el complemento de la disponibilidad por esa ventana, (1 − disponibilidad) × 43,200. Con 99.9 % son 43.2 minutos; con 99.99 %, 4.32 minutos; con 99.999 %, ≈ 26 segundos. Cada nueve más divide entre 10 el tiempo que te puedes permitir caído.

Lo que cada nivel suele pedir, según la hoja de números de la Ronda (una regla práctica, no una norma):

99.9 % no es «casi nunca»

Tres nueves suena a perfección. No lo es: son 43 minutos al mes y, en C01, con 10 millones de requests al día, 0.1 % son 10,000 requests fallidos cada día. Un SLO de 99.9 % no promete que nada falle: promete que lo que falla cabe en ese número.

El presupuesto de error

Si el SLO es 99.9 %, el 0.1 % que sobra es el presupuesto de error (error budget): lo que se te permite fallar en la ventana. En C01 son 43.2 minutos al mes, medido en tiempo, o 0.001 × 10,000,000 × 30 = 300,000 requests al mes, ≈ 10,000 al día, medido en requests. Lo viste de pasada en la lección de unidades; aquí va para qué sirve.

La idea viene de la ingeniería de confiabilidad de Google (site reliability engineering, SRE): tratarlo como un presupuesto de verdad, que se gasta: en lanzar versiones nuevas (cada deploy arriesga un poco), en experimentos, en mantenimiento. Un presupuesto intacto a fin de mes no es un logro: quiere decir que el equipo pudo moverse más rápido. Uno agotado quiere decir que hay que frenar.

Un request de C01 pasa por tres piezas, una detrás de otra: el balanceador (ALB), que reparte el tráfico; el gateway, un programa en CPU que abre y prepara la foto, y Triton, el servidor que corre la ResNet-50 en una GPU T4. Esas piezas están en serie: el request necesita a las tres. Además, el gateway y Triton existen en dos copias, una en cada zona, y esas copias están en paralelo: basta con una.

En serie se multiplican las disponibilidades

Si el request necesita todas las piezas, funciona solo cuando funciona cada una. Con fallas independientes es la regla del producto aplicada a «funciona»:

disponibilidad en serie = a₁ × a₂ × … × aₙ

La última fila es un atajo útil: con disponibilidades altas, los minutos caídos de las piezas en serie casi se suman. Es el «sumar casi atina con probabilidades chicas» de la sección de independencia, ahora a tu favor: 0.0001 + 0.0005 + 0.001 = 0.0016, y la cuenta exacta da 0.0015994.

De aquí salen dos reglas de diseño. Con fallas independientes, un sistema no puede estar más disponible que el producto de lo que tiene en serie. Y pase lo que pase, nunca más que su pieza más débil: si tu servicio llama, sin plan B, a una base de datos de 99.95 %, prometer 99.99 % es prometer algo imposible.

En paralelo se multiplican las indisponibilidades

Si hay k copias de una pieza y basta con una, la pieza solo falla cuando fallan todas. Tener copias de sobra se llama redundancia (redundancy), y cada copia es una réplica: el mismo programa, corriendo en otra máquina. Si cada réplica está disponible con probabilidad a y fallan por separado, fallan todas con probabilidad (1 − a)^k, y por el complemento:

disponibilidad con k réplicas = 1 − (1 − a)^k

• Dos réplicas al 99 %: 1 − 0.01² = 1 − 0.0001 = 99.99 %. Dos piezas de dos nueves dan cuatro nueves.
• Dos réplicas al 99.5 %: 1 − 0.005² = 1 − 0.000025 = 99.9975 %: ≈ 1 minuto al mes, contra 216 de una sola.
• Tres réplicas al 99 %: 1 − 0.01³ = 99.9999 %: ≈ 2.6 segundos al mes.

Cada réplica más multiplica la indisponibilidad por (1 − a): con réplicas de 99 %, cada una agrega dos nueves. Eso, en el papel. La siguiente sección dice por qué la realidad casi nunca da esas cifras.

N+1: una de sobra

¿Cuántas réplicas? La regla más común se llama N+1: N son las que necesitas para atender el tráfico, y la +1 es la de repuesto, para que perder una no se note. En la lección de unidades contaste así las T4 de C01; aquí importa qué le pasa a la que queda:

La de repuesto tiene que estar donde no le pegue lo mismo que a la otra. Por eso C01 pone cada réplica en una zona de disponibilidad (availability zone, AZ) distinta: un centro de datos, o un grupo de ellos, con su propia electricidad, su enfriamiento y su red, separado de los demás de la misma región, que es el grupo de zonas que la nube tiene en una misma área geográfica. Dos réplicas en la misma máquina, o en la misma zona, no son un N+1 de verdad: si se va la luz, caen juntas.

Con esas cifras, la cadena completa de C01 queda así: el balanceador, que ya vive en las dos zonas, al 99.99 %; el gateway en dos zonas, con 1 − 0.0005² ≈ 99.99998 %, y Triton en dos zonas, con 1 − 0.005² = 99.9975 %. Multiplicadas en serie dan ≈ 99.99 %: unos 5 minutos al mes, muy por debajo de los 43 que permite el SLO. Y 4 de esos 5 minutos los pone el balanceador, la única pieza que entra a la cuenta sin una réplica en paralelo (su 99.99 % ya incluye sus propias copias).

Un reintento es una réplica en el tiempo

Volver a intentar algo que falló (retry) usa la misma cuenta. Si cada intento falla el 1 % de las veces, sin depender del anterior, los dos intentos fallan solo 0.01 × 0.01 = 0.01 % de las veces. «Sin depender del anterior» es la letra chica: si el intento falló porque el servidor está caído, el segundo va a fallar igual.

Sacar al modelo del camino crítico

Hay algo todavía mejor que tener copias de una pieza: que el producto no la necesite, o sea, sacarla del camino crítico, lo que tiene que funcionar para que el producto funcione. En C01, si el modelo no contesta en 300 ms, el backend de publicación (el programa del marketplace que recibe lo que publica Ana) muestra el selector de categorías y Ana elige a mano. Ese fallback no depende del modelo, así que la disponibilidad del modelo deja de multiplicarse con la de publicar: si el modelo falla, publicar sigue funcionando, con un paso más para Ana. Por eso a C01 le basta con 99.9 % en una sola región. Un caso de pagos como C09, donde el modelo decide dentro de cada compra, pide 99.99 %: ≈ 4.3 minutos al mes.

La cuenta de la redundancia, 1 − (1 − a)^k, esconde una suposición enorme: que las réplicas fallan cada una por su lado. Cuando una misma causa las tumba a todas a la vez, se habla de una falla correlacionada, o de causa común. Es lo que de verdad tumba a los sistemas que tienen redundancia.

De dónde salen las fallas que llegan juntas

• El mismo error en todas las réplicas. Una versión con un error, o un cambio de configuración, se aplica a todas a la vez. Las dos zonas quedan perfectamente sanas… corriendo el mismo error.
• Todo un dominio de falla. Lo que depende de un mismo punto débil forma un dominio de falla (failure domain): una máquina, un rack (el mueble donde se apilan varias máquinas), una zona, una región. Dos réplicas en la misma zona caen juntas cuando cae la zona.
• Una dependencia compartida. Las dos réplicas leen la misma base de datos, el mismo caché (una copia rápida de datos que se consultan seguido) o el mismo certificado de seguridad (el archivo con el que un servidor demuestra quién es), que vence el mismo día para todas. Hasta el plan B puede depender de lo que falló: la Ronda (M15) da el ejemplo de un plan B que guarda sus respuestas en el mismo servidor de caché que usa el camino principal, en la misma zona. Si ese servidor se cae, caen los dos.
• La sobrecarga que se contagia. Si una réplica cae y la otra no aguanta el doble de tráfico, cae también: la segunda falla la causó la primera. Por eso el N+1 se mide con el tráfico del pico: la T4 que queda en C01 tiene que aguantar 500 por segundo sola.
• Reintentos en manada. Si un servicio se cae y cada cliente reintenta 3 veces, el servicio recibe hasta 4 veces su tráfico justo cuando está más débil. Los reintentos de miles de clientes llegan juntos, no al azar: es una tormenta de reintentos (retry storm).

La causa común manda

Supón que, además de sus fallas propias, de vez en cuando algo tumba a las dos zonas de Triton a la vez: digamos el 0.1 % del tiempo, por un deploy malo o una configuración rota. La cuenta cambia así:

Fíjate qué pasó. La segunda zona bajó la falla propia de Triton de 216 minutos al mes a ≈ 1, pero no tocó los 43 de la causa común. Una tercera zona tampoco los tocaría. Contra una causa común, más copias de lo mismo no sirven.

Cómo se defiende uno

Contra una causa común no sirve multiplicar réplicas. Sirve que la causa no llegue a todas a la vez:

• Cambiar de a poco. Una versión nueva entra primero a una parte chica del tráfico, en C01 el 5 %, y a una zona a la vez. A esa primera parte se le llama canary, por los canarios que los mineros bajaban a la mina para detectar gases. Si los errores suben, se regresa a la versión anterior en minutos, antes de que llegue a la otra zona. Lo ves en la Ronda, en M11.
• Un plan B que no comparta nada. El selector manual de C01 no usa el modelo ni nada de lo que el modelo usa: si se cae todo lo del modelo, sigue ahí. Un plan B que depende de lo mismo que falló no es plan B.
• Reintentar con medida. Pocos reintentos, en una sola capa del sistema, con esperas cada vez más largas y solo para lo que es seguro repetir. Lo ves en la lección «Timeouts, reintentos e idempotencia».
• Ensayarlo. Apagar una zona a propósito en un ensayo programado (game day) para descubrir qué compartían las réplicas sin que nadie lo supiera.

Casi todos tienen la misma raíz: una cuenta que supone algo (independencia, una sola pieza, el promedio) sin decir que lo supone.

Sumar lo que se multiplica

Qué pasa: «cada uno de los 50 servicios es lento el 1 %, así que el request es lento el 50 %». Sumar solo vale con eventos excluyentes, y aquí pueden coincidir. La cuenta correcta da 1 − 0.99⁵⁰ ≈ 39.5 %. Con 150 servicios, la suma diría 150 %.

Cómo evitarlo: para «todos funcionan», multiplica las probabilidades de funcionar. Para «al menos uno falla», usa el complemento: 1 − P(todos funcionan). Si una probabilidad te da más de 1, la cuenta está mal.

Suponer independencia sin revisarla

Qué pasa: se multiplica sin preguntar si las cosas se mueven juntas. Dos tramos de un request son lentos el 2 % de las veces cada uno, y se calcula que los dos son lentos a la vez solo 0.02 × 0.02 = 0.04 %. Pero si a los dos los vuelve lentos la misma foto gigante, pasan juntos casi el 2 % de las veces: 50 veces más.

Cómo evitarlo: antes de multiplicar, pregunta si hay una causa que mueva a los dos. Si la hay, no supongas: mide en los datos cuántas veces pasan juntos.

Olvidar las fallas correlacionadas

Qué pasa: se calcula «dos réplicas al 99.5 % dan 99.9975 %» y se promete eso, pero las dos réplicas reciben la misma versión el mismo día, o viven en la misma zona, o leen la misma base. La primera causa común se come los nueves.

Cómo evitarlo: para cada par de réplicas, pregunta qué comparten: máquina, zona, versión, configuración, dependencias, el mismo plan B. Cambia de versión de a poco y una zona a la vez, y pon en la cuenta una causa común con su probabilidad, aunque sea estimada.

Creer que 99.9 % es «casi nunca»

Qué pasa: «falla uno de cada mil, eso no es nada». Con 10 millones de requests al día son 10,000 fallas diarias, y como tiempo son 43 minutos al mes.

Cómo evitarlo: traduce siempre el porcentaje a conteos y minutos con el volumen real: «0.1 % = 10,000 requests al día = 43 minutos al mes». Y pregunta qué vive la persona en esas 10,000 veces: con plan B es una molestia; sin plan B, alguien que no pudo publicar.

Prometer más nueves que la cadena

Qué pasa: tu servicio depende en serie de un balanceador al 99.99 %, de una base al 99.95 % y del servicio de otro equipo al 99.9 %, y prometes 99.99 %. El producto da ≈ 99.84 %: lo prometido es imposible desde el diseño.

Cómo evitarlo: antes de aceptar un SLO, multiplica lo que está en serie. Si no alcanza, las salidas son réplicas en paralelo para lo que se puede copiar, o un plan B que saque del camino crítico a la pieza débil.

Medir cada pieza y no el conjunto

Qué pasa: cada uno de los 10 servicios de un fan-out cumple su p99, y el equipo celebra. Pero ≈ 9.6 % de los requests toca la cola de alguno, y el p99 de lo que vive la persona es mucho peor que el de cualquier pieza.

Cómo evitarlo: mide la latencia y la disponibilidad de punta a punta, donde las vive quien llama. Y a cada pieza pídele lo que el conjunto necesita: con 10 en paralelo, su p99.9.

Dimensionar para el promedio

Qué pasa: «llegan 10 por segundo y el servidor atiende 10 por segundo: alcanza». Con llegadas al azar, ≈ 8 % de los segundos trae 15 o más, y cada uno forma una fila que tarda en vaciarse. Lo que no es aleatorio, como las notificaciones y los reintentos, lo empeora.

Cómo evitarlo: dimensiona para el pico y agrega margen (C01: promedio 116, pico 350 y diseño 500 por segundo), y planea las máquinas lejos del 100 % de uso, por ejemplo al 50 %.

Resuélvelos con lápiz antes de abrir la solución. Los primeros cuatro son directos; los dos últimos piden juntar varias ideas.

1. 1Fácil

   Un servicio responde mal el 0.2 % de los requests y recibe 5 millones al día. ¿Cuántas respuestas malas se esperan al día? ¿Qué probabilidad tiene un request de salir bien?

   Ver la solución paso a paso

   Respuestas malas esperadas: 5,000,000 × 0.002 = 10,000 al día. Es un valor esperado, N × p.

   Salir bien es el complemento: 1 − 0.002 = 0.998 = 99.8 %.

2. 2Fácil

   Un request necesita a dos servicios en serie, independientes, cada uno con 99.9 % de disponibilidad. ¿Qué disponibilidad tiene el conjunto? ¿Cuántos minutos caído es eso en un mes de 30 días?

   Ver la solución paso a paso

   Regla del producto: 0.999 × 0.999 = 0.998001 ≈ 99.8 %.

   Caído: (1 − 0.998001) × 43,200 = 0.001999 × 43,200 ≈ 86.4 minutos. Con el atajo de sumar los minutos de cada pieza: 43.2 + 43.2 = 86.4. El doble de lo que permite cada pieza por separado.

3. 3Fácil

   ¿Cuánto tiempo caído permite 99.95 % en un mes de 30 días? ¿Y en un día?

   Ver la solución paso a paso

   Mes: 43,200 × 0.0005 = 21.6 minutos.

   Día: 1,440 minutos × 0.0005 = 0.72 minutos = 43.2 segundos.

4. 4Fácil

   Un request hace fan-out a 5 servicios, cada uno lento el 2 % de las veces, de forma independiente. ¿Qué probabilidad hay de que el request sea lento? ¿Qué diría la suma?

   Ver la solución paso a paso

   Los 5 rápidos: 0.98⁵ ≈ 0.904. Al menos uno lento: 1 − 0.904 ≈ 9.6 %.

   La suma diría 5 × 2 % = 10 %. Con probabilidades chicas casi atina, pero ya se pasa.

5. 5Medio

   Un servicio tiene dos réplicas, cada una con 99 % de disponibilidad, independientes, y basta con una. ¿Qué disponibilidad tiene? ¿Y con tres réplicas? Pásalo a tiempo caído por mes.

   Ver la solución paso a paso

   Dos réplicas: 1 − 0.01² = 1 − 0.0001 = 99.99 %, que son 43,200 × 0.0001 = 4.32 minutos al mes.

   Tres réplicas: 1 − 0.01³ = 1 − 0.000001 = 99.9999 %, que son 43,200 × 0.000001 = 0.0432 minutos ≈ 2.6 segundos al mes.

   En el papel, cada réplica de 99 % agrega dos nueves. En la realidad, una causa común se come casi todo eso.

6. 6Medio

   El SLO de C01 es 99.9 % en 30 días, con 10 millones de requests al día. Un incidente hace fallar el 50 % de los requests durante 15 minutos. ¿Qué parte del presupuesto del mes se come?

   Ver la solución paso a paso

   Requests por minuto

   10,000,000 ÷ 1,440

   ≈ 6,944

   Requests fallidos en el incidente

   6,944 × 15 × 0.5

   ≈ 52,083

   Presupuesto del mes

   0.001 × 10,000,000 × 30

   =300,000

   Parte que se comió

   52,083 ÷ 300,000

   =≈ 17 %

   Resultado

   Quince minutos se comen más presupuesto que el deploy de dos horas con 5 % de errores (14 %). Lo que cuenta es cuántos requests fallan, no cuánto dura.

7. 7Medio

   Un request hace fan-out a 50 servicios, espera a los 50, y quieres que el 99 % de los requests sean rápidos. ¿Qué percentil tiene que cumplir cada servicio? ¿Y qué fracción de los requests sería lenta si cada uno solo cumpliera su p99?

   Ver la solución paso a paso

   Si q es la probabilidad de que cada servicio sea rápido, necesitas q⁵⁰ = 0.99, así que q = 0.99^(1/50) ≈ 0.99980.

   Con el atajo: 1 − 0.01 ÷ 50 = 1 − 0.0002 = 0.9998.

   Cada servicio tiene que cumplir su p99.98: ser lento solo 1 de cada 5,000 veces. Si solo cumpliera su p99, serían lentos 1 − 0.99⁵⁰ ≈ 39.5 % de los requests.

8. 8Medio

   Supón que el equipo de C01 hace ≈ 20 deploys al mes y que cada uno tiene 2 % de probabilidad de salir malo (los dos números son supuestos). Sin canary, un deploy malo deja el servicio caído 30 minutos. ¿Cuántos minutos caídos por deploys se esperan al mes? ¿Y si con un canary uno malo solo afecta al 5 % del tráfico durante 10 minutos?

   Ver la solución paso a paso

   Deploys malos esperados al mes: 20 × 0.02 = 0.4.

   Sin canary: 0.4 × 30 = 12 minutos esperados al mes, ≈ 28 % de los 43.2 que permite el SLO, solo por deploys.

   Con canary: cada deploy malo hace fallar el 5 % de los requests durante 10 minutos. Para el SLI, que cuenta requests, eso pesa lo mismo que 0.05 × 10 = 0.5 minutos con todo caído. Esperado al mes: 0.4 × 0.5 = 0.2 minutos, menos del 0.5 % del presupuesto.

   El canary no hace que los deploys salgan mal menos seguido: hace que cada uno cueste 60 veces menos. Es la misma palanca que el rollback rápido de «El presupuesto en la práctica»: no evita la falla, achica su daño.

9. 9Reto

   Las dos zonas de Triton en C01 tienen 99.5 % cada una, y un deploy malo las tumba a la vez el 0.1 % del tiempo. (a) ¿Qué disponibilidad tiene Triton? (b) Con canary y una zona a la vez, esa causa común baja a 0.02 % del tiempo. ¿Qué disponibilidad queda y cuántos minutos al mes se ahorran? (c) ¿Serviría más agregar una tercera zona, sin canary?

   Ver la solución paso a paso

   (a) Réplicas: 1 − 0.005² = 0.999975. Con la causa común: 0.999975 × 0.999 ≈ 0.998975 ≈ 99.90 %, que son (1 − 0.998975) × 43,200 ≈ 44.3 minutos al mes.

   (b) 0.999975 × 0.9998 ≈ 0.999775 ≈ 99.98 %: ≈ 9.7 minutos al mes. Se ahorran 44.3 − 9.7 ≈ 34.6 minutos.

   (c) Tres zonas sin canary: 1 − 0.005³ = 0.999999875, y por la causa común, 0.999999875 × 0.999 ≈ 0.999000 → ≈ 43.2 minutos al mes. Se ahorra ≈ 1 minuto. La tercera zona ataca la falla propia, que ya era chica; el canary ataca la causa común, que era casi todo.

10. 10Reto

    (a) Un servicio recibe en promedio 10 requests por segundo, al azar, y puede atender como máximo 15 por segundo. ¿En qué fracción de los segundos llegan más de los que puede atender? (b) ¿Por qué no es lo mismo que el «15 o más» de la lección?

    Ver la solución paso a paso

    (a) «Más de 15» es 16 o más. Con Poisson y λ = 10, P(16 o más) = 1 − P(0 a 15). Sumar 16 términos a mano es largo; en Python:

    python

    import math
    
    lam = 10   # promedio por segundo
    hasta_15 = sum(lam**k * math.exp(-lam) / math.factorial(k) for k in range(16))
    print("P(16 o más):", round(1 - hasta_15, 4))
    print("segundos por hora:", round(3600 * (1 - hasta_15)))

    Salida

    P(16 o más): 0.0487
    segundos por hora: 175

    ≈ 4.9 % de los segundos: ≈ 175 por hora en que llega más de lo que el servicio puede atender, y se forma una fila.

    (b) «15 o más» incluye los segundos con exactamente 15, que el servicio sí alcanza a atender. P(15 exactos) ≈ 3.47 %, y 4.87 % + 3.47 % ≈ 8.3 %, el número de la lección. En una cuenta de capacidad, ese «o más» mueve el resultado de 8.3 % a 4.9 %: lee la pregunta dos veces.

En la Ronda:

• M03 · Latencia y capacidad calcula el fan-out con 1 − 0.99^N (1 %, ≈ 9.6 % y ≈ 63.4 %), explica por qué los p99 de los tramos no se suman, usa Poisson para las ráfagas en ventanas de 10 ms y recorta la cola con hedging.
• M15 · Seguridad y confiabilidad define SLI, SLO y SLA, hace la disponibilidad compuesta de C01 en serie y en paralelo, con y sin causa común, y convierte el presupuesto de error en una política.
• M06 · Orquestación y escalado lleva el N+1 por zona a Kubernetes: las réplicas repartidas en dos zonas y qué falla cubre cada mecanismo.
• M02 · Patrones de inferencia advierte que cada llamada síncrona extra es cola que pagas, y M11 · Despliegue seguro explica el canary, la defensa contra el deploy malo.
• La hoja de números de la Ronda trae la tabla de nueves completa, por mes, por año y por día.

En el Dojo: cuando abran las estaciones 9 (Kubernetes) y 10 (Rollout seguro), vas a repartir las réplicas de C01 en dos zonas y a cambiar de versión de a poco, con las cuentas de esta lección.

En Sensei: la siguiente lección, «Ruido, muestras y pruebas A/B», usa la probabilidad para otra pregunta: si una métrica subió, ¿mejoró de verdad o fue suerte? Ahí vas a ver cuántos datos hay que juntar para que una diferencia no sea solo ruido, la misma pregunta que se hace un canary antes de decidir. Más adelante, «Timeouts, reintentos e idempotencia» desarrolla los reintentos que aquí solo contamos; «Qué tan rápido y cuánto: latencia y throughput» explica por qué la fila se dispara cerca del 100 % de uso, y «Regiones, zonas y disponibilidad», qué es exactamente una zona y cuándo vale la pena una segunda región.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Por qué se multiplican, y no se suman, las probabilidades de que dos servicios independientes funcionen?Ver respuesta

   Porque «los dos funcionan» es una fracción de una fracción: de los casos en que funciona A, solo en una parte funciona también B. Sumar sirve para eventos excluyentes. Para «al menos uno falla» se usa el complemento: 1 − P(todos funcionan).

2. 2Un request espera a 100 servicios, cada uno lento el 1 % de las veces. ¿Qué fracción de los requests es lenta?Ver respuesta

   1 − 0.99¹⁰⁰ ≈ 63 %. El p99 de cada pieza se vuelve la latencia típica del conjunto.

3. 3¿Cuánto es 99.9 % en minutos al mes? ¿Y 99.99 %?Ver respuesta

   Un mes de 30 días tiene 43,200 minutos: 43.2 minutos y 4.32 minutos. Cada nueve más divide el tiempo entre 10.

4. 4¿Qué es el presupuesto de error de C01 y para qué sirve?Ver respuesta

   Es 1 − SLO: 0.1 %, que son 43.2 minutos o 300,000 requests al mes. Se gasta en deploys y experimentos, y una política escrita de antemano dice qué hacer cuando se acaba, como congelar los lanzamientos riesgosos.

5. 5¿Por qué dos réplicas en la misma zona no son N+1?Ver respuesta

   Porque comparten lo que falla: si se cae la zona, caen juntas. La cuenta 1 − (1 − a)² supone fallas independientes, y contra una causa común más réplicas iguales no ayudan.

6. 6Llegan 10 requests por segundo en promedio. ¿Por qué no basta con atender 10 por segundo?Ver respuesta

   Porque las llegadas al azar se amontonan: se alejan del promedio en ≈ √10 ≈ 3, y ≈ 8 % de los segundos trae 15 o más. Se dimensiona para el pico, con margen.

7. 7Un pago de US$30 tiene probabilidad 0.05 de ser fraude, y aprobar un fraude cuesta US$45. ¿Cuál es el costo esperado de aprobarlo y qué significa?Ver respuesta

   0.05 × 45 = US$2.25. Ningún pago cuesta US$2.25: cada uno cuesta US$0 o US$45. Es lo que se pierde en promedio por pago, entre muchos pagos como ese.