10 min lectura • Guide 751 of 877
Gestión de Guardias con GitScrum
Las guardias no deberían agotar a tu equipo. GitScrum ayuda a gestionar tareas de guardia, rastrear incidentes y asegurar una rotación justa de responsabilidades.
Fundamentos de las Guardias
Por Qué Existen las Guardias
PROPÓSITO Y OBJETIVOS DE LAS GUARDIAS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PROPÓSITO: │
│ Asegurar que alguien esté siempre disponible para │
│ responder a problemas de producción que afectan usuarios. │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ GUARDIA SALUDABLE: │
│ │
│ ✅ Rotación justa entre el equipo │
│ ✅ Expectativas claras y runbooks │
│ ✅ Compensación apropiada │
│ ✅ Baja tasa de falsas alarmas │
│ ✅ Carga de trabajo sostenible │
│ ✅ Aprendizaje de incidentes │
│ │
│ GUARDIA NO SALUDABLE: │
│ │
│ ❌ Siempre las mismas personas de guardia │
│ ❌ Falsas alarmas constantes (fatiga de alertas) │
│ ❌ Sin documentación ni runbooks │
│ ❌ Se espera que arregles todo solo │
│ ❌ Sin compensación de tiempo │
│ ❌ Burnout y deserción │
│ │
│ PRINCIPIO DE GUARDIA: │
│ Si lo construyes, lo operas │
│ El equipo es dueño de sus servicios de punta a punta │
│ Crea responsabilidad y mejor diseño │
└─────────────────────────────────────────────────────────────┘
Configuración de Rotación
Construyendo el Horario
DISEÑO DE ROTACIÓN DE GUARDIA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ OPCIONES DE ROTACIÓN: │
│ │
│ ROTACIÓN SEMANAL: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Sem 1: @alex (primario) / @maria (secundario) ││
│ │ Sem 2: @maria (primario) / @jordan (secundario) ││
│ │ Sem 3: @jordan (primario) / @chen (secundario) ││
│ │ Sem 4: @chen (primario) / @alex (secundario) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Mejor para: Equipos más grandes, menor volumen de alertas │
│ │
│ ROTACIÓN DIARIA: │
│ Cada persona de guardia por 1-2 días │
│ Mejor para: Alto volumen de alertas, más personas │
│ │
│ FOLLOW-THE-SUN: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 00:00-08:00 UTC: Equipo APAC ││
│ │ 08:00-16:00 UTC: Equipo EMEA ││
│ │ 16:00-00:00 UTC: Equipo Américas ││
│ └─────────────────────────────────────────────────────────┘│
│ Mejor para: Equipos globales, sin turnos nocturnos │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REGLAS DE EQUIDAD: │
│ │
│ • Rotar equitativamente (rastrear en hoja de cálculo) │
│ • Sin turnos consecutivos sin consentimiento │
│ • Guardia feriado/fin semana = consideración extra │
│ • Permitir intercambios de turno │
│ • Nuevos miembros acompañan antes de ir solos │
│ • Compensar apropiadamente │
└─────────────────────────────────────────────────────────────┘
Ruta de Escalamiento
ESTRUCTURA DE ESCALAMIENTO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ NIVEL 1: Guardia Primario │
│ ↓ (si no hay respuesta en 15 min) │
│ │
│ NIVEL 2: Guardia Secundario │
│ ↓ (si no hay respuesta en 15 min) │
│ │
│ NIVEL 3: Líder de Equipo / Gerente │
│ ↓ (si SEV 1 o impacto en negocio) │
│ │
│ NIVEL 4: VP Ingeniería / Ejecutivo │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REGLAS DE ESCALAMIENTO: │
│ │
│ AUTO-ESCALAR CUANDO: │
│ • Sin reconocimiento en 15 minutos │
│ • Duración del incidente > 30 minutos │
│ • SEV 1 (siempre notificar liderazgo) │
│ • Problema reportado por cliente │
│ │
│ EL PRIMARIO DEBE ESCALAR CUANDO: │
│ • Fuera de su experiencia │
│ • Necesita manos adicionales │
│ • El impacto está creciendo │
│ • No puede resolver solo │
│ │
│ NO HACER: │
│ • Dudar en escalar │
│ • Tratar de ser un héroe │
│ • Esperar demasiado │
└─────────────────────────────────────────────────────────────┘
Preparación para Guardias
Runbooks
ESENCIALES DE RUNBOOKS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CADA SERVICIO NECESITA RUNBOOKS: │
│ │
│ PLANTILLA DE RUNBOOK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Servicio: API de Pagos ││
│ │ Dueño: Equipo de Pagos ││
│ │ Guardia: payments-oncall@empresa.com ││
│ │ ││
│ │ ═══════════════════════════════════════════════════════ ││
│ │ ││
│ │ ALERTAS COMUNES: ││
│ │ ││
│ │ Alerta: payment-api-error-rate-high ││
│ │ ───────────────────────────────────────── ││
│ │ Qué: Tasa de error > 5% ││
│ │ Por qué: Solicitudes de pago fallando ││
│ │ ││
│ │ Pasos: ││
│ │ 1. Revisar dashboard: [enlace] ││
│ │ 2. Revisar deploys recientes: [enlace] ││
│ │ 3. Revisar downstream: Estado Stripe [enlace] ││
│ │ 4. Revisar base de datos: pool de conexiones [enlace] ││
│ │ ││
│ │ Causas comunes: ││
│ │ • Caída de Stripe → esperar o failover ││
│ │ • Base de datos llena → escalar o limpiar ││
│ │ • Deploy malo → rollback ││
│ │ ││
│ │ Rollback: kubectl rollout undo deploy/payment-api ││
│ │ ││
│ │ Escalar si: No se identifica causa en 30 min ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MANTENER RUNBOOKS: │
│ • Actualizados (revisar trimestralmente) │
│ • Accesibles (no detrás de VPN) │
│ • Accionables (pasos, no solo info) │
│ • Enlazados en alertas │
└─────────────────────────────────────────────────────────────┘
Kit de Herramientas de Guardia
EL INGENIERO DE GUARDIA NECESITA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ACCESO (Verificado antes de que comience la rotación): │
│ │
│ ☐ Dashboards de monitoreo (Datadog, Grafana, etc.) │
│ ☐ Sistema de alertas (PagerDuty, Opsgenie, etc.) │
│ ☐ Consola cloud (AWS, GCP, Azure) │
│ ☐ Herramientas de despliegue (kubectl, CI/CD) │
│ ☐ Acceso a base de datos (lectura como mínimo) │
│ ☐ Agregación de logs (Splunk, ELK, etc.) │
│ ☐ Comunicación (Slack, canal de incidentes) │
│ ☐ Página de estado (para publicar actualizaciones) │
│ ☐ Runbooks (wiki, Notion, etc.) │
│ │
│ DOCUMENTACIÓN: │
│ │
│ ☐ Runbooks para todos los servicios │
│ ☐ Diagramas de arquitectura │
│ ☐ Contactos de escalamiento │
│ ☐ Contactos de soporte de proveedores │
│ ☐ Post-mortems de incidentes anteriores │
│ │
│ HERRAMIENTAS: │
│ │
│ ☐ Laptop con VPN │
│ ☐ Móvil con app de alertas │
│ ☐ Cargador y batería de respaldo │
│ ☐ Internet confiable (o hotspot de respaldo) │
│ │
│ ANTES DEL TURNO: │
│ • Verificar acceso a todas las herramientas │
│ • Revisar incidentes pendientes │
│ • Revisar cambios/deploys recientes │
│ • Confirmar contactos de escalamiento │
└─────────────────────────────────────────────────────────────┘
Planificación de Sprint con Guardia
Ajuste de Capacidad
CAPACIDAD DE GUARDIA EN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CONSIDERACIÓN EN PLANIFICACIÓN DE SPRINT: │
│ │
│ CAPACIDAD NORMAL: 28 puntos │
│ │
│ AJUSTES DE GUARDIA: │
│ │
│ Semana completa de guardia: │
│ • -25% a -50% capacidad según volumen de alertas │
│ • @jordan: 28 pts → 14-21 pts │
│ │
│ Media semana de guardia: │
│ • -10% a -25% capacidad │
│ • @alex: 28 pts → 21-25 pts │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ VISTA DEL SPRINT: │
│ │
│ @alex [██████████████████████░░░] 24 pts (4 pts guardia)│
│ @maria [████████████████████████░] 28 pts │
│ @jordan [██████████████░░░░░░░░░░░] 18 pts (10 pts guard.)│
│ @chen [████████████████████████░] 28 pts │
│ │
│ Total: 98 pts (vs 112 estándar) │
│ │
│ TAREAS DE GUARDIA: │
│ • Columna o etiqueta separada │
│ • No contar contra velocity │
│ • Rastrear para visibilidad de carga │
│ │
│ PRESUPUESTO DE GUARDIA DEL SPRINT: │
│ Reservar 10% de capacidad para incidentes inesperados │
│ Si no se usa, traer trabajo adicional │
└─────────────────────────────────────────────────────────────┘
Traspaso de Guardia
PROCESO DE TRASPASO DE ROTACIÓN:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ANTES DE QUE TERMINE EL TURNO: │
│ │
│ EL GUARDIA SALIENTE PROPORCIONA: │
│ │
│ 1. PROBLEMAS ACTIVOS │
│ • Incidentes abiertos │
│ • Problemas en curso │
│ • Cosas a vigilar │
│ │
│ 2. CAMBIOS RECIENTES │
│ • Deploys de esta semana │
│ • Cambios de configuración │
│ • Nuevas funcionalidades lanzadas │
│ │
│ 3. RIESGOS PRÓXIMOS │
│ • Mantenimiento planificado │
│ • Eventos grandes de clientes │
│ • Deploys riesgosos conocidos │
│ │
│ 4. APRENDIZAJES │
│ • Nuevas entradas de runbook │
│ • Problemas descubiertos │
│ • Tips útiles │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REUNIÓN DE TRASPASO (15 min): │
│ │
│ • Llamada sincrónica o traspaso escrito │
│ • Documentar en Slack/wiki │
│ • Confirmar que entrante tiene acceso │
│ • Transferir pager/enrutamiento de alertas │
│ • Entrante confirma que está listo │
│ │
│ GITSCRUM: │
│ Nota de traspaso enlazada al registro de rotación │
└─────────────────────────────────────────────────────────────┘
Sostenibilidad
Previniendo el Burnout
PRÁCTICAS SOSTENIBLES DE GUARDIA:
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRICAS A MONITOREAR: │
│ │
│ Alertas por turno: │
│ Objetivo: < 5 por semana │
│ Actual: 8 ⚠️ (investigar alertas ruidosas) │
│ │
│ Alertas fuera de horario: │
│ Objetivo: < 2 por semana │
│ Actual: 4 ⚠️ (priorizar automatización) │
│ │
│ Tasa de falsos positivos: │
│ Objetivo: < 10% │
│ Actual: 25% ❌ (arreglar alertas) │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ REDUCIENDO CARGA DE GUARDIA: │
│ │
│ ARREGLAR ALERTAS RUIDOSAS: │
│ • Revisar todas las alertas trimestralmente │
│ • Eliminar o arreglar alertas de bajo valor │
│ • Ajustar umbrales │
│ • Agregar automatización para arreglos comunes │
│ │
│ MEJORAR CONFIABILIDAD: │
│ • Arreglar causas raíz, no solo síntomas │
│ • Invertir en infraestructura │
│ • Mejor testing y canaries │
│ • Ingeniería del caos │
│ │
│ APOYAR LA GUARDIA: │
│ • Compensar justamente │
│ • Permitir recuperación de tiempo después de turnos duros │
│ • Celebrar semanas tranquilas │
│ • El liderazgo también hace guardia │
│ │
│ TAMAÑO DEL EQUIPO: │
│ Mínimo 4-5 personas para rotación sostenible │
│ Menos = turnos muy frecuentes │
└─────────────────────────────────────────────────────────────┘