La dernière édition du rapport annuel de Google sur le DevOps présente des données inattendues compte tenu des résultats précédents.
« Avant, le lien était bien plus clair. » Après bientôt dix ans à publier ses rapports sur le DevOps, Google dispose d’une matière qui lui permet une telle démarche comparative. Appliquée à la 9e édition, tout juste publiée, elle fait ressortir un certain nombre d’éléments contre-intuitifs ou tout du moins inattendus au regard des données historiques.
Cette année, l’échantillon comprend « plus de 1350 » répondants. Répartis comme suit (métier et taille de l’organisation).
Au-delà des contradictions qu’il soulève, le rapport a pour mais premier révèle des corrélations entre pratiques DevOps et performance. Performance sur trois points :
– Livraison logicielle (livraison)
Avec quatre indicateurs : fréquence de déploiement, délai de mise en œuvre des changements (du commettre à la prod), taux d’échec et temps de rétablissement.
– Performance opérationnelle
Un indicateur : la fiabilité. C’est-à-dire la capacité à répondre aux attentes des utilisateurs, essentiellement en termes de disponibilité et de performance.
– Performance organisationnelle (capacité à atteindre les objectifs de performance et de rentabilité)
Architectures découplées : durée limite ?
Depuis 2018, l’étude catégorise les organisations en « clusters », selon les critères de livraison. L’an dernier, il y en avait quatre. Cette année, il n’y en a plus que trois, faute d’un écart suffisant entre les deux catégories les plus « avancées ». Hypothèse : une diminution de l’innovation dans le développement logiciel, autant sur les pratiques que l’outillage.
Dans ce contexte, un deuxième classement a été réalisé cette année. Il inclut la performance opérationnelle. À la clé, quatre grappes.
Le fameux « lien bien plus clair » appelle la performance en livraison logicielle à la performance organisationnelle. Ou plutôt unissait : cette année, la première a tendance à ne pas bénéficier à la seconde aussi longtemps que la performance opérationnelle n’est pas élevée.
Des contradictions, il y en a aussi sur les architectures découplées. En particulier, le taux de burn-out est plus élevé dans les équipes qui sont sur ce modèle. Le rapport formule une hypothèse : dans les organisations concernées, la sécurité n’est peut-être pas du ressort des équipes responsables des applications. Le découplage de leurs travaux peut donc s’avérer plus complexe.
La tendance se retrouve pour le développement basé sur le tronc, comme pour CI et CD. Ressort une autre hypothèse, liée à une donnée mesurable : le niveau moyen d’expérience dans l’ayant baissé, sur un peut-être interrogé plus d’implémenteurs que de superviseurs.
Du CI au SRE : l’effet « courbe en J »
Le potentiel effet négatif des architectures découplées se fait aussi sentir lorsqu’on les combine à la livraison continue. Google évoque ici un phénomène de « courbe en J », où les premiers gains sont rapides, mais où on ne récolte les fruits postérieurs qu’à partir d’un certain stade de maturité. C’est ce qui se passe aussi avec le SRE (cf. schéma). Même dynamique pour le développement sur la base du tronc, alors que depuis 2014, on avait systématiquement constaté l’inverse.
Le SRE, justement, semble lui aussi avoir ses effets, en l’occurrence sur le livraison. Cela tient peut-être, nous explique-t-on, au fait que certaines organisations se concentrent sur la partie fiable (cluster « Retiring »).
Élément pas directement en contradiction avec des données historiques, mais à noter tout de même : les utilisateurs du cloud connaissent des taux d’échec plus importants. Cloud hybride et multicloud, en particulier, ont un impact négatif sur l’essentiel des critères de livraison… sauf si la performance opérationnelle est bonne.
Illustration principale © tout ce qui est possible – Shutterstock
