Méthode DevOps : comment aligner vos Dev et vos Ops ?

La culture DevOps en quelques mots

La culture DevOpsrepose sur le principe suivant : casser les silos entre les Dev et les Ops en montant une vraie feature team (ou équipe fonctionnelle), pour raccourcir au maximum les cycles de release.

Qu’est-ce qu’une vraie équipe fonctionnelle ?

L’équipe classique, dans un projet tech, comprend généralement les rôles suivants : un Product Owner, un/des développeur(s), et un UX. Les “Ops” (opérationnels), garants de la stabilité et de la disponibilité des applications, ont alors leur propre équipe séparée. Dans la culture DevOps, l’Ops est inclus dans l’équipe produit. C’est ce que l’on nomme une équipe fonctionnelle, car elle est autonome pour produire ses fonctionnalités. De la conception à la mise en production.

Qu’est-ce qu’un bon cycle de release ?

Une équipe agile performante peut réaliser des sprints d’une semaine et déployer tous les jours des fonctionnalités en staging. En revanche, même les équipes les plus efficaces ont tendance à attendre deux semaines, voire un mois pour mettre en production leurs développements. Un tel cycle de release ralentit l’obtention des retours clients et donc l’amélioration du produit.

Grâce à la culture DevOps, la collaboration fluide entre les Dev et les Ops favorise une mise en production plus régulière et ainsi raccourcit les cycles d’itération. Une bonne organisation DevOps permet aussi de réagir plus efficacement en cas d’incident.

Dev et Ops : des objectifs contradictoires ?

Historiquement, les développeurs sont focus sur le nombre de fonctionnalités qu’ils livrent. Les Ops, quant à eux, ont pour mission d’assurer un site up 100% du temps. Les mises en production étant une cause récurrente de down time et d’instabilité, on peut comprendre la réticence des Ops à déployer quotidiennement des fonctionnalités.

Ces objectifs contradictoires et le manque de collaboration entre Dev et Ops créent souvent des tensions entre ces deux métiers, au détriment du produit et de ses utilisateurs finaux.

Les symptômes ne trompent pas. Parmi les points de friction classiques :

• le désaccord sur la nécessité de faire une mise en production.
• le renvoi de la balle en cas de bug “c’est pas chez nous que ça casse, c’est côté applicatif, à eux de gérer”
• les délais de communication entre métiers. Une simple question peut faire perdre de précieuses heures lorsque la communication n’est pas fluide.

Petit exemple pour illustrer ce dernier point :

Chez un client, dû a un mauvaise communication, un changement de variables d’environnement censé prendre 10min a pris plus de 24h (pas de bons process de communication , au lieu de se parler directement)

Mettre les 2 équipes dans les bonnes conditions pour collaborer efficacement leur fera gagner du temps, améliorera la qualité du produit et l’ambiance dans les équipes.

Mon plan d’action pour une meilleur collaboration Dev/Ops

La communication. C’est (toujours) le nerf de la guerre.

1ère étape : Créer une équipe fonctionnelle

Les Devs et les Ops sont réunis sur un même plateau. Les succès restent inchangés, mais sont affichés au même endroit, et c’est l’équipe entière qui en porte la responsabilité. Ops et Dev s’entraident pour assurer ensemble le bon déploiement des fonctionnalités et la stabilité de la production.

2e étape : Dédier du temps Ops au soutien des équipes de Dev

Cela peut prendre de nombreuses formes selon votre méthodologie, mais l’objectif est toujours le même : créer les conditions pour une collaboration apaisée.
La demande imprévue d’un développeur, pour l’ouverture d’un nouvel environnement par exemple, ne doit pas être vécue comme un dérangement par l’équipe Ops.

De son côté, un développeur doit comprendre que les Ops ont des tâches prioritaires, et que le former sur Docker ou mettre un script de rollback sur sa préprod n’en fait peut-être pas partie.

Chez Padok, chaque Ops a une demi-journée dite de “buffer”, réserve dans laquelle il pioche à chaque demande. Ce buffer fait l’objet d’un ticket hebdomadaire embarqué dans nos sprints Ops. Cela donne à l’Ops le temps nécessaire pour intervenir, mais oblige les développeurs à prioriser leurs demandes car ce temps n’est pas illimité.

3e étape : En finir avec les demandes “informelles”

Toute demande, même la plus petite, prend du temps. Comprendre le besoin, interrompre son ticket en cours, faire la tâche, donner de la visibilité quand elle est terminée, tout cela finit par coûter cher en fin de semaine.

Pour que les équipes de développement réalisent à quel point les Ops sont sollicités et l’impact que cela peut avoir, nous avons interdit les demandes “informelles”. Par Whatsapp, à la machine à café, en fin de réunion etc… Elles sont toutes formulées sur un canal commun à l’ensemble des équipes techniques (généralement un Slack). Il en découle deux effets : les développeurs ont la vision de toutes les demandes faites aux Ops et évitent de les surcharger, et les demandes formulées sont plus précises.

4e étape : Impliquer les Ops dans les évènements des Devs

La méthode agile est également un bon moyen de faciliter la communication, et donc la bonne collaboration de l’équipe. Pour prévenir l’équipe de développement de l’impact de leurs fonctionnalités, et pour les avertir des complexités qu’ils pourraient rencontrer.

Chez Padok, les Ops participent :

• Aux dailys ;
• A la partie “Review” des cérémonies Scrum ;
• Aux workshops ;
• Aux résolutions de problèmes.

5e étape : définir des objectifs communs

Chez Google, pour aligner Dev et Ops, les équipes ont mis en place un objectif commun : l’error budget. Tous les mois, chaque équipe fonctionnelle est autorisée à atteindre 0,01% de down time. Cela permet de fixer un standard équilibré entre mises en productions régulières et stabilité de l’infrastructure.

Il est aussi essentiel de fêter les succès ensemble. Que les objectifs Dev et Ops soient distincts ou communs (cf Google) au sein d’une équipe fonctionnelle, lorsque l’un d’entre eux est atteint, il est important de le célébrer en équipe. Cela amène une meilleure implication au sein de l'équipe.

Pour conclure

Le DevOps permet de gagner du temps en livrant plus souvent, avec des livraisons de meilleure qualité. Pour y parvenir il est essentiel de faire travailler en équipe les Ops et les Dev. Voici un résumé des étapes à suivre pour y parvenir :

1) Mettre en place une équipe fonctionnelle

2) Dédier du temps Ops au soutien des équipes de Dev

3) En finir avec les demandes “informelles”

4) Impliquer les Ops dans les évènements des Devs

5) Définir des objectifs communs

Une fois ces bases instaurées, il est toujours possible d’aller plus loin. Des sujets comme le débug ou l’astreinte peuvent faire l’objet d’une coopération encore plus rapprochée.

Si vous avez des questions plus précises, ou que vous souhaitez nous donner des éléments pour compléter cet article, n’hésitez pas à nous écrire via notre formulaire de contact !

Nous vous invitons également à découvrir notre offre Accompagnement DevOps, une équipe Ops Padok est dédiée à votre projet, en autonomie ou en soutien de votre équipe Ops interne.