Alertas que la gente atiende, y las que aprendió a ignorar

Pregúntale a alguien de guardia qué pasa cuando le vibra el teléfono a las dos de la madrugada. En un equipo sano, lee la alerta y sabe en diez segundos si tiene que abrir el portátil. En la mayoría de los equipos, la lee, piensa "otra vez esa", la silencia y se vuelve a dormir. A veces la que silenció era real.

Eso no es un fallo individual. Es el resultado predecible de una guardia donde la mayoría de los avisos no son accionables. En cuanto la tasa base de falsas alarmas pasa de aproximadamente una de cada tres, la atención humana se derrumba, y no hay proceso que lo arregle. La única reparación es borrar alertas.

Alerta sobre síntomas, no sobre causas

El cambio con más valor es pasar de alertas basadas en la causa a alertas basadas en el síntoma.

Una alerta de causa se dispara con la CPU por encima del 80 por ciento, la memoria por encima del 90, una cola de más de mil, el disco al 85. Cualquiera de esas puede estar perfectamente bien. Un trabajo por lotes al cien por cien de CPU durante veinte minutos es un trabajo por lotes trabajando. Una cola de cinco mil que se vacía en noventa segundos es normal. Todas estas alertas se van a disparar cuando no pasa nada, que es la definición del problema.

Una alerta de síntoma se dispara con lo que experimenta el usuario: la tasa de error del pago supera el umbral, la latencia del percentil noventa y nueve en la búsqueda se ha duplicado, los pedidos no se están procesando. Si ninguno de tus usuarios lo puede notar, no es un aviso.

El contraargumento es siempre el mismo: "pero quiero enterarme antes de que le duela al usuario". Dos respuestas. Primera, las cosas que predicen de forma fiable el dolor del usuario son pocas, y el disco llenándose es el ejemplo honesto, así que conserva esas y borra el resto. Segunda, para eso están los paneles y los tickets. La predicción va en una pantalla que alguien mira en horario laboral, no en un teléfono de noche.

El ritmo de consumo gana a los umbrales estáticos

Si tienes objetivos de nivel de servicio, alerta sobre el ritmo de consumo del presupuesto de error en lugar de sobre un umbral crudo. El mecanismo es simple: compara la velocidad a la que estás consumiendo el presupuesto con la velocidad a la que lo consumirías si todo el periodo fuera uniformemente malo.

La razón de que funcione es que escala con la gravedad automáticamente. Una caída total quema un mes de presupuesto en una hora y avisa de inmediato. Una degradación lenta quema el presupuesto a lo largo de días y produce un ticket, no un aviso. Una regla sustituye la maraña de umbrales de "cinco por ciento durante cinco minutos, o dos por ciento durante treinta" que los equipos van acumulando durante años.

La implementación estándar usa dos ventanas a la vez, una rápida para cazar eventos graves enseguida y otra lenta para no dispararse con un parpadeo, y las dos tienen que estar quemando para que avise. Recorta los avisos falsos de forma sustancial en casi todos los entornos. Esto solo funciona si los objetivos están bien elegidos de entrada, que es el argumento de objetivos que detienen un despliegue.

Aviso, ticket o panel

Toda alerta tiene que clasificarse en exactamente uno de tres destinos, y la clasificación es una decisión sobre tiempo humano.

Aviso significa despertar a alguien ahora. El criterio es estricto: impacto visible para el usuario, o daño irreversible inminente como un disco que se va a llenar antes de que amanezca, y una persona puede hacer algo al respecto ahora mismo. Si la corrección automática lo va a resolver, no es un aviso.

Ticket significa que necesita trabajo pero no esta noche. Un certificado que caduca en tres semanas, un grupo de nodos sistemáticamente sobrecomprometido, una tasa de error que sube pero todavía no incumple el objetivo. Las alertas que van a ticket tienen que tener una cola real con un dueño real, o son solo una forma más lenta de ignorar cosas.

Panel significa que es contexto, no una notificación. La mayoría de las métricas de infraestructura van aquí.

La regla que mantiene esto honesto: si una alerta se dispara y la respuesta es "habría que mirar eso algún día", nunca fue un aviso. Reclasifícala a la mañana siguiente.

Agrupación, inhibición y el incidente que avisa doce veces

Cuando una base de datos falla, veinte servicios reportan errores. Veinte avisos por un incidente es la forma en que se quema una guardia.

Alertmanager y sus equivalentes se encargan de esto, pero solo si se configuran. Agrupa las alertas por una etiqueta común como clúster o servicio para que una notificación lleve muchas instancias. Usa reglas de inhibición para que una alerta activa de base de datos caída suprima las alertas dependientes de servicios que no conectan. Pon una espera de agrupación para que una ráfaga de alertas relacionadas llegue como una notificación y no como doce. Y encamina por propiedad de equipo a partir de una etiqueta de la alerta, no de una lista estática en la configuración que se desactualiza en cuanto alguien cambia de equipo.

Los silencios necesitan caducidad. Un silencio permanente es una alerta borrada con disfraz, salvo que nadie lo ve en la revisión de código. Audita los silencios cada mes y borra la alerta de debajo si el silencio se renueva una y otra vez.

Toda alerta enlaza a un runbook, y el runbook es honesto

Una alerta que dice "uso de memoria alto" y nada más le entrega a quien está de guardia un proyecto de investigación. Adjunta un enlace a un runbook en la anotación de la alerta, y exígelo antes de poder fusionar la alerta.

El runbook necesita cuatro cosas y ninguna más: qué significa esto en términos de usuario, cómo confirmar en menos de dos minutos que es real, las dos primeras mitigaciones y a quién escalar. Debería caber en una pantalla. Los runbooks largos no se leen a las tres de la madrugada. Es el mismo documento al que apunta el runbook de respuesta a incidentes para la capa técnica.

Los runbooks se pudren. Enlázalos desde la definición de la alerta para que el revisor los vea juntos, y compruébalos durante los días de juego.

La revisión que de verdad borra cosas

Una vez al mes, saca todas las alertas que se dispararon y clasifica qué pasó: un incidente real, una recuperación automática o nada. Después aplica una regla contundente. Una alerta que se ha disparado más de tres veces sin producir ninguna acción humana se borra o se degrada a ticket. Ni se ajusta, ni se silencia. Se borra.

Los equipos se resisten porque cada alerta la añadió alguien con un motivo. El motivo fue casi siempre un único incidente pasado, y la alerta es un monumento a él más que un control. Si el fallo se repite, te enterarás por la alerta de síntoma sobre el efecto visible para el usuario, que es la que lo habría cazado también la primera vez.

Sigue dos números y ponlos donde el equipo los vea: avisos por turno de guardia y porcentaje que llevó a una acción. Por debajo de unos dos avisos por turno con la mayoría accionables es una guardia que se mantiene sana. Todo lo demás es un plan de rotación de personal.

Lo que se olvida

• Las alertas sobre una métrica que desaparece no se disparan nunca. Si un servicio deja de reportar del todo, no hay serie que evaluar. Alerta sobre la ausencia explícitamente.
• El sistema de monitorización necesita monitorización. Un recolector muerto es silencioso, que se parece exactamente a que todo va bien. Usa una alerta de latido contra un servicio externo.
• Nadie prueba las alertas. Son código, y el código que nunca se ha ejecutado está roto. Dispáralas a propósito en un día de juego.
• El horario laboral no es el mismo en todas partes. Un equipo repartido entre husos necesita encaminamiento por hora, no una guardia única que en silencio significa una sola persona.
• La fatiga de notificaciones incluye el chat. Un canal con cuatrocientos mensajes automáticos al día se ignora exactamente igual que un busca ruidoso.

Qué hacer esta semana

Exporta todas las alertas que se dispararon en los últimos treinta días, ordenadas por número. Coge las cinco primeras y pregunta, para cada una, qué hizo una persona al respecto. Si la respuesta de alguna es nada, bórrala hoy. En casi todos los entornos esas cinco son más de la mitad de todos los avisos, y borrar dos cambia la experiencia de estar de guardia más que cualquier compra de herramienta. Hacemos esta pasada en la primera quincena de un proyecto cloud.