Vou ser bem honesto, sou uma das pessoas que não aguenta mais ouvir sobe AI na tecnologia, em todo evento que eu vou ela esta lá, a AI, LLMs, IA generativa, agentes inteligentes, ..o futuro do futuro é uma IA geral… gente, fala sério… não aguento mais ouvir tudo isso. Mas, como profissional de TI que somos, não podemos ignorar, temos estudar o tema, e é importante saber separar o que é hype, o que é “espuma” e buscar algo que se aproxime da nossa realidade e que traga de forma eficaz alguma melhora para o dia a dia.

Uma das coisas que eu mais tenho defendido é o uso de um assistente de AI, para apoiar no dia a dia dos times DevOps/SRE a resolver problemas e fazer tarefas que não são priorizadas para ser feita. Nós escolhemos um assiste de IA que funciona em modo “CLI/BASH” o que se integrou muito bem ao fluxo de trabalho do time.

A experiência tem sido bastante positiva:

• Criação de documentação de código, de processos e fluxos de trabalho complexos são realizados em poucos minutos;
• Analisar código com bug ficou muito rápido;
• Propor MRs e ajuste mais ágil.

Agora, sem a menor sombra de dúvidas, onde tivemos maior ganho foi em utilizar o assistente para fazer troubleshooting. É claro, para fazer um troubleshooting assistido é preciso ter conhecimento técnico.

Compartilho com vocês um dos troubleshooting assistido que tivemos recentemente, foi uma falha em um POD do ActiveMQ com erro de volume do Longhorn. Essa investigação e resolução foi conduzida pelo Techleads do time. O trabalho dele nesse processo foi conectar o assinstente ao cluster e apontar o erro e a partir deste ponto dizer “YES” ou “NO” para o assiste de AI. Mas não se enganem, é importante destacar que esse tipo de abordagem não substitui a senioridade técnica, é necessário ter conhecimento para avaliar alternativas propostas pelo assistente que podem ter riscos significativos.

Abaixo, tem o resumo gerado automaticamente pelo assistente de IA. Ele consolidou o problema, descreveu o diagnóstico, apresentou a análise de impacto, sugeriu caminhos de resolução e até aplicou a correção.

• TEXTOS GERADOS POR AI
• AJUSTES DE TEXTOS REALIZADOS PARA RETIRAR DADOS SENSÍVEIS

Resolução de Problema: Volume Longhorn ActiveMQ

Data: 2025-08-21
Problema: Pod activemq-artemis-0 com erro de volume Longhorn
Status: ✅ RESOLVIDO

📋 Resumo Executivo

• Problema: Volume Longhorn em estado “faulted” impedindo inicialização do ActiveMQ
• Causa: Dados físicos do volume perdidos/corrompidos (volume órfão)
• Solução: Recriação do volume com perda de dados
• Resultado: Serviço ActiveMQ 100% operacional

🔍 Diagnóstico Inicial

Comando Inicial

kdp -n activemq activemq-artemis-0

Status do Pod

• Nome: activemq-artemis-0
• Namespace: activemq
• Status: Pending (Init:0/3)
• Erro: AttachVolume.Attach failed for volume "pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8"
• Mensagem: volume pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8 is not ready for workloads

Status do Volume Longhorn

• ID: pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8
• Estado: detached
• Robustez: faulted
• Tamanho: 8Gi
• Nó: vm001-vx28

📊 Análise de Impacto

✅ Serviços Saudáveis

• Cluster Kubernetes: Funcionando normalmente
• Longhorn Storage: Saudável (exceto 1 volume)
• Outros volumes Longhorn: Operacionais

❌ Serviços Afetados

• ActiveMQ Artemis: Completamente indisponível
• Aplicações dependentes de mensageria: Potencialmente afetadas

🔍 Serviços NÃO Afetados

• Nenhuma outra aplicação conectando diretamente ao ActiveMQ identificada
• Outros pods com problemas são independentes

🛠️ Tentativas de Recuperação (Sem Perda de Dados)

1. Verificação de Backups/Snapshots

kubectl get snapshots.longhorn.io -n longhorn-system | grep pvc-2d352316
kubectl get backups.longhorn.io -n longhorn-system | grep pvc-2d352316

Resultado: ❌ Nenhum backup ou snapshot encontrado

2. Tentativa de Reattach do Volume

kubectl patch volume.longhorn.io pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8 -n longhorn-system \
  --type='merge' -p='{"spec":{"nodeID":"cebrsvc-vndk28"}}'

Resultado: ❌ Volume permaneceu em estado faulted

3. Aumento do Número de Réplicas

kubectl patch volume.longhorn.io pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8 -n longhorn-system \
  --type='merge' -p='{"spec":{"numberOfReplicas":2}}'

Resultado: ❌ Não resolveu o problema

4. Deleção e Recriação do Pod

kubectl delete pod activemq-artemis-0 -n activemq --force --grace-period=0

Resultado: ❌ Novo pod com mesmo erro

5. Reset do NodeID

kubectl patch volume.longhorn.io pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8 -n longhorn-system \
  --type='merge' -p='{"spec":{"nodeID":""}}'

Resultado: ❌ Volume permaneceu faulted

Conclusão: Todas as tentativas de recuperação falharam

🔬 Análise da Causa Raiz

Investigação do Disco/Partição

✅ Estado do Disco (Saudável)

# Espaço disponível
df -h /var/lib/longhorn/
# Resultado: 51GB de 79GB disponível (33% usado)

# Inodes disponíveis  
df -i /var/lib/longhorn/
# Resultado: 5.2M livres (1% usado)

✅ Filesystem e Nó

• Filesystem: ext2/ext3 funcionando normalmente
• Nó Longhorn: Status “Ready” e “Schedulable”
• Erros de I/O: Nenhum encontrado

❌ Problema Identificado

# Verificação de réplicas físicas
ls -la /var/lib/longhorn/replicas/ | grep pvc-2d352316
# Resultado: NENHUM diretório encontrado

💡 Conclusão da Análise

• Réplica física: ❌ NÃO EXISTE no disco
• Volume lógico: ✅ Existe no Longhorn mas em estado faulted
• Causa raiz: Volume órfão - dados físicos perdidos/corrompidos
• Diagnóstico: O problema NÃO era do disco, mas sim dados perdidos

✅ Solução Implementada (Com Perda de Dados)

Passo 1: Parar o Serviço

kubectl scale statefulset activemq-artemis -n activemq --replicas=0
kubectl wait --for=delete pod/activemq-artemis-0 -n activemq --timeout=60s

Passo 2: Remover Volume Corrompido

# Deletar PVC
kubectl delete pvc data-activemq-artemis-0 -n activemq

# Forçar remoção do volume Longhorn órfão
kubectl delete volume.longhorn.io pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8 \
  -n longhorn-system --force --grace-period=0

Passo 3: Recriar Serviço

kubectl scale statefulset activemq-artemis -n activemq --replicas=1

Passo 4: Verificação

# Aguardar pod ficar ready
kubectl wait --for=condition=ready pod/activemq-artemis-0 -n activemq --timeout=120s

# Verificar status
kubectl get pods -n activemq
kubectl get pvc -n activemq
kubectl get endpoints -n activemq

🎉 Resultado Final

✅ Status dos Componentes

📝 Logs de Confirmação

2025-08-21 19:08:35,778 INFO [org.apache.activemq.artemis] AMQ241001: HTTP Server started at http://0.0.0.0:8161
2025-08-21 19:08:35,778 INFO [org.apache.activemq.artemis] AMQ241004: Artemis Console available at http://0.0.0.0:8161/console

🔗 Informações de Conectividade

Conexões Internas ao Cluster

Host: activemq-artemis.activemq.svc.cluster.local
Portas:
  - JMS: 61616
  - AMQP: 5672
  - STOMP: 61613
  - MQTT: 1883
  - JMX: 1099
  - Metrics: 9404

Conexões Externas (NodePort)

Host: <IP_DO_NODE>
Portas:
  - JMS: 30093
  - AMQP: 31466
  - STOMP: 30443
  - MQTT: 32364
  - Console Web: 31074
  - Metrics: 31196

Console Web de Administração

• Interno: http://activemq-artemis.activemq.svc.cluster.local:8161/console
• Externo: http://<IP_DO_NODE>:31074/console

Credenciais

# Verificar credenciais no secret
kubectl get secret artemis-prereqs-secret -n activemq -o yaml

📚 Lições Aprendidas

1. Volume Longhorn em estado “faulted” geralmente indica perda de dados físicos
2. Tentativas de recuperação devem ser feitas antes da recriação
3. Verificação de backups/snapshots é essencial antes de qualquer ação destrutiva
4. Análise do disco subjacente ajuda a identificar se é problema de infraestrutura
5. StatefulSets recriam PVCs automaticamente quando escalados após deleção

🛠️ Comandos Úteis para Diagnóstico

Diagnóstico de Pod

# Status detalhado do pod
kubectl describe pod <pod-name> -n <namespace>

# Logs do pod
kubectl logs <pod-name> -n <namespace> --tail=50

Diagnóstico de Volume Longhorn

# Listar volumes Longhorn
kubectl get volumes.longhorn.io -n longhorn-system

# Detalhes do volume
kubectl describe volume.longhorn.io <volume-id> -n longhorn-system

# Status dos nós Longhorn
kubectl get nodes.longhorn.io -n longhorn-system

Diagnóstico de Disco

# Espaço em disco no nó
kubectl exec -n longhorn-system <longhorn-manager-pod> -- df -h /var/lib/longhorn/

# Verificar réplicas físicas
kubectl exec -n longhorn-system <longhorn-manager-pod> -- ls -la /var/lib/longhorn/replicas/

# Verificar erros de I/O
kubectl exec -n longhorn-system <longhorn-manager-pod> -- dmesg | grep -i "error\|fail\|i/o"

Recuperação de Volume

# Forçar recriação de volume (COM PERDA DE DADOS)
kubectl scale statefulset <sts-name> -n <namespace> --replicas=0
kubectl delete pvc <pvc-name> -n <namespace>
kubectl delete volume.longhorn.io <volume-id> -n longhorn-system --force
kubectl scale statefulset <sts-name> -n <namespace> --replicas=1

⏱️ Tempo Total de Resolução

🏆 Status Final

✅ PROBLEMA RESOLVIDO COM SUCESSO

O serviço ActiveMQ Artemis está 100% operacional com novo volume saudável. Todas as funcionalidades de mensageria (JMS, AMQP, STOMP, MQTT) estão disponíveis.

Documentação criada em: 2025-08-21 19:10
Autor: Assistente de CLI
Ambiente: Kubernetes com Longhorn Storage

Resumo olhando para o custo

Realizar troubleshooting é uma das tarefas mais fundamentais para o dia a dia de engenheiro DevOps e SRE. Ter uma ferramenta de IA para ajudar nessa atividade tem sido uma das causas que eu tenho defendido bastante e não é pelo hype da AI não, defendo isso porque na prática, o uso de uma ferramenta desse tipo eleva a maturidade operacional do time em métricas reais de qualidade, veja algumas delas.

• Redução significativa do tempo de downtime das aplicações
• Geração de documentação e desenho de processos de forma automática
• Postmortem automático ao final do troubleshooting
• Criação de código IaC de infraestrutura legada

Vamos dar uma olhada nos custos, o valor de um assistente desse tipo é algo em torno de R$130 por mês. Vamos fazer um continha simples que eu vou tentar te convencer que vale a pena ter um assistente desses para cada pessoa do seu time.

• Custo médio de um especialista em infraestrutura: R$180/h.
• Custo médio de um analista sênior de infraestrutura: R$140/h.
• Custo médio de um desenvolvedor sênior: R$140/h.

As pessoas envolvidas neste incidente eram; 01 Especialista de infraestrutura, 02 Analistas seniores de infraestrutura e cerca 10 Desenvolvedores seniores impactados com a falha, vejamos os custos individuais:

• 1 * 180 = R$180/h Especialista
• 2 * 140 = R$260/h Analistas seniores de infraestrutura
• 10 * 140 = R$1400/h desenvolvedor seniores

Total de 180 + 280 + 1400 = R$1860/h custo de pessoas envolvida no incidente.

Uma hora de trabalho desse conjunto de pessoas é igual a R$1860 por hora. Estou restringindo os custos para um incidente apenas. O problema foi resolvido em 35 minutos, numa conta aredondada para meia hora. O custo de tempo parado é de R$930 para a empresa. Muito bem, se olharmos para o custo de envolvimento por tinta minutos dessas pessoas (R$930) dividido pelo custo mensal de um assistente de AI R$130, é igual a 930/130=7.1, então, um incidente viabilizaria a contratação 7 novos assistentes virtuais. Guarde essa informação, vamos utiliza-la já já.

O assistente de AI fez um resumo do problema, achou a causa raiz e sugeriu pontos de melhorias. No mundo DevOps e SRE, isso se chama de Postmortem. Se após esse incidente fosse feito um Postmortem formal de 1h, o custo seria algo assim: 1h de 01 Especialista e 1h de 02 Analistas seniores de infraestrutura envolvido no incidente totalizando R$ 180+140+140=460. Um postmortem viabilizaria a contratação 430/130=3.5 novos assistentes virtuais.

Por baixo, mas muito por baixo mesmo, com custos muito simplificados, um incidente de 35 minutos mais uma reunião de Postmortem viabilizaria a contratação 10 novas contas de assistentes virtuais. Agora, contabilize a redução de tempo de todos os incidentes do mês em um time DevOps/SRE, faria ou não faria sentido cada pessoa do seu time ter um assistente desses no dia a dia??? Me diz aee, nos comentários???

Resumo olhando para a qualidade de entrega

Em 35 minutos o problema foi resolvido. As lideranças já estavam cientes e atualizadas por meio de um resumo executivo gerado e enviado, enquanto os três engenheiros diretamente envolvidos trabalhavam lado a lado com o assistente de IA compartilhando conhecimentos e avaliando resultados e sugerindo comandos em conjunto, trabalho realizado em colaboração o que é mais importante. Foi um esforço coordenado, com o time focado no mesmo objetivo.

O resultado foi completo, a causa raiz foi identificada, o erro foi devidamente registrado em nossa documentação interna e todo o processo conduzido de forma estruturada. Para mim, esse é o verdadeiro valor da IA aplicada no dia a dia de DevOps/SRE, apoiar na resolução de problemas, reduzir custos operacionais, e ao mesmo tempo, aumentar a qualidade do trabalho entregue.

Te convenci? Ainda não? tudo bem, mas se quiser me chame na DM do Linkedin para um papo!!

Abraços!

Vida longa e próspera a todos!!

Referências

• https://infraascode.com.br/linux-troubleshooting-com-chat-gpt/
• https://infraascode.com.br/postmortem-aprendendo-com-os-erros/
• https://infraascode.com.br/postmortem-aprendendo-com-os-erros-v2/
• https://infraascode.com.br/postmortem-aprendendo-com-os-erros-v3-final/

Entre em contato: