Qu'est-ce que le DevOps ? L'article pour tout savoir

Rédigé par Katia HIMEUR le 10/04/2023
Temps de lecture: 14 minutes

1. Introduction

Cela fait plusieurs années que j’ai la chance d’évoluer dans le domaine du cloud et du DevOps. Et en tant que consultante, j’ai eu l’occasion d’échanger avec de très nombreuses personnes dans des contextes tous différents sur le sujet. À la question, qui pourtant parait simple : dis-moi ce qu’est le DevOps ?, je me suis rendue compte que nous n’avions pas toutes et tous la même réponse.

Il faut dire aussi, que pendant un certain temps, ce mot-là était LE buzz word du moment. Et sa popularité n’a de cesse de grandir. Le mot “DevOps” est depuis décliné à toutes les sauces. Amenant un peu plus de confusion à la situation.

Que cela soit lors d’ateliers d’acculturation DevOps que je mène ou lors de discussions informelles, je fais souvent la même réponse lorsque l’on me retourne la question. J’ai donc décidé d’en faire un article pour pouvoir le partager au plus grand nombre. Même s’il est impossible de résumer dans un article tout ce qui touche au DevOps, mon objectif est de donner les clés pour comprendre ce que c’est et de pouvoir savoir par où commencer.

Dans ce qui suivra, je traiterai des événements qui ont mené à la naissance du DevOps tout en définissant ce mot et en donnant les clés pour pouvoir l’adopter et se l’approprier au sein de son organisation.

2. Le mur de la confusion

Traditionnellement, les déploiements en production étaient réputés longs et fastidieux. Mais surtout, peu fréquents. Les équipes étaient organisées en silo avec les équipes de développement d’un côté et les équipes opérationnelles de l’autre.

Des équipes de développement, nous attendons habituellement de la vélocité : livrer rapidement de nouvelles fonctionnalités, tenir à jour la base de code et être à la pointe de ce qui se fait en termes de technologies.
Et des équipes opérationnelles, nous attendons la stabilisation, le maintien en condition opérationnelle de la production et une maitrise des changements.

Cette différence entre les besoins et les attentes engendrent souvent des frictions entre ces équipes. D’autant plus quand les personnes qui constituent ces équipes n’utilisent pas les mêmes outils ni le même vocabulaire, cela mène forcément à de l’incompréhension. Nous parlons alors du fameux mur de la confusion. Concept popularisé par Andrew Clay Shafer à partir de 2009.

Mur de la confusion - DevOps

Capture d’écran issue d’un talk d’Andrew Clay Shafer

Ce schéma de fonctionnement, que l’on retrouve encore aujourd’hui dans de nombreuses organisations, tend les relations et surtout dessert les équipes et les projets. Ce qui a amené de nombreuses personnes à chercher des moyens et des solutions pour contrer ce mode de fonctionnement dans l’intérêt des projets.

3. 2003 : Naissance du Site Reliability Engineering chez Google

Bien avant la naissance du mouvement DevOps, Google a fait face à de nouveaux grands défis techniques. Pour se remettre dans le contexte de l’époque, en 2003, l’entreprise fêtait ses 5 ans et son moteur de recherche comptabilisait trois cents millions de requêtes par jour. Cette année, Google recrute Ben Treynor Sloss, pour prendre la responsabilité, entre autres, de l’infrastructure globale de production de l’entreprise. Pour gérer cette infrastructure mondiale et assurer sa très haute disponibilité dans un contexte à très fort trafic, il décide de créer la toute première équipe de Site Reliability Engineering (SRE) ou Ingénierie de la fiabilité des sites. Son objectif : intégrer les principes d’ingénierie logicielle à la gestion des infrastructures afin d’avoir des systèmes évolutifs, fiables et résilients.

Mur de la confusion - DevOps

Ben Treynor Sloss définit le SRE comme suit :

Fundamentally, it’s what happens when you ask a software engineer to design an operations function.

Définition que l’on peut traduire par

“Fondamentalement, c’est ce qui se produit lorsqu’on demande à un·e ingénieur·e logiciel de concevoir une fonction d’exploitation.

Dès 2003, nous voyons que Google a appliqué les principes du monde du développement logiciel à la gestion des infrastructures. Et depuis, de nombreuses entreprises lui ont emboitées le pas.

4. 2007 : Agile system administration

En 2007, Patrick Debois, ingénieur belge, est administrateur de bases de données dans une entreprise. Il a pour mission de tester un grand projet de migration de data centers. Les grandes frictions entre les équipes de développement et les équipes opérationnelles le poussent à chercher des solutions pour améliorer ces relations, dans l’intérêt du projet. Membre de la communauté agile, il décide d’appliquer les approches agiles du monde du développement, à la gestion des infrastructures. Il décide d’appeler son approche : Agile system administration

5. 2008 : Agile 2008 Conference

Lors de la conférence Agile 2008 au Canada, Andrew Clay Shafer, alors développeur logiciel, doit donner un talk appelé “Agile infrastructure”. Patrick Debois, présent à cette conférence, était ravi de découvrir qu’une personne a eu les mêmes problématiques liées à la gestion des infrastructures. Et que cette dernière a décidé d’appliquer la même approche issue du monde de l’agilité. Il allait donc assister au talk d’Andrew. Sauf qu’entre temps, Andrew a décidé d’annuler sa session, du fait des mauvais retours qu’il a eus en amont. Patrick Debois va tout de même à sa recherche et entame une longue discussion avec lui. Ils garderont contact et continueront d’échanger sur le sujet plusieurs mois durant.

Logo de la conférence Agile 2008

6. 2009 : Agile System Administrators & AgileRoots 2009

Quelques mois après leur première rencontre, Patrick Debois et Andrew Clay Shafer créent un groupe de discussion Google nommé Agile System Administrators. Plusieurs personnes rejoignent ce groupe, constituant ainsi une communauté, qui pendant plusieurs années, va échanger autour des apports de l’agilité à la gestion des infrastructures. Nous y trouverons notamment des contributions de John Allspaw, que l’on présentera plus tard. Si vous souhaitez parcourir ce groupe, c’est par ici : Google group Agile System Administrators

Cette même année, Andrew Clay Shafer finit par donner son talk “Agile Infrastructure” lors de l’événement AgileRoots 2009. D’ailleurs, lorsque l’on lit son abstract, nous voyons qu’il est toujours d’actualité :

Storage, network and computational resources are becoming API driven. Configuration management tools provide another level of automation and semantics to the systems. As these tools evolve the exercise of building systems looks more and more like software development. Further, when developing web applications, the application is the infrastructure. If the servers are down, there is no application. The value of the application is tied to the systems. Treating the systems and application holistically, encouraging communication and collaboration between dev and ops is the path to true artisanal retro-futurism ⊗ team-scale anarcho-syndicalism.

Les sources de ce talk sont ici :

7. Juin 2009 : 10 + Deploys per Day : Dev & Ops Cooperation at Flickr

Cette célèbre conférence donnée par John Allspaw et Paul Hammond pendant l’événement Velocity 2009 a véritablement marqué les annales.

Pour se remettre dans le contexte de l’époque, ce mois de juin 2009, au moment où la conférence fut donnée, Flickr, racheté par Yahoo quelques années auparavant, est le plus grand site de partage de photos au monde. Sa base était constituée de trois milliards de photos. Et chaque seconde, 40 000 nouvelles photos étaient téléchargées.

Durant ce talk, nous y apprenons, comment dans ce contexte à très fort trafic, Flickr réussissait à déployer en production plus de 10 fois par jour. Avec un gros plan sur comment les équipes OPS et les équipes DEV collaboraient pour réussir à atteindre cet objectif. Cela tranchait nettement avec les usages répandus dans l’IT à ce moment-là.

En plus de la collaboration entre les devs et les ops et la culture, d’autres outils utilisés sont cités : l’automatisation des infrastructures, les feature flags, les tests, les dark launches…

D’ailleurs, il est dit que Patrick Debois a suivi cette conférence à distance. À la suite de cela il a décidé de créer la première conférence Devopsdays et que c’est de là que vient l’inspiration du mot DevOps.

Pour en savoir plus sur cette conférence :

8. Octobre 2009 : Création de la première conférence Devopsdays

À la suite de l’événement Velocity 2009, Patrick Debois décide d’organiser son propre événement dans son pays d’origine, la Belgique, pour parler de l’agilité dans la gestion des infrastructures. Il appelle cet événement le Devopsdays. Il tirerait son inspiration de la conférence de Flickr.

Depuis la première édition qui s’est tenue à Gand, en Belgique, plusieurs autres éditions ont eu lieu chaque année dans plusieurs villes du monde.

Le succès des Devopsdays n’a cessé d’augmenter et a contribué à populariser le mouvement DevOps, le rendant incontournable aujourd’hui.

Ces devopsdays continuent de se tenir jusqu’à aujourd’hui. Pour en savoir plus https://devopsdays.org/

9. Mais alors, qu’est-ce que le DevOps ?

On l’aura bien compris, le mot DevOps, est issu de la concaténation des premières lettres des deux mots developper et operational. Il s’agit d’un framework culturel qui permet aux différentes équipes de collaborer plus efficacement.

Si initialement DevOps visait à rapprocher les équipes de développement et les équipes opérationnelles. Aujourd’hui, il s’adresse à l’ensemble des actrices et acteurs du cycle de vie des logiciels : devs, ops, QA, équipes produit, équipes commerciales…

Les objectifs du DevOps sont : la réduction du Time to market et l’amélioration de la fiabilité des produits.

10. Quels sont les avantages du DevOps pour une organisation ?

Adopter la culture DevOps au sein de son organisation permet aux entreprises de rester compétitives et de renforcer leurs innovations : plus vite de nouvelles fonctionnalités sont livrées, plus vite les retours clients sont collectés.

De plus, les pratiques DevOps aident à détecter et à résoudre les bogues et les problèmes beaucoup plus rapidement. Elles permettent aussi d’augmenter la fiabilité et la résilience des systèmes et, par la même occasion, réduire les temps d’indisponibilité.

11. Les anti-patterns du DevOps ?

Anti-pattern 1 : l’équipe DevOps

DevOps n’est pas une équipe d’Ops ni une équipe entre les devs et les ops. J’ai rencontré cet anti-pattern plusieurs fois : nous ne pouvons pas casser les silos et rapprocher les équipes en ajoutant une troisième équipe au milieu. Et nous ne pouvons pas dire d’une équipe qu’elle est “DevOps”, simplement, car elle est sur le cloud ou qu’elle utilise certains outils.

Anti-pattern 2 : Essentialisation du DevOps aux outils

Le DevOps n’est ni un outil de CI/CD, ni un autre outil d’automatisation, ni même la conteneurisation. Il faut faire très attention à ne pas essentialiser le DevOps aux outils. Les outils doivent rester un moyen d’atteindre des objectifs et ne doivent pas devenir l’objectif. De nombreuses personnes pensent adopter la culture DevOps, en adoptant les outils qui sont dits “DevOps” sans rien changer d’autres. Ce qui peut générer des déceptions ou des frustrations.

DevOps n’est pas les outils, mais la manière de les utiliser. Il est donc bien important de questionner les usages que nous en faisons. Nous ne sommes nullement obligé de changer tout l’outillage déjà mis en place.

Landscape des outils CNCF

Landscape des outils CNCF

Anti-pattern 3 : DevOps, le mouton à 5 pattes

Le mouton à 5 pattes, aka l’ingénieur(e) DevOps, Dev et Ops fullstack, qui doit savoir tout faire. Il est vrai que ce titre de poste ne fait clairement pas l’unanimité, même si de nombreuses offres d’emploi existent. DevOps étant une culture, il est compliqué d’être ingénieur(e) d’une culture. Et il ne suffit pas d’avoir un profil dit “DevOps” pour dire d’une organisation qu’elle est DevOps.

12. Indicateurs clés de performance pour mesurer sa démarche DevOps

Avant de se lancer dans un chantier de transformation DevOps, il est très important de dresser un état des lieux pour pouvoir se fixer des objectifs mesurables et atteignables.

Ci-dessous, les principaux indicateurs clés de performance que nous pouvons mesurer :

  • Mean Time Between Failure (MTBF) : Temps entre chaque incident en production.
  • Mean Time Between Repair (MTBR) : Temps nécessaire pour rétablir les services après un incident.
  • Availabilty : Formule pour calculer la disponibilité des services: MTBF/(MTBF+MTTR)
  • Mean Time to detect : Temps moyen de détection des problèmes qui peuvent survenir en production.
  • Lead Time : Temps nécessaire pour qu’un commit soit déployé en production.
  • Time to market (TTM) : Temps entre la naissance d’une idée et sa mise en production.
  • Fréquence des déploiements
  • Durée des déploiements
  • Pourcentage de mise en production générant des incidents.

13. Comment atteindre ses objectifs dans le cadre d’une transformation DevOps ?

Maintenant que nous avons compris ce qu’était le DevOps, nous pouvons définir des objectifs mesurables à atteindre. Pour pouvoir amorcer sa transformation DevOps, nous allons pouvoir s’appuyer sur un ensemble d’outils et de concepts.

Disclaimer : La liste ci-dessous n’est pas exhaustive et n’est absolument pas obligatoire pour amorcer une transformation DevOps. Il n’y a aucun outil magique ni aucune obligation de changer ses outils. Il faut garder en tête que l’important, reste l’usage que nous en faisons.

a. La collaboration

L’un des premiers piliers du DevOps, c’est la collaboration. Et il faut s’assurer que les personnes collaborent aussi bien intra-équipe qu’interéquipe. Il existe de nombreux moyens d’améliorer la collaboration : communication, transparence, pair programming, documentation, le partage de connaissances

Lorsque nous voulons améliorer la collaboration entre les différentes personnes actrices du cycle de vie d’un produit, il est primordial de toujours garder en tête la diversité des profils (parcours différents, expériences différentes, personnes issues de reconversion…) pour apporter des solutions pertinentes.

b. Les feedbacks

Si nous voulons nous inscrire dans une démarche d’amélioration continue, il est important de savoir faire des retours régulièrement. Ces retours peuvent aussi bien être faits dans le cadre d’évaluations individuelles ou bien de rétrospectives de projets ou de postmortems. C’est un excellent moyen de dégager les points positifs sur lesquels il faudra capitaliser et les axes d’amélioration sur lesquels il faudra travailler.

Les feedbacks ne doivent pas non plus être unidirectionnels.

c. L’automatisation

L’automatisation, dans une démarche DevOps, consiste à s’appuyer sur des outils et des concepts technologiques pour réduire les interventions humaines et accélérer le développement et le déploiement. Elle permet de disposer de process reproductibles, cohérents, documentés, résilients et auditables.

L’automatisation offre de nombreux avantages :

  • Maitrise des actions et des résultats, en réduisant les risques d’erreurs.
  • Gain de temps et de productivité
  • Résilience des infrastructures
  • Réduction des coûts
  • Réduction des temps d’indisponibilité

L’automatisation n’est pas la mécanisation. Il ne s’agit pas de mettre dans un script toutes les actions qui sont d’habitude exécutées manuellement. Il s’agit de s’appuyer sur des concepts et des outils qui permettent de réduire la complexité dans la gestion des infrastructures.

Ci-dessous, une liste d’approches et d’outils qui permettent d’automatiser les process et les déploiements efficacement :

CI/CD

  • Continuous Integration (Intégration continue) : Intégration des modifications de façon régulière à sa base de code avec exécution automatisée des tests. L’objectif est d’introduire des changements plus petits afin de détecter plus rapidement les bugs et les régressions.
  • Continuous delivery (Livraison continue) : C’est l’étape qui suit l’intégration continue. La livraison continue permet de s’assurer que le code est testé, livré et est prêt à être déployé.
  • Continuous Deployment (Déploiement continu) : C’est l’approche d’ingénierie logicielle qui vient après la livraison continue. C’est un processus de déploiement automatisé des modifications, où les risques d’introduire des bugs ou des pannes est fortement réduits grâce aux tests et aux validations automatiques.

Infrastructure as Code (IaC)

L’infrastructure as code est le fait de gérer son infrastructure avec du code. C’est un moyen d’automatiser le management des infrastructures, en ayant la possibilité, notamment, d’intégrer ces process dans des workflows de CI/CD. Cette approche permet de faciliter la reproductibilité d’environnements afin de disposer d’environnements de tests et de validation ISO à la production.

Il existe de nombreux outils d’infrastructure as code : Terraform (le plus connu et le standard du marché), Pulumi(lire l’article pour en savoir plus)…

Conteneurisation

La conteneurisation est un mécanisme de regroupement logique qui va permettre de regrouper une application et ses dépendances afin de la rendre portable. La conteneurisation n’est pas obligatoire lorsque nous souhaitons transformer son organisation. Cependant, elle offre un avantage indéniable qui est celui de disposer d’un environnement isolé et prévisible, et cela, dès le poste de développement.

La conteneurisation est aujourd’hui un standard du marché et permet d’exploiter au maximum les avantages du Cloud.

d. Observabilité

L’observabilité est la capacité de connaître l’état d’un système, à partir de données de sortie. Elle s’appuie sur trois piliers : les métriques, les logs et les traces.

Grâce aux outils et aux techniques d’observabilité, nous allons pouvoir disposer d’indicateurs de pannes, de détecter les états indésirables du système et disposer d’éléments factuels pour améliorer sa fiabilité.

e. Sécurité

La sécurité est un des piliers du DevOps. Elle doit être intégrée dans le cycle de vie des applications dès la phase de conception. Il existe de nombreux moyens et outils pour garantir la sécurité de son système. En ce qui concerne les tests de sécurité, de nombreux outils permettent d’intégrer leurs exécutions dans les workflows de CI/CD afin d’automatiser leurs exécutions.

14. Conclusion

Lorsque nous voyons les événements qui ont mené à la naissance du DevOps, nous comprenons combien ce mouvement est lié à l’agilité. Les outils permettent d’accélérer la transformation DevOps d’une organisation, mais le DevOps est avant tout et surtout une histoire de collaboration, de process et de culture.

Il n’existe pas de roadmaps ou d’outils “DevOps” prêts à l’emploi et utilisables de la même manière partout tels quels. Il existe des organisations, des contextes, des personnes et des problématiques différentes. Le tout et de bien définir ses objectifs, de les mesurer et d’ensuite, adapter ses process et choisir les outils adéquats, lorsque cela est nécessaire.

Je finirai par dire, que DevOps est une question d’amélioration et d’optimisation en continu. Que cela doit devenir un fil conducteur qui permet d’accélérer et de fiabiliser ses services et ses produits. Et qu’il faut garder en tête, que c’est, avant tout, une histoire de bon sens et d’humain.