Le "chaos day", un outil pour rapprocher Devs et Ops ?

Je suis chez mon employeur actuel depuis plusieurs années, et je constate comme chez d'autres employeurs, que des clivages existent malheureusement entre développeurs (Devs) et ingénieurs de production (Ops).

Un rôle différent au sein de l'IT

Peut-on vraiment en vouloir à des gens dont le métier, la formation, les attentes et les objectifs sont différent d'avoir des difficultés à se comprendre ?

Attention, je ne jete la pierre d'aucun des deux côtés, mais force est d'admettre que les rôles des deux parties ne sont pas les mêmes, quand bien même dev et ops sont complémentaires pour avoir une production efficace et performante, tout en étant innovant.

Seulement voila... quand les gens ne parle pas le même langage, il est difficile de se comprendre et d'appréhender la difficulté du métier de l'autre. Car, même s'il est simple de l'oublier, les développeurs jouent souvent contre la montre, pour livrer la dernière fonctionnalité à la mode pour avant hier, avec des specs souvent... approximatives. De leur côté, les ingénieurs de productions ont des rôles divers, le MCO de la production déjà, mais aussi l'intégration, la sécurité (point devenu de plus en plus primordial ces dernières années). Je ne compte pas être exhaustifs sur ces points, les rôles Dev/Ops variant d'une entreprise à une autre.

Le chaos pour rapprocher

De là, on en arrive à se demander comment faciliter les rapprochement entre les deux mondes. On entends souvent parler de feature team, fonctionnement en vogue, notamment chez les GAFAM, avec la logique "you build it, you run it". Et ça marche! Mais pourquoi ? Tout simplement parce que les soucis d'un dev devient aussi le souci d'un Ops, et vice-versa, puisque cette division n'existe plus en tant que telle.

Pour ma part, j'ai eu l'occasion d'avoir une autre approche, j'ai participé à deux gameday en collaboration avec AWS au sein de mon entreprise. Le but ? Au sein d'une entreprise fictive de location de licorne, Unicorn Rentals, mettre en place une infrastructure basée sur des exercices créés par Amazon.

Petite subtilité, cette journée se déroule en équipe, et surtout en équipe mixte Dev/Ops. Il s'agit d'une journée très intense, où la collaboration est primordiale pour l'emporter. Au travers de problématiques de production (stabiliser un service, optimiser les performances d'infrastructure, incident réseau etc...) et de développement (mise en place de code pour de la reconnaissance d'image, remise en fonction d'un pipeline de déploiement avec test du code etc...), cette journée permet de rapprocher des gens qui voient autrement leurs métiers respectifs et leurs compétences.

J'ai pu constater des changements dans les relations que je peux avoir avec les dits collègues, en passant d'un simple "bonjour" à de vrais questions, des sollicitations, des échanges techniques concrets, des demandes d'avis etc... De mon point de vue, pour moi, qui vient du monde des Ops, ayant occupé plusieurs poste d'ingénieurs ces dernières années, cela m'a permis de voir autrement les connaissances de certains de mes collègues développeurs.

Organiser des Chaos Day de manière indépendante

De notre côté, nous avons fait le choix de solliciter Amazon pour organiser ces journées, néanmoins, il est complétement possible d'organiser ce type d'événement avec ses propres infrastructure, cela permet par exemple d'éprouver la qualité des documentations, des backups etc... l'important n'est pas tant le contenu que la manière d'appréhender ces journées.

De manière assez simple, il est nécessaire :

• D'avoir des équipes mixtes DevOps
• De créer des problématiques nécessitant une collaboration entre les deux parties
• Un esprit "compétition" permet de catalyser la manière de travailler
• Ne pas prendre cette journée au sérieux
• Une ou des personnes pour aider, de manière à ce qu'aucune équipe ne soit frustrée si elle est trop en retrait, comme dans le point précédent, entretenir une compétition est nécessaire.

En complément, quelques souvenirs :

Cet article est issu de mes propres expériences et ne reflète pas forcément la vision de tous mes collègues de travail.