Cómo rotar una guardia de soporte entre zonas horarias
El objetivo es la cobertura “siguiendo al sol”: los incidentes los recoge quien está despierto, nadie recibe avisos a las 3am de forma regular, el reloj de 24 horas se divide sin que una sola persona cargue con la mayor parte.
La parte difícil no es el concepto. Son los traspasos.
El modelo básico
La estructura más simple asigna a cada equipo regional una ventana UTC contigua durante su jornada laboral normal:
| Región | Ventana de cobertura (UTC) | Equivalente local |
|---|---|---|
| Américas (San Francisco) | 16:00–00:00 UTC | 8am–4pm PST |
| Europa (Londres) | 08:00–16:00 UTC | 8am–4pm GMT |
| APAC (Singapur) | 00:00–08:00 UTC | 8am–4pm SGT |
Cobertura de 24 horas, nadie de guardia fuera del horario laboral. Esta es la versión ideal. Los equipos reales no siempre tienen tres oficinas regionales equilibradas — ver más abajo.
Los traspasos son el punto de fallo
La mayoría de los problemas en las rotaciones de guardia ocurren en los límites de traspaso. Un incidente se activa a las 15:55 UTC — ¿es de APAC o de Europa? Si la respuesta es ambigua, los avisos se pierden o se duplican.
Defínelo explícitamente:
- La responsabilidad la determina quien está de guardia en el momento en que se activa el incidente, no quien lo investigó primero.
- En los límites de turno, el ingeniero saliente escribe un breve resumen del estado; el entrante lo confirma antes de que el saliente se desconecte.
- Incorpora 15–30 minutos de solapamiento en cada traspaso donde ambos equipos estén disponibles. Cuesta poco y captura todo lo que llega en la costura.
El cambio de horario provoca deriva en la rotación
Si tus ingenieros están en regiones que observan el horario de verano, las ventanas de cobertura UTC necesitan desplazarse cuando cambian los relojes — o las ventanas dejan de coincidir con las jornadas laborales reales.
Ejemplo: Londres cubre 08:00–16:00 UTC en invierno. Después de que el Reino Unido pase a BST (UTC+1), las 08:00 UTC son las 9am en Londres — una hora dentro de su jornada, pero efectivamente están empezando la guardia una hora antes en hora local.
La solución con menos errores: ancla los turnos a la hora local en tu herramienta de guardia (“8am–4pm hora de Londres”) y deja que la herramienta gestione la conversión a UTC. La mayoría de las plataformas modernas admiten esto. Si la tuya no, tendrás que actualizar las ventanas UTC dos veces al año después de los cambios de horario — algo que la gente consistentemente olvida hacer.
Cuando no tienes tres regiones equilibradas
Tres equipos con ventanas de 8 horas dividiendo el reloj a la perfección es el mejor caso. La mayoría de los equipos no tienen eso.
Dos regiones: Una debe cubrir el hueco. Rota semanalmente — la semana A, las Américas se extienden hasta medianoche UTC; la semana B, Europa empieza a las 06:00 UTC. Registra explícitamente para que ningún equipo lo lleve indefinidamente.
Tamaños de equipo desiguales: Ajusta los límites de ventana para que las horas por ingeniero sean aproximadamente iguales, no para que las ventanas regionales sean iguales. Un equipo de 10 personas cubriendo 10 horas es más ligero por persona que un equipo de 2 cubriendo 8 horas.
Cobertura de fin de semana: Defínela por separado de los días de semana. Muchos equipos aceptan SLAs más largos los fines de semana y menos ingenieros de guardia. Dilo explícitamente — las expectativas de cobertura de fin de semana “implícitas” son una fuente fiable de tensión.
Usa meetwhen para verificar que tus ventanas UTC caen donde crees que caen en la hora local de cada ingeniero, especialmente después de cambios de horario o cuando se incorpora un nuevo equipo de una ciudad diferente.
Buy me a coffe