Probar el sistema vivo evitaba 26 caídas de 40; comprar más redundancia, 9

Hay un número de 2003 que debería salir en más comités de dirección que en ninguno. Tres investigadores de Berkeley —David Oppenheimer, Archana Ganapathi y David Patterson— cogieron los informes internos de caída de tres grandes servicios de internet, los leyeron uno a uno y luego hicieron la pregunta que nadie hace después de un postmortem: ¿qué técnica, concretamente, habría evitado esta caída? Para el servicio del que tenían el material más completo, con cuarenta caídas analizadas, el ranking salió así: probar el sistema en marcha habría evitado 26; exponer y vigilar mejor los fallos habría acortado la detección o la reparación en más de diez casos; añadir más redundancia habría evitado 9.

Veintitrés años después, el presupuesto de infraestructura de casi cualquier empresa española está construido alrededor del 9. El segundo nodo, la segunda fuente, la segunda línea, la segunda cabina. Y el 26 —probar de verdad lo que ya está encendido— sigue siendo lo que se hace cuando sobra tiempo, que es nunca.

Qué midieron exactamente, y qué no

Conviene acotarlo antes de usarlo, porque un número así es fácil de estirar. El estudio se llama Why Do Internet Services Fail, and What Can Be Done About It? y se presentó en el simposio USITS de USENIX en 2003. Analiza tres servicios anonimizados: Online («un portal de internet maduro»), Content («un servicio global de alojamiento de contenido puntero») y ReadMostly («un servicio maduro de lectura mayoritaria»). De los dos primeros tenían 296 y 205 informes de fallo de componente respectivamente, que se tradujeron en 40 y 56 caídas de servicio —las que el usuario nota—. Del tercero, 21.

El ranking de técnicas que abre este post es del primer servicio, sobre esas cuarenta caídas. No es una ley universal ni una estadística del sector: es la cuenta de una casa concreta, hecha por gente que tenía los informes delante. Y hay otra precisión que toca hacer, porque cambia el significado de la palabra. Lo que el estudio llama online testing no es exactamente romper cosas a propósito. Lo definen así: «la prueba previa al despliegue previene fallos de componente en el sistema desplegado, y la prueba en marcha detecta componentes defectuosos antes de que fallen durante la operación normal». Es decir, comprobar que lo que ya está encendido hace lo que dice que hace. Y añaden un matiz que explica por qué casi nadie lo tiene montado: para que sirva, la prueba necesita «información semántica de la aplicación», su ejemplo literal es «publicar un artículo de noticias y comprobar que aparece». No vale con que el puerto 443 conteste.

Y una advertencia sobre el uso que vamos a darle, para que nadie se lleve una idea que el estudio no sostiene: el 26 no es la cifra de la inyección de fallos. Romper cosas a propósito aparece en ese mismo apartado como una técnica distinta y sin número, solo con la etiqueta de «beneficio potencial significativo». Todo lo que proponemos más abajo —apagar un nodo, quitar un cable, revocar una credencial— es una extrapolación nuestra desde el 26, no una conclusión suya. Lo decimos ahora y no en la nota de fuentes.

El 9 se compra; el 26 hay que hacerlo

La asimetría entre esos dos números no es técnica, es comercial. La redundancia tiene factura, albarán y número de serie: se aprueba en un comité, se amortiza en tres años y se puede enseñar. La prueba del sistema vivo no tiene nada de eso. Es tiempo de gente competente haciendo algo que, si sale bien, no produce ningún entregable visible —solo la confirmación de que lo que creías sigue siendo verdad—. Es, literalmente, lo más difícil de vender y lo más difícil de defender cuando hay que recortar.

Y, sin embargo, el mismo estudio explica por qué la redundancia rinde menos de lo que parece. La causa número uno de caída de servicio en dos de los tres servicios no fue el hierro: fue el operador. Los autores lo dicen sin adornos —«operator error is the leading cause of service failure in two of the three services»— y afinan todavía más: «más del 50 % (y en un caso casi el 100 %) de los errores de operador que provocaron caídas de servicio fueron errores de configuración», y esos errores «surgieron cuando los operadores estaban haciendo cambios en el sistema, por ejemplo escalando o reemplazando hardware, o desplegando o actualizando software».

Léelo despacio: escalar o reemplazar hardware está en la lista de actividades que provocan caídas. Comprar el segundo nodo no es gratis en riesgo; el día que lo montas, lo tocas. La redundancia no es un seguro que se firma y se olvida, es una pieza más que alguien tiene que mantener, actualizar y, cada cierto tiempo, cambiar. Hay un dato más del estudio que se cita poco y duele: los errores de operador «a menudo tardan significativamente más en repararse» que los demás tipos de error. El fallo del disco lo arregla un repuesto. El fichero de configuración mal escrito a las ocho de la tarde lo arregla alguien que primero tiene que darse cuenta de que fue eso.

Aquí toca decir algo que nos quita razón, porque está en el mismo apartado del estudio y omitirlo sería hacer trampa. Los autores no concluyen que haya que comprar menos redundancia. Cuando meten el coste en la ecuación escriben lo contrario: «observamos que las técnicas de añadir redundancia adicional y exponer y vigilar mejor los fallos ofrecen el bang for the buck más significativo (...) incurriendo en un coste relativamente bajo». Y avisan de algo más: Online ya usaba algo de redundancia, monitorización, aislamiento, reinicio proactivo y prueba previa y en marcha, así que la tabla infraestima lo que esas técnicas habrían aportado. Lo que no dicen en ninguna parte es que puedas saltarte el 26.

En 2003 ya le pusieron nombre a la otra mitad

El párrafo que cierra ese análisis es el que nos interesa de verdad, porque nombra algo que entonces no existía como disciplina: «la comprobación automática de sanidad de los ficheros de configuración, y la inyección de fallos y de carga en marcha, también parecen ofrecer un beneficio potencial significativo». Inyección de fallos en el sistema en producción. En 2003. Nueve años antes de que Netflix liberara Chaos Monkey como código abierto, el 30 de julio de 2012, y trece antes de que el equipo que lo mantenía escribiera el artículo que le puso marco académico.

Ese artículo —Chaos Engineering, de Basiri y otros seis autores, publicado en IEEE Software en 2016— define la idea en una frase que no tiene nada de épica: «muchas organizaciones tecnológicas grandes usan la experimentación para verificar la fiabilidad de estos sistemas; usamos el término Chaos Engineering para referirnos a este enfoque». Experimentación. Verificar. Son palabras de laboratorio, no de demolición.

Chaos Monkey rompe cosas de nueve a tres, y viene apagado

La fama de la herramienta ha hecho más daño que bien, porque el nombre evoca un simio suelto por el centro de datos. La documentación de Netflix, que es pública y se lee en diez minutos, describe algo bastante más aburrido y bastante más listo. Cada día laborable, por cada grupo de instancias, Chaos Monkey «lanza una moneda ponderada» para decidir si mata una; si sale cara, programa la terminación «en un momento aleatorio entre las 9:00 y las 15:00 de ese día». No de madrugada. No en fin de semana. En horario de oficina.

Sigue siendo más prudente. El fichero de configuración, en el apartado que la propia documentación titula «valores por defecto», arranca con enabled = false; sigue con el que más me gusta, leashed = true, con este comentario al lado: «si es verdadero, las terminaciones solo se simulan (solo se registran)»; y a continuación schedule_enabled = false. La herramienta más famosa de romper cosas en producción viene de fábrica desactivada, sin planificación y en modo simulacro. Y tiene una pieza más que casi nadie menciona: un outage checker, cuya documentación empieza así: «se usa para desactivar automáticamente Chaos Monkey durante caídas en curso». Es decir, no rompe nada si ya estás roto.

El parámetro que se ajusta, por cierto, no es la brutalidad: es la frecuencia. Se configura μ, la media de días laborables entre terminaciones, y la probabilidad diaria sale de ahí (p = 1/μ). Con μ=5, una de cada cinco jornadas. La agresividad de Chaos Monkey es un número que decide el dueño del servicio, y por defecto es cero.

No eres Netflix, y no hace falta que lo seas

Una empresa de software de cuarenta personas con tres nodos Proxmox, un Ceph pequeño, un servidor de copias y Microsoft 365 no necesita un demonio matando máquinas al azar. Necesita la otra parte de la disciplina, la que sí escala hacia abajo: el método. Los cinco principios publicados por quienes la formalizaron son construir una hipótesis sobre el comportamiento en estado estable, variar sucesos del mundo real, ejecutar en producción, automatizar y minimizar el radio de impacto. De esos cinco, los que valen dinero en una pyme son el primero y el último.

La ficha del experimento: seis campos en media cara de folio

Lo que separa un simulacro de una caída que te has provocado tú no es la herramienta: es haber escrito seis cosas antes de tocar nada. Si no están escritas, no es un experimento; es una corazonada con testigos.

• Hipótesis. Una frase falsable y concreta, no un deseo. «Si apago el nodo 2, las máquinas que corren en él arrancan en otro nodo y el ERP vuelve a dar login en menos de cinco minutos.» Si la frase no se puede desmentir con un reloj, no es una hipótesis.
• Radio de impacto. Qué entra y qué queda fuera, por escrito. Un nodo, no el clúster. Un buzón de pruebas, no el del director financiero. Una sede, no las cuatro.
• Señal que se mira. La métrica de negocio, no la de la máquina. Logins por minuto, pedidos confirmados, correos entregados. El estudio de Berkeley ya lo decía: la prueba necesita semántica de aplicación. Que el nodo responda al ping no significa nada.
• Condición de parada. El número y el minuto exactos a partir de los cuales se aborta y se revierte. Escrito antes, cuando nadie tiene prisa. En caliente, siempre parece que aguanta un poco más.
• Quién puede decir basta. Un nombre, no un cargo. Y que esa persona esté en la sala, no localizable.
• Qué aprendimos. Dos líneas al terminar, incluso —sobre todo— si no pasó nada. Un experimento que confirma la hipótesis también es un resultado, y es el que convierte el simulacro en una serie en vez de en una anécdota.

Cuatro experimentos, de menos a más radio

Esto es lo que pondríamos sobre la mesa en un parque pequeño y corriente. El orden importa: cada uno asume que el anterior salió bien. No se empieza por el tercero porque suene más valiente.

Fíjate en que el primero no rompe nada. Es a propósito. Si el experimento número uno no se supera, los otros tres no se hacen: se arregla la documentación y se vuelve el mes que viene. Lo escribimos hace unas semanas con otras palabras en el plan de continuidad que nadie ha ensayado, y sigue siendo el patrón que más nos encontramos: el plan existe, está bien redactado y nadie lo ha leído con un reloj en la mano.

Por qué en horario de oficina y no a las tres de la mañana

La costumbre del sector es tocar de madrugada, y para un cambio planificado tiene todo el sentido: menos usuarios, menos coste si sale mal. Para un simulacro, no. Un simulacro se hace cuando está despierta la gente que sabe arreglarlo, que es exactamente el motivo por el que Netflix lo programa de nueve a tres. A las cuatro de la mañana no hay nadie mirando la métrica de negocio, nadie que note que el pedido no entra, y el hallazgo se pierde.

Y hay un corolario incómodo. Si la única respuesta posible a «¿podemos apagar un nodo el jueves a las once?» es «ni de broma», eso ya es el resultado del experimento. Acabas de descubrir, sin apagar nada, que tu sistema no tolera perder una pieza en horario laboral. Que es precisamente cuando las piezas se rompen.

Cuándo NO hacer nada de esto

Lo decimos porque es la parte que se calla en los artículos entusiastas, y porque nos hemos encontrado las cuatro situaciones. Si falta alguna de estas piezas, un «día del caos» no es ingeniería: es una caída que has programado tú y encima has pagado.

• No tienes una copia que hayas restaurado alguna vez. Entonces el único experimento que te toca es el número uno de la tabla, y hasta que no se pase, los demás no existen. Una copia sin probar no es una copia: es un amuleto.
• No tienes forma de volver atrás en un paso. Si revertir implica una reinstalación, el radio de impacto no es el que escribiste: es todo.
• No tienes telemetría que te diga si estás bien. Sin la señal de negocio no puedes distinguir «aguantó» de «nadie lo estaba usando en ese momento». El experimento no da resultado: da sensación.
• No hay nadie con autoridad para parar. Si la decisión de abortar depende de convencer a alguien por teléfono, el experimento dura exactamente lo que tarde esa llamada, y esa llamada es siempre más larga que la condición de parada.

Lo que suele salir mal cuando sale mal

El fallo más frecuente en un simulacro no es que la pieza no se recupere. Es la segunda ola: todo lo que estaba conectado a la pieza empieza a reintentar a la vez, y la carga de los reintentos termina de tumbar lo que la caída original solo había rozado. Lo contamos entero en la tormenta de reintentos, donde la segunda caída la provocas tú, y es la razón por la que la condición de parada se escribe antes: en medio de una tormenta de reintentos, todo el mundo a la vez propone esperar un poco más a ver si remonta.

Lo que medimos nosotros, y lo que no prometemos

Nuestro último simulacro de recuperación completa cronometrado dio 14 minutos. Es un dato interno y lo acotamos con la misma claridad con la que lo decimos: es una prueba, no una promesa, y no es una garantía contractual de nada. Mide nuestro sistema, con nuestra documentación y nuestra gente, en una fecha concreta. Un cliente con otra arquitectura dará otro número, y el valor del ejercicio no es el número: es que exista y esté fechado.

Y conviene recordar contra qué se mide. Un 99 % de disponibilidad son 87,6 horas al año a oscuras: más de dos semanas laborables. Esa cifra aparece en los contratos como un adorno tranquilizador. Nadie la cumple ni la incumple por suerte, y desde luego nadie la comprueba el día que se firma. Lo único que distingue un número prometido de un número sabido es haberlo cronometrado alguna vez.

Lo que haríamos este trimestre

Primero, el experimento uno: que alguien que no montó el sistema restaure un fichero de la copia de anteayer con la documentación delante, cronómetro en mano, un martes a las once. Segundo, escribir la ficha de seis campos para el experimento dos antes de hacerlo —y dejarla archivada con fecha, aunque el resultado sea «no pasó nada»—. Tercero, meter el resultado en el orden del día de la reunión mensual, al lado del gasto, porque es ahí donde esto sobrevive o muere. Y cuarto, repetirlo. Un simulacro suelto es una anécdota; cuatro al año, fechados, son una serie que te dice si vas mejorando o empeorando.

Fuentes (consultadas el 16-10-2026): el recuento de técnicas sobre las 40 caídas de servicio del servicio Online («online testing would have helped the most, mitigating 26 service failures», «simply increasing redundancy would have mitigated 9 failures», el «more than 10 instances» de la monitorización y la frase sobre «online fault and load injection»), la definición de online testing, los 296 y 205 informes de fallo de componente, las 40, 56 y 21 caídas de servicio, la descripción de los tres servicios, la frase «operator error is the leading cause of service failure in two of the three services», el «more than 50% (and in one case nearly 100%)» de errores de configuración, el contexto de cambio (escalar o reemplazar hardware, desplegar o actualizar software) el mayor tiempo de reparación de los errores de operador, la frase «we observe that the techniques of adding additional redundancy and better exposing and monitoring for failures offer the most significant bang for the buck (...) while incurring relatively low cost» y la advertencia de que Online ya usaba algunas de esas técnicas, de modo que la tabla infraestima su efecto, salen de Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX USITS 2003. El horario de 9:00 a 15:00, la moneda ponderada, la distribución geométrica y el parámetro μ de días laborables, de la documentación de comportamiento de terminación de Chaos Monkey; los valores por defecto enabled = false, schedule_enabled = false, leashed = true y start_hour/end_hour, de su formato de fichero de configuración; el outage checker, de su documentación de complementos. La definición de la disciplina y la cita de la experimentación, de Basiri et al., «Chaos Engineering», IEEE Software 33(3), 2016; los cinco principios, de principlesofchaos.org. Los nueves (87,6 h, 8,76 h y 52,6 min al año) son aritmética. Lo nuestro, y lo acotamos: la lectura del 26 frente al 9 como asimetría comercial, la ficha de seis campos, la tabla de cuatro experimentos, las cuatro situaciones en las que NO hacerlo y los 14 minutos, que son un dato interno de una prueba fechada y no una garantía.