Por qué los trenes de Japón son tan confiables (y qué tiene que ver con tu infra de software)

Estaba revisando logs de producción a las 11pm cuando me llegó una notificación de Railway — mi proveedor de infra, no el modo de transporte — avisando que un servicio había caído por tercera vez en la semana. Reinicié el container, anoté mentalmente "ver esto mañana", y seguí. Dos días después leí que el Shinkansen había tenido un delay de 49 segundos y la compañía emitió una disculpa pública formal. Cuarenta y nueve segundos. Me quedé mirando la pantalla un rato largo.

No es que me sorprendió el dato. Ya lo había escuchado. Lo que me sorprendió fue el contraste con mi propia normalización: yo había reiniciado ese servicio tres veces en una semana y lo registré mentalmente como "cosas que pasan". Ellos tuvieron 49 segundos de delay y lo trataron como un evento que requiere análisis formal y disculpa pública. Ahí empecé a entender que el problema no era técnico.

Sistemas confiables, diseño institucional e infraestructura: la trampa de buscar mejores herramientas

La explicación fácil del tren japonés es tecnológica: maglev, ingeniería de precisión, presupuesto enorme. Es una explicación cómoda porque si el problema es tecnológico, la solución es comprar mejor tecnología. Pero no cierra.

Suiza también tiene trenes extraordinariamente puntuales. Con tecnología bastante más modesta. Alemania tiene ICE, alta tecnología, presupuesto federal, y tiene delays crónicos que son motivo de chiste nacional. India está construyendo metros de alta tecnología en ciudades donde la señalización falla todos los días. La tecnología no explica la varianza.

Lo que explica la varianza es más incómodo: la estructura de consecuencias.

En JR (Japan Railways), el costo institucional de un fallo es brutalmente alto. No hablo solo de multas o métricas. Hablo de algo más profundo: la identidad organizacional está construida alrededor de la confiabilidad. Un operador que reporta un problema a tiempo es tratado como parte del sistema de seguridad. Un operador que oculta un problema para no generar fricción está traicionando la institución. Esa inversión de incentivos no es cultural en el sentido vago — es diseñada, reforzada y mantenida activamente.

El resultado práctico: el mantenimiento preventivo no es un costo. Es la única forma racional de operar. Porque el costo de fallar — en reputación, en consecuencias internas, en el análisis postmortem que viene después — es sistemáticamente más alto que el costo de mantener.

Compará eso con la mayoría de los sistemas de software que conozco, incluyendo los míos.

Qué significa esto para arquitectura de software

Cuando cursaba Ciencias de la Computación en la UBA mientras laburaba full time, llegaba a veces directo del trabajo con el traje puesto. Había una presión constante de hacer las cosas funcionar ahora, no de hacerlas funcionar bien y para siempre. Aprobé Análisis II en el cuarto intento. Aprendí a sobrevivir en entornos donde el costo de no entregar hoy era más visible que el costo de entregar mal.

Eso moldea cómo pensás sistemas. Y es exactamente el problema institucional que el tren japonés resolvió y nosotros no.

En la mayoría de los equipos de software, la estructura de consecuencias favorece fallar silenciosamente:

• Un servicio que cae y se recupera solo no genera conversación
• Un servicio que nunca cae pero requirió 3 horas de trabajo preventivo tampoco genera conversación visible
• Un servicio que se cae espectacularmente a las 3pm en producción genera una reunión, un postmortem y a veces una RCA

La consecuencia visible está en el fallo grande, no en la degradación silenciosa. Eso hace que reiniciar tres veces en una semana sea "cosas que pasan" y no una señal de alerta institucional.

// Lo que hacemos habitualmente:
const manejarError = async (error: Error) => {
  // Reiniciar y seguir — el uptime se recupera solo
  logger.error('Service crashed', { error: error.message });
  await reiniciarServicio();
  // ✗ Sin análisis de causa raíz
  // ✗ Sin registro de frecuencia
  // ✗ Sin costo visible para el equipo
};

// Lo que haría una institución con estructura de consecuencias real:
const manejarErrorConCosto = async (error: Error, contexto: ContextoOperacion) => {
  // 1. Registrar con suficiente detalle para análisis posterior
  await registrarIncidente({
    timestamp: new Date(),
    error: error.message,
    stack: error.stack,
    contexto,
    // Frecuencia en las últimas 24h — esto es lo que importa
    frecuenciaReciente: await contarIncidentesSimilares('24h'),
  });

  // 2. Si es el tercer incidente similar en una semana:
  // NO reiniciar silenciosamente — escalar con contexto
  const historial = await obtenerHistorialIncidentes(7);
  if (historial.similares >= 3) {
    await escalarConContexto({
      mensaje: 'Tercer incidente similar esta semana — esto no es ruido',
      historial,
      costoEstimadoDeIgnorar: calcularCostoDeDegradacionContinua(historial),
    });
  }

  // 3. Recuperar, pero dejar huella visible
  await reiniciarServicio();
  await actualizarDashboardConfiabilidad(contexto.servicio);
};

La diferencia no es técnica. Es qué hace visible el sistema, y a quién le importa.

Cuando diseñé la arquitectura de mi agente IA y medí los costos reales, el problema no era la tecnología. Era que yo no tenía estructura para hacer visible el costo de las decisiones malas. Los fallos se absorbían silenciosamente y yo seguía pensando que el sistema andaba "más o menos bien".

Los agentes IA van exactamente en la dirección contraria

Acá es donde me pongo más incómodo, porque es el territorio donde estoy trabajando activamente.

El ecosistema de agentes IA en 2025 está construyendo, de manera bastante sistemática, sistemas donde el costo de fallar es artificialmente bajo. Y lo presenta como una virtud.

"El agente reintenta solo." "Si hay un error, el LLM lo detecta y corrige." "La resiliencia está integrada." Todo eso suena bien. Y en ciertos contextos lo es. Pero en términos institucionales, estás construyendo un sistema que hace que los fallos sean invisibles. El agente falla, reintenta, eventualmente llega a algún resultado, y vos nunca sabés que el camino fue tortuoso.

Yo lo medí en tokens y la incomodidad fue concreta: hay decisiones de diseño que cuestan 3x más tokens sin que nadie lo sepa, porque el resultado final llega igual. El costo se absorbe silenciosamente. El sistema "funciona".

Es el equivalente al tren que llega 49 segundos tarde pero nadie lo registra porque igual llegó.

La diferencia con JR es que JR construyó la capacidad institucional para que esos 49 segundos sean visibles, analizados y cuesten algo. Nosotros estamos construyendo agentes que optimizan para que los 49 segundos nunca sean visibles.

Cuando analicé los costos reales de las decisiones de diseño de mi agente, encontré exactamente eso: la arquitectura de reintentos automáticos era, en términos de visibilidad institucional, un sistema para ocultar fallos. Funcionaba. Pero estaba construyendo deuda de comprensión.

Los errores que cometí (y que probablemente estés cometiendo)

Error 1: Confundir disponibilidad con confiabilidad. Mi servicio tenía 99.2% de uptime el mes pasado. También tuvo 47 reinicios automáticos. Esos números no se contradicen, y eso es el problema. JR no mide "el tren llegó" — mide cuánto tardó, por qué, y qué condiciones lo permitieron. Yo medía solo si llegó.

Error 2: Tratá los reintentos como solución, no como señal. Un retry exitoso no es un éxito. Es un fallo que se resolvió. La diferencia importa porque si no la registrás como fallo, no tenés datos para prevenir el próximo.

Error 3: Construir observabilidad sin consecuencias. Tenía dashboards. Tenía logs. Tenía alertas. Pero no tenía una estructura donde esos datos costaran algo si mostraban deterioro. Información sin consecuencias es decoración.

Error 4: Asumir que "funciona" es el objetivo. Esta es la más profunda. El sistema japonés no optimiza para que el tren llegue. Optimiza para que el proceso que hace llegar el tren sea sosteniblemente confiable. Son objetivos distintos con arquitecturas institucionales distintas.

Cuando escribí un intérprete de Python en Python para entender compiladores, la lección más grande no fue técnica — fue que los lenguajes formales fuerzan explicitación. No podés tener comportamiento vago. O la gramática lo permite o no lo permite. Los sistemas de confiabilidad real funcionan igual: necesitás hacer explícito lo que cuenta como fallo.

FAQ: Sistemas confiables, diseño institucional e infraestructura

¿El modelo japonés es replicable en software sin un presupuesto enorme? Sí, porque el componente más importante no es económico. Es estructural. Lo que JR hace que cuesta poco pero cambia todo: registrar los reintentos como incidentes, no como ruido. Eso no requiere presupuesto. Requiere cambiar qué hace visible tu sistema y acordar que eso importa.

¿No es esto lo que ya hacen los SLOs y SLAs? Parcialmente. Los SLOs son un buen primer paso porque hacen visible el objetivo. Pero el problema institucional es qué pasa cuando no se cumplen. Si el costo de no cumplir un SLO es una reunión y un "hay que mejorar", no cambiaste la estructura de consecuencias. La pregunta relevante es: ¿qué le cuesta a alguien concreto que el SLO falle repetidamente?

¿Cómo aplicarías esto a un sistema de agentes IA? Empezaría por hacer visibles los reintentos. No como métrica de éxito ("el agente completó la tarea") sino como métrica de calidad del camino ("el agente necesitó X reintentos, costó Y tokens, tomó Z segundos más de lo esperado"). Después construiría un umbral donde ese número activa algo: no necesariamente una alarma, pero sí una revisión. El sistema tiene que saber que fallar silenciosamente tiene costo.

¿Por qué la cultura de "move fast and break things" es el opuesto exacto de esto? Porque optimiza para velocidad de iteración sobre cualquier otra cosa. No es malo en contextos donde el costo del fallo es bajo y la velocidad de aprendizaje es lo más valioso — como un experimento, o un MVP. El problema es cuando esa cultura persiste después de que el sistema tiene usuarios reales, datos reales y consecuencias reales. En ese punto, la velocidad de iteración sin estructura de consecuencias es deuda institucional.

¿No hay un trade-off real entre confiabilidad y velocidad de desarrollo? Sí, y no voy a fingir que no. Pero el trade-off habitualmente se presenta mal. No es "velocidad vs confiabilidad". Es "costo visible hoy vs costo invisible que se acumula". El mantenimiento preventivo de JR es más caro por tren-kilómetro que el mantenimiento reactivo. Pero el costo total del sistema — incluyendo fallos, disrupciones, reparaciones de emergencia y daño reputacional — es mucho más bajo. El problema es que el costo de hoy es visible y el costo futuro no.

¿Qué herramienta concreta recomendarías para empezar? Ninguna herramienta. Eso es exactamente el punto. Antes de elegir herramientas, necesitás acordar qué cuenta como fallo en tu sistema. Escribilo. Literalmente en un documento: "Un fallo es X. Un retry es un fallo. Tres fallos similares en siete días activan Y." Cuando tengas eso claro, cualquier stack de observabilidad funciona. Sin eso, tenés dashboards bonitos y ningún cambio institucional.

Confiabilidad real no es un problema técnico

Llevo semanas con este tema dando vueltas. Empezó con ese dato de los 49 segundos y terminó haciéndome replantear cómo diseño sistemas.

La conclusión más incómoda es esta: en el ecosistema de software actual — y especialmente en el ecosistema de agentes IA — estamos construyendo activamente sistemas que hacen que los fallos sean invisibles. Y los presentamos como resilientes. La resiliencia real es cuando el sistema quiere que los fallos sean visibles, porque la institución construyó las consecuencias correctas.

Cuando Anthropic diseña la experiencia de developer para Claude, hay una tensión exactamente acá: la API hace que los reintentos sean fáciles, que los errores sean manejables, que todo fluya. Eso baja la fricción de desarrollo. También baja la visibilidad de los fallos. No sé si está bien o mal — probablemente depende del contexto. Pero sé que es una decisión institucional con consecuencias, y que habría que hacerla consciente.

Incluso cuando pensé en Brunost, el lenguaje de programación en Nynorsk, había algo de esto: quién decide qué es legible, qué cuenta como correcto, qué estructura hace visible o invisible el error. El diseño institucional está en todos lados, incluso en los lenguajes.

No tengo una solución empaquetada. Tengo una práctica que empecé hace dos meses: cada vez que hago restart a un servicio, lo registro como incidente con timestamp, contexto y frecuencia acumulada. No hago nada con eso todavía. Pero cuando llegué a 47 reinicios en un mes, el número fue suficientemente incómodo como para que no pudiera seguir llamándolo "cosas que pasan".

Ahí empieza el cambio institucional. En hacer visible lo que antes absorbías silenciosamente.

Si te quedó algo de esto, contame en los comentarios cómo medís los fallos silenciosos en tu sistema. O si tenés la estructura de consecuencias resuelta de una manera que funcione — quiero aprender de eso.