El SRE autónomo con IA para flotas Linux.
OpenRemedy es tu SRE autónomo de confianza para flotas Linux. Observa, diagnostica y aplica la solución bajo tres niveles de confianza escalonados por servidor — observar, simulación, en vivo. Creado por operadores con más de 20 años de experiencia en producción. Para las máquinas a las que Kubernetes no llega.
¿Tienes curiosidad? Descubre cómo funciona.
Sustained CPU on api-prod-03
opened by daemon · 00:00 ago
Agent pipeline starting…
Atlas is being assigned to the incident.
Repetición de un pico de CPU real. Detectado, clasificado y cerrado automáticamente en menos de tres segundos.
La premisa
Detectar es la parte fácil. Cerrar el ciclo es el trabajo de fondo.
La mayoría de las plataformas te avisan de que algo se rompió y le pasan la alerta a una persona. OpenRemedy recibe señales de todas las fuentes que ya tienes y ejecuta el mismo ciclo que antes hacía una persona — diagnosticar, decidir, actuar, documentar — bajo tu control, con el rastro de auditoría que los equipos de cumplimiento esperan.
En el servidor
Un pequeño agente en Go reporta el estado del sistema y ejecuta chequeos de salud firmados por la plataforma cada 15 segundos.
En la plataforma
Sondeos programados con Ansible cubren los servidores sin agente, y las patrullas de IA buscan patrones inusuales.
Desde fuera
La recepción de webhooks acepta alertas de Alertmanager, Grafana, Datadog o cualquier fuente HTTP — firmadas con HMAC.
Desde el operador
Creación manual de incidentes para consultas puntuales; el agente ejecuta el chequeo solicitado al momento y responde con los resultados.
Gradientes de confianza, no autonomía de todo o nada
Rápido donde debe serlo. Cuidadoso donde no debería.
Cada servidor vive en uno de tres modos escalonados — observar (el agente vigila pero nunca actúa), simulación (simula la solución y te muestra exactamente qué habría pasado) y en vivo (la ejecuta: las soluciones de bajo riesgo son autónomas y las de riesgo medio o alto requieren aprobación humana). Asciendes un servidor de modo cuando ves que el agente se lo ha ganado. El LLM nunca decide por sí mismo que algo es lo bastante seguro para ejecutarse.
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.
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.
Preparado para auditoría desde el diseño
Cada incidente escribe su propio post-mortem.
La plataforma documenta qué pasó, qué razonó el agente, qué se aprobó, quién lo aprobó y cómo se verificó la solución. Llegas a la revisión semanal — o a la próxima auditoría de cumplimiento — con el informe ya redactado.
¿Quieres una plaza?
Todavía estamos enseñando a la plataforma a operar flotas Linux con seguridad — por ahora la probamos nosotros mismos en nuestra propia infraestructura de producción. Déjanos tu correo y te avisaremos cuando la historia de seguridad esté a la altura de la tuya.
Sin spam, sin goteo de marketing — un solo correo cuando se abra tu plaza.