Cet article est un extrait de notre livre blanc "La révolution DevOps", à télécharger d'urgence !

Les géants américains de l’internet ont popularisé une nouvelle organisation des DSI, appelée DevOps, qui améliore significativement la réactivité et la qualité de l’informatique, et pose ainsi un nouveau défi aux entreprises et aux DSI traditionnelles qui ont emprunté d’autres voies. Voyons sept questions que tout DG ne manquera pas de poser prochainement à son DSI sur ce sujet d’importance.

Comment caractériser DevOps ?

DevOps est un mot formé de la contraction du mot « développement » et du mot « opérations » qui correspond au mot français « production ». DevOps est une approche qui prône le rapprochement des équipes de développement informatique et d’exploitation dans le but d’améliorer la réactivité des DSI et de diminuer la durée comprise entre la demande de la modification d’un service IT et sa mise en ligne. Les méthodes agiles de développement issues de la démarche Lean d’optimisation des organisations d’origine japonaise sont ainsi étendues à la production informatique.

La méthode Lean vise la suppression progressive et continue de tout type de gaspillage et requiert la collaboration de l’ensemble des acteurs. Scrum est par exemple un mode de développement agile qui évite la réalisation de fonctionnalités inutiles, et s’appuie sur des itérations courtes consacrées aux attentes prioritaires.

Les gaspillages

DevOps s’attaque de même aux gaspillages que génèrent :

  • Les délais de mise à disposition des infrastructures de développement ou de production
  • Les délais dans la mise en production des applications du fait d’un grand nombre de tâche
    manuelles
  • Un processus de changement en production beaucoup trop long et bureaucratique, alors qu’il est inutile de demander aux productions de comprendre le contenu de chaque changement applicatif lorsqu’il s’agit par exemple d’une modification du paramétrage de règles de gestion du métier.

Réactivité et stabilité

Le manque de réactivité des Opérations conduit à présenter cette structure comme un silo fermé sur lui-même. Ce fonctionnement est dû selon les tenants de DevOps au fait que les opérations sont missionnées sur la « stabilité » de la production, alors que les études sont incitées au contraire à La Révolution DevOps : 7 questions incontournables du DG au DSI
produire de nombreuses « évolutions » pour satisfaire leurs clients et à aligner ainsi en continu les fonctionnalités des services rendus par les logiciels sur les besoins des métiers.

Le « build », le « run » et les « services IT »

Cette divergence s’explique aussi selon eux par la focalisation des études sur le service quotidiennement en ligne, alors que les productions seraient restées sur une vision basée sur les applications qui distingue leur développement (le build) et leur exploitation (le run). Les partisans de DevOps considèrent cette vision obsolète.

Les solutions

Les solutions reposent donc essentiellement sur :

  • La mise à disposition des infrastructures et des environnements à la demande conformément aux fonctionnements des Clouds
  • La suppression des tâches manuelles dans les opérations, à commencer par les mises en production
  • L’acceptation automatique des changements applicatifs
  • L’accès à la supervision et aux messages d’erreur applicatifs pour les équipes études

DevOps est donc prôné par les « Dev ». Qu’en disent les « Ops » ?

La stabilité du fonctionnement

Les productions expliquent que si leur attachement à la stabilité est bien réel, il faut l’entendre comme la stabilité du fonctionnement des services IT en production, et pas du tout comme la stabilité du périmètre des services !

Le problème avec la modification du périmètre des services, c’est à dire avec les mises en production, vient de ce qu’elle entraîne de nombreux incidents parfois dus à des erreurs lors des opérations d’installations de nouvelles versions, mais aussi dus très largement à la mauvaise qualité des logiciels fournis, ou aux régressions qu’une mauvaise gestion des versions entraîne.

La principale raison d’être de la définition d’un nombre limité de dates autorisées de mise en production n’est pas le besoin de tranquillité des productions, qui voient au contraire leur charge d’installation concentrée sur quelques jours, mais bien d’obtenir une période de rémission suffisante dans les défauts de fonctionnement des services IT après les corrections consécutives à la dernière vague d’installation !

De même les difficultés d’installation résident souvent dans une définition erronée ou incomplète des actions à mener demandées par les études.

Les logiciels inaptes à la mise en production

Les livraisons de logiciels inaptes à la mise en production mettent l’exploitation en défaut par rapport aux engagements qu’elle prend quant à la disponibilité des services IT pour les utilisateurs et expliquent la réticence des exploitants à une augmentation de leur fréquence.

Le « build », le « run » et les « services IT »

Par ailleurs, l’idée américaine que les productions seraient en retard dans la perception de l’importance des « services » rendus aux utilisateurs est sans objet dans le cas des productions européennes qui sont beaucoup plus en avance que leurs semblables américaines sur l’adoption du référentiel de bonnes pratiques d’origine anglaise connu sous le nom d’ITIL qui met cette notion au centre de ses préconisations. Les productions récusent en fait aussi bien le parallèle implicite entre études/production et Build/Run que celui déjà décrit entre études/production et réactivité/stabilité.

En effet une production n’est pas l’entité en charge du « Run », alors que les études seraient en charge du Build. Les études participent à l’exploitation des services à au moins deux titres : Elles sont impliquées dans le diagnostic et la résolution d’incidents lorsqu’ils touchent la couche applicative et elles mènent souvent des vérifications quotidiennes du bon fonctionnement des traitements critiques pour le compte des métiers.

Les études ne sont pas davantage l’organisation exclusivement en charge de la fabrication des services (Build), puisque les productions créent, à l’occasion des mises en production, les paramétrages qui permettent aux logiciels proprement applicatifs d’utiliser les outils d’infrastructure : paramétrages des serveurs d’application, des ordonnanceurs de traitements,
des outils de sauvegarde ou d’archivage, de surveillance, etc. Ces paramétrages sont appelés « objets de production ».

Mission et organisation actuelle de la DSI

En revanche, les productions ne disconviennent pas que le fonctionnement en vigueur n’est pas optimal. En effet, par construction, les productions traditionnelles sont constituées des seuls personnels habilités à intervenir sur les machines de production. La raison historique de ce choix est la sanctuarisation de ressources nécessaires et suffisantes à la fourniture des services aux métiers.

La mission de la DSI, qui consiste essentiellement à fournir des services alignés sur les besoins métiers et dotés d’une sûreté de fonctionnement correcte, ne coïncide donc pas avec le découpage actuel entre département études et productions : Si les études sont seules en charge de l’alignement fonctionnel, la sûreté de fonctionnement de la couche applicative implique assurément les deux structures. L’exploitation ne peut pas être tenue seule responsable des dysfonctionnements des services IT en production du simple fait qu’elle est la première à les constater et la seule à disposer des accès pour les réparer.

L’intérêt de DevOps est de résoudre très différemment la difficulté que cette double mission représente.

[...]


Warning: Undefined array key 0 in /home/clients/4524025f656cbe0ae61b8ba6d71d7b71/web/wp-content/plugins/oxygen/component-framework/includes/acf/oxygen-acf-integration.php on line 739