Cuando arreglar una parte rompe las demás

Cuando algo falla en un sistema, la reacción más común es ajustar la parte que falló. Es razonable, y casi siempre funciona a corto plazo. El problema aparece después, cuando ese ajuste mueve otras variables que nadie estaba observando.

Un equipo nota que un reporte interno tarda cada vez más en generarse. La solución más directa es agregar más capacidad de cómputo al servidor que lo procesa. Se aplica el cambio, el reporte vuelve a generarse rápido, y el ticket se cierra como resuelto.

Un ajuste que funciona no siempre significa que el problema se resolvió

En un sistema con varias partes conectadas entre sí, resolver un síntoma no siempre resuelve el problema de fondo. A veces solo lo mueve a otra parte donde todavía no se ve. Eso es justo lo que pasa después de agregar esa capacidad: el reporte deja de ser un problema, y por tres semanas nadie vuelve a pensar en el servidor.

Tres semanas después, otro proceso que corría en ese mismo servidor (uno que nadie mencionó cuando se hizo el ajuste, porque no tenía relación aparente con el reporte lento) empieza a fallar de forma intermitente. Nadie conecta los dos eventos porque pasaron semanas entre uno y otro. Pero el segundo problema es consecuencia directa de haber resuelto el primero sin preguntar qué más dependía de esos mismos recursos.

La pregunta que casi nadie hace antes de ajustar

Pensar en sistema, no en síntoma, significa hacer una pregunta distinta antes de tocar nada: si cambio esto, ¿qué más depende de ello, directa o indirectamente? Es una pregunta incómoda porque no tiene una respuesta rápida, y bajo presión lo rápido casi siempre gana.

Quien atendió el reporte lento sabía operar el servidor: sabía cómo agregar capacidad, cómo confirmar que el cambio funcionara. Lo que no sabía, porque nadie lo había documentado, era qué otros tres procesos dependían de ese mismo servidor y cómo les iba a afectar el cambio más adelante.

Lo que cambia cuando el equipo se detiene a mapear

Cuando aparece la segunda falla, el equipo esta vez sí se detiene antes de ajustar de nuevo. En vez de tratarla como un problema aislado, revisan qué otros procesos comparten el mismo servidor que se modificó tres semanas antes. En diez minutos encuentran la lista completa: tres procesos, uno de ellos el que ahora falla de forma intermitente, todos compitiendo por los mismos recursos que el ajuste anterior redistribuyó sin que nadie lo documentara.

El principio que se puede llevar a cualquier sistema

Con esa lista en mano, la solución cambia de naturaleza. En vez de agregar más capacidad otra vez, algo que solo movería el problema una vez más, separan los procesos que compiten por el mismo recurso y le asignan a cada uno lo que necesita. La falla intermitente desaparece, y esta vez queda documentado qué depende de qué, para que el próximo ajuste en ese servidor se haga sabiendo de antemano qué más se va a mover.

Esto cambia el orden del trabajo. En vez de resolver lo primero que se ve, conviene invertir un poco de tiempo en entender qué más está conectado, y desde ahí decidir qué ajustar y en qué orden.

La próxima vez que un ajuste puntual "funcione" pero algo distinto empiece a fallar poco después, vale la pena preguntarse si el ajuste resolvió la causa o solo movió el síntoma a un lugar donde todavía no era visible.

¿Tu equipo revisa el mapa de dependencias antes de ajustar algo, o resuelve el síntoma que tiene enfrente y espera que no reaparezca en otra parte?