DevOps et performance : une corrélation évidente selon Google

« 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 9^e é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 but premier de révéler des corrélations entre pratiques DevOps et performance.

Performance sur trois points :

– Livraison logicielle (delivery)
Avec quatre indicateurs : fréquence de déploiement, délai de mise en œuvre des changements (du commit à 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 profitabilité)

Architectures découplées : dure limite ?

Depuis 2018, l’étude catégorise les organisations en « clusters », selon les critères de delivery.

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 clusters.

Le fameux « lien bien plus clair » susmentionné unit 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’échantillon ayant baissé, on a 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 ressentir 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 ulté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 négatifs, en l’occurrence sur le delivery. Cela tient peut-être, nous explique-t-on, au fait que certaines organisations se concentrent sur la partie fiabilité (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 delivery… sauf si la performance opérationnelle est bonne.

Illustration principale © everything possible – Shutterstock