¿Hay alguien a bordo?
¿Qué aprendimos sobre resiliencia y antifragilidad con el apagón?
Hace unos días, como casi siempre, esta reflexión de
me dejó pensando sobre cómo a menudo confiamos en la disponibilidad constante de las personas como salvaguarda de los procesos.Ayer, durante el apagón generalizado en España, muchas organizaciones nos vimos de repente sin maquinista: sin electricidad, sin Internet, sin red móvil.
¿Cuántas tenían la autonomía suficiente para operar más de 15 horas sin nadie a bordo? ¿Cuántas contaban con un mecanismo para aquellos procesos que dependían de intervención humana?
Después de medio día incomunicado, sabiendo que el resto del equipo también lo estaba, me preguntaba cuánto seguía en pie. Aunque hoy encontré todo en orden, no dejo de preguntarme qué podría haber fallado y si la ausencia de maquinistas a bordo podría haber generado problemas de mayor calado, incluso irreversibles.
¿Habría habido alertas críticas que nadie pudo atender? ¿Algún servicio menor que, sin supervisión, podría haberse degradado hasta impactar a los clientes? ¿Dependemos demasiado de acciones humanas puntuales que ayer simplemente no eran posibles?
Mientras hacía estas preguntas al equipo hoy, conecté con el mecanismo del pedal de los trenes al que se refería José Carlos, y me llevó a reflexionar sobre cómo detectamos (o no) la presencia activa de operadores y cómo diseñamos sistemas que puedan sobrevivir también a la ausencia temporal de sus «maquinistas».
El dispositivo de hombre muerto
El “dispositivo de hombre muerto” consiste en un sistema que monitoriza la presencia o acción constante de una persona y, si detecta su ausencia o inacción durante un período determinado, activa automáticamente una respuesta predefinida.
Componentes básicos del mecanismo:
Sensor de actividad o confirmación: Puede ser un pedal, un botón, una señal digital (usuarios conectados a Slack, heartbeat, ACK a alarmas) o incluso una acción programada (como enviar un “ping”).
Temporizador: Controla cuánto tiempo puede pasar sin detectar actividad antes de actuar.
Acción de seguridad: Lo que sucede si no se detecta actividad. Ejemplos:
Frenado de emergencia (en trenes, maquinaria pesada).
Apagado del sistema.
Envío de una alerta o activación de un protocolo (mensajes, publicaciones, liberación de información).
Lanzamiento automático de una acción irreversible (en sistemas militares o de alta seguridad).
Algunos ejemplos:
En un tren, el conductor debe mantener presionado un pedal. Si lo suelta durante más de unos segundos, el tren se detiene.
En el mundo digital, un activista puede usar un servicio que, si no confirma que sigue activo cada semana, publique automáticamente un archivo con información confidencial.
En una infraestructura crítica, un sistema puede reiniciar servicios si no recibe heartbeats de un servidor supervisor.
En una organización que opera en remoto, si no detecta a nadie online en Slack, activa un protocolo especial para autoresponder operaciones que requieren intervención humana.
Algunos equipos evalúan su resiliencia preguntándose cuántas personas críticas podrían faltar antes de que los sistemas dejaran de funcionar (lo que se conoce como bus factor). Pero incluso si ese riesgo inmediato fuese cero, queda una cuestión igual de importante: ¿por cuánto tiempo podría mantenerse el sistema sin intervención humana?
¿Qué habría pasado si nuestra incomunicación se hubiese extendido tres días, solo en España, mientras nuestros clientes seguían usando nuestro producto?
En la industria manejamos métricas que abordan partes del problema:
MTTR (Mean Time to Recovery): mide cuánto tarda un sistema en recuperarse tras una falla, pero asume intervención humana inmediata.
MTBF (Mean Time Between Failures): mide la fiabilidad general entre fallos, sin considerar la capacidad de autorecuperación.
MTTD (Mean Time to Detect): mide el tiempo para detectar un fallo, suponiendo sistemas de monitoreo activos y personal disponible.
Sistemas fail-safe o fail-operational: en sectores como la aviación o el ferroviario, exigen que ciertos sistemas sigan funcionando de forma segura durante un tiempo tras perder operadores o sufrir fallos.
Principios de sistemas self-healing: en entornos cloud-native y SRE se diseñan plataformas que intentan recuperarse solas ante incidentes, aunque no existe una métrica específica que mida su autonomía en ausencia total de operadores.
No he encontrado un estándar formal que mida exactamente esto, así que de momento le pongo nombre para poder comparar la próxima vez que nos enfrentemos a una situación similar.
Unattended System Lifetime:
Tiempo máximo que un sistema puede mantener estándares operativos aceptables sin intervención humana.
Qué mide: Tiempo máximo sin humanos operando ni corrigiendo nada.
Cómo medirlo: Simulaciones controladas + observación de eventos reales.
Qué necesitas: Definir SLA mínimo, fallos válidos, período de gracia.
Para qué sirve: Evaluar la resiliencia real del sistema en escenarios extremos o de baja disponibilidad humana.
Checklist de acciones para optimizar esta métrica
🔔 Monitorización y alertas
¿Existen sistemas de monitoreo activos (health checks, métricas, logs) que no dependan de intervención humana continua?
¿Las alertas escalan automáticamente si no son reconocidas en un tiempo definido?
¿Existe una alerta meta (watchdog) que detecte si ninguna alerta ha sido reconocida en X tiempo?
¿Las alertas críticas pueden llegar a alguien fuera del país afectado (por ejemplo, un equipo de backup o soporte en otra región)?
🔁 Automatización operativa
¿Los servicios críticos tienen mecanismos de autorecuperación (restart, failover, circuit breaker)?
¿Hay tareas de mantenimiento programadas que podrían fallar sin supervisión (por ejemplo, backups, borrado de logs, jobs ETL)?
¿Las tareas programadas tienen verificación posterior para confirmar su ejecución?
🧰 Runbooks y contingencias
¿Existen runbooks accesibles para otros roles (no técnicos), en caso de necesitar acciones mínimas?
¿Hay bots o scripts automatizados que puedan ejecutar ciertas respuestas sin interacción humana?
¿Los equipos no técnicos saben a quién escalar si algo falla y no hay respuesta técnica?
🔒 Seguridad y control de accesos
¿Hay límites definidos para accesos críticos si no se puede intervenir en tiempo real (por ejemplo, caducidad de sesiones, expiración de tokens)?
¿Se pueden revocar accesos o desactivar cuentas críticas sin intervención directa del equipo técnico?
💬 Comunicación y coordinación
¿Existen canales alternativos de comunicación con otros equipos (clientes, soporte, dirección) fuera del país?
¿Los roles no técnicos clave conocen el plan de contingencia y su papel en ausencia del equipo de ingeniería?
¿Hay mensajes predefinidos o mecanismos automáticos de comunicación para clientes si se detecta un incidente?
🔎 Observabilidad a distancia
¿Alguien fuera del país puede acceder a dashboards, logs o métricas clave?
¿Existe acceso remoto seguro y controlado para al menos una persona externa o delegada?
🧪 Pruebas y simulacros
¿Se ha ensayado alguna vez un escenario de pérdida total de disponibilidad del equipo técnico?
Hacer simulacros suele ser carísimo y, aun así, es difícil que reflejen escenarios reales. Ayer vivimos un simulacro forzado: si no lo aprovechamos para reflexionar, aprender y mejorar, estaríamos perdiendo una gran oportunidad.
Me encantaría saber cómo lo vivieron en otros equipos. Si te animas, cuéntamelo en los comentarios.
Me ha encantado la reflexión y las estrategias que propones 👏🏽👏🏽