Cultura de Guardia Bien Hecha: Respuesta a Incidentes Sin Agotamiento
La guardia es una de las formas más rápidas de destruir la moral de un equipo de ingeniería si la haces mal. Y la mayoría de las empresas la hacen mal.
Los síntomas son predecibles: las mismas dos personas reciben siempre las alertas porque nadie más "conoce el sistema lo suficientemente bien." Los ingenieros temen sus semanas de guardia. Los incidentes se repiten porque nadie arregla las causas raíz. Los mejores ingenieros se van y no puedes entender por qué tu retención es terrible.
Construir una cultura de guardia saludable no es complicado. Requiere pensamiento claro, algunas buenas herramientas y un liderazgo que trate la guardia como una responsabilidad de primera clase, no como algo secundario.
SLAs vs. SLOs: Saber Qué Estás Gestionando
Antes de construir una rotación de guardia, necesitas saber qué estás defendiendo. Esto empieza entendiendo la diferencia entre SLAs y SLOs, porque la mayoría de los equipos los confunden.
SLA (Service Level Agreement) es un contrato con tus clientes. "Garantizamos un 99,9% de disponibilidad. Si lo incumplimos, recibes créditos." Los SLAs tienen consecuencias legales y financieras.
SLO (Service Level Objective) es un objetivo interno más estricto que el SLA. Si tu SLA promete un 99,9%, tu SLO podría apuntar al 99,95%. El SLO te da un margen — un error budget — antes de incumplir el SLA.
Si tu SLO es del 99,95% en una ventana de 30 días, tienes aproximadamente 21 minutos de tiempo de inactividad permitido al mes. Cuando estás dentro del presupuesto, lanza funciones agresivamente. Cuando lo estás consumiendo, frena y prioriza la fiabilidad.
Por qué importa para la guardia: tus ingenieros de guardia deben conocer los SLOs que están defendiendo y el estado actual del error budget. "Tenemos 14 minutos de presupuesto restantes este mes" crea urgencia. "Mantén el sistema en funcionamiento" es tan vago que carece de sentido.
Patrones de Rotación para Equipos Pequeños
El error más común con la guardia es hacer que sea demasiado onerosa para los individuos. Esto funciona para equipos de 5-8 ingenieros, el tamaño típico en startups:
Rotación semanal, un único responsable principal. Una persona gestiona todas las alertas durante una semana (lunes a lunes). Simple y efectivo con suficientes personas en la rotación.
La rotación mínima viable es de 4 personas. Menos de 4 significa que cada persona está de guardia más del 25% del tiempo — insostenible. Con 5-6, obtienes una cómoda cadencia de una semana de cada cinco.
Follow-the-sun para equipos distribuidos. Los ingenieros en Europa cubren de 08:00 a 20:00 CET, América cubre el resto. Nadie pierde el sueño. Esta es una de las ventajas reales de los equipos distribuidos.
Guardia secundaria como escalada. Si el responsable principal no puede resolver en 30-60 minutos, escala al secundario — alguien con conocimiento más profundo del sistema. Rota ambos roles.
Regla firme: no se espera que la persona de guardia haga el trabajo normal del sprint a la misma capacidad. Estar de guardia significa ser interrumpible. Si además esperas que cierre 8 story points, los estás configurando para hacer ambas cosas mal.
El Equipamiento Básico
No necesitas una gran inversión en herramientas, pero sí necesitas los básicos:
Alertas y paginación: PagerDuty u Opsgenie. Gestionan el enrutamiento de alertas, las políticas de escalada, los calendarios y las sustituciones de guardia. PagerDuty es el estándar de la industria. Opsgenie (ahora parte de Atlassian) es una alternativa sólida y más económica. No dependas de notificaciones de Slack o correo electrónico para las alertas. La gente silencia Slack. La gente se pierde los correos. Una llamada telefónica a las 3 AM de PagerDuty no se ignora.
Runbooks: Para cada alerta que llama a alguien, debe haber un runbook. Un runbook es un documento que responde: ¿Qué significa esta alerta? ¿Cuál es la causa probable? ¿Cuáles son las primeras 3 cosas que revisar? ¿Cómo lo mitigas? ¿Dónde están los logs y los dashboards? Un runbook convierte una sesión de pánico de 45 minutos en un diagnóstico de 10 minutos. Guárdalos en tu wiki, vincúlalos directamente en la alerta.
Página de estado: Statuspage (Atlassian), Instatus o incluso una página estática simple. Cuando algo está caído, tus clientes deben enterarse por tu página de estado, no por intentar usar el producto y fallar. El ingeniero de guardia debe poder actualizar la página de estado en menos de un minuto.
Canal de incidentes: Un canal dedicado de Slack (o equivalente) que se crea automáticamente para cada incidente. Toda la comunicación sobre el incidente ocurre allí. Sin mensajes directos, sin hilos paralelos. Esto crea una línea de tiempo automática invaluable para el postmortem.
Postmortems Sin Culpa: Cómo Hacerlos de Verdad
"Postmortem sin culpa" se ha convertido en una palabra de moda que muchos equipos dicen practicar y pocos practican realmente. Así es como se ve uno real:
Momento: Dentro de las 48 horas posteriores a la resolución. Espera una semana y la gente olvida los detalles.
Asistentes: Todos los involucrados en el incidente, más cualquiera que quiera aprender.
Estructura:
- Reconstrucción de la línea de tiempo. Qué pasó, en qué orden, desde la primera señal hasta la resolución.
- Análisis de causa raíz. No "quién la cagó" sino "¿qué en el sistema permitió que esto sucediera?" Un error humano nunca es la causa raíz — lo es el sistema que lo dejó llegar a producción.
- Factores contribuyentes. ¿Qué ralentizó la detección? ¿Qué dificultó la resolución?
- Elementos de acción. Concretos, asignados, con fechas límite. "Mejorar el monitoreo" no es un elemento de acción. "Añadir una alerta en la tasa de error de pagos que supere el 2% durante 5 minutos, asignada a Sofia, fecha límite 15 de septiembre" sí lo es.
El elemento cultural crítico: nadie recibe castigo por los incidentes. Si la gente teme el reproche, oculta información. Si ocultan información, no puedes aprender. Si no puedes aprender, los incidentes se repiten.
Compensar la Guardia Adecuadamente
Esta es la causa por la que lucharé siempre: si no compensas a los ingenieros de guardia, no tienes una rotación — tienes explotación.
Estar de guardia limita tu tiempo personal. No puedes ir a acampar sin cobertura. Mantienes tu portátil accesible. Pretender que es "simplemente parte del trabajo" es cómo pierdes a tus mejores personas.
Modelos de compensación que funcionan:
- Subsidio fijo por turno de guardia. 200-500 EUR por semana, independientemente de si recibes alertas.
- Bonificación por incidente. Compensación adicional por respuestas reales fuera del horario laboral.
- Tiempo libre compensatorio. ¿Alerta a las 3 AM durante 2 horas? Medio día libre al día siguiente. No negociable.
- Combinación. Subsidio + tiempo libre compensatorio es el modelo más común y equitativo.
Lo que importa es que sea explícito, en el contrato laboral y aplicado de manera consistente.
Señales de que tu Cultura de Guardia Está Rota
Si cualquiera de estos te suena familiar, tienes trabajo por hacer:
- La gente teme las semanas de guardia. No una leve molestia — verdadero miedo. Lo mencionan en las 1:1 y cambian turnos constantemente.
- Siempre llaman a la misma persona. Silo de conocimiento o alertas mal configuradas — de cualquier manera, es insostenible.
- Los incidentes se repiten. El mismo fallo cada pocas semanas. Los elementos de acción del postmortem nunca se priorizan.
- Sin compensación ni reconocimiento. La guardia se espera pero es invisible.
- La guardia se usa como novatada. Los nuevos ingenieros entran en guardia antes de entender el sistema.
- No hay runbooks. Cada incidente es una investigación fresca desde cero.
Todo esto es solucionable. Requiere un liderazgo que tome la salud operacional tan en serio como la entrega de funciones.
En Conectia, los ingenieros senior que integramos en tus equipos han vivido culturas de guardia buenas y terribles. Traen madurez operacional — escribiendo runbooks, configurando alertas adecuadas, construyendo la automatización que previene incidentes en lugar de solo responder a ellos. Cuando tu equipo tiene personas que tratan la fiabilidad en producción como un oficio, la guardia deja de ser una carga y se convierte en una parte normal y bien gestionada de la vida de ingeniería.
¿Necesitas ingenieros que construyan sistemas fiables, no solo funciones? Habla con un CTO — nuestros ingenieros senior de LATAM aportan la madurez operacional que convierte la guardia de una obligación temida en una práctica sostenible.
