Furia contra el on-call: Diseñando sistemas que tratan a los ingenieros como personas, no como infraestructura
En la economía de la disponibilidad constante, la infraestructura digital se ha convertido en el sistema nervioso del comercio global. Sin embargo, mientras las empresas invierten millones en redundancia de hardware y arquitectura de microservicios, a menudo ignoran el componente más crítico —y frágil— de la ecuación: el operador humano.
La guardia u on-call no es simplemente un rito de iniciación para ingenieros; es un mecanismo de transferencia de riesgos. El problema es que, sin un diseño deliberado, este riesgo se convierte en un “impuesto sobre el sueño” que erosiona la cultura de ingeniería y, eventualmente, la estabilidad del producto.
La economía del agotamiento
En términos macroeconómicos, la fatiga por alertas es una externalidad negativa. Cuando un sistema mal diseñado despierta a un ingeniero a las 3:00 AM por un falso positivo, la empresa no incurre en un gasto inmediato en su balance, pero está consumiendo su capital de innovación.
La ciencia cognitiva es tajante: la privación de sueño degrada la capacidad de resolución de problemas a niveles comparables con la intoxicación etílica. Mantener una rotación de guardia dolorosa es, por tanto, una decisión de ingeniería negligente. No solo es inhumano sino operativamente arriesgado.
El Cuadro de Mando de la Resiliencia Humana
Para gestionar la salud de un sistema, debemos medir la carga que impone sobre quienes lo sostienen. En las organizaciones de alto rendimiento, el éxito no se mide solo por el uptime, sino por estas tres métricas de fidelidad:
Principios de diseño para sistemas “silenciosos”
La filosofía suele ser que los sistemas deben ser auto-explicativos. Para que el on-call sea sostenible, debemos aplicar una disciplina férrea en la configuración de nuestra observabilidad:
Alertas basadas en síntomas, no en causas: Monitorear el uso de disco es reactivo; monitorear la latencia del usuario es proactivo. Una base de datos al 80% de capacidad es una tarea de mantenimiento para el martes a las 10:00 AM; una API devolviendo errores 500 es una emergencia de madrugada.
La Regla de la Accionabilidad: Si una alerta no tiene un procedimiento claro (un runbook) y una acción inmediata que realizar, no es una alerta; es ruido de fondo. El botón de “Snooze” no debería existir en una cultura de producción responsable.
Incentivos Alineados: El equipo que construye la funcionalidad debe ser el mismo que la opera. Separar “Desarrollo” de “Operaciones” crea un riesgo moral donde quienes escriben el código no sufren las consecuencias de su fragilidad.
De la “Autopsia” al Aprendizaje
El lenguaje que usamos define nuestra cultura. Mientras que el término post-mortem implica finalidad y culpa, las Revisiones de Aprendizaje se centran en la arqueología de los sistemas complejos.
Un incidente es una oportunidad de inversión. Si una guardia fue difícil, el resultado no debe ser solo un sistema “arreglado”, sino una lista de mejoras estructurales que garanticen que ese dolor específico no se repita. La medida de una organización madura es su negativa a sufrir el mismo incidente dos veces.
El Checklist de la Alerta Perfecta
Antes de poner una alerta en producción, nos hagamos estas cuatro preguntas:
¿Es urgente? ¿El negocio pierde dinero o integridad de datos si no se atiende en los próximos 15 minutos?
¿Es accionable? ¿El ingeniero sabrá qué comando ejecutar nada más abrir el portátil?
¿Tiene contexto? ¿La alerta incluye enlaces directos a los dashboards y logs relevantes?
¿Es única? ¿O es la quinta alerta que recibo por la misma causa raíz?
La excelencia operativa no es el resultado de tener ingenieros que duermen poco, sino de construir sistemas que les permitan dormir bien.