Una cultura de guardias que funciona: respuesta a incidentes sin quemar al equipo
La guardia es una de las formas más rápidas de hundir la moral de un equipo de ingeniería si se hace mal. Y la mayoría de las empresas la hacen mal.
Los síntomas son predecibles: las mismas dos personas reciben siempre los avisos porque nadie más «conoce el sistema lo bastante bien». Los ingenieros temen su semana de guardia. Los incidentes se repiten porque nadie ataca las causas raíz. Los mejores ingenieros se marchan, y no entiendes por qué tu retención es tan mala.
He llevado el busca durante años de respuesta a incidentes a escala enterprise, y puedo decirte que construir una cultura de guardia sana no es complicado. Hace falta pensar con claridad, unas pocas herramientas buenas y un liderazgo que trate la guardia como una responsabilidad de primer orden, no como algo accesorio.
SLA vs. SLO: saber qué estás gestionando en realidad
Antes de montar una rotación de guardia necesitas saber qué estás defendiendo. Y eso empieza por entender la diferencia entre SLA y SLO, porque la mayoría de los equipos los confunden.
El SLA (Service Level Agreement) es un contrato con tus clientes. «Garantizamos un 99,9% de disponibilidad. Si lo incumplimos, recibes créditos de servicio». Los SLA tienen consecuencias legales y financieras.
El SLO (Service Level Objective) es un objetivo interno más estricto que el SLA. Si tu SLA promete un 99,9%, tu SLO puede apuntar al 99,95%. El SLO te da un colchón — un error budget — antes de incumplir el SLA.
Con un SLO del 99,95% sobre una ventana móvil de 30 días, dispones de unos 21 minutos de caída permitida al mes. Mientras te quede presupuesto, lanza funcionalidades sin miedo. Cuando lo estés agotando, frena y prioriza la fiabilidad.
Por qué importa para la guardia: tus ingenieros de guardia deberían conocer los SLO que defienden y el estado actual del error budget. «Nos quedan 14 minutos de presupuesto este mes» crea urgencia. «Mantén el sistema en pie» es tan vago que no significa nada.
Una rotación sostenible empieza en cuatro personas
El error más habitual con la guardia es hacerla demasiado gravosa para cada persona. Esto es lo que funciona en equipos de 5-8 ingenieros, el tamaño típico de una startup:
Rotación semanal con un único primario. Una persona atiende todos los avisos durante una semana (de lunes a lunes). Simple y eficaz si hay suficiente gente en la rotación.
La rotación mínima viable son 4 personas. Con menos de 4, cada persona está de guardia más del 25% del tiempo: insostenible. Con 5-6 consigues una cadencia cómoda de una semana de cada cinco.
Follow-the-sun para equipos distribuidos. Los ingenieros de Europa cubren de 08:00 a 20:00 CET y América cubre el resto. Nadie pierde horas de sueño. Es una de las ventajas reales de los equipos distribuidos.
Guardia secundaria como escalado. Si el primario no resuelve en 30-60 minutos, el incidente escala al secundario, alguien con un conocimiento más profundo del sistema. Rota ambos roles.
Regla innegociable: a la persona de guardia no se le exige el trabajo normal del sprint al mismo ritmo. Estar de guardia significa ser interrumpible. Si además esperas que cierre 8 puntos de historia, la estás condenando a hacer mal las dos cosas.
La base de herramientas son cuatro, no una plataforma
No necesitas una gran inversión en herramientas, pero sí lo básico:
Alertas y avisos: PagerDuty u Opsgenie. Se encargan del enrutado de alertas, las políticas de escalado, los calendarios y las sustituciones de guardia. PagerDuty es el estándar del sector. Opsgenie (hoy parte de Atlassian) es una alternativa sólida y más barata. No confíes en notificaciones de Slack ni en el correo para avisar. La gente silencia Slack. Los correos pasan desapercibidos. Una llamada de PagerDuty a las 3 de la madrugada no se ignora.
Runbooks: por cada alerta que despierta a alguien debería existir un runbook. Un runbook es un documento que responde: ¿qué significa esta alerta? ¿Cuál es la causa probable? ¿Cuáles son las tres primeras comprobaciones? ¿Cómo se mitiga? ¿Dónde están los logs y los dashboards? Un runbook convierte 45 minutos de pánico en un diagnóstico de 10 minutos. Guárdalos en la wiki y enlázalos directamente desde la alerta.
Página de estado: Statuspage (Atlassian), Instatus o incluso una página estática sencilla. Cuando algo se cae, tus clientes deberían enterarse por tu página de estado, no al intentar usar el producto y toparse con el fallo. El ingeniero de guardia debe poder actualizarla en menos de un minuto.
Canal de incidentes: un canal de Slack (o equivalente) dedicado que se crea automáticamente para cada incidente. Toda la comunicación sobre el incidente sucede allí. Nada de mensajes directos ni hilos paralelos. Eso genera una cronología automática que vale oro en el postmortem.
Postmortems sin culpa: cómo hacer uno de verdad
«Postmortem sin culpa» se ha convertido en una etiqueta que muchos equipos dicen practicar y pocos practican de verdad. Uno real tiene este aspecto:
Cuándo: en las 48 horas siguientes a la resolución. Si esperas una semana, la gente olvida los detalles.
Quién asiste: todos los implicados en el incidente, más cualquiera que quiera aprender.
Estructura:
- Reconstrucción de la cronología. Qué pasó y en qué orden, desde la primera señal hasta la resolución.
- Análisis de la causa raíz. No «quién metió la pata», sino «¿qué permitió en el sistema que esto ocurriera?». Un error humano nunca es la causa raíz; lo es el sistema que dejó que llegara a producción.
- Factores contribuyentes. ¿Qué retrasó la detección? ¿Qué dificultó la resolución?
- Acciones. Concretas, asignadas y con fecha. «Mejorar la monitorización» no es una acción. «Añadir una alerta cuando la tasa de error de pagos supere el 2% durante 5 minutos, asignada a Sofía, para el 15 de septiembre» sí lo es.
El elemento cultural crítico: nadie es castigado por un incidente. Si la gente teme la culpa, esconde información. Si esconde información, no puedes aprender. Y si no puedes aprender, los incidentes se repiten.
Compensar la guardia como es debido
En esto no pienso ceder: si no compensas a los ingenieros de guardia, no tienes una rotación; tienes explotación.
Estar de guardia condiciona tu vida personal. No puedes irte de acampada sin cobertura. Tienes el portátil siempre a mano. Hacer como si fuera «parte del trabajo y ya está» es la manera de perder a tu mejor gente.
Conozco el contraargumento: los salarios senior ya lo llevan incorporado. A veces es así — y si ese es tu modelo, perfecto, pero ponlo por escrito en el contrato. La compensación implícita no es más que trabajo no pagado con pasos de más.
Modelos de compensación que funcionan:
- Plus fijo por turno de guardia. 200-500 EUR por semana, te avisen o no.
- Bonificación por incidente. Compensación adicional por cada intervención real fuera de horario.
- Descanso compensatorio. ¿Aviso a las 3 de la madrugada y dos horas de trabajo? Medio día libre al día siguiente. Innegociable.
- Combinación. Plus fijo + descanso compensatorio es el modelo más común y el más equitativo.
Lo importante es que sea explícito, que figure en el contrato laboral y que se aplique con consistencia.
Señales de que tu cultura de guardia está rota
Si algo de esto te suena, tienes trabajo por delante:
- La gente teme su semana de guardia. No es una molestia leve: es pavor real. Lo sacan en los 1:1 y se intercambian turnos constantemente.
- Siempre avisan a la misma persona. Silo de conocimiento o alertas mal configuradas; en ambos casos, insostenible.
- Los incidentes se repiten. El mismo fallo cada pocas semanas. Las acciones del postmortem nunca se priorizan.
- Ni compensación ni reconocimiento. La guardia se da por hecha pero es invisible.
- La guardia se usa como novatada. Los ingenieros nuevos entran en la rotación antes de entender el sistema.
- No hay runbooks. Cada incidente es una investigación desde cero.
Todo esto tiene arreglo, y ninguno de los arreglos exige un gran presupuesto. Si este fuera mi equipo, esto es lo que haría este trimestre:
- Auditar cada alerta que avisa a un humano. Si no tiene runbook, escribirlo o dejar de avisar con ella.
- Llevar la rotación a un mínimo de cuatro personas y dejar la ruta de escalado por escrito.
- Meter la compensación de guardia en el contrato laboral: plus, descanso compensatorio o ambos.
- Hacer un postmortem sin culpa en las 48 horas siguientes al próximo incidente, con acciones asignadas y fechadas.
Lo que las cuatro exigen es un liderazgo que se tome la salud operacional tan en serio como la entrega de funcionalidades.
En Conectia, los ingenieros senior que integramos en tus equipos han vivido culturas de guardia buenas y terribles. Aportan madurez operacional: escriben runbooks, montan un buen sistema de alertas y construyen la automatización que previene incidentes en lugar de limitarse a responderlos. Cuando en tu equipo hay gente que trata la fiabilidad en producción como un oficio, la guardia deja de ser una carga y pasa a ser una parte normal y bien gestionada de la vida de ingeniería.
¿Necesitas ingenieros que construyan sistemas fiables, no solo funcionalidades? Habla con un CTO — nuestros ingenieros senior de LATAM aportan la madurez operacional que convierte la guardia de obligación temida en práctica sostenible.
