Hace ya varios años que tuve la oportunidad de experimentar el poder de la automatización en redes de gran tamaño. Mi 1a aproximación fue usar scripts de VBS en SecureCRT, hoy hago scripts no vinculados a una terminal y conozco más de Netconf/Yang y un orquestador de Cisco. Lo que van a leer a continuación es una descripción de mi visión, según mi experiencia, de cómo introducir la programabilidad de red en un equipo de trabajo, cómo estimar el esfuerzo ahorrado y una sugerencia de etapas de implementación. Al final les dejo un pequeño ejemplo con base en un programa que hice recientemente para que saboreen un poco de Python. Disfrútenlo.
Resumen: ¿Por qué programar y por qué Python/Excel?, Estimación de esfuerzo, Etapas y fases para un equipo de trabajo, Utilidad y limitaciones, Programa de ejemplo, Conclusiones y continuación
Introducción: ¿por qué programar y por qué Python/Excel?
A manera de introducción les recuerdo que Cisco va a cambiar completamente su esquema de certificaciones a partir de Febrero de 2020, un enfoque orientado a los logros y a la ludificación (luego les escribo al respecto). Una de las características más interesantes de ese cambio es una línea de certificaciones sobre programabilidad de red, algo indispensable para cualquier operador, carrier o ISP que se quiera montar de verdad sobre el tren de SDN o la automatización. Yo opino que lo primero que hay que hacer no es comprar plataformas, es cambiar la mentalidad de los ingenieros y capacitarlos en programación. Cisco probablemente se haya dado cuenta, que hacer un programa para una tarea rutinaria ahorra muchísimo tiempo respecto al paradigma actual y que éste paso es necesario para que la panacea de SDN (con toda su complejidad) se haga realidad. Hay otra justificación más personal que seguro más de uno ya ha visto: si la empresa no invierte en automatización, el ingeniero sí se puede dar más tiempo haciendo un buen programa 😉 Al respecto ya publiqué alguna vez sobre la discusión: es ético automatizar y no avisar?
Programar es la forma de administrar redes de hoy y del futuro, en una ocasión anterior describí algunas tareas típicas en las cuales yo veo protagonismo para la automatización. No es necesario empezar con una plataforma de automatización como las que ofrecen los grandes fabricantes, por ejemplo NSO/NCS de Cisco o las arquitecturas de Agile Controller de Huawei, éstos sistemas usualmente involucran mucha programación y conocer más acerca de las formas estándar de comunicación entre sistemas IT, no sólo hay que saber de redes (con conocimiento avanzado). Es mejor y más fácil, empezar con un enfoque de programabilidad básica, con lenguajes fáciles y con tareas relativamente simples. De ésta idea se desprende un plan de trabajo para implementar de manera exitosa la programación/automatización en la operación de la red en una primera fase que sólo involucra a los ingenieros y la operación.
Python, de otro lado, se ha convertido en uno de los lenguajes más populares hoy en día, especialmente en el tratamiento de grandes cantidades de información o big data, no es un lenguaje difícil de aprender y parece que es muy eficiente además de soportar algunas estructuras de programación avanzadas que no todos los lenguajes soportan como las lambdas. Hay otra particularidad importante del mismo como lenguaje iniciático a parte de su curva de aprendizaje: muchos fabricantes están incluyendo módulos de Python en sus dispositivos. Los nuevos sistemas operativos de Cisco (IOS XE/XR) cuentan con módulos de programabilidad en el lenguaje, así como ALU e incluso Huawei tiene un rudimento por el estilo.
Sobre Excel no hay mucho qué decir: todos los actores en el diseño, implementación y operación de redes tenemos mucha familiaridad con ésta herramienta y la usamos cotidianamente, otra discusión que se podría dar es si explotamos todo lo que ésta puede hacer, pero lo mínimo que podemos decir es que es MUY popular. Por ende, usar Python para leer y escribir en archivos de Excel es tal vez la opción más fácil a la hora de introducir la automatización de tareas de administración u operación de red. Una de las ventajas de que Python sea popular es que muchas personas están desarrollando librerías con funciones y objetos muy útiles para hacer cosas sofisticadas.
Estimación de esfuerzo para un script
Aunque quería que esta entrada fuera más técnica, me parece muy importante «vender la idea» y que tanto ingenieros como administrativos vean lo que propongo: automatizar la red es un proceso que toma tiempo y esfuerzo y como programar es una actividad creativa, el ambiente de trabajo no puede ser bajo presión, como acostumbran decir los jefes. Prometo entrar en detalles más técnicos en futuras publicaciones de éste tema.
Hace poco hice un programa que me parece muy ilustrativo de cuánto tiempo ahorra hacer un programa. El escenario es el siguiente: se tienen desplegados unos tendidos de fibra óptica por diferentes ciudades de México, en ciertos puntos se van a instalar routers pequeños que formarán anillos conectados a dos routers agregadores que cerrarán el circuito con un enlace lógico. Entre varias áreas de la organización se decide qué sitios conformarán los anillos, una vez acordados dan un listado de sitios que componen diferentes anillos terminados en agregadores distribuidos por la ciudad/región. La tarea del área de ingeniería (donde yo trabajo) es entregar las configuraciones que tendrán cada uno de los routers para el despliegue. La tarea original consistía en tomar los nombres de los sitios y, para cada anillo, asignar nombres de host, direcciones IP de loopback (dos por router), un SystemID para enrutar con ISIS, direcciones IP de cada interfaz, sus descripciones y, con base en la distancia entre los sitios definir el tipo de transceivers/SFPs y cantidad que se deben pedir al almacén. Este trabajo tomaba más o menos 1 semana, cuando se enviaban los scripts a veces tenían errores pequeños que hacían que la operación fallara y se reprogramara. La última instrucción que recibimos fue que una vez que se terminara el IP Plan, dos ingenieros revisaran con lupa que todo estuviera bien y sólo después de la doble revisión se entregara el resultado a operaciones. La siguiente imagen describe el escenario, los anillos típicamente tienen entre 5 y 10 routers y son de 50 a 100 anillos por región. Como pueden ver en la imagen hay varias situaciones de excepción: anillos que no cierran, routers que no hacen parte del anillo sino que son ramas pegadas a un router del anillo, etc. Esas excepciones son de la operación, no se pueden cambiar por la dinámica del despliegue y el programa debe tenerlas en cuenta.
Ante la sugerencia de hacer un programa en vez de toda esta mecánica tan arcaica, el coordinador aceptó y he aquí el programa que hice: toma de una hoja de cálculo con los siguientes datos:
- Un listado de nombres de routers (de 50 a 100) organizados por grupos que conforman anillos
- Los nombres de cada sitio de instalación
- Las distancias entre sitio y sitio
- Una hoja con los nombres de los agregadores y las interfaces a las cuales se pega el 1er router de cada anillo
- Una hoja con las direcciones IP base (para las loopbacks y cada enlace punto a punto)
- Algunos parametros del script como qué interfaces usará cada router como este/oeste o para pegar routers fuera del anillo
Adicionalmente a ésta información, que es estrictamente funcional, yo agregué unas instrucciones en la primera hoja sobre cómo usar el programa, qué restricciones/condiciones tiene y qué esperar. Lo primero que hace el script es analizar la consistencia de los datos: numera e imprime cuántos anillos cierran o no cierran, advierte si se usa una misma interfaz para iniciar/terminar un anillo terminando la ejecuión sin continuar y otras cosas que son precondiciones del diseño o podrían ser errores potenciales. Luego, en el mismo archivo XLS y sin modificar el formato inicial (que fue proporcionado por personal de Operaciones), el programa genera y rellena las celdas vacías con las IPs de administración, SysID, las IPs de cada interfaz, su máscara, descripción para cada router. Adicionalmente se genera un inventario (una hoja del mismo archivo) de los diferentes SFP/transceivers. En otras palabras, si el área de planeación tiene definidos todos los anillos de una región para todo el año, generar el IP Plan puede consistir en definir nombres de routers (con un patrón normatizado) y correr el programa que tarda menos de 5 minutos en generar el resultado. Probablemente se pueda terminar el trabajo de todo el año en una semana! El programa no genera scripts de configuración dado que para eso ya habían desarrollado otro programa, lamentablemente no sé si de ésta hoja de cálculo se saque fácilmente el input del otro pero es sólo cuestión de modificar el formato de este output, no es nada difícil, sólo que ésta hoja de cálculo es para otros humanos ya familiarizados con este formato. Yo fui transferido a otra tarea cuando terminé este programa por lo que no pude seguir desarrollando la idea 🙁 Una ventaja de éste método (automático) respecto al original (manual) es que no es susceptible a ciertos errores, por ejemplo, en routers ALU un espacio en la descripción puede hacer que el script falle y la operación se tenga que reprogramar/retrasar; también es muy fácil poner mal una IP y que todo el IP plan se dañe a partir de allí o usar una interfaz equivocada (dos veces por ejemplo) por ello no era descabellada la idea de que dos ing. hicieran revisión del trabajo original en el modo manual. Ésta hoja de cálculo, una vez generada, no requiere revisión (excepto durante el desarrollo).
Como vemos, crear un IP Plan implicaba el trabajo de un ingeniero durante una mañana o un día entero (8 hrs), con frecuencia, después de creado se detectaban errores y eso implicaba otra mañana o más de verificación/corrección y si algún error pasaba a operaciones, por la burocracia típica de la operación de red la tarea se debía reprogramar y el IP plan pasar a revisión nuevamente. Sumele, como mencioné anteriormente, que nuestro coordinador nos había instruído que dos ingenieros debíamos revisar el IP plan una vez que se generara antes de pasarlo a operaciones para evitar reprogramación de cambios en la red. En otras palabras, el trabajo de entregar un IP Plan perfecto a Operaciones tardaba unos 3 días/hombre (1 ing creando y 2 revisando) contando conque la doble revisión eliminara 100% los posibles defectos y no se reprogramaran tareas. Yo estuve programando más o menos una semana y ya tenía listo el programa, luego cotejé la funcionalidad con mis compañeros y ajusté cosas durante otra semana aproximadamente. Los IP Planes que se esperaban hacer durante el año son unos 100, los cuales pasaron de necesitar 3 días/hombre a 4 hrs/hombre (listar los nombres de routers y distancias proporcionadas por los site surveys). Un ahorro de 83% del tiempo requerido originalmente: de 8*3=24 hrs a 4hrs. Eso multiplicado por 100 IP Planes significa un ahorro de 2000 horas de trabajo al año (2400 vs 400).
Hay muchas formas de interpretar el análisis anterior:
- Mi forma de verlo es que las 20 horas que se ahorran (más de 2 días de trabajo si fuera un sólo ing.) se pueden dedicar a estrategias no lineales de innovación, a crear más programas y seguir ahorrando tiempos en ésta escala. Ésta es la forma correcta de ver la automatización: una oportunidad de mejorar las condiciones de trabajo y generar una retroalimentación positiva que cambie la mentalidad de la organización.
- La forma cavernícola de interpretar los datos anteriores es: nos ahorramos casi 1 ing. por mes si se hace 1 IP plan cada mes. Lamentablemente en los países latinoamericanos se tiene éste tipo de mentalidad y se necesitan liderazgos que inspiren y no que continúen el círculo vicioso en el que hacer las cosas bien significa que te van a poner más trabajo o te van a reemplazar pero de ninguna manera obtienes una mejoría directa en tus condiciones. Es decir, es desestimulante hacer las cosas bien.
Etapas y fases en la implementación de programabilidad en un equipo de trabajo
El anterior sólo es un ejemplo, medio rudimentario de lo que puede lograr la programabilidad. Alguien puede sugerir que el programa anterior se podría hacer sin uso de Python, lo cual probablemente sea acertado, pero hacerlo con un programa permite desarrollar las habilidades que se necesitarán más adelante y es mucho más versátil. De otro lado, el problema de hacerlo sobre la hoja de cálculo es que se requiere un cierto nivel de conocimiento para todos los involucrados, no sólo para quien crea la hoja de cálculo sino para todos los actores porque cualquier alteración hará que las fórmulas se dañen o los datos se corrompan, adicionalmente, nos quedamos limitados a las posibilidades de la hoja de cálculo, al fabricante (Microsoft seguramente), a sus capacidades y al nivel de conocimiento de quienes crean e interactúan con el producto (la hoja de cálculo). Todos conocemos la hoja de cálculo, pero no todos sabemos todo lo que puede hacer 🙂 La mejor solución que veo es combinar las tecnologías: fórmulas de la hoja de cálculo + lógica de programación para extender las posibilidades del resultado.
El ejemplo dado es simplemente una implementación de una lógica de programación sobre una tarea rutinaria y masiva, otra tarea típica de las redes es verificar información sobre los equipos, identificar aquellos en los que cierta condición se cumple o no. Para éste tipo de tarea ya se requiere interacción con la red y algo más de riesgo.
Antes de continuar, y mirando más lejos, el enfoque de todo lo que he escrito está orientado a los ingenieros de red y como lo sugerí desde el principio, lo 1ro que hay que hacer es capacitar a los ing. de red en programación. A ésta la consideraríamos una primera etapa, durante la cual, después de dominar la programación y los mecanismos de programabilidad básica de la red, descubriríamos problemas estrictamente de desarrollo: versionamiento, almacenamiento, capacidad de cómputo, entre otros. La segunda etapa es involucrar a programadores natos que nos transfieran ese conocimiento y hacer programas que se hablen de maneras estándar, por ejemplo usando Netconf, y trabajando fuertemente con entornos virtuales; y finalmente una tercera y última etapa en la que usaríamos las plataformas que tienen los diferentes fabricantes para operar la red, es decir WAE, NCS/NSO de Cisco, uTraffic/U2000/Agile controller de Huawei o Nuage de Nokia pero con ingenieros de red que saben de programación y un pequeño Staff de programadores profesionales que saben de redes.
Ahora sí, en la primera etapa, yo sugiero las siguientes fases para una primera etapa de implementación exitosa de la programabilidad y automatización de la operación de la red:
- Programar en la máquina local, usando las herramientas cotidianas (hoja de cálculo), sobre información local y un lenguaje de programación
- Programar interacción con los dispositivos sin riesgo, por ejemplo recolectando información, haciendo auditorías, healthcheck, capacidades, etc.
- Hacer programas para la ejecución de configuraciones (el mayor riesgo), una fase posible etapa 3A sería ejecutar en un ambiente de laboratorio virtualizado antes de ponerlo en ambiente de producción.
En términos generales podemos usar éstas fases como derrotero inicial para implementar exitosamente la automatización en un grupo de trabajo. El 1er nivel, el más simple con menor o cero riesgo, el 2o un poco más complejo y con riesgo mínimo y el 3o la mayor complejidad con un riesgo mayor. En éste derrotero es importante tener herramientas de emulación de redes que permitan hacer pruebas piloto controladas, para minimizar riesgos e impactos, por ejemplo, Eve-NG del cual he escrito ya en éste blog con el cual se pueden emular redes casi reales, muy fieles al ambiente de producción, con casi toda la complejidad de la red real y hacer las pruebas de automatización sobre ellas sin riesgo.
Utilidad y limitaciones de la programabilidad
Cualquier programa está limitado a la calidad de la información sobre la cual opera. Lo que queremos lograr debe estar respaldado por información completa y de buena calidad para lograr el objetivo. Sí, los programas pueden verificar la integridad de la información (en muchas ocasiones), pero ciertamente no pueden validar la completitud (saber qué falta). Un enfoque común que podemos usar es hacer programas específicamente para obtener información completa y de calidad. También hay que tener en cuenta que mientras más «excepciones» tenga la estructura de la información, más complejo va a ser el programa y el esfuerzo puede no ser razonable y más importante: si la organización ha aceptado las «excepciones» seguramente las van a seguir aceptando, es decir, todos es una excepción, por ende el programa va a resultar obsoleto rápidamente y sólo habremos trasladado el esfuerzo de un ing a otro o habríamos creado un proceso más en vez de uno menos. Uno de los valores más importantes de la automatización es cambiar el paradigma de todo es para ayer y todo es una excepción (el CTO personalmente está pendiente) a todo tiene un patrón, está planificado y sólo en algunas ocasiones hay excepciones y se tratan de manera especial.
Para verificar información sobre la red se pueden tener dos enfoques: si existe una base de datos de configuraciones confiable se puede sacar una copia y correr un programa sobre ésta, esta opción es poco probable en redes grandes porque usualmente tal base de datos no existe o no es confiable; de otro lado, el programa puede implementar rutinas de conexión controladas que ingresen a los equipos, ejecuten los comandos necesarios y «anoten» los hallazgos.
Finalmente, dado que queremos hacer cosas masivas, es importante tener en cuenta las limitaciones tiempo que pueden ocurrir, por ejemplo, conectarse a un dispositivo puede tomar algunos segundos, eso a una escala de cientos o miles de equipos sí tiene un impacto mayor. También es posible que los datos superen las capacidades normales de una hoja de cálculo, otros mecanismos básicos de almacenamiento o no se puedan almacenar al ritmo deseado o que se requiera una solución de mayor envergadura. Algunas de éstas limitantes ya las ha resuelto la programación pero se necesita conocer más el entorno para saber qué soluciones hay a mano.
Programa de ejemplo
Para terminar, voy a mostrar un pequeño ejemplo, una porción de un script que hice recientemente. No voy a entrar en detalles de instalación de Python, librerías ni nada por el estilo, eso lo dejaremos para futuras publicaciones.
El escenario es el siguiente: se van a migrar servicios MPLS de un nodo de marca Nokia (ALU), por éste nodo pasan LSPs que a su vez están vinculados con servicios representados en SDPs, cada LSP tiene una IP origen, destino y un nombre. En el nodo a eliminar yo puedo ejecutar un comando que me dice qué LSPs pasan por él, pero no me dice qué servicios, para saberlo debo usar la salida de éste comando, entrar a cada una de las IPs origen que lista y en cada una correr otros dos comandos que me dirán si sí hay servicios pasando por el nodo a eliminar. La tarea se va a repetir varias veces porque se están migrando los servicios de Nokia a otra marca, por ende, antes de apagar y retirar el equipo, se necesita tener un inventario de los servicios que están pasando por él y prever alguna afectación. El problema, es que por cada nodo pasan más de 100 servicios de unos 8 o 10 routers a los cuales toca entrar y correr comandos para preguntar por los LSPs detectados en el nodo a eliminar. Como ven, éste es un buen ejemplo para aplicar un script: la tarea es «masiva» y se repite en el tiempo, no importa si no es una tarea para siempre, conque se repita y cueste mucho trabajo hacerla cada vez es suficiente para pensar en un programa. Se invierte un tiempo en ello para ahorrar mucho más después. También observen que el programa está en la fase inicial descrita anteriormente: se trabaja sólo con información local.
Ésta es la salida del comando show router mpls lsp transit en un router Nokia (Todos los nombres e IPs fueron cambiados):
*A:NOD777-EUA1089-XX# show router mpls lsp transit
===============================================================================
MPLS LSPs (Transit)
===============================================================================
Legend : @ - Active Detour
===============================================================================
From To In I/F Out I/F State LSP Name
-------------------------------------------------------------------------------
192.168.3.156 192.168.3.127 6/2/1 4/2/1 Up
To-NOD123-XXM::primary
192.168.3.127 192.168.3.157 4/2/1 6/2/1 Up
To-NOD234-ABC::primary
192.168.3.127 192.168.3.156 4/2/1 6/2/1 Up
To-NOD234-CDE::primary
192.168.3.127 192.168.3.58 4/2/1 6/2/1 Up
To-NOD234-XXF::primary
192.168.3.125 192.168.48.166 4/2/1 6/2/1 Up
bypass-node192.168.3.80-64763
192.168.3.125 10.170.48.18 4/2/1 6/2/1 Up
bypass-node192.168.3.80-64766
192.168.3.140 192.168.3.125 6/2/1 4/2/1 Up
To-NOD707-XXM::primary
[RESULTADO PARCIAL, PORCIONES OMITIDAS POR BREVEDAD]
-------------------------------------------------------------------------------
LSPs : 126
-------------------------------------------------------------------------------La tarea de un ing. sería ingresar a cada nodo (la ip origen) y buscar si existen SDPs asociados con el nombre del LSP. Los nodos no son más de 10, pero los LSPs son 126 (no todos se mostraron). Como ven el programa debe conectarse a una IP, eso no lo vamos a hacer en ésta ocasión, lo que vamos a hacer, es simplemente reorganizar la información en un excel que contenga por lo menos el 1er comando que debo ejecutar en cada nodo. Voy a usar una característica de Python llamada list comprehension que ya hablaremos de ella y una librería que me permite leer y escribir a archivos de excel llamada Openpyxl
El programa hace lo siguiente: lee un archivo de texto (el resultado del comando de arriba), extrae la información relevante (IPs y nombres de LSPs) y luego en un ciclo se guarda en un archivo de Excel comandos que incluyen el nombre del LSP. Este es un principio, el programa real usa las IPs para conectarse a cada IP (sin repetir), extaer los servicios, guardar la info y hacer un resumen. Osea que éste es sólo el principio 🙂
Destaco varias cosas: el programa tiene una estructura con autor, propósito y última actualización, usa list comprehension y usar Excel como lo he expuesto en la lectura. Probablemente se pueda hacer más fácilmente con otras herramientas, pero como ya lo he mencionado: es un proceso incremental. Este programa sirve para ver la sintaxis de Python y hacer un par de cosas interesantes. El programa es el siguiente:
'''
PURPOSE: Find out which services pass through an specific router and determine if the services need to be migrated beforehand.
USAGE: Execute it as __py <THIS>.py__
AUTHOR: César A. Cabrera E. Created: Jul/2019 Last Updated: Sep 4th/2019
DOCs:
- https://openpyxl.readthedocs.io/en/stable/
'''
import re
import datetime
from openpyxl import load_workbook
# Leer archivo de texto con la salida del comando
transitCommand = open("ServiciosTransito.txt", "r")
lineas=transitCommand.readlines()
print("Lineas leídas: "+str(len(lineas))+", LSPs: "+str(len(lineas)-11))
start=datetime.datetime.now()
transitCommand.close()
# Obtiene las líneas que no incluyan la palabra bypass
LSPs=[x for x in lineas if not re.search("bypass",x)]
# Obtiene las líneas que incluyan algo parecido a una IP
LSPs=[x for x in LSPs if re.search("\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}",x)]
# Extrae los nombres de los LSPs
LSPnames=[x for x in lineas if re.search("bypass|::",x)]
archServicios='servicios.xlsx'
wb = load_workbook(archServicios)
sheet=wb["Sheet1"]
i=0
LSP=[]
lsp_name=""
while i<len(LSPs):
l=LSPs[i]
parts=re.split(" ",l)
host=parts[0]
print(" ==> "+host)
sheet["A"+str(i+1)]=host
lsp_name=LSPnames[i].replace(" ","")
LSP.append({'src':parts[0],'dst':parts[4],'name':lsp_name})
# No incluya los LSP de bypass, sólo los primarios
if not re.search("bypass",lsp_name):
lsp_name=re.split("::",lsp_name)[0]
print(" LSP("+str(i+1)+"): "+lsp_name)
sheet["B"+str(i+1)].value='admin display-config | match context all '+lsp_name
sheet["C"+str(i+1)].value='show service service-using sdp '
else:
print(" Omitiendo bypass-tunel")
i=i+1
print("- Iniciado a : "+str(start))
print("- Finalizado a: "+str(datetime.datetime.now()))
wb.save(archServicios)
wb.close()En ésta publicación no voy a entrar en detalles muy técnicos, así que el programa es sólo una muestra de lo que vamos a hacer más adelante y quien quiera curiosear puede hacerlo libremente con base en el código o esperar la siguiente publicación de continuación del tema.
Cuando se ejecuta éste programa, busca dos archivos en la carpeta local: ServiciosTránsito.txt y Servicios.xlsx, lee el archivo, va imprimiendo sus hallazgos y finaliza indicando el tiempo de ejecución (start/end), por ende la primera salida es a la «consola» o la cmd indicando los datos de resumen y cada LSP analizado. El segundo resultado es lo que queda en el archivo XLSX.
| Salida del programa | Excel |
 |  |
Para experimentar con éste programa es necesario instalar Python, recomendable la versión de Anaconda e instalar la librería openpyxl (bajar pip y luego ejecutar en cmd: pip install openpyxl).
Conclusiones y continuación
Como ven, la programabilidad es un cambio de paradigma que ya está ad portas de ser común. Como ing. de implementaciones u operación, debemos saber del tema porque pronto va a ser necesario y nos veremos en aprietos si no lo dominamos. Como diseñadores, la programabilidad nos permite identificar los patrones más comunes y modularizar las tareas, como implementadores también nos permite hacer cosas masivas con esfuerzos menores y como jefes de equipos de trabajo ésta es una oportunidad de mejorar las condiciones de trabajo, estimular la creatividad y el interés por las labores cotidianas. También es importante reconocer que los programas estarán limitados a la calidad, completitud y estructura de la información sobre la cual trabaja, ésto puede implicar una depuración de procesos e información antes de atacar directamente el problema con algoritmos. Finalmente, los programas no son magia, no se hacen de la noche a la mañana, requieren una actividad creativa intensa, mucho tiempo y un ambiente tranquilo, si al ing. que va a programar, le dan tareas cotidianas a parte de hacer el programa, los resultados seguramente no van a ser satisfactorios: o el programa va a salir con fallas o se va a tardar más tiempo del previsto. Tampoco es correcto dedicar programadores a la tarea de manera exclusiva, el principal problema que enfrenta la automatización ahora es que es una sinergia entre dos mundos igualmente complejos: programación y redes (IP e IT), por ende no sólo programadores ni sólo ingenieros de red, los dos (mejor opción) o ingenieros que tengan ambos perfiles.
Lo que sigue para ésta línea de publicaciones son programas en las etapas mencionadas: conectarse y ejecutar. Adicionalmente, explorar las tareas descritas en otra publicación: panorámica de la automatización de redes. Estén pendientes. Espero que les haya resultado útil y por favor, compartan.