Gestión de problemas: la práctica que reduce incidentes de verdad

Muchas operaciones de TI son muy buenas apagando fuegos. Restauran rápido, coordinan bien los incidentes mayores y tienen guardias comprometidas. Y aun así, mes tras mes, el volumen de incidentes no baja. La razón casi siempre es la misma: la gestión de incidentes funciona, pero la gestión de problemas no existe o existe solo en el papel.

Incidente y problema no son lo mismo

La distinción es simple de enunciar y difícil de sostener en la práctica. Un incidente es una interrupción o degradación del servicio; el objetivo es devolver el servicio a la normalidad cuanto antes, aunque sea con un parche. Un problema es la causa, real o potencial, de uno o más incidentes; el objetivo es entenderla y eliminarla, o al menos reducir su impacto.

Las dos prácticas tienen ritmos distintos. Incidentes trabaja en minutos y horas, bajo presión. Problemas trabaja en días o semanas, con calma y con datos. Cuando se mezclan, pierden ambas: el incidente queda abierto "hasta saber qué pasó" y las métricas de restauración se inflan, o el problema se da por resuelto en cuanto el servicio vuelve y nadie investiga.

ITIL 4 organiza la práctica en tres fases que conviene tener presentes: identificar problemas, controlarlos (analizarlos y documentar soluciones temporales y errores conocidos) y controlar los errores (gestionar los errores conocidos hasta su corrección definitiva o su aceptación formal).

Reactiva y proactiva: dos puertas de entrada

La gestión reactiva nace de incidentes que ya ocurrieron. Los disparadores típicos son un incidente mayor, un incidente que se repite o un grupo de incidentes con síntomas parecidos. Es por donde casi todas las organizaciones empiezan, y está bien que así sea: el dolor está a la vista y el valor es fácil de explicar.

La gestión proactiva busca problemas antes de que produzcan incidentes visibles para el usuario. Sus fuentes son el análisis de tendencias en el historial de incidentes, las alertas que se disparan y se resuelven solas, las advertencias de capacidad, las vulnerabilidades publicadas por los proveedores y los errores conocidos que informan los fabricantes de software.

Un criterio práctico para empezar: dedicar la mayor parte de la capacidad a lo reactivo durante los primeros meses, hasta que el registro de errores conocidos tenga contenido útil, y luego reservar una porción fija (por ejemplo, una revisión de tendencias quincenal) para lo proactivo. Si lo proactivo no tiene tiempo asignado, nunca ocurre.

Cuando la lista de problemas abiertos crece, hay que priorizar. Un criterio simple combina tres factores: cuántos incidentes generó el problema en el período, qué servicios afectó y cuánto esfuerzo consume hoy la solución temporal. Un problema que provoca pocos incidentes pero obliga al equipo a intervenir manualmente cada noche puede valer más que uno ruidoso y de bajo impacto. Revisar esta priorización junto con el dueño de cada servicio evita que el equipo técnico decida solo qué importa.

Errores conocidos y soluciones temporales

Un error conocido es un problema que ya se analizó pero que todavía no tiene una corrección definitiva. Una solución temporal es una forma de reducir o evitar el impacto mientras tanto: reiniciar un servicio, redirigir tráfico, aplicar un ajuste manual.

El registro de errores conocidos es uno de los activos más rentables de la operación, siempre que cumpla tres condiciones:

• Es accesible para el service desk. Si solo lo consultan los especialistas, no reduce tiempos de restauración.
• Describe síntomas como los ve el usuario. "No carga el estado de cuenta" es más útil para buscar que "timeout en el pool de conexiones del servicio X".
• Tiene dueño y fecha de revisión. Una solución temporal que se vuelve permanente sin que nadie lo decida es deuda técnica oculta.

Cada error conocido termina de una de dos formas: con un cambio que lo corrige, gestionado por habilitación de cambios, o con una decisión explícita de aceptar el riesgo porque corregirlo cuesta más que convivir con él. Ambas son válidas. Lo que no es válido es dejarlo abierto indefinidamente.

Técnicas de causa raíz y sus límites

No hay una técnica universal. Cada una sirve para un tipo de situación, y todas comparten un riesgo: detenerse en la primera explicación plausible. En sistemas complejos, rara vez hay una sola causa; suele haber varios factores que coinciden.

Técnica	Cuándo sirve	Límite principal
Cinco porqués	Problemas acotados, con una cadena causal relativamente lineal	Sigue un solo camino; depende de lo que el grupo ya sabe y puede terminar en "error humano"
Diagrama de Ishikawa (espina de pescado)	Problemas con muchas causas posibles; ordena la lluvia de ideas por categorías	Produce hipótesis, no evidencia; cada rama hay que validarla con datos
Análisis de línea de tiempo	Incidentes mayores y fallas que involucran varios sistemas o equipos	Exige relojes sincronizados y registros completos; sin datos, se reconstruye de memoria

En la práctica, conviene combinarlas. La línea de tiempo establece qué pasó y en qué orden. El Ishikawa abre el abanico de causas posibles. Los cinco porqués profundizan en las que la evidencia sostiene.

Dos recomendaciones de método. Primero, que el análisis sea sin culpables: el objetivo es entender por qué el sistema permitió el error, no quién lo cometió. Si la conclusión es "la persona se equivocó", la pregunta siguiente es qué hizo posible esa equivocación. Segundo, que cada conclusión cite su evidencia: una métrica, un log, un cambio registrado. Una causa raíz sin evidencia es una opinión.

La observabilidad acelera el análisis

Buena parte del tiempo de un análisis de problemas se va en reunir datos: qué cambió, cuándo empezó la degradación, qué componentes participaron en la transacción que falló. Ahí la observabilidad marca la diferencia.

Logs, métricas y trazas son señales complementarias. Las métricas muestran cuándo y cuánto; las trazas muestran por dónde pasó una transacción y dónde se demoró; los logs explican qué ocurrió en cada punto. Una plataforma APM, como Dynatrace, Datadog u otras, hace observable la infraestructura y captura mucho de forma automática, incluida la correlación entre servicios.

Pero plataforma observable no es lo mismo que aplicación observable. Para que el análisis de causa raíz sea rápido, el software tiene que estar escrito para ser observable:

• Logs estructurados, con campos consistentes en lugar de texto libre.
• Identificadores de correlación que permitan seguir una operación de punta a punta.
• Propagación del contexto de trazas entre servicios, colas y llamadas a terceros.
• Métricas de negocio (operaciones completadas, rechazadas, abandonadas), no solo técnicas.
• Eventos significativos, como despliegues y cambios de configuración, registrados en la misma línea de tiempo.

OpenTelemetry es el estándar abierto de referencia para instrumentar estas señales. Con esa base, el análisis de línea de tiempo deja de ser una reconstrucción de memoria y pasa a ser una consulta. Por eso conviene que los hallazgos de problemas alimenten también el backlog de desarrollo: muchas causas raíz difíciles de encontrar revelan, de paso, qué faltaba instrumentar.

Métricas que muestran si la práctica funciona

La gestión de problemas se juzga por sus efectos sobre los incidentes, no por la cantidad de análisis realizados. Estas son las métricas que recomendamos seguir:

• Recurrencia: incidentes asociados a problemas ya analizados. Es la métrica principal; si no baja, el análisis no está llegando a la causa.
• Incidentes resueltos con un error conocido: proporción de incidentes que el service desk resolvió aplicando una solución temporal documentada.
• Tiempo hasta el error conocido: días desde la apertura del problema hasta que hay una solución temporal publicada.
• Antigüedad de los errores conocidos abiertos: cuántos llevan más tiempo del que la organización considera aceptable sin corrección ni aceptación formal.
• Proporción de problemas proactivos: cuántos problemas se abrieron antes de que hubiera un incidente visible para el usuario.

Conviene evitar la tentación de medir "problemas cerrados por mes". Incentiva cerrar rápido, no cerrar bien.

Cómo empezar en cuatro pasos

1. Define el criterio de apertura. Por ejemplo: todo incidente mayor, y todo incidente con el mismo síntoma que ocurra tres veces en un mes.
2. Asigna un dueño de la práctica. No tiene que analizar todo, pero sí asegurar que cada problema tenga responsable, fecha y seguimiento.
3. Publica el registro de errores conocidos. Aunque empiece con pocas entradas, debe estar integrado a la herramienta del service desk.
4. Revisa la recurrencia cada mes. Una reunión breve con incidentes, cambios y desarrollo, centrada en los cinco síntomas más repetidos.