Le NetOps a besoin de défenseurs, pas d’adversaires

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Vous vous apprêtez à savourer un repas que vous attendiez avec impatience toute la journée lorsque vous vous rendez compte qu’il n’est pas assez cuit. Agacé, vous vous adressez sèchement à la personne qui vous sert et réduisez peut-être même son pourboire. Elle garde le sourire, même si ce n’est pas sa faute. Après tout, ce n’est pas elle qui a préparé votre repas. Mais c’est elle qui fait le lien entre vous et la cuisine et, en fin de compte, c’est elle qui paie le prix des erreurs commises en coulisses.

Qu’il s’agisse du serveur dans un restaurant ou d’un conseiller du service client de <insérer le service ici>, c’est généralement la personne avec laquelle vous êtes en contact qui finit par faire les frais de votre anxiété, de votre frustration ou de votre colère lorsque quelque chose ne va pas.

C’est également vrai dans le centre de données.

Alors que l’informatique opère sa transformation numérique afin d’optimiser davantage ses activités et de gagner en rapidité, ce sont les équipes NetOps qui sont le plus susceptibles d’interagir avec les « clients » internes et, par conséquent, de subir le mécontentement des utilisateurs lorsque les processus n’avancent pas aussi vite que souhaité.

Il est important de reconnaître que ce ne sont pas toujours les « NetOps » qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.

Faites-vous vraiment du DevOps ou vous contentez-vous d’automatiser ?

CAMS est le moyen le plus couramment utilisé pour diffuser les principes fondamentaux du DevOps. CAMS signifie : culture, automatisation, mesure et partage.

Parmi ces quatre principes, l’automatisation est celui qui suscite généralement le plus d’enthousiasme. Les trois autres ont tendance à être délaissés, voire totalement ignorés, dans la quête d’une prestation de services informatiques plus rapide.

Il convient notamment de souligner que les trois concepts couramment négligés sont étroitement liés. Il est difficile de faire évoluer la culture lorsque les équipes restent cloisonnées par fonction et se concentrent sur des indicateurs qui n’ont aucune importance pour les autres équipes. Nous orientons nos efforts en fonction de ce sur quoi nous sommes évalués. Si nous sommes évalués sur la disponibilité du réseau, c’est sur cela que nous allons nous concentrer, même si nos homologues des opérations cherchent à améliorer la disponibilité de l’application .

À ce propos, vous vous souvenez peut-être de l’étude sur l’état de l’automatisation des réseaux dans laquelle nous nous sommes associés à Red Hat pour explorer le monde nébuleux du DevOps, du NetOps et de l’automatisation. Nous y avons constaté de grandes disparités entre les indicateurs (mesures) recherchés par les équipes NetOps et ceux privilégiés par les équipes de développement et d’exploitation.

Près des trois quarts (73 %) des équipes NetOps ont cité la « disponibilité du réseau » comme principal indicateur. De l’autre côté, 59 % des équipes de développement et d’exploitation nous ont indiqué que la « disponibilité des applications » constituait leur principal indicateur. À l’inverse, la fréquence des déploiements sert d’indicateur à près de deux fois plus d’équipes de développement et d’exploitation (30 %) que d’équipes NetOps (16 %) et de sécurité (17 %).

Pourquoi cette disparité est-elle importante ? Si mon objectif principal est de garantir la disponibilité du réseau, je vais consacrer mon temps à me concentrer sur celui-ci. L’instrumentation et la surveillance — cette dernière étant essentielle à la composante de partage de DevOps — porteront d’abord sur le réseau, puis éventuellement sur l’application. S’il reste du temps. Personne n’a de temps à consacrer à la sécurité et, de toute façon, personne n’est évalué sur ce critère. En fait, le principal indicateur cité en matière de sécurité était, <roulement de tambour>, la « disponibilité du réseau », 59 % des professionnels de la sécurité étant évalués selon cet indicateur.

Les personnes, qui restent au cœur de l’informatique et constituent les équipes chargées de mettre en œuvre l’automatisation et l’orchestration, ne poursuivent pas nécessairement les mêmes objectifs. Ce décalage s’explique notamment par le cloisonnement persistant des domaines opérationnels. Les équipes NetOps et de sécurité sont plus susceptibles de fonctionner comme des équipes « monofonctionnelles ». Les NetOps se préoccupent du réseau. La sécurité ? De la sécurité. Les opérations ? De l’exploitation des systèmes.

Mais le problème est encore plus profond que cela. Car au sein des GRANDS silos se trouvent des silos encore plus petits. À l’image des matriochkas — ces poupées russes qui s’emboîtent —, NetOps regroupe de nombreuses équipes différentes par lesquelles cette demande de « nouveau site », en apparence si simple, doit transiter avant d’aboutir. Pour qu’une telle demande puisse être satisfaite, de nombreux services d’infrastructure et d’application doivent être provisionnés et intégrés. Un nouveau site nécessite non seulement les ressources de calcul et de réseau pour l’héberger, mais aussi une multitude d’autres éléments : un serveur web et son stockage, le contrôle des accès, les certificats et la gestion des clés, l’équilibrage de charge, les règles de pare-feu… La liste des silos internes à l’IT que cette demande « simple » doit traverser est interminable.

Et si un seul de ces silos au sein du silo NetOps n’est pas automatisé, le processus s’arrête brutalement. Le traitement d’une telle demande peut alors prendre plusieurs jours, voire plusieurs semaines supplémentaires.

Vu de l’extérieur — par le demandeur —, on a l’impression que l’équipe NetOps ne fait tout simplement pas son travail. C’est l’« interlocuteur », l’« agent de liaison », le « partenaire informatique » qui essuie la colère de ceux qui exigent de savoir pourquoi il faut autant de temps pour satisfaire une demande apparemment simple. Nous rejetons la faute sur l’équipe NetOps comme les néophytes en informatique accusent leur fournisseur d’accès local en cas de perturbations d’Internet, alors que le problème vient en réalité d’un routeur situé au cœur du réseau fédérateur et géré par un autre fournisseur.

Soyez un allié, pas un adversaire

Pour de nombreuses organisations, l’évolution vers une informatique plus collaborative et transparente se profile encore à peine à l’horizon. Si certaines équipes informatiques en comprennent la nécessité et adoptent les changements qui s’imposent, ce n’est pas le cas de toutes. Au cours des cinq années pendant lesquelles nous avons mené des recherches sur les services applicatifs, nous n’avons pas vu le « DevOps » atteindre le niveau d’importance stratégique requis pour véritablement amorcer les changements culturels et organisationnels nécessaires afin d’atteindre la rapidité que l’entreprise souhaite — et dont elle a besoin. Au lieu de cela, les organisations ont adopté l’automatisation, tout en oubliant les trois autres composantes essentielles du DevOps.

Cette incapacité à reconnaître que l’adoption du mouvement DevOps au sein de l’informatique ne se limite pas à l’automatisation est préoccupante. Elle revient à ignorer que, pour gagner en rapidité, il faut automatiser le pipeline, lequel traverse la quasi-totalité des domaines opérationnels et des silos informatiques. Toutes les personnes concernées doivent donc s’engager dans cette voie, faute de quoi vous ne parviendrez pas à atteindre la rapidité et la fréquence de déploiement recherchées. Il ne suffit pas d’adopter l’automatisation pour réussir. Lorsque celle-ci doit franchir les frontières entre des équipes cloisonnées, l’échec est inévitable sans un changement culturel profond.

Le changement nécessaire doit venir d’en haut, en particulier lorsqu’il s’agit de transformation organisationnelle. Nous ne pouvons pas vraiment nous réorganiser nous-mêmes, n’est-ce pas ? Nous ne pouvons pas redéfinir l’ordre de priorité de nos objectifs et utiliser un ensemble d’indicateurs totalement différent, n’est-ce pas ?

Nous ne le pouvons pas, et à moins d’informer et de convaincre ceux qui peuvent apporter les changements nécessaires, nous resterons prisonniers de processus manuels au sein d’un pipeline par ailleurs automatisé.

Cessons donc de faire des NetOps un bouc émissaire et reconnaissons qu’elles peuvent, elles aussi, être frustrées. Rappelons plutôt aux décideurs qu’il est nécessaire de réévaluer les structures organisationnelles et de redéfinir les priorités en matière d’indicateurs afin de mieux les aligner sur les objectifs de l’entreprise et sur le reste du pipeline continu.

Crier sur les équipes NetOps en première ligne peut sembler satisfaisant, mais cela ne change en rien la situation à l’origine de cette colère. Et sans changement, le pipeline ne gagnera pas en rapidité.

Défendez les équipes NetOps au lieu de vous opposer à elles. Elles ont besoin de tout le soutien possible.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie