Publié par
Il y a 3 années · 7 minutes · DevOps

Cinq anti-patterns DevOps

 

Vous en avez assez de patienter deux mois pour livrer en production ? Vous souhaitez fluidifier les livraisons de votre entreprise en faisant collaborer Devs et Ops ?
Bravo ! Mais une fois n’étant pas coutume, plutôt que de prêcher la bonne parole, nous allons parler des erreurs souvent commises et voir ensemble comment les éviter.

Découvrez avec nous cinq anti-patterns DevOps courants.

Anti-Pattern numéro 1: L’outil magique

2012-velocity-london-devops-patterns-distilled-29-728.jpgLe premier Anti-Pattern dont nous allons parler est également le plus courant (malheureusement). Il consiste à confondre DevOps avec automatisation et donc à ajouter un outil permettant de déployer automatiquement les systèmes.

Disons le tout de suite il n’existe pas d’outil magique fluidifiant comme par magie le processus de mise en production.

Si l’idée de cet outil provient des équipes de développement, les opérationnels penseront qu’on veut les remplacer. Au contraire si l’idée vient des opérationnels, les développeurs se sentiront peu (voir pas du tout) impliqués.

Le plus important n’est pas l’outil mais bien la culture de l’échange et de la communication entre les équipes.
Construire une vraie culture de la qualité est bien plus complexe que d’installer un outil mais il s’agit de la seule façon efficace d’améliorer la chaine de valeur et d’obtenir les bénéfices escomptés par l’application des pratiques DevOps.

Anti-Pattern numéro 2 : L’équipe merveilleuse

Quasiment aussi courant que l’Anti-Pattern « j’impose un outil » voici l’Anti-Pattern « L’équipe merveilleuse » aussi connu sous le nom de « Je crée mon équipe DevOps ».

Il consiste tout simplement à créer une équipe dédiée à la mise en place d’une démarche DevOps au sein de l’entreprise.

Un principe fondateur de cette démarche est de faciliter le passage du logiciel de l’équipe de développement à la mise en production et de pouvoir livrer des fonctionnalités rapidement. Ajouter une nouvelle équipe n’est pas la bonne façon de faire, sauf à imaginer que cette nouvelle équipe soit en charge de l’amélioration des pratiques et de la transformation des autres équipes.

Le but de DevOps est de supprimer les silos pas d’en créer un nouveau.

Plutôt que d’ajouter une couche supplémentaire il faut plutôt faciliter le passage du livrable d’une couche à une autre. Pour cela il est nécessaire d’accroitre les liens entre les différentes équipes: Développement, Opérationnel mais également Gestion de projets & Quality Assurance, bien que ceux-ci soient souvent oubliés.
Cela se fait en indiquant clairement l’objectif à atteindre, en fournissant de la visibilité sur la situation actuelle, en fournissant les métriques associées, afin d’aligner les buts de l’ensemble des équipes.

Anti-Pattern numéro 3 : L’histoire sans fin

Afin de faire émerger une culture commune dédiée à livrer de la valeur en production, il est nécessaire que chaque équipe implique l’autre et cela dès le début du projet.

Une étape importante dans tout projet Agile est de choisir une Definition of Done qui aide chaque membre de l’équipe de développement à comprendre ce qui est nécessaire pour considérer une tâche comme terminée.

Bien souvent la Definition of Done choisie est trop réductrice; Une User Story est finie quand elle apporte de la valeur au client et donc quand elle est en production, et non pas quand elle est seulement commitée ou acceptée par le PO ou la QA.

Cela oblige à inclure les Ops dans le projet, à ajouter une étape dans votre management visuel et à vous préoccuper du devenir de vos User Stories une fois le développement terminé. Et la réciproque est également vraie pour les administrateurs systèmes; Avoir un beau script automatisant un déploiement sur son PC n’est pas suffisant. Ce script doit être disponible dans le gestionnaire de source, compréhensible, modifiable et exécutable par d’autres, en particulier l’équipe de développement.

Il est capital de se mettre à la place de l’autre, celui qui reçoit votre livraison ou doit utiliser votre script de déploiement.

Anti-Pattern numéro 4 : Chez moi ça marche

De la même façon que les développeurs se doivent d’inclure les opérationnels dans leurs processus le contraire est également vrai.

Cela permet d’éviter des dialogues extrêmement constructifs de type :
« – La dernière version est lente en production !
– Ah bon ? Chez moi ça marche… »

Cette réponse trop souvent donnée par les développeurs provient principalement d’un manque d’information sur ce qui se passe réellement en production. Et pour corriger cela il faut partager, échanger, comme toujours.

Les Ops peuvent par exemple partager les différents indicateurs de santé de la plateforme avec les développeurs sous forme de dashboards.
Sur le même principe les développeurs peuvent être notifiés en même temps que les Ops en cas de problème sur la plateforme (ce qui incitera également à ne pas mettre tous les logs au niveau Error ou Critical…)

Enfin il est également souhaitable de mettre en place des tests de performance en continu sur un environnement de pré-production toujours dans le but de partager des métriques communes entre les équipes opérationnelles et de développement.

De manière plus générale chaque personne de l’équipe doit se sentir responsable des fonctionnalités livrées à l’utilisateur. Problèmes de code, problèmes d’infrastructure doivent avoir le même résultat: chacun doit se sentir concerné.

Anti-Pattern numéro 5 : Nous sommes uniques

Un autre classique, nous ne pouvons pas mettre en place DevOps, nous sommes uniques. Notre entreprise est tellement particulière que ces nouvelles techniques ne fonctionneront pas.

Oui, mais c’est le cas de tout le monde. Chaque entreprise à ses particularités, ses individualités différentes et ses problèmes. Et donc à cause de cet état d’esprit on continue à travailler, toujours de la même manière, toujours avec les même problèmes.

Il faut bien se rendre compte que les principes DevOps sont appliqués dans un grand nombre d’entreprises, petites ou grandes et même au sein de gouvernements (par exemple celui du Royaume-Uni). Bien évidement changer une culture d’entreprise n’est pas une tâche simple et aisée. On ne peut pas arriver un lundi matin et se dire, aujourd’hui mon entreprise passe à DevOps. Cela prend du temps et se fait par incrément.

L’idée principale est  de commencer petit afin de construire de la confiance et montrer que cela fonctionne sur un petit projet pilote. De plus il est plus aisé de convaincre le management d’appliquer cela sur un petit projet, représentant moins de risques que de débuter directement par le projet critique pour la survie de l’entreprise.

Une fois que l’on a un projet pilote il est très important de mettre en place des métriques, c’est une idée essentielle de DevOps, mesurer. Il faut trouver des KPI représentatifs du changement et permettant de le suivre. Ces KPI sont également très utiles pour communiquer sur le projet et sur l’application de DevOps. Appuyer son histoire DevOps sur des données chiffrées est toujours plus convaincant et objectif que de l’appuyer sur des sentiments.

Si tout se passe bien et que vous communiquez régulièrement sur votre projet (via les indicateurs et votre histoire) celui-ci devrait commencer à attirer des personnes curieuses. Il faut dégager du temps pour elles afin d’expliquer la méthode, les difficultés rencontrées sur votre projet et les bénéfices apportés par la méthode.

L’amélioration continue est également une part importante du processus de transformation. Vous allez rencontrer des problèmes. Il est essentiel d’apprendre de ces problèmes et de retirer (ou d’automatiser) les étapes ne créant pas de valeurs suivant une démarche typiquement Lean.

Ainsi petit à petit même votre entreprise totalement unique pourra effectuer sa transformation.

Conclusion:

La démarche DevOps ne se résume pas à une démarche d’automatisation ou à une équipe de développeurs DevOps faisant le travail des opérationnels. Il s’agit d’un ensemble de pratiques humaines ayant pour but de livrer des logiciels en production de façon rapide, sûre et mesurable.

Celles-ci peuvent être résumées par l’acronyme CALMS:

  • Culture : privilégier les personnes et les interactions plutôt que les process ou les outils ;
  • Automation : l’automatisation est primordiale pour faciliter les installations afin d’obtenir des retours rapides d’une nouvelle version ;
  • Lean : utiliser les principes Lean (débuter petit, identifier les processus amenant de la valeur, amélioration continue) afin de diminuer le temps de cycle ;
  • Measurement : mesurer tout ! Cela permet d’aligner les équipes via des métriques communes et partagées ainsi que de voir les points de blocage empêchant un feedback rapide ;
  • Sharing : créer une culture où les personnes partagent des idées, des outils,…


Bon courage !

Matthieu Nantern
Matthieu est un consultant Java senior spécialisé en DevOps, Apache Cassandra et la performance des applications. Depuis plus de 8 ans il remplit des missions agiles de développement, d'architecture et de conseils pour diverses sociétés. Récemment il est devenu formateur sur Apache Cassandra. Il travaille actuellement sur un projet de développement d'une plateforme IoT pour un grand groupe français.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *