Vincent, consultant Site Reliability Engineering (ingénieur de fiabilité de service, ou maintien en condition opérationnelle), est en mission depuis une dizaine de mois au sein d’un acteur français majeur des télécommunications, dans sa filiale spécialisée dans les services managés. Son rôle principal est de mettre en place la pile de supervision de la plateforme.
Nous sommes revenus avec lui sur les enjeux fondamentaux de l’approche DevOps dans son environnement de travail, ainsi que les liens qu’il tisse naturellement entre DevOps et agilité.
1. Les atouts d’une culture DevOps déjà bien ancrée
Dès son arrivée en poste, Vincent a évolué dans un environnement de travail dans lequel l’approche DevOps était déjà fermement implantée :
« On développe, on livre et on maintient nos produits. On essaye d’automatiser un maximum de processus, et de collecter plus de mesures. Et surtout dans l’équipe monitoring, c’est d’autant plus ciblé. On a une vraie approche DevOps, la majorité des gens de l’équipe viennent déjà de ces mouvements-là philosophiquement. C’est dans leur ADN depuis des années. »
Vincent s’est parfaitement intégré dans cette démarche puisque l’approche DevOps est quelque chose qui lui tient à cœur depuis plusieurs années.
Le saviez-vous ? Si l’on voit souvent passer des noms de poste qui incluent le terme « DevOps » (ingénieur devops, intégrateur devops, devops manager ou même « devops » tout court), ce n’est pas pour autant adéquat.Vincent nous le confirme : « Le DevOps c’est une culture, une façon de travailler. C'est la contraction de Développement & Opérations, une extension d'Agile englobant la livraison et le maintien en conditions opérationnelles. Ça ne peut donc pas être un intitulé de poste, tout comme on ne recrute pas d'"Ingénieur Agile"… ». Le DevOps met l'accent sur le passage à une structure d'équipe basée sur les résultats, sur la connaissance de son métier (basé sur la carte de flux de valeur), sur la limitation des périmètres, sur l'utilisation des données pour guider les actions et les décisions et sur la reconnaissance du fait plutôt que d'effectuer un travail qui est un travail (ex : ne pas avoir un d'arriéré de fonctionnalités, un historique de dette technique et un arriéré de travail opérationnel).Notez qu’on peut tout de même raisonnablement parler de “coach” ou “consultant DevOps”. Une info intéressante à avoir en tête, notamment auprès d’éventuels recruteurs, pour montrer que vous êtes sympathisant, voire militant de l’approche !
2. DevOps et agilité : deux faces d’une même pièce
Vincent est un adepte convaincu de l’approche DevOps et, pour lui, le lien avec l’agilité est indéniable : « En schématisant un peu, on peut dire que DevOps c’est l’application IT de l’agilité. La première fois qu’on a vu le mot « agile » apparaître dans des rapports, c’était pour de la manufacture (21ST Century Manufacturing Enterprise Strategy Report, Roger N. Nagel) : on voit donc bien qu’on peut faire de l’agilité pour un peu tout. Et côté IT, DevOps c’est vraiment l’application du concept d’agilité au sens où on doit gérer le produit du développement à son opérabilité (livraison, maintien en conditions opérationnelles et mises à jour du produit). »
La pertinence de ce lien entre approche agile et DevOps est assez peu connue, que ce soit du côté des agilistes, développeurs ou des opérationnels. Vincent a donc à cœur de sensibiliser sur le sujet, notamment lors de présentations données avec l’association Agile France.
Pour lui, l’évidence de cette connexion ne fait aucun doute : « DevOps, c’est la contraction de Development and Operations et donc il faut vraiment voir ça comme un tout : c’est le cycle de vie du produit de A à Z, du début jusqu’à la fin. C’est vraiment de l’agilité. »
3. Expérimenter, tester, se tromper : l’exploration au cœur de l’approche DevOps
Parmi les défis principaux que Vincent a rencontré sur sa mission, le plus important a été l’expérimentation, de coupler des technologies déjà utilisées avec d’autres formes de déploiements (hors applications conteneurs, sur lesquelles leur travail était centré jusqu’alors), tout en garantissant une simplicité maximale d’utilisation pour le client final.
Pour relever ce défi, Vincent nous explique qu’il a fallu expérimenter, se tromper, analyser là où ça marchait, les points bloquants, etc. et avancer progressivement. Il s’est avoué confiant sur le fait qu’en continuant sur cette lancée, son équipe et lui-même arriveront à bout de ce challenge : « Quand on va sur un terrain sur lequel personne n’est encore allé, on peut se prendre les pieds dans les ronces. Mais, au fur et à mesure, en continuant d’avancer, c’est de cette manière que les explorateurs arrivent à poser de premières fondations. »
L’important dans une démarche de test and learn est de ne pas perdre de vue l’objectif final, à savoir apporter de la valeur à l’utilisateur final. Pour cela, il n’est pas forcément nécessaire de devoir choisir entre vitesse de développement et stabilité de l’applicatif. Le modèle Accelerate affirme ainsi que les deux peuvent tout à fait aller de pair ! Le tout est de bien monitorer un certain nombre d’indicateurs pour s’assurer de la performance globale de la démarche :
- 2 indicateurs de vitesse à suivre : la fréquence de déploiement, et la rapidité de mise à disposition du code finalisé en production ;
- 2 indicateurs de stabilité à suivre : le temps moyen pour rétablir un service tombé en panne, et la qualité du code livré.
Ce qu’il faut retenir de l’expérience de Vincent :
Il est urgent de changer d’état d’esprit sur les erreurs, sur les chutes éventuelles au cours d’une exploration.« Ne parlons pas d’erreurs, disons qu’on a identifié des façons qui ne fonctionnent pas… ! »
4. La communication : un enjeu majeur du DevOps, complexifié par le télétravail
Au sein de l’équipe de Vincent, des problèmes de priorisation des sujets et d’organisation du travail ont éclos dès le premier confinement (en mars 2020). L’équipe avait alors commencé à travailler avec une approche Kanban à cette période, ce qui n’a pas été simple à mettre en place au vu des circonstances.
Le télétravail systématisé à l’échelle nationale n’a pas non plus arrangé les choses, surtout pour les nouveaux arrivants dans l’équipe. Vincent nous confie : « même en ayant l’habitude de travailler à distance, pour l’onboarding, c’est délicat. Quand on n’a jamais rencontré certains collègues (ou juste en distanciel), les malentendus peuvent être plus fréquents. Finalement, ce sont les temps d’échange informel qui permettent de mieux cerner la personnalité de ses interlocuteurs et de lever d’éventuelles incompréhensions mutuelles. »
Concrètement, pour fluidifier la communication, il a fallu prévoir plus de rétrospectives, et ajouter des labels dans JIRA pour simplifier le travail en équipe sur les tickets qui le nécessitaient.
Faciliter la communication entre les équipes est sans conteste l’un des piliers de l’approche DevOps. Tout le monde doit saisir les objectifs et les enjeux de chacun, pour pouvoir avancer dans la même direction.
Laissons Vincent conclure : « Quand on joue au foot, mieux vaut que les membres de l’équipe collaborent pour mettre le ballon dans le but, plutôt que chacun prenne un ballon et essaie d’avancer seul. Le travail d’équipe c’est ça : on est ensemble. »
Et plus d’infos pour maintenir son équipe soudée en télétravail dans notre article !
