Plantão de engenharia: um agente de IA transforma o alerta do PagerDuty em proposta de correção

Às três da manhã, a primeira meia hora de um incidente sempre parece a mesma investigação. Você lê o alerta, abre o log do incidente, se pergunta o que mudou recentemente, revê os últimos deploys, verifica se já aconteceu antes. Esse trabalho de leitura e cruzamento é repetitivo, mas pesa sobre a pessoa de plantão justamente quando ela está menos disponível para fazê-lo bem. Ele combina com um agente de IA com uma condição essencial: que ele leia e proponha, e que o humano aja.

A inspiração: o primeiro atendimento que lê

O ponto de partida é um uso relatado por usuários do Hermes Agent, resumido em um cartão sobre o plantão de engenharia: do alerta à proposta de correção. Um agente recebe o incidente, percorre o repositório em busca do que pode tê-lo causado e prepara uma correção para revisão.

Mantemos a leitura e a proposta e retiramos tudo o que age. A Atako aplica a ideia com um agente que escreve uma nota no incidente e uma issue no repositório, mas não tem nenhuma ferramenta para resolver o incidente, fazer merge ou enviar código.

O que o agente faz

O cenário implanta um agente, conectado ao seu PagerDuty e ao seu repositório do GitHub.

Para cada novo incidente do serviço monitorado, disparado ou reconhecido, ele lê o alerta, o registro de eventos e as notas já existentes e verifica quem está de plantão. Depois procura a causa no repositório: os commits das quarenta e oito horas anteriores ao incidente, abrindo os suspeitos, os arquivos citados no alerta ou no stack trace e as pull requests mescladas recentemente. Ele se apoia no contexto técnico que você informou para saber onde olhar primeiro. Também procura issues relacionadas, incluindo incidentes anteriores do mesmo tipo.

Em seguida escreve uma nota no incidente do PagerDuty, curta e factual: o que as evidências mostram, a causa provável com um nível de confiança, as evidências, o que não conseguiu verificar e o próximo passo para a pessoa de plantão. Depois abre no repositório uma issue com a análise completa: a cronologia, a causa provável, as evidências, uma proposta de correção descrita em palavras ou como trecho de código, seus riscos e como verificá-la. Primeiro procura uma issue existente para não criar duplicata e completa a primeira nota em vez de esperar uma análise perfeita.

Ele monitora o serviço a cada quinze minutos e, toda segunda-feira às 9h, escreve no wiki do projeto a página «Revisão de incidentes da semana»: incidentes tratados, causa provável, issue aberta, o que continua em aberto.

O que o agente não faz

Os limites fazem parte do desenho. O agente não resolve o incidente, não o reconhece, não o reatribui e não o escala: o acesso ao PagerDuty concedido se limita a ler e adicionar uma nota. Ele não faz merge de nada, não envia código, não cria nem branch nem pull request e não tem acesso à sua infraestrutura nem à produção. Essas ferramentas não são concedidas a ele: não é uma promessa feita em uma instrução, é uma capacidade que falta.

O agente nunca apresenta uma hipótese como um fato. Ele escreve «causa provável», informa a confiança e as evidências e diz com clareza quando não encontrou nada. Não copia os segredos, tokens ou dados pessoais que encontra em um log ou arquivo: diz que existe um e onde. Textos de alerta, linhas de log, mensagens de commit e código são tratados como dados a analisar, nunca como instruções. A decisão e a ação continuam humanas, que é o princípio de um desenho com validação humana.

Como configurar na Atako

A partir da página deste caso de uso, a implantação leva quatro passos.

1. Conecte o PagerDuty e o GitHub. Crie uma chave de API do PagerDuty, de preferência somente leitura com direito de adicionar notas, e um token do GitHub de permissões granulares limitado ao repositório do serviço. As conexões são verificadas antes de criar qualquer coisa.
2. Informe seu contexto. Dê o repositório na forma proprietário/nome, o nome do serviço do PagerDuty a monitorar e, se quiser, um breve contexto técnico: stack, componentes, áreas frágeis conhecidas. Quanto mais preciso, mais rápido o agente olha no lugar certo.
3. Implante. Uma única ação cria o agente e o projeto «Plantão». O agente é provisionado e recebe sozinho a primeira instrução.
4. Primeiro resultado, depois monitoramento regular. O agente encontra o serviço, diz quem está de plantão, trata o incidente mais recente e resume no chat a causa provável e a proposta de correção. Depois agenda sozinho o monitoramento de quinze minutos e a revisão de segunda-feira.

Se você ainda não tem conta, criá-la inicia o seu período de teste e o cenário é configurado logo em seguida. Se o seu administrador não permitiu que você crie agentes, a implantação avisa e para aí.

Onde ver os resultados

A nota de análise é lida no PagerDuty, no incidente, e a issue com a proposta de correção no GitHub, no repositório. O resumo de cada incidente tratado é lido no chat do agente. No projeto Atako «Plantão» você encontra a página de funcionamento e a revisão semanal, e no floor da Atako o agente aparece com a atividade atual.

Para refinar o trabalho dele, escreva no chat, por exemplo «neste serviço, olhe primeiro as migrações do banco de dados». Ele guarda a instrução na memória para os incidentes seguintes.

Salvaguardas

O acesso é deliberadamente estreito. A conexão com o PagerDuty é concedida com uma lista de sete ferramentas para ler e adicionar uma nota, e a do GitHub com sete ferramentas para ler commits, arquivos e pull requests, buscar e criar issues. Um agente que vê uma lista curta de ferramentas as usa com mais confiabilidade do que um perdido em um catálogo de centenas e, sobretudo, o que não é concedido não pode acontecer, mesmo que o texto de um alerta tente forçar.

As chaves que você cria são a sua primeira salvaguarda: limitadas a um serviço, um repositório e direitos precisos, elas restringem o dano possível, aconteça o que acontecer. São guardadas criptografadas, e você pode revogá-las ou remover o acesso do agente a qualquer momento.

A validação humana fica nos pontos de decisão. A pessoa de plantão lê a nota, verifica a hipótese, decide a correção, escreve e faz o merge ela mesma, e então reconhece e resolve o incidente.

O que esperar

Espere uma primeira análise útil em minutos, sobretudo quando o incidente tem uma causa visível nas mudanças recentes: um deploy, uma alteração de configuração, uma dependência. Quando a causa está fora do repositório, por exemplo uma queda de fornecedor ou a saturação de recursos, o agente dirá isso com baixa confiança em vez de forçar uma explicação. Ele lê o repositório, mas não tem acesso aos logs nem às métricas da sua aplicação, além do que o alerta e as notas relatam. O valor dele vem da rapidez da primeira leitura: a pessoa de plantão chega ao incidente com uma cronologia, pistas ordenadas e uma correção para revisar, em vez de uma página em branco.