Blog DevOps

Culture DevOps et méthode : définition et mise en place | Padok

Rédigé par Clément David | 30 juin 2019 22:00:00

Les grands principes du DevOps

Rapide rappel sur les fondements et les avantages d’une culture DevOps.

DevOps est la contraction des mots “Developpers” et “Ops”, mais vous le savez probablement déjà. La culture DevOps vise à casser la séparation entre les développeurs qui produisent de nouvelles fonctionnalités, et les Ops qui ont pour objectif la fiabilité du site. Des intérêts a priori antagonistes comme l’a illustré Andrew Shafer en 2008 lors d’une conférence avec un schéma devenu mondialement connu : “The wall of confusion”.

Le DevOps ou la culture du déploiement continu


L’objectif du DevOps est de casser cette barrière et le fonctionnement en silo. Cette collaboration passe par de nombreux moyens que nous allons aborder dans la suite de cet article, mais l’objectif est toujours le même : faire collaborer développeurs et Ops pour atteindre des objectifs communs.

L’objectif de cette collaboration, au final, est de mettre en place de nouvelles features plus rapidement, sans altérer la qualité. C’est ce qu’on appelle le déploiement continu. Cette idée est illustrée par un concept essentiel du DevOps, la “feedback loop” :

  • Je déploie mes features ;
  • Je les opère ;
  • Je récupère du feedback ;
  • Je corrige et déploie de nouvelles features.

Impossible donc de mettre en place une démarche DevOps si l’on n'est pas à l’écoute de l’utilisateur, et impliqué pour améliorer en continu les produits mis à sa disposition.

Où s’arrête le travail des développeurs, où commence celui des Ops ?


C’est l’éternelle question, à quel moment le domaine du développeur s’arrête-t-il pour laisser place aux missions de l’Ops ? Quelle que soit l’organisation mise en place, quels que soient les principes de collaboration, nous parlons de deux métiers différents. De deux stacks techniques différentes. Voici quelques moments où une distinction floue entre les 2 postes va vous jouer des tours :

  • La mise en production : lourde responsabilité, la mise en production risque d’impacter directement vos utilisateurs et votre business en cas d’incident. Le développeur a-t-il la responsabilité de son incrément ? L’Ops a-t-il la main car il est responsable de la stabilité ?
  • La qualité du code produit : l’Ops met à disposition du développeur des outils de test pour vérifier la qualité de son incrément. En revanche il ne faut pas déresponsabiliser le développeur “je balance mon code, l’Ops se débrouillera avec”
  • Le post-mortem : Chaque incident doit donner lieu à un post-mortem, on l’analyse et on prend des actions correctives. L’Ops run la plateforme, le développeur en a produit le code, qui doit tirer pour que cette résolution de problème ait lieu, et pour que les actions soient tenues ?

D’un point de vue technique, la question se pose aussi. Exemple : qui gère les variables d’environnement et comment faire pour qu’elles soient sécurisées mais n’impactent pas le flux de développement ?

Toutes ces questions doivent être tranchées. Chacun doit connaître son rôle, sa responsabilité. Les règles du jeu changeront au cours du temps, mais elles doivent rester claires et connues (acceptées) de tout le monde.

L’histoire du DevOps

La conférence de Shafter en 2008 marque le début du DevOps.

En 2009, la première conférence “DevOpsday” se tient en Belgique, à Ghent. Créée par Patrick Debois, consultant en organisation agile, elle se développe ensuite à l’international et continue à être un des piliers du monde du DevOps avec plus de 30 conférences programmées pour 2019.

En 2012, le premier rapport “State of DevOps” est produit par Alanna Brown de Puppet. Quelques mois plus tard, en 2013, “The Phoenix project” sort à son tour. Cette nouvelle raconte l’histoire d’un manager IT impliqué dans une situation qui semble désespérée.

Une des clés de sa réussite sera l’application des concepts lean et DevOps. Cet ouvrage va largement contribuer à la diffusion de la culture DevOps.

En 2019, selon IDC, la démarche DevOps est une tendance lourde de l’organisation IT mais le DevOps ne concerne encore que 20% des projets applicatifs. Selon les estimations, ce chiffre passera en 2021 à 35% voire 40%.

Les avantages du DevOps

Une démarche DevOps vous fera gagner du temps. Beaucoup de temps.

Petit exemple :

Sur le site d’e-commerce de l’un de nos prospects, certains produits étaient affichés en double. Il a fallu 19 jours-homme de travail aux équipes internes pour en trouver la cause : un cron s’exécutait à deux endroits différents mais touchait à la même base de données. Les Ops avaient l’info “où le cron tourne” et les développeurs l’info “que fait le cron”.

À partir du moment où les 2 équipes ont commencé à travailler sur ce bug dans la même pièce, il a été résolu en 2 heures...

D’une manière générale, le DevOps vous permettra :

D’accélérer les délais de lancement


Selon le rapport State of DevOps de 2016, les entreprises qui ont mis en place une organisation DevOps affichent une fréquence de déploiements 200 fois plus élevée et des délais de production 2 555 fois plus courts (entre la volonté de déployer et la mise en production).

De réduire les risques

Autant que la collaboration de toutes les parties, l’automatisation des processus va permettre de réduire les risques de défaillance. Un processus d’amélioration continue, clé en DevOps, permettra ainsi de rendre les déploiements de plus en plus fiables et fluides.

D’accélérer la réaction aux incidents

La démarche d’automatisation sous-tendue par le DevOps doit permettre de mieux réagir aux inévitables incidents. La bonne communication entre les développeurs et les Ops (comme dans l’exemple de notre client) facilitera aussi cette réaction.

D’augmenter la satisfaction de vos clients

Avoir des cycles de déploiement courts et mettre régulièrement en production de nouvelles features va mécaniquement améliorer la satisfaction de vos clients et votre adéquation au marché. Voir leurs retours pris en compte et le produit s’améliorer les valorise, règle leurs problèmes, et fait la différence avec la concurrence.

Comment mettre en place le DevOps dans son entreprise ?

Prévoir du temps dédié à la collaboration


Vos équipes de développement et vos Ops ont-ils un temps dédié à collaborer ? Ou est-ce une charge supplémentaire qui vient s’ajouter à la pression de leurs sprints ?  

Quelques exemples de manières dont on peut dédier du temps à cette collaboration, et faciliter l’implémentation d’une culture DevOps dans l’entreprise :

Tickets d’atelier conception :


La conception d’une nouvelle feature ou de l’ajout d’une nouvelle technologie doit faire l’objet d’une concertation en amont entre développeurs et Ops. Pour le faire proprement, ce workshop doit être pris en compte dans les sprints des 2 équipes sous la forme d’un ticket estimé. Sinon vous avez toutes les chances que ce soit fait à la va-vite entre 2 features, et vous le paierez après.

Temps de formation :


L’architecture conçue par vos Ops est-elle correctement utilisée par vos développeurs ? Le processus est-il simple pour eux, ou manquent-ils de connaissances techniques ? Surtout si le turnover est important dans vos équipes techniques, prévoir un temps de formation hebdomadaire sur les outils DevOps mis en place peut régler beaucoup de problèmes.

Tests utilisateurs :


Vous allez me dire “qu’est-ce qu’un test utilisateur vient faire dans le monde du DevOps ?”. Vous avez tort. Cette vision peut agacer, mais vos développeurs sont les utilisateurs des outils mis en place par vos Ops, autant vérifier que ces outils sont pratiques et répondent à leurs besoins.

Avoir des objectifs communs


Une autre manière de permettre à vos Ops et à vos développeurs de travailler ensemble est de leur fixer des objectifs communs. Cela crée un cercle vertueux où les réussites des uns sont les réussites des autres, et où tout le monde a intérêt à collaborer. Il faut alors fixer des objectifs avec 2 mesures, une venant des objectifs “naturels” des développeurs, et l’une venant du monde des Ops.

Si vous fixez un objectif “brandé” Ops, du type “la plateforme est disponible à 99,9%”, vous pouvez être certain que vos Ops vont partir en croisade contre les développeurs qui viendront mettre cet objectif en péril avec leur volonté de mettre des features en production.

Peu importe à quel point vous essayez d’onboarder vos Ops sur la roadmap de développement, vous avez créé une culture où l’infrastructure domine l’application. Fixez un objectif de delivery, et vous obtiendrez le processus inverse avec une obsession de la livraison chez les développeurs qui rendra la vie de vos Ops infernale.

Exemple d’objectif : 1 mise en production par semaine avec 0 downtime de l’application

À vous de gérer la reconnaissance et la célébration que vous mettez en place pour motiver vos troupes, on entre alors plus dans le domaine du management. Mais gardez en tête que vous posez ainsi les bases d’une collaboration DevOps saine et efficace.

Développer la culture client chez les Ops


C’est un peu iconoclaste, mais une équipe Ops est une équipe support, transverse, qui a donc ses propres utilisateurs. En interne, pour une bonne partie de ses tâches, une équipe Ops a des “clients”. Il faut développer dans votre équipe infrastructure une culture du service client :

  • Comprendre les problèmes des développeurs
  • Adapter les solutions à leurs besoins
  • Prendre en compte leurs feedbacks

Cela nécessite une vraie dose d’humilité, et c’est un changement d’état d’esprit qui sera très difficile à mettre en place dans bon nombre d’entreprises où la culture DevOps n’est pas encore bien implémentée. Il ne faut pas non plus tomber dans un mode de communication dictatorial et malsain où les développeurs se servent de cette étiquette de “client” pour dominer l’équipe Ops.

Mais développer une culture du service et de la satisfaction client dans votre équipe Ops vous permettra d’améliorer la qualité, la vitesse de vos livraisons, et la communication entre vos Ops et vos développeurs.

Nous vous donnions dans un précédent article les différentes étapes afin d’aligner vos Dev et vos Ops, afin d’avoir une culture DevOps parfaitement implémentée au sein de votre entreprise.

Relation entre le DevOps et les autres approches organisationnelles

Agile : Le DevOps est souvent vu comme une manière d’appliquer l’agilité au monde de la production. Les méthodes agiles appliquées au développement permettent de réduire la distance entre les besoins utilisateurs et l’équipe de développement. Le DevOps peut être considéré comme venant en complément, permettant à l’équipe de développement de mettre rapidement en production les nouvelles fonctionnalités.

Nous avons rédigé un précédent article traitant un peu plus en détail de la culture DevOps et surtout de comment l’adapter à une méthodologie Agile.

ArchOps : Extension du DevOps en partant de l’architecture logicielle et non du code pour les opérations de déploiement.

DataOps : Application du déploiement continu et du DevOps à l’analyse de données. DataOps cherche à intégrer le data engineering, la data intégration, la sécurité des données et la privatisation des données avec les opérations (Ops).

Site Reliability Engineer (SRE) : le Site Reliability Engineering est une approche développée par Google depuis 2003, dans le but de déployer de nouvelles fonctionnalités en continu tout en maintenant un haut niveau de qualité et de disponibilité de l’infrastructure. DevOps et SRE reprennent des problématiques largement similaires.

WinOps : WinOps est le terme utilisé pour les pratiques DevOps centrées autour de l’environnement Windows

En 2019, la démarche DevOps était intégrée dans 20% des projets applicatifs en France. En 2021 les prévisions montent à 40% de projets reprenant cette organisation. Il y a encore bien des choses à dire sur la culture DevOps, mais ce rapide panorama vous permettra de poser les premières bases de cette collaboration dans votre entreprise. Si vous souhaitez plus d’informations, n’hésitez pas à parcourir nos autres articles ou à nous poser des questions sur le DevOps !