Resolución de problemas complejos de IT

La incidencia lleva abierta tres meses. Red dice que es la aplicación. Aplicación dice que es la red. El proveedor de VoIP dice que es Kubernetes. Y todos los lunes a primera hora, vuelve a fallar.

Si te suena esta película, estás en el territorio donde yo trabajo: problemas técnicos complejos que cruzan capas y que ningún equipo ve enteros.

El fallo que rebota entre equipos

Los problemas que me llegan tienen un patrón reconocible:

La incidencia rebota entre equipos o proveedores: cada uno mira su trozo, y su trozo funciona.
El bug solo pasa en producción. En staging, jamás.
El sistema lo montó alguien que ya no está y nadie lo entiende entero.
Lleva semanas abierto y ya se han probado tres parches que no parchean nada.

El denominador común es que el problema no vive una capa: vive entre capas. Entre el SIP y la red. Entre el móvil sin cobertura y la sincronización. Entre el modelo de IA, la cola y la base de datos. Por eso no lo ve quien solo mira una.

Cómo trabajo: método, no heroicidades

No creo en el gurú que mira los logs, frunce el ceño y siente dónde está el bug. Creo en un proceso aburrido que funciona:

Reproducir. Si el fallo se puede provocar a voluntad, ya está medio acotado. Si solo pasa en producción, se trabaja por observación: capturar cada vez que ocurre hasta tener el patrón.
Acotar capas. Se descarta con pruebas, no con opiniones. Cada capa que cae con una prueba delante es una reunión menos y un equipo que deja de perder tiempo.
Medir antes de tocar. Logs, métricas, trazas. Si no hay observabilidad, lo primero es ponerla: a veces el arreglo empieza por poder ver.
Hipótesis falsables. Cada hipótesis lleva su experimento y su criterio de descarte. Si no se puede falsear, no es una hipótesis, es una opinión. Y las opiniones no arreglan producción.

Y todo queda documentado: qué se probó, qué se descartó y por qué. Si el problema vuelve dentro de un año, el diagnóstico está escrito y no hay que empezar de cero.

Un ejemplo real: 1.000 errores al día con el mismo patrón

En mi propia plataforma, el listado del admin fallaba al filtrar por categoría. Sin pantallazos ni intuiciones: consulté los logs del entorno en Axiom y en 24 horas había unos 1.000 errores, casi todos idénticos —PostgreSQL rechazando un NaN donde esperaba un entero—. La traza señalaba el camino completo, del render del listado a la query que monta el ORM, y los parámetros contaban el resto: un null que se convertía en NaN al construir el filtro.

Eso es el método aplicado: medir, agrupar, leer la traza. El bug deja de ser un misterio y pasa a ser una línea concreta en un fichero concreto.

De dónde viene el criterio

Los problemas interesantes siempre cruzan fronteras. Tres sistemas que he construido y operado lo enseñan mejor que cualquier presentación:

Telefonía SIP a escala. CERNphone da servicio a más de 5.000 usuarios y unas 30.000 llamadas al día. Cuando una llamada no entra, el fallo puede estar en el protocolo, en la red, en el provisioning o en el cliente de escritorio. Y la telefonía no perdona: si una llamada no entra, se nota.
Una app offline-first. La Survey App de Naiz Fit guarda todo en el dispositivo y sincroniza cuando vuelve la red. Un bug de sincronización no se reproduce mirando el servidor: hay que reconstruir qué pasó en el móvil horas antes, sin cobertura y con la encuesta a medias.
Una plataforma de IA con colas. En Konect, un análisis atraviesa una cola de Redis Streams, un worker, un gateway de modelos y un proveedor de transcripción. Cuando un resultado no llega, hay que seguir el rastro por las cuatro piezas sin dar nada por supuesto.

No lo cuento para presumir de stack. Lo cuento porque haber operado sistemas raros de verdad —telefonía IP a escala, móviles sin conectividad, plataformas multi-tenant— es lo que me permite llegar a tu sistema y no asustarme.

Cuándo tiene sentido llamarme

Este servicio encaja cuando la incidencia lleva semanas abierta y ya ha pasado por varias manos; cuando el fallo solo aparece en producción y nadie sabe provocarlo; cuando el sistema es legacy y la documentación murió con el que lo montó. En una frase: cuando llevas meses con esto y el coste de seguir igual ya supera al de arreglarlo.

No encaja si el problema está acotado en un solo equipo y ese equipo tiene acceso, tiempo y observabilidad. En ese caso no me necesitas: necesitas dejarles trabajar.

Hablemos

Si tienes una incidencia que rebota entre equipos, cuéntamela por el síntoma, no por la solución que te han vendido hasta ahora: qué falla, desde cuándo y qué habéis probado ya. Con eso te digo en una primera conversación si puedo ayudarte y cómo lo atacaría.

Puedes reservar una toma de contacto. El peor caso es que salgas de la llamada con el problema mejor acotado de lo que estaba.