Paso 5: Resilience y Error Handling Completo

Descripción de la cápsula

Aplicar todo M06 (error handling) al sistema. Retry strategies, fallbacks, Error Workflow, observabilidad.

---

Aplicar retry strategies

En todos los nodos críticos de los 3 workflows:

Sheets reads/writes

• Retry On Fail: ON
• Max Tries: 3
• Wait Between Tries: 2000ms

Slack notifications

• Retry On Fail: ON
• Max Tries: 3
• Wait: 2000ms
• Continue On Fail: ON (Slack down no debe parar todo)

Email send

• Retry On Fail: ON
• Max Tries: 3
• Wait: 5000ms
• Continue On Fail: ON

---

Fallbacks

Si Slack falla

[Slack con Continue on Fail]
   │
[IF: error?]
└─ TRUE → [Email alternativo a oncall]  // fallback al email

Si el principal canal (Slack) falla, usar email como fallback.

Si Email falla

Considerar SMS via Twilio como fallback de último recurso para críticas.

---

Error Workflow

Crear [GUARDIAN-ALERTS]

[Error Trigger]
   │
[Set: enriquecer]
- workflow_name: $json.workflow.name
- timestamp
- severity: critical (porque es un sistema de alertas — irónico si falla)
   │
[Slack #ops-critical: "Error en sistema de alertas"]
   │
[Email a CTO/admin: "URGENT: alert system failure"]
   │
[Sheet log 'system_failures']

Asignar a los 3 workflows

• [ALERTS-MAIN] → Error Workflow: [GUARDIAN-ALERTS]
• [ALERTS-ACK] → mismo
• [ALERTS-ESCALATE] → mismo

---

Observabilidad

Sheet system_log

Cada ejecución de [ALERTS-MAIN] logea:

- timestamp
- duration_seconds
- alerts_generated (count)
- alerts_critical
- alerts_high
- ok_metrics
- errors_encountered (count)
- status: 'success' | 'partial_failure' | 'error'

Dashboard manual

Workflow separado [ALERTS-DASHBOARD] que corre diariamente:

[Schedule diario 9am]
   │
[Sheet read: system_log últimos 7 días]
   │
[Set: calcular métricas]
- runs_total
- failure_rate: errors / total
- avg_duration
- pct_runs_with_alerts
   │
[Slack a #monitoring: "Health report semanal del sistema de alertas"]

---

Alarma "alarm system is dead"

Trampa famosa: tu sistema de alertas falla. Cómo te enteras? Necesitas un "watcher of watchers".

Implementación

[ALERTS-HEARTBEAT]:

[Schedule cada 30 min]
   │
[Sheet read: system_log]
   │
[IF: hay execution en últimos 30 min?]
├─ TRUE → todo OK, log heartbeat
└─ FALSE → [Slack a admin: "ALERTS-MAIN no ha corrido en 30+ min — sistema posiblemente caído"]

Otro workflow que verifica que el principal está vivo.

---

Validación de configuración

Al inicio de [ALERTS-MAIN], sanity check:

[Verificación inicial]
- ¿Sheets accesibles?
- ¿Slack credential funciona?
- ¿Email credential funciona?
   │
[IF: algún check falla]
└─ TRUE → notificar a admin, no proceder

Sin esto, el sistema corre con credenciales rotas y falla silenciosamente.

---

Idempotencia

Si el mismo Schedule dispara 2 veces (por bug de n8n o algo raro), no duplicar alertas:

Approach

Cada execution genera un execution_id único. Al loggear, check si ya existe:

[Sheet check: ya existe alert con este timestamp + metric?]
├─ TRUE → skip (duplicado)
└─ FALSE → procesar normal

---

Test de resilience

Test: Slack caído

Simular: cambiar Slack credential a inválida.

• [ALERTS-MAIN] debería:
  • Retry 3 veces (cada uno falla)
  • Continue on Fail
  • Si configurado, fallback a email
  • Workflow termina con éxito parcial

Test: Sheet caído

Simular: revocar acceso al Sheet desde Google.

• [ALERTS-MAIN] retry → falla → Error Workflow se dispara
• Recibes alert "sistema de alertas falló"

Test: Workflow no corre

Desactivar [ALERTS-MAIN]. Después de 30 min:

• [ALERTS-HEARTBEAT] detecta
• Slack al admin

---

Validación

• Retry configurado en nodos críticos
• Continue on Fail donde apropiado
• Fallbacks (Slack → email)
• [GUARDIAN-ALERTS] asignado a 3 workflows
• Sheet system_log con observabilidad
• [ALERTS-HEARTBEAT] corriendo
• Validación inicial implementada

Lo que sigue: Test, deploy y monitoring final.

---

Creado: Mayo 11, 2026 Versión: 1.0