Funcionalidades
O ciclo agêntico de SRE, a fundo.
Quatro pilares: sinais de entrada, raciocínio autônomo, ação controlada e o tecido operacional que torna tudo isso usável em uma equipe de operações real. Detectar é a entrada; fechar o ciclo é o trabalho. Cada seção lista as capacidades concretas que já vêm incluídas.
Cinco caminhos independentes para alimentar o ciclo do agente.
O OpenRemedy não depende de um único sinal. Cinco mecanismos rodam ao mesmo tempo, com cobertura sobreposta, de modo que um alarme perdido não signifique um incidente perdido — e todos convergem para o mesmo pipeline de fechamento de ciclo.
Monitores contínuos do daemon
Um pequeno agente em Go em cada servidor gerenciado verifica a saúde do sistema a cada quinze segundos. CPU, memória, disco, portas, serviços, processos, padrões de log, containers Docker — tipos de monitor já embutidos que você pode combinar em políticas. Verificações de shell personalizadas usam o mesmo canal, assinadas pela plataforma, de modo que uma configuração adulterada não consiga injetar comandos arbitrários no host.
Sondagens programadas do lado da plataforma
Servidores sem daemon continuam cobertos. Receitas marcadas como recipe_check disparam em uma programação configurável, rodam como playbooks de Ansible a partir da plataforma, e os resultados passam por um avaliador com LLM que decide aprovado / reprovado com todo o contexto.
Agentes de IA em patrulha
Intervalos de patrulha por agente deixam a IA percorrer a frota por conta própria, procurando anomalias para as quais você não escreveu uma regra. O silêncio das 3 da manhã que não devia ser silêncio, a carga que ficou plana, o serviço que reiniciou três vezes em uma hora — o agente abre um incidente com o próprio raciocínio anexado.
Recebimento de webhooks
As ferramentas de monitoramento que você já usa se conectam via webhook assinado com HMAC. Alertmanager, Grafana, Datadog, PagerDuty, clientes HTTP personalizados — qualquer fonte que envie dados converge para o mesmo pipeline de incidentes. Latência inferior a um segundo entre o alerta e o incidente no banco de dados.
Consultas manuais pontuais
Operadores podem abrir um incidente personalizado com uma pergunta livre. O agente executa a verificação solicitada na hora, contra o servidor real, e retorna o resultado — útil para investigações pontuais que não justificam um monitor permanente.
Agentes especializados, cada um com seu papel e seu nível de confiança.
Cada incidente passa por um pipeline de invocações de agente distintas. Cada etapa tem seu próprio prompt, seu próprio orçamento de ferramentas e seu contexto restrito por tenant. Nenhuma chamada de LLM carrega o peso todo.
Pipeline de cinco etapas
Triagem → diagnóstico → validação → execução → revisão. Incidentes do tipo personalizado pulam a execução e são resolvidos após o diagnóstico. Cada etapa registra suas chamadas de ferramenta e seu raciocínio como eventos discretos, de modo que a trilha de auditoria mostra o que o agente pensou e por quê — não só o que ele fez.
Porta de confiança × risco
Cada agente tem um nível de confiança (autônomo / supervisionado / manual). Cada receita tem um nível de risco (baixo / médio / alto). A porta de controle da plataforma roda no servidor; o LLM não pode se autoaprovar. A confiança autônoma só permite execução automática em risco baixo. Todo o resto passa por uma pessoa.
Skills como módulos de conhecimento
Documentos em markdown associados a um agente — "operação de nginx", "fundamentos de PostgreSQL", "triagem de Docker" — carregados no contexto em tempo de execução. Os skills refinam o raciocínio de domínio sem forçar um único prompt gigante. Catálogo embutido mais autoria por tenant.
Substituições de prompt por tenant
A plataforma já vem com templates Jinja padrão; qualquer tenant pode substituir o prompt de qualquer etapa do pipeline direto do painel. Ajuste para a sua frota, sua terminologia, suas convenções de escalonamento — sem tocar em código.
Consciência de resoluções anteriores
A triagem busca em incidentes históricos por padrões parecidos antes de decidir. Condições recorrentes são casadas com soluções já conhecidas. O agente não reaprende a solução de ontem todas as manhãs.
Remediação curada, aprovada onde importa, totalmente auditada.
A superfície de ação é deliberadamente estreita. O LLM nunca tem acesso a um shell livre. A remediação é um catálogo explícito de playbooks de Ansible verificados, executados sob as regras de aprovação que você controla.
Catálogo de receitas
Toda remediação é um playbook de Ansible pré-aprovado em um catálogo global. Cada uma carrega um nível de risco, uma categoria e um caminho de rollback quando aplicável. Leitura e execução ficam abertas para a sua equipe; criar / atualizar / excluir ficam restritos ao superadmin, para que administradores de tenant não consigam injetar caminhos de playbook maliciosos.
Fluxo de aprovação
Incidentes esperando aprovação mostram o contexto completo — o que o agente observou, o que ele propõe, por quê, como seria o rollback. Um clique executa o playbook com a saída em tempo real transmitida para o painel; um clique rejeita e encerra.
Saída de execução em tempo real
As execuções de receitas transmitem a saída via WebSocket direto para a página de detalhe do incidente. Status por tarefa (ok / alterado / falhou), stdout/stderr expansível por tarefa, código de retorno ao concluir. O próprio log de auditoria da plataforma guarda a saída do playbook ao pé da letra.
Revisões de verificado e encerrado
Depois que um playbook termina, um agente revisor executa verificações — o serviço voltou a funcionar, as métricas voltaram ao normal, não há regressão em outro lugar — antes de encerrar o incidente. Se a verificação falhar, o incidente é reaberto com as descobertas do agente.
Post-mortems gerados automaticamente
Cada incidente resolvido escreve o seu próprio relatório de causa raiz, costurado a partir da linha do tempo, das evidências, do raciocínio do agente, da cadeia de aprovações e do resultado da execução. Você chega à reunião semanal com o documento já pronto.
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.
Estrutura multi-tenant para equipes que realmente operam coisas.
Construído desde o início para equipes de SRE e de serviços gerenciados. A parte de encanamento é o que normalmente você precisa construir por conta própria; aqui ela já vem de fábrica.
Isolamento multi-tenant
Servidores, receitas (leitura), políticas, agentes, logs de auditoria, segredos, o segredo do webhook e usuários — tudo isolado por tenant. A difusão em tempo real via WebSocket é filtrada no servidor por tenant_id. Um papel de superadmin com personificação explícita cruza os limites de tenant quando a operação exige; todo o resto fica na sua faixa.
Cofre de segredos criptografado
Chaves SSH, tokens bearer, pares de autenticação básica, credenciais de banco de dados — armazenados criptografados com AES-256-GCM em repouso. Referenciados por nome a partir dos registros de servidor e de ferramentas HTTP personalizadas. A chave de criptografia nunca aparece no próprio banco de dados.
Ecossistema de plugins e marketplace
Pontos de extensão para novas fontes de alerta, eventos de hook (notificações no slack / e-mail / pagerduty), backends de armazenamento e provedores de LLM. Pacotes prontos no marketplace combinam um template de agente com skills e ferramentas — instale com um clique no seu tenant.
Temporizadores de SLA com escalonamento por violação
Políticas por severidade definem tempo de reconhecimento, primeira resposta e resolução. Temporizadores em tempo real em cada card de incidente, indicador de violação que fica vermelho ao ser perdido, e regras de escalonamento que podem marcar o agente ou avisar uma pessoa quando o prazo esgota.
Janelas de manutenção
Planos e agendamentos com portas de aprovação opcionais e recorrência. Janelas de manutenção ativas suprimem automaticamente a criação de incidentes nos servidores afetados — sem alarmes falsos durante mudanças planejadas.
Log de auditoria somente-anexação
Toda ação que muda estado — criar, atualizar, excluir, executar, aprovar, login, falha de login — gera uma linha. Isolada por tenant, com o IP capturado (com lógica de proxy confiável para que o X-Forwarded-For não possa ser falsificado), e indexada por recurso, de modo que o filtro de histórico por recurso do painel é um único clique.
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.
Quer ver funcionando nos seus servidores?
A lista de espera é o caminho mais rápido. Ordem de leitura recomendada a partir daí: comece pela visão geral, siga para o capítulo de detecção proativa e depois instale o daemon.