DevOps pour NetOps est une question d'évolutivité

Et l’échelle mène à la vitesse. Et la vitesse mène au succès.

Supposons qu’un ingénieur puisse traiter une demande de changement en deux heures. Supposons qu’un autre ingénieur puisse traiter cette demande de changement en 1,5 heure. S’ils travaillent ensemble, combien de temps leur faudra-t-il pour traiter deux cents demandes de changement ?

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

Tout le monde se souvient probablement (avec une certaine peur et un certain dégoût) des fameux problèmes de mots « train » ou « peinture » dans les cours de mathématiques, qui étaient conçus pour nous enseigner les relations fractionnaires. En réalité, c’était là leur intention, même si beaucoup d’entre nous en ont retiré un dégoût pour la peinture et les voyages en train. Et beaucoup de mèmes. N’oublions pas les mèmes.

Le problème est que ce type de mesures formelles devient une exigence dans le centre de données, en particulier dans le réseau. C’est parce que les budgets sont limités (je sais, n’est-ce pas ? (C'est fou, non ?) et vous ne pouvez embaucher que X ingénieurs pour faire Y travail. Dans un monde d'applications où les cycles de publication rapides et fréquents sont la règle du jeu, le nombre de « X » que vous pouvez embaucher pour réaliser des publications dans les délais est limité.

C’est pourquoi l’échelle est un moteur principal du « devops » dans le réseau, également appelé « netops ». En appliquant les principes opérationnels de DevOps au réseau, on pense que les netops peuvent atteindre l’échelle opérationnelle nécessaire pour permettre aux ingénieurs « X » de réaliser le travail « Y » dans les délais et dans les limites du budget, même lorsque la relation entre X et Y est exponentielle (traduction profane : vraiment déséquilibrée).

Le problème des demandes de changement est réel ; présenté par un ingénieur réseau qui a dû faire face à un nombre croissant de demandes de changement (définies comme la création d'un point de terminaison d'équilibrage de charge pour une application, son ajout au DNS et la création d'une règle de pare-feu pour autoriser l'accès) qui menaçaient finalement de submerger le personnel disponible tout en augmentant simultanément le temps de traitement.

La réponse a bien sûr été trouvée dans l’automatisation, ainsi que dans l’application des principes de DevOps et dans l’offre d’une interface en libre-service permettant à d’autres ingénieurs de faire des demandes qui étaient ensuite documentées dans le système de billetterie et exécutées via diverses API de réseau et de services d’application.

Non seulement cette adoption de l'automatisation (et de l'orchestration, car l'ensemble du processus est également automatisé) permet aux ingénieurs existants d'évoluer opérationnellement, mais elle a également rendu le processus plus rapide . Il ne faut plus jusqu’à deux heures pour traiter une demande de changement ; désormais, cela ne prend que cinq minutes.

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

Il s’agit d’une amélioration significative de la vitesse résultant de la capacité d’ évolution grâce à l’automatisation et à l’orchestration. Et même s'il ne s'agit pas d'un projet ambitieux à l'échelle d'un « centre de données », il répond à un problème spécifique que les ingénieurs et les propriétaires d'applications rencontrent fréquemment. Dans ce cas, apparemment jusqu'à 200 fois par semaine.

C’est exactement de cette manière que les réseaux devraient aborder l’automatisation et l’orchestration au sein du réseau de production. Trouver les tâches répétables et considérées par le comité d'examen des modifications comme triviales (c'est-à-dire qu'elles sont manifestement non perturbatrices et que la plupart des ingénieurs peuvent effectuer pendant leur sommeil) peut donner lieu à des opportunités d'évolution significatives qui aboutissent à la vitesse que les propriétaires d'entreprise et d'applications nous indiquent que nous devons atteindre dans le réseau.

En extrayant les pépites qui peuvent être automatisées avec le moins de risques de perturbation possible, les ingénieurs sont libres de se concentrer sur les tâches qui ne sont pas considérées comme mûres pour l’automatisation. Cette concentration se traduit également par des délais plus rapides pour d’autres implémentations de services, car elles sont libérées de la nécessité de consacrer une quantité excessive de temps à des tâches plus simples et répétables.

Je ne saurais trop insister sur l’importance 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 des délais de livraison plus rapides, avec moins de risques de perturbations dues à des erreurs. Il s’agit du mariage des modèles d’exploitation dits « mode 1 » et « mode 2 », où la fiabilité et la stabilité règnent mais où l’agilité est toujours souhaitable. En activant une approche CPR pour l’automatisation et l’orchestration du réseau, les organisations peuvent améliorer l’agilité avec beaucoup moins de risques de perturber la fiabilité d’un réseau chargé de fournir de très nombreuses autres applications (environ 200 en moyenne).

Les réseaux de centres de données sont composés de technologies héritées et émergentes, souvent liées par des techniques de type MacGyver qui nécessitent du chewing-gum et une ligne de pêche. Ces réseaux doivent supporter simultanément des applications en production depuis près de cinquante ans (les mainframes existent toujours) et des applications émergentes construites sur des technologies à peine sorties des couches (comme les conteneurs). Il doit fournir toutes les applications, et ce de manière fiable et sécurisée. Ces normes ne peuvent être ignorées au profit de la vitesse et de la fréquence requises par des applications plus récentes et plus brillantes.

Mais les réseaux peuvent atteindre un équilibre qui permet aux deux de coexister, s'ils peuvent identifier et ensuite automatiser à fond les tâches et les options de prestation de services qui ne sont pas perturbatrices et qui sont considérées comme des tâches à cocher par le contrôle des modifications et d'autres approbateurs.

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 concernés reçoivent des rouleaux de peinture automatiques au lieu de pinceaux manuels.

Ne vous inquiétez pas trop de changer le réseau, changez simplement l’équation à la place.