5 min de lectura
Un amigo ingeniero DevOps me llamó el año pasado tras su primera noche de guardia. 2:17 h, martes, alerta en Slack: «CRÍTICO – Tiempo de respuesta de la puerta de enlace API > 5 s – Producción». Miraba fijamente un panel de Grafana con 14 gráficos, y solo entendía tres de ellos. Nadie le había explicado que hacer guardia no significa resolver problemas, sino saber cuál es, en cada momento, el problema correcto. Tres lecciones de esa noche que todo ingeniero en la nube debería conocer antes de su primer turno.
En resumen
- La fatiga por alertas es el verdadero problema de los turnos de guardia: los equipos con más de 100 alertas por semana ignoran, de media, el 30 % de las notificaciones críticas (PagerDuty State of Digital Operations, 2025).
- Los manuales operativos (runbooks) sin revisiones periódicas y simulacros (game days) son inútiles: describen sistemas que han cambiado desde su última actualización.
- Una cultura de análisis postmortem no es una carga burocrática, sino el único método para aprender sistemáticamente de los incidentes, en lugar de repetirlos.
2:17 h: El momento en que nada funciona como en los tutoriales
Mi amigo – llamémosle Max – llevaba seis meses en el equipo. Había desplegado clústeres de Kubernetes, escrito charts de Helm y construido pipelines de CI/CD. Se sentía preparado. Lo que no sabía era que todo lo que había aprendido servía únicamente para el funcionamiento normal. El turno de guardia comienza justo donde este termina.
La alerta llegó a través de PagerDuty, se redirigió a Slack y, simultáneamente, apareció como notificación push en su teléfono móvil. En los siguientes cuatro minutos llegaron siete alertas más: tres CRÍTICAS, dos DE ADVERTENCIA y dos INFORMATIVAS. Max no tenía ni idea de cuál de las siete era la causa original y cuáles eran errores secundarios. Su panel de Grafana mostraba líneas rojas por todas partes, pero no podía distinguir si el pico de uso de CPU era la causa o la consecuencia del problema de latencia.
Tras 20 minutos y una llamada de emergencia por Slack con el ingeniero senior, el problema quedó resuelto: un pod había alcanzado su límite de memoria y se encontraba atrapado en un bucle de reinicios. La solución era una sola línea de código. Pero esos 20 minutos de pánico le enseñaron a Max más sobre operaciones en la nube que los seis meses anteriores de funcionamiento normal.
Lección 1: Señal frente a ruido – el trabajo verdadero ocurre ANTES del incidente
Esa noche, Max recibió 11 alertas en 15 minutos. Solo una de ellas era relevante. Las otras diez eran errores secundarios o alertas con umbrales demasiado bajos, que se disparaban ante cualquier mínima fluctuación de carga.
Lo que Max hubiera querido saber antes: ajustar las alertas no es una tarea que se haga una vez y luego se olvide. Es un proceso continuo. Cada alerta que no desencadena una acción es ruido. Cada alerta que debería haber desencadenado una acción pero pasó desapercibida constituye un riesgo. Mejorar la relación señal/ruido es el trabajo más importante antes del primer incidente – no la configuración de paneles.
Su consejo: pregunta a tu equipo qué alertas, en los últimos 30 días, llevaron efectivamente a una acción concreta. Todas las demás deben someterse a revisión.
Lección 2: Un manual operativo (runbook) que nadie ha revisado no es un runbook
A las 2:30 h, Max abrió el runbook. Describía una arquitectura que había sido modificada tres meses atrás. El microservicio marcado como «punto único de fallo» ya no existía. El equilibrador de carga descrito como «punto final primario para comprobaciones de estado» había sido sustituido por uno nuevo. Tenía un documento que, activamente, le inducía a error.
«Un runbook obsoleto es más peligroso que no tener ninguno. Sin runbook, sabes que no tienes nada. Con un runbook obsoleto, crees que tienes algo – y sigues unas instrucciones que ya no son válidas».
– Valoración editorial de cloudmagazin
Lo que Max aprendió de esto: los simulacros (game days) no son una actividad lúdica para equipos con demasiado tiempo libre. Son la única forma de garantizar que los runbooks funcionan antes de necesitarlos en una situación real. Su equipo ahora realiza un incidente simulado cada seis semanas. Desde entonces, el runbook está actualizado – porque cada simulacro revela los puntos donde la documentación se ha desviado de la realidad.
Lección 3: Una cultura de análisis postmortem salva nervios y reputación
Al día siguiente del incidente ocurrió algo que Max no esperaba: un análisis postmortem estructurado. Sin señalar culpables, sin asignar culpas. En su lugar: cronología, causa raíz, factores contribuyentes y acciones concretas, incluyendo responsable y fecha límite. El ingeniero senior contaba con una plantilla que utilizaba desde hacía tres años: cinco secciones, una página.
El análisis postmortem reveló tres aspectos que nadie había tenido en cuenta: primero, la fuga de memoria existía desde hacía dos semanas, pero la alerta correspondiente estaba configurada como «prioridad baja». Segundo, el camino de escalado era poco claro: Max no sabía cuándo «tenía permiso» para llamar al ingeniero senior en lugar de intentar resolverlo él mismo. Tercero, el proceso de incorporación para nuevos miembros de guardia no contemplaba ninguna fase de observación (shadowing).
Los tres puntos de acción se implementaron en la semana siguiente. Desde entonces, cada nuevo miembro del equipo pasa una semana completa en «guardia observacional» (Shadow On-Call) antes de entrar en la rotación individual. Esto cuesta una semana por persona. Pero ahorra meses de frustración.
Lo que Max hace hoy de forma distinta
Dos años y probablemente 50 noches de guardia después, Max conserva tres hábitos: revisa sus alertas una vez por sprint y elimina todas aquellas que no hayan provocado una acción en los últimos 30 días; revisa el runbook tras cada cambio arquitectónico – no solo tras los incidentes – ; y redacta un análisis postmortem tras cada incidente, incluso si este es «pequeño». Los incidentes pequeños son de donde más se aprende – porque son los precursores de los grandes.
Si te enfrentas a tu primer turno de guardia: cometerás errores. Eso no es el problema. El problema es cuando tu equipo carece de una estructura para aprender de esos errores. Pregunta por los simulacros (game days), pregunta por los procesos de respuesta a incidentes, pregunta por la guardia observacional (Shadow On-Call). Si nada de eso existe: créalo tú. Es la forma más rápida de pasar de ser un ingeniero junior a ser el ingeniero al que el equipo llama por la noche – no porque conozcas la mejor solución, sino porque conoces el mejor proceso.
Preguntas frecuentes
¿A partir de cuándo debería un ingeniero junior incorporarse a la rotación de guardia?
Tras una fase de observación (shadowing) de al menos una semana y la participación en un simulacro (game day). Más importante que el conocimiento técnico es conocer el camino de escalado: ¿cuándo debo escalar?, ¿a quién?, ¿por qué canal? Sin esta claridad, nadie debe asumir un turno de guardia en solitario.
¿Cuántas alertas por semana son aceptables?
PagerDuty recomienda como orientación menos de 40 alertas por semana por equipo. Lo decisivo no es el número, sino la proporción: más del 50 % de las alertas deberían dar lugar a una acción concreta. Si esta tasa es inferior, es urgente realizar un ajuste del sistema de alertas.
¿Qué formato de análisis postmortem funciona mejor?
El más sencillo que tu equipo realmente utilice. Una estructura probada: cronología, causa raíz, factores contribuyentes, impacto y acciones concretas (con responsable y fecha límite). Máximo una página. Google y Atlassian publican gratuitamente sus plantillas.
Recomendaciones de lectura de la redacción
Fuente de imagen: ilustración generada por IA (FLUX.2) – sin representación de producto
