Combler les lacunes : l'importance de la communication DevOps

Même si la méthodologie DevOps est avec nous depuis un certain temps maintenant, elle est toujours au centre de discussions animées. Les entreprises le souhaitent mais ne savent pas comment l'aborder.

DevOps est partout. Et même s'il s'agit d'une tendance intéressante, elle doit être adaptée aux produits, et non l'inverse.

Mais certaines personnes ne le voient pas de cette façon. On me pose souvent des questions telles que "Pensez-vous que nous devrions commencer à utiliser Docker ou passer directement à Kubernetes ?" De telles questions n'ont aucun sens sans même savoir de quoi parle le produit.

Tous ces termes fantaisistes (cloud, Kubernetes, conteneurs, gestion de la configuration, Infrastructure-as-Code) promettent quelques améliorations. Mais ils sont pour DevOps tout comme les télescopes sont pour l'astronomie. Ils peuvent être utiles, mais ils ne sont pas nécessaires.

À la base, DevOps vise à combler l'écart entre ce que le client a commandé et ce que l'équipe de développement a livré. L'accent est mis sur les cycles de publication courts, l'approche itérative de la conception et l'automatisation des étapes répétitives. Selon vous, qu'est-ce qui est le plus important pour les concrétiser ?

Si vous avez dit "excellente communication", vous avez raison. Les outils sont tous bons. Mais ils ne valent l'argent investi en eux que lorsqu'ils améliorent la communication.

Un aspect de la communication consiste à savoir ce qui est nécessaire pour faire le travail. Et le travail ne signifie pas que "le code est validé dans le référentiel". Pensez-y plutôt comme "le client a vu le changement de production et l'a accepté".

Dès que cette première étape est déterminée, et que tout le monde sait ce qui doit se passer, c'est le meilleur moment pour l'écrire. Où? Eh bien, je suis un grand défenseur du maintien d'un README.md . Chaque membre d'une équipe peut toujours jeter un coup d'œil à l'intérieur et connaître l'état d'un projet, et c'est une référence naturelle pour les nouveaux venus.

L'automatisation, la prochaine étape après l'écriture d'un README, est facultative. Il s'agit cependant d'une conséquence naturelle de la documentation du processus. Et oui, l'automatisation est ce qui vient souvent à l'esprit lorsque l'on pense à DevOps.

Attendez une minute… l'automatisation est facultative en matière de DevOps ? DevOps n'est-il pas le département de la personne qui effectue les déploiements ?

Ce que les gens comprennent généralement sous le terme « ingénieur DevOps » est soit un ingénieur en fiabilité logicielle, un ingénieur en plate-forme ou un ingénieur en automatisation des opérations. Ce sont tous des rôles valides qui permettent de pratiquer DevOps, mais l'utilisation du terme collectif « ingénieur DevOps » peut être un peu ambiguë.

Examinons donc de plus près DevOps lui-même.

DevOps expliqué

Tout d'abord, laissez-moi vous montrer ce que DevOps n'est pas :

1. Ce n'est pas seulement un préfixe de titre de poste
2. Ce n'est pas une équipe (mais "Dev" et "Ops" le sont)
3. Ce n'est pas une technologie
4. Cela ne signifie pas "un administrateur système qui peut coder"
5. Cela ne signifie pas "automatiser les choses"
6. Cela ne signifie pas "il n'y a pas d'équipe d'exploitation maintenant"

Sachant cela, vous savez maintenant que vous ne pouvez pas simplement "embaucher un ingénieur DevOps" ou "créer une équipe DevOps" dans une entreprise pour vous assurer d'être pérenne. DevOps s'apparente au développement Agile. Embaucheriez-vous un développeur Agile en tant que tel ? Probablement pas. Soit vous développez un produit de manière Agile, soit vous ne le faites pas.

Comment alors décrire DevOps ? C'est une méthodologie. Ou peut-être une culture. Peut-être même un esprit. Faire un produit selon les principes DevOps signifie que tout le monde, qu'il soit développeur, ingénieur d'exploitation ou chef de produit, partage une vision commune, la maintenant par la communication. Dans une moindre mesure, cela signifie aussi que tout le monde utilise les mêmes outils. Ces outils ne sont pas destinés à aider un seul groupe de personnes. Ils sont destinés à faire avancer le produit.

Aller avec ce concept nécessite un sérieux changement de mentalité, qui est le principal obstacle. Pourquoi donc? C'est parce que les gens doivent sortir de leur zone de confort et commencer à collaborer avec des personnes qui ont des compétences différentes. Les développeurs doivent soudainement apprendre comment fonctionne le cloud et commencer à déployer leur propre code. Les responsables des opérations doivent abandonner les configurations manuelles et commencer à coder. Tout le monde doit apprendre de nouveaux concepts. Chacun a de nouvelles responsabilités .

Ce n'est pas facile, mais avec une bonne communication et un objectif commun, c'est tout à fait réalisable. Cette communication implique l'établissement d'une culture, la mise en place de processus légers et le maintien d'une documentation appropriée.

DevOps Automation est une documentation

Vous n'y avez probablement jamais pensé de cette façon. Mais la plupart des outils couramment associés au DevOps sont des outils de documentation :

• Les scripts de construction écrits pour la lisibilité servent à documenter le processus de construction
• Les pipelines d'intégration continue documentent le processus d'intégration, de la création de pièces uniques à un produit complet
• Les pipelines de déploiement continu vont plus loin en documentant comment déployer un produit que votre client peut utiliser
• Les fichiers de gestion de configuration documentent le processus d'installation et de configuration
• Les spécifications d'infrastructure en tant que code documentent l'infrastructure nécessaire (assez formellement, en fait !)
• Les conteneurs sont livrés avec leurs propres Dockerfile s qui documentent comment créer et configurer un microservice donné

Tous ces concepts fantaisistes font essentiellement une chose : ils aident les membres de l'équipe à mieux communiquer en documentant les processus. Ces processus peuvent ensuite être exécutés manuellement ou être automatisés. Ce qui est important, c'est que chaque acteur d'un projet puisse les suivre.

Documenter vos processus sous forme de code présente un gros avantage par rapport aux manuels d'instructions habituels. Le code peut être vérifié et se comporte de manière prédictive. Étant donné la même entrée, il produit la même sortie.

Avec des instructions écrites, vous aurez autant d'interprétations qu'il y a de lecteurs. Si vous écrivez une documentation ambiguë ou vague, la personne qui la lira comblera les lacunes. Le fait est que vous n'avez aucun contrôle sur ce qui se passe dans les lacunes.

C'est beaucoup plus simple avec du code. Sans mesures concrètes, le programme cessera de fonctionner. Ces étapes concrètes sont un aspect clé de la communication DevOps.

Communication DevOps : le seul moyen de combler le fossé entre le développement et les opérations

Dans le livre The Phoenix Project, nous assistons aux problèmes d'un manager récemment promu chargé de déployer un grand projet. Comme personne ne sait ce qui se passe, tout le monde combat les incendies sans grand progrès. Le sous-titre du livre mentionne que c'est une histoire de DevOps. Je suis d'accord avec ça.

Mais ce qui est intéressant, c'est que tout au long du livre, aucun nouvel outil n'est introduit. Pouvez-vous atteindre un état de DevOps en améliorant uniquement la communication ? Les protagonistes du livre l'ont fait, alors il y a de l'espoir pour vous aussi !

Même si l'approche des protagonistes peut être considérée comme "à l'ancienne" (utiliser de véritables cartes papier au lieu d'un véritable système de suivi des bogues), les choses ne commencent à changer pour le mieux qu'une fois que toutes les parties impliquées commencent à se parler.

Vous pensez peut-être qu'il n'est possible d'améliorer la collaboration entre le développement et les opérations qu'en créant de meilleures interfaces entre eux, comme des accords de niveau de service ou des arriérés d'incidents. Mais le contraire est vrai. En détruisant les interfaces et en introduisant l'empathie et une cause commune, vous aurez une équipe qui travaille vers un objectif commun.

Structure de l'équipe DevOps : qui fait partie d'une équipe ?

Idéalement, chaque produit ne devrait avoir qu'une seule équipe : l'équipe produit.

J'étais une fois dans une équipe de développement où un objectif commun avec d'autres équipes était absent. L'équipe de développement voulait pousser autant de changements que possible. L'équipe de validation a été chargée d'empêcher l'introduction de défauts. Ils avaient des managers différents et ils étaient évalués individuellement.

Le résultat? Le développement et la validation ont joué au ping-pong avec des rapports de défauts. Lorsque la validation a trouvé un test qui ne réussissait pas, le développement était plus intéressé à trouver des failles dans le code de test lui-même qu'à essayer de rendre son propre code exempt de bogues.

Le cycle de publication a gonflé, bien sûr, car il y avait d'énormes frais généraux nécessaires pour remplir correctement les rapports, les contre-rapports, etc. Ce que la plupart semblaient ne pas reconnaître, c'est qu'en termes de produit, les deux équipes devaient partager un objectif commun et travailler ensemble pour l'atteindre. Mais le manque de coopération appropriée et la mentalité de silo rendaient cela très difficile à remarquer.

La lutte contre le gaspillage est un effort commun

L'état d'esprit de production allégée qui a inspiré le Manifeste pour le développement logiciel agile (qui à son tour nous a présenté DevOps) visait à lutter contre le gaspillage. Par déchets, nous entendons tout ce qui n'est pas directement lié à la commande du client. Les travaux en cours empilés sont un gaspillage. Chaque étape d'un processus qui ne conduit pas clairement à une libération est un gaspillage.

Mais les déchets ne peuvent être vus qu'à un niveau élevé. Dans le cadre d'une équipe, certaines procédures peuvent sembler indispensables. Du point de vue du produit, cependant, ils pourraient bien être inutiles.

Pour déterminer quels efforts sont inutiles, vous devez unir vos forces et tenir compte du cycle de vie d'un produit expédié. Vous devez également penser du point de vue du client. Cette fonctionnalité est-elle souhaitée par le client ? Si ce n'est pas le cas, vous pouvez aussi bien l'ignorer pour le moment. Vos processus sont-ils simples et légers ? Examinez de plus près, en particulier ceux qui traversent les frontières de l'équipe.

Vous voulez vous assurer que le développement d'un produit est aussi efficace que possible ? Invitez un étranger à voir comment vous travaillez. Une personne qui ne fait pas partie de votre équipe pourra poser des questions perspicaces et repérer de nouveaux domaines à améliorer.

Principes DevOps : Gardez votre (vos) CALME(S)

CALMS est une description très précise de la façon dont on devrait pratiquer DevOps :

• C ulture
• Automatisation
• Maigre
• M esure
• Partager

Remarquez qu'il a la forme d'un sandwich. Les trois valeurs intermédiaires sont plus techniques, tandis que les valeurs extérieures concernent les compétences non techniques. Mais la base de toute culture est la communication : nous échangeons nos valeurs et nos croyances avec les autres membres de l'équipe jusqu'à ce que nous parvenions à un consensus sur la manière dont les choses doivent se comporter.

Il en va de même avec le partage. Partager quelque chose de basique comme la nourriture ne nécessite pas de communication. Mais le geste lui-même peut aussi être vu comme un acte de communication. "Je tiens à toi, alors je partage avec toi." Nous ne voulons pas limiter la portée uniquement à la communication verbale.

Le partage d'idées et d'outils nécessite toutefois la communication. Comment doit-on les partager ? Où va-t-on les mettre ? Sont-ils utiles pour chaque personne d'une équipe ou juste pour un petit groupe ?

Si vous vous concentrez uniquement sur les aspects plus techniques (automatisation, lean et mesure), vous passez à côté de l'intérêt de DevOps. Qu'y a-t-il de si bien à avoir un script de déploiement automatisé que personne n'utilise jamais en dehors de l'auteur ? Si le script lui fait gagner du temps, cela pourrait être justifié. Mais imaginez combien de temps pourrait être gagné si tout le monde partageait ce script. Cela en dit long sur la lutte contre le gaspillage !

DevOps rapproche les entreprises du développement

Certains disent que DevOps rapproche les opérations du développement. C'est vrai, mais ce n'est pas toute la vérité. Lorsqu'il est bien fait, DevOps rapproche chaque unité. Il permet aux entreprises et aux clients de voir ce que fait le développement, presque en temps réel.

Cette boucle de rétroaction plus courte profite à toutes les parties prenantes. Le travail est généralement plus visible et les développeurs peuvent également voir facilement comment les clients utilisent le code qu'ils produisent. Avec un déploiement traditionnel, vous pouvez attendre plusieurs mois avant que quelqu'un remarque des bogues ou des exigences manquées. Avec un déploiement continu, tout le monde peut réagir à tous les problèmes au fur et à mesure qu'ils surviennent. Les développeurs, les opérations, les entreprises et les clients peuvent s'asseoir dans une pièce et modifier l'application de travail en fonction des besoins actuels.

Les outils DevOps d'abord ? Détrompez-vous

Bien sûr, il faut tous les outils pour rendre cela possible.

Mais aucune quantité d'outils ne peut remplacer une bonne communication et l'empathie au sein de l'entreprise. Une fois, j'ai observé un produit où le processus de construction appartenait à une équipe, tandis que le code fourni appartenait à une autre.

Les problèmes avec le système de construction étaient courants. Les développeurs ne savaient pas comment l'utiliser. Il était basé sur des outils standards mais ils étaient customisés au point que toute documentation disponible sur le web s'avérait inutile.

Tout le monde voulait améliorer la situation, mais il n'y avait pas d'entente entre les deux équipes. Cela signifiait que les deux parties ont introduit de nouveaux outils sans consulter l'autre partie. Cela n'a fait qu'élargir l'écart, au lieu de le combler.

Si vous souhaitez démarrer une transformation DevOps au sein de votre organisation, commencez par améliorer votre façon de communiquer. Ne vous contentez pas de présumer d'une solution : faites d' abord un remue-méninges avec un esprit ouvert . Dans ce cas, vous constaterez peut-être que, par exemple, le support d'outillage est insuffisant pour vos besoins. C'est à ce moment-là que vous pouvez envisager de peaufiner vos outils actuels ou d'en introduire de nouveaux, sinon vous ajouterez probablement au problème initial.

Le moyen le plus rapide d'établir DevOps ? Mieux Communiquer !

Dans l'introduction, j'ai mentionné la question que les clients me posent souvent : "Dois-je utiliser Docker ou dois-je passer directement à Kubernetes ?" Après avoir lu cet article, vous pouvez voir qu'il est préférable de répondre à une telle question après avoir effectué un travail de préparation, avec un état d'esprit DevOps.

Si vous savez que votre équipe produit comprend les avantages de DevOps pour elle-même et pour le client, l'équipe et le client peuvent commencer par définir leurs attentes. Ensuite, les ingénieurs peuvent déterminer le modèle de développement et de déploiement. Enfin, vous pouvez déterminer quels outils sont nécessaires.

Une fois toutes les exigences documentées, les choix technologiques sont beaucoup plus faciles à faire.

Je suis un défenseur de tous les excellents outils d'automatisation DevOps qui rendent notre travail plus facile et plus gérable. Mais notre travail quotidien est de travailler avec les gens . Investissons un peu de temps pour améliorer cet aspect des meilleures pratiques DevOps plutôt que d'obtenir un autre certificat technologique.