Techniques pour des équipes DevOps hautement performantes

Transcription de la vidéo

Nous avons utilisé ChatGPT pour améliorer la grammaire et la syntaxe de la transcription.

Bonjour à tous. Merci d'être venus. Je m'appelle Branislav. Je suis responsable de l'ingénierie chez Platform.sh. Je suis aussi ingénieur, père, mari et passionné de réduction des déchets, ce qui va m'être utile dans cette présentation. Aujourd'hui, je vais parler de l'optimisation des performances et des stratégies que les entreprises peuvent mettre en œuvre pour optimiser leurs processus.

Avant de commencer, combien d’entre vous sont des managers ? Combien d’entre vous sont des ingénieurs qui ont tendance à devenir managers ? Et combien d’entre vous sont des DevOps ? Super ! Tu es au bon endroit.

Maintenant, combien d’entre vous savent qui est cette personne ? Il s’agit de Bruce McLaren, né en 1937 et décédé en 1970. Il était un pionnier du sport automobile et a créé certaines des voitures les plus incroyables et les plus avancées de l’histoire. Même après sa mort, McLaren a continué à gagner, avec huit titres de champion du monde des constructeurs et 12 titres de champion du monde des pilotes en Formule 1. Ils s’y connaissent en matière de fabrication de machines hautement performantes.

Il y a cependant un problème : ces machines sont des pièces uniques. Qu'est-ce que ça veut dire ? Pense à démarrer une voiture de Formule 1. Tu ne te contentes pas de tourner la clé. Au lieu de ça, tu connectes la voiture à une machine externe qui chauffe l’huile. Une fois que l’huile est à la bonne température, ils commencent à la pomper dans la voiture, lubrifiant et chauffant lentement le moteur. Ce processus est géré par de nombreux techniciens utilisant des ordinateurs puissants, le tout supervisé par un superviseur de démarrage de moteur — un vrai titre de poste ! Ce n’est qu’alors qu’ils sont prêts à démarrer le moteur. Comme je l’ai dit, c’est une machine hautement spécialisée, une pièce unique.

Quelle est la voiture la plus vendue au monde ? Ce n’est pas une McLaren ; c’est la Toyota Corolla. Depuis sa création dans les années 1960, plus de 50 millions d’exemplaires ont été vendus. En tant que constructeur, Toyota fait bien mieux que McLaren. Quand on y pense, Ford, Volkswagen et pratiquement tous les constructeurs automobiles font mieux que McLaren. Pourquoi ?

Voici cet homme, Eiji Toyoda. Né en 1913, il a vécu 100 ans. C'était un industriel japonais et le président de Toyota. Son histoire est fascinante. Après la Seconde Guerre mondiale, il a été invité par les Américains à visiter les sites de production de Ford pour comprendre la production de masse et l’organisation des usines. Il est revenu chez Toyota, qui était alors en difficulté et produisait parfois plus de 1 000 voitures par mois, et il a essayé de mettre en place de meilleurs processus. Il a inventé ce qu’on appelle « la méthode Toyota ».

Dans le cadre de la Méthode Toyota, il a introduit deux techniques. La première est le Kanban. Qui ici n’utilise pas le Kanban ? Une, deux, trois personnes. Il a co-créé ce processus. La seconde est le Kaizen, et c’est du Kaizen dont je vais te parler aujourd’hui. « Kai » signifie changement, et « Zen » signifie bon. C’est un changement positif ou une amélioration. Cette méthodologie met l’accent sur l’amélioration continue par petites étapes, sans innovations ni révolutions majeures, et sans changements radicaux.

Pourquoi ? C’est évident. Une grande entreprise qui introduit un changement radical arrête la chaîne de production, interrompt le processus et complique les choses pour tout le monde. Ensuite, il faut tout redémarrer lentement à partir de zéro. Cette méthodologie met également l’accent sur les processus, c’est-à-dire la familiarité. Si tu disposes d’une bonne documentation et d’un environnement familier, c’est là que la créativité peut s’épanouir. Enfin, le Kaizen favorise l’automatisation, qui est la clé de la performance.

Le Kaizen repose sur 10 principes, tous axés sur la prise de décisions éclairées. Il est important de bouleverser le statu quo par de petites étapes progressives. Le perfectionnisme n’a pas sa place ici ; l’accent est mis sur l’atteinte de l’objectif étape par étape. Cette approche favorise la réflexion analytique et exploite les connaissances collectives de tous les membres de l’organisation. Elle privilégie l’économie du changement, ce qui signifie que tu trouves le levier le plus petit et le plus simple pour obtenir le meilleur résultat possible. Et le dixième principe est « ne jamais cesser de mettre en œuvre », ce qui signifie que le processus est perpétuel et cyclique — il ne s’arrête jamais. Chaque cycle doit apporter un peu plus d’amélioration à l’organisation.

En pratique, ça se passe comme ça : d’abord, tu planifies — tu définis le problème, tu proposes des solutions et tu identifies les mesures pour suivre les progrès. Ensuite, tu mets en œuvre le plan et tu testes de petits changements pour t’assurer que tu es sur la bonne voie. Une fois ça fait, tu vérifies et évalues toutes les données pour t’assurer que les écarts entre ce que tu attendais et ce que tu as obtenu sont minimes. Enfin, tu standardises les changements à l’échelle de l’organisation.

L’objectif est d’améliorer les performances en réduisant le gaspillage. Qu’est-ce que le gaspillage ? Pense au temps perdu : les réunions où tu n’étais pas nécessaire ou où tu avais d’autres priorités. Pense au travail qui a dû être abandonné parce qu’il était redondant ou hors sujet. Pour ceux qui travaillent dans l’industrie manufacturière — même si personne ici ne semble en faire partie —, pense au gaspillage de matériaux. Pour le reste d’entre nous, c’est le gaspillage d’électricité, de CPU, de RAM, de stockage, de bande passante — tout ce qui rend l’hébergement plus coûteux.

Donc, on essaie d’améliorer les performances, mais comment savoir si on a vraiment progressé ? Comment évaluer si on est sur la bonne voie ? D’après le rapport State of DevOps — au fait, combien d’entre vous l’ont lu ? Levez la main. Bon, tu vois de quoi je parle. D’après le rapport State of DevOps, publié chaque année, la fréquence de déploiement est l’un des indicateurs clés à surveiller. Chaque année, depuis sept ou huit ans, ils disent la même chose : la fréquence de déploiement et le délai de reprise sont les deux indicateurs les plus critiques.

Qu’est-ce que ça veut dire ? Tu ne devrais pas déployer tous les mois, ni même toutes les semaines. Tu devrais déployer quand c’est nécessaire — à la demande. Éviter les pannes n’est pas l’objectif, car la meilleure façon d’éviter les pannes, c’est de ne rien faire. Au contraire, tu dois t’assurer que quand une panne survient, tu peux te remettre rapidement. Les équipes très performantes sont celles qui peuvent se remettre en moins d’une heure.

Le dernier rapport State of DevOps introduit également le concept d’« équipes équilibrées ». Il s’agit d’équipes qui allient haute performance, grande efficacité organisationnelle, forte satisfaction professionnelle et faible épuisement professionnel — une nouveauté dans le rapport de cette année. Les équipes équilibrées utilisent la technologie de manière durable et, par conséquent, sont plus performantes.

Je le répète : la haute performance est associée à des déploiements plus fréquents. C’est l’indicateur que tu dois surveiller. Le temps moyen entre deux pannes n’est pas aussi important. Ce qui compte, c’est la rapidité avec laquelle tu te remets d’une panne.

Si tu veux classer toutes les capacités nécessaires à une haute performance, tu peux les diviser en trois groupes : les capacités techniques, l’optimisation des processus et une culture de sécurité psychologique. Je vais m’étendre un peu plus sur chacun de ces points, mais commençons par les capacités techniques.

Le premier point consiste à rompre avec les technologies héritées. Cela semble évident, mais si tu utilises des versions d’exécution non prises en charge, tu es déjà en difficulté. Qui ici utilise PHP 8 ou une version antérieure ? Si c’est ton cas, tu as un problème. Les versions d'applications non prises en charge, les dépendances ou les technologies redondantes peuvent également te freiner. Ou imagine que tu aies un modèle de données qui ne correspond plus à tes besoins : combien de fois as-tu dû dire à tes interlocuteurs métier : « Je ne peux pas faire ça parce que la base de données ne le permet pas » ? C'est un problème. Le couplage serré est un autre problème, car il limite ta flexibilité.

Toutes ces choses — technologies non prises en charge, systèmes obsolètes, couplage serré — créent une dette technique. La dette technique survient généralement pour de nombreuses raisons, mais l’une des principales est de s’en tenir à des stacks technologiques dépassés. Au lieu de cela, nous devrions réfléchir à une architecture moderne.

Pense à adopter des conceptions ou des modèles adaptés au cloud et natifs du cloud. Commence par des architectures faiblement couplées. Je ne parle pas nécessairement de microservices, mais les microservices pourraient être une solution. L’idée est de se concentrer sur de petites améliorations progressives plutôt que de déployer une mise à jour massive qui pourrait échouer lamentablement. Tu veux tester des changements plus modestes et minimiser les risques.

Bien sûr, l’intégration, la livraison et le déploiement continus sont essentiels si tu peux les gérer — ça devrait être ton objectif. Je veux insister sur un point précis : les conteneurs immuables. Qui ici héberge sur des conteneurs immuables ? Une poignée d’entre vous. Tu aimes ça ? Certains d’entre vous probablement pas. Mais les conteneurs immuables sont cruciaux car ils garantissent l’intégrité de ton application une fois qu’elle est en production.

Pense aussi aux API qui relient les applications et conçoit-les pour qu’elles soient antifragiles. Qu’est-ce que ça veut dire ? Ça veut dire que le système peut gérer des défaillances individuelles tout en continuant à fonctionner. Même quand quelque chose tourne mal, ça te permet de te remettre rapidement.

L’étape suivante consiste à réduire le gaspillage grâce à la standardisation. Qu’est-ce que ça veut dire ? Pense aux systèmes d’exploitation que ton organisation utilise : pense aux coûts de licence et de maintenance. Pense aussi aux normes de développement. Si elles diffèrent d’une application à l’autre, tu auras du mal à déplacer les personnes d’un projet à l’autre, à créer des équipes interfonctionnelles ou à intégrer de nouveaux collaborateurs. Des processus d’intégration plus longs, des revues de code plus lentes et l’adaptation à différentes normes sont autant de pertes de temps.

La standardisation doit avoir un objectif ultime : l’automatisation. Une fois que tu es standardisé, tu peux automatiser, et c’est essentiel. Automatise tout. En matière d’hébergement et de DevOps, cela signifie disposer d’environnements de type production à des fins de test.

Pour y parvenir, nous avons introduit l’« infrastructure as code », un concept déjà relativement bien connu. L’idée est de disposer de la recette pour provisionner l’infrastructure dans un fichier, sous forme de code. Ce code peut être géré par contrôle de version, ce qui te permet de suivre les modifications et d’ajuster ton infrastructure selon les besoins. Pense à des événements comme le Black Friday, où tu peux avoir besoin d’ajuster rapidement ton infrastructure.

Maintenant, voici un point crucial : ton premier déploiement en production ne doit pas être le véritable premier déploiement en production. Qui sait ce que cela signifie ? Une personne ? D’accord. Cela signifie qu’avant de déployer en production, tu dois tout tester dans un environnement qui reflète exactement la production. Tu as besoin d’une copie identique, octet par octet, de l’environnement de production où tu peux tout tester en toute sécurité : le code, l’infrastructure, les bases de données, les caches, etc. Tester dans un tel environnement est essentiel pour éviter les surprises lors de la mise en production.

C'est bien beau d'avoir un tel environnement de test, mais il peut être difficile à maintenir. Certains d'entre vous pensent peut-être déjà à Kubernetes ou à des outils similaires. L'objectif final ici est la banalisation. Qu'est-ce que ça veut dire ? Ça veut dire pouvoir obtenir l'infrastructure dont tu as besoin à la demande, en libre-service.

Chez Platform.sh, l’entreprise pour laquelle je travaille, c’est ce que nous te proposons. C’est une plateforme en tant que service, et notre tout dernier produit, Upson, est conçu pour répondre à ces besoins. Cela rejoint le premier pilier : les capacités techniques. Passons maintenant au deuxième pilier : les processus lean.

Qu’est-ce qu’un processus allégé ? Tu as besoin de tes rituels et de tes processus, mais ils doivent être conçus pour apporter de la valeur au client. C’est l’objectif principal. Tout ce que tu fais qui n’ajoute pas directement de la valeur est du gaspillage.

Alors, comment se concentrer sur l’utilisateur ? Il existe plusieurs techniques, mais ce qui fonctionne bien pour nous, ce sont les initiatives interfonctionnelles. Celles-ci permettent aux équipes de prendre des décisions quand c’est nécessaire sans devoir tout remonter aux niveaux hiérarchiques supérieurs. Cette approche évite le « jeu de l’escalade », où les décisions doivent passer par plusieurs niveaux d’approbation avant qu’une action puisse être entreprise.

Voyons cela en détail. Pour la première fois, le rapport State of DevOps indique que les équipes fortement axées sur l’utilisateur affichent des performances organisationnelles supérieures de 40 %. Quarante pour cent, c’est un chiffre énorme. Les initiatives interfonctionnelles sont un moyen d’y parvenir. Elles permettent aux organisations dotées de structures ou de divisions rigides de rassembler des personnes issues de différentes équipes, de leur confier une tâche et de leur fournir l’infrastructure nécessaire pour mener à bien leur mission.

Chez Platform.sh, on a introduit le concept de « trio produit ». Ça veut dire qu’un chef de produit, un concepteur produit et un ingénieur en chef travaillent ensemble pour donner vie à une nouvelle fonctionnalité. Qui veut en savoir plus là-dessus ? Reste après cette session, et on va entrer dans les détails. L’idée, c’est de rassembler toutes les personnes dont tu as besoin pour mener à bien le projet.

Dans ce trio produit, le chef de produit veille à ce que l’équipe reste centrée sur l’utilisateur. Le concepteur produit s’assure que ce que tu développes est à la fois fonctionnel et esthétique. L’ingénieur en chef s’assure que la solution s’intègre dans l’architecture technique globale.

Je t'ai donné une description, mais je ne m'attarderai pas trop sur ces diapositives — tu auras un lien vers les diapos à la fin de cette session. L'objectif ici est de prendre les décisions au bon endroit et d'éviter le « jeu du téléphone » organisationnel, où les messages sont transmis d'une personne à l'autre, perdant en clarté au passage.

Comment faire ? Tu t'assures que l'équipe dispose de tout ce dont elle a besoin pour livrer. Cela inclut des environnements de développement dédiés, la possibilité de tester les changements d'infrastructure et la capacité de vérifier que tout fonctionne avant de fusionner vers le staging et, enfin, la production.

Cela donne aux gens le temps de se consacrer à des tâches importantes, comme la documentation. La documentation est le fondement d’une organisation performante. Il existe plusieurs outils que tu peux utiliser — Confluence, GitBook, Read the Docs, Sphinx et Guru, entre autres — pour gérer la documentation au sein de tes équipes. Une documentation adéquate contribue à rendre les revues de code plus efficaces et favorise une culture du feedback.

Parlons maintenant du dernier pilier : la culture générative. La culture est le moteur principal du bien-être des employés, et j’ai répertorié quelques aspects importants sur lesquels tu dois te concentrer lorsque tu conçois ou favorises une bonne culture. Tu dois te soucier de la sécurité psychologique, en veillant à ce que les gens se sentent en sécurité pour exprimer leurs idées et leurs préoccupations. Tu dois promouvoir une communication ouverte et de qualité, et tu dois t’assurer que tes collègues ont la possibilité d’apprendre et d’échanger des informations.

Tout cela s’inscrit dans la culture générative, un concept très important mais qui pourrait nécessiter une session entière à lui seul. En bref, Westrum classe les cultures organisationnelles en trois types :

1. Pathologique – motivée par la peur et la menace, où les gens se soucient davantage de leur survie personnelle que des objectifs de l’organisation.
2. Bureaucratique – où l’accent est mis sur le respect des règles et la protection des territoires individuels (mon équipe, mon service).
3. Générative – centrée sur la mission de l’organisation, où tout le monde travaille ensemble pour créer de la valeur.

Dans une culture générative, l’indicateur principal est la performance de l’organisation, et non la performance individuelle. C’est une différence clé qui favorise la collaboration et le partage des responsabilités.

En réalité, la culture générative réduit l’épuisement professionnel, qui est l’une des principales causes de la baisse de performance des équipes. Selon le dernier rapport State of DevOps, l’épuisement professionnel est réduit de 61 % dans les organisations où la sécurité de l’emploi et la sécurité psychologique sont élevées. Pour continuer à aider tes collègues à donner le meilleur d’eux-mêmes, tu dois t’assurer que la mission de l’organisation reste au centre des préoccupations.

Il est beaucoup plus facile de maintenir tout le monde aligné sur la mission lorsque la direction fonctionne sur la base de la confiance, et non du contrôle. Cela passe également par la promotion des autres au sein de l’organisation, plutôt que par l’autopromotion. Souviens-toi de ceci : les équipes très performantes ne sont pas composées de stars isolées et exceptionnelles. Elles sont constituées de constellations — des équipes de personnes qui travaillent ensemble en parfaite harmonie.

Merci beaucoup.