NetBrain El fundador y CEO Lingping Gao presentó su sesión de Think Tank, "Desafíos ocultos de la automatización de redes en la era SDN y más allá", en Cisco Live 2018 en Orlando. Este post resume su presentación.
¿Cuáles son nuestros mayores desafíos de automatización de redes para la automatización de redes? estoy hablando de de hoy Redes del mundo real, no desafíos futuros. Me refiero a nuestros flujos de trabajo y tareas operativas diarias actuales: resolución de problemas, gestión de cambios, seguridad y documentación en redes SDN, multicloud e híbridas.
Hay dos aspectos fundamentales que hacen que la automatización de redes sea un desafío. El primero es la red en sí misma. Las redes actuales son realmente complejas. Acabamos de superar la virtualización y luego llegaron las redes definidas por software como Cisco ACI y ahora tenemos SD-WAN. El segundo aspecto son nuestras herramientas y datos. Usamos muchas herramientas: sistemas de tickets como ServiceNow, soluciones de monitoreo 24×7, Splunk, SEIM e IDS, e incluso APM. Cada herramienta hace su propio trabajo, pero funciona de forma aislada. Terminamos con muchos silos de datos. Tantas herramientas con una gran cantidad de datos significan que automatizar la resolución de problemas o la gestión de cambios no es tan sencillo.
Dicho esto, hay 5 desafíos de automatización de red "ocultos" para la automatización de red práctica cotidiana que he aprendido a lo largo de los años.
Cuando las personas escuchan "automatización de red", a menudo tienen una de dos reacciones. O dicen: "No vale la pena", o piensan: "Estás tratando de quitarme el trabajo". En el primer caso, los administradores de red piensan que gastarán mucho dinero sin obtener mucho retorno de su inversión. No quieren pensar en comprar otra solución más, gastar tiempo en encontrar una nueva forma de hacer las cosas o escribir otro guión. En el otro extremo, algunos ingenieros de redes, generalmente los chicos de NOC de primer nivel, escuchan "eliminación de trabajos" cuando dices la palabra "automatización".
Pero la automatización is vale la pena y no te va a quitar el trabajo. Le da la vuelta a la ecuación: la automatización elimina los trabajos que no valen la pena. La automatización no puede, y no eliminará, el trabajo de las personas. Pero elimina todo el trabajo sin salida que nadie quiere hacer. Libera el tiempo de todos para asumir un trabajo más desafiante.
En las redes de hoy, las secuencias de comandos no son suficientes. Cualquiera que haya escrito una secuencia de comandos de Python o Java sabe que el mayor desafío de automatización de red con las secuencias de comandos no es escribirlas. Es mantenerlos. Escribió un script una vez, pero luego, a medida que cambia la red, se queda atascado haciendo una gran cantidad de depuración. Y compartir ese guión con otras personas no es tan fácil.
Incluso hoy en día todavía escuchas mucho sobre cómo los chicos de la red necesitan convertirse en programadores. Realmente no veo que sea un movimiento natural para nosotros pasar de ingeniero de redes a desarrollador, o una solución para la automatización de redes.
¿A qué nos referimos con “cuándo pulsar el botón”? La gente piensa que, con la automatización, deberíamos escribirla una vez, enviarla y todo se solucionará solo. Pero en el mundo real, no funciona así. Alguien, en algún lugar, tiene que activar esa parte de la automatización, ya sea para la resolución de problemas, la gestión de cambios, la seguridad, lo que sea. Si hay una interrupción en mitad de la noche, ¿quién va a poner en marcha la automatización que diagnostica el problema? ¿Y cuándo? Hoy en día, este es un gran desafío de automatización de redes que debemos resolver.
We están va a híbrido. Nos guste o no, vendrán más centros de datos ACI, NSX y otros SDN. Vienen más SD-WAN. La red tradicional con la que estamos familiarizados, que acabamos de entender, ya no es suficiente. Para la mayor parte de la automatización en una red tradicional, ¿"lo escribe una vez, lo usa una vez"? Eso es algo que enfrentamos todo el tiempo hoy. Podría decir: "Está bien, separaremos la automatización de la red tradicional de la nueva red". Pero, ¿qué pasa con el flujo de tráfico? Si tiene lentitud al pasar de su red tradicional a su SDN, ¿cómo lo maneja? Entonces, tenemos que descubrir cómo automatizar dentro de la red híbrida, lo mismo con una red de múltiples proveedores.
Ya tenemos muchas herramientas, o soluciones. Pero cada herramienta habla su propio idioma; son su propia "isla de datos". Tiene una herramienta de supervisión del rendimiento que no se comunica con la herramienta de gestión de eventos que no se comunica con el sistema de detección de intrusos, etc. Toda la información importante que necesita, colectivamente, está aislada entre sí en silos de datos.
Entonces, ¿cómo superamos estos desafíos? Hemos intentado actualizar el hardware, cambiar el software, reemplazar a las personas; esas no son la solución. Necesitamos una automatización que piense diferente. Necesitamos Automatización Adaptativa.
El concepto de Automatización Adaptativa no es nada nuevo. En el campo de la ingeniería mecánica, existe una solución de diseño asistido por computadora (CAD); la industria electrónica tiene EDA (automatización de diseño electrónico); en redes, hay algo similar: lo llamamos Automatización Adaptativa. La idea detrás de esto es que cuando tiene un montón de tareas que debe realizar en una red compleja y que necesita integrar diferentes islas de datos, necesita dos cosas para resolver el problema.
Uno es un mapa. En CAD o EDA, el diagrama (o mapa) es realmente un modelo de datos que abstrae cosas en un formato visual. Entonces necesitas un mapa para poder abstraer tu tarea. Un mapa le permite definir la alcance de tu tarea
La otra pieza del rompecabezas es un runbook – no un guión – que le permite organizar lo que necesita hacer. Él runbook le permite definir la pasos de tu tarea
Juntos, el mapa logra la idea de documentar su red, creando una vista de panel único de su red, y el runbook realiza la automatización "justo a tiempo" y la capacidad de "escribir una vez, ejecutar en todas partes".
Esta automatización adaptativa aborda la automatización de la red una tarea a la vez, un paso a la vez, para los 5 desafíos anteriores. Veamos un ejemplo de cómo se vería esto.
Supongamos que recibe una notificación en su consola de eventos, por ejemplo, un ticket en ServiceNow que indica que una aplicación es lenta. En el marco de Automatización adaptativa, lo primero que sucede es que la automatización "justo a tiempo" se activa a través de la API para crear un Dynamic Map de esa lentitud. Luego un “diagnóstico de nivel 0” runbook entra en acción automáticamente para recopilar datos de rendimiento, datos de comandos CLI o datos de su herramienta de gestión del rendimiento y adjuntar la información al ticket de ServiceNow. Todo esto sucede automáticamente en el instante en que se crea el evento cuando se detecta la lentitud, digamos en medio de la noche, sin necesidad de interacción humana. (Por eso se le conoce como “diagnóstico de nivel 0”). Ese es el paso 1.
Paso 2: Por la mañana, cuando llega al trabajo, está el ServiceNow que se creó en medio de la noche. Ahora ejecuta un rendimiento de lentitud diferente o solución de problemas de QoS runbooks. Estas RunbookLos s fueron creados por sus ingenieros de redes sénior en función de su experiencia, tanto su conocimiento del dominio como su experiencia en la materia. Si es necesario, el ingeniero de nivel 1 puede derivar el problema a los ingenieros de nivel 2 o 3. Cuando se escala el ticket, todo lo que hizo el ingeniero de nivel 1 se captura en el runbook para que el ingeniero de siguiente nivel no tenga que reinventar la rueda, volviendo a ejecutar los mismos diagnósticos básicos. Para profundizar en el problema, puede aprovechar un solo panel para ver la información de todas las demás herramientas (Splunk, archivos de registro, soluciones de monitoreo de rendimiento las 24 horas, los 7 días de la semana).
Una vez que haya identificado el problema, y esto es lo que ocupa aproximadamente el 80 % de nuestro tiempo de solución de problemas, puede solucionarlo. Arreglar las cosas es bastante simple: tal vez cambiar la configuración de QoS, tal vez redirigir el tráfico. Y tiene una herramienta de automatización que no solo puede impulsar los cambios, sino también verificar el impacto de esos cambios automáticamente. En realidad, esto es más importante que impulsar los cambios automáticamente.
Adaptive Automation luego le permite monitorear de manera proactiva este problema en el futuro, de modo que cuando surja nuevamente (y probablemente lo hará), lo capturará de inmediato sin esperar a que alguien tome una decisión sobre cómo abordarlo. Los pasos que su herramienta de ingeniería de nivel 2 se pueden codificar en un runbook que se puede activar para que se ejecute automáticamente en ejecución 24×7.