L'adoption de l'automatisation par NetOps entraînera un besoin d'opérations NetOps

L'automatisation est l'avenir. DevOps a depuis longtemps adopté l’idée d’automatiser tout ce qui se présente à lui, mais NetOps comble rapidement l’écart entre eux en utilisant largement l’automatisation et l’orchestration dans les processus de production.

Près de la moitié (46 %) des répondants à notre enquête sur l’état de la distribution des applications 2018 ont indiqué utiliser au moins « partiellement » l’automatisation en production. Cela inclut l'utilisation systématique de l'automatisation pour les changements de production majeurs (25 %), les changements de production mineurs (26 %) et même la réponse aux incidents (22 %). Plus de la moitié utilisent « parfois » l’automatisation dans les trois cas.

Cette automatisation est mise en œuvre de diverses manières. L’automatisation des réseaux comme celle de Cisco, VMware et OpenStack est populaire, tout comme les frameworks et les outils comme Puppet, Chef et les bons vieux scripts Python.

Dire que l’automatisation est une chose qui se produit réellement n’est pas un euphémisme. NetOps est arrivé. Ce n'est pas un exercice.

C’est passionnant, à première vue, mais quand on creuse un peu plus ce que cela signifie, on découvre qu’il y a des défis qui n’ont peut-être pas encore fait surface.

Par exemple, automatiser un changement sur le pare-feu ou le routeur est une chose. L'inclure dans un processus de déploiement global, eh bien, c'est une autre chose (et le terme approprié pour cela est orchestration, au cas où vous vous poseriez la question).

Une fois que vous commencez à enchaîner (intégrer) des systèmes et des scripts, vous avez construit ce qui équivaut à une « application ». Il existe de nombreux éléments mobiles qui doivent être déployés, gérés, entretenus, mis à niveau, corrigés et sous licence.

Ce n’est pas une tâche sisyphienne, mais c’est une tâche que NetOps ne prend probablement pas en considération.

C’est formidable que les développeurs puissent désormais saisir un ticket dans ServiceNow et cela lancera un flux de travail informatique qui provisionne, configure et facture automatiquement la ressource souhaitée. Mais que se passe-t-il lorsque ServiceNow s’étouffe ? Ou lorsque l’un des composants de cette chaîne fragile s’effondre soudainement. Ou lorsqu'une mise à niveau d'un des composants rompt l'intégration ?

Si vous fermez les yeux, vous entendrez le son des développeurs qui gloussent à cause d’une overdose de Schadenfreude à cette pensée.

L’une des conséquences imprévues de l’automatisation de l’informatique sera que le service informatique aura davantage de logiciels et de systèmes à maintenir. Certains d’entre eux seront critiques et nécessiteront plus de soins et de nourriture que d’autres.

Tout comme il existe des légions de développeurs de « maintenance » ou de « support » au sein des entreprises dont la tâche consiste simplement à maintenir les systèmes logiciels en fonctionnement, il sera nécessaire de créer un rôle similaire au sein de l’informatique pour gérer les opérations quotidiennes des opérations NetOps.

NetOpsOps. Oui, c’est un mot-valise terrible, mais c’est une manière précise de décrire ce qui sera nécessaire à mesure que l’automatisation consomme de plus en plus de tâches de déploiement NetOps.

Certaines de ces tâches seront de nature (intégration, systèmes logiciels, etc.) qui pourront être assumées par le personnel opérationnel existant. Mais certains sont spécifiques au réseau, et cela nécessite quelqu'un qui comprend à la fois les scripts et les systèmes ainsi que les composants réseau impliqués.

Vous ne pouvez pas dépanner, mettre à jour ou modifier du code/des scripts/des modèles si vous ne savez pas ce qu’ils font.

Si vous me demandez ce qui ne va pas avec ma motoneige, je vous dirai que je n’en ai aucune idée. Je sais comment ouvrir le capot et charger la batterie, mais ne me demandez pas de bricoler les pièces qui le font fonctionner. C’est comme demander à un stagiaire en développement compétent en JavaScript d’aller mettre à jour un cahier de travail COBOL. C’est une recette pour un désastre.

En fin de compte, NetOps aura besoin de personnes (les NetOps Ops) qui connaissent le réseau et les systèmes utilisés pour l’automatiser. Plus l’automatisation sera utilisée, plus il sera impératif d’avoir ces personnes en place pour prendre en charge le maintien de cette automatisation pendant que les ingénieurs travaillent sur la prochaine grande nouveauté.