No toda alerta merece despertar a una persona. Pero alguien sigue levantándose por ella. El problema real no es la alerta — es que se volvió paisaje.
Ya conoces esa sensación.
Son las 3am. El celular suena. Abres un ojo, lo agarras, y lees la alerta antes de estar completamente despierto. El ritmo cardíaco se dispara antes de que el cerebro haya procesado si esto es realmente serio.
Abres el laptop. Revisas el dashboard. Miras los logs.
Y entonces — treinta segundos después — cierras el laptop y vuelves a la cama. Porque no era nada. Un umbral configurado demasiado agresivo. Un pico transitorio que se resolvió solo. Una métrica que cruzó una línea que alguien dibujó hace años y que nadie ha revisado desde entonces.
No arreglaste nada. Solo confirmaste que no había nada que arreglar.
Y mañana en la noche, probablemente va a pasar de nuevo.
La alerta que nadie tiene asignada
Hay una pregunta que vale la pena hacer en la próxima retrospectiva del equipo:
De cada alerta que disparó el mes pasado — ¿Cuándo fue la última vez que alguien revisó deliberadamente si esa alerta debería seguir existiendo?
En la mayoría de los equipos, la respuesta honesta es: nadie. O alguien que ya no trabaja ahí.
Las alertas se acumulan. Se crean durante incidentes, se agregan como precaución después de un postmortem, se copian de plantillas sin pensar demasiado si aplican al contexto específico. Y luego se quedan. Porque eliminar una alerta se siente arriesgado — ¿y si algo realmente pasa y no lo detectamos? o como dice las abuelas "es mejor la seguridad que la policia" — mientras mantenerla se siente seguro, aunque signifique falsas alarmas ocasionales a las 3am.
El resultado es un sistema de alertas que crece en una sola dirección. Más alertas, más ruido, más interrupciones. Y un equipo que lentamente aprende a tratar las alertas como la mayoría de la gente trata las alarmas de los carros: como ruido de fondo que probablemente no significa nada.
Ese es un lugar peligroso. No porque el equipo sea descuidado — sino porque la desensibilización es una respuesta humana natural al ruido constante de bajo valor. Cuando todo es urgente, nada lo es.
El costo real no es el sueño perdido
El sueño importa. El sueño interrumpido tiene consecuencias reales en el rendimiento cognitivo, la calidad de las decisiones y la salud a largo plazo. Eso solo debería ser suficiente para tomarlo en serio.
Pero hay un costo que es más difícil de ver y más fácil de ignorar: la pérdida de confianza en el sistema de monitoreo y observabilidad.
Cada falsa alarma a las 3am es un retiro de una cuenta de confianza. El equipo empieza a tratar las alertas con escepticismo. Los tiempos de respuesta se alargan. El modelo mental cambia de "una alerta significa que algo está mal" a "una alerta significa que tengo que verificar si algo está mal". No son lo mismo, y la diferencia importa cuando ocurre un incidente real.
También está el costo del cambio de contexto. Una verificación de treinta segundos a las 3am tarda más de treinta segundos en recuperarse. Volver a dormir después de un pico de adrenalina no es inmediato. Retomar un pensamiento complejo a la mañana siguiente desde donde lo dejaste la noche anterior no es gratis.
Estos costos no aparecen en dashboards. Aparecen en la resignación silenciosa, en el ingeniero que deja de mencionar las interrupciones porque las aceptó como parte del trabajo, en el declive gradual del compromiso que antecede a una renuncia que nadie vio venir.
Cómo llegamos aquí
La cultura de oncall en Cloud Operations tiende a seguir un camino conocido.
Empieza razonable. Un equipo pequeño, un sistema crítico, alguien necesita estar disponible si algo se rompe. La rotación es liviana, las alertas son significativas, y las interrupciones son lo suficientemente infrecuentes como para sentirse aceptables.
Luego el sistema crece. Más servicios, más dependencias, más casos. Más alertas agregadas después de cada incidente — porque después de un incidente, el instinto siempre es agregar cobertura, nunca cuestionar si la cobertura existente sigue bien calibrada.
La rotación mantiene el mismo tamaño mientras la superficie de lo que necesita monitorearse se expande. La relación entre señal y ruido cambia. Y en algún punto — nadie puede precisar exactamente cuándo — el equipo cruza una línea de "estamos cubiertos" a "nos estamos ahogando en cobertura que no cubre las cosas correctas".
Nadie decidió que esto era aceptable. Simplemente se volvió la línea base.
Viví esto de primera mano con un desborde de base de datos que ningún índice podía contener. Una sola consulta mal optimizada derribaba el servicio — cinco minutos de aplicación caída, búsqueda desesperada de escalamiento vertical, y rezar para que la base secundaria tuviese toda la información replicada antes de subirla y restablecer. Lo hacíamos una y otra vez. Éramos expertos en el procedimiento de recuperación.
Lo que no nos preguntábamos era por qué teníamos que recuperar.
Un día alguien hizo el símil: éramos como el que toma una pastilla para el dolor de cabeza todos los días. La pastilla funciona, el dolor pasa, y mañana vuelve. Funciona tan bien que nunca vamos al médico. Hasta que un día decidimos ir — y en una hora de análisis encontramos que la consulta tenía un costo altísimo y los índices estaban completamente fragmentados. La solución real tardó una hora en identificarse. La automatización que generamos después desescalaba en las noches para reducir costos, la escalaba antes de iniciar la jornada, y desfragmentaba los índices día de por medio.
Meses de oncall nocturno, resueltos con una hora de análisis que nunca habíamos priorizado porque siempre había algo más urgente.
No toda alerta merece despertar a una persona
Esto es obvio una vez que se dice en voz alta, pero rara vez se dice explícitamente:
Una alerta que consistentemente no requiere acción no necesita despertar a una persona. Necesita ser arreglada, automatizada, o eliminada.
Las tres categorías que vale aplicar a cada alerta del sistema:
Arréglarla. Si una alerta dispara porque algo genuinamente está mal pero la solución siempre es la misma — reiniciar un servicio, limpiar una cola, ajustar un parámetro — eso no es una alerta. Es una automatización esperando ser escrita. La alerta debería disparar un script, no una llamada.
Automatizar la respuesta. Si la alerta requiere investigación pero la investigación casi siempre lleva a la misma conclusión, esa conclusión puede codificarse. No toda alerta necesita una decisión humana. Algunas necesitan una revisión humana de una decisión que el sistema ya tomó correctamente.
Eliminarla. Si una alerta dispara regularmente y regularmente no requiere acción, no es una alerta — es ruido. El miedo de eliminarla es real, pero el costo de mantenerla también es real, y ese costo lo paga la persona cuyo sueño interrumpe.
El objetivo no es cero alertas. El objetivo es que cada alerta que dispare tenga un dueño claro, una respuesta esperada clara, y una razón para creer que una persona necesita estar involucrada en esa respuesta.
La conversación que la mayoría de los equipos evita
Hay una razón por la que la higiene de alertas está perpetuamente en el backlog y perpetuamente sin priorizarse: requiere una conversación que se siente incómoda.
Requiere que alguien mire una alerta que fue creada después de un incidente real y diga "esta alerta disparó cuarenta veces en los últimos noventa días y tomamos acción dos veces — quizás no debería existir en su forma actual". Y eso se siente como decir que el incidente no importó, o que la persona que creó la alerta estaba equivocada.
También requiere admitir que el estado actual de la rotación de oncall no es sostenible, lo que significa admitir que algo que el equipo normalizó no debería haberse normalizado.
Estas conversaciones valen la pena. No en un postmortem, no cuando alguien está agotado después de una semana difícil de guardia, sino deliberadamente, cuando hay espacio para mirar el sistema con ojos frescos y preguntar: si estuviéramos diseñando este oncall desde cero hoy, ¿se vería así?
Casi siempre, la respuesta es no.
Cómo se ve cuando funciona bien
Un oncall bien calibrado no se mide por qué tan raramente suena el pager. Se mide por qué tan seguros está el equipo de que cuando suena, importa.
Esa confianza cambia todo. Cambia qué tan rápido responden las personas, qué tan en serio toman la investigación, cuánta energía cognitiva le dedican al problema. Cambia la relación entre el equipo y los sistemas que operan.
También cambia quién quiere estar en el equipo. Los ingenieros que están construyendo sus carreras no quieren pasar años despertándose por alertas que no los necesitan. Los mejores tienen opciones, y las ejercen.
Y hay algo que pocas veces se dice en voz alta: los ingenieros existimos para mejorar la calidad de vida de las personas. Es triste que en nuestra propia área seamos los descuidados — como dice el dicho: en casa de herrero, cuchillo de palo. Es preferible dejar de apagar incendios y empezar a preguntarnos: ¿por qué se está incendiando?
Una rotación de oncall sostenible es una estrategia de retención. Y también es simplemente lo correcto construir.
En el siguiente post: la aprobación en la que todos hacen click sin leer — y lo que dice sobre los procesos que construimos alrededor de una confianza que en realidad no tenemos.
¿Tu equipo ha hecho una auditoría de alertas recientemente? ¿Qué encontraron? Cuéntalo en los comentarios — lo gracioso es que estos patrones pasan en tu equipo, en tu país, y en equipos del resto del mundo. No somos los únicos a los que nos ha pasado esto.
Top comments (0)