Le DevOps est souvent associé à l'acronyme CALMS désignant les 5 piliers de cette méthodologie, qui sont :
Culture ;
Automatisation ;
Lean ;
Mesure ;
Share.
Dans ce chapitre, nous allons découvrir ensemble à quoi correspond chacun de ces mots, et quelles sont les pratiques qui y sont associées.
Culture
Le DevOps résout, en premier lieu, des problèmes humains, des problèmes de communication et des problèmes de responsabilités entre équipes. Dans ce sens, le DevOps se rapproche de l'agilité, mais en incluant d'autres équipes comme les opérations, les testeurs, les designers, les développeurs, les chefs de projet, et en règle générale, toute personne dont les aptitudes sont requises afin de délivrer un produit de qualité.
En résulte alors une équipe orientée produit, avec toutes les aptitudes requises afin de délivrer la meilleure application et la meilleure expérience possibles, et non plus des équipes éparses regroupées par silos de compétences. Ces équipes œuvrent pour un but commun, et partagent un plan pour l'atteindre. Un des moyens pour atteindre ce genre d'équipe est d'inclure par exemple les opérations aux Daily Meetings, les réunions quotidiennes et rapides de l'équipe, afin que ceux-ci puissent exposer leur problématiques, et que ces problématiques soient incluses dans les différents sprints. La réciproque est aussi vraie, les opérations peuvent faire appel à des développeurs, afin que ceux-ci puissent les aider à résoudre leur problèmes.
Toutes ces pratiques partagées entre développeurs et opérations rendent la gestion du déploiement et la résolution de problèmes beaucoup plus efficaces ! Ce processus est appelé la pollinisation croisée. Un bon moyen de savoir si la culture DevOps est bien implémentée est de se poser des questions comme :
Est-ce que les problèmes sont résolus par toute l'équipe produit ?
Est-ce que tous les membres de l'équipe partagent une vision commune ?
Est-ce que les post-mortem sont dirigés vers la résolution des problèmes et non vers la détermination d'un responsable de l'erreur ?
Si la réponse à ces 3 questions est oui, alors il est fort probable que votre équipe ait adopté la culture DevOps ! C'est ce qu'on appelle la culture des responsabilités partagées.
J'ai l'habitude de dire qu'aller prendre un verre après le travail entre équipes dev et ops est une très bonne pratique DevOps, car elle renforce le sentiment de travailler dans la même équipe et pour un but commun. C'est aussi un moyen de mieux connaître les personnes. Ainsi, lorsqu'un problème survient, il est plus facile d'aller voir la personne pour résoudre le problème et travailler avec elle, que de créer un ticket dans un outil quelconque, et d'attendre que celui-ci soit résolu par quelqu'un.
Automatisation
Voyons ensemble les avantages qu'apporte l'automatisation.
Déployez plus fréquemment
Les applications sont déployées plus souvent. Cela amène à être rassuré sur la procédure de déploiement. Généralement, les entreprises sont amenées à ne déployer que quelques fois dans l'année, alors que des entreprises comme Google, Amazon et Facebook, qui sont souvent prises en exemple sur l'automatisation, peuvent déployer jusqu'à 17 fois par minute en production.
L’une d’entre elles est le déploiement bleu/vert, qui consiste à maintenir deux serveurs, un « bleu » et un « vert ». Un seul de ces serveurs répond aux requêtes publiques et joue donc le rôle d’environnement de production (disons le serveur bleu). L’autre serveur (ici, le serveur vert) est un environnement de test sur lequel les modifications sont déployées. Une fois que le dernier déploiement réalisé sur le serveur vert a réussi les tests, les rôles s’inversent. Les requêtes publiques sont routées vers le serveur vert, qui devient donc le serveur de production. Cette méthode de déploiement permet de revenir rapidement à un état antérieur en cas de problème.
Configurez vos déploiements automatiquement
Les configurations sont gérées automatiquement par les outils. Dans les entreprises dites traditionnelles, les développeurs rédigent souvent un manuel de déploiement sous Word, à destination des équipes d'exploitation, expliquant comment déployer les logiciels et les configurer.
À cause de ce fameux mur de la confusion, et du manque d'interaction entre les équipes de dev et les ops, les paramètres de configuration sont souvent envoyés par mail, ou écrits dans le document d'exploitation. Il est alors facile de se tromper lors du déploiement d'une application, en ayant oublié une étape ou l'exécution d'un script, et de se retrouver avec un système fonctionnant mal ou ne fonctionnant pas du tout. De plus, l'erreur étant humaine, il est souvent difficile de bien paramétrer l'application en écrivant les bons paramètres de configuration.
Tous ces problèmes conduisent à la situation citée précédemment, c'est-à-dire à ne déployer que quelques fois dans l'année, de peur de ne plus voir le système fonctionner.
Les mises en production se font aussi, souvent, en dehors des plages d'heures ouvrées, ou le week-end, pour éviter d'impacter les utilisateurs. Grâce à l'automatisation, ce déploiement peut se faire durant les heures ouvrées, réduisant le stress des équipes d'ops.
Créez des environnements à la demande
La création d'environnements se fait à la volée. En utilisant des outils d'Infrastructure-as-Code, il est possible de créer à la demande des environnements pour tester et déployer les applications, ce qui réduit notamment les temps d'attente liés à la fourniture d'environnements hors production.
Par exemple, au lieu d'attendre qu'une équipe de production vous fournisse un environnement en quelques jours, voire quelques semaines, la création d'un environnement est quasi immédiate (comprendre quelques dizaines de minutes, voire quelques minutes). Il sera alors possible de créer autant d'environnements que nécessaire, afin de faciliter les tests, mais aussi les différentes cérémonies agiles.
Ces environnements étant codifiés et versionnés, il est alors facile de recréer le même environnement rapidement. Afin d'économiser de l'argent, il est d'usage de complètement détruire l'environnement, une fois que celui-ci ne sert plus à rien.
Dans la grande entreprise française pour laquelle j'ai travaillé, avec l'utilisation d'Infrastructure-as-Code, j'ai pu reproduire à l'identique plusieurs types d'environnements, tout en faisant économiser de l'argent à l'entreprise. En effet, afin de pouvoir assurer nos tests, il existait un environnement qui était allumé en permanence durant le mois, et donc facturé à l'équipe pour un mois complet. De plus, lors de l'utilisation de cet environnement, il était indisponible pour d'autres types de tests, ce qui est problématique lorsque plusieurs utilisateurs finaux veulent tester en même temps les dernières fonctionnalités.
Avec l'Infrastructure-as-Code, j'ai pu non seulement créer trois environnements parfaitement identiques, les livrer aux utilisateurs finaux afin que ceux-ci puissent faire leurs tests, mais en plus économiser de l'argent en détruisant rapidement les environnements inutiles.
Testez plus fréquemment
Les tests peuvent être lancés plus souvent. Même si l'utilisation de techniques comme le Test-Driven-Development ou le Behavior-Driven-Development permettent de maximiser les tests unitaires, dont la rapidité d'exécution permet d'avoir un résultat en quelques minutes, il est souvent nécessaire de pousser plus avant certains types de tests, comme les tests de performance, les tests de charge ou même les tests de bout-en-bout.
Sur ces types de tests, il est nécessaire d'avoir un environnement configuré correctement pour simuler des contraintes de production, ou des chaînes complètes entre applications. Comme les tests et l'infrastructure sont versionnés au même niveau que le code, tout changement de l'une de ces trois briques (tests, infrastructure et code) relance automatiquement toute la chaîne dans un processus complet. Dès lors, il est facile de rejouer des campagnes de tests de non-régression complète en quelques minutes, ou en quelques heures si la chaîne de bout en bout couvre une grande partie des fonctionnalités.
Lean
Évitez le gaspillage avec le Lean
Les types de gaspillage sont au nombre de 7 :
surproduction ;
attente ;
transports ;
étapes inutiles ;
stocks ;
mouvements inutiles ;
corrections / retouches.
Dans le contexte du DevOps, Lean va alors s'intéresser à délivrer de la valeur ajoutée au client final (dans le cadre d'une application grand public, le public), tout en minimisant les processus longs, coûteux, sans valeur ajoutée. Dans un sens, le Lean de DevOps se rapproche de l'agilité, avec des concepts d'amélioration continue et d'acceptation des erreurs. Le mot japonais Kaizen résume très bien cet état d'esprit. Il veut littéralement dire "changement" (kai) et "meilleur" (zen). Mais attention à ne pas rogner sur la qualité de l'application, en sautant des étapes de l'intégration continue, afin de faire des économies sur les environnements !
Maîtrisez la chaîne de valeur avec la VSM
Si je reviens sur l'implémentation du DevOps chez Contoso, la création d'une VSM a fait ressortir que la création et la fourniture d'environnements représentaient l'étape du processus la plus longue, l'attente pouvant être de plusieurs semaines. Durant cette attente, les développements étaient stoppés, et la mise en production retardée. L'utilisation de l'Infrastructure-as-Code a fait baisser cette attente de plusieurs semaines à quelques heures, voire quelques minutes. Vous avez ici une bonne idée de l'intérêt de créer une VSM dans votre entreprise, ainsi que d'avoir une démarche Lean dans votre quotidien.
Une personne ayant un état d'esprit DevOps va alors avoir l'opportunité de faire de l'amélioration continue dans ses processus un peu partout. Par exemple, implémenter des rétrospectives ou des post-mortem est un bon moyen d'améliorer les processus et l'équipe, en identifiant ce qui n'a pas fonctionné lors d'un développement ou d'un déploiement, et en essayant de le faire disparaître.
Les erreurs sont inévitables ! Si je reprends la phrase de Werner Vogels, le CTO d'Amazon Web Services, "Everything fails all the time" ("Tout échoue tout le temps"). Ça peut être un serveur qui redémarre de façon intempestive, le réseau qui ne fonctionne plus, ou tout simplement un déploiement qui s'est mal déroulé, à cause d'une erreur humaine. Il est alors important dans le DevOps de ne pas reprocher à quelqu'un le problème de déploiement, mais plutôt d'encourager l'équipe à parler librement lorsqu'une erreur arrive, afin d'identifier celle-ci, ses causes et mettre en place un processus garantissant la non-reproduction de cette erreur. Certaines personnes appellent cette idée être "antifragile".
Mesure
Heureusement, il existe une multitude d'outils sur le marché pour juger de la performance d'une application, ou d'une transformation. Par exemple, ces indicateurs sont souvent utilisés dans des domaines comme le webmarketing, où le taux de conversion des personnes est utilisé afin de savoir comment la campagne marketing s'est déroulée.
Si je reprends mon exemple d'Amazon, il faut savoir que le site stocke absolument toutes sortes de données. Cela sert à Amazon pour voir si leurs développements sont meilleurs qu'avant ; par exemple, en calculant le taux de conversion grâce à un nouvel algorithme de Machine Learning. Mais cela a aussi un impact direct sur leur business. En effet, 100 millisecondes perdues sur l'affichage de la page d'accueil chez Amazon leur fait perdre 1 % de leur chiffre d'affaires ! Sur des systèmes financiers par exemple, si la latence de l'application est plus longue de 5 millisecondes, cela peut faire perdre des millions d'euros à des plateformes d'échange.
Les différents indicateurs utilisés peuvent être :
Combien de temps la nouvelle fonctionnalité a pris pour passer du développement à la production ?
Combien de fois un bug récurrent apparaît ?
Combien de personnes utilisent le produit en temps réel ?
Combien d'utilisateurs a-t-on gagnés ou perdus en une semaine ?
Ces indicateurs sont aussi utiles en entreprise, afin de pouvoir challenger les métiers sur la priorisation du backlog.
Par exemple, si un Product Owner permet de montrer factuellement que le métier a dépensé 100 000 euros dans une fonctionnalité qui n'est utilisée qu'une fois par mois, n'aurait-il pas mieux fallu dépenser cet argent dans une fonctionnalité utilisée beaucoup plus souvent, et donc économiser du temps de traitement sur l'application ?
Nous allons voir dans la suite du cours que ces mesures sont très importantes pour définir des KPI comme le SLA (Service Level Agreement), pour n'en citer qu'un.
Sharing (Partage)
Si les développeurs commencent, grâce à cette politique, à savoir comment opérer de manière optimale et à connaître le métier des opérations, il seront plus enclins à aller aider l'exploitant de l'application. Cela ne veut pas dire que chaque développeur doit être un exploitant excellent ! Mais que les opérations et les développeurs doivent travailler de concert sur le cycle de vie complet de l'application.
Les équipes mettant en place le DevOps ont souvent un rôle tournant : les développeurs corrigent les problèmes des utilisateurs finaux, mais aussi participent à la résolution des problèmes de production. Ces développeurs répondent à des problèmes urgents, créent des patches pour résoudre rapidement les problèmes si nécessaire, et corrigent tous les bugs remontés par les utilisateurs. Les développeurs apprennent comment leur application est utilisée au quotidien par les utilisateurs finaux. En se rendant disponibles auprès des équipes des opérations, les développeurs construisent une relation de confiance avec eux, ainsi qu'un respect mutuel.
En résumé
Ça y est, vous en savez un peu plus sur ce qu'est le DevOps, et quels sont ses 5 piliers. Résumons-les à nouveau :
Culture : le DevOps est une affaire de culture d'entreprise entre les dev et les ops, avant d'être un ensemble d'outils ou même de pratiques métier. Il faut que les dev et les ops travaillent ensemble, aient une vision commune, soient tournés vers les mêmes objectifs.
Automatisation : tout ce qui peut être automatisé doit l'être ! Ceci se fait par des déploiements programmés et fréquents, des environnements créés à la demande et des tests automatisés.
Lean : dans la méthodologie DevOps, concentrez-vous sur la création de valeur et limitez le gaspillage de ressources. Pour cela, utilisez la Value Stream Map pour maîtriser votre chaîne de valeur.
Mesure : Afin de tout automatiser et tout optimiser, il faut mesurer tout ce que vous faites. Pour ça, mettez en place les KPI nécessaires pour superviser vos déploiements !
Sharing : Dans le DevOps, les équipes de dev et d'ops partagent des moments et les responsabilités. C'est le cœur de l'objectif du DevOps !
Dans le prochain chapitre, nous allons voir quelques bonnes et mauvaises pratiques d'implémentation du DevOps en entreprise.
