Como funciona
O pipeline de fechamento de ciclo, cena por cena.
O OpenRemedy é construído em torno de um único ciclo agêntico: vigiar continuamente, reconhecer o desvio, classificar e encaminhar, propor uma correção, aprovar onde importa, executar, verificar e escrever o post-mortem. Cada servidor passa por três modos de confiança escalonados — observar, simulação, ao vivo — de modo que a autonomia é um gradiente concedido por etapas, não um interruptor único. As páginas a seguir percorrem o ciclo cena por cena.
Sinais do servidor, da plataforma e de fora.
O OpenRemedy roda um pequeno daemon em cada servidor gerenciado. Ele reporta fatos a cada quinze segundos e executa as verificações de saúde que a plataforma enviou — cada uma assinada com HMAC, de modo que uma configuração adulterada não consiga injetar comandos arbitrários no host.
Servidores sem agente também ficam cobertos. Sondagens programadas rodam a partir da plataforma em uma cadência configurável, e as patrulhas de IA inspecionam periodicamente a frota em busca de condições para as quais ninguém escreveu uma regra. Cada sinal alimenta o mesmo pipeline de fechamento de ciclo mais adiante.
Um incidente se abre no momento em que algo sai do lugar.
Seja o sinal vindo do daemon, de uma sondagem programada, de um agente em patrulha ou de uma fonte de alerta externa como Alertmanager ou Datadog, ele cai no mesmo lugar: um novo incidente com severidade, tipo, contexto do servidor e a evidência relevante já anexada.
O piso de detecção é de cerca de quinze segundos para condições de limiar no daemon, e de menos de um segundo para alertas por push. A maioria dos problemas chega aqui muito antes de afetar qualquer usuário.
Sustained CPU on api-prod-03
opened 41 seconds ago · daemon · resolved automatically
Triage · Atlas
Pattern matches a recurring spike from the daily ingest job. Routed to the diagnose stage.
Diagnose · Forge
Captured a fresh top -bn1 snapshot. Top consumer: python ingest_worker.py at 89% (expected behaviour during ingest).
Resolved · Default SRE
Transient — load returning to baseline. No action taken. Marked for monitoring.
A triagem encaminha para o especialista certo.
Um agente de triagem lê o incidente, procura resoluções anteriores para condições parecidas e decide quem cuida dele. Padrões recorrentes são casados com soluções conhecidas; problemas inéditos recebem mais investigação.
O agente registra o próprio raciocínio conforme avança, de modo que a trilha da decisão fica visível depois — nada de um opaco "a IA fez alguma coisa".
Linha do tempo de triagem · Atlas
Busca por resoluções anteriores
Encontrados 3 incidentes correspondentes em api-prod-03 nos últimos 30 dias. Todos resolvidos pela mesma receita.
Classificado
cpu_high · severidade alta · padrão: pico de tarefa agendada
Repassado
Encaminhado para a etapa de diagnóstico com o contexto do pico recorrente anexado.
Evidência em primeiro lugar, só com ferramentas em sandbox.
O agente de diagnóstico coleta evidências usando um conjunto curado de ferramentas somente leitura — status de serviço, trechos de log, capturas de processo, introspecção de containers. Ele raciocina sobre a causa raiz e propõe uma correção.
O LLM nunca tem acesso a um shell livre. Cada chamada de diagnóstico é um verbo tipado contra o catálogo em sandbox da plataforma. Operadores podem estender esse catálogo, mas cada nova ferramenta passa pelo mesmo mecanismo de escape de parâmetros e de lista de hosts permitidos que as ferramentas embutidas.
Correções de baixo risco rodam. As arriscadas esperam por você.
Cada receita carrega um nível de risco explícito, definido pelo operador que a escreveu. Agentes autônomos podem executar por conta própria as correções de baixo risco; as de risco médio ou acima sempre pausam esperando aprovação humana. O LLM não tem como avaliar a própria segurança.
As solicitações de aprovação mostram o contexto completo: o que o agente propõe, por quê, o que poderia dar errado e como foram as execuções anteriores da mesma receita. Um clique e a plataforma executa; um clique e ela desiste.
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.
O Ansible aplica a correção. A plataforma cuida da auditoria.
A receita aprovada é despachada para um worker que executa o playbook de Ansible correspondente via SSH. A saída é transmitida ao painel em tempo real, para que você acompanhe a execução, intervenha se precisar, e veja exatamente o que mudou no host. No modo simulação, o mesmo playbook simula sem tocar no estado real — você vê o que teria acontecido antes de deixar acontecer de verdade.
Um agente revisor verifica a resolução depois que o playbook termina — o serviço voltou a funcionar, as métricas voltaram ao normal, não há regressão em outro lugar — e só então encerra o incidente.
Cada incidente escreve o seu próprio post-mortem.
A plataforma costura a linha do tempo, as evidências, o raciocínio do agente, a cadeia de aprovações e o resultado da execução em um único relatório. Se uma pessoa interveio, o raciocínio dela fica registrado junto ao do agente.
Padrões recorrentes se tornam candidatos a novos playbooks pré-aprovados. O runbook da equipe cresce por conta própria, curado pelo trabalho que a plataforma realmente vem fazendo.
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.
Essa é a forma completa.
Toda fonte de detecção, todo agente, toda receita segue o mesmo ciclo. O painel, a trilha de auditoria e a documentação são organizados em torno dele.