Framework CALMS

Les défis, voire les urgences, constituent des tests efficaces de la culture DevOps. Vos équipes de développement, opérationnelles et spécialistes du service clients « swarment »-elles à la résolution des problèmes en groupe ? Les post-mortems d'incident visent-ils à améliorer les résultats pour le prochain incident plutôt qu'à pointer du doigt ? Si la réponse est « oui », c'est une bonne indication que votre organisation adopte une culture DevOps.

Les entreprises les plus fructueuses ont intégré la culture DevOps dans tous leurs départements et à tous les échelons de l'organigramme. À une telle échelle, le terme « DevOps » est souvent trop restrictif et n'est plus nécessaire. De telles entreprises disposent de canaux de communication ouverts et échangent fréquemment. Elles partent du principe que la satisfaction des clients relève tout autant de la responsabilité des chefs de produit que de celle des équipes de développement. Elles comprennent que DevOps n'est pas le fardeau d'une équipe. C'est un travail collectif.

L'automatisation permet d'éliminer les tâches manuelles répétitives, exploite des processus reproductibles et crée des systèmes fiables.

L'automatisation du développement, des tests, du déploiement et des tâches de provisionnement constitue un point de départ classique pour les équipes qui n'ont pas encore franchi ce cap. Et à quoi bon se mentir : quelle meilleure motivation pour les équipes de développement, de test et opérationnelles que de collaborer pour développer des systèmes qui profitent à tous ?

Les équipes qui débutent avec l'automatisation démarrent généralement par la livraison continue : soumettre chaque changement de code à une batterie de tests automatisés (une opération souvent facilitée par l'infrastructure basée dans le cloud), puis créer un package des builds fonctionnels et les promouvoir dans les différents environnements grâce à des déploiements automatisés.

Pourquoi ? Les ordinateurs exécutent des tests de façon plus rigoureuse et plus fiable que les êtres humains. Ces tests détectent les bugs et les failles de sécurité au plus tôt. De plus, le déploiement automatisé alerte les équipes informatiques et opérationnelles de toute « dérive » entre les environnements, ce qui réduit les surprises au moment de la livraison.

Une autre contribution majeure de DevOps est le concept de CaC ou « Configuration as Code ». Les développeurs s'efforcent de créer des applications modulaires et composables, car elles sont plus fiables et plus faciles à administrer. Cet état d'esprit peut être étendu à l'infrastructure qui les héberge, qu'elle se trouve dans le cloud ou sur le réseau de la société.

« Configuration as Code » et « livraison continue » ne sont pas les seuls types d'automatisation observés à l'ère DevOps, mais cela vaut la peine d'en parler, car ils contribuent à éliminer les cloisons entre les équipes de développement et opérationnelles. Et, lorsque DevOps s'appuie sur les déploiements automatisés pour envoyer du code minutieusement testé à des environnements provisionnés de la même façon, la mentalité « Ça fonctionne sur ma machine » n'est plus pertinente.

Lorsque nous parlons de « Lean » dans le contexte des logiciels, nous pensons généralement à éliminer les activités à faible valeur ajoutée pour travailler plus rapidement. En un mot, être Agile. Les concepts d'amélioration continue et de reconnaissance des échecs sont d'autant plus pertinents pour DevOps qu'ils posent les bases d'un état d'esprit expérimental.

Une mentalité DevOps reconnaît les opportunités d'amélioration continue en permanence. Certaines sont évidentes, comme la tenue de rétrospectives régulières pour améliorer les processus de l'équipe. D'autres sont plus subtiles, comme les tests A/B de différentes approches d'intégration de nouveaux utilisateurs de vos produits.

Nous devons remercier le développement Agile pour avoir popularisé l'amélioration continue. Les premiers partisans de la méthodologie Agile ont prouvé qu'un simple produit mis entre les mains d'un client dès aujourd'hui a plus de valeur qu'un produit parfait qui sera livré aux clients dans six mois. Si le produit est amélioré en continu, les clients restent fidèles.

Et devinez quoi : l'échec est inévitable. Vous feriez donc bien de faire en sorte que votre équipe l'assimile, s'en remette et en tire des leçons (certains parleraient d'une mentalité antifragile). Chez Atlassian, nous pensons que si vous n'échouez pas au moins une fois, vous ne faites pas assez d'efforts.

Dans le contexte DevOps, l'échec n'est pas une infraction. Les équipes partent du principe que quelque chose va finir par mal tourner, c'est pourquoi elles mettent tout en œuvre pour détecter rapidement les bugs et les résoudre. Les post-mortems se concentrent sur les aspects sur lesquels les processus ont échoué et sur les méthodes pour les renforcer, et non sur le membre de l'équipe qui a failli. Pourquoi ? Parce que l'amélioration continue va de pair avec les défaillances.

Il est difficile de prouver que les efforts que vous déployez en vue de l'amélioration continue améliorent réellement les données. Fort heureusement, il existe de nombreux outils et technologies permettant de mesurer les performances : durée d'utilisation de votre produit par les utilisateurs, ventes générées par un billet de blog, fréquence des alertes critiques dans vos journaux…

Bien que vous puissiez mesurer la plupart des indicateurs, cela ne veut pas dire que vous devriez le faire. Prenez un projet de développement Agile et commencez par le début :

Combien de temps vous a-t-il fallu pour passer du développement au déploiement ?

À quelle fréquence les bugs ou les défaillances se reproduisent-ils ?

De combien de temps avez-vous besoin pour reprendre vos activités après une panne système ?

Combien de personnes utilisent-elles votre produit à cet instant ?

Combien d'utilisateurs avez-vous gagnés/perdus cette semaine ?

Si vous mettez des bases solides en place, il est facile de suivre des métriques plus sophistiquées sur l'utilisation des fonctionnalités, le parcours client et les accords de niveau de service (SLA). Les informations qui vous parviennent tombent à point nommé, quand le moment est venu d'établir une feuille de route et de définir les spécifications de votre prochain grand projet.

Toutes ces précieuses données aideront votre équipe à prendre des décisions, mais elles ont encore plus d'impact lorsqu'elles sont partagées avec d'autres équipes, en particulier celles d'autres services. Par exemple, votre équipe marketing a besoin de nouvelles fonctionnalités géniales dont elle peut faire la promotion. Mais, dans le même temps, vous constatez que vous perdez des clients, car le produit accumule une dette technique. Le recours aux données utilisateur pour appuyer votre feuille de route, même si elle concerne davantage les corrections que les fonctionnalités, vous permettra de parvenir à un consensus et d'obtenir l'appui des parties prenantes plus facilement.

Autant nous souhaiterions disposer d'une baguette magique pour transformer toutes les équipes en équipes DevOps ultra performantes, autant les transformations DevOps nécessitent un mélange de pratiques, de philosophies culturelles et d'outils. Mais, comme vous l'avez lu, les avantages du décloisonnement des équipes de développement et opérationnelles en valent la peine : confiance accrue, livraisons de logiciels plus rapides, déploiements plus fiables et meilleure boucle de feedback entre les équipes et les clients.

Adopter DevOps n'est pas une mince affaire. Pourtant, avec la mentalité, les efforts et les outils appropriés, une organisation peut opérer une transformation DevOps pour en tirer des avantages significatifs.

Le désaccord de longue date entre les équipes de développement et opérationnelles est principalement dû à l'absence de terrain d'entente. Nous pensons que partager la responsabilité et les réussites contribuera grandement à combler ce fossé. Les équipes de développement s'attireront les bonnes grâces des équipes opérationnelles en endossant l'un de leurs plus lourds fardeaux : le pager (un concept figuré de nos jours). L'un des grands principes DevOps est que le développeur d'une app doit également participer à sa livraison et à son exécution.

C'est de cette idée que découle l'approche YBIYRI (« you build it, you run it » ou « vous le concevez, vous en êtes responsable ») qui favorise la pratique au sein des équipes. Cela ne veut pas dire que les développeurs que vous embauchez seront aussi d'office d'excellents opérateurs. Dans les faits, les développeurs et les opérateurs travaillent main dans la main tout au long du cycle de vie de l'app. En outre, certains rapports ont montré que la revue du code et des produits par des pairs constitue le seul examen qui se traduise par une amélioration de la livraison et des performances. En fait, les cycles faisant appel à des réviseurs externes ne sont pas plus efficaces qu'un cycle sans aucune revue.

Les équipes qui adoptent DevOps jouent souvent un rôle variable ; les développeurs résolvent les tickets soumis par les utilisateurs finaux, tout en apportant une réponse aux problèmes de production. Ils réagissent aux tickets urgents soumis par les clients, créent des correctifs si nécessaire et travaillent sur le backlog des défauts signalés par les utilisateurs. Le « développeur en support » en apprend plus sur la façon dont l'application est utilisée sur le terrain. En se tenant à la disposition de l'équipe opérationnelle, les équipes de développement instaurent la confiance et le respect mutuel.

Atlassian a créé Open DevOps pour les équipes qui cherchent à créer la chaîne d'outils de leur choix, avec les outils qu'elles aiment, grâce à des intégrations avec les principaux fournisseurs et les principales apps du Marketplace. Essayer maintenant.