Techniques pour des équipes DevOps 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 également ingénieur, père, mari et passionné de réduction des déchets, ce qui sera utile dans cette présentation. Aujourd'hui, je vais vous parler de l'optimisation des performances et des stratégies que les organisations peuvent appliquer 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 des managers ? Et combien d'entre vous sont des DevOps ? C'est formidable ! Vous êtes au bon endroit.

Maintenant, combien d'entre vous savent de qui il s'agit ? Il s'agit de Bruce McLaren, né en 1937 et décédé en 1970. Pionnier des sports de course, il a créé certaines des voitures les plus étonnantes et les plus perfectionnées de l'histoire. Même après sa mort, McLaren a continué à gagner, avec huit championnats des constructeurs et 12 championnats des pilotes en Formule 1. McLaren s'y connaît en matière de fabrication de machines hautement performantes.

Mais il y a un problème : ces machines sont des flocons de neige absolus. Qu'est-ce que cela signifie ? Pensez au démarrage d'une voiture de Formule 1. Il ne suffit pas de tourner la clé. Au lieu de cela, vous reliez la voiture à une machine externe qui chauffe l'huile. Une fois que l'huile est à la bonne température, on commence à la pomper dans la voiture, ce qui permet de lubrifier et de chauffer lentement le moteur. Ce processus est géré par de nombreux techniciens à l'aide d'ordinateurs puissants, tous supervisés par un superviseur du démarrage du moteur - un vrai titre de poste ! Ce n'est qu'ensuite qu'ils sont prêts à démarrer le moteur. Comme je l'ai dit, c'est une machine très spécialisée, un flocon de neige.

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'unités ont été vendues. En tant que producteur, Toyota fait beaucoup mieux que McLaren. À bien y réfléchir, Ford, Volkswagen et la quasi-totalité des constructeurs automobiles affichent de meilleurs résultats que McLaren. Pourquoi ?

Voici un homme, Eiji Toyoda. Né en 1913, il a vécu 100 ans. Industriel japonais, il était 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 installations de production de Ford pour comprendre la production de masse et l'organisation des usines. Il est retourné chez Toyota, qui était 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 que l'on appelle le "Toyota Way".

Dans le cadre du Toyota Way, il a introduit deux techniques. La première est le Kanban. Qui ici n'utilise pas Kanban ? Une, deux, trois personnes. Il est coauteur de ce processus. La seconde est Kaizen, et je vais parler de Kaizen aujourd'hui. "Kai" signifie changement, et "Zen" signifie bon. Il s'agit d'un bon changement ou d'une amélioration. Cette méthodologie se concentre sur l'amélioration continue par petites étapes, sans grandes innovations ou révolutions, et sans changements radicaux.

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

Kaizen repose sur dix principes, tous liés à la prise de décisions en connaissance de cause. Il est important de bouleverser le statu quo en procédant par petites étapes. 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 pensée analytique et exploite le savoir collectif de tous les membres de l'organisation. Elle donne la priorité à l'économie du changement, ce qui signifie que l'on trouve le levier le plus petit et le plus facile pour obtenir le meilleur résultat possible. Enfin, 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 se termine jamais. Chaque cycle doit apporter un peu plus d'améliorations à l'organisation.

En pratique, le processus se présente comme suit : Tout d'abord, vous planifiez - définissez le problème, proposez des solutions et identifiez des mesures pour suivre le succès. Ensuite, vous mettez en œuvre le plan et testez de petits changements pour vous assurer que vous êtes sur la bonne voie. Ensuite, vous vérifiez et évaluez toutes les données pour vous assurer que les écarts entre ce que vous attendiez et ce que vous avez obtenu sont minimes. Enfin, vous normalisez les changements dans l'ensemble de l'organisation.

L'objectif est d'accroître les performances en réduisant les gaspillages. Qu'est-ce que le gaspillage ? Pensez au temps perdu, aux réunions où l'on n'avait pas besoin de vous ou à d'autres priorités. Pensez aux travaux qui ont dû être abandonnés parce qu'ils faisaient double emploi ou n'étaient pas pertinents. Pour ceux qui travaillent dans l'industrie manufacturière - mais il semble que ce ne soit le cas de personne ici - pensez au gaspillage de matériaux. Pour le reste d'entre nous, il s'agit de gaspillage d'électricité, de CPU, de RAM, de stockage, de bande passante - tout ce qui rend l'hébergement plus coûteux.

Nous essayons donc d'augmenter les performances, mais comment savoir si nous les avons réellement améliorées ? Comment pouvons-nous mesurer si nous sommes dans une bonne position ? Selon le rapport State of DevOps, combien d'entre vous l'ont lu, au fait ? Levez la main. D'accord, vous savez de quoi je parle. Selon le rapport State of DevOps, qui est 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 cela signifie ? Il ne faut pas déployer tous les mois, ni même toutes les semaines. Vous devez le faire chaque fois que c'est nécessaire, à la demande. L'objectif n'est pas d'éviter l'échec, car la meilleure façon d'éviter l'échec est de ne rien faire. En revanche, vous devez vous assurer qu'en cas d'échec, vous pouvez vous rétablir rapidement. Les équipes les plus performantes sont celles qui peuvent récupérer en moins d'une heure.

Le dernier rapport State of DevOps introduit également le concept d'"équipes équilibrées". Il s'agit d'équipes très performantes, très efficaces sur le plan organisationnel, très satisfaites au travail et peu sujettes à l'épuisement professionnel, ce qui est 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.

Permettez-moi de le répéter : Des performances élevées sont associées à des déploiements plus fréquents. C'est cette mesure qu'il faut surveiller. L'intervalle entre les échecs n'est pas aussi important. Ce qui compte, c'est la rapidité avec laquelle vous vous remettez d'une défaillance.

Si vous voulez classer toutes les capacités nécessaires pour obtenir de hautes performances, vous pouvez les diviser en trois groupes : les capacités techniques, l'optimisation des processus et une culture de la sécurité psychologique. Je vais parler un peu plus en détail de chacun de ces groupes, mais commençons par les capacités techniques.

Le premier point consiste à couper les liens avec les technologies existantes. Cela semble évident, mais si vous utilisez des versions d'exécution non prises en charge, vous avez déjà des problèmes. Qui ici fonctionne avec PHP 8 ou moins ? Si c'est le cas, vous avez un problème. Les versions d'applications non prises en charge, les dépendances ou les technologies redondantes peuvent également vous entraîner dans leur chute. Imaginez que vous ayez un modèle de données qui ne correspond plus à vos besoins. Combien de fois avez-vous dû dire à vos partenaires commerciaux : "Je ne peux pas faire ça parce que la base de données ne le permet pas" ? C'est un problème. Le couplage étroit est un autre problème, car il limite votre flexibilité.

Tous ces éléments - technologie non prise en charge, systèmes obsolètes, couplage étroit - créent une dette technique. La dette technique est généralement due à de nombreuses raisons, mais l'une des principales est le fait de s'en tenir à des piles technologiques dépassées. Nous devrions plutôt penser à une architecture moderne.

Pensez à adopter des conceptions ou des modèles adaptés à l'informatique dématérialisée et à l'informatique dématérialisée. Commencez par des architectures à couplage lâche. Je ne parle pas nécessairement de microservices, mais les microservices pourraient être une solution. L'idée est de se concentrer sur l'apport de petites améliorations progressives plutôt que de déployer une mise à jour massive qui pourrait échouer lamentablement. Il s'agit de tester des changements plus petits et de minimiser les risques.

Bien entendu, l'intégration, la livraison et le déploiement continus sont essentiels si vous pouvez les gérer - cela devrait être votre objectif. Je voudrais insister sur un point précis : les conteneurs immuables. Qui, ici, héberge des conteneurs immuables ? Une poignée d'entre vous. Cela vous plaît-il ? Certains d'entre vous ne l'aiment probablement pas. Mais les conteneurs immuables sont essentiels car ils garantissent l'intégrité de votre application une fois qu'elle est en ligne.

Pensez également aux API qui connectent les applications et concevez-les de manière à ce qu'elles soient anti-fragiles. Qu'est-ce que cela signifie ? Cela signifie que le système peut supporter des défaillances individuelles et continuer à fonctionner. Même si quelque chose ne va pas, cela vous permet de récupérer rapidement.

L'étape suivante consiste à réduire le gaspillage grâce à la normalisation. Qu'est-ce que cela signifie ? Considérez les systèmes d'exploitation utilisés par votre organisation - pensez aux coûts de licence et de maintenance. Pensez également aux normes de développement. Si elles diffèrent d'une application à l'autre, vous aurez du mal à faire passer les gens d'un projet à l'autre, à créer des équipes interfonctionnelles ou à intégrer de nouveaux employés. Des processus d'intégration plus longs, des révisions de code plus lentes et l'adaptation à des normes différentes sont autant de facteurs qui font perdre du temps.

La normalisation doit avoir un objectif ultime : l'automatisation. Une fois que vous êtes normalisé, vous pouvez automatiser, et c'est essentiel. Tout automatiser. En matière d'hébergement et de DevOps, cela signifie disposer d'environnements de type production à des fins de test.

Pour ce faire, nous avons introduit l'"infrastructure en tant que code", un concept déjà relativement bien connu. L'idée est d'avoir la recette pour provisionner l'infrastructure dans un fichier, dans le code. Ce code peut faire l'objet d'un contrôle de version, ce qui vous permet de suivre les modifications et d'affiner votre infrastructure en fonction des besoins. Pensez à des événements comme le Black Friday, où vous pouvez avoir besoin d'ajuster votre infrastructure rapidement.

Voici un point crucial : votre premier déploiement en production ne doit pas être le véritable premier déploiement en production. Qui sait ce que cela signifie ? Une seule personne ? D'accord. Cela signifie qu'avant de procéder au déploiement en production, vous devez tout tester dans un environnement qui reflète exactement la production. Vous avez besoin d'une copie à l'identique, octet par octet, de l'environnement de production où vous pouvez tout tester en toute sécurité - le code, l'infrastructure, les bases de données, les caches, etc. Les tests dans un tel environnement sont essentiels pour éviter les surprises au moment de la mise en service.

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 est la banalisation. Qu'est-ce que cela signifie ? Cela signifie que vous pouvez obtenir l'infrastructure dont vous avez besoin à la demande, en libre-service.

Chez Platform.sh, la société pour laquelle je travaille, nous vous fournissons cela. Il s'agit d'une plateforme en tant que service, et notre dernier produit, Upson, est conçu pour répondre à ces besoins. Cela est lié au premier pilier - les capacités techniques. Passons maintenant au deuxième pilier : les processus allégés.

Qu'est-ce qu'un processus allégé ? Vous avez besoin de vos rituels et de vos processus, mais ils doivent être conçus pour apporter de la valeur au client. C'est l'objectif principal. Tout ce que vous faites qui n'ajoute pas directement de la valeur est du gaspillage.

Alors, comment se concentrer sur l'utilisateur ? Il existe de nombreuses techniques, mais ce qui fonctionne bien pour nous, ce sont les initiatives interfonctionnelles. Elles permettent aux équipes de prendre des décisions lorsque c'est nécessaire sans avoir à faire remonter toutes les questions aux niveaux de gestion supérieurs. Cette approche évite le "jeu de l'escalade", où les décisions doivent passer par plusieurs niveaux d'approbation avant de pouvoir être prises.

Voyons cela en détail. Pour la première fois, le rapport State of DevOps indique que les équipes fortement axées sur les utilisateurs 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 réunir des personnes issues de différentes équipes, de leur confier une tâche et de leur fournir l'infrastructure nécessaire pour mener à bien ce travail.

Chez Platform.sh, nous avons introduit le concept de "trio de produits". Cela signifie qu'un chef de produit, un concepteur de produit et un ingénieur en chef travaillent ensemble pour donner vie à une nouvelle fonctionnalité. Qui veut en savoir plus ? Restez après cette session et nous entrerons dans les détails. L'idée est de rassembler toutes les personnes dont vous avez besoin pour mener à bien votre projet.

Dans ce trio de produits, le chef de produit veille à ce que l'équipe reste concentrée sur l'utilisateur. Le concepteur du produit s'assure que ce que vous construisez est à la fois fonctionnel et esthétique. L'ingénieur en chef veille à ce que la solution s'intègre dans l'architecture technique globale.

J'ai fourni une description, mais je ne m'attarderai pas trop sur ces diapositives - vous aurez un lien vers les diapositives à la fin de cette session. L'objectif est de prendre des 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 et perdent en clarté en cours de route.

Comment procéder ? En veillant à ce que l'équipe dispose de tout ce dont elle a besoin pour travailler. Cela inclut des environnements de développement dédiés, la possibilité de tester les changements d'infrastructure et de s'assurer que tout fonctionne avant de passer à la phase de préparation et, enfin, à la phase de production.

Cela permet de consacrer du temps à des tâches importantes, telles que la documentation. La documentation est la base d'une organisation réussie. Il existe plusieurs outils que vous pouvez utiliser - Confluence, GitBook, Read the Docs, Sphinx et Guru, entre autres - pour gérer la documentation au sein de vos équipes. Une documentation appropriée permet de rendre les révisions de code plus efficaces et favorise une culture du retour d'information.

Parlons maintenant du dernier pilier : la culture générative. La culture est le principal moteur du bien-être des employés, et j'ai énuméré quelques aspects importants sur lesquels vous devez vous concentrer lorsque vous concevez ou encouragez une bonne culture. Vous devez vous préoccuper de la sécurité psychologique, en veillant à ce que les personnes se sentent en sécurité pour exprimer leurs idées et leurs préoccupations. Vous devez promouvoir une communication ouverte et de qualité et veiller à ce que vos collègues aient la possibilité d'apprendre et d'échanger des informations.

Tout cela est lié à la culture générative, un concept très important qui pourrait faire l'objet d'une session entière. En bref, Westrum classe les cultures organisationnelles en trois catégories :

1. Pathologique - motivée par la peur et la menace, où les gens sont plus préoccupés par leur survie personnelle que par les 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 département).
3. Générative - axé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, la principale mesure est la performance de l'organisation, et non la performance individuelle. Il s'agit là d'une différence essentielle 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 des performances 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 à soutenir vos collègues dans l'accomplissement de leur meilleur travail, vous devez vous assurer que la mission de l'organisation reste le point central.

Il est beaucoup plus facile de maintenir l'alignement de tous sur la mission lorsque la direction fonctionne sur la base de la confiance et non du contrôle. Pour ce faire, il faut également promouvoir les autres au sein de l'organisation, plutôt que de se promouvoir soi-même. N'oubliez pas ceci : Les équipes performantes ne sont pas composées d'étoiles uniques et extraordinaires. Elles sont constituées de constellations, c'est-à-dire d'équipes de personnes qui travaillent ensemble de manière harmonieuse.

Je vous remercie de tout cœur.