Voy a ser bien honesto: soy una de esas personas que ya no aguanta escuchar hablar de AI en la tecnología. En todo evento al que voy ahí está, la AI, los LLMs, la IA generativa, los agentes inteligentes… el futuro del futuro es una IA general… gente, en serio… ya no aguanto escuchar todo eso. Pero, como profesionales de TI que somos, no podemos ignorarlo, tenemos que estudiar el tema, y es importante saber separar lo que es hype, lo que es “espuma”, y buscar algo que se acerque a nuestra realidad y que traiga de forma eficaz alguna mejora al día a día.

Una de las cosas que más he defendido es el uso de un asistente de AI para apoyar en el día a día de los equipos DevOps/SRE a resolver problemas y hacer tareas que no se priorizan. Nosotros elegimos un asistente de IA que funciona en modo “CLI/BASH”, lo que se integró muy bien al flujo de trabajo del equipo.

La experiencia ha sido bastante positiva:

• La creación de documentación de código, de procesos y de flujos de trabajo complejos se realiza en pocos minutos;
• Analizar código con bugs quedó muy rápido;
• Proponer MRs y ajustes de forma más ágil.

Ahora, sin la menor sombra de duda, donde tuvimos mayor ganancia fue en usar el asistente para hacer troubleshooting. Claro, para hacer un troubleshooting asistido es necesario tener conocimiento técnico.

Comparto con ustedes uno de los troubleshootings asistidos que tuvimos recientemente: fue una falla en un POD de ActiveMQ con error de volumen de Longhorn. Esa investigación y resolución fue conducida por el Tech Lead del equipo. Su trabajo en ese proceso fue conectar el asistente al cluster y señalar el error y, a partir de ese punto, decir “YES” o “NO” al asistente de AI. Pero no se engañen, es importante destacar que este tipo de enfoque no sustituye la senioridad técnica; es necesario tener conocimiento para evaluar alternativas propuestas por el asistente que pueden tener riesgos significativos.

Abajo está el resumen generado automáticamente por el asistente de IA. Consolidó el problema, describió el diagnóstico, presentó el análisis de impacto, sugirió caminos de resolución e incluso aplicó la corrección.

• TEXTOS GENERADOS POR AI
• AJUSTES DE TEXTO REALIZADOS PARA ELIMINAR DATOS SENSIBLES

Resolución de Problema: Volumen Longhorn ActiveMQ

Fecha: 2025-08-21
Problema: Pod activemq-artemis-0 con error de volumen Longhorn
Estado: ✅ RESUELTO

📋 Resumen Ejecutivo

• Problema: Volumen Longhorn en estado “faulted” impidiendo la inicialización de ActiveMQ
• Causa: Datos físicos del volumen perdidos/corrompidos (volumen huérfano)
• Solución: Recreación del volumen con pérdida de datos
• Resultado: Servicio ActiveMQ 100% operativo

🔍 Diagnóstico Inicial

Comando Inicial

kdp -n activemq activemq-artemis-0

Estado del Pod

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

Estado del Volumen Longhorn

• ID: pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8
• Estado: detached
• Robustez: faulted
• Tamaño: 8Gi
• Nodo: vm001-vx28

📊 Análisis de Impacto

✅ Servicios Saludables

• Cluster Kubernetes: Funcionando normalmente
• Longhorn Storage: Saludable (excepto 1 volumen)
• Otros volúmenes Longhorn: Operativos

❌ Servicios Afectados

• ActiveMQ Artemis: Completamente indisponible
• Aplicaciones dependientes de mensajería: Potencialmente afectadas

🔍 Servicios NO Afectados

• Ninguna otra aplicación conectándose directamente a ActiveMQ identificada
• Otros pods con problemas son independientes

🛠️ Intentos de Recuperación (Sin Pérdida de Datos)

1. Verificación 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: ❌ Ningún backup o snapshot encontrado

2. Intento de Reattach del Volumen

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

Resultado: ❌ El volumen permaneció en estado faulted

3. Aumento del 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: ❌ No resolvió el problema

4. Eliminación y Recreación del Pod

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

Resultado: ❌ Nuevo pod con el mismo error

5. Reset del NodeID

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

Resultado: ❌ El volumen permaneció faulted

Conclusión: Todos los intentos de recuperación fallaron

🔬 Análisis de la Causa Raíz

Investigación del Disco/Partición

✅ Estado del Disco (Saludable)

# Espacio disponible
df -h /var/lib/longhorn/
# Resultado: 51GB de 79GB disponibles (33% usado)

# Inodos disponibles  
df -i /var/lib/longhorn/
# Resultado: 5.2M libres (1% usado)

✅ Filesystem y Nodo

• Filesystem: ext2/ext3 funcionando normalmente
• Nodo Longhorn: Estado “Ready” y “Schedulable”
• Errores de I/O: Ninguno encontrado

❌ Problema Identificado

# Verificación de réplicas físicas
ls -la /var/lib/longhorn/replicas/ | grep pvc-2d352316
# Resultado: NINGÚN directorio encontrado

💡 Conclusión del Análisis

• Réplica física: ❌ NO EXISTE en el disco
• Volumen lógico: ✅ Existe en Longhorn pero en estado faulted
• Causa raíz: Volumen huérfano - datos físicos perdidos/corrompidos
• Diagnóstico: El problema NO era del disco, sino datos perdidos

✅ Solución Implementada (Con Pérdida de Datos)

Paso 1: Detener el Servicio

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

Paso 2: Eliminar el Volumen Corrompido

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

# Forzar la eliminación del volumen Longhorn huérfano
kubectl delete volume.longhorn.io pvc-2d352316-6fc6-4c42-8b03-d8a069604ce8 \
  -n longhorn-system --force --grace-period=0

Paso 3: Recrear el Servicio

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

Paso 4: Verificación

# Esperar a que el pod quede ready
kubectl wait --for=condition=ready pod/activemq-artemis-0 -n activemq --timeout=120s

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

🎉 Resultado Final

✅ Estado de los Componentes

📝 Logs de Confirmación

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

🔗 Información de Conectividad

Conexiones Internas al Cluster

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

Conexiones Externas (NodePort)

Host: <IP_DEL_NODO>
Puertos:
  - JMS: 30093
  - AMQP: 31466
  - STOMP: 30443
  - MQTT: 32364
  - Consola Web: 31074
  - Metrics: 31196

Consola Web de Administración

• Interna: http://activemq-artemis.activemq.svc.cluster.local:8161/console
• Externa: http://<IP_DEL_NODO>:31074/console

Credenciales

# Verificar credenciales en el secret
kubectl get secret artemis-prereqs-secret -n activemq -o yaml

📚 Lecciones Aprendidas

1. Un volumen Longhorn en estado “faulted” generalmente indica pérdida de datos físicos
2. Los intentos de recuperación deben hacerse antes de la recreación
3. La verificación de backups/snapshots es esencial antes de cualquier acción destructiva
4. El análisis del disco subyacente ayuda a identificar si es un problema de infraestructura
5. Los StatefulSets recrean los PVCs automáticamente cuando se escalan tras la eliminación

🛠️ Comandos Útiles para Diagnóstico

Diagnóstico de Pod

# Estado detallado del pod
kubectl describe pod <pod-name> -n <namespace>

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

Diagnóstico de Volumen Longhorn

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

# Detalles del volumen
kubectl describe volume.longhorn.io <volume-id> -n longhorn-system

# Estado de los nodos Longhorn
kubectl get nodes.longhorn.io -n longhorn-system

Diagnóstico de Disco

# Espacio en disco en el nodo
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 errores de I/O
kubectl exec -n longhorn-system <longhorn-manager-pod> -- dmesg | grep -i "error\|fail\|i/o"

Recuperación de Volumen

# Forzar la recreación de un volumen (CON PÉRDIDA DE DATOS)
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

⏱️ Tiempo Total de Resolución

🏆 Estado Final

✅ PROBLEMA RESUELTO CON ÉXITO

El servicio ActiveMQ Artemis está 100% operativo con un nuevo volumen saludable. Todas las funcionalidades de mensajería (JMS, AMQP, STOMP, MQTT) están disponibles.

Documentación creada el: 2025-08-21 19:10
Autor: Asistente de CLI
Entorno: Kubernetes con Longhorn Storage

Resumen mirando el costo

Hacer troubleshooting es una de las tareas más fundamentales del día a día de un ingeniero DevOps y SRE. Tener una herramienta de IA para ayudar en esa actividad ha sido una de las causas que he defendido bastante, y no es por el hype de la AI, no. Lo defiendo porque en la práctica, el uso de una herramienta de este tipo eleva la madurez operacional del equipo en métricas reales de calidad. Mira algunas de ellas.

• Reducción significativa del tiempo de downtime de las aplicaciones
• Generación de documentación y diseño de procesos de forma automática
• Postmortem automático al final del troubleshooting
• Creación de código IaC de infraestructura legada

Vamos a echar un vistazo a los costos. El valor de un asistente de este tipo es algo alrededor de R$130 por mes. Vamos a hacer una cuentita simple con la que voy a intentar convencerte de que vale la pena tener un asistente de estos para cada persona de tu equipo.

• Costo medio de un especialista en infraestructura: R$180/h.
• Costo medio de un analista sénior de infraestructura: R$140/h.
• Costo medio de un desarrollador sénior: R$140/h.

Las personas involucradas en este incidente eran: 01 Especialista de infraestructura, 02 Analistas séniores de infraestructura y cerca de 10 Desarrolladores séniores impactados por la falla. Veamos los costos individuales:

• 1 * 180 = R$180/h Especialista
• 2 * 140 = R$260/h Analistas séniores de infraestructura
• 10 * 140 = R$1400/h desarrolladores séniores

Total de 180 + 280 + 1400 = R$1860/h de costo de personas involucradas en el incidente.

Una hora de trabajo de este conjunto de personas equivale a R$1860 por hora. Estoy restringiendo los costos a un solo incidente. El problema se resolvió en 35 minutos, en una cuenta redondeada a media hora. El costo del tiempo parado es de R$930 para la empresa. Muy bien, si miramos el costo de involucramiento por treinta minutos de estas personas (R$930) dividido por el costo mensual de un asistente de AI de R$130, es igual a 930/130=7.1, entonces, un incidente viabilizaría la contratación de 7 nuevos asistentes virtuales. Guarda esa información, la vamos a usar ya mismo.

El asistente de AI hizo un resumen del problema, encontró la causa raíz y sugirió puntos de mejora. En el mundo DevOps y SRE, esto se llama Postmortem. Si después de ese incidente se hiciera un Postmortem formal de 1h, el costo sería algo así: 1h de 01 Especialista y 1h de 02 Analistas séniores de infraestructura involucrados en el incidente, totalizando R$ 180+140+140=460. Un postmortem viabilizaría la contratación de 430/130=3.5 nuevos asistentes virtuales.

Por lo bajo, pero muy por lo bajo, con costos muy simplificados, un incidente de 35 minutos más una reunión de Postmortem viabilizaría la contratación de 10 nuevas cuentas de asistentes virtuales. Ahora, contabiliza la reducción de tiempo de todos los incidentes del mes en un equipo DevOps/SRE. ¿Tendría o no tendría sentido que cada persona de tu equipo tuviera un asistente de estos en el día a día??? ¿Me dices por ahí, en los comentarios???

Resumen mirando la calidad de la entrega

En 35 minutos el problema se resolvió. Los líderes ya estaban al tanto y actualizados mediante un resumen ejecutivo generado y enviado, mientras los tres ingenieros directamente involucrados trabajaban codo a codo con el asistente de IA compartiendo conocimientos, evaluando resultados y sugiriendo comandos en conjunto, un trabajo realizado en colaboración lo que es más importante. Fue un esfuerzo coordinado, con el equipo enfocado en el mismo objetivo.

El resultado fue completo: la causa raíz fue identificada, el error fue debidamente registrado en nuestra documentación interna y todo el proceso conducido de forma estructurada. Para mí, ese es el verdadero valor de la IA aplicada al día a día de DevOps/SRE: apoyar en la resolución de problemas, reducir costos operacionales y, al mismo tiempo, aumentar la calidad del trabajo entregado.

¿Te convencí? ¿Todavía no? Está bien, pero si quieres escríbeme por DM en LinkedIn para conversar!!

¡Abrazos!

¡Larga vida y prosperidad para todos!!

Referencias

• 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: