Plantilla de Entrega de Guardia (On-Call Handoff)

Overview

Las entregas de guardia deficientes son una causa principal de escalamiento de incidentes. Cuando se pierde el contexto entre turnos, el ingeniero entrante pierde minutos preciosos redescubriendo lo que el ingeniente saliente ya sabia. Esta plantilla estandariza el proceso de entrega, asegurando que la informacion critica sobre incidentes activos, alertas en curso y estado del sistema se transfiera completamente y consistentemente.

When to Use

• For alternatives, see Incident Communication Template.

Usa esta plantilla cuando:

• Transfieres responsabilidad de guardia entre turnos o miembros del equipo
• Te vas de vacaciones o licencia extendida con cobertura de guardia
• Entregas durante un incidente prolongado que abarca multiples turnos
• Rotas responsabilidades de guardia semanalmente o quincenalmente

Prerequisites

Antes de la entrega:

• El ingeniero saliente revisa todas las alertas e incidentes activos
• Los runbooks para problemas en curso se actualizan con los ultimos hallazgos
• El historial del canal de incidente se resume para contexto
• Los cambios programados o despliegues proximos se anotan

Solution

# Reporte de Entrega de Guardia

## Metadatos de la Entrega

| Campo | Valor |
|-------|-------|
| Ingeniero saliente | ______ |
| Ingeniero entrante | ______ |
| Fecha/hora de entrega | ______ |
| Duracion del turno | ______ |

## 1. Incidentes Activos

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

**Resumen:**
Parrafo de una oracion describiendo que paso, que se ha intentado y estado actual.

**Proximos pasos:**
- [ ] Item de accion 1 (responsable: ______, fecha limite: ______)
- [ ] Item de accion 2 (responsable: ______, fecha limite: ______)

**Runbook / Referencia:**
Enlace al runbook o guia de troubleshooting relevante.

---

### Incidente #2: `<Titulo>`
(Misma estructura que arriba)

## 2. Alertas y Advertencias en Curso

| Alerta | Estado | Vista por Primera Vez | Notas |
|--------|--------|----------------------|-------|
| Alta latencia en API | WARN | hace 2 horas | Correlaciona con pico de trafico, no util aun |
| Uso de disco > 80% | WARN | hace 1 dia | Limpieza programada para esta noche |
| Lag de replicacion > 5s | OK | Recien resuelto | Auto-resuelto despues de reconstruccion de indice |

## 3. Resumen de Salud del Sistema

| Componente | Estado | Notas |
|------------|--------|-------|
| Latencia p95 de API | Saludable / Degradado / Critico | Valor actual: ______ |
| Tasa de error | Saludable / Degradado / Critico | Valor actual: ______ |
| Conexiones de base de datos | Saludable / Degradado / Critico | Valor actual: ______ |
| Profundidad de cola | Saludable / Degradado / Critico | Valor actual: ______ |
| Tasa de aciertos de cache | Saludable / Degradado / Critico | Valor actual: ______ |
| Uso de disco | Saludable / Degradado / Critico | Valor actual: ______ |

## 4. Cambios y Despliegues

### Completados Este Turno
| Cambio | Hora | Estado | Impacto |
|--------|------|--------|---------|
| Reconstruccion de indice de base de datos | 02:00 UTC | Exito | Redujo tiempo de consulta en 40% |
| Actualizacion de config de caching | 14:30 UTC | Exito | Sin impacto observado |

### Programados para el Proximo Turno
| Cambio | Hora | Riesgo | Preparado? |
|--------|------|--------|------------|
| Actualizacion de Kubernetes | 06:00 UTC | Medio | Rollback probado, guardia informada |
| Renovacion de certificado SSL | 10:00 UTC | Bajo | Auto-renovacion configurada |

## 5. Problemas Conocidos y Soluciones Temporales

| Problema | Solucion Temporal | Ticket | Prioridad |
|----------|---------------------|--------|-----------|
| Fuga de memoria en proceso worker | Reiniciar cada 6 horas | INC-123 | Media |
| Test flaky en pipeline de CI | Reintentar trabajo fallido | DEV-456 | Baja |

## 6. Rutas de Escalamiento

| Escenario | Escalar A | Contacto |
|-----------|-----------|----------|
| Incidente P1 > 30 min | Gerente de Ingenieria | Slack / Telefono |
| Incidente de seguridad | Equipo de Seguridad | PagerDuty |
| Interrupcion de infraestructura | Equipo de Plataforma | Slack / Telefono |
| Problema de integridad de datos | DBA de guardia | PagerDuty |

## 7. Notas y Contexto

**Observaciones inusuales este turno:**
- Cualquier anomalia que no llegue a nivel de alerta pero podria ser precursora de problemas

**Solicitudes de otros equipos:**
- Cualquier peticion no urgente que llego durante el turno

**Recordatorios generales:**
- Cualquier contexto especifico del equipo que el ingeniero entrante deberia saber

Explanation

La plantilla estructura la entrega en incidentes (que esta roto), alertas (que podria romperse), salud (estado actual) y cambios (lo que viene). La seccion de ruta de escalamiento es critica para el ingeniero entrante que puede no saber a quien llamar a las 3 AM. La seccion de notas captura el contexto sutil que no encaja en otras categorias pero puede prevenir sorpresas.

Checklist de Handoff

=== Checklist Pre-Handoff ===

[ ] Todos los incidentes activos documentados con estado actual y proximos pasos
[ ] Todas las alertas de este turno revisadas y disposicion anotada
[ ] Screenshot o link del dashboard de salud del sistema incluido
[ ] Cambios programados para el proximo turno documentados
[ ] Problemas conocidos y workarounds actualizados
[ ] Rutas de escalacion verificadas (contactos aun validos)
[ ] Observaciones inusuales anotadas incluso si no estan alertando
[ ] Peticiones de otros equipos documentadas
[ ] Cronograma de PagerDuty confirmado para el ingeniero entrante
[ ] El ingeniero entrante ha reconocido la recepcion del handoff

=== Flujo de Conversacion de Handoff ===

1. Revisar incidentes activos primero (5 min)
2. Revisar alertas que pueden escalar (3 min)
3. Revisar salud del sistema juntos (2 min)
4. Discutir cambios programados (2 min)
5. Revisar problemas conocidos (2 min)
6. Compartir observaciones inusuales (1 min)
7. El ingeniero entrante hace preguntas (5 min)
8. Ambos confirman que el handoff esta completo

Variants

Contexto	Enfoque	Notas
Entrega diaria de turno	Version abreviada (15 min)	Enfocarse solo en incidentes activos y alertas
Rotacion semanal	Plantilla completa con retrospectiva	Incluir conteo de incidentes, tendencias de MTTR
Cobertura de vacaciones	Version extendida	Agregar contexto de proyecto, calendario de reuniones, contactos de stakeholders
Entrega a mitad de incidente	Enfocado en incidente	Analisis profundo del incidente activo, de-priorizar items rutinarios

Lo que funciona

1. Realizar entregas de forma sincronica — las entregas asincronicas pierden preguntas y matices
2. Actualizar la plantilla en tiempo real — no la reconstruyas de memoria al final del turno
3. Enlazar, no describir — pega enlaces a dashboards, no capturas de pantalla de metricas
4. Incluye el “entonces que” — explica por que importa una alerta, no solo que existe
5. Verificar el acuse de recibo del ingeniero entrante — confirma que tiene acceso y entiende el contexto

Common Mistakes

1. Solo cubrir incidentes activos — pierde problemas en gestacion que se convertiran en incidentes
2. Copiar y pegar descripciones de alertas — no proporciona contexto sobre lo que se ha investigado
3. No mencionar cambios programados — el ingeniero entrante se sorprende con ventanas de mantenimiento
4. Saltar la ruta de escalamiento — pierde minutos encontrando a quien llamar durante un P1
5. Entregar durante un incidente activo — la transferencia de contexto mientras se depura es incompleta; pausa la investigacion por 5 minutos para documentar

Troubleshooting

• Pipeline fails silently: enable verbose logging and store pipeline artifacts between stages so you can inspect the exact state that failed.
• Container crashes on startup: check that environment variables, secrets, and config files are mounted correctly. Read the first 50 lines of logs before scaling replicas.
• Deployment rolls back repeatedly: verify health checks, resource limits, and startup probes. A failing readiness probe is a common cause of rolling restarts.
• Slow CI builds: cache dependencies and docker layers. Split large test suites into parallel jobs to reduce wall-clock time.
• Drift between environments: use infrastructure-as-code and immutable artifacts.

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de on-call y runbook para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica plantilla de entrega de guardia (on-call handoff) cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

Errores Comunes en Producción

• Dejar campos requeridos vacíos o usar respuestas vagas de una palabra.
• Llenar el documento una vez y nunca actualizarlo cuando cambia el alcance o las decisiones.
• Guardar el documento donde el equipo no lo busque durante incidentes o revisiones.
• No asignar un responsable, fecha límite o cadencia de revisión.
• Copiar texto base sin eliminar secciones que no aplican.
• Saltar el control de versiones, lo que impide rollback y responsabilidad.
• No vincular el documento con decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.