OR
OpenRemedy
Para equipos empresariales y sectores regulados

El andamiaje que puedes auditar y controlar.

OpenRemedy ofrece a los equipos de plataforma y SRE un gradiente de confianza documentado por servidor y un registro de auditoría de solo escritura — no un interruptor de autonomía de caja negra.

https://openremedy.io/
highcpu_high · #7c3d

Sustained CPU on api-prod-03

opened by daemon · 00:00 ago

open
SLA · 00:00 / 04:00

Agent pipeline starting…

Atlas is being assigned to the incident.

agent pipeline startinglive · ws

El costo de la respuesta manual a incidentes

Lo que ya te cuesta esa alerta de las 3 de la mañana.

Un ingeniero senior dedica entre 20 y 40 minutos a comprobar qué solución conocida aplica antes de actuar. Ese costo existe hoy, en cada turno de guardia, uses o no OpenRemedy.

Cifra ilustrativa, no un resultado real de cliente — OpenRemedy aún no tiene clientes externos, por diseño. Esto modela el costo que ya carga todo equipo de SRE.

20-40 min

Tiempo de ingeniería por incidente, antes de OpenRemedy

~27 s

Tiempo mediano que el pipeline de OpenRemedy tarda en la misma investigación

Casos de uso

Pensado para lo que realmente corre en producción.

Flotas Docker en producción

Un especialista SRE dedicado a Docker diagnostica incidentes de hosts de contenedores con herramientas reales — uso de disco, inspección de contenedores, detalle a nivel de proceso — no un runbook genérico.

Operaciones de hipervisor y Proxmox

Un especialista de dominio independiente gestiona los incidentes a nivel de hipervisor de forma distinta a los de hosts de contenedores — el agente correcto, con las herramientas correctas, para cada tipo de servidor.

Mantenimiento planificado sin caídas sorpresa

Los planes de mantenimiento corren bajo estrategias rolling, canary o por anillos, con puertas de aprobación en cada paso — el mismo modelo de control del operador que rige la remediación de incidentes.

Cumplimiento y auditoría

Cada acción que cambia estado escribe una fila de auditoría de solo escritura. La escalera de confianza registra quién otorgó la autonomía, cuándo y con base en qué evidencia.

highcpu_high

Sustained CPU on api-prod-03

opened 41 seconds ago · daemon · resolved automatically

resolved
  1. Triage · Atlas

    Pattern matches a recurring spike from the daily ingest job. Routed to the diagnose stage.

  2. Diagnose · Forge

    Captured a fresh top -bn1 snapshot. Top consumer: python ingest_worker.py at 89% (expected behaviour during ingest).

  3. Resolved · Default SRE

    Transient — load returning to baseline. No action taken. Marked for monitoring.

3 tool calls · 2.4s wallView incident

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.

Anyone with role admin can approve

Postura de despliegue y seguridad

Control autoalojado, ejecución controlada.

Todo el plano de control — base de datos, cola, almacén de secretos, gateway de modelos — está diseñado para correr dentro de tu propio perímetro. Cada remediación pasa por la escalera de confianza y una puerta de aprobación en dos etapas antes de tocar producción.

Post-incident report · auto-generated

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.

Se integra con lo que ya usas

No es una isla más que administrar.

Plugins y webhooks conectan OpenRemedy con Slack, Microsoft Teams, ServiceNow, Jira y endpoints de webhook genéricos — incidentes y aprobaciones aparecen donde tu equipo ya trabaja.

Slack
Microsoft Teams
ServiceNow
Jira
Webhook

Hablemos de tu flota.

OpenRemedy está en fase de pruebas privadas. Únete a la lista de espera para ser uno de los primeros operadores empresariales con los que trabajemos.