Alertas de datos: cuándo merece la pena interrumpir al equipo

Imagina que a las tres de la madrugada llega un aviso: una tabla ha recibido menos filas de las habituales. La persona de guardia abre el portátil, comprueba que el origen no ha enviado nada nuevo y vuelve a la cama. A la mañana siguiente llega otro aviso parecido. Esta vez sí faltan datos que necesita el equipo de operaciones.

La dificultad que plantea es reconocible: dos señales técnicas casi iguales pueden justificar respuestas muy distintas. Si las tratamos como urgencias idénticas, obligamos a la persona a reconstruir el contexto cada vez que suena el teléfono.

Una alerta de datos merece interrumpir cuando hay un daño relevante que todavía podemos evitar y una respuesta que puede cambiar el desenlace. Detectar una anomalía no basta para decidir a quién despertar. Necesitamos conectar la señal con el uso del dato, el plazo y la intervención disponible.

Qué convierte una señal técnica en una alerta urgente

Una señal describe algo observado. Una alerta urgente añade una expectativa: alguien debe actuar ahora. Entre ambas hay una decisión de servicio que suele quedar escondida dentro de un umbral. «Menos filas que ayer» no explica por sí solo si hay un problema, cuánto importa o qué capacidad de respuesta necesitamos.

El capítulo de monitorización de sistemas distribuidos de Google SRE distingue síntomas y causas, y defiende que las reglas que llaman a personas sean simples y representen fallos claros. La lección que podemos trasladar al dato es separar la evidencia para diagnosticar de la razón para interrumpir. No necesitamos enviar cada detalle del diagnóstico al teléfono de guardia.

Esto tampoco obliga a esperar a que el usuario sufra el daño. Una señal anticipada puede justificar la interrupción si amenaza un compromiso y permite intervenir a tiempo. Lo importante es poder explicar la relación. Un umbral preventivo sin ese razonamiento puede producir mucho ruido; uno bien conectado con el servicio puede ser precisamente lo que evita el incidente.

La urgencia depende del uso y del tiempo disponible

Imaginemos que una conciliación necesita estar completa a las ocho. A las tres falta una fuente, pero el proveedor tiene una demora habitual y el equipo no puede acelerar su entrega. A las siete y media sigue faltando y ya existe una alternativa: detener un envío que utilizaría datos incompletos.

La diferencia es que, en el segundo momento, hay una consecuencia próxima y una acción definida. En el primero puede bastar registrar la anomalía y preparar el seguimiento, siempre que la observación posterior esté garantizada. Si el problema exige tres horas de reparación, el momento de avisar cambia otra vez.

Por eso frescura y urgencia no son sinónimos. Un dato reciente puede estar incompleto y ser peligroso para una decisión inmediata; uno antiguo puede ser perfectamente adecuado para una comparación histórica. El criterio se parece al de la ventana útil del dato, pero aquí lo aplicamos a otra decisión: cuándo consumir atención humana para proteger esa ventana.

El contrato de interrupción

Propongo llamar contrato de interrupción al acuerdo mínimo que debería acompañar a una alerta que exige respuesta inmediata. Es un modelo propio de conversación entre quienes producen, operan y utilizan el dato; no sustituye el análisis de riesgos ni un sistema de guardias.

Uso afectado

Qué decisión o servicio queda comprometido. «La tabla está vacía» es evidencia; «la asignación de rutas quedaría sin pedidos» explica el impacto.

Daño y plazo

Qué puede ocurrir y hasta cuándo tiene sentido intervenir. Un efecto ya consumado exige una respuesta distinta de uno todavía evitable.

Señal suficiente

Qué observación sostiene el aviso, con qué población y qué incertidumbre. Una caída de volumen en un festivo no significa lo mismo que durante una jornada comparable.

Respuesta disponible

Qué puede hacer la persona: recuperar, detener un consumo, cambiar a una alternativa o escalar a quien sí tiene capacidad. Recibir una alerta sin permisos para actuar no equivale a controlar el problema.

Cierre verificable

Qué evidencia demuestra que el servicio vuelve a ser aceptable y qué efectos anteriores siguen pendientes.

Si falta una casilla, hemos encontrado trabajo de diseño. No necesariamente una razón para borrar el aviso. Puede que debamos mejorar el diagnóstico, acordar quién responde o reconocer que necesitamos una alternativa que todavía no existe.

Presupuesto de error: una forma de dar escala al daño

El capítulo de alertas basadas en objetivos de servicio de Google SRE analiza precisión, cobertura, tiempo de detección y tiempo de recuperación de la alerta. Su enfoque de consumo del presupuesto de error relaciona la urgencia con la velocidad a la que se agota la tolerancia acordada. Trasladarlo a datos exige elegir qué cuenta como evento bueno, en vez de copiar un porcentaje de disponibilidad de una web.

Supongamos un objetivo inventado: al menos el 99 % de mil entregas mensuales debe estar completo antes de su plazo. Eso deja diez entregas fuera del objetivo como presupuesto de error. Si cuatro incumplen en una mañana, se ha consumido el 40 % de ese presupuesto. No significa que cualquier dato incorrecto esté permitido ni que esas cuatro entregas tengan el mismo impacto económico.

El ejemplo muestra tanto la utilidad como el límite del agregado. Una entrega crítica puede merecer respuesta aunque el presupuesto mensual siga holgado. Y con pocas entregas, una sola cambia mucho el porcentaje. El indicador ayuda a razonar sobre un servicio definido; no reemplaza la clasificación de consecuencias.

También debemos distinguir que una alerta se apague de que el incidente esté resuelto. Una tabla puede volver a su volumen esperado mientras siguen circulando informes elaborados durante el fallo. Esa separación entre origen y efectos aparece igualmente en la recuperación de datos y la aceptación del servicio.

Menos avisos no demuestra una mejor operación

Un equipo puede reducir el número de alertas subiendo umbrales hasta dejar de enterarse de los incidentes. La gráfica del ruido mejora; el servicio empeora. Por eso necesitamos contrastar qué interrupciones fueron útiles y qué problemas relevantes no se detectaron a tiempo.

Una revisión honesta de guardia puede distinguir avisos con intervención necesaria, avisos que no permitían actuar, incidentes descubiertos por usuarios y reincidencias sin solución. No hace falta convertirlo todo en una cifra única. La combinación permite decidir si debemos ajustar una regla, mejorar una alternativa operativa o resolver una dependencia que está consumiendo atención cada semana.

Hay señales que merecen una tarea planificada y otras que deben quedarse disponibles para investigar. Reservar la interrupción para lo urgente no rebaja la importancia del mantenimiento: le asigna un canal en el que pueda resolverse sin fingir que todo es una emergencia.

El objetivo de una buena alerta es que quien la recibe entienda qué está en juego y qué puede cambiar. Si cada llamada exige empezar averiguando para qué sirve el dato, todavía falta una parte del sistema. Esa parte se diseña hablando del servicio, no añadiendo otro umbral.