El panel está verde. El sistema responde. Los usuarios entran, las pantallas abren, el tiempo de respuesta está dentro de lo acordado. Y la operación está detenida desde hace semanas.

No es una contradicción — es la diferencia entre dos preguntas que casi todo el mundo trata como una sola. La disponibilidad mide si el sistema responde. La resiliencia operacional mide si el trabajo ocurre. Son cosas distintas, y solo la primera suele tener alarma.

Por qué el monitor no lo ve

Todo monitoreo está construido sobre eventos. Algo ocurre, algo se registra, una regla evalúa el registro y decide si avisa. El modelo funciona bien para lo que se rompe.

Es ciego a lo que simplemente no ocurre. Un proceso que debería haber corrido y no corrió no genera evento alguno. No hay línea en el log, no hay código de retorno, no hay nada que una regla pueda evaluar. El silencio es indistinguible de un día tranquilo.

Y el silencio tiene tres formas, que conviene separar porque se investigan de maneras distintas:

Lo que debería haber empezado y no empezó. La cola existe, los mensajes entran, y no hay nadie consumiendo del otro lado. Todo se acumula, ordenadamente, sin error.

Lo que empezó y no terminó. El documento queda en un estado intermedio — preparado, liberado, esperando — y nunca avanza. Cada registro por separado parece normal; el problema solo aparece en el total.

Lo que terminó mal y nadie comparó. El resultado salió, es plausible, y es incorrecto. Ese es el más difícil, porque exige una expectativa contra la cual comparar.

El número que lo delata: cero en error

En un ambiente que atendemos, las facturas dejaron de salir. Ningún error en pantalla, ningún registro, ninguna alerta.

La investigación giró cuando alguien contó los documentos por estado, en lugar de buscar el fallo:

• 250 documentos detenidos en preparación
• 7 liberados
• cero concluidos
• cero en error

Ese último número es el hallazgo. Nada había fallado. Nada lo había siquiera intentado. La pieza que reparte el trabajo apuntaba a una dirección inexistente, y había más de cien mil unidades represadas — parte de ellas desde hacía más de un mes. El sistema pasaba cualquier verificación de disponibilidad.

El caso completo, con la hipótesis equivocada que costó dos días, está en salida que no imprime: ningún spool, ningún error, ningún log.

La medición que falta: contar lo esperado

La corrección no es más monitoreo. Es otro tipo de monitoreo, que nadie instala por defecto porque exige algo que la herramienta no tiene: qué debería ocurrir.

La pregunta cambia de «¿qué falló?» a «¿qué debería haber ocurrido y no ocurrió?«. Y se responde con conteo simple, por ventana de tiempo:

• documentos por estado — cuántos entraron, cuántos concluyeron, cuántos quedaron en el medio;
• cola por consumidor — cuántas unidades esperando, y qué antigüedad tiene la más vieja;
• interfaz por período — cuántos mensajes en la misma ventana de ayer, de la semana pasada, del mismo día del mes anterior;
• rutina por calendario — lo que corre todos los lunes, ¿corrió este lunes?

Ninguno de esos conteos es sofisticado. Lo que exigen es la parte que suele faltar: alguien tiene que haber escrito qué se espera. Sin expectativa declarada no hay ausencia detectable — hay solo un número sin referencia.

Cómo montarlo sobre lo que ya existe

1. Liste los procesos que producen un resultado contable. Emisión, integración, cierre, carga, expedición. Si el resultado no se puede contar, su ausencia no se puede detectar.

2. Escriba lo esperado por ventana. No hace falta que sea preciso. «Entre 200 y 400 por día hábil» ya es infinitamente mejor que nada, porque el cero se vuelve visible al instante.

3. Alarma por ausencia, no por error. La regla que importa es «se esperaban N y llegaron 0» — y es distinta de todas las reglas que usted ya tiene.

4. Un dueño por proceso. Una alarma sin destinatario se vuelve ruido en dos semanas, y el ruido apagado es peor que ninguna alarma, porque da sensación de cobertura.

Lo que sale mal, con nombre

Usar la disponibilidad como indicador de operación. Un sistema puede pasar meses con 99,9% de disponibilidad sin procesar parte del trabajo. Los dos números son verdaderos al mismo tiempo, y solo uno llega al negocio.

Monitorear el componente, no el resultado. Servicio arriba, proceso detenido. Vigilar la pieza es necesario y no es suficiente — lo que importa es el documento que sale del otro lado.

Tratar «nadie reclamó» como evidencia. En el caso de arriba, el documento que generó el ticket era menos del 0,1% de lo represado. Nadie había abierto ticket sobre el resto — y el resto era casi todo.

Medir promedios en lugar de conteos. El tiempo medio de procesamiento sigue siendo excelente cuando no se está procesando nada. El promedio esconde la ausencia; el conteo no.

Confiar en la alarma que nunca sonó. Una alarma que nunca disparó tiene dos explicaciones posibles, y la mayoría de las operaciones solo considera una.

En ambiente regulado esto dejó de ser opcional

La resiliencia operacional entró en el vocabulario de las normas del sector financiero, y el texto pide más que política escrita: pide demostración. Declarar que existe un control y demostrar que el control funciona son ejercicios distintos — el segundo exige justamente la evidencia de que el trabajo ocurrió.

Es la misma lógica de una auditoría en cualquier sector regulado: no basta afirmar que el proceso corre; hay que poder mostrar cuántas veces corrió, cuándo, y qué salió. Lo tratamos en TI para instituciones financieras.

El límite honesto

Contar lo esperado exige saber qué se espera — y buena parte de las operaciones no lo sabe. Descubrirlo es trabajo de negocio, no de infraestructura, y es la parte que suele trabarse. Cuando nadie logra decir cuántos documentos produce un día normal, el problema es anterior al monitoreo.

Esto tampoco reemplaza lo que ya existe. El monitoreo de fallos sigue siendo necesario — lo que se propone aquí es una capa que nadie instaló, no el cambio de una por otra.

Y hay un límite de alcance: detectar la ausencia acorta el tiempo hasta descubrir, no el tiempo hasta corregir. En el caso citado, la detección habría ahorrado la mayor parte de once días. La corrección en sí seguiría exigiendo investigación — y coordinación, porque volver a encender un repartidor de trabajo con cien mil unidades represadas es un evento en sí mismo.

Si el punto de partida es descubrir qué está ya detenido sin que nadie lo sepa, es exactamente lo que busca el diagnóstico de TI. Para sostenerlo en el día a día, el camino es observabilidad. Y si la discusión es poner procesos automáticos en ese ambiente, conviene antes entender qué hereda la autonomía.

Preguntas frecuentes