DevOps : les pièges sont humains, pas techniques

Prolongement de l’agilité, la démarche DevOps apporte son lot d’améliorations en termes d’accélération du rythme des livraisons, d’architecture et de qualité. Pour autant, elle n’est pas une « solution miracle ». Aussi outillée soit-elle, elle requiert une adaptation des processus et des comportements humains, sous peine d’introduire de nouvelles difficultés. Trois pièges à éviter pour réussir sa démarche DevOps.

L’accélération des livraisons, induite par le DevOps, implique des changements à toutes les étapes du processus de « fabrication » et de livraison des applications : intégration continue, automatisation des tests, des déploiements et enfin, automatisation des opérations. Avec pour principal corollaire un décloisonnement des différents corps de métiers  (développement, qualité, opération) doivent travailler plus fréquemment et plus étroitement sur l’ensemble du cycle de vie du produit, du design au support en production.

Si les grands principes restent les mêmes, l’amorçage et la définition des étapes de mise en œuvre d’une démarche DevOps n’est pas identique d’une organisation à l’autre. Et dépend avant tout de sa taille, de sa complexité et bien sûr de la maturité de ses processus existants. Le quotidien d’une agence web mono-site de trois personnes travaillant sur un site web diffère complètement d’un projet regroupant 100 personnes réparties entre plusieurs pays et œuvrant à la mise en place d’une plateforme multi-composants. Or, la problématique de la mise à l’échelle d’une méthode est trop souvent minimisée. De même, l’existence d’équipes d’exploitation internes ou le recours à un infogéreur aura un impact direct sur la démarche DevOps, qui sera plus complexe à mettre en œuvre (et à contractualiser) avec un exploitant externe.

Dans tous les cas, la démarche DevOps ne peut pas faire l’économie d’un audit préliminaire. Objectif : déterminer la maturité actuelle de l’organisation et surtout définir les étapes de mise en œuvre. Concrètement, il s’agit de définir un certain nombre d’objectifs accessibles rapidement et présentant une forte valeur ajoutée. Car travailler à la réalisation d’un objectif idéal et lointain, en oubliant les impératifs de livraison à court terme, ne peut qu’aboutir à un échec. En bref, il s’agit de définir les grands principes, adaptés au cas par cas. La méthodologie doit avant tout être le bon sens !

Initier la démarche DevOps nécessite des ressources. Pour autant, l’approche étant  relativement récente, les profils réellement spécialisés sont encore peu nombreux. En attendant, les profils développeurs sont généralement privilégiés car ils disposent de compétences spécifiques, notamment de scripting, pour l’automatisation des tests ou encore des déploiements. La raison avancée est simple : on considère, à tort ou à raison, que cette compétence est la plus compliquée et longue à acquérir.

Résultat : les profils initialement formés à la qualité ou à l’exploitation sont moins représentés dans les équipes DevOps que leurs homologues développeurs. Rien de grave a priori ? C’est pourtant vite réduire l’IT à du simple codage et scripting, et oublier l’importance du contexte, de l’expérience, de la prise en compte des dépendances et de la prise de hauteur. Au risque, in fine, de passer à côté de l’essentiel : automatisation des tests sans prise en compte des cas d’utilisation réels de bout en bout et des cas de test dégradés, automatisation du déploiement sans capacité de rollback, de back-up et sans prise en compte d’un plan de reprise d’activité, etc.

Cet écueil est entretenu par la littérature et la documentation proliférant sur le web, tandis que l’apparition du concept « NoOps » amplifie le phénomène. Alors certes, dans plus ou moins 10 ans, les Ops seront peut-être remplacés par des automatismes, mais en attendant, ce n’est pas le cas. Et ce sont bel et bien encore les équipes d’exploitation qui gèrent le quotidien de la production. A quelques exceptions près, les intégrer et les faire contribuer à la démarche DevOps n’est aujourd’hui pas une option mais une obligation.

Avec des objectifs communs orientés vers la satisfaction utilisateur et le service rendu, DevOps tend à abolir les barrières entre les développeurs, les exploitants et les testeurs. Les nouvelles activités de chacun impliquent l’apparition de zones de chevauchement des responsabilités des différents corps de métier. Or, dans un rythme de déploiements soutenu, le flou qui peut en résulter constitue un risque majeur. Il n’est d’ailleurs pas rare, qu’au cours des premières itérations, il manque un certain nombre de prérequis à la veille du déploiement…

Si la démarche DevOps prône la responsabilité collective, c’est d’un point de collaboratif, pas quant aux livrables. Le risque de dire que « tout le monde » est responsable conduit souvent, dans les faits, à l’irresponsabilité de chacun ! Si des groupes de travail sont intercalés entre les équipes traditionnelles, les livraisons, dont le contenu a évolué, s’effectuent en respectant les mêmes étapes qu’auparavant. DevOps implique donc à la fois une responsabilité collective par rapport au service rendu mais également une responsabilité de chaque groupe de travail sur son périmètre d’actions, condition essentielle pour identifier les axes d’amélioration.

Enfin, dans un souci d’efficacité, le nombre de réunions d’étapes a été réduit. Or ces dernières permettaient de s’assurer que toutes les tâches avaient bien été réalisées, par chaque groupe, et que les risques avaient été couverts.

Pour répondre à ces enjeux, il est indispensable de modéliser les processus de l’usine logicielle, et de bien définir les tâches, les rôles et les responsabilités de chaque groupe. Ces éléments constituent la base d’une démarche DevOps.