O sintoma 

 Um agente relatava que continuava recebendo ligações mesmo estando em pausa. 

Ele seguia o procedimento normal para pausar, mas a fila continuava distribuindo chamadas para ele. O comportamento era intermitente: em alguns momentos a pausa funcionava corretamente; em outros, o agente continuava recebendo chamadas. 

Em troubleshooting, comportamentos intermitentes são um importante sinal de investigação. Quando o mesmo procedimento apresenta resultados diferentes, é necessário entender quais estados ou processos podem estar concorrendo entre si.

A investigação: onde a IA entrou no troubleshooting 

Para agilizar a investigação, utilizamos IA por meio do Kiro CLI, com agentes e subagentes, como apoio ao processo de troubleshooting. 

A IA foi utilizada principalmente para: 

• analisar e organizar grandes volumes de logs; 

• identificar padrões e sequências de eventos; 

• levantar hipóteses sobre o comportamento da fila; 

• correlacionar eventos de pausa, remoção e adição de membros; 

• ajudar a interpretar comandos e comportamentos do Asterisk; 

• comparar diferentes possibilidades para a causa do incidente; 

• direcionar a investigação para os pontos que precisavam ser validados no ambiente. 

Um ponto importante foi que a IA não foi utilizada como fonte única de decisão. As hipóteses levantadas foram confrontadas com o ambiente, com os comandos do Asterisk e com as evidências observadas nos logs e validadas junto aos agentes e subagentes utilizados na investigação. 

Esse processo reduziu significativamente o tempo gasto entre a identificação do sintoma, a formulação das hipóteses e a descoberta da causa raiz. 

A descoberta: dois membros, uma pessoa 

Ao inspecionar a fila, identificamos que o mesmo agente aparecia duas vezes, utilizando dois tipos de interface diferentes. 

Uma das interfaces respeitava a pausa. A outra continuava disponível para receber chamadas. 

Esse foi um ponto importante da investigação: “pausar em todas as filas” não significa necessariamente que todas as interfaces associadas ao agente estejam pausadas. 

No Asterisk, as interfaces são tratadas como membros independentes. Dessa forma, era possível que uma interface estivesse pausada enquanto a outra permanecesse disponível. 

A partir dessa descoberta, a investigação passou a buscar a origem de cada membro.

De onde vinha cada membro? 

Rastreando a origem das interfaces, identificamos duas formas diferentes de gerenciamento: 

Interface 1 — gerenciamento pelo painel administrativo 

• Adicionada pelo painel administrativo; 

• Configurada como membro dinâmico; 

• Mantida como configuração persistente; 

• Armazenada na AstDB, o banco interno do Asterisk; 

• Respeitava o estado de pausa. 

Interface 2 — gerenciamento automatizado 

• Criada por um serviço auxiliar; 

• O serviço monitorava o registro do ramal; 

• Adicionava o membro quando o agente realizava login/registro; 

• Removia o membro quando o registro era perdido; 

• Ao adicionar novamente o membro, não restaurava o estado de pausa. 

A investigação revelou, portanto, duas automações diferentes atuando sobre o mesmo recurso. 

Duas vias de automação gerenciando a mesma fila, sem conhecimento uma da outra, criavam a condição para a duplicidade.

Como a IA ajudou a encontrar a causa 

Nesse ponto, a análise dos logs foi fundamental. 

Utilizamos a IA para auxiliar na leitura e correlação dos eventos do . Em vez de analisar os registros apenas de forma individual, buscamos reconstruir a linha do tempo do incidente.queue_log 

A análise permitiu relacionar eventos que, isoladamente, poderiam parecer normais: 

PAUSEALL 
      ↓ 
REMOVEMEMBER 
      ↓ 
ADDMEMBER 
      ↓ 
ENTERQUEUE 
      ↓ 
CONNECT 

A partir dessa sequência, foi possível levantar uma hipótese mais precisa: 

O agente era pausado, mas posteriormente o serviço auxiliar removia e adicionava novamente o membro. Como o novo membro não recebia o estado de pausa, ele voltava a ficar disponível para chamadas. 

Essa hipótese foi então validada tecnicamente no ambiente. 

Esse foi um dos principais ganhos proporcionados pelo uso da IA: transformar uma grande quantidade de informações dispersas em uma sequência lógica de eventos, facilitando a identificação da relação entre eles.

O contou a história queue_log 

Depois da correlação dos eventos, a sequência ficou clara: 

… PAUSEALL 
    ← agente realizou a pausa 

… REMOVEMEMBER 
    ← serviço auxiliar removeu o membro após detectar o desregistro… ADDMEMBER 
    ← serviço auxiliar adicionou novamente o membro    ← o estado de pausa não foi restaurado… ENTERQUEUE / CONNECT 
    ← uma chamada chegou e foi atendida pelo agente 

O comportamento que inicialmente parecia aleatório passou a ter uma explicação técnica. 

Não era a pausa “falhando”. 

Era um novo membro sendo criado sem o estado de pausa.

A armadilha da correção temporária 

A primeira tentativa foi remover o membro duplicado pela linha de comando. 

A ação funcionou, mas apenas temporariamente. 

O motivo estava relacionado à diferença entre estado em execução e persistência. 

Remover um membro diretamente da execução altera o estado atual da fila, mas não necessariamente elimina a configuração persistida que pode recriá-lo posteriormente. 

Como o membro estava persistido na AstDB, ele poderia voltar após eventos como: 

• reload; 

• restart; 

• alterações realizadas pelo painel; 

• outros processos responsáveis por recarregar a configuração. 

Ou seja: 

o sintoma havia sido removido, mas a origem continuava existindo.

A solução definitiva

A correção definitiva foi realizada pela camada de gerenciamento de mais alto nível: o painel administrativo. 

Dessa forma, foi possível remover a configuração persistente e, ao mesmo tempo, retirar o membro da fila ativa. 

Após a correção, foi mantida apenas a interface gerenciada pelo serviço auxiliar, eliminando a duplicidade e mantendo o fluxo de gerenciamento definido para aquele ambiente. 

A solução não foi simplesmente “remover o membro”. 

Foi eliminar a fonte que fazia o membro voltar.  

O papel da IA na resolução 

O uso de IA nesse chamado trouxe ganhos principalmente em três etapas: 

1. Aceleração do troubleshooting 

A IA ajudou a organizar as informações disponíveis e direcionar a investigação para hipóteses mais relevantes, reduzindo o tempo necessário para chegar aos pontos críticos do ambiente. 

2. Análise e correlação dos logs 

Em vez de observar cada evento isoladamente, utilizamos a IA para auxiliar na construção da sequência temporal dos acontecimentos. 

Isso facilitou a identificação da relação entre: 

pausa → remoção → nova adição → perda da pausa → recebimento da chamada. 

3. Validação das hipóteses 

Os agentes e subagentes utilizados no Kiro CLI ajudaram a explorar diferentes possibilidades e questionar as hipóteses levantadas durante a investigação. 

As conclusões, entretanto, foram validadas no ambiente real, utilizando comandos, configurações, comportamento observado e evidências dos logs. 

Dessa forma, a IA atuou como uma ferramenta de apoio ao raciocínio técnico, acelerando a investigação sem substituir a análise e a validação realizadas pela equipe.

As lições que ficam 

1. Comportamento intermitente merece investigação de estado 

Quando um problema acontece “às vezes”, procure estados diferentes ou processos concorrentes antes de classificá-lo como aleatório. 

2. Entenda de onde o estado é criado 

Não basta remover o recurso. É necessário descobrir quem o cria, quem o altera e quem pode recriá-lo. 

3. Evite múltiplas automações para o mesmo recurso 

Duas automações atuando sobre a mesma fila podem produzir estados inconsistentes e comportamentos difíceis de reproduzir. 

4. Diferencie execução de persistência 

Uma alteração realizada “ao vivo” pode resolver o problema naquele momento, mas não necessariamente elimina a configuração que será restaurada posteriormente. 

5. Use IA para aumentar a capacidade de investigação 

IA pode ser especialmente útil em troubleshooting para: 

• logs analisar; 

• encontrar padrões; 

• eventos correlacionar; 

• estruturar hipóteses; 

• sugerir caminhos de investigação; 

• explicar comportamentos técnicos; 

• acelerar a documentação da solução. 

Mas a evidência precisa continuar sendo validada no ambiente. 

6. Logs transformam suspeitas em evidências 

A sequência de eventos registrada pelo sistema permitiu sair de uma percepção de “comportamento aleatório” para uma explicação técnica baseada em evidências. 

Conclusão

O problema inicialmente parecia simples: 

“O agente está em pausa, mas continua recebendo ligações.” 

A investigação mostrou que a causa estava em uma questão de arquitetura e gerenciamento de estado: dois membros representavam o mesmo agente, sendo controlados por mecanismos diferentes. 

O uso de IA com Kiro CLI, agentes e subagentes contribuiu para agilizar o troubleshooting, analisar os logs, correlacionar eventos e direcionar a investigação até a causa raiz. As hipóteses foram posteriormente validadas com evidências do ambiente. 

O chamado, que poderia exigir uma investigação prolongada, foi solucionado em poucas horas. 

A principal lição não foi apenas sobre Asterisk. 

Foi sobre troubleshooting: 

Não basta corrigir o sintoma. É preciso entender de onde o estado vem, quem o altera e o que pode recriá-lo. 

E, nesse processo, a IA pode atuar como um acelerador do raciocínio técnico — transformando dados, logs e hipóteses em uma investigação mais rápida, estruturada e eficiente. 

Tags: #Asterisk #VoIP #Telecom #Troubleshooting #PBX #CloudOps #Sustentacao #IA #Kiro #GenAI