Le DevOps pour les NetOps est une question de passage à l’échelle

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

Et le passage à l’échelle mène à la rapidité. Et la rapidité mène au succès.

Supposons qu’un ingénieur puisse traiter une demande de modification en deux heures et qu’un autre puisse traiter cette même demande en une heure et demie. S’ils travaillent ensemble, combien de temps leur faudra-t-il pour traiter deux cents demandes de modification ?

Oui, la réponse est évidemment la bière.

Tout le monde se souvient probablement (non sans une bonne dose de peur et de dégoût) des tristement célèbres problèmes de « trains » ou de « peinture » rencontrés en cours de mathématiques, qui étaient censés nous apprendre les rapports entre fractions. C’était vraiment leur objectif, même si beaucoup d’entre nous en ont surtout retiré une aversion pour la peinture et les voyages en train. Sans oublier une foule de mèmes. Ne les oublions surtout pas.

Le fait est que ce type de mesures fondées sur des formules devient indispensable dans le centre de données, en particulier au niveau du réseau. En effet, les budgets sont limités (eh oui, qui l’eût cru ?) et vous ne pouvez recruter que X ingénieurs pour effectuer une quantité de travail Y. Dans un monde applicatif où les cycles de publication rapides et fréquents sont la règle, le nombre d’ingénieurs « X » que vous pouvez recruter pour assurer des publications dans les délais est limité.

C’est pourquoi l’évolutivité est l’un des principaux moteurs du « DevOps » appliqué au réseau, aussi appelé « NetOps ». En appliquant au réseau les principes opérationnels du DevOps, on estime que le NetOps peut atteindre l’échelle opérationnelle nécessaire pour permettre à « X » ingénieurs d’effectuer « Y » tâches dans les délais et le respect des contraintes budgétaires, même lorsque la relation entre X et Y est exponentielle (en termes simples : vraiment disproportionnée).

Le problème des demandes de modification est bien réel. Il a été présenté par un ingénieur réseau confronté à un nombre croissant de demandes de modification (consistant à créer un point de terminaison d’équilibreur de charge pour une application, à l’ajouter au DNS et à créer une règle de pare-feu pour en autoriser l’accès), qui risquaient à terme de submerger le personnel disponible tout en allongeant les délais de traitement.

La solution résidait bien sûr dans l’automatisation, ainsi que dans l’application des principes DevOps et la mise à disposition d’une interface en libre-service permettant aux autres ingénieurs de soumettre des demandes, qui étaient ensuite consignées dans le système de gestion des tickets et exécutées par l’intermédiaire de diverses API de services réseau et applicatifs.

Non seulement l’adoption de l’automatisation (et de l’orchestration, puisque l’ensemble du processus est lui aussi automatisé) permet aux ingénieurs en poste de faire évoluer les opérations, mais elle a également rendu le processus plus rapide. Le traitement d’une demande de modification ne prend désormais plus jusqu’à deux heures, mais seulement cinq minutes.

Oui, vous avez bien lu. Cinq minutes au lieu de deux heures maximum.

Il s’agit d’une amélioration considérable de la rapidité rendue possible par la capacité à passer à l’échelle grâce à l’automatisation et à l’orchestration. Et même s’il ne s’agit pas d’un projet ambitieux à l’échelle de l’ensemble du centre de données, il répond à un problème précis auquel les ingénieurs comme les responsables d’applications étaient fréquemment confrontés. Dans ce cas, apparemment jusqu’à 200 fois par semaine.

C’est exactement ainsi que les équipes d’exploitation réseau doivent aborder l’automatisation et l’orchestration au sein du réseau de production. Repérer les tâches répétitives que le comité de validation des changements considère comme triviales (c’est-à-dire dont il est démontré qu’elles n’entraînent aucune interruption et que la plupart des ingénieurs pourraient effectuer les yeux fermés) peut offrir d’importantes possibilités de mise à l’échelle et permettre ainsi d’atteindre la rapidité que les responsables métier comme les responsables d’applications attendent du réseau.

Identifier les tâches qui peuvent être automatisées avec un risque de perturbation aussi faible que possible permet aux ingénieurs de se concentrer sur celles qui ne sont pas encore jugées adaptées à l’automatisation. Cette concentration accélère également la mise en œuvre d’autres services, puisqu’ils n’ont plus à consacrer une part démesurée de leur temps à des tâches plus simples et répétitives.

Je ne saurais trop insister sur l’importance cruciale d’adopter une approche CPR pour l’automatisation du réseau : une automatisation cohérente, prévisible et reproductible permettra une mise à l’échelle plus efficace et une livraison plus rapide, tout en réduisant le risque de perturbations dues à des erreurs. Il s’agit de conjuguer les modèles opérationnels dits « mode 1 » et « mode 2 », où la fiabilité et la stabilité priment, sans pour autant renoncer à l’agilité. En appliquant une approche CPR à l’automatisation et à l’orchestration du réseau, les organisations peuvent gagner en agilité tout en réduisant considérablement le risque de compromettre la fiabilité d’un réseau chargé d’assurer le fonctionnement de très nombreuses autres applications — environ 200 en moyenne.

Les réseaux de centres de données sont constitués de technologies anciennes et émergentes, souvent assemblées à l’aide de techniques dignes de MacGyver, avec du chewing-gum et du fil de pêche. Ces réseaux doivent prendre en charge simultanément des applications en production depuis près de cinquante ans (les mainframes existent toujours) et des applications émergentes reposant sur des technologies qui sortent à peine de l’enfance (comme les conteneurs). Ils doivent fournir toutes les applications, de manière fiable et sécurisée. Ces exigences ne peuvent être sacrifiées au profit de la rapidité et de la fréquence requises par des applications plus récentes et plus séduisantes.

Mais les équipes d’exploitation réseau peuvent trouver un équilibre permettant aux deux de coexister, à condition d’identifier puis d’automatiser au maximum les tâches et les options de fourniture de services qui ne provoquent aucune interruption et sont considérées comme de simples formalités par le contrôle des changements et les autres responsables de l’approbation.

Après tout, notre équation préférée pour déterminer le temps nécessaire pour peindre une maison change radicalement lorsque les peintres disposent de rouleaux à peinture automatiques plutôt que de pinceaux manuels.

Ne vous préoccupez pas tant de modifier le réseau ; modifiez plutôt l’équation.

À 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