Cuando uno trabaja en operaciones de redes de telecomunicaciones, escuchar «DevOps» suena a ese término que los consultores y vendors repiten en cada junta. Y sí, hay mucho humo alrededor. Pero también hay una realidad ineludible: la industria telco está en medio de una transformación que no da tregua, y quienes no se suban al tren se van a quedar viendo cómo otros les ganan el paso.

Llevo años en operaciones IMS y CS Core, viendo cómo la red evoluciona. Pasamos de tener equipos dedicados, hardware propietario y configuraciones estáticas, a un mundo donde las funciones de red se virtualizan, se containerizan y se orquestan con las mismas herramientas que usa cualquier startup de Silicon Valley. Y en medio de todo eso, DevOps dejó de ser una opción para convertirse en una necesidad operativa.

¿Qué significa realmente DevOps en telco?

DevOps —la combinación de desarrollo (Dev) y operaciones (Ops)— nació en el mundo del software, donde los equipos de desarrollo y operaciones trabajaban en silos y los despliegues eran lentos y dolorosos. La idea era simple: automatizar, integrar continuamente, entregar de forma continua, y romper las barreras entre equipos.

Pero en telco la cosa se complica. No somos una empresa de software. Nosotros operamos redes que tienen que estar disponibles 99.999% del tiempo. No podemos hacer deploy cada hora como lo haría Netflix. Nuestros ciclos son más largos, nuestros sistemas son más complejos, y nuestros proveedores no siempre juegan con las mismas reglas.

Sin embargo, el principio aplica: necesitamos automatizar lo automatizable, integrar lo integrable, y acortar los ciclos de entrega sin sacrificar estabilidad.

El problema de copiar-pegar DevOps de IT

Uno de los errores más comunes que veo es querer aplicar DevOps exactamente igual que en una empresa de software. No funciona. En telco:

• No desarrollamos el software, lo compramos a vendors (Ericsson, Nokia, Huawei, Mavenir, etc.)
• Trabajamos con paquetes de software, no con código fuente que podamos modificar
• El lifecycle management de las VNF/CNF está separado del workload, a diferencia de IT donde todo está integrado
• Operamos en ecosistemas NFV con múltiples cloud managers, versiones y releases frecuentes

China Mobile lo entendió bien y acuñó un término que me parece mucho más acertado: DevIntOps (Development + Integration + Operations). La idea es que el operador no está en el ciclo de desarrollo del vendor, pero sí debe estar en el ciclo de integración. Y ahí está el verdadero valor.

DevIntOps: el modelo que sí funciona

El modelo DevIntOps propone tres círculos:

1. Dev — El vendor desarrolla el software como siempre
2. Int — El operador tiene un laboratorio de integración donde recibe las builds estables del vendor, las despliega automáticamente, las integra con los demás componentes del ecosistema, y ejecuta pruebas automatizadas. Si algo falla, se retroalimenta al vendor.
3. Ops — Solo lo verificado en el laboratorio pasa a producción. Y los issues de producción se reproducen en el laboratorio para corregirse.

Este modelo es mucho más realista para nuestra industria. No necesitamos ser desarrolladores de software, pero sí necesitamos tener capacidad de integración, un laboratorio propio, y pipelines de CI/CD que automaticen la validación.

¿Qué estamos haciendo en la práctica?

En el día a día de operaciones IMS/CS Core, DevOps se traduce en cosas concretas:

Automatización de despliegues

Ya no es aceptable estar 3 meses configurando manualmente un nuevo elemento de red. Con herramientas como Ansible, Helm y pipelines CI/CD, podemos desplegar una VNF o CNF en horas, con configuraciones estandarizadas y repetibles.

Infraestructura como Código (IaC)

Los días de hacer configuraciones a mano en cada equipo se están acabando. Hoy describimos nuestra infraestructura —servidores, redes, balanceadores— en archivos de configuración que versionamos en Git. Un cambio se revisa, se aprueba y se aplica automáticamente.

Monitoreo y observabilidad

Ya no basta con tener un SNMP polling cada 5 minutos. Necesitamos dashboards en tiempo real, alertas inteligentes, y correlación de métricas entre capas. Herramientas como Prometheus, Grafana y Elasticsearch se están volviendo estándar incluso en entornos telco.

Kamailio y el mundo open source

Cada vez más operadores están adoptando soluciones open source como Kamailio para SIP routing, o FreeSWITCH para procesamiento de medios. Y con open source, el ciclo DevOps se vuelve más natural: puedes hacer cambios, probarlos en laboratorio, y pasarlos a producción con total control.

Los desafíos que nadie menciona

No todo es color de rosa. Adoptar DevOps en telco tiene obstáculos reales:

• Costo inicial: La inversión en herramientas, capacitación y cambios culturales no es menor
• Resistencia al cambio: Los equipos de operaciones tradicionales no siempre ven con buenos ojos la automatización
• Multi-vendor: Cada vendor tiene sus propias herramientas, APIs y formatos de configuración. Integrarlos es un dolor de cabeza
• Seguridad y compliance: En telco no puedes abrir puertos ni exponer APIs sin pasar por controles estrictos
• Capacitación: No es fácil encontrar ingenieros que entiendan tanto de redes como de automatización

El rol del ingeniero de operaciones está cambiando

Y esto es quizá lo más importante para quienes estamos en esto. El ingeniero de operaciones telco ya no puede ser solo el que hace configuraciones y revisa alarmas. Ahora necesita:

• Entender de automatización (Python, Ansible, Bash)
• Manejar conceptos de CI/CD (Git, Jenkins, GitLab CI)
• Conocer de contenedores y orquestación (Docker, Kubernetes)
• Saber de observabilidad (Prometheus, Grafana, Loki)
• Tener visión de integración, no solo de operación

Suena abrumador, pero también es una oportunidad enorme. Los ingenieros que logren combinar su conocimiento profundo de redes con estas nuevas habilidades van a ser los más valiosos en los próximos años.

---

DevOps en telco no es un lujo ni una moda. Es una respuesta a la complejidad creciente de nuestras redes. No podemos seguir operando redes 5G, cloud nativas y virtualizadas con procesos de la era 2G.

El camino no es copiar lo que hace Google o Netflix. Es entender nuestras particularidades —multi-vendor, alta disponibilidad, ciclos largos— y adaptar las prácticas DevOps a nuestra realidad. El modelo DevIntOps es un excelente punto de partida.

Y al final del día, se trata de algo muy simple: hacer mejor nuestro trabajo, con menos errores, más rápido, y con menos estrés. Porque operar redes ya es bastante complicado como para no tener las herramientas adecuadas.

---

Este artículo lo escribí pensando en mis colegas de operaciones que están viendo cómo el mundo cambia y no saben por dónde empezar. Si te identificas, bienvenido al club. El primer paso es aceptar que lo de siempre ya no funciona.