La llamada entró un jueves. Las facturas no estaban saliendo.

No es un problema técnico cualquiera — una factura que no imprime es mercadería que no sale. El camión queda en el patio, el pedido no se factura, y cada hora cuesta más. Es el tipo de ticket que pasa al frente de todo lo demás.

Lo que nadie imaginaba es que tomaría once días encontrar la causa. Y que estaría a tres pantallas de todo lo que se investigó.

Día 1: el problema no se comporta como problema

Lo primero que se hace es reproducir. Clic en imprimir, y ahí viene el detalle que marcaría toda la investigación: no pasa nada. Ningún mensaje de error. Ninguna advertencia. La pantalla no reclama nada.

Había un segundo sistema — el de homologación — con la misma versión, el mismo código, la misma configuración. Allí la factura imprimía todos los días, sin fallar. Dos ambientes gemelos, uno funcionando y otro no.

Eso es, al mismo tiempo, la mejor y la peor noticia posible. La mejor porque da un punto de comparación. La peor porque significa que la diferencia está escondida en algún lugar que nadie pensó en mirar.

La semana de las hipótesis razonables

Se empezó por lo obvio, como siempre se empieza.

La impresora. Había realmente una diferencia de configuración entre los dos ambientes. Se corrigió con alguna esperanza. No resolvió.

El sistema de impresión. ¿Tal vez estaba trabado? No: más de diecisiete mil documentos se habían impreso esa semana, en el mismo sistema. Sano.

El formulario y el generador de PDF. Probados en los dos ambientes, respuesta idéntica.

La versión del software. Componente por componente, misma actualización en los dos.

La autorización del usuario. Autorizado en los dos.

Una semana después, la lista de causas descartadas era larga y la de sospechosos estaba vacía. Y cada verificación que daba «igual en los dos» volvía el problema más extraño, no más claro.

El silencio que nadie había extrañado

El giro de perspectiva vino de un conteo simple. Cada documento a imprimir se vuelve un registro con un estado: en preparación, liberado, en proceso, concluido, o error.

En el ambiente con problema:

• 250 documentos parados en «en preparación»
• 7 en «liberado»
• cero concluidos
• cero en error

Ese último número es el hallazgo. Nada había fallado. Nada lo había siquiera intentado.

Por eso ningún monitor sonó, ningún log registró nada, ninguna alerta se disparó. Las herramientas de monitoreo encuentran fallas. Ahí no había falla — había ausencia. Y una ausencia no dispara nada.

El descubrimiento que atrasó todo

Al octavo día llegó lo que parecía ser la respuesta. Saltando el camino normal y pidiendo al sistema emitir la factura directamente, imprimió. Cuatro segundos, documento en la cola, concluido.

La lectura fue inmediata y natural: si funciona cuando lo llamo directo, el problema está en quien lo llama. La investigación giró hacia el programa que dispara la impresión, y llegó a aislar la línea exacta donde parecía fallar. Todo encajaba.

Y estaba equivocado.

La llamada directa funcionaba justamente porque saltaba la pieza rota, en vez de atravesarla. La prueba que parecía confirmar la hipótesis era, en realidad, la prueba de que la hipótesis miraba al lugar equivocado — solo que leída al revés.

Fueron dos días más en esa dirección. Así es como una investigación larga sale cara: no por el error grosero, sino por la teoría coherente que explica todo lo que uno ve — y nada de lo que no miró.

La pregunta que faltaba

Al undécimo día alguien hizo una pregunta que no era sobre impresión: ¿cuántos trabajos hay en cola esperando ejecutarse?

En el ambiente de homologación, donde todo funcionaba: cero. Ejecutaba al instante.

En el ambiente con problema: 109.678.

Ciento nueve mil unidades de trabajo ahí paradas, esperando. Cincuenta y seis de ellas eran las facturas. Las otras ciento nueve mil seiscientas eran todo lo demás que ese sistema debía estar procesando en segundo plano — incluyendo una cola trabada desde hacía más de un mes sin que nadie lo notara.

Una dirección que no existía

El componente que reparte ese trabajo necesita un supervisor para funcionar. Ese supervisor tiene una dirección de conexión configurada — y en aquel sistema la dirección apuntaba a un ambiente que no existía ahí.

Era un número de mandante válido en otro sistema del paisaje, probablemente copiado en alguna configuración antigua. En el ambiente de homologación ese mandante sí existe — y por eso allá todo siempre funcionó.

Sin supervisor válido, el repartidor de trabajo no reparte nada. Los documentos se preparaban, se liberaban, y quedaban esperando a alguien que nunca vendría. Sin error, porque no hubo falla.

Once días de investigación por un campo con el número equivocado.

Lo que este caso enseña

Un sistema «arriba» no es un sistema trabajando. Aquel ambiente pasaba cualquier verificación de disponibilidad. Estaba encendido, respondía, tenía usuarios conectados. Y hacía semanas que no ejecutaba parte del trabajo.

Cero errores no es buena noticia — es una pregunta. Cuando un proceso debería producir resultado y no produce ni éxito ni falla, el defecto rara vez está en el proceso. Está en quien debería tomarlo y no lo tomó.

«Funciona cuando lo hago manualmente» es pista de que el problema está en la automatización, no en la tarea. Aquí se leyó al revés, y costó días.

Comparar dos ambientes es la herramienta más fuerte que existe — siempre que se compare lo correcto. Comparar configuración funcionó. Comparar tamaño de programa no, porque el número que parece el tamaño del código es en realidad su tamaño comprimido.

El límite honesto

Once días es mucho, y la mayor parte se gastó en hipótesis razonables y equivocadas. No se puede prometer que la próxima investigación será corta — un síntoma silencioso es caro por naturaleza, porque no deja rastro.

Lo que sí se puede cambiar es el orden de las preguntas. Antes de investigar el proceso, confirme que la infraestructura que lo ejecuta está viva — la cola, quién la reparte, adónde apunta. Cuatro verificaciones de diez minutos que aquí habrían ahorrado diez días.

Por qué este es un caso de diagnóstico y no de soporte

Note lo que estaba pasando al lado del problema que abrió el ticket. La factura era 56 de 109.678 unidades detenidas — menos del 0,1%. Todo lo demás tampoco se procesaba, y nadie había abierto ticket sobre nada de eso.

Esa es la diferencia entre soporte y diagnóstico. El soporte responde a lo que duele. El diagnóstico mira el ambiente entero y encuentra lo que está roto antes de doler — la cola que se acumula, el proceso que no corre, la configuración que apunta a ninguna parte. Nada de eso genera alarma, porque nada de eso es un error.

El síntoma que generó la llamada fue el único que alguien notó. No fue el único que había.

Si sospecha que hay cosas detenidas en su ambiente que nadie notó, es exactamente lo que busca el diagnóstico de TI. Y si el patrón de «cada día falla de una forma nueva» suena familiar, el camino es la investigación dirigida, no la adivinanza.