OR
OpenRemedy
Para times enterprise e setores regulados

O arcabouço que você pode auditar e controlar.

O OpenRemedy dá aos times de plataforma e SRE um gradiente de confiança documentado por servidor e uma trilha de auditoria somente-inserção — não um interruptor de autonomia caixa-preta.

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

O custo da resposta manual a incidentes

O que aquele chamado às 3 da manhã já custa a você.

Um engenheiro sênior gasta de 20 a 40 minutos comprovando qual correção conhecida se aplica antes de agir. Esse custo já existe hoje, em todo plantão, quer você use o OpenRemedy ou não.

Número ilustrativo, não um resultado real de cliente — o OpenRemedy ainda não tem clientes externos, por design. Isso modela o custo que todo time de SRE já carrega.

20-40 min

Tempo de engenharia por incidente, antes do OpenRemedy

~27 s

Tempo mediano que o pipeline do OpenRemedy leva na mesma investigação

Casos de uso

Feito para o que já está rodando em produção.

Frotas Docker em produção

Um especialista de SRE dedicado a Docker diagnostica incidentes em hosts de containers com ferramentas reais — uso de disco, inspeção de containers, detalhe no nível de processo — não um runbook genérico.

Operações de hipervisor e Proxmox

Um especialista de domínio separado trata incidentes na camada de hipervisor de forma distinta dos hosts de containers — o agente certo, com as ferramentas certas, para cada tipo de servidor.

Manutenção planejada sem downtime surpresa

Os planos de manutenção rodam sob estratégias rolling, canary ou por anéis, com portas de aprovação em cada etapa — o mesmo modelo de controle do operador que rege a remediação de incidentes.

Compliance e auditoria

Toda ação que muda estado grava uma linha de auditoria somente-inserção. A escada de confiança registra quem concedeu a autonomia, quando e com base em qual evidência.

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 implantação e segurança

Controle self-hosted, execução controlada.

Todo o plano de controle — banco de dados, fila, cofre de segredos, gateway de modelos — é feito para rodar dentro do seu próprio perímetro. Toda remediação passa pela escada de confiança e por uma porta de aprovação em duas etapas antes de tocar a produção.

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.

Integra com o que você já usa

Não é mais uma ilha para gerenciar.

Plugins e webhooks conectam o OpenRemedy ao Slack, Microsoft Teams, ServiceNow, Jira e endpoints de webhook genéricos — incidentes e aprovações aparecem onde seu time já trabalha.

Slack
Microsoft Teams
ServiceNow
Jira
Webhook

Fale com a gente sobre a sua frota.

O OpenRemedy está em teste privado. Entre na lista de espera para ser um dos primeiros operadores enterprise com quem vamos trabalhar.