Funciones
El ciclo agéntico de SRE, a fondo.
Cuatro pilares: señales de entrada, razonamiento autónomo, acción controlada y el tejido operativo que lo hace usable en un equipo de operaciones real. Detectar es la entrada; cerrar el ciclo es el trabajo. Cada sección enumera las capacidades concretas que vienen incluidas.
Cinco vías independientes para alimentar el ciclo del agente.
OpenRemedy no depende de una sola señal. Cinco mecanismos funcionan a la vez, con cobertura solapada, de modo que una alarma perdida no significa un incidente perdido — y todos convergen en el mismo pipeline de cierre del ciclo.
Monitores continuos del daemon
Un pequeño agente en Go en cada servidor gestionado revisa la salud del sistema cada quince segundos. CPU, memoria, disco, puertos, servicios, procesos, patrones de log, contenedores Docker — tipos de monitor integrados que puedes combinar en políticas. Los chequeos de shell personalizados usan el mismo canal, firmados por la plataforma, de modo que una configuración manipulada no puede introducir comandos arbitrarios en el host.
Sondeos programados desde la plataforma
Los servidores sin daemon siguen cubiertos. Las recetas etiquetadas como recipe_check se disparan según una programación configurable, se ejecutan como playbooks de Ansible desde la plataforma, y sus resultados pasan por un evaluador con LLM que decide aprobado o fallido con todo el contexto.
Agentes de IA en patrulla
Los intervalos de patrulla por agente dejan que la IA recorra la flota por su cuenta, buscando anomalías para las que no escribiste una regla. El silencio de las 3 de la madrugada que no debería ser silencio, la carga que se aplanó, el servicio que se reinició tres veces en una hora — el agente abre un incidente con su propio razonamiento adjunto.
Recepción de webhooks
Los sistemas de monitorización que ya usas se conectan mediante webhook firmado con HMAC. Alertmanager, Grafana, Datadog, PagerDuty, clientes HTTP personalizados — cualquier fuente que empuje datos converge en el mismo pipeline de incidentes. Latencia de menos de un segundo desde la alerta hasta el incidente en la base de datos.
Consultas manuales puntuales
Los operadores pueden abrir un incidente personalizado con una pregunta libre. El agente ejecuta el chequeo solicitado al momento contra el servidor real y responde — útil para investigaciones puntuales que no justifican un monitor permanente.
Agentes especializados, cada uno con su rol y su nivel de confianza.
Cada incidente avanza por un pipeline de invocaciones de agente distintas. Cada etapa tiene su propio prompt, su propio presupuesto de herramientas y su contexto acotado por inquilino. Ninguna llamada al LLM carga con todo el peso.
Pipeline de cinco etapas
Triage → diagnóstico → validación → ejecución → revisión. Los incidentes de tipo personalizado se saltan la ejecución y se resuelven tras el diagnóstico. Cada etapa registra sus llamadas a herramientas y su razonamiento como eventos discretos, de modo que el rastro de auditoría te dice qué pensó el agente y por qué — no solo qué hizo.
Puerta de confianza × riesgo
Cada agente tiene un nivel de confianza (autónomo / supervisado / manual). Cada receta tiene un nivel de riesgo (bajo / medio / alto). La puerta de control de la plataforma se ejecuta en el servidor; el LLM no puede autoaprobarse. La confianza autónoma solo permite ejecución automática en riesgo bajo. Todo lo demás pasa por una persona.
Skills como módulos de conocimiento
Documentos en markdown asociados a un agente — «operación de nginx», «fundamentos de PostgreSQL», «triage de Docker» — cargados en el contexto en tiempo de ejecución. Los skills afinan el razonamiento de dominio sin forzar un único prompt gigante. Catálogo integrado más autoría por inquilino.
Anulaciones de prompt por inquilino
La plataforma viene con plantillas Jinja por defecto; cualquier inquilino puede sobrescribir el prompt de cualquier etapa del pipeline desde el panel. Ajústalo a tu flota, tu terminología, tus convenciones de escalado — sin tocar código.
Conciencia de resoluciones pasadas
El triage busca en incidentes históricos patrones similares antes de decidir. Las condiciones recurrentes se emparejan con soluciones conocidas. El agente no vuelve a aprender la solución de ayer cada mañana.
Remediación curada, aprobada donde importa, auditada por completo.
La superficie de acción es deliberadamente estrecha. El LLM nunca tiene acceso a una shell libre. La remediación es un catálogo explícito de playbooks de Ansible verificados, ejecutados bajo las reglas de aprobación que tú controlas.
Catálogo de recetas
Cada remediación es un playbook de Ansible preaprobado en un catálogo global. Cada una lleva un nivel de riesgo, una categoría y una ruta de reversión cuando corresponde. La lectura y la ejecución están abiertas a tu equipo; crear, actualizar y borrar están restringidos a superadmin, para que los administradores de inquilino no puedan introducir rutas de playbook maliciosas.
Flujo de aprobación
Los incidentes en espera de aprobación muestran el contexto completo — qué observó el agente, qué propone, por qué, cómo sería la reversión. Un clic ejecuta el playbook con la salida en directo transmitida al panel; un clic lo rechaza y lo cierra.
Salida de ejecución en directo
Las ejecuciones de recetas transmiten su salida vía WebSocket directamente a la página de detalle del incidente. Estado por tarea (ok / cambiado / fallido), stdout/stderr expandible por tarea, código de retorno al finalizar. El propio registro de auditoría de la plataforma guarda la salida del playbook al pie de la letra.
Revisiones de verificado y cerrado
Cuando un playbook termina, un agente revisor ejecuta comprobaciones de verificación — el servicio ha vuelto a funcionar, las métricas han vuelto a la normalidad, no hay regresión en otro lugar — antes de cerrar el incidente. Si la verificación falla, el incidente se reabre con los hallazgos del agente.
Post-mortems generados automáticamente
Cada incidente resuelto escribe su propio informe de causa raíz, hilado a partir de la línea de tiempo, la evidencia, el razonamiento del agente, la cadena de aprobaciones y el resultado de la ejecución. Llegas a la revisión semanal con el documento ya terminado.
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.
El andamiaje multi-inquilino para los equipos que realmente operan cosas.
Diseñado desde el principio para equipos de SRE y de servicios gestionados. El cableado es la parte que normalmente tienes que construir tú mismo; aquí viene incluido de fábrica.
Aislamiento multi-inquilino
Servidores, recetas (en lectura), políticas, agentes, registros de auditoría, secretos, secreto de webhook y usuarios están todos acotados por inquilino. La difusión en tiempo real por WebSocket se filtra en el servidor por tenant_id. Un rol de superadmin con suplantación explícita cruza los límites de inquilino cuando la operación lo requiere; todo el resto se mantiene en su carril.
Almacén de secretos cifrado
Claves SSH, tokens bearer, pares de autenticación básica, credenciales de base de datos — almacenados cifrados con AES-256-GCM en reposo. Referenciados por nombre desde los registros de servidor y desde herramientas HTTP personalizadas. La clave de cifrado nunca aparece en la propia base de datos.
Ecosistema de plugins y marketplace
Puntos de extensión para nuevas fuentes de alerta, eventos de hook (notificaciones a slack / correo / pagerduty), backends de almacenamiento y proveedores de LLM. Paquetes preempaquetados en el marketplace combinan una plantilla de agente con skills y herramientas — instálalos con un clic en tu inquilino.
Temporizadores de SLA con escalado por incumplimiento
Las políticas por severidad definen tiempo de reconocimiento, primera respuesta y resolución. Temporizadores en vivo en cada tarjeta de incidente, un indicador de incumplimiento que se pone en rojo al fallar, y reglas de escalado que pueden marcar al agente o avisar a una persona cuando se agota el plazo.
Ventanas de mantenimiento
Planes y programaciones con puertas de aprobación opcionales y recurrencia. Las ventanas de mantenimiento activas suprimen automáticamente la creación de incidentes en los servidores afectados — sin falsas alarmas durante cambios planificados.
Registro de auditoría de solo anexado
Cada acción que cambia estado — crear, actualizar, borrar, ejecutar, aprobar, iniciar sesión, fallo de inicio de sesión — genera una fila. Acotado por inquilino, con la IP capturada (con lógica de proxy de confianza para que X-Forwarded-For no se pueda falsificar), e indexado por recurso, de modo que el filtro de historial por recurso del panel es un solo clic.
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.
¿Quieres verlo funcionando en tus servidores?
La lista de espera es el camino más rápido. Orden de lectura recomendado desde ahí: empieza por la visión general, sigue con el capítulo de detección proactiva y luego instala el daemon.