Cómo funciona
El pipeline de cierre del ciclo, escena por escena.
OpenRemedy se construye alrededor de un único ciclo agéntico: vigilar de forma continua, reconocer la desviación, clasificar y encaminar, proponer una solución, aprobar donde importa, ejecutar, verificar y escribir el post-mortem. Cada servidor pasa por tres modos de confianza escalonados — observar, simulación, en vivo — de modo que la autonomía es un gradiente que concedes por etapas, no un interruptor único. Las siguientes páginas recorren el ciclo escena por escena.
Señales desde el servidor, la plataforma y el exterior.
OpenRemedy ejecuta un pequeño daemon en cada servidor gestionado. Reporta hechos cada quince segundos y ejecuta los chequeos de salud que le envía la plataforma — cada uno firmado con HMAC, de modo que una configuración manipulada no pueda introducir comandos arbitrarios en el host.
Los servidores sin agente también quedan cubiertos. Sondeos programados se ejecutan desde la plataforma con una cadencia configurable, y las patrullas de IA inspeccionan periódicamente la flota en busca de condiciones para las que nadie escribió una regla. Cada señal alimenta el mismo pipeline de cierre del ciclo más adelante.
Un incidente se abre en el momento en que algo no va bien.
Tanto si la señal viene del daemon, de un sondeo programado, de un agente en patrulla o de una fuente de alertas externa como Alertmanager o Datadog, aterriza en el mismo lugar: un incidente nuevo con severidad, tipo, contexto del servidor y la evidencia relevante ya adjunta.
El umbral de detección es de unos quince segundos para condiciones de umbral en el daemon, y de menos de un segundo para alertas push. La mayoría de los problemas llegan aquí mucho antes de afectar a ningún usuario.
Sustained CPU on api-prod-03
opened 41 seconds ago · daemon · resolved automatically
Triage · Atlas
Pattern matches a recurring spike from the daily ingest job. Routed to the diagnose stage.
Diagnose · Forge
Captured a fresh top -bn1 snapshot. Top consumer: python ingest_worker.py at 89% (expected behaviour during ingest).
Resolved · Default SRE
Transient — load returning to baseline. No action taken. Marked for monitoring.
El triage encamina hacia el especialista correcto.
Un agente de triage lee el incidente, busca resoluciones pasadas para condiciones similares y decide quién lo gestiona. Los patrones recurrentes se emparejan con soluciones conocidas; los problemas nuevos reciben más investigación.
El agente registra su razonamiento a medida que avanza, de modo que el rastro de la decisión queda visible después — nada de un opaco «la IA hizo algo».
Línea de tiempo de triage · Atlas
Búsqueda de resoluciones pasadas
Se encontraron 3 incidentes coincidentes en api-prod-03 en los últimos 30 días. Todos resueltos con la misma receta.
Clasificado
cpu_high · severidad alta · patrón: pico de tarea programada
Traspasado
Encaminado a la etapa de diagnóstico con el contexto del pico recurrente adjunto.
Evidencia primero, con herramientas en sandbox y nada más.
El agente de diagnóstico recoge evidencia usando un conjunto curado de herramientas de solo lectura — estado de servicios, colas de logs, capturas de procesos, introspección de contenedores. Razona sobre la causa raíz y propone una solución.
El LLM nunca tiene acceso a una shell libre. Cada llamada de diagnóstico es un verbo tipado contra el catálogo en sandbox de la plataforma. Los operadores pueden ampliar ese catálogo, pero cada herramienta nueva pasa por el mismo mecanismo de escapado de parámetros y de lista blanca de hosts que las herramientas integradas.
Las soluciones de bajo riesgo se ejecutan. Las arriesgadas esperan por ti.
Cada receta lleva un nivel de riesgo explícito, fijado por el operador que la escribió. Los agentes autónomos pueden ejecutar por su cuenta las soluciones de bajo riesgo; las de riesgo medio o superior siempre se detienen a esperar la aprobación de una persona. El LLM no se examina a sí mismo sobre si algo es seguro.
Las solicitudes de aprobación muestran el contexto completo: qué propone el agente, por qué, qué podría salir mal y qué aspecto tuvieron las ejecuciones anteriores de la misma receta. Un clic y la plataforma ejecuta; un clic y se retira.
Approval requested
Restart nginx on edge-04?
Proposed recipe
systemd-restart-service
risk: medium · trust: supervised · expected duration: ~8 s
Why this fix
nginx.service has been in failed for 4 min. Last 12 lines of the journal show recurring SIGSEGV after a config reload. A clean restart is the standard remedy and reproduces past resolutions on this server.
Ansible aplica la solución. La plataforma se encarga de la auditoría.
La receta aprobada se envía a un worker que ejecuta el playbook de Ansible subyacente por SSH. La salida se transmite al panel en tiempo real para que puedas seguir la ejecución, intervenir si es necesario, y ver exactamente qué cambió en el host. En modo simulación el mismo playbook simula sin tocar el estado real — ves qué habría pasado antes de dejar que pase de verdad.
Un agente revisor verifica la resolución cuando el playbook termina — el servicio ha vuelto a funcionar, las métricas han vuelto a la normalidad, no hay regresión en otro lugar — y solo entonces cierra el incidente.
Cada incidente escribe su propio post-mortem.
La plataforma hila la línea de tiempo, la evidencia, el razonamiento del agente, la cadena de aprobaciones y el resultado de la ejecución en un único informe. Si intervino una persona, su razonamiento queda capturado junto al del agente.
Los patrones recurrentes se convierten en candidatos para nuevos playbooks preaprobados. El runbook del equipo crece por sí solo, curado por el trabajo que la plataforma ha estado haciendo de verdad.
nginx restart on edge-04
Tue, 14:08 UTC · 12 minutes total · approved by alberto@…
- What happened
- nginx.service crashed with SIGSEGV after a config reload at 14:01. The daemon detected the failed state within 12 seconds and opened an incident.
- Root cause
- A reload pulled in a partially-written /etc/nginx/sites-enabled/api.conf. The deploy pipeline had no atomic-write step.
- What we did
- Approved the systemd-restart-service recipe at 14:09. Service back to active (running) in 6 s. Verified with three follow-up health probes.
- Follow-up
- Open ticket against the deploy pipeline to add atomic file-replace. Add a proactive policy to alert on partial config files.
Esa es toda la forma.
Cada fuente de detección, cada agente, cada receta sigue el mismo ciclo. El panel, el rastro de auditoría y la documentación están organizados alrededor de él.