NetBrain Le fondateur et PDG Lingping Gao a présenté sa session de réflexion intitulée "Les défis cachés de l'automatisation du réseau à l'ère du SDN et au-delà", lors du Cisco Live 2018 à Orlando. Ce billet résume sa présentation.
Quels sont nos plus grands défis d'automatisation du réseau pour l'automatisation du réseau ? Je parle de aujourd'hui des réseaux du monde réel, et non des défis à venir. Je parle de nos flux de travail et tâches opérationnels quotidiens actuels : dépannage, gestion des changements, sécurité et documentation dans les réseaux SDN, multicloud et hybrides.
Deux facteurs fondamentaux rendent l’automatisation des réseaux difficile. Le premier est le réseau lui-même. Les réseaux d’aujourd’hui sont très complexes. Nous venons de sortir de la virtualisation, puis sont arrivés les réseaux définis par logiciel comme Cisco ACI et maintenant nous avons SD-WAN. Le deuxième facteur est nos outils et nos données. Nous utilisons de nombreux outils : des systèmes de gestion des tickets comme ServiceNow, des solutions de surveillance 24h/7 et XNUMXj/XNUMX, Splunk, SEIM et IDS, et même APM. Chaque outil fait son propre travail mais fonctionne sur une « île ». Nous nous retrouvons avec de nombreux silos de données. Tant d’outils avec une abondance de données signifient que l’automatisation du dépannage ou de la gestion des changements n’est pas si simple.
Cela dit, il y a 5 défis d'automatisation de réseau "cachés" pour l'automatisation de réseau pratique au quotidien que j'ai appris au fil des ans.
Lorsque les gens entendent « automatisation du réseau », ils ont souvent l'une des deux réactions suivantes. Soit ils disent : « Ça n'en vaut pas la peine », soit ils pensent : « Vous essayez de me retirer mon travail. Dans le premier cas, les gestionnaires de réseau pensent qu'ils vont dépenser beaucoup d'argent sans obtenir beaucoup de retour sur leur investissement. Ils ne veulent pas penser à acheter une énième solution, passer du temps à trouver une nouvelle façon de faire les choses ou écrire un autre script. À l'autre extrémité, certains ingénieurs réseau - généralement les gars du CNO de premier niveau - entendent «élimination d'emplois» lorsque vous prononcez le mot «automatisation».
Mais l'automatisation is vaut la peine et ne va pas vous enlever votre travail. Cela renverse l'équation : l'automatisation supprime les emplois qui n'en valent pas la peine. L'automatisation ne peut pas – et ne supprimera pas – le travail des gens. Mais cela élimine tout le travail sans issue que personne ne veut faire. Cela libère le temps de chacun pour entreprendre des tâches plus difficiles.
Dans les réseaux d'aujourd'hui, les scripts ne suffisent plus. Quiconque a écrit un script Python ou Java sait que le plus grand défi d'automatisation du réseau avec des scripts n'est pas de les écrire. C'est les maintenir. Vous avez écrit un script une fois, mais à mesure que le réseau change, vous êtes obligé de faire beaucoup de débogage. Et partager ce script avec d'autres personnes n'est pas si facile.
Même aujourd'hui, vous entendez encore beaucoup parler de la nécessité pour les gars du réseau de devenir programmeurs. Je ne vois pas vraiment que ce soit une évolution naturelle pour nous de passer d'ingénieur réseau à développeur - ou une solution pour l'automatisation du réseau.
Que veut-on dire par « quand appuyer sur le bouton » ? Les gens pensent qu’avec l’automatisation, il suffit de l’écrire une fois, de l’appliquer et tout se règlera tout seul. Mais dans le monde réel, cela ne fonctionne pas de cette façon. Quelqu’un, quelque part, doit déclencher cet élément d’automatisation – pour le dépannage, la gestion des changements, la sécurité, etc. En cas de panne au milieu de la nuit, qui va lancer l’automatisation qui diagnostique le problème ? Et quand ? Aujourd’hui, c’est un grand défi d’automatisation du réseau que nous devons résoudre.
We are passer à l'hybride. Qu'on le veuille ou non, il y a plus d'ACI, de NSX et d'autres centres de données SDN à venir. Il y a plus de SD-WAN à venir. Le réseau traditionnel que nous connaissons, dont nous venons tout juste de nous imprégner, ne suffit plus. Pour la plupart de l'automatisation dans un réseau traditionnel, « l'écrivez-vous une fois, l'utilisez-vous une fois » ? C'est quelque chose auquel nous sommes constamment confrontés aujourd'hui. Vous pourriez dire : "D'accord, nous allons séparer l'automatisation du réseau traditionnel du nouveau réseau". Mais qu'en est-il de la fluidité du trafic ? Si vous rencontrez des lenteurs entre votre réseau traditionnel et votre SDN, comment gérez-vous cela ? Nous devons donc trouver comment automatiser au sein du réseau hybride - même chose avec un réseau multifournisseur.
Nous avons déjà beaucoup d'outils – ou de solutions. Mais chaque outil parle son propre langage ; ils sont leur propre « île de données ». Vous avez un outil de surveillance des performances qui ne communique pas avec l'outil de gestion des événements qui ne communique pas avec le système de détection d'intrusion, etc. Toutes les informations importantes dont vous avez besoin, collectivement, sont isolées les unes des autres dans des silos de données.
Alors, comment pouvons-nous surmonter ces défis? Nous avons essayé de mettre à niveau le matériel, de changer le logiciel, de remplacer les gens – ce n'est pas la solution. Nous avons besoin d'une automatisation qui pense différemment. Nous avons besoin d'automatisation adaptative.
Le concept d'automatisation adaptative n'est pas nouveau. Dans le domaine du génie mécanique, il existe une solution de conception assistée par ordinateur (CAO) ; l'industrie électronique a EDA (automatisation de la conception électronique); en réseau, il y a quelque chose de similaire : nous l'appelons Adaptive Automation. L'idée sous-jacente est que lorsque vous avez un tas de tâches que vous devez effectuer dans un réseau complexe et qui doivent intégrer différents îlots de données, vous avez besoin de deux choses pour résoudre le problème.
L'un est une carte. En CAO ou EDA, le diagramme (ou la carte) est en réalité un modèle de données qui résume les choses dans un format visuel. Vous avez donc besoin d'une carte pour pouvoir résumer votre tâche. Une carte permet de définir portée de votre tâche.
L'autre pièce du puzzle est un runbook – pas un script – qui vous permet d'organiser ce que vous devez faire. Le runbook permet de définir la mesures de votre tâche.
Ensemble, la carte concrétise l'idée de documenter votre réseau, de créer une vue unique de votre réseau et de runbook réalise l'automatisation "juste à temps" et la capacité "écrire une fois, exécuter partout".
Cette automatisation adaptative aborde l'automatisation du réseau une tâche à la fois, une étape à la fois, pour les 5 défis ci-dessus. Regardons un exemple de ce à quoi cela ressemblerait.
Supposons que vous receviez une notification dans votre console d'événements - un ticket dans ServiceNow indiquant qu'une application est lente, par exemple. Dans le framework Adaptive Automation, la première chose qui se passe est que l'automatisation "juste à temps" est déclenchée via l'API pour créer un Dynamic Map de cette lenteur. Puis un "diagnostic de niveau 0" runbook entre automatiquement en action pour collecter des données de performances, des données de commande CLI ou des données de votre outil de gestion des performances et joindre les informations au ticket ServiceNow. Tout cela se produit automatiquement dès l'instant où l'événement est créé lorsque la lenteur est détectée - au milieu de la nuit, par exemple - sans aucune interaction humaine requise. (C'est pourquoi on l'appelle "diagnostic de niveau 0".) C'est l'étape 1.
Étape 2 : Le matin en arrivant au travail, il y a le ServiceNow qui a été créé au milieu de la nuit. Maintenant, vous exécutez différentes performances de lenteur ou de dépannage QoS runbooks. Ces Runbooks ont été créés par vos ingénieurs réseau seniors sur la base de leur savoir-faire, à la fois leur connaissance du domaine et leur expertise en la matière. Si nécessaire, l'ingénieur de niveau 1 peut ensuite faire remonter le problème à un ingénieur de niveau 2 ou 3. Lorsque le ticket est remonté, tout ce que l'ingénieur de niveau 1 a fait est enregistré dans le runbook Ainsi, l'ingénieur de niveau supérieur n'a pas à réinventer la roue, en réexécutant les mêmes diagnostics de base. Pour approfondir le problème, vous pouvez utiliser une seule fenêtre pour consulter les informations de tous les autres outils (Splunk, fichiers journaux, solutions de surveillance des performances 24 × 7).
Une fois que vous avez identifié le problème — et c'est ce qui prend environ 80 % de notre temps de dépannage — vous pouvez résoudre le problème. Réparer les choses est assez simple : peut-être modifier la configuration QoS, peut-être rediriger le trafic. Et vous disposez d'un outil d'automatisation qui peut non seulement appliquer les modifications, mais également vérifier automatiquement l'impact de ces modifications. C'est en fait plus important que de pousser les changements automatiquement.
Adaptive Automation vous permet ensuite de surveiller de manière proactive ce problème à l'avenir. Ainsi, lorsqu'il se reproduira (et il le fera probablement), vous le capturerez immédiatement sans attendre que quelqu'un prenne une décision sur la manière de le résoudre. Les étapes de votre outil d'ingénieur de niveau 2 peuvent être codifiées dans un runbook qui peut être déclenché pour s'exécuter automatiquement en exécution 24 × 7.