Cómo integramos Baxilio en nuestras operaciones IT (y qué hemos aprendido)
Llevamos unos meses trabajando con Baxilio, nuestro agente de IA, integrado en nuestras operaciones técnicas. No como asistente al que se le pregunta y luego uno decide, sino conectado a la base de conocimiento, a los servidores y a los procedimientos reales: diagnostica, propone, ejecuta y documenta lo que hace.
Cuento cómo lo hemos montado porque es la pregunta que más nos hacen últimamente, y porque las respuestas que circulan suelen ser o entusiastas de más o directamente humo. La parte interesante no es Baxilio en sí. Es la disciplina que hay que montar alrededor para que se pueda confiar en él.
El problema que nos empujó a esto
En cualquier infraestructura con años encima hay una capa de cosas que fallan en silencio. No caen: fallan. Y nadie se entera porque su salida va a un log que no lee nadie.
Nos pasó con una tarea programada que llevaba meses sin ejecutarse. Redirigía su salida a /dev/null, así que el error no aparecía en ningún sitio. El síntoma visible era otro: el sistema no detectaba actualizaciones. Nadie relacionó una cosa con la otra hasta que alguien se sentó a revisar el conjunto.
Ese es el tipo de trabajo que se pospone siempre. No es urgente hasta que lo es, y revisar sistemáticamente lo que funciona «bien» no entusiasma a nadie. Es exactamente donde Baxilio, incansable, aporta algo que una persona no va a aportar de forma sostenida.
Cómo lo hemos integrado
1. Una base de conocimiento que se consulta antes de tocar nada
Es la pieza que más ha costado y la que más rinde. Toda la documentación técnica —topologías, procedimientos, decisiones de arquitectura y por qué se tomaron, esquemas de bases de datos de sistemas de terceros, bitácoras de incidentes— vive en un wiki interno indexado en una base de datos vectorial.
La regla es que antes de explorar nada, se busca ahí. Parece burocracia y es justo lo contrario: evita que alguien se lance a inspeccionar un sistema en producción para averiguar algo que ya estaba escrito. Nos ha ahorrado más de un diagnóstico equivocado por asumir que dos entornos eran lo que parecían por el nombre.
2. Herramientas con red de seguridad incorporada
Baxilio no ejecuta comandos sueltos. Trabaja con guiones nuestros que encapsulan las operaciones: uno para consultar, otro para aplicar cambios, otro para hacer copia de seguridad. La copia previa no es opcional ni depende de que alguien se acuerde: está dentro del procedimiento, y cada cambio imprime la línea exacta para revertirlo.
Esto es lo que hace viable trabajar directamente contra producción. No porque no vayan a cometerse errores, sino porque cada error tiene una vuelta atrás conocida y probada.
3. Verificación medida, no declarada
Un cambio no está hecho cuando se aplica. Está hecho cuando se ha comprobado con datos que hace lo que decía, preguntándole al sistema en marcha, no al fichero que acabas de escribir.
La diferencia no es teórica. Nos hemos encontrado con directivas de seguridad declaradas en la definición de un contenedor que no estaban activas: ese bloque solo se aplica cuando el servicio genera su configuración por primera vez, y como el fichero ya existía en el volumen, nunca llegaron a entrar. Sobre el papel, todo correcto. En ejecución, nada. Desde entonces la comprobación es siempre contra la configuración efectiva.
Es la trampa más común al verificar: leer el valor que uno mismo acaba de escribir y darlo por bueno. Da confianza injustificada, que es peor que no comprobar nada.
El proceso, en cuatro pasos
Cada intervención sigue el mismo camino, sea cambiar una línea de configuración o migrar un servicio:
- Diagnosticar con datos. Medir antes de opinar. La hipótesis razonable es incorrecta más veces de las que uno espera.
- Planificar y acordar. Lo que tiene consecuencias visibles o es difícil de revertir se propone, no se ejecuta. La decisión sigue siendo de una persona.
- Ejecutar con copia previa. Un cambio cada vez, con su punto de retorno.
- Verificar y documentar. Medir el resultado, y dejar escrito qué se cambió, por qué y cómo revertirlo. Si no está documentado, para el equipo no ha ocurrido.
Cuatro trampas técnicas donde esto se nota
El valor no está en ir más rápido. Está en no pisar cosas que parecen inofensivas. Cuatro ejemplos del tipo de trabajo que hacemos, contados por su patrón:
La misma cadena de conexión vive en seis sitios
Al clonar una plataforma de telefonía para montar un entorno de pruebas, hay que repuntar la base de datos del clon. La conexión no está en un fichero: está en la configuración del panel web, en la de los scripts que procesan la llamada, en los orígenes de datos ODBC, en el módulo de configuración en tiempo real, en el demonio de monitorización y en el fichero de entorno del servicio auxiliar.
Si te dejas uno, normalmente el de procesamiento de llamada, el panel se ve perfecto y las llamadas fallan. El síntoma no apunta a la causa. Tener esa lista escrita —«son seis, y el que se olvida es este»— vale más que cualquier herramienta.
Una lista blanca detrás de un proxy inverso no filtra nada
Restringir un panel de administración a las redes internas parece trivial: se permite el rango interno y se deniega el resto. Pero si el servicio está detrás de un proxy inverso, todas las peticiones llegan con la dirección del proxy, que es interna. La regla da por buena a media Internet mientras la configuración parece correcta y la sensación de seguridad es total.
Hay que resolver la dirección real del cliente a partir de la cabecera que añade el proxy y, muy importante, hacerlo sin recorrer la cadena hacia atrás: si se acepta el primer valor de la cabecera, cualquiera puede inyectar una dirección de confianza y saltarse el filtro. La diferencia entre las dos configuraciones es una línea, y decide si el filtro existe o es decorativo.
Revertir un snapshot puede llevarse por delante lo que no tocaste
Cuando varias máquinas virtuales comparten el mismo conjunto de datos en la cabina, revertir un snapshot a nivel de almacenamiento para recuperar una destruye los discos de todas las demás. La operación se llama igual que la que uno tiene en la cabeza y hace algo mucho más grande.
La vía segura es el snapshot por máquina, que es específico de esa máquina; y si lo único que hace falta es rescatar unos ficheros, clonar el snapshot, montar el clon, copiar lo necesario y destruir el clon. Nunca revertir. Esto está en nuestras normas como prohibición explícita, no como recomendación.
Dos entornos que parecían gemelos y no lo eran
Una revisión automática señaló datos de producción aparentemente duplicados entre dos plataformas cuyos nombres sugerían que una era el preproducción de la otra. No lo era: eran dos productos independientes, cada uno en producción cumpliendo su propia función, que por casualidad de nomenclatura parecían un par entorno-clon.
Baxilio, a primera vista y sin la base de conocimiento, llegó exactamente a esa conclusión errónea: que una era la copia de la otra y que los datos duplicados eran basura a limpiar. De haber actuado sobre esa hipótesis sin verificarla contra la documentación, habría borrado datos de producción de un cliente en una plataforma que nada tenía que ver con la otra. Es el ejemplo más claro de hasta dónde puede meter la pata un agente que razona bien pero sobre una premisa falsa.
Lo relevante es que la respuesta correcta ya estaba documentada. No hacía falta investigar nada: hacía falta consultar antes de investigar. De ahí que la consulta previa a la base de conocimiento sea obligatoria y no una buena práctica, y de ahí que ningún cambio con ese nivel de impacto se ejecute sin pasar antes por una persona.
Comprobar el efecto, no la intención
Los cambios en infraestructura compartida se verifican por su ausencia de efectos secundarios, no solo por su resultado.
Cuando repuntamos un entorno de preproducción para que dejara de escribir en la plataforma de producción, el criterio de éxito no fue «el entorno funciona». Fue: cero filas nuevas en las tablas de producción asociadas a ese entorno desde el momento del cambio. Una consulta concreta, con un número que tiene que dar cero. Eso es verificable; «parece que va bien» no lo es.
El mismo principio aplica a limitar el radio de daño antes de tocar nada. Un enlace de pruebas contra una plataforma en producción se levanta con un máximo de llamadas simultáneas deliberadamente bajo: si algo se descontrola, se descontrola dentro de un límite. Y el procedimiento de vuelta atrás se escribe antes de aplicar el cambio, no cuando hace falta.
Lo que no hace
Conviene ser claro, porque aquí es donde se vende humo con más alegría.
No decide. Las decisiones con impacto —desplegar en producción un viernes, dar de baja un servicio, aceptar un riesgo— siguen siendo de una persona con nombre. Baxilio propone y avisa; el criterio y la responsabilidad no se delegan.
No sustituye conocer el sistema. Rinde en la medida en que la documentación es buena. Con una base de conocimiento pobre, Baxilio es un becario muy rápido dando tumbos por producción, que es exactamente lo que nadie quiere.
Y se equivoca. Nuestra defensa no es que no falle, sino que cada acción tenga copia previa, cada resultado se mida y cada error acabe escrito para que no se repita. Varias de las lecciones de este artículo salen de fallos propios.
Qué nos ha dado
No es velocidad. Es cobertura: revisar sistemáticamente lo que parece que funciona.
El rodaje lo hemos hecho en nuestros propios sistemas antes de acercar nada a los de un cliente, empezando por lo menos crítico. Ahí ya aparecieron varias tareas programadas que llevaban meses fallando en silencio, permisos mal puestos que impedían operaciones normales sin que nadie lo reportara, y actualizaciones automáticas con efectos colaterales que solo se ven si alguien mira el resultado, no el registro de la actualización.
Ninguna de esas cosas estaba en un ticket. Ese es exactamente el punto: no fallaban lo bastante como para que alguien las escribiera, pero estaban ahí.
Es también, en el fondo, lo que hacemos cuando alguien nos confía su infraestructura en outsourcing IT o su red en servicios para operadores: mirar lo que nadie está mirando. La diferencia es que ahora tenemos una herramienta que no se cansa de mirar.
Cómo lo aplicamos en Bayma al entrar en un entorno de cliente nuevo
Este es el método que seguimos siempre que incorporamos Baxilio a la infraestructura de un cliente nuevo, sea telefonía, red de operador o sistemas IT generales. No improvisamos sobre el terreno: repetimos la misma secuencia que hemos rodado durante meses en nuestros propios sistemas.
- Documentar primero. Antes de que Baxilio toque nada, levantamos la base de conocimiento del entorno: topologías, qué es cada plataforma y para qué sirve, decisiones de arquitectura y por qué se tomaron. Sin esto no hay fase dos.
- Crear las reglas y normas propias de ese entorno. Qué puede ejecutar Baxilio solo, qué tiene que proponer y esperar aprobación, y qué queda prohibido sin excepción —como revertir un snapshot compartido en vez de uno por máquina—.
- Construir un entorno de test y rodaje antes de tocar producción. Baxilio se prueba primero contra una réplica o un entorno de bajo impacto del propio cliente, con el mismo rigor —copia previa, verificación medida, radio de daño limitado— que aplicamos internamente.
- Solo entonces, producción. Cada cambio con copia previa, verificación contra el sistema en marcha y decisión humana cuando hay consecuencias reales.
Es la misma disciplina que nos ha costado aciertos y tropiezos propios, convertida ahora en el proceso que ofrecemos como servicio de outsourcing IT y operaciones para operadores: documentación primero, Baxilio sometido a reglas, y un entorno de pruebas real antes de acercarnos a lo que de verdad importa.
Si tenéis una infraestructura con años encima y la sospecha de que hay cosas fallando en silencio, probablemente la tengáis. En Bayma nos dedicamos a encontrarlas y a montar este mismo proceso en vuestro entorno: cuéntanos tu caso y le echamos un vistazo.