Saltar a contenido

Self-healing infrastructure (patrón)

Patrón arquitectónico donde el monitoring no sólo detecta fallos sino que dispara una investigación → diagnóstico → fix → verificación automatizada, idealmente con un AI agent como ejecutor. Convierte "alert-and-wait" en "detect-diagnose-and-fix". Documentado en el setup de madebynathan; aplicable —con adaptaciones— al setup del usuario.

Contexto

Para la pregunta de "treat smart home como problema de software engineering", este patrón es el techo conceptual: lo más ambicioso que cabe en el wiki sin caer en ciencia ficción. La cita central: "The AI layer is the force multiplier — it turns your monitoring from alert-and-wait into detect-diagnose-and-fix." La adopción puede ser gradual (capas 1-4 sin AI primero, AI en una capa 5 opcional).

Contenido

El loop canónico (6 pasos)

  1. Detect — Health checks (Gatus o equivalente) fallan, o scheduled audits encuentran drift.
  2. Investigate — Agente lee logs (Loki) y estado actual de servicios.
  3. Diagnose — Identifica root cause: OOM, config error, network, certificate expired, disk full, etc.
  4. Fix — Aplica remedio: restart pod, fix config, apply Terraform change, renew cert.
  5. Verify — Confirma que el fix resolvió el problema (re-corre el check fallido).
  6. Document — Loguea el incidente y la resolución (PR comment, Slack, postmortem markdown).

Capas reusables (independientes de k8s)

Capa Función Implementación posible (sin k8s)
1. Hypervisor / runtime Aislar workloads, snapshot/restore Proxmox + LXC, o plain Docker host
2. IaC Definición declarativa Terraform + Ansible (sin k8s providers)
3. Orquestación de servicios Levantar, restart, networking Docker Compose con healthchecks, o Nomad, o systemd units
4. Monitoring Health, logs, métricas ../entities/gatus + Loki + Grafana + Prometheus
5. AI brain (opcional) Detect → diagnose → fix automation ../entities/openclaw, o agente custom con Claude SDK

Adopción incremental

No hace falta hacer todo de golpe. Las capas son útiles aunque no llegues nunca a la 5.

  • Capas 1-2: deja el setup reproducible. Si rompe, se reconstruye desde git.
  • Capa 3: levanta los servicios con healthchecks y restart policies. Recovery básica sin AI.
  • Capa 4: ves qué pasa cuando algo falla. Reduces MTTD (mean time to detect).
  • Capa 5: cierra el loop. Reduces MTTR (mean time to recover) cuando la causa es conocida.

Para el setup del usuario, la propuesta razonable es adoptar capas 1-4 en el nodo experimental (HA Container) y mantener el HA Yellow (essentials) sin capa 5 hasta validar que es seguro.

Conexión con los principios de madebynathan

  • everything-is-code — sin esto, capa 2 colapsa.
  • ai-as-operator — sin esto, capa 5 deja de ser segura (el agente toma decisiones que no debería).
  • Defense in depth — multi-channel alerts + scheduled audits (no en una página propia, pero queda como recordatorio).
  • Fail safe, not fail secure — degradación graceful prioriza availability.

Riesgos del patrón

  • AI sobre-actuante: si el agente "arregla" agresivamente puede ocultar problemas más profundos.
  • Loops infinitos: detección → fix → detección → fix → ... si el fix no resuelve. Requiere circuit breakers.
  • Costo cognitivo: armar el stack lleva semanas; mantenerlo se compone si no se ata a un repo y a hábitos.

Relaciones

Citas / evidencia

Abierto / gaps

  • Failure cases públicos: documentar 2-3 casos donde un agente self-healing tomó la decisión incorrecta y rompió cosas. Ingerir el HN thread crítico (en candidatos media).
  • ¿Qué tipo de problema NO debe self-heal? Política recomendable: cambios de datos (DB drops, file deletes), cambios de seguridad (certs sin renovar, firewall rules nuevas), cambios de schema.
  • Métricas para evaluar si el self-healing está funcionando: MTTR, % de incidentes resueltos sin humano, % de over-actions.