Plantilla de Handoff On-Call Gratis (Copiable)

Visión General

Un handoff on-call (también llamado “handover” o entrega de guardia) es la transferencia estructurada de contexto operativo y responsabilidad del ingeniero saliente al entrante en el cambio de turno. Los handoffs mal hechos son una causa frecuente de escalamiento de incidentes: cuando el contexto se pierde, el ingeniero entrante quema minutos preciosos redescubriendo lo que el saliente ya sabía.

Esta plantilla estandariza el handoff para que la información crítica sobre incidentes activos, alertas en curso y estado del sistema se transfiera completa en cada turno. Abajo tienes la plantilla en blanco, un ejemplo ya rellenado, un formato corto para Slack y la checklist para llevar la conversación.

Cuándo Usarla

Usa esta plantilla cuando:

• Transfieres la responsabilidad on-call entre turnos o miembros del equipo
• Te vas de vacaciones o baja prolongada con cobertura on-call
• Entregas a mitad de un incidente que se extiende por varios turnos
• Rotas las guardias semanal o quincenalmente

Es excesiva para un equipo de una sola persona y sobra cuando el ingeniero entrante ya estuvo en el canal del incidente todo el turno. Para comunicar a stakeholders en lugar del siguiente ingeniero, usa la Plantilla de Comunicación de Incidentes: otra audiencia, otro nivel de detalle.

Antes del Handoff

Diez minutos antes de la conversación:

• El ingeniero saliente revisa todas las alertas e incidentes activos
• Los runbooks de los problemas en curso están actualizados con los últimos hallazgos
• El historial del canal del incidente está resumido como contexto
• Los cambios o despliegues programados están anotados
• El documento de handoff ya está rellenado — no lo escribas de memoria durante la llamada

El último punto importa más que el resto. La memoria comprime mal bajo fatiga, y el final del turno es justo cuando más cansado estás. Actualiza el documento a medida que pasan las cosas durante el turno, y la revisión previa se convierte en un sanity check de diez minutos en lugar de una hora de reconstrucción.

La Plantilla

# Reporte de Entrega de Guardia

## Metadatos de la Entrega

| Campo | Valor |
|-------|-------|
| Ingeniero saliente | ______ |
| Ingeniero entrante | ______ |
| Fecha/hora de la entrega | ______ |
| Duración del turno | ______ |

## 1. Incidentes Activos

### Incidente #1: `<Título>`
| Campo | Valor |
|-------|-------|
| Estado | Investigando / Mitigado / Resuelto |
| Severidad | P1 / P2 / P3 / P4 |
| Hora de inicio | ______ |
| Canal del incidente | ______ |
| Responsable actual | ______ |

**Resumen:**
Descripción de un párrafo sobre qué pasó, qué se ha intentado y el estado actual.

**Próximos pasos:**
- [ ] Acción 1 (responsable: ______, fecha límite: ______)
- [ ] Acción 2 (responsable: ______, fecha límite: ______)

**Runbook / Referencia:**
Enlace al runbook o guía de troubleshooting relevante.

---

### Incidente #2: `<Título>`
(Misma estructura que el anterior)

## 2. Alertas y Advertencias en Curso

| Alerta | Estado | Primera vez | Notas |
|--------|--------|-------------|-------|
| ______ | WARN / OK | ______ | ______ |

## 3. Resumen de Salud del Sistema

| Componente | Estado | Notas |
|------------|--------|-------|
| Latencia API p95 | Saludable / Degradado / Crítico | Valor actual: ______ |
| Tasa de errores | Saludable / Degradado / Crítico | Valor actual: ______ |
| Conexiones a la base de datos | Saludable / Degradado / Crítico | Valor actual: ______ |
| Profundidad de cola | Saludable / Degradado / Crítico | Valor actual: ______ |
| Tasa de aciertos de caché | Saludable / Degradado / Crítico | Valor actual: ______ |
| Uso de disco | Saludable / Degradado / Crítico | Valor actual: ______ |

## 4. Cambios y Despliegues

### Completados en este turno
| Cambio | Hora | Estado | Impacto |
|--------|------|--------|---------|
| ______ | ______ | ______ | ______ |

### Programados para el próximo turno
| Cambio | Hora | Riesgo | ¿Preparado? |
|--------|------|--------|-------------|
| ______ | ______ | ______ | ______ |

## 5. Problemas Conocidos y Soluciones Temporales

| Problema | Solución temporal | Ticket | Prioridad |
|----------|-------------------|--------|-----------|
| ______ | ______ | ______ | ______ |

## 6. Rutas de Escalamiento

| Escenario | Escalar a | Contacto |
|-----------|-----------|----------|
| ______ | ______ | ______ |

## 7. Verificación de Accesos y Entorno

- [ ] El ingeniero entrante está en la rotación de PagerDuty/Opsgenie
- [ ] VPN y acceso a producción verificados esta semana
- [ ] Dashboards, visores de logs y herramientas de despliegue accesibles
- [ ] Unido a los canales de incidentes en Slack y sin silenciarlos
- [ ] Ubicación física / zona horaria anotada para el turno

## 8. Notas y Contexto

**Observaciones inusuales del turno:**
- Cualquier anomalía que no llegue a nivel de alerta pero pueda anticipar problemas

**Solicitudes de otros equipos:**
- Cualquier pedido no urgente que haya llegado durante el turno

**Recordatorios generales:**
- Cualquier contexto específico del equipo que el ingeniero entrante deba saber

Las ocho secciones mapean a las preguntas que el ingeniero entrante realmente hará, más o menos en el orden en que las hará. Primero incidentes, porque es lo que está ardiendo; luego alertas, porque esas se convierten en incidentes; salud y cambios para establecer qué es normal y qué está por moverse; problemas conocidos y rutas de escalamiento para que nada se descubra en frío a las 3 AM; verificación de accesos, porque es la comprobación más barata y la más incómoda de saltarse; y notas para todo lo que no cabe en una tabla pero igual importa.

La versión rellenada de abajo muestra cómo se ve un handoff bien hecho: se lee en dos minutos.

Ejemplo Rellenado

## 1. Incidentes Activos

### Incidente #1: Errores 500 en la API de pagos tras un despliegue
| Campo | Valor |
|-------|-------|
| Estado | Mitigado (rollback hecho, monitoreando) |
| Severidad | P2 |
| Hora de inicio | 14:35 UTC |
| Canal del incidente | #inc-payment-500s |
| Responsable actual | Dana (el entrante lo toma) |

**Resumen:**
Los errores de checkout subieron al 12% tras el despliegue 4f2a1c.
Rollback a las 15:20 y la tasa volvió a la base (0.3%). Causa
sospechada: falta un índice en la nueva ruta de consulta. El índice
se está construyendo ahora.

**Próximos pasos:**
- [ ] Verificar que el índice terminó de construirse (~18:00 UTC, resp.: Dana)
- [ ] Publicar el resumen del incidente en el canal antes de fin de día (resp.: Dana)

## 2. Alertas y Advertencias en Curso

| Alerta | Estado | Primera vez | Notas |
|--------|--------|-------------|-------|
| Latencia alta en la API | WARN | hace 2h | Correla con el despliegue, vigilar |
| Uso de disco > 80% | WARN | hace 1d | El cron de limpieza corre hoy a las 02:00 |

## 7. Verificación de Accesos y Entorno

- [x] Dana confirmada en la rotación de PagerDuty de esta semana
- [x] Dashboards y herramientas de despliegue verificados el martes
- [ ] Falta unirse a #inc-payment-500s — envío la invitación ahora

Fíjate en que el ejemplo mezcla trabajo casi resuelto (el incidente mitigado) con cosas que morderán más tarde (la alerta de disco, el canal sin unirse). De eso va el handoff: los detalles aburridos son los que se olvidan a las 3 de la mañana.

Variante Slack / Asíncrona

Cuando no hay ventana de solapamiento (zonas horarias distintas, huecos de cobertura), un mensaje estructurado de Slack le gana a una página de wiki que nadie abre. Mantenlo por debajo de 15 líneas o la gente deja de leer:

HANDOFF @canal — salgo 18:00 UTC, Dana cubre hasta las 08:00

INCIDENTE: 500s en API de pagos — P2, mitigado con rollback 15:20.
Canal: #inc-payment-500s. Próximo: confirmar índice ~18:00.

VIGILAR: alerta de latencia sigue WARN (2h), disco >80% limpieza 02:00.

CAMBIOS: upgrade de k8s mañana 06:00 UTC — rollback probado.

NOTAS: el ticket #4521 de soporte (retraso de facturación) es ruido, no un bug.

Confirma con 👍 cuando lo leas. Escríbeme si algo no queda claro esta noche.

Los handoffs asíncronos funcionan en rotaciones rutinarias. Con un P1 activo, exige handoff síncrono: las preguntas que no puedes responder por chat son justo las que importan. Si tu equipo trabaja por tickets, las mismas secciones encajan en una issue de Jira o Linear; mira la Plantilla de Runbook On-Call para la estructura de runbook más amplia en la que esto encaja.

Handoffs Síncronos vs Asíncronos

Los handoffs síncronos capturan lo que los documentos se pierden. El ingeniero entrante escucha la duda en tu voz cuando describes una alerta de la que no estás seguro, y puede interrumpir con un “espera, ¿eso correla con el despliegue?” que por texto nunca ocurre. Por defecto, síncrono siempre que haya solapamiento.

Lo asíncrono es el plan B para huecos de zona horaria, y solo funciona con dos reglas: un documento escrito lo bastante completo para valerse por sí solo (la variante Slack de arriba, o la plantilla completa pegada en algún sitio persistente) y un plazo explícito de confirmación. “Confirma en 30 minutos” cubre el modo de fallo en el que nadie notó que el handoff ocurrió. Para lo ambiguo, una grabación de video (Loom o similar) recupera parte del beneficio del síncrono: el saliente narrando el dashboard vale más que el mismo texto dos veces.

Explicación

La plantilla estructura el handoff en incidentes (qué está roto), alertas (qué puede romperse), salud (estado actual) y cambios (qué viene). Dos secciones se ganan su sitio específicamente:

• Rutas de escalamiento existen para el ingeniero entrante que no sabe a quién llamar a las 3 AM. Sin ella, el primer P1 del turno empieza con quince minutos de “¿a quién pagueo?”
• Verificación de accesos suena trivial hasta que el entrante descubre a las 02:00 que su certificado de VPN caducó o que no ve el pipeline de despliegue. Verifica los accesos durante el handoff, mientras el saliente aún puede arreglarlo.

“Handoff” y “handover” significan lo mismo aquí: el primero es común en equipos de EE. UU., el segundo en equipos británicos o internacionales. Usa el que use tu organización; solo mantenlo consistente en los documentos para que la búsqueda los encuentre.

Medir la Calidad del Handoff

Un proceso de handoff que nunca se mide se degrada en silencio hasta volverse un ritual que nadie lee. Revisa los documentos de handoff cada semana en la reunión del equipo: destaca los buenos, señala los huecos y sé breve. Tres métricas te dicen si funciona:

• Incidentes perdidos tras el handoff: con qué frecuencia el entrante se sorprende por algo que el saliente sabía. Debería tender a cero.
• Tiempo hasta la primera respuesta tras el cambio de turno: si el nuevo guardia tarda notablemente más en responder la primera alerta, la transferencia de contexto está fallando.
• Confianza del ingeniero entrante: una encuesta mensual de una pregunta — “¿el handoff te dio suficiente contexto para manejar el turno?”. Barata de hacer y brutalmente honesta.

Usa las respuestas para podar la plantilla. Las secciones que vuelven vacías semana tras semana o son innecesarias o no se entienden; en cualquiera de los dos casos, arréglalas o bórralas. Las que siguen produciendo momentos de “eso no lo sabía” merecen quedarse.

Mantener la Plantilla Útil

Pon el documento donde la gente realmente mira durante un incidente. Un doc compartido por turno, un hilo continuo en el canal de on-call de Slack o una página en la herramienta de incidentes funcionan; un archivo en el portátil de alguien, no. Lo que elijas debe ser buscable: los handoffs se vuelven historial útil al depurar un problema recurrente semanas después.

Trata la plantilla como código: bajo control de versiones o en la wiki del equipo, con revisión trimestral, y que el revisor sea el ingeniero más nuevo de la rotación. Los ojos frescos detectan las secciones que dejaron de tener sentido hace dos reorganizaciones.

Checklist de Handoff

=== Checklist pre-handoff ===

[ ] Todos los incidentes activos documentados con estado y próximos pasos
[ ] Todas las alertas del turno revisadas con su disposición anotada
[ ] Enlace al dashboard de salud del sistema incluido (no un screenshot)
[ ] Cambios programados del próximo turno documentados
[ ] Problemas conocidos y soluciones temporales actualizados
[ ] Rutas de escalamiento verificadas (contactos aún válidos)
[ ] Accesos del ingeniero entrante confirmados (ver sección 7 de la plantilla)
[ ] Observaciones inusuales anotadas aunque no alerten
[ ] Solicitudes de otros equipos documentadas
[ ] El ingeniero entrante confirmó recepción del handoff

Una conversación de handoff síncrona toma unos veinte minutos:

Handoff Durante un Incidente Activo

El caso más difícil es un cambio de turno en medio de un P1 o P2. Los dos ingenieros están cansados, el contexto está repartido entre cinco herramientas y la tentación es saltarse el handoff por completo — así es como los incidentes se estancan una hora mientras el nuevo ingeniero se pone al día.

Haz un micro-handoff enfocado: pausa el incidente cinco minutos, corre solo las secciones 1, 6 y 7 de la plantilla (el incidente activo, contactos de escalamiento, verificación de accesos) y deja explícito quién es ahora el responsable. Sáltate lo rutinario: una alerta de disco puede esperar cuando los pagos están caídos. Escribe el micro-handoff en el propio canal del incidente, donde además sirve de entrada en la línea de tiempo del postmortem. Si el saliente está en medio de una sesión de debugging, mantenlo como secundario designado durante la primera hora en lugar de perder su contexto a mitad de hipótesis.

Variantes

Contexto	Enfoque	Notas
Entrega diaria	Versión abreviada (15 min)	Solo incidentes activos y alertas
Rotación semanal	Plantilla completa con retrospectiva	Incluir conteo de incidentes y tendencias de MTTR
Cobertura por vacaciones	Versión extendida	Añadir contexto de proyectos, reuniones y contactos de stakeholders
Handoff a mitad de incidente	Centrado en el incidente	Priorizar el incidente activo, posponer lo rutinario
Asíncrono / zonas horarias	Variante Slack de arriba	Documento escrito + plazo de confirmación, sin llamada

Lo Que Funciona

1. Haz los handoffs síncronos siempre que se pueda. Lo asíncrono se pierde las preguntas que importan.
2. Actualiza el documento durante el turno, no al final de memoria.
3. Enlaza, no describas. Pega URLs de dashboards, no capturas de métricas.
4. Escribe el “y qué” de cada alerta: por qué importa, no solo que saltó.
5. Pide confirmación explícita. “Lo leí” no es una confirmación; “tengo acceso y contexto” sí.

Errores Comunes

1. Cubrir solo los incidentes activos: los problemas que se cuecen son los P1 de mañana.
2. Copiar y pegar el texto de la alerta tal cual: inútil sin lo que ya investigaste.
3. Olvidar los cambios programados: el entrante se lleva la sorpresa de la ventana de mantenimiento.
4. Saltarse las rutas de escalamiento: minutos perdidos buscando a quién llamar durante un P1.
5. Entregar a mitad de incidente sin pausar: para cinco minutos a documentar, o el contexto se pierde en el ruido del debugging.
6. Asumir que los accesos funcionan: el fallo clásico es un entrante que no puede entrar en nada.

Después del Handoff

El trabajo del entrante no termina en el “confirmado”. En la primera hora: abre de verdad los dashboards y herramientas (no des por buena la verificación de accesos), repasa los canales de incidentes referenciados en el documento y pon recordatorios para los cambios programados, para que el upgrade de las 06:00 no sea una sorpresa a las 06:05.

El saliente tampoco ha terminado del todo. Quédate alcanzable la primera hora por si el modelo mental que transferiste tiene huecos, y vuelca en el runbook cualquier cosa que hayas explicado de voz y no estuviera ya escrita: si tuviste que decirla en alto, pertenece al documento.

• Google SRE Book — Being On-Call: el capítulo de referencia sobre guardias y disciplina de handoff.
• PagerDuty — Incident Response Guide: roles, severidades y convenciones de escalamiento que estas plantillas asumen.
• Atlassian — Incident Management Handbook: contexto de proceso más amplio para flujos de incidentes.
• NIST SP 800-61 — Incident Handling Guide: referencia formal de fases de incidente si tu organización necesita alineación de compliance.

Archivos complementarios: la plantilla en blanco y el ejemplo rellenado están en el repo complementario — cópialos directamente a tu wiki.