Loading...Il s’est passé un peu de temps depuis mon précédent article sur DevOps et je m’en excuse. Cela m’aura au moins appris une leçon : il vaut mieux écrire tout de suite un article et sa suite et de les publier en deux temps.
Dans ce second article, je voudrais expliquer les 5 aspects que j’évoquais dans la première partie et présenter non seulement les bonnes pratiques à appliquer pour les faire émerger mais aussi les erreurs à éviter.
Comme toutes les méthodes agiles, DevOps agit sur trois axes : l’humain, l’organisation et la technologie. Les cinq aspects de la méthode DevOps se retrouvent dans chacun de ces trois axes.
Repenser l’organisation
Traditionnellement, les équipes de développement et d’exploitation sont distinctes car leurs buts diffèrent intégralement. Les unes veulent faire évoluer les applications de production et les autres veulent maintenir la stabilité du SI. Comment ces objectifs contradictoires peuvent être réconciliés ?
La première chose à faire est de démontrer que ces deux objectifs ne sont que les facettes d’un seul et même but : répondre à des besoins métiers. Quand développeurs et exploitants prendront le recul nécessaire (et DevOps y contribue pour une large part) et constateront qu’ils visent un même but, les freins traditionnels pourront plus facilement s’effacer.
Mélanger les compétences au sein des équipes, décloisonner les organisations et favoriser la communication sont les leviers qui permettent cette prise de conscience. Il s’agit avant tout d’une « évolution culturelle » (notez bien l’emploi du mot évolution).
Adapter l’infrastructure et l’architecture logicielle à l’automatisation
La devise officieuse de DevOps est « automatiser, automatiser et encore automatiser ». Si l’incertitude du résultat des déploiements et les aspects « goulet d’étranglement » et « point individuel de défaillance » (respectivement bottleneck et single point of failure pour ceux qui sont rétifs à l’emploi de termes français) peuvent être éliminés par l’emploi de technologies adaptées, il existe des bonnes pratiques à appliquer et des erreurs à éviter pour que la technologie d’automatisation ne se transforme pas en cauchemar d’implémentation et ne complexifie le système qu’elle était censé simplifier.
Du côté exploitation, l’automatisation suppose la virtualisation et la standardisation des environnements. La standardisation doit être décidée au niveau de la gouvernance du SI mais conçue et mise en place par le niveau opérationnel rassemblant développeurs et exploitants. On voit ici que les aspects sont fortement imbriqués. Cela ne signifie pas qu’il faille parvenir à mettre en place une organisation décloisonnée et des équipes pluridisciplinaires avant toute tentative de standardisation mais que les deux vont de pair et qu’il s’agit d’un processus continu d’amélioration et de généralisation. De ce point de vue, commencer à mettre en place des équipes mixtes développeurs/exploitation pour déterminer les standards du SI est une bonne idée.
Du côté conception et réalisation, le déploiement incrémental suppose que l’architecture de la solution logicielle l’accepte. Cette problématique est très semblable à celle posée par l’intégration continue et une équipe de développement rodée à cet exercice ne devrait pas avoir trop de mal à franchir ce pas. Les solutions ici s’appellent architecture modulaire, couplage lâche, séparation des responsabilités, tests automatisés et refactoring.
Informer, informer et encore informer
Si DevOps (et les méthodes agiles en règle générale) devait avoir une devise ce serait plutôt celle-ci. En effet, les aspects communication et mesure sont incontournables dès qu’il s’agit de savoir qu’est-ce qui a été déployé, où, quand, comment et par qui.
Automatiser à outrance sans avoir un framework de communication et de mesure adéquat conduit à re-complexifier le système et à y introduire de l’incertitude, tout ce qu’on cherche à éviter en adoptant la démarche DevOps !
Communication et mesure sont intimement liées et peuvent aussi bien être mises en place à un niveau informel que formel. Par exemple, mettre les développeurs en première ligne du support technique leur permettra d’obtenir des retours d’expérience de première main et de répondre plus efficacement aux demandes de corrections et d’évolution. Il s’agit là encore d’un exemple d’organisation décloisonnée car si les exploitants peuvent participer au développement des solutions, l’inverse est également vrai : les développeurs peuvent également mettre la main à la pâte dès qu’il s’agit de maintenir ce qu’ils ont développé. Il est possible que certains considèrent cela comme une sorte de déchéance mais c’est là que réside toute la difficulté de DevOps : opérer cette évolution culturelle.
On ne change pas la culture mais on peut changer les comportements
N’importe quel ethnologue le dira, on ne change pas la culture d’une organisation parce qu’on le décide. Tout ce qu’on peut faire c’est changer les comportements individuels ou, tout du moins, inciter les individus à changer leur comportement s’ils en voient les bénéfices immédiats. Au bout d’un moment, l’évolution des ces comportements individuels définira une nouvelle culture.
Les incitations qui fonctionnent dépendent largement des individus et de leur propre culture mais il existe quelques bonnes pratiques qui ont fait leurs preuves :
- mettre en place des outils simples que les utilisateurs DevOps s’approprient
- favoriser l’émulation entre pairs
- promouvoir les activités des équipes DevOps auprès des décideurs (direction et product owners) et en renforcer la reconnaissance
Se faire accompagner
Une erreur souvent commise est de croire que DevOps c’est simple à mettre en place parce que c’est simple à comprendre. En réalité, s’agissant de conduite du changement et d’évolution culturelle, c’est bien plus complexe et incertain que ça en a l’air. Prendre du recul, aller à l’essentiel et ne pas mettre la charrue avant les bœufs sont des choses qui sont difficiles à faire lorsqu’on a une DSI à diriger, une infrastructure à exploiter et des services à concevoir. Autant mettre toutes les chances de son côté et demander conseil à un prestataire dont les avis objectifs et l’expérience permettront de démarrer l’approche DevOps sur les bons rails.
