NetDevOps : là où DevOps et réseautage se rencontrent
NetDevOps est l'application de DevOps au développement et à la gestion de réseaux. ' DevOps » fait référence à une philosophie qui traite le développement de logiciels et les opérations système comme un continuum.
En réalité, le concept est une réaction à ITIL , qui a formalisé la gestion des services informatiques (ITSM). Alors que l'ITSM divise les différentes fonctions du service informatique en équipes distinctes, DevOps fusionne ces fonctions en un seul département.
L'ITSM est formulé par ITIL mais DevOps n'a pas de définition standard. Les partisans de la discipline font référence à « briser les silos .» Cela signifie que la division formelle des fonctions informatiques ne fait que créer davantage d'obstacles à l'efficacité et que la suppression de ces structures rend le service informatique plus réactif.
La stratégie ITSM formalise la fourniture de services mais elle crée également beaucoup de paperasse car chaque responsabilité doit être une définition formelle de ses responsabilités afin que son engagement dans chaque tâche ait des limites et un objectif mesurable. Chaque tâche doit être facturée afin que les budgets puissent être correctement alloués et suivis. Il s’agit d’une grande avancée pour les comptables et la haute direction, mais cela finit par être un cauchemar pour le personnel informatique. Cela crée simplement beaucoup de tâches administratives qui détourne les efforts loin de l'objectif principal du département, qui est de fournir des services informatiques de manière efficace et rapide.
Pensée Lean
Les adeptes de l’ITSM verront DevOps comme un pas en arrière. Cela semble chaotique. Cela semble être une manière pour les responsables informatiques qui n'aiment pas être surveillés de mettre une patine théorique sur leur obstination. Cependant, il existe un argument solide qui sous-tend le DevOps. Cela réside dans « pensée maigre .» L'école de la pensée Lean découle de fabrication au plus juste , qui a été lancé au Japon et a donné aux Japonais une avance dans la production de biens.
Le développeur emblématique du Lean Manufacturing était Toyota . D’autres constructeurs japonais ont suivi l’exemple de Toyota, puis, constatant que leurs activités étaient menacées, les constructeurs du reste du monde développé ont emboîté le pas.
Bien que certaines des techniques utilisées par Toyota soient très spécifiques à la fabrication, de nombreux concepts peuvent être appliqués à n'importe quel domaine de travail. Les idées de Lean Manufacturing de systèmes de fabrication flexibles et cercles de qualité peut facilement être traduit en opérations informatiques. Ce sont les théories fondamentales qui constituent la base de la « suppression des silos ».
Inefficacités de l'ITSM
Le problème de la division des fonctions informatiques en équipes distinctes est que chaque équipe nécessite une structure de gestion. Afin de mener une tâche à terme, de nombreux managers doivent négocier entre eux des contrats et des budgets. Ainsi, les managers s’impliquent beaucoup les uns avec les autres et fournissent les preuves dont ils ont besoin pour négocier les budgets et prouver leurs erreurs. Le travail réel devient étouffé par l'administration .
Pendant que les managers se disputent sur les contrats et les confirmations d'achèvement, les travailleurs quotidiens sont frustrés de ne pas être écoutés. Leur travail est rendu plus difficile par une paperasse inutile. Ceux qui ont les mains sur le volant savent ce qui fonctionne. Se faire dire d'en haut quel équipement ils doivent utiliser et quelles pratiques de travail ils doivent mettre en œuvre aboutit à les travailleurs se dissocient des objectifs de l'entreprise et du but de leur travail. Ils finissent par « simplement faire leur travail » et ne contribuent pas à l’efficacité.
Le cercle de qualité Le concept de production au plus juste donne aux travailleurs la responsabilité de décider comment les choses vont être faites. En informatique, une prestation de services réussie repose sur trois facteurs : matériel , logiciel , et Pratiques de travail . Le personnel des opérations est très doué pour trouver des solutions de contournement. Les pénuries d’infrastructures peuvent être compensées par des logiciels ou des modifications des procédures.
Les gestionnaires de réseau peuvent instantanément penser à de nombreuses façons de résoudre les goulots d'étranglement dans le trafic réseau sans avoir à acheter de nouveaux équipements. Par exemple, le déplacement des tâches d'administration et des tâches par lots vers des périodes en dehors des heures d'ouverture supprime le trafic des heures de pointe. Une autre stratégie qui peut aider le réseau à fonctionner plus efficacement est « façonnage du trafic », qui donne la priorité au trafic interactif, tel que la VoIP et la vidéo, par rapport aux demandes moins immédiates provenant d'applications telles que la messagerie électronique.
La planification des tâches est un solution procédurale et la gestion du trafic nécessite des outils de surveillance et des systèmes de gestion des commutateurs, tout comme un solution logicielle . Ces deux méthodes compensent les exigences matérielles et offrent des niveaux de service acceptables pour moins d'argent. Les managers formés au contrôle budgétaire et à la négociation de contrats ne sont pas intéressés par ces astuces pour réduire les coûts. Ils se soucient davantage de leur propre capacité à accumuler du pouvoir et à gagner des fonds pour leur équipe.
Efficacité DevOps
Dans l'ITSM, le processus de gestion prend le relais sur l'objectif réel du département, et les personnes qui savent organiser efficacement les tâches n'ont aucun pouvoir. Finalement, l’objectif du service informatique est détourné par les nombreux managers qui passent tout leur temps à se parler et à séparer leurs collaborateurs. On arrive au point où coopération entre les équipes devient une infraction passible de renvoi.
DevOps commence par se débarrasser de tous ces gestionnaires.
Dans DevOps, l'équipe de développement logiciel et l'équipe d'exploitation des systèmes sont fusionnées. Cela ne signifie pas que les mêmes personnes effectuent les deux tâches : les programmeurs sont formés pour écrire des logiciels et les administrateurs système savent comment modifier différents paramètres pour gagner en efficacité. Chaque ensemble de compétences est adapté à différents emplois. Cependant, sous DevOps, ces deux types de travailleurs sont autorisés à se parler.
Le personnel opérationnel sait ce dont le système a besoin pour mieux fonctionner et sait comment informer les programmeurs des nouvelles exigences. Les développeurs de logiciels peuvent penser qu’un nouveau programme est prêt, mais il peut y avoir des conditions de fonctionnement qu’ils n’avaient pas prévues lors de l’écriture du nouveau système. Ce n'est que lorsque le programme est en cours d'exécution dans le monde réel que toutes les éventualités sont rencontrées. Cela pourrait nécessiter des ajustements. Cela ne veut pas dire que le programmeur a commis une erreur, il n’est donc pas nécessaire de le blâmer ou de lui donner des coups de coude pour obtenir une promotion.
DevOps recrute tout le personnel informatique travailler ensemble sans le compartimentage de l’ITSM.
NetDevOps
NetDevOps est un concept beaucoup plus facile à imaginer que DevOps. DevOps est particulièrement fort dans le développement de logiciels . Dans le domaine des réseaux, la création de logiciels sur mesure est très rare. Il est plus courant d’introduire des outils de surveillance et de gestion du système.
L'ITSM ne sépare pas seulement les équipes de développement logiciel et d'exploitation, elle sépare également les fonctions de gestion du système et de support utilisateur. Lorsque le besoin de nouveaux matériels et logiciels est identifié par les gestionnaires de systèmes ou les techniciens du service d'assistance, l'ITSM dicte que quelqu'un d'autre devrait être chargé d’évaluer les nouveaux systèmes. Pour les partisans du DevOps, cette division du travail n’a pas de sens. Dans NetDevOps, c'est encore plus illogique.
Si un gestionnaire de réseau sait ce qui doit être acheté pour améliorer le fonctionnement du réseau, cette personne est l'employé le plus compétent pour identifier le service à acheter. Dans le système ITSM, le gestionnaire de réseau doit transmettre toutes les exigences à un gestionnaire de services.
Sous ITIL, le gestionnaire de réseau doit soumettre son exigence à l'ITSM Service Desk » changer d'autorité », qui nomme alors un « gestionnaire du changement », à qui le gestionnaire de réseau doit ensuite expliquer en détail ses besoins. Le responsable du changement ne travaille pas en réseau et n’a donc pas les compétences nécessaires pour évaluer correctement les options disponibles. Le gestionnaire du réseau devrait être consulté à plusieurs reprises avant de recevoir une décision finale, ce qui pourrait ne pas constituer une solution décente.
Avec la voie NetDevOps, le gestionnaire de réseau identifie un besoin puis clarifie l'idée avec le responsable du service informatique. Le gestionnaire sera probablement plus préoccupé par le budget et imposera une limite au montant pouvant être dépensé pour l'acquisition. Le gestionnaire de réseau recherche ensuite les options et décide laquelle choisir : si le budget est respecté, le responsable du service informatique s’en fiche et ne s’implique pas.
ITSM et NetDevOps
ITIL s'oppose à l'idée que le gestionnaire de réseau trouve un nouveau système car cela détourne son attention de la tâche pour laquelle il est payé, à savoir la gestion du réseau. ITIL vise à éviter de perturber les opérations normales alors qu'un projet de changement est en cours.
Il est vrai que l’implication des opérationnels dans le changement réduit leur attention à la gestion quotidienne de leurs responsabilités. Si la gestion du réseau ne prend pas tout le temps du gestionnaire du réseau, alors il est clair qu’il sous-occupé et peut-être qu'un gestionnaire de réseau à temps partiel conviendrait mieux.
Le contre-argument est qu’en permettant au personnel des opérations de s’impliquer dans la gestion du changement, ils réduisent essentiellement leur allocation à l’exploitation au niveau du travail à temps partiel et utilisent le reste de leur temps pour remplacer un département entier : l'autorité de changement du Service Desk.
Le système ITIL de responsabilités segmentées ne fait pas gagner de temps et éloignerait le gestionnaire de réseau de sa tâche principale tout autant que de le laisser évaluer et acheter lui-même des logiciels. Les réunions nécessaires pour aider le Change Manager comprendre les exigences est un processus long et pourrait très bien aboutir à un achat inapproprié en raison du manque d’expérience du Change Manager dans le domaine spécialisé.
ITIL s'attend à ce qu'une autre section du service informatique mette en œuvre le changement demandé. Dans le cas de l’achat d’un logiciel d’aide à la gestion du réseau, cela impliquerait d’évaluer l’utilitaire acheté. Les personnes les plus qualifiées pour évaluer l’achat sont l’équipe des opérations réseau, et non un autre service. Si l'équipe de mise en œuvre du changement ITIL possédait suffisamment de compétences pour tester correctement les logiciels réseau, elle serait une équipe d'exploitation du réseau fantôme , ce qui constitue un gaspillage de ressources.
ITIL retire les changements décisionnels des mains des personnes qui ont demandé le changement et qui devront également vivre avec les conséquences d'une mauvaise décision. Plutôt que d'améliorer la répartition des responsabilités, ITIL permet simplement à ceux qui prennent de mauvaises décisions à plusieurs reprises de progresser dans leur carrière sans jamais avoir à subir les conséquences de leur mauvais jugement.
Projets NetDevOps
Un projet NetDevOps est ce que ITIL appelle un « changement majeur .» Il ne s’agit pas d’une maintenance quotidienne car ces tâches relèveraient naturellement de la compétence de la section des opérations, même dans le cadre de l’ITSM. Un projet NetDevOps typique nécessitera un travail de développement et des changements majeurs pour l’infrastructure du réseau .
Un exemple de ceci serait la sélection d'un nouvel outil de surveillance du réseau ou de nouvelles procédures de maintenance nécessitant un nouveau logiciel. Un autre exemple serait la création d'un nouveau département commercial, qui nécessiterait la fourniture de points d'extrémité supplémentaires et la pose de nouveaux câbles en guise d'extension du réseau.
L'ajout d'un nouveau sous-réseau peut nécessiter la réaffectation des sous-réseaux existants. Il faudrait donc évaluer l’impact de ces changements – une tâche qui serait confiée à une équipe distincte sous l’ITSM. Un projet NetDevOps nécessitera plus acquisition de matériel qu'un projet DevOps typique, qui est généralement presque entièrement un problème logiciel.
CI/CD
La notion de CI/CD est une stratégie DevOps qui peut être appliquée à la création de nouveaux systèmes sous NetDevOps. Le « CI » de ce terme fait référence à « Intégration continue » et le CD peut avoir deux significations : « déploiement continu ' ou ' livraison continue .» Le concept de livraison continue implique de préparer les modifications logicielles pour la publication, mais le déploiement continu signifie envoyer chaque modification de code directement en production.
Le modèle CI/CD est étroitement lié à Développement agile . Il s’agit de mettre en service une partie du nouveau système et d’utiliser la version partielle comme méthode pour tester l’adéquation du produit aux besoins des utilisateurs. La théorie est que les erreurs de conception peuvent être détectées plus tôt, avant qu’un investissement important ne soit réalisé. Cela évite qu’un changement coûteux soit nécessaire une fois que l’ensemble du système est livré.
Comme NetDevOps concerne bien plus le matériel que le logiciel, il existe certains projets pour lesquels une livraison partielle ne serait tout simplement pas pratique. Par exemple, cela ne servirait à rien si un réseau était à moitié construit. Ainsi, les pratiques CI/CD ne sont pas aussi pertinentes pour NetDevOps que pour DevOps. Cependant, certains projets NetDevOps pourraient avoir une livraison échelonnée , comme une transition progressive vers les services cloud.
Les modifications apportées à l'infrastructure réseau peuvent souvent être un processus itératif, car l'augmentation de la capacité dans une zone d'un réseau peut très facilement créer un nouveau goulot d'étranglement ailleurs. Modélisation synthétique un logiciel peut aider à détecter ces problèmes avant le début d’un projet d’expansion. Cependant, ces outils ne prédisent pas toujours correctement l’avenir. Vous ne saurez exactement ce que signifiera un changement dans le réseau qu’une fois que ce changement sera opérationnel.
Il est difficile de s’adresser aux détenteurs de fonds avec une définition initiale des exigences, sachant que les estimations des performances futures pourraient être erronées. NetDevOps offre aux gestionnaires de réseau un moyen plus simple de dire qu'ils ne savent pas si de nouveaux problèmes surgiront en raison de l'expansion de l'infrastructure visant à atténuer la surcharge des appareils. Un cadre NetDevOps peut être décrit comme un modèle de livraison continue visant à étendre la capacité sur l'ensemble du réseau, en commençant par des solutions pour ce commutateur déjà connu pour être surchargé. C'est une approche de planification plus réaliste dans le monde réel où les modèles de trafic ne se comportent pas toujours comme ils le devraient en théorie.
Le modèle CI/CD implique de déployer rapidement une solution partielle, de surveiller les résultats, d'ajuster le nouveau système en conséquence, de surveiller les résultats de ces changements, de faire des ajustements si nécessaire, et ainsi de suite, jusqu'à ce que la conception soit mise en place. un service qui fonctionne réellement et exécute toutes les fonctions souhaitées par les utilisateurs. Ainsi, la stratégie NetDevOps de CI/CD est un modèle de mise en œuvre idéal pour l'expansion de la capacité du réseau.
Avantages de NetDevOps
La pierre de touche organisationnelle du DevOps est « briser les silos .» Dans cette expression, un « silo » est une fonction compartimentée du service informatique qui a été figée dans un modèle de dotation en personnel dédié en permanence.
Selon le modèle ITIL, le personnel affecté à une fonction informatique n'est pas autorisé à intervenir et à aider lorsque les techniciens travaillant pour une fonction différente sont surchargés. La solution ITSM à une section surchargée de travail est de embaucher du personnel supplémentaire pour cette équipe, même si le personnel ayant des compétences similaires dans une autre section n'a que peu ou rien à faire.
L'objectif principal du DevOps est de augmenter la rentabilité par une efficacité améliorée. Un exemple de la façon dont la stratégie atteint cet objectif est une meilleure utilisation du personnel qualifié. Très peu d’entreprises ont une demande de changement suffisante pour justifier une section de développement de réseau distincte . Le besoin en personnel le plus constant concerne les opérations. De ce fait, la DSI concentrera sa stratégie de ressources humaines sur les opérations et sous-traiter le développement aux consultants. Cela résout la nature temporaire du développement mais crée ses propres problèmes.
Apporter une expertise pour le développement signifie que le personnel d’exploitation n’est pas impliqué dans la construction du nouveau système. Cela signifie que échange de connaissances doit constituer une très grande partie du début d’un projet. Formation opérationnelle est une tâche de transfert importante qui a lieu à la fin du projet. Si les personnes qui gèrent actuellement le système informatique sont celles qui développent le nouveau service, les processus d'entretien et de formation seront supprimés, ce qui permettra d'économiser du temps et de l'argent.
La segmentation ITSM des tâches entre les équipes crée coûts inutiles . Contrôler la portée d'un projet est notoirement difficile et la définition des exigences devient un processus très long qui, encore une fois, crée des coûts et des retards supplémentaires. Le cabinet de conseil externe ne sera pas obligé d’exécuter une tâche à durée indéterminée pour un prix fixe. Cette entreprise devra planifier sa propre capacité et elle devra savoir quand elle pourra libérer du personnel d'un projet pour en démarrer un autre pour un autre client.
La stratégie consistant à recourir à une ressource externe pour le développement peut aboutir à des contrats qui communiquer de manière inappropriée les exigences , proposant un système qui ne fonctionne pas mais qui doit être payé. Ainsi, l'ITSM peut fournir des systèmes insatisfaisants qui doivent être profondément retravaillés afin de les rendre conformes aux exigences d'origine. Ces réécritures coûtent de l’argent et, dans certains cas, les contrôleurs budgétaires ne sont pas disposés à allouer davantage de fonds pour corriger le système.
Politiques de bureau
Une solution mal adaptée et inappropriée apportée à un contrat mal rédigé peut obliger le service des opérations à créer des solutions de contournement pour compenser les erreurs et les lacunes. En réalité, le développement de tous les nouveaux systèmes informatiques est un processus récursif . Ce cycle répété de publication et de refonte qui s’exprime dans le modèle de développement Agile et la stratégie CI/CD se produira toujours. En ITSM, les ajustements sont perçus comme un échec, ce qui carrière menaçante pour les responsables informatiques et considéré comme une source de honte.
La stratégie ITSM consistant à répartir les responsabilités au sein du service informatique entraîne un grand nombre de politiques de bureau . Les managers deviennent réticents à démarrer un projet, sachant que le risque d’échec est grand. Ne rien faire ou retarder le lancement devient une stratégie de survie . Passer du temps à monter un dossier pour blâmer les autres avant que les choses ne tournent inévitablement mal finit par absorber plus de temps de gestion que la gestion réelle d'un projet de développement.
L'ITSM est déqualification des techniciens d'exploitation . Être laissé à la maintenance de systèmes obsolètes, tandis que des étrangers glamour et bien payés bénéficient de toute l'expérience de pointe crée hostilité entre opérateurs et développeurs . Tous deux possèdent les mêmes compétences et ont probablement suivi les mêmes cours à l’université. Ils pourraient donc tout aussi bien effectuer les mêmes tâches si leurs descriptions de poste n’obligeaient pas continuellement chaque équipe à suivre des cheminements de carrière différents.
NetDevOps crée un pool de compétences unique qui peut être appliqué aux tâches de développement ou d’exploitation. Cela maintient tous les techniciens sur un pied d'égalité et élimine la possibilité que certains membres du personnel soient sous-employés et sous-estimés.
Chaînes d'outils NetDevOps
Outre CI/CD, il existe pas de théorie globale qui sous-tend NetDevOps de la même manière que l'ITSM a ITIL. Il n’existe donc pas de progiciel unique d’outils prenant en charge le processus. Au lieu de cela, les responsables et les équipes NetDevOps utilisent une sélection d'outils distincts, et chaque responsable ou service choisira des outils différents en fonction de son expérience passée et de ses préférences personnelles. Ainsi, le logiciel qui prend en charge la stratégie NetDevOps est collectivement connu sous le nom de « chaîne d'outils .»
Le sujet des logiciels pour DevOps, et donc NetDevOps couvrirait un article entier. En fait, nous avons rédigé ce guide et vous pouvez le lire sur Les 8 meilleurs outils d'automatisation DevOps .
