L'actu Pourquoi, en tant qu’Agiliste, aller à la conf DevOps REX ?

Pourquoi, en tant qu’Agiliste, aller à la conf DevOps REX ?

2021-08-06

Cela fait maintenant 4 ans que chaque année, j’attends octobre avec impatience. Pour savoir pourquoi, vous devrez lire la suite.

pasted image 0.png

Lever de rideau

Cela fait donc 4 ans que j’attends octobre avec impatience, pour l’arrivée imminente du Beaujolais nouveau peut-être me direz-vous ?

Ou comme excuse pour ne plus me raser la moustache afin de préparer « movember », le mouvement caritatif, alors ? Ou encore pour L’Oktoberfest, la fête de la bière ?

Ha oui… Halloween bien sûr !

Encore raté… depuis 4 ans je suis ravi de l’arrivée de l’automne, car je sais que j’y passerai des journées intéressantes, et que l’une d’elles sera au Grand REX sur le sujet du DevOps. C’est effectivement dans ce mythique cinéma parisien qu’a lieu la conférence DevOps REX, avec comme particularité le respect de la règle des trois unités :

Unité d’action, on n’y parle qu’en français et d’un seul sujet : le mouvement DevOps
Unité de temps, une seule journée
Unité de lieu, enfin, la grande salle de 2700 personnes

En effet, tous les REX, les retours d’expérience donc, auront lieu en séquence, dans la salle de cinéma, où l’écran de 300 mètres carrés sera le seul décor pour les oratrices et orateurs, sur scène. Théâtral en somme !

Une conférence à retenir de cette édition 2018 ?

« Eh oui ! », en bon imposteur, je vous livre ce texte écrit en décembre 2018 et jamais achevé, jusqu’à aujourd’hui. Je n’ai pas pu assister personnellement à l’édition 2019 et on peut oublier collectivement 2020, ça fait déjà une année de retard en moins… ^_^

Je reviens donc sur l’une des conférences particulièrement marquantes pour moi, et sur le fait qu’elle parle autant de DevOps que d’agilité.

La conférence “Mise à l’échelle d’une équipe d’astreinte dans un contexte de forte croissance” Ce REX a pour sujet la construction de l’équipe pluridisciplinaire, constituée de plus de personnes issues du monde du développement que de celui de l’infrastructure.

« Est-ce que vous trouvez normal de confier la survie nocturne de votre environnement de production à une seule personne ? »

C’est par cette phrase que Damien PACAUD commence sa conférence sur son expérience chez Teads. Pour absorber leur forte croissance et maintenir leurs systèmes opérationnels, cette société est rapidement passée d’une personne seule (le directeur technique), à 3 puis finalement 5 personnes constituant leur équipe d’astreinte « historique ». Une personne d’astreinte par semaine en rotation toutes les 4 semaines. Au-delà du cadre légal à respecter pour faire travailler des salariés la nuit et le week-end, la très forte croissance de l’entreprise a amené des difficultés inattendues par rapport au besoin de maintenir une équipe d’astreinte compétente et opérationnelle.

Première difficulté : la peur, celle qui mène au côté obscur

Ces 5 « sachants », qui ont fait grandir le système et l’ont vu se complexifier au fil des semaines et des mois, sont maintenant considérés comme des experts. Ils ont atteint une compréhension profonde du système. Pour eux, la transition fut « douce », en tout cas continue, d’un produit simple vers une plateforme de plus en plus compliquée. C’est le recrutement qui en est maintenant d’autant plus difficile.

En effet, les nouveaux arrivants sont « terrifiés » à l’idée d’être réveillés la nuit et de devoir opérer un système complexe, qu’ils ne connaissent pas. Cette équipe avait donc atteint une taille maximale incompatible avec la croissance de la société. Ils se sont heurtés à un mur, une taille critique impossible à dépasser.

Second embarras, la documentation

Puisque le système semble inconnu de certains, il suffit de lire la « documentation exhaustive »…

Vraiment ?

Or s’il existe bien une certaine doc, le constat est lui sans appel : elle n’est pas à jour, d’une part, et celle qui existait n’est en fait pas adaptée aux opérations de maintien en condition opérationnelle. Décision fût donc prise « de construire de la documentation » et après six semaines d’essai, ils furent contraints de constater l’échec : rien de concret n’avait été rédigé. Sans surprise, écrire de la documentation n’a pas marché… « Les individus et leurs interactions plus que les processus et les outils »[2], comme dirait l’autre.

Dernier problème « assez important » : un membre de l’équipe veut arrêter l’astreinte

Ce départ, et la difficulté à recruter de nouveaux membres dans l’équipe, provoqua le passage du mode « c’est compliqué » au mode « Houston, nous avons un problème ». Et paradoxalement, c’est ce sentiment d’urgence, qui je pense, leur a permis d’innover.

En replaçant les individus au cœur de la problématique et en cherchant les vraies raisons de la difficulté à recruter et à construire une connaissance commune, ils ont pris plusieurs décisions et engagements importants :

Pour remplacer 1 personne, ils allaient en recruter 8 nouvelles (pour avoir une équipe de 12 personnes),
Plutôt qu’une personne d’astreinte, ce serait un binôme, soit 2 personnes d’astreinte par semaine,
Il n’y aura plus de processus d’escalade,
Le discours attenant : « Nous avons conscience que vous ne pouvez pas tout savoir, tout résoudre. Nous savons que vous allez faire de votre mieux pour résoudre tous les problèmes qui arriveraient pendant la nuit, pendant le week-end »,
Sanctification du post mortem : systématiquement fait dans un délai de 48 heures suivant un incident, avec les 12 personnes, pour la recherche de la cause racine.

Pour éviter à quelqu’un d’affronter seul la panne, la nuit, et d’avoir à prendre la décision de réveiller un collègue, c’est la machine qui réveillera en même temps les deux humains. L’union fait la force, et la méthode du canard où l’on explique à haute voix son problème à un objet inanimé dans l’espoir de le résoudre seul, marche d’autant mieux avec une personne réelle.

Une personne issue plutôt du build[3], une autre issue plutôt du run[4], de l’infra, le binôme aura un « set (ensemble) de compétences mutuellement exclusif », ou en tout cas « une surface de connaissance de l’ensemble de la plateforme beaucoup plus large ». On laisse à ce binôme toute latitude pour corriger les problèmes et surtout, on lui fait confiance pour ça ! C’est cette confiance, exprimée clairement, et le fait d’être par deux, Dev et Ops, qui permirent de faire disparaître la peur et de débloquer le recrutement. Depuis environ un an, Teads est « absolument ravie » de son équipe d’astreinte. Elle est vivante, les entrées sorties ne posent pas de difficulté, elle se constitue une bibliothèque de runbooks[5] au fil des rétrospectives (post mortem) et ils ont déjà identifié des pistes d’amélioration

Ce que j’en retire

Ce retour d’expérience m’a inspiré car il démontre selon moi que l’on a beaucoup à gagner en remettant l’humain au centre, et qu’il est toujours bon de changer de perspective, de point de vue, voire de paradigme.

Parce que d’une part, ils ne pouvaient pas faire plus de la même chose : avoir une équipe plus grande. Et, d’autre part, ils ne pouvaient pas faire mieux la même chose : faire une meilleure documentation. Ils ont simplement arrêté d’essayer pour faire différemment. « L’adaptation au changement »[6], ça vous rappelle probablement quelque chose ?

Durant toute la présentation, j’ai noté ce parallèle entre l’esprit DevOps de cette équipe et l’agilité de leur transformation: « Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance (…) », ou encore « À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence », c’est pratiquement le Manifest Agile « by the book »…

Et à vous, ça vous dit quoi ?

Voilà pourquoi, ami(e)s agilistes, amis facilitateurs, amies actrices du changement, vous devez aller à DevOps REX, ou à toute autre conférence ou atelier DevOps. Et ce même si vous êtes loin de la technique. A quel moment ce texte vous a-t-il perdu ? Damien a-t-il parlé de technologies nuageuses ? De magie noire automatisée ? De serveurs de « CiDi »[7] ? A aucun moment… et pour cause. DevOps, même s’il vient avec une panoplie d’outils et de technologies, est avant tout un mouvement culturel. Il s’agit de changer la culture des organisations, là encore, ça doit vous évoquer quelque chose, non ?

Et même si vous restez écartés des phases de d’exploitation effectives des produits que vous aidez à concevoir, il faut vous y intéresser. Notre monde est devenu numérique, le moindre produit maintenant est connecté… il y a donc quelque part des machines qui écoutent, qui répondent, et ces machines sont mises en place par des femmes et des hommes qui devront interagir à un moment avec celles qui ont réalisé le produit ou service. Sans quoi, sans cette bonne interaction, il est envisageable que la valeur ajoutée soit faible pour l’utilisateur. Sans ce partage, il est possible que les clients soient frustrés par la belle application qu’ils utilisent et qui n’affiche plus rien car la partie serveur, chez l’hébergeur, n’arrive pas à suivre. L’agilité est un moyen de délivrer plus rapidement de la valeur, DevOps est nécessaire pour que cette valeur arrive tout aussi rapidement à celles et ceux qui l’attendent.

Pour aller plus loin

Notes

[0] Illustration de mon ami et grand maître Gribouilleur Jean-Pierre BONNAFOUS (@ramuncho)

[2] C’est la 1ère valeur inscrite dans le Manifeste Agile : https://agilemanifesto.org/

[3] Je nomme « build » l’ensemble des personnes et métiers qui construisent, au sens large, la solution (produit et/ou service).

[4] Je nomme « run » l’ensemble des personnes et métiers qui exploitent, durant sa vie commerciale, la solution (produit et/ou service).

[5] Le runbook est le dossier d’exploitation, c’est une compilation systématique des procédures et des opérations que l’administrateur ou l’opérateur du système effectue.

[6] C’est la 4éme valeur inscrite dans le Manifeste Agile : « L’adaptation au changement plus que le suivi d’un plan ».

[7] Je n’évoque pas « l’antique » CD audio mais le terme de génie logiciel « CI / CD » qui fait généralement référence aux pratiques combinées d’intégration continue et de livraison continue.