O SRE autônomo com IA para frotas Linux.
O OpenRemedy é o seu SRE autônomo de confiança para frotas Linux. Ele observa, diagnostica e aplica a correção em três níveis crescentes de confiança por servidor — observar, simulação, ao vivo. Criado por operadores com mais de 20 anos de produção. Para as máquinas que o Kubernetes não alcança.
Já ficou curioso? Veja como funciona.
Sustained CPU on api-prod-03
opened by daemon · 00:00 ago
Agent pipeline starting…
Atlas is being assigned to the incident.
Reprodução de um pico real de CPU. Detectado, classificado e encerrado automaticamente em menos de três segundos.
A premissa
Detectar é a parte fácil. Fechar o ciclo é o trabalho de fato.
A maioria das plataformas avisa que algo quebrou e passa o aviso para uma pessoa. O OpenRemedy recebe sinais de todas as fontes que você já tem e executa o mesmo ciclo que antes era feito por uma pessoa — diagnosticar, decidir, agir, documentar — sob o seu controle, com a trilha de auditoria que as equipes de compliance esperam.
No servidor
Um pequeno agente em Go reporta o estado do sistema e executa verificações de saúde assinadas pela plataforma a cada 15 segundos.
Na plataforma
Sondagens programadas com Ansible cobrem os servidores sem agente, e as patrulhas de IA procuram padrões fora do comum.
De fora
O recebimento de webhooks aceita alertas do Alertmanager, Grafana, Datadog ou qualquer fonte HTTP — assinados com HMAC.
Do operador
Criação manual de incidentes para consultas pontuais; o agente executa a verificação solicitada na hora e retorna o resultado.
Gradientes de confiança, não autonomia de tudo ou nada
Rápido onde precisa ser. Cuidadoso onde não pode ser diferente.
Cada servidor vive em um de três modos escalonados — observar (o agente vigia, mas nunca age), simulação (simula a correção e mostra exatamente o que teria acontecido) e ao vivo (aplica a correção: as de baixo risco são autônomas e as de médio risco ou mais dependem de aprovação humana). Você promove um servidor de modo quando vê que o agente merece essa confiança. O LLM nunca decide por conta própria que algo é seguro o suficiente para ser executado.
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.
Pronto para auditoria por construção
Cada incidente escreve o seu próprio post-mortem.
A plataforma documenta o que aconteceu, o que o agente raciocinou, o que foi aprovado, quem aprovou e como a correção foi verificada. Você chega à reunião semanal — ou à próxima auditoria de compliance — com o relatório já pronto.
Quer uma vaga?
Ainda estamos ensinando a plataforma a operar frotas Linux com segurança — por enquanto usamos nós mesmos, na nossa própria infraestrutura de produção. Deixe seu e-mail e avisamos quando a história de segurança estiver madura o suficiente para colocar na sua.
Sem spam, sem gotejamento de marketing — um único e-mail quando sua vaga abrir.