Hace unos días, en Linkedin, mi amigo NVDK publicaba este desafío:

Preguntale a tu asistente de IA favorito esto:

“Based on what you know about me will ai replace my job in the following 12 months? Be straight, no question ask.”

Y yo tomé el desafío. Lo hice con ChatGPT, que es el asistente de IA que uso más frecuentemente, y por lo tanto, conoce mi trabajo.

La respuesta, resumidamente, fue:

No. En los próximos 12 meses, es muy improbable que la IA reemplace tu trabajo. La razón: tu valor no reside simplemente en “escribir comandos” o “crear configuraciones”. Tu trabajo se encuentra en la capa más compleja: el análisis de sistemas. Operas en entornos Linux, identidad, redes, automatización, OpenShift, restricciones de seguridad, arquitectura empresarial, planificación de migraciones, resolución de problemas y formación. Precisamente en esta combinación es donde la IA aún depende de un operador humano. Lo que la IA sí puede reemplazar es parte del trabajo que realizas en tu puesto.

O sea, debo hacer que la IA me ayude a ser más productivo, eliminando trabajo superfluo.

Ahora, muchas veces se me pide guía o asesoramiento de carrera por parte de alumnos, o colegas más junior. Entonces me pregunté, ¿que le aconsejaría a un estudiante de IT, para navegar este nuevo mundo?

Y por supuesto, se los pregunté a ChatGPT, y lo que me respondió coincide con algo que para mi mismo siempre fue clave:

“Aprende los fundamentos tan bien, que las herramientas cambien sin volverte obsoleto.”

Vamos a ir al detalle. Es curioso porque es algo que estuve conversando con mis alumnos hace unas semanas en el Taller de Linux en ORT.

Tomar una estrategia de “formación en T”, o sea, una base amplia de fundamentos, y profundizar en una (o dos) áreas de especialización.

• Construir una base de fundamentos que aplican a cualquier camino que quiera transitar en IT,
• y después profundizar en un área lo antes posible, para aportar valor.

Generalmente uno deja la especialización para cuando tiene más experiencia, pero es un lujo que no podemos darnos actualmente.

¿Cual es la base de fundamentos?

• Sistemas Operativos
• Redes
• Lógica de programación
• Estructuras de datos básicas
• Seguridad básica
• Control de Versiones
• “Troubleshooting”
• Escritura técnica y comunicación.

Estos fundamentos son transferibles a desarrollo, infraestructura, redes, cyberseguridad, cloud, etc.

Con esa base, elegí algo para profundizar. Lo que te guste.

En mi caso, me formé con Analista Programador, pero siempre trabajé en infraestructura, más específicamente, con servidores Linux. Entonces,

• Entiendo el proceso de desarrollo de software, arquitecturas, modelos de despliegue de aplicaciones.
• Se lo suficiente sobre Windows, sin ser experto, para interactuar con otros y resolver problemas.
• Se lo suficiente de redes para interactuar con otros y resolver problemas.
• Se bastante de Cyberseguridad como para aplicar hardening, y aplicar mejores prácticas.
• Se suficiente de hardware como para trabajar on premises.
• Se mucho de instalación y configuración de servidores Linux.
• Se mucho de Automatización.
• Se un montón de plataformas de contenerización.
• Puedo entender, arreglar, y hacer pipelines sencillos.
• Puedo trajabar en la nube.

Pero sobre todo, y esto muchas veces no se le da importancia, desde muy temprano en mi carrera aprendí a comunicar. Y puedo escribir bastante bien, que es algo sumamente importante. Lo fundamental es poder comunicar claramente conceptos técnicos en lenguaje sencillo.

Y último, pero no menos importante, es fundamental poder hablar inglés. No se trata solo de poder leer documentación y sitios web. Se trata de poder entender y comunicarse con otras personas en Inglés competentemente.

Espero que estos consejos te sirvan para enfrentar mejor el futuro.

Originalmente, le había puesto “Perfect Stranger” a este Blog Personal, hasta que recordé que tenía el logo de guerrero de la línea de comandos y, como la mayoría de lo que voy a escribir tiene que ver con administración de sistemas, elegí SysWarrior.

Ahora, ¿porqué Perfect Stranger? Corría el año 1984. Hacía poco, con Adrían, mi hermano de la vida, habíamos descubierto el Hard Rock y el Heavy Metal. Iron Maiden, AC/DC, Judas Priest… you know. Y apareció el disco Perfect Strangers, de Deep Purple, el disco de la reunión con la mejor alineación de toda la historia de la banda. Jon Lord, Ritchie Blackmore, Ian Gillan, Ian Paice y Roger Glover. Y me enamoré de esa banda.

La canción que le da nombre al disco, tiene una atmosfera misteriosa, comenzando con el órgano de Jon Lord, y sumándose el resto de la banda en un riff denso y pesado, con la voz de Gillan cantando como “ecos del pasado”. Para Ritchie Blackmore es su canción favorita de la banda, y para mi, es de las mejores, sin duda.

Así que, si ya los conocés, es buen momento para volver a escucharlos, y si no, descubrí con “Perfect Strangers” a esta banda, que representa lo mejor del Hard Rock británico.

El joven discípulo había pasado semanas perfeccionando cada movimiento, cada postura, cada golpe. Cada día practicaba más, convencido de que, si podía controlarlo todo, nunca fallaría. Pero cada vez que enfrentaba un nuevo desafío, su mente se bloqueaba: había demasiadas variables que no podía dominar.

Un día, el Maestro lo llevó al pie de un lago tranquilo y le dijo:

“Nunca enfrentarás tu destino hasta que no abandones la ilusión del control.”

El discípulo, confundido, lo miró.
El Maestro arrojó una piedra al agua, y las ondas comenzaron a expandirse.

“Mirá el agua. No podés detener las ondas, pero podés aprender a fluir con ellas.
La verdadera maestría no está en controlarlo todo, sino en construir el camino para que las cosas fluyan con armonía.”

El joven entendió. Su entrenamiento ya no sería memorizar movimientos, sino aprender a construir prácticas y sistemas que funcionen, incluso cuando no pudiera ver ni controlar cada detalle.

En la automatización empresarial pasa lo mismo. Muchas organizaciones intentan controlar cada script, cada tarea, cada excepción, aferrándose a esa ilusión de control. Pero para madurar, colaborar y evitar errores, hay que dejar esa ilusión atrás y construir prácticas compartidas: entender dónde estamos (madurez), cómo evolucionar (de comunidades informales a estructuras formales) y cómo evitar caer en los antipatrones que nos devuelven al caos.

Modelos de madurez en automatización

A la hora de recorrer el camino de la automatización, es importante saber dónde estamos, y el camino que tenemos por delante. Para eso es muy útil un modelo de madurez.

0. Manual

En esta etapa, las tareas de IT se realizan de forma completamente manual. No existen procedimientos definidos, la documentación es mínima o inexistente, y cada cambio o configuración depende del conocimiento individual de las personas. Los errores son frecuentes y los tiempos de entrega son altos.

1. Experimental

Algunos equipos comienzan a automatizar tareas puntuales, usualmente mediante scripts propios, en base a impulsos individuales, o de pequeños equipos. No hay un enfoque común ni herramientas compartidas. Cada grupo trabaja de forma aislada, con distintos lenguajes, estándares y niveles de calidad. El conocimiento no se sistematiza ni se comparte.

2. Definido

Se adoptan herramientas de automatización estandarizadas (como Ansible), y se establecen estructuras reutilizables (roles, playbooks, colecciones). Los procesos empiezan a documentarse formalmente y a compartirse entre equipos. Se promueve la colaboración, aunque aún de forma limitada. La automatización deja de ser una “isla” y empieza a consolidarse como una práctica organizacional.

3. Gestionado

La automatización se gestiona de forma centralizada o coordinada. Existen repositorios comunes, revisión de código, buenas prácticas compartidas y métricas para evaluar el impacto. La colaboración entre áreas técnicas y funcionales se vuelve sistemática. Empiezan a aparecer estructuras como una Community of Practice o incluso un Center of Excellence.

4. Optimizado

La automatización se alinea con los objetivos estratégicos de la organización. Se mide el valor entregado, se identifican oportunidades de mejora continua, y se priorizan iniciativas con alto impacto. La automatización es parte del ADN de la empresa: confiable, visible y sostenible. La cultura se orienta a eliminar el trabajo repetitivo y potenciar el talento.

Es importante entender que en una organización grande, no todos los equipos van a estar en el mismo nivel de madurez. Algunos estarán en el nivel 0 (Manual), la mayoría estarán en el nivel 1 (Experimental) y unos pocos posiblemente están en el nivel 2 (Definido). El primer objetivo debería ser nivelar, para que, como organización, se pueda avanzar en forma coordinada.

Ahora, la madurez no se adquiere adoptando herramientas. La clave son las personas. Ya hablamos en artículos anteriores de la importancia de seleccionar las personas claves para nuestro primer proyecto, pero hoy te quiero hablar de dos estructuras que deberías empezar a construir para nivelar a todos tus equipos de IT, llevándolos al nivel “Definido”, y desde ahí continuar avanzando hasta alcanzar los siguientes niveles.

Los conceptos de los artículos anteriores (4S, elección del primer proyecto, involucrar a personas) son fundamentales para avanzar en esas etapas.

De Comunidad de Prácticas a Centro de Excelencia

El primer paso es construir una Comunidad de Prácticas (Community of Practice o CoP). Una comunidad de prácticas es un grupo informal de personas que comparten un interés común —en este caso, la automatización— y que se reúnen voluntariamente para aprender, compartir experiencias y mejorar su práctica profesional.

No es un equipo formal, ni responde a las estructuras jerárquicas: se forma desde la base, impulsada por la motivación de hacer mejor las cosas y ayudar a otros.

Los objetivos principales de una CoP, en este contexto, son:

• Compartir conocimiento: evitar reinventar la rueda. Aprender de la experiencia de otros.
• Difundir buenas prácticas: cómo organizar un playbook, cómo versionar roles, cómo documentar cambios.
• Mentoría y aprendizaje cruzado: generar un espacio donde los más experientes puedan acompañar a quienes recién comienzan.
• Fomentar la colaboración entre equipos: romper los silos y facilitar el intercambio entre quienes automatizan desde diferentes sectores.
• Identificar patrones y casos de uso: detectar qué procesos son candidatos a ser reutilizados o estandarizados a mayor escala.
• Sembrar la base cultural para futuras estructuras formales (como un CoE): la CoP es el semillero natural de referentes técnicos y culturales que luego pueden liderar un Centro de Excelencia a medida que la organización madura.

¿Cómo nace una Comunidad de Prácticas?

Todo empieza con el primer caso exitoso: un proceso se automatiza exitosamente. Se ve el beneficio: menos errores, más rapidez, menos trabajo repetitivo. El equipo que lo hizo se siente orgulloso… y el resto nota el impacto.

Y luego ocurre algo natural: alguien pregunta “¿Cómo lo hicieron?”. Aparece una conversación, un hilo, una reunión espontánea. Se organizan demos, charlas internas, “cafés técnicos”, y así nace una Comunidad de Prácticas.

¿Qué puede hacer la organización para facilitar y nutrir a una CoP?

Te sugiero un conjunto de actividades que podés promover en tu organización:

• Talleres técnicos abiertos (hands-on): en un laboratorio donde se pueda probar Ansible en un entorno controlado.
• Charlas internas / lightning talks: donde integrantes del equipo pueden mostrar algo que automatizaron, en un estilo informal.
• Hackathones o desafíos para automatizar tareas, con incentivos simbólicos o reales (stickers o medallas digitales, recursos para un after del equipo, etc.). Los desafíos pueden ser individuales o por equipos.
• Canales internos dedicados (chat, foro, wiki, repositorio) que permitan hacer preguntas, compartir recursos, pedir ayuda, etc.
• Reconocimiento explícito del liderazgo informal en reuniones, Town Halls, boletines, a quienes aportan a la Comunidad. Puede ser simbólico, pero tiene alto impacto para apuntalar la cultura.

La CoP te va a llevar al estado “Definido” del Modelo de Madurez, por lo tanto, en el punto que estés hoy, a partir del primer proyecto deberías estar tomando acción para que se genere esa Comunidad.

Una vez que llegás a esta etapa, lo que vas a necesitar para pasar al estado “Gestionado” y seguir avanzando es un Centro de Excelencia (Center of Excellence o CoE).

El Centro de Excelencia de Automatización

Al contrario de la CoP, un CoE es una estructura formal dentro de la organización, que se encarga de liderar, coordinar y sostener las iniciativas de automatización, para que sean sostenibles y escalables, y estén alineadas a la estrategia y objetivos de la organización.

El CoE se crea cuando la organización ya reconoce el valor de la automatización, y necesita ordenar y profesionalizar los esfuerzos.

Objetivos principales del CoE de Automatización:

• Definir estándares técnicos y de calidad: cómo se escriben, documentan, prueban y versionan los artefactos de automatización.
• Seleccionar y mantener herramientas comunes: entorno de desarrollo, orquestación, control de versiones, etc.
• Reutilizar y mantener componentes compartidos: gestiona el catálogo de automatismos, listos para ser consumidos por diferentes equipos.
• Dar soporte y acompañamiento a los equipos: provee guía, formación y ayuda técnica.
• Alinear la automatización con los objetivos del negocio.
• Medir y reportar resultados: define métricas de madurez, ROI y adopción, para mostrar el progreso y el valor aportado.

Se podría resumir así:

• La Comunidad de Prácticas cultiva la cultura.
• El Centro de Excelencia la transforma en estructura.

El CoE nace desde una CoP madura. Lo importante es que no borre la cultura comunitaria, sino que la potencie con recursos, foco y visibilidad organizacional.

Recuerda que debes olvidar la ilusión del control.

Antipatrones en automatización (y cómo evitarlos)

Para terminar, en el camino de la automatización es fácil caer en algunas trampas. Te comento los antipatrones más comunes:

• Automatizar caos: procesos mal definidos o ineficientes. Muchas veces se piensa que la automatización, “automágicamente”, va a resolver problemas con los procesos. No hay atajos: trabajá en tus procesos antes de automatizarlos.
• Scriptitis: proliferación de scripts sin estándares. Este es un problema cuando tenés equipos que ya tienen automatismos que funcionan. La CoP puede ayudar a mostrar valor, y hacer la transición.
• Tecnología primero: obsesión con la herramienta sobre los objetivos.
• Silos automatizados: equipos que no comparten ni reutilizan. Relacionado con el antipatrón de Scriptitis. Falta de pensamiento estratégico y de alineación con el negocio.
• Falta de métricas: no medir impacto ni aprendizaje.

Recuerda las 4S (Sencillo, Seguro, Sostenible, Significativo), que vimos en el artículo anterior. Involucrar a las personas correctas, y mostrar éxitos tempranos. Ansible es una herramienta excelente, pero es eso, una herramienta. Usarla correctamente te va a aportar muchísimo valor.

Y así llegamos al final de esta serie…

La parte más fácil de la automatización es adoptar Ansible y escribir playbooks. Lo verdaderamente crítico es construir capacidad y dar valor para el negocio. Para eso empezamos con pequeños logros, involucramos a las personas, compartimos lo que aprendemos, evitamos las trampas comunes y vamos consolidando una práctica que escale.

Como nos enseñó el maestro Oogway:

“El verdadero crecimiento ocurre cuando dejamos de querer controlarlo todo, y empezamos a construir sistemas que nos permitan avanzar juntos.”

No. 1: Deep Purple

En casi cualquiera de sus sabores, si bien tengo cierta predilección por la siguiente formación, la que considero más clásica de la banda.

• Jon Lord: Teclados
• Ritchie Blackmore: Guitarra
• Ian Gillan: Voz
• Roger Glover: Bajo
• Ian Pace: Batería

Esta es la alineación que escuché por primera vez, en el disco de 1984 “Perfect Strangers”. Lamentablemente, las diferencias entre Gillan y Blackmore no se pudieron superar y este último dejó la banda finalmente, pero Deep Purple sigue rockeando.

5 músicos de lujo, en cada alineación, con muchos cambios luego de la reunión del ‘84 debido a los problemas entre Blackmore y Gillan que hicieron la convivencia insostenible. Joe Lynn Turner, Joe Satriani, Steve Morse, Don Airey (que llegó cuando falleció Jon Lord), entre otros.

Te dejo con el clip del tema “Perfect Strangers” del álbum homónimo de 1984.

No. 2: Led Zeppelin

No recuerdo que escuché primero de Zepp, si fue “Staiway to Heaven”, si fue “Whole Lotta Love”, si fue “Black Dog”. Pero me encantaron. Al contrario de Purple, Zeppelin nunca cambió su alineación:

• Robert Plant en voz
• Jimmy Page en guitarra
• John Paul Jones en bajo y teclados
• y John Bonham en la batería.

Supieron amalgamar el rock, el heavy, el blues, el soul, y hasta ritmos orientales de manera magistral.

Tuve la oportunidad de ver a Page y Plant en Buenos Aires, en 1996 y fue una experiencia alucinante, sobre todo por la energía que transmitía Robert desde el escenario.

Te dejo con uno de sus clásicos, Kashmir

No. 3: Jimi Hendrix Experience

¿Que se puede decir del músico que revolucionó lo que se podía hacer con una guitarra? Uno de los guitarristas más influyentes de todos los tiempos. Tengo que confesar que no lo escucho todo lo que debería, y quizás por eso queda en 3er. lugar. Es un orden de preferencias, más que de calidad musical.

James Marshall Hendrix, guitarrista norteamericano que brilló en Inglaterra. Descubierto por Chas Chandler, bajista de los Animals, que lo llevó a la vieja Albion y consiguió los socios ideales para su Jimi Hendrix Experience, Noel Redding y Mitch Mitchell.

Donde brillaba Jimi sin dudas era en vivo, tenía una gran presencia escénica donde hacía cosas increíbles. Temas como “Purple Haze”, “Voodoo Child”, “Foxy Lady” tenían mágia, aunque mi favorito es “All Along the Watchtower”. Sobre este tema, el autor, Bob Dylan dijo que desde la muerte de Jimi lo toca como lo hacía él, y que de alguna manera siente que es un homenaje. Nada más ni nada menos.

Lamentablemente, su adicción lo destruyó y murió a los 27 años, pasando a formar parte del infame “Club de los 27”.

Justamente ese es el tema que te dejo como cierre de este pequeño artículo, All Along the Watchtower

Espero que te haya gustado el artículo y esperame para mas tops.

• Vamos a hablar de temas, grupos y cantantes que, de seguir vivos, empezaron en los 60’s por lo menos.
• No voy a ser riguroso con los estilos y los períodos de tiempo.
• Soy dogmático.

Por todo eso, mi primer artículo del tema no es un Top 5. Es mi Top 3.

En la Flota Estelar, nadie quiere ser el oficial de ingeniería que rompe todo en su primer día.

El teniente recién asignado, entusiasmado por demostrar su valía, decide automatizar la calibración de los sensores de largo alcance. Pero no consulta a nadie, sube su script al núcleo de control y… sin quererlo, deja a la nave ciega justo cuando entra en una anomalía gravitacional.

No fue malicia. Fue puro entusiasmo sin contexto.

Afortunadamente, el capitán no ordena su traslado a una colonia minera. En cambio, lo manda a entrenar con la ingeniera jefe: una veterana que ya vio más reinicios forzados que amaneceres en Risa.

— “Automatizar no es solo escribir código, teniente”, le dice. — “Es entender qué parte del sistema podés tocar, cuál no, y sobre todo: por qué importa eso.”

Juntos, revisan el catálogo de tareas repetitivas. Eligen una pequeña, aislada, pero importante: reinicializar las secuencias de diagnóstico de los replicadores. Una hora después, la tripulación disfruta de café caliente servido más rápido que nunca.

Ese día, el teniente no salvó la nave. Pero ganó la confianza del equipo. Y ese fue el verdadero comienzo de su misión.

Introducción

En el artículo anterior hablábamos de tener una visión estratégica para encarar la automatización de IT a nivel empresa, y los elementos principales de esa estrategia. También te hablamos de los 3 pilares: Procesos, Personas y Tecnología.

La Tecnología la presentamos en el primer capítulo de la serie: Ansible.

Hoy toca hablar de otros pilares importantes que son los Procesos, sobre todo los primeros procesos a automatizar, que van a marcar el tono del resto del camino: como se trabaja, con quién, qué se prioriza y que nivel de calidad se espera. También vamos a hablar de las Personas, con el enfoque en quienes van a elegir esos primeros procesos.

Si se eligen bien los proyectos, se acelera la adopción y se generan aliados. Por el contrario, si se elige mal, se genera rechazo, frustración o la percepción de “esto no sirve”.

Por eso le vamos a dedicar un artículo entero, para ayudarte a elegir los primeros proyectos que funcionen, entusiasmen y sumen valor.

Criterios para elegir un buen primer caso

¿Qué características deben tener los procesos candidatos? Te voy a presentar un marco sencillo, pero efectivo, las 4S (Sencillo, Seguro, Sostenible, Significativo):

Sencillo: técnicamente simple, sin dependencias complejas.

Sencillo no significa trivial. Un proceso sencillo es uno que está bien documentado, todos los pasos están definidos claramente y sus parámetros están establecidos para cada ambiente.

Seguro: no arriesga entornos críticos, fácil de probar y revertir. Si bien Ansible tiene mecanismos de salvaguarda antes de hacer cambios, es bueno que las primeras pruebas se puedan hacer en ambientes no productivos, y que sea fácilmente trasladables a ambientes productivos (idealmente cambiando solo parámetros vía variables) o que se puedan deshacer estos cambios fácilmente.

Sostenible: se puede mantener y extender fácilmente.

El ideal es que podamos usar módulos de Ansible para todos los pasos del proceso. Eso hace que el automatismo sea legible, y fácilmente sustentable, además de que podemos aprovechar una importante propiedad de la mayoría de los módulos de Ansible: la idempotencia.

Significativo: ahorra tiempo o resuelve una molestia real (visible para otros). Para que un proceso sea significativo, debe tener impacto para el negocio, más que para IT.

Candidatos que suelen fracasar

• Procesos muy complejos o con demasiados sistemas involucrados.
• Casos sin dueño claro o sin usuarios dispuestos a colaborar.
• Automatizar algo que ya está por desaparecer o ser reemplazado.

Ejemplos de buenos primeros pasos

• Despliegue de una aplicación web en ambiente de pruebas.
• Automatizar actualizaciones de seguridad.
• Provisión de cuentas de usuario en un entorno controlado.
• Backups automatizados de archivos de configuración.

Dos de estos casos los usamos en un proyecto de adopción de automatización. Uno fue el despliegue de una aplicación web (Java Enterprise en JBoss) que interesaba poder delegar a los desarrolladores para que actualizaran ambiente de test o desarrollo. El proceso estaba bien claro y había un referente del proceso, y el valor para el negocio era agilizar el trabajo de los desarrolladores y liberar al equipo de infraestructura de una tarea tediosa que no generaba valor.

El otro caso fue el aprovisionamiento de cuentas de usuario, que incluía también la configuración de teléfonos IP y accesos en distintos servicios. En este caso, el problema era que al tener varios pasos alguno se pasaba por alto al momento de ingresar un nuevo funcionario a la organización y eso generaba demoras y reclamos al equipo de IT.

¿Quién debería elegir los primeros procesos a automatizar?

Automatizar no es apretar un botón. Tampoco es una decisión que pueda tomar una sola persona desde su escritorio. Si queremos que los primeros pasos con Ansible generen impacto real y no se queden en una prueba de laboratorio, necesitamos que las personas correctas estén involucradas desde el principio.

¿Quiénes deberían participar?

• El consultor experto en Ansible: alguien con experiencia y conocimiento para aplicar la automatización con Ansible en distintos dominios. Este consultor además dirigirá los talleres necesarios, enseñará las mejores prácticas, y sobre todo, ayudará a seleccionar, entre todos los candidatos, cuáles son los mejores para comenzar.
• Alguien del equipo técnico: que tenga conocimiento de Ansible o esté dispuesto a aprenderlo. Idealmente, alguien que ya haya trabajado con shell scripts o tareas repetitivas y vea en Ansible una forma más estructurada y escalable de automatizar.
• Una persona del área funcional u operativa: que entienda el proceso como se hace hoy, con sus excepciones, atajos y dolores reales.
• Un referente de negocio o líder de área: que pueda conectar el esfuerzo con prioridades más amplias: reducir tiempos, liberar al equipo de tareas repetitivas o mejorar la trazabilidad.

¿Cómo deberían trabajar?

• Sesión de descubrimiento. Revisar procesos actuales, identificar tareas manuales, entender los sistemas involucrados. Preguntar: ¿esto se puede hacer con Ansible? ¿Hay módulos disponibles? ¿La tarea es lo suficientemente predecible como para declararla en YAML?
• Lenguaje común. No todos tienen que escribir playbooks. Pero todos deben entender qué se gana si automatizamos ese proceso con Ansible, qué riesgos evitamos, y cómo vamos a validar que funciona.

¿Por qué es importante este punto?

Porque Ansible no es mágico, pero bien usado, puede dar resultados rápidos, sostenibles y visibles. Y si el primer proceso se elige mal, no solo falla la automatización: se pierde confianza. La automatización con Ansible, para algunos de tus colaboradores va a implicar cambiar la forma de trabajar. Sin éxitos rápidos y consistentes, lo que vas a obtener es resistencia, en vez de colaboración.

Llamado a la acción

Como el teniente de la Flota, lo importante no es impresionar con fuegos artificiales, sino empezar con algo simple que funcione y construir confianza.

¿Ya hiciste tu primer proyecto? ¿Cómo resultó? Y si no, ¿Querés ayuda para identificar tu primer proyecto? Podemos charlarlo. A veces, el mejor primer paso es una buena conversación.

En nuestro próximo encuentro terminaremos la serie hablando del tercer pilar, las personas, y como generar una cultura de automatización, y derribar los silos organizacionales.

Había una vez un joven Sysadmin Jedi que quería automatizar. Y para esto escribía shell-scripts sin cesar. Pero una incómoda voz en su interior le susurraba, una y otra vez, que no, eso no escalaba. El joven Sysadmin Jedi se preguntaba: ¿Cómo podía integrar su automatización con los servidores Windows? y sobre todo: ¿Qué pasaría cuando un router o un balanceador se involucraran?

El novato Jedi, en su ambiente podía automatizar libremente, pero no tenía un idioma común para dialogar con sus colegas. Entonces algo extraordinario pasó, un poderoso Maestro Jedi apareció, y el poder de la fuerza le mostró. “Ansible es mi nombre”, dijo con una voz que lo inundó todo, y de una forma sabia los obstáculos derribó.

“¿Un Maestro Jedi de la Automatización quieres ser, como yo?”, le dijo mirándolo fijo, “Entonces continúa leyendo con atención.”

La importancia de la automatización empresarial

Ya hace tiempo que la automatización empresarial ha dejado de ser una opción. Con la virtualización, y el uso cada vez mayor de la nube. La aplicación manual de parches para la gestión de vulnerabilidades, o el escalado de la infraestructura, implican un desvío de recursos en tareas de poco valor agregado que impactan negativamente en la fuerza de trabajo.

Un caso de uso sencillo, como el despliegue de una aplicación web, puede llevar hasta un mes o más, desde la solicitud inicial hasta que todos los componentes estén disponibles y la aplicación desplegada.

La documentación de los sistemas se hace difícil de mantener, aumenta el desvío de configuración, los ambientes caen en estados inconsistentes, y las posibilidades de problemas de seguridad aumentan. Y estos problemas se producen principalmente en empresas grandes y con un montón de sistemas heredados para mantener. Donde cada aspecto de IT es además gestionado por grupos distintos: Mesa de Ayuda, Operaciones, Desarrollo, Redes, etc.

La automatización:

• libera recursos para tareas que aportan valor,
• aumenta la satisfacción de la fuerza de trabajo,
• acelera los tiempos de desarrollo, manteniendo la consistencia y aumentando la seguridad.

Desafíos claves para adoptar la Automatización Escalable

Infraestructura Compleja

Sin duda que la infraestructura híbrida y multicloud implica desafíos, principalmente en las grandes organizaciones. La evolución del Departamento de TI naturalmente favoreció la creación de “silos tecnológicos” que administran distintos sistemas y componentes y hablan su propio lenguaje. Para mantener un control se han diseñado procedimientos basados en sistemas de gestión que en general, agregan burocracia sin mejorar el desempeño.

Seguridad y cumplimiento

El control de acceso y consiguiente registro de auditoria es un desafío. En algunas organizaciones se utilizan múltiples usuarios para las tareas administrativas, de acuerdo a los sistemas y el nivel de acceso, con la complejidad de tener que mantener esas múltiples cuentas y sus credenciales y la gestión de la desvinculación de personal de IT.

Gobierno y Estandarización

Los Entornos Operativos Estándar aseguran la consistencia de los sistemas y facilitan la administración. Pero esto es un desafío cuando tenemos sistemas heterogéneos, y ese desafío aumenta con los sistemas en la nube. Cuando los cambios se realizan según necesidades puntuales producirán desvíos, la mayoría de las veces no documentados. La probabilidad de esto también aumenta con las urgencias, y con el tiempo generarán más incidentes de soporte o de seguridad.

La solución de estos problemas requiere un enfoque estratégico a nivel de la organización, para que la solución de los desafíos de IT estén alineados a las necesidades del negocio.

¿Por qué Ansible?

Ansible es una herramienta de automatización de código abierto.

Escrita originalmente por Michael De Haan (Cobbler, FUNC) en 2012, se ha convertido prácticamente en el estándar de facto para la automatización de IT. A diferencia de otras herramientas de automatización basadas en agentes, Ansible utiliza conexiones temporales usando SSH o WinRM, lo que hace más sencilla la implementación. Tiene una arquitectura modular, lo que permite extender su funcionalidad en base a plugins, y fundamentalmente los módulos, que son las “tools in the box”.

Existen más de 2.000 módulos para operar infraestructura en nube en los principales “hyperscalers”, servidores de la familia Unix, servidores Windows y equipamiento de red.

Utiliza una sintaxis declarativa basada en YAML, que hace que sea muy fácil de mantener y sobre todo, de leer.

Ansible sobresale por su:

• Arquitectura escalable: que lo hace ideal para pequeños y grandes despliegues.
• Idempotencia: que asegura un estado consistente entre múltiples sistemas.
• Seguridad: Elimina la necesidad de múltiples cuentas. Las credenciales y otra información sensible se pueden mantener cifradas.

Casos de Uso

Ansible se destaca en:

• Gestión de la configuración: mantiene configuraciones consistentes a través de miles de servidores.
• CI/CD: Automatización de pipelines de build and deploy.
• Orquestación de Cloud: Gestión de infraestructura en la nube híbrida.

Un ejemplo: Como muchas organizaciones, NASA quería pasar de gestionar sus propios datacenters, que son costosos de administrar y difíciles de escalar, a infraestructura en la nube. El desafío particular era mover 65 aplicaciones basadas en hardware, a la nube de Amazon (AWS). Gestionar múltiples VPCs y diferentes cuentas hacía esto bastante complejo. Previamente NASA utilizaba Shell Scripts y conexiones SSH manuales, pero con la implementación de Ansible lograron:

• Aplicar actualizaciones en servidores web con un simple playbook de 10 líneas.
• Reparación inmediata de problemas de seguridad.
• Cada semana las versiones web y mobile de son actualizadas en menos de 5 minutos.
• Los usuarios son creados y eliminados instantáneamente, asegurando que solo tienen acceso a los servidores las personas indicadas.
• También integraron Ansible facts a su CMDB para tener mayor visibilidad de la infraestructura.

Ref: https://www.linkedin.com/pulse/case-study-explained-how-nasa-used-ansible-migrate-cloud-sharma/

Primeros pasos

Los requerimientos básicos para usar Ansible son tener Python, SSH y Ansible. Es recomendable utilizar alguna de las distribuciones de la familia Red Hat.

Puedes seguir las instrucciones de la documentación de Ansible para crear tu nodo de control.

Te muestro un playbook simple para configurar un servidor web.

- name: Demo playbook to install apache web server on Red Hat.
  hosts: webserver

  tasks:
  - name: Install httpd package
    dnf:
       name: httpd
       state: latest
  
  - name: Start and enable httpd service
    service:
       name: httpd
       enabled: true
       state: started

  - name: Create a custom index.html file
    copy:
       dest: /var/www/html/index.html
       content: \|
           Enable SysAdmin Demo
           Ansible first steps
           Custom Web Page

Con este ejemplo te invito a que des tus primeros pasos.

Conclusión

La automatización de IT en la empresa te va a permitir simplificar las tareas administrativas, y liberar recursos para utilizar donde sea necesario aportarle valor al negocio.

Coming soon

En el próximo artículo de esta serie hablaremos acerca de la Estrategia de Automatización. Te invito a seguir la serie para profundizar en este importante tema.

Había una vez una Comunidad — valiente, bien intencionada, y sinceramente… un poco caótica — formada para llevar a cabo una gran misión: destruir la Única Tarea Manual. Esta criatura los dominaba a todos. Cada miembro tenía su propia forma de enfrentarla.

El elfo escribía scripts elegantes que solo él podía entender.

El enano prefería las tareas programadas, porque ‘eso siempre funciona’.

El mago insistía en que la próxima versión del framework iba a resolverlo todo.

El montaraz trabajaba solo, evitando reuniones.

Y los hobbits… ellos solo querían algo simple que funcionara.

Todos hacían su mejor esfuerzo, pero el avance… era mínimo. Sí, había automatización — pero aislada, sin una visión común. Hasta que, finalmente, dejaron de enfocarse en cómo y empezaron a hablar del por qué. Se alinearon: qué automatizar primero, quién lo haría, y cómo hacerlo de forma reutilizable. Empezaron a compartir lo que aprendían. A reutilizar el trabajo de los demás. A hablar un mismo lenguaje de automatización. Ahí fue cuando la verdadera aventura comenzó — no con scripts, sino con estrategia.

Introducción

En el artículo anterior te presenté Ansible. Si hiciste los deberes, seguro miraste un poco la documentación, y capaz que hasta probaste un laboratorio. Y se lo mostraste a tus colegas… y es muy probable que algunos ya lo conocieran, y hasta lo estuvieran usando (si tengo que apostar, serían los elfos). Entonces, me dirás, “¡Ya está!” Pero no, esto recién empieza. Si tenés equipos automatizando en tu organización, incluso usando Ansible, lo que probablemente tenés son ‘silos automatizados’. Seguramente son eficientes en lo que hacen, pero todavía no le aportan valor a toda la organización. Lo que necesitás no son más playbooks. Lo que necesitás es estrategia.

¿Que entendemos por estrategia?

La estrategia es un plan de alto nivel, con un objetivo concreto. Es la guía que nos servirá de base para tomar decisiones, priorizar acciones y coordinar esfuerzos. En el contexto de la automatización, la estrategia nos permite establecer qué automatizar, por qué, cómo y con quién.

En mi experiencia, la estrategia se desarrolla sobre 3 pilares: los procesos, las personas, y las tecnologías.

Procesos: el objetivo es agilizar los procesos. Deben estar definidos y documentados. Y deben aportar valor. Siempre recuerdo esta máxima de uno de mis profesores en la Universidad: “No debemos informatizar ineficiencias”. Automatizar procesos mal diseñados lleva a la frustración y al fracaso.

Personas: Detrás de cada proceso hay personas: quienes lo ejecutan, quienes lo diseñan, quienes lo soportan. Debemos identificar a los involucrados, quienes se benefician, y más importante, quienes pueden resistirse, para incluirlos en el diseño y la adopción de la solución. Sin involucramiento, no hay adopción, ni automatización exitosa.

Tecnología: Las herramientas son importantes, pero no son el centro, sino un medio para llegar a un fin. Ya identificamos a Ansible como la mejor herramienta, pero no es una bala de plata. La tecnología potencia la estrategia, no la reemplaza.

Un ejemplo

Mi primer proyecto de automatización comenzó con un taller sobre Ansible. El objetivo era presentar las capacidades de la herramienta para que los involucrados vieran las posibilidades.

A continuación tuvimos una sesión que podríamos llamar de “descubrimiento”. Como era un proyecto pequeño, solo estaba involucrado parte del equipo de IT. El objetivo era no solo automatizar algún proceso, sino también empoderar al equipo y, a partir de ese núcleo, crecer en la automatización. Involucramos también a la gerencia, para tener su visión y compromiso.

En esa reunión de descubrimiento surgieron varios procesos que identificaban como “pain points”. De esos, el equipo de IT seleccionó 2 que podíamos desarrollar en un plazo de pocos días, y que les aportaban valor, ya fuera porque eran procesos complejos que involucraban múltiples sistemas, o porque eran procesos repetitivos y manuales que distraían recursos.

Formamos 2 duplas: un consultor experto en Ansible y en las tecnologías involucradas en esos procesos, junto a alguien del equipo del cliente que conocía a fondo como se hacía. Ese integrante participó durante el desarrollo de las automatizaciones, para que pudieran aprender a usar la herramienta, de forma de darle soporte y poder desarrollar más automatismos a futuro.

Este proyecto me dejó varias lecciones valiosas que hoy forman parte de mi forma de encarar la automatización. Las resumo en 3 principios que, si estás empezando, pueden ayudarte a evitar errores y ganar tracción desde el inicio.

Tres principios para empezar con el pie derecho

1. Empezá en pequeño y mostrá valor rápido: Elegí un proceso simple, estable y que aporte ese valor. Este primer caso de uso puede parecer pequeño, pero si genera entusiasmo y demuestra resultados, será tu mejor carta de presentación.

2. Involucra a las personas correctas: Preguntá ¿qué problema se resuelve con esta automatización? Hablá con las personas que están cerca del trabajo real, y escuchá lo que necesitan para hacerlo mejor. “La herramienta puede ser Ansible, pero la estrategia es lo que une a los equipos, acelera los procesos y conecta el trabajo técnico con los objetivos de negocio.”

3. Aprovechá las capacidades de la tecnología: Usá un lenguaje y estructura clara, y establecelo como norma. Es más importante que cualquier persona pueda leer y entender lo que escribís a que sea una obra de arte técnica.

Qué hace que un proyecto de automatización funcione… o fracase

✅ Factores de éxito

• Compromiso de la Dirección para destinar recursos.
• Referentes con autoridad técnica y que conozcan los procesos.
• Documentar el proceso de forma clara y sencilla.
• Debe ser simple de probar. Que no interfiera con el trabajo del equipo.
• Fundamental: que aporte valor real al negocio.

❌ Errores comunes

• No comunicar claramente el objetivo. A veces, personas con mucha experiencia ya automatizaron lo que necesitaban y ven a Ansible como un paso atrás o como una amenaza a su autonomía. Incluirlos en el diseño de la estrategia y mostrar cómo pueden aprovechar su conocimiento dentro de un marco común es clave para el éxito.
• No obtener feedback de las personas involucradas.
• Automatizar procesos mal definidos o inestables.
• Complicar las cosas desde el principio (sobreingeniería innecesaria).

“Muchos proyectos de automatización fracasan no por fallos técnicos, sino por errores estratégicos y organizacionales. Entre los más comunes están: automatizar procesos ineficientes, enamorarse de una única tecnología, excluir a las áreas de negocio, y tener expectativas poco realistas sin una estrategia clara.” — Gartner - “10 automation mistakes to avoid”

Cierre

Una buena estrategia de automatización no trata de hacerlo todo, sino de hacer lo correcto y hacerlo bien. Para eso, elegir los primeros casos de uso es clave. Te lo cuento en el próximo artículo.