Un guardia mal diseñado cobra su precio en retención: quien se despierta tres noches seguidas actualiza su CV la semana siguiente. Antes de elegir la herramienta de alertas, cinco decisiones de diseño determinan si la rotación aguanta seis meses. Las decisiones siguientes vienen de equipos de 8 a 40 personas con guardia propio, y cada una cierra con un número que el equipo sigue.
Una persona se despierta, como máximo, por noche
Tope semanal de páginas y turno con descanso. El libro Site Reliability Engineering (Beyer et al., O'Reilly, 2016) trata la fatiga de guardia como riesgo de proyecto y defiende la rotación con tiempo de recuperación. Súmale un límite de eventos: pasados tres incidentes en siete días, el siguiente paso es estabilizar la causa en lugar de enrutar más páginas. Publica el número en el panel del equipo.
Handover escrito al final de cada turno
Seis líneas: qué cambió, qué está inestable, a quién llamar. Sin handover, el turno siguiente descubre el sistema por ensayo. Building Secure and Reliable Systems (Google, O'Reilly, 2020) vincula operar con contexto explícito a menos errores humanos y trata el cambio de turno como parte del trabajo. El registro queda en el canal del guardia y se vuelve materia prima del postmortem.
Runbook antes que la alerta
Ninguna alerta entra en la rotación sin una acción documentada. Cada alerta apunta a un runbook de diez líneas: qué revisar, qué es grave, quién decide el rollback. Una alerta sin runbook entrena a la rotación a llamar a una persona. Empieza con las alertas que despiertan al equipo más de dos veces por semana y deja el resto fuera de la lista. Deja el runbook en el mismo directorio del servicio, porque un runbook en una wiki fuera del repositorio envejece en semanas.
Quién entra en la rotación
Junior y senior juntos, en pareja los primeros tres meses. El ingeniero nuevo hace el guardia con alguien experimentado hasta cerrar cinco turnos sin escalar un error. Quien capacita gente en guardia gana dos turnos menos en la cuenta semanal, y el cambio aparece en el reporte.
Costo medido en sueño y en retrabajo
Dos métricas: interrupciones por noche y horas de estabilización. El State of DevOps Report de DORA lee estabilidad y burnout en el mismo análisis: un equipo que entrega rápido y se quema entrega menos el trimestre siguiente. Lleva las dos métricas a la revisión trimestral de la rotación, junto con la lista de páginas por causa raíz.
