ChatOps en redes: útil si declara lo que cuesta

La herramienta poderosa que nadie abre

Hay un patrón conocido en las plataformas de gestión de red: se compran por sus capacidades y se usan por su pantalla principal. El resto de los módulos existe, funciona, y nadie entra. No porque estén mal hechos, sino porque llegar a la respuesta exige saber en qué pestaña vive, con qué filtros, y en qué orden.

El operador que necesita saber si un equipo cumple, o por dónde pasa un flujo, o qué cambió desde ayer, tiene la información disponible y aun así abre una sesión contra el equipo. Es más rápido para él, aunque sea peor para la organización: no deja rastro, no es repetible y no escala a quien no tiene su experiencia.

Una capacidad que exige saber dónde buscarla sólo la usan los que ya sabían.

Qué es ChatOps, y qué no

ChatOps es operar desde una conversación: se pregunta en lenguaje natural y la plataforma responde con datos reales, ejecuta la consulta, o propone una acción. La idea es vieja en el mundo de los sistemas y llega tarde a redes.

Conviene decir lo que no es, porque la confusión está en todas partes. No es un modelo de lenguaje contestando de memoria sobre redes: eso produce respuestas plausibles sobre una red que no es la suya. Tampoco es una terminal con otro nombre.

Un asistente de operación útil hace tres cosas distintas, y conviene distinguirlas porque tienen riesgos muy diferentes:

• Consultar. Leer el inventario, el cumplimiento, la topología. Sin riesgo: sólo lee.
• Diagnosticar. Correlacionar varias fuentes para explicar algo. Riesgo bajo, pero puede equivocarse, así que debe mostrar en qué se basó.
• Proponer cambios. Generar configuración. Aquí el riesgo es real y por eso la respuesta no puede ser la acción: tiene que ser una propuesta que alguien aprueba.

La pregunta incómoda: ¿esto consume IA?

Cualquiera que haya puesto un modelo de lenguaje en producción conoce las dos preocupaciones: cuánto cuesta y qué sale de la organización.

Lo que casi nunca se dice es que buena parte de lo que un operador pregunta no necesita un modelo de lenguaje. «¿Cuántos equipos hay en el sitio norte?» es una consulta. «¿Qué equipos incumplen la regla de servidores de tiempo?» es un filtro. «¿Por dónde pasa el tráfico entre estas dos direcciones?» es un recorrido sobre tablas de ruteo. Resolver eso con un modelo es caro, más lento y menos exacto que resolverlo de forma determinista.

El modelo aporta donde de verdad aporta: interpretar una pregunta ambigua, redactar una explicación, proponer una configuración a partir de una intención descrita en palabras.

Un asistente que no le dice si va a consumir el modelo antes de ejecutar convierte su factura en una sorpresa mensual.

Declararlo antes de ejecutar cambia dos cosas. La primera es el costo, que deja de ser un misterio. La segunda es la confianza: saber que la respuesta salió de una consulta determinista y no de un modelo le dice al operador cuánto tiene que verificarla.

Un chat que puede cambiar la red necesita barandillas

Conversar con la plataforma es cómodo, y esa comodidad es justamente el riesgo: baja tanto la fricción que pedir un cambio se vuelve tan fácil como preguntar la hora. Las protecciones tienen que ser explícitas.

• Separar leer de escribir. Consultar es inmediato; cambiar pasa por el mismo flujo de aprobación que cualquier otro cambio, con su diferencial revisable.
• Mostrar la fuente. Una respuesta sobre la red tiene que poder señalar de dónde salió: qué equipo, qué recolección, de qué fecha.
• Respetar los permisos de quien pregunta. El asistente no puede ser una puerta trasera a datos que ese usuario no vería en la interfaz.
• Dejar rastro. Lo que se pidió por conversación tiene que quedar en el mismo historial que lo que se pidió por pantalla, o se pierde la trazabilidad que justificaba automatizar.

Cómo lo resuelve Oktavia

Argos es la capa de conversación sobre toda la plataforma, no un módulo aparte. Atraviesa inventario, cumplimiento, topología, seguridad, direccionamiento y remediación, de modo que la pregunta no obliga a saber en qué pantalla vive la respuesta.

Cada acción declara, antes de ejecutarse, si va a consumir el modelo de lenguaje o si se resuelve de forma determinista. El operador decide con el costo a la vista, y sabe de qué naturaleza es la respuesta que va a recibir.

Cuando Argos propone configuración, no la aplica: produce la misma propuesta que el Gemelo Digital, con su diferencial revisable y su aprobación, el flujo que describimos en el artículo sobre cerrar el ciclo. La conversación cambia la forma de pedir las cosas, no las protecciones.

El centro de automatización: dónde vive Argos dentro de la plataforma.

Argos en acción: se pide una loopback nueva conversando y el cambio sale como propuesta para revisar y aprobar.