Qué hacer cuando una automatización se rompe

Diseñá tres capas: saberlo (monitoreo y heartbeat que detectan la caída en horas), aguantarlo (reintentos con espera creciente y el plan B manual de cada ficha) y repararlo con un protocolo sin pánico: contener con el botón rojo, diagnosticar preguntando '¿qué cambió?', reparar y probar, y documentar el incidente.

La verdad que separa a los que operan sistemas de los que los abandonan: todo se rompe, eventualmente — la plataforma cambia algo, el form agrega un campo, la API renueva sus llaves. La diferencia entre el incidente de 20 minutos y el desastre silencioso de tres semanas no es la suerte: es el diseño de la rotura.

Las tres capas de la resiliencia

Las tres capas de resiliencia ante una automatización rota: saberlo, aguantarlo y repararlo.

Capa 1 — Saberlo (el monitoreo). El pulso de los sistemas + las alertas de incendio. El upgrade clave: el heartbeat de los puentes — cada integración crítica registra su última corrida exitosa, y una tarea vigía pregunta a diario “¿corriste cuando debías?”. El puente caído que nadie nota es el peor escenario del parque entero — y con heartbeat, es imposible.

Capa 2 — Aguantarlo (reintentos y degradación). Las fallas transitorias (el servicio que no respondió 30 segundos) se resuelven solas con reintentos — la mayoría de las plataformas de flujos los traen: activalos con espera creciente (a los 5 min, a los 30, avisar si falla la tercera). Y para las fallas largas, la degradación elegante: el plan B manual de cada ficha — el sistema cae, la operación sigue a mano, nadie se entera del otro lado.

Capa 3 — Repararlo (el protocolo sin pánico). El incidente tiene método:

  1. Contener — el botón rojo si está haciendo daño; el plan B manual activado.
  2. Diagnosticar — el error completo a Claude + la pregunta de oro de las integraciones: “¿qué cambió?” (el 90% de las roturas de puentes vienen de un cambio en una punta: el form editado, la columna renombrada, el permiso vencido).
  3. Reparar y probar — el arreglo + las dos pruebas (camino feliz e infeliz) antes de redeclarar vivo.
  4. Documentar — la ficha del puente suma su historial: qué se rompió, por qué, cómo se arregló. El parque con historial se repara cada vez más rápido.

El simulacro

Rompé un puente a propósito (cambiá el nombre de una columna) y corré el protocolo completo, cronometrado. El simulacro de hoy es la calma del incidente real. Y junto a eso, configurá los reintentos en cada flujo y dejá el protocolo de incidentes en una página, al proyecto.