Durante mucho tiempo pensé que la automatización de redes no era para mí. Me aferré a la interfaz de línea de comandos (CLI) como si fuera el aire que respiraba. Pensé que incluso podrían poner la siguiente cita en mi lápida: «Puedes tener mi CLI cuando me la quites de las manos frías y muertas». Construí mi carrera sobre los comandos de la CLI y me negué a renunciar a ellos, sin importar las adversidades de la industria.
Había reprobado informática en la universidad, incapaz de comprender las infinitas capas de abstracción que contienen los conceptos de programación. Todavía puedo ver la pantalla: una maraña de llaves y punto y coma mirándome como jeroglíficos que nunca aprendería a leer.
Esa experiencia temprana grabó una profunda conexión neuronal en mi cerebro. Esa conexión transmitió un mensaje:
La programación es para desarrolladores. Y tú, amigo mío, no eres desarrollador.
Así que llevaba esa insignia con orgullo. Era un experto en CLI. Crecí en la industria de las redes en una época en la que la CLI era la reina. Su dominio fue la base de todos los programas de certificación de redes de proveedores que seguí. Podía configurar casi cualquier cosa en la CLI mientras dormía. A menudo, configuraba redes de producción medio dormido, en un desfile interminable de ventanas de mantenimiento. Esos comandos de CLI crípticos que ahora parecen arcanos fueron el alma de mi carrera. De todas nuestras carreras en redes.
¿Automatización? Eso era para empresas a gran escala con equipos de ingenieros de software, no para gente como yo. Cuando Python, Git o YAML aparecían, saludaba cortésmente y me hacía a un lado.
La trampa del sesgo
Esto fue más que una simple mala experiencia universitaria. Estaba atrapado en mis propios sesgos cognitivos:
- El sesgo de confirmación me mantuvo atrapado en un círculo en el que cada dificultad con una herramienta técnica reforzaba la narrativa de “no sé codificar”.
- El sesgo de anclaje significaba que todavía juzgaba mis habilidades en función de quién era hace décadas, en lugar de en quién me había convertido como ingeniero de redes experimentado.
Estos prejuicios influyeron en mi visión del mundo. Mientras creí que no podía aprender herramientas de automatización como Python y Git, la realidad me lo confirmó. Evitaba la automatización en mis trabajos, evitaba las herramientas DevOps y me convencía de que dominar la CLI era suficiente.
Mi momento «uh-oh»
Gestioné una gran WAN de producción para una empresa fintech, donde mis métodos manuales de operaciones de red basados en CLI fueron aceptados e incluso celebrados. Luego vino la fusión con otro gigante fintech. ¿Sus ingenieros? Dominaban las herramientas de automatización.
Un día, la seguridad dio una orden: cambiar la cadena de comunidad SNMP en 217 dispositivos .
El único método que conocía:
- Inicie sesión en una caja de salto.
- SSH a un dispositivo.
- Pegar comandos de comprobación previa desde el Bloc de notas.
- Pegar el cambio de configuración.
- Pegar comandos posteriores a la comprobación.
- Guardar cambio.
- Consulte con el centro de operaciones de red.
- Repetir… 216 veces más.
Tan solo abrir la cantidad necesaria de tickets de cambio me habría llevado días. Sabía que mis nuevos compañeros lo automatizarían, y cuando el trabajo llegó a mi escritorio, ese viejo miedo regresó. Opresión en el pecho. Nudos en el estómago. Me van a pedir que automatice esto. No puedo. No lo haré.
Pedí ayuda y un colega escribió un script en Python que gestionó todo el cambio en minutos. Tuvo la amabilidad de guiarme, pero me pareció un lenguaje desconocido. Necesitaba tiempo para ir más despacio, pero el tiempo no era una opción.
Y así se reafirmó mi convicción: «La automatización es para desarrolladores. Y tú, amigo, no eres desarrollador». Mi plan era seguir mi carrera en CLI hasta que me despidieran o encontrara una salida.
La gran evasión
Esa «salida» llegó en forma de trabajo en un proveedor de redes. Sin periodos de mantenimiento. Sin turnos de guardia. Sin necesidad de programar. Perfecto.
Me sumergí en el área empresarial (proyectos de experiencia del cliente, mejoras de procesos) y prosperé. Me imaginaba una larga carrera allí. Pero, en retrospectiva, no estaba eludiendo el problema, solo lo estaba retrasando.
La verificación de la realidad
Esa ilusión terminó el día que me despidieron.
Al revisar las ofertas de empleo, vi los mismos requisitos de habilidades una y otra vez. Python. Git. Infraestructura como código. Ansible. Terraform.
No importaba que hubiera sido un crack en mi anterior puesto como ingeniero de redes. Sin habilidades de automatización, ni siquiera estaba cualificado para el puesto que antes tenía. Las certificaciones de redes y las descripciones de puestos coincidían: la automatización ya no era opcional. Era fundamental.
Y nada te saca de una ilusión cómoda como el desempleo. Mis prejuicios no me protegían, sino que me excluían.
Rompiendo la barrera
Por pura necesidad, dejé de lado mis excusas y prejuicios. Creé un laboratorio. Aprendí los fundamentos de Python y Git. Y una noche, usé la biblioteca Netmiko para iniciar sesión en un router y ejecutar una versión de demostración.
Fueron solo unas pocas líneas de código, pero para mí fue algo trascendental: la primera vez que usé un lenguaje de codificación para interactuar con equipos de red y hacerlos funcionar.
Resultó que no fue tan malo como me había estado diciendo mi cerebro durante 20 años. Ese momento no solo me proporcionó una habilidad. Rompió una barrera mental de décadas. Y si yo pude, tal vez otros que viven en CLI también podrían.
¿Por qué Nokia? ¿Por qué ahora?
Cuando vi la plataforma de automatización impulsada por eventos (EDA) de Nokia en un evento de Networking Field Day, me cautivó.
EDA proporciona la red de seguridad de automatización de red que nos faltaba (flujos de trabajo basados en intenciones, un gemelo digital sincronizado, verificaciones previas y posteriores, confirmaciones atómicas, reversión instantánea, telemetría en tiempo real) sin exigir que nadie se convierta en un desarrollador de software a tiempo completo.
EDA no es una automatización que se da por arte de magia. Es una plataforma de operaciones diseñada para que las redes sean más seguras, rápidas y fáciles de operar, incluso en entornos multiproveedor. Y demuestra que la automatización puede ser accesible para ingenieros de cualquier nivel, desde un novato como yo hasta un experto en scripting de infraestructura como código con Kubernetes.
Por eso me uní a Nokia. Y por eso lancé una serie de videos cortos: Automatización basada en eventos en acción.
Hasta el momento, la serie incluye vídeos sobre:
- Poniendo en marcha un laboratorio gratuito de Proxmox
- Preparación de Linux para la automatización
- Implementación de EDA
- Construyendo una estructura de centro de datos completa en minutos
Y esto es solo el comienzo. Suscríbete a la lista de reproducción de EDA para aprender más sobre redes de centros de datos confiables y automatización de infraestructura multiproveedor con esta plataforma nativa de la nube.
Porque si yo pude romper décadas de prejuicios y aprender esto, tú también puedes.
Todavía me encanta la CLI. Ha sido mi arma y mi escudo durante la mayor parte de mi carrera. Pero la realidad es que la automatización ha tomado el trono.
El rey del CLI no se ha ido, pero hay un nuevo gobernante en la ciudad.
El rey ha muerto. Larga vida al rey.
NOKIA Blog. A. L. Traducido al español
