Como a OpenCo automatizou alertas do Amazon EBS com Amazon Bedrock

Por Marcelo Oliveira, Arquiteto de Soluções na AWS; Jefferson Amará, Líder Técnico de Inteligência Artificial na Open Co; Rafael Ferreira, Engenheiro SRE na Open Co; Luiz Miguel Batista, Estagiário de Inteligência Artificial na Open Co.

Sobre a OpenCo

A OpenCo é a maior fintech de crédito sem garantia do Brasil, tendo concedido mais de R$ 5 bilhões em crédito e atendido a mais de 337 mil clientes.

A empresa opera através das marcas Geru (para pessoas físicas) e Biz (para pequenas e médias empresas), com o compromisso de reinventar para incluir e transformar o poder de compra do brasileiro.

Desafios dos Alertas Recorrentes

Nas operações de confiabilidade (SRE), a OpenCo identificou em dados históricos que uma parcela expressiva dos incidentes, cerca de 55% do total de alertas de produção estava concentrado em alertas relacionados a volumes do Amazon EBS, e que aproximadamente 43% dos acionamentos ocorridos fora do expediente tinham a mesma origem.

Embora esses alertas não fossem complexos, o volume e a repetitividade comprometiam a eficiência operacional. Neste contexto, eficiência refere-se à capacidade da equipe de SRE de responder rapidamente a incidentes críticos e focar em tarefas de maior valor agregado, em vez de gastar tempo e recursos em alertas recorrentes e de baixa complexidade. Diante desse cenário, havia uma oportunidade clara de aplicar automação inteligente para melhorar a eficiência:

• Delegar a triagem de casos de padrões conhecidos.
• Resolver alertas com agentes autônomos.

Pilares da Solução

Construir uma solução baseada em dois agentes autônomos que trabalham de forma coordenada na detecção, análise e resolução desses alertas.

O primeiro é o agente de monitoramento, responsável por coletar métricas através do agente do ElasticSearch. A partir disso, regras de alarme são criadas usando o ElastAlert e roteados para o OpsGenie. Esse agente coleta informações contextuais, como métricas do volume, logs recentes, região, conta AWS e consulta no Amazon Bedrock Knowledge Bases estruturada no Amazon Bedrock. Essa base contém runbooks internos e procedimentos alinhados à ISO 27001, permitindo que o agente formule um plano de ação inicial.

Uma vez consolidado o contexto, o agente de monitoramento aciona o agente de resolução. Esse segundo agente utiliza o modelo Claude 3.5 no Amazon Bedrock, em conjunto com a técnica de Retrieval-Augmented Generation (RAG), para validar o diagnóstico e decidir os próximos passos. A partir daí, são executadas ações corretivas diretamente no ambiente, invocando APIs da AWS como Amazon EC2, Amazon EBS e AWS Systems Manager.

Durante todo o processo, são registradas decisões e ações em tempo real em um canal do Slack, garantindo transparência para o time. Ao final, o incidente é encerrado com a geração de um relatório pós-incidente no Confluence, que alimenta continuamente a base de conhecimento.

Nos casos em que a confiança do agente não é suficiente ou quando o procedimento não pode ser concluído autonomamente, é escalado o incidente para um analista humano. Nestes cenários, o engenheiro recebe o contexto completo já preparado pelo agente, incluindo logs, hipóteses de causa e tentativas de mitigação.

SRE Monitor Agent

Figura 1: Diagrama Arquitetural – SRE Monitor Agent

SRE Resolution Agent

Figura 2: Diagrama Arquitetural – SRE Resolution Agent

Fluxo

O elastalert detecta a anomalia através de queries feitas em indexes do ElasticSearch com dados inseridos por agentes de monitoramento do próprio ElasticSearch. O agente de monitoramento recebe o alerta através de eventos disparados pelo OpsGenie no Slack, consulta o Amazon Bedrock Knowledge Bases e identifica os procedimentos recomendados para aquele tipo de evento. Em seguida, o agente de resolução valida o diagnóstico e executa as ações necessárias por meio das integrações com as APIs da AWS.

Enquanto isso, cada passo é comunicado no Slack, permitindo o acompanhamento em tempo real. Quando a condição é normalizada, o agente gera um relatório pós-incidente no Confluence. Caso seja necessário escalonar, um tíquete é automaticamente aberto no Jira com todos os detalhes já coletados.

Figura 3: Exemplo mensagem – Jira Service Management ChatOps

Figura 4: Exemplo mensagem – SRE Monitor Agent

Figura 5: Exemplo mensagem – SRE Agent

Resultados

A adoção dos agentes demonstrou ganhos claros e mensuráveis. É possível resolver de forma autônoma cerca de 95% dos alertas de Amazon EBS. Apenas 5% dos casos são escalados para analistas, que recebem todo o contexto previamente reunido. O tempo médio de resolução foi reduzido em 75%, de doze minutos para aproximadamente três minutos, reduzindo o MTTR (tempo médio de reparo), garantindo maior disponibilidade para os sistemas.

Além da redução de tempo, houve padronização da execução: onde todas as respostas seguem runbooks aprovados, eliminando variações na abordagem e consolidando boas práticas. Cada incidente resolvido alimenta automaticamente a base de conhecimento, fortalecendo o ciclo de melhoria contínua.

Conclusão

Com a adoção de agentes de IA generativa, é possível transformar a forma de lidar com alertas de infraestrutura. Com Amazon Bedrock, arquitetura serverless e integrações corporativas, foi possível automatizar a resolução de 95% destes casos e reduzir o tempo médio de resposta para apenas três minutos.

Essa iniciativa mostra como é possível aplicar IA generativa de forma prática em operações críticas de SRE, convertendo rotinas repetitivas em processos autônomos e consistentes. Ao mesmo tempo, remover o overhead operacional das equipes para focarem em iniciativas de maior valor estratégico.

Autores

	Marcelo Oliveira é Solutions Architect no time AWS. Apoia clientes do setor DNB (Digital Native Business) em sua jornada para nuvem AWS. Tem foco em projetos que envolvam arquiteturas distribuídas e escaláveis, além de grande interesse na área de Infraestrutura, Networking, Segurança e Containers.
	Jefferson Amará é Líder Técnico de Inteligência Artificial na Open Co e Mestre em Ciência da Computação pela UFJF. Atua na arquitetura e implementação de soluções de inteligência artificial aplicadas a processos de embedded finance. É entusiasta de inteligência artificial, engenharia de sistemas, educação tecnológica e liderança.
	Luiz Miguel Batista é Estagiário de Inteligência Artificial na Open Co, com atuação focada em projetos de automação de processos utilizando agentes de IA. Apresenta grande entusiasmo pelas áreas de ciência de dados e inteligência artificial.
	Rafael Junqueira Ferreira é SRE na Open Co atuando em toda a cadeia de monitoramento e resiliência dos serviços da empresa. Apresenta interesse em soluções envolvendo Inteligência Artificial cursando um mestrado na área.