Los sistemas no fallan de repente

Los sistemas no fallan de repente.

La alerta de las 3 de la mañana, el error en cascada, el incidente que deja un producto fuera de servicio durante cuatro horas — todo esto parece súbito. No lo es. Es la superficie visible de algo que ya era verdad, revelado por el conjunto particular de condiciones que lo hicieron inevitable.

Entender esto cambia cómo construyes, cómo operas y qué haces después de que algo se rompe.

La acumulación lenta

La mayoría de los fallos tienen una larga prehistoria.

Un índice de base de datos que nunca se creó porque la consulta era suficientemente rápida en desarrollo. Un valor de timeout configurado “temporalmente” que nunca se revisó. Un proceso de despliegue manual que funcionó bien hasta que no lo hizo. Un runbook que era preciso en 2022 y lleva equivocado desde entonces.

Nada de esto es dramático. Nada de esto parece riesgo en el momento en que se introduce. Parece trabajo normal bajo restricciones normales — un atajo tomado porque el plazo era real, una decisión aplazada porque el sistema funcionaba, un documento no actualizado porque actualizarlo parecía menos urgente que todo lo demás.

Los fallos son el interés compuesto de decisiones ordinarias tomadas en tiempos ordinarios.

El desencadenante no es la causa

Lo que desencadena un fallo raramente es su causa.

Un pico de tráfico. Un cambio de configuración. Una actualización de dependencia. Un fin de semana festivo con guardia reducida. Estos son desencadenantes. La causa ya estaba presente. El desencadenante es la condición que hizo visible la debilidad existente.

Esto importa porque los post-mortems a menudo se centran en el desencadenante. “Desplegamos un viernes.” “El tráfico era inusualmente alto.” “El disco estaba lleno.” Esto es verdad, pero no es donde está el aprendizaje.

El aprendizaje está en qué hizo al sistema susceptible a ese desencadenante en primer lugar. ¿Por qué el volumen de tráfico reveló ese bug? ¿Por qué un cambio de configuración expuso esa asunción? ¿Por qué la guardia reducida significó que nadie lo notó hasta que el daño estaba hecho?

El desencadenante explica cuándo. La prehistoria explica por qué.

El mantenimiento como práctica

La forma de evitar fallos no es responder mejor a ellos. Es reducir continuamente la superficie de riesgo acumulado.

Esto es el mantenimiento — no en el sentido estricto de mantener los servidores funcionando, sino como una disciplina de observación y reducción. Identificar los índices que no existen. Revisar los timeouts que se configuraron temporalmente. Revisar los runbooks después de que las condiciones que describen hayan cambiado.

El mantenimiento no es un trabajo glamuroso. Raramente produce un ticket que alguien esté emocionado de escribir. El beneficio es negativo: el número de incidentes que no ocurren, los fallos detectados antes de que se propaguen, el ingeniero que no pasa su sábado deshaciendo seis meses de fragilidad acumulada.

Los mejores equipos operacionales tratan el mantenimiento como una práctica de primer nivel, no como lo que haces cuando no hay nada más programado.

Lo que realmente hace un buen post-mortem

Un post-mortem que termina en el desencadenante no ha hecho su trabajo.

Un post-mortem útil pregunta: ¿dónde más en el sistema existe este tipo de asunción? ¿Qué hizo que este modo de fallo fuera invisible hasta ahora? ¿Qué en nuestros procesos normalizó aplazar la corrección?

El objetivo no es documentar el incidente específico. El objetivo es entender las condiciones que permitieron que el fallo se acumulara, porque esas condiciones probablemente están generando otros fallos que aún no han emergido.

El output más valioso de un post-mortem no son los puntos de acción. Es el modelo mental actualizado de dónde el sistema es frágil.

Operar con honestidad

Los equipos que operan bien no asumen fiabilidad — la miden.

Saben qué partes del sistema son frágiles, no porque lo hayan diseñado así, sino porque han sido honestos sobre dónde vive el riesgo. Han ejecutado simulaciones de fallo antes de que producción las ejecutara. Han leído el código que nadie entiende. Han preguntado qué pasa cuando este servicio particular es lento, no solo cuando está caído.

Esto no es pesimismo. Es honestidad operacional. El riesgo existe tanto si alguien lo ha mirado como si no. Mirarlo no crea el problema; lo revela en un momento en que aún se puede hacer algo.

Sobre el tiempo

El tiempo es la única variable de la que ningún sistema escapa.

Cada decisión tiene una fecha. El esquema elegido en el año uno sigue ahí en el año cinco. El servicio que era “temporal” es crítico para producción en el año tres. La abstracción que tenía sentido con cien mil usuarios no tiene sentido con diez millones.

Los sistemas envejecen. No con elegancia, a menos que alguien trabaje continuamente contra la entropía. Los equipos que construyen sistemas duraderos no son los que tomaron mejores decisiones iniciales — son los que revisan las decisiones a medida que el contexto a su alrededor cambia.

El fallo a menudo es solo el tiempo haciendo visible una decisión que debería haberse revisado antes.

La pregunta que vale la pena hacerse no es “¿por qué se rompió esto?” Es “¿qué más llevamos demasiado ocupados como para mirar?”