Guardias y postmortems sin culpa para equipos pequeños

En un equipo de tres o cuatro personas, la guardia suele armarse sola: la alerta le llega a quien instaló el sistema, a cualquier hora, y nadie anota qué pasó. Al tercer mes esa persona está cansada, las alertas se ignoran y el mismo incidente vuelve a ocurrir.

Las referencias más usadas sobre guardias e incidentes son los libros de SRE de Google (Site Reliability Engineering y The Site Reliability Workbook), la documentación de respuesta a incidentes de PagerDuty, publicada con licencia Apache 2.0, y el manual de incidentes de Atlassian. Están escritos por empresas grandes, pero el capítulo de guardias del Workbook sostiene que buena parte de lo aprendido sirve a organizaciones de cualquier tamaño. Esta guía toma lo que funciona con pocas personas y cierra con plantillas y una lista de verificación.

1. Decide qué cubre la guardia

Antes de armar el calendario, define qué servicios cubre la guardia, en qué horario y con qué tiempo de respuesta. Los números de Google sirven de referencia. En el capítulo Being On-Call del libro de SRE, Andrea Spadaccini explica que un SRE no debe dedicar más del 25 % de su tiempo a la guardia. De ahí deriva el mínimo para una rotación 24/7: ocho personas si el equipo está en un solo sitio y seis por sitio si son dos. El capítulo de guardias del Workbook (Ollie Cook, Sara Smollett, Andrea Spadaccini, Cara Donnelly, Jian Ma y Garrett Plasky) parte de un mínimo de cinco personas por sitio si la rotación 24/7 tiene varios sitios y ocho si hay uno solo, y recomienda sumar una más por sitio como margen ante bajas: seis por sitio, o nueve con un solo sitio.

Con tres personas no se alcanzan esos números. Lo honesto es acotar el alcance:

• Tiempo de respuesta según impacto. El libro da como valores típicos 5 minutos para servicios de cara al usuario y 30 minutos para sistemas menos sensibles. El Workbook agrega que un problema menor, como un respaldo fallido, puede atenderse en unas horas. Solo lo urgente justifica despertar a alguien.
• Turnos cortos. El Workbook recomienda turnos de 12 horas como máximo y considera insostenibles 24 horas de guardia sin relevo. Otra opción que propone son turnos de menos de una semana, por ejemplo 3 días de guardia y 4 libres.
• Primaria y respaldo. Muchos equipos tienen una guardia primaria y una secundaria. PagerDuty, en su guía Going On-Call, sugiere que el segundo nivel de escalamiento sea quien hizo la guardia anterior, porque todavía tiene el contexto.
• Carga medible. Según el libro, atender un incidente toma en promedio 6 horas entre análisis, mitigación y postmortem; por eso el máximo es de 2 incidentes por turno de 12 horas. El Workbook mide la carga con un promedio móvil de 21 días y pide corregir cuando sube.
• Compensación. Google compensa la guardia con tiempo libre o dinero, con un tope proporcional al sueldo.
• Preparación. PagerDuty pide equipo de la empresa, internet confiable en casa y accesos verificados antes de entrar a la rotación. En un caso del Workbook, quienes recién llegan acompañan a alguien con experiencia antes de tomar turnos.

Si tu equipo está en Chile

El Código del Trabajo (texto en LeyChile) tiene artículos que conviene leer antes de definir la guardia. El artículo 21 considera jornada de trabajo el tiempo en que la persona está a disposición del empleador sin realizar labor, por causas que no le son imputables. El artículo 30 define la jornada extraordinaria como la que excede el máximo legal o el pactado. El artículo 31 permite pactar hasta dos horas extraordinarias por día en faenas que no perjudiquen la salud. El artículo 32 dice que solo pueden pactarse para necesidades temporales, por escrito y por un máximo de tres meses renovables; que sin pacto escrito igual se consideran extraordinarias las horas trabajadas en exceso con conocimiento del empleador, y que se pagan con un recargo del 50 %. Desde la Ley 21.561, el mismo artículo permite acordar por escrito compensarlas con días adicionales de feriado: hasta cinco días hábiles al año, a razón de una hora y media de feriado por cada hora extraordinaria. El artículo 25 ter regula de forma expresa los turnos de espera o llamado, pero solo para tripulaciones de ferrocarriles. Esto no es asesoría legal: define con tu asesor laboral cómo se pacta, registra y paga la guardia.

2. Qué alerta despierta a alguien

En el capítulo Monitoring Distributed Systems, Rob Ewaschuk distingue dos preguntas: qué está roto (el síntoma) y por qué (la causa). Para él, cada página debe ser accionable, debe tratar un problema nuevo y, si la respuesta es mecánica, no debería ser una página. Su prueba para cada regla: ¿detecta una condición urgente, accionable y visible para el usuario, ahora o pronto, que nadie más detectaría?

Benjamin Treynor Sloss, en la introducción del libro, separa tres salidas del monitoreo: alertas (alguien debe actuar ya), tickets (alguien debe actuar, pero no ya) y registros (nadie necesita mirarlos salvo para diagnóstico). Todo lo que no requiere acción inmediata va a ticket, no al teléfono.

La forma más precisa de alertar sobre síntomas es hacerlo sobre el SLO. En Alerting on SLOs, Steven Thurgood y coautores definen la tasa de consumo (burn rate) como la velocidad con que el servicio gasta su presupuesto de error respecto del SLO. Para un SLO de 99,9 % proponen:

El Workbook agrega dos prácticas: probar cada alerta nueva en producción antes de convertirla en página, para descartar falsos positivos, y buscar la causa raíz de cada página.

3. Runbooks

Treynor Sloss escribe que dejar por escrito las buenas prácticas en un playbook mejora el tiempo medio de reparación unas 3 veces frente a improvisar. El Workbook precisa que un playbook da instrucciones de alto nivel; si es una lista fija de comandos que siempre se ejecuta igual, hay que automatizarla. Un runbook útil por alerta responde:

Alerta: <nombre exacto, como aparece en la página>
Qué significa: <síntoma e impacto para el usuario>
Tablero: <enlace>
Primeras verificaciones: <2 o 3 pasos>
Mitigación: <rollback, desviar tráfico, escalar recursos>
Escalar a: <persona o equipo, y cuándo>
Última revisión: <fecha y responsable>

4. Traspaso de turno

En el Workbook, quien entra a la guardia lee el traspaso del turno anterior y quien sale envía uno al siguiente; si no cumple lo esperado, el equipo lo conversa. PagerDuty recomienda que el traspaso sea formal (reunión, correo o documento compartido) e incluya despliegues recientes, acciones pendientes de postmortems, tareas abiertas y cambios de personal en equipos clave. Sugiere además hacer el cambio los lunes, para no cambiar de turno en fin de semana.

Traspaso de guardia · <fecha> · sale <rol> → entra <rol>
Incidentes del turno: <n.º, enlace a cada uno>
Abierto ahora: <qué sigue en curso y próximo paso>
Alertas ruidosas: <cuáles, ticket creado>
Despliegues recientes o programados: <qué y cuándo>
Acciones pendientes de postmortems: <enlaces>
Ausencias o cambios en escalamiento: <quién no está>

5. Roles durante un incidente

En el capítulo Managing Incidents, Andrew Stribblehill describe cuatro roles: comandante del incidente (tiene la visión completa y asigna tareas), operaciones (el único grupo que modifica el sistema), comunicaciones (la cara visible hacia afuera) y planificación (registra bugs y se ocupa de lo que viene después). Para él, es un incidente si hace falta un segundo equipo, si el cliente lo ve o si sigue sin resolver tras una hora de análisis. La tarea más importante del comandante es mantener un documento vivo del incidente, y el rol se traspasa de forma explícita.

Con pocas personas, la regla clave está en el capítulo Incident Response del Workbook (Jennifer Mace y coautores): el comandante asume todos los roles que no ha delegado, y si el incidente se achica, comunicaciones vuelve al comandante. Su consejo es declarar incidentes temprano y seguido. Aplicado a un equipo pequeño, una opción es esta: con dos personas, una comanda y comunica, y la otra opera; con tres, una tercera se hace cargo de comunicaciones. PagerDuty suma el rol de escriba, que registra la línea de tiempo, y sus niveles de gravedad dan una regla útil: si dudas entre dos niveles, usa el más alto. Atlassian insiste en que el responsable del incidente es un rol, no una persona, para que cualquiera preparado pueda asumirlo.

6. Postmortem sin culpa

En Postmortem Culture, John Lunney y Sue Lueder definen el postmortem como el registro escrito de un incidente: impacto, acciones de mitigación, causas y acciones para que no se repita. Proponen escribirlo cuando hay caída o degradación visible sobre un umbral, pérdida de datos, intervención de la guardia (rollback, desvío de tráfico), resolución lenta o una falla del monitoreo. Es sin culpa si busca las causas sin acusar a personas ni equipos: no se puede "arreglar" a las personas, pero sí los sistemas y procesos.

John Allspaw, en su artículo de 2012 en Etsy, explica por qué funciona: si no hay castigo, quien estuvo ahí cuenta qué hizo, qué vio, qué esperaba y qué suponía. Atlassian, en su proceso de postmortems, pide nombrar a las personas por su rol y preguntarse por qué el sistema permitió esa acción. El Workbook (Daniel Rogers y coautores) muestra la diferencia: en vez de culpar a quien ejecutó un proceso a mano, describe que el servidor no validaba los comandos que enviaba.

Sobre los plazos, PagerDuty agenda la reunión dentro de 3 días corridos para SEV-1 y 5 días hábiles para SEV-2, con una duración de 15 a 30 minutos. Esta plantilla sigue el ejemplo de postmortem de Google y la plantilla de PagerDuty:

Postmortem · <título> · <fecha> · estado: borrador/revisado
Responsable: <rol>    Participantes: <roles>
Resumen: <2 frases: qué pasó, cuánto duró, a quién afectó>
Impacto: <usuarios, transacciones, minutos, datos>
Detección: <alerta, cliente o persona; cuánto tardó>
Desencadenante: <cambio o evento que lo inició>
Causas: <condiciones del sistema y del proceso, sin nombres>
Resolución: <qué lo mitigó y qué lo resolvió>
Línea de tiempo (hora local): <hora · evento · fuente>
Qué salió bien / qué salió mal / dónde tuvimos suerte
Acciones: <acción · tipo (mitigar/prevenir/proceso) · responsable · fecha · ticket>

7. Seguimiento de acciones

Un postmortem sin acciones cerradas no cambia nada. El Workbook advierte que sin un proceso formal las acciones se olvidan y el incidente vuelve; por eso Google las registra como bugs en un sistema central y mide su cierre. Cada acción debe tener responsable y un estado final verificable. También recuerda que cambiar el comportamiento humano es menos confiable que cambiar sistemas automatizados.

Atlassian marca como "acciones prioritarias" las que corrigen la causa raíz y les fija un plazo de 4 u 8 semanas según el servicio, con recordatorios. Usa la técnica de los cinco porqués y aprobación de un gerente, aunque reconoce que en equipos con pocos incidentes esa aprobación puede no ser necesaria.

Con pocas personas: un ticket por acción en el mismo sistema que el trabajo diario, una fecha comprometida y una revisión mensual de las abiertas.

Lista de verificación

Fuentes

• Google · Site Reliability Engineering: Introduction (Benjamin Treynor Sloss).
• Google · Being On-Call (Andrea Spadaccini).
• Google · Monitoring Distributed Systems (Rob Ewaschuk).
• Google · Managing Incidents (Andrew Stribblehill).
• Google · Postmortem Culture: Learning from Failure (John Lunney y Sue Lueder) y Example Postmortem.
• Google · The Site Reliability Workbook: On-Call, Alerting on SLOs, Incident Response y Postmortem Culture.
• PagerDuty · Incident Response Documentation: roles, niveles de gravedad, proceso y plantilla de postmortem; licencia Apache 2.0.
• PagerDuty · Going On-Call: Technical Preparations y Setting Team Norms.
• Atlassian · Incident Management Handbook e Incident postmortems.
• John Allspaw · Blameless PostMortems and a Just Culture (Etsy, 22 de mayo de 2012).
• Código del Trabajo de Chile, DFL 1 de 2002, en LeyChile: artículos 21, 25 ter, 30, 31 y 32.

Si quieres revisar tus alertas o tu rotación de guardia con tu equipo, conversemos.