Infrastructure as Code : comment surmonter les problèmes avec XP

Bonjour Habr! Auparavant, je me plaignais de la vie dans le paradigme de l'infrastructure en tant que code et je n'avais rien proposé pour résoudre la situation actuelle. Aujourd’hui, je suis de retour pour vous expliquer quelles approches et pratiques vous aideront à sortir de l’abîme du désespoir et à orienter la situation dans la bonne direction.

Dans un article précédent "Infrastructure as code : première connaissance" J'ai partagé mes impressions sur ce domaine, essayé de réfléchir à la situation actuelle dans ce domaine et j'ai même suggéré que des pratiques standards connues de tous les développeurs pourraient aider. Il peut sembler qu'il y a eu beaucoup de plaintes concernant la vie, mais il n'y a eu aucune proposition pour sortir de la situation actuelle.

Qui nous sommes, où nous sommes et quels problèmes nous avons

Nous faisons actuellement partie de l'équipe Sre Onboarding, composée de six programmeurs et de trois ingénieurs en infrastructure. Nous essayons tous d'écrire l'Infrastructure as Code (IaC). Nous faisons cela parce que nous savons fondamentalement comment écrire du code et que nous sommes des développeurs « au-dessus de la moyenne ».

• Nous avons un ensemble d'avantages : un certain bagage, une connaissance des pratiques, la capacité d'écrire du code, une envie d'apprendre de nouvelles choses.
• Et il y a une partie qui s'affaisse, qui est aussi un inconvénient : le manque de connaissances sur le matériel d'infrastructure.

La pile technologique que nous utilisons dans notre IaC.

• Terraform pour créer des ressources.
• Packer pour assembler des images. Ce sont des images Windows, CentOS 7.
• Jsonnet pour créer un build puissant dans drone.io, ainsi que pour générer le packer json et nos modules terraform.
• D'azur.
• Ansible lors de la préparation des images.
• Python pour les services auxiliaires et les scripts de provisionnement.
• Et tout cela en VSCode avec des plugins partagés entre les membres de l'équipe.

Conclusion de mon dernier article était comme ceci : j'ai essayé d'inculquer (d'abord en moi-même) l'optimisme, je voulais dire que nous allons essayer les approches et les pratiques que nous connaissons afin de faire face aux difficultés et complexités qui existent dans ce domaine.

Nous sommes actuellement aux prises avec les problèmes IaC suivants :

• Imperfection des outils et moyens de développement de code.
• Déploiement lent. L'infrastructure fait partie du monde réel et elle peut être lente.
• Manque d’approches et de pratiques.
• Nous sommes nouveaux et ne savons pas grand chose.

Extreme Programming (XP) à la rescousse

Tous les développeurs connaissent Extreme Programming (XP) et les pratiques qui la sous-tendent. Beaucoup d’entre nous ont travaillé avec cette approche, et cela a été couronné de succès. Alors pourquoi ne pas utiliser les principes et les pratiques qui y sont énoncés pour surmonter les défis liés aux infrastructures ? Nous avons décidé d'adopter cette approche et de voir ce qui se passe.

Vérifier l'applicabilité de l'approche XP à votre secteur d'activitéVoici une description de l'environnement pour lequel XP est bien adapté et de ses relations avec nous :

1. Exigences logicielles changeantes de manière dynamique. Il était clair pour nous quel était l’objectif final. Mais les détails peuvent varier. Nous décidons nous-mêmes où nous devons rouler, donc les exigences changent périodiquement (principalement par nous-mêmes). Si nous prenons l'équipe SRE, qui effectue elle-même l'automatisation, et limite elle-même les exigences et la portée du travail, alors ce point correspond bien.

2. Risques causés par les projets à durée déterminée utilisant les nouvelles technologies. Nous pouvons rencontrer des risques lors de l'utilisation de choses qui nous sont inconnues. Et c'est 100% notre cas. L'ensemble de notre projet reposait sur l'utilisation de technologies que nous ne connaissions pas entièrement. En général, c'est un problème constant, car... De nombreuses nouvelles technologies émergent constamment dans le secteur des infrastructures.

3,4. Petite équipe de développement étendue colocalisée. La technologie automatisée que vous utilisez permet d'effectuer des tests unitaires et fonctionnels. Ces deux points ne nous conviennent pas tout à fait. Premièrement, nous ne sommes pas une équipe coordonnée, et deuxièmement, nous sommes neuf, ce qui peut être considéré comme une grande équipe. Bien que, selon certaines définitions d'une « grande » équipe, un lot compte plus de 14 personnes.

Examinons quelques pratiques XP et comment elles affectent la vitesse et la qualité des commentaires.

Principe de la boucle de rétroaction XP

À mon sens, le feedback est la réponse à la question : est-ce que je fais la bonne chose, y allons-nous ? XP a un plan divin pour cela : une boucle de rétroaction temporelle. Ce qui est intéressant, c'est que plus nous sommes bas, plus vite nous pouvons amener le système d'exploitation à répondre aux questions nécessaires.

C'est un sujet de discussion plutôt intéressant, car dans notre industrie informatique, il est possible d'obtenir rapidement un système d'exploitation. Imaginez à quel point il est pénible de réaliser un projet pendant six mois et de découvrir ensuite seulement qu'il y a eu une erreur au tout début. Cela se produit lors de la conception et de toute construction de systèmes complexes.

Dans notre cas d'IaC, les commentaires nous aident. Je vais immédiatement apporter un petit ajustement au schéma ci-dessus : le plan de publication n'a pas de cycle mensuel, mais a lieu plusieurs fois par jour. Il existe certaines pratiques liées à ce cycle du système d'exploitation que nous examinerons plus en détail.

Important : les commentaires peuvent être une solution à tous les problèmes mentionnés ci-dessus. Combiné aux pratiques XP, cela peut vous sortir de l’abîme du désespoir.

Comment se sortir du gouffre du désespoir : trois pratiques

Tests

Les tests sont mentionnés deux fois dans la boucle de rétroaction XP. Ce n'est pas juste comme ça. Ils sont extrêmement importants pour l’ensemble de la technique Extreme Programming.

On suppose que vous disposez de tests unitaires et d'acceptation. Certains vous donnent leur avis en quelques minutes, d’autres en quelques jours, ils prennent donc plus de temps à rédiger et sont révisés moins souvent.

Il existe une pyramide de tests classique, qui montre qu’il devrait y avoir davantage de tests.

Comment ce cadre s’applique-t-il à nous dans un projet IaC ? En fait... pas du tout.

• Les tests unitaires, même s'ils devraient être nombreux, ne peuvent pas être trop nombreux. Ou alors ils testent quelque chose de manière très indirecte. En fait, on peut dire que nous ne les écrivons pas du tout. Mais voici quelques applications de tels tests que nous avons pu réaliser :
  1. Test du code jsonnet. Il s’agit par exemple de notre pipeline d’assemblage de drones, qui est assez compliqué. Le code jsonnet est bien couvert par les tests.
     Nous utilisons ceci Cadre de tests unitaires pour Jsonnet.
  2. Teste les scripts exécutés au démarrage de la ressource. Les scripts sont écrits en Python et des tests peuvent donc être écrits dessus.
• Il est potentiellement possible de vérifier la configuration lors de tests, mais nous ne le faisons pas. Il est également possible de configurer des règles de configuration des ressources de vérification via silex. Cependant, les vérifications y sont tout simplement trop basiques pour Terraform, mais de nombreux scripts de test sont écrits pour AWS. Et nous sommes sur Azure, donc cela ne s'applique pas encore une fois.
• Tests d'intégration de composants : cela dépend de la façon dont vous les classez et de l'endroit où vous les placez. Mais en gros, ils fonctionnent.

  Voici à quoi ressemblent les tests d'intégration.

  
  
  Ceci est un exemple lors de la création d'images dans Drone CI. Pour les atteindre, il faut attendre 30 minutes que l'image Packer se forme, puis attendre encore 15 minutes pour qu'elles passent. Mais ils existent !

  Algorithme de vérification d'image

  1. Packer doit d’abord préparer complètement l’image.
  2. À côté du test se trouve une terraform avec un état local, que nous utilisons pour déployer cette image.
  3. Lors du dépliage, un petit module situé à proximité est utilisé pour faciliter le travail avec l'image.
  4. Une fois la VM déployée à partir de l'image, les vérifications peuvent commencer. Fondamentalement, les contrôles s'effectuent en voiture. Il vérifie le fonctionnement des scripts au démarrage et le fonctionnement des démons. Pour ce faire, via ssh ou winrm, nous nous connectons à la machine nouvellement créée et vérifions l'état de la configuration ou si les services sont opérationnels.

• La situation est similaire avec les tests d'intégration dans les modules pour Terraform. Voici un petit tableau expliquant les caractéristiques de ces tests.

  
  
  Le retour sur le pipeline dure environ 40 minutes. Tout se passe depuis très longtemps. Il peut être utilisé pour la régression, mais pour le nouveau développement, il est généralement irréaliste. Si vous êtes très, très préparé à cela, préparez des scripts en cours d'exécution, vous pouvez alors le réduire à 10 minutes. Mais ce ne sont toujours pas des tests unitaires, qui font 5 pièces en 100 secondes.

L'absence de tests unitaires lors de l'assemblage d'images ou de modules Terraform incite à déplacer le travail vers des services distincts exécutables simplement via REST, ou vers des scripts Python.

Par exemple, nous devions nous assurer que lorsque la machine virtuelle démarre, elle s'enregistre dans le service ÉchelleFT, et lorsque la machine virtuelle a été détruite, elle s'est supprimée d'elle-même.

Puisque nous avons ScaleFT en tant que service, nous sommes obligés de travailler avec lui via l'API. Il y avait un wrapper écrit là-bas que vous pouviez extraire et dire : « Entrez et supprimez ceci et cela ». Il stocke tous les paramètres et accès nécessaires.

Nous pouvons déjà écrire des tests normaux pour cela, car ce n'est pas différent d'un logiciel ordinaire : on se moque d'une sorte d'apiha, vous le tirez et voyez ce qui se passe.

Résultats des tests : Les tests unitaires, qui devraient donner le système d'exploitation en une minute, ne le donnent pas. Et les types de tests situés plus haut dans la pyramide sont efficaces, mais ne couvrent qu’une partie des problèmes.

Programmation en binôme

Les tests sont bien sûr bons. Vous pouvez en écrire beaucoup, ils peuvent être de différents types. Ils travailleront à leur niveau et nous feront part de leurs commentaires. Mais le problème des mauvais tests unitaires, qui donnent le système d’exploitation le plus rapide, demeure. En même temps, je souhaite toujours un système d’exploitation rapide, facile et agréable à utiliser. Sans parler de la qualité de la solution obtenue. Heureusement, il existe des techniques qui peuvent fournir un feedback encore plus rapide que les tests unitaires. Il s’agit d’une programmation en binôme.

Lorsque vous écrivez du code, vous souhaitez obtenir un retour sur sa qualité le plus rapidement possible. Oui, vous pouvez tout écrire dans une branche de fonctionnalités (pour ne rien casser à personne), faire une pull request dans Github, l'attribuer à quelqu'un dont l'avis a du poids et attendre une réponse.

Mais vous pouvez attendre longtemps. Les gens sont tous occupés et la réponse, même s’il y en a une, n’est peut-être pas de la plus haute qualité. Supposons que la réponse vienne immédiatement, que le critique comprenne instantanément l'idée dans son ensemble, mais que la réponse arrive encore tard, après coup. J'aurais aimé que ce soit plus tôt. C’est à cela que vise la programmation en binôme – dès la rédaction de cet article.

Vous trouverez ci-dessous les styles de programmation en binôme et leur applicabilité au travail sur IaC :

1. Classique, Expérimenté+Expérimenté, décalage par minuterie. Deux rôles – conducteur et navigateur. Deux personnes. Ils travaillent sur le même code et changent de rôle après une certaine période de temps prédéterminée.

Considérons la compatibilité de nos problèmes avec le style :

• Problème : imperfection des outils et outils de développement de code.
  Impact négatif : on met plus de temps à se développer, on ralentit, le rythme de travail se perd.
  Comment nous combattons : nous utilisons un outil différent, un IDE commun et apprenons également des raccourcis.
• Problème : déploiement lent.
  Impact négatif : augmente le temps nécessaire pour créer un morceau de code fonctionnel. On s'ennuie en attendant, nos mains se tendent pour faire autre chose pendant qu'on attend.
  Comment nous combattons : nous ne l’avons pas surmonté.
• Problème : manque d’approches et de pratiques.
  Impact négatif : on ne sait pas comment bien faire les choses et comment les mal faire. Rallonge la réception des commentaires.
  Comment nous combattons : l'échange mutuel d'opinions et de pratiques dans le cadre du travail en binôme résout presque le problème.

Le principal problème lié à l'utilisation de ce style dans IaC est le rythme de travail inégal. Dans le développement logiciel traditionnel, vous avez un mouvement très uniforme. Vous pouvez passer cinq minutes et écrire N. Passez 10 minutes et écrire 2N, 15 minutes - 3N. Ici, vous pouvez passer cinq minutes et écrire N, puis passer encore 30 minutes et écrire un dixième de N. Ici, vous ne savez rien, vous êtes coincé, stupide. L'enquête prend du temps et détourne l'attention de la programmation elle-même.

Conclusion : sous sa forme pure, il ne nous convient pas.

2. Ping-pong. Cette approche implique qu’une personne rédige le test et qu’une autre effectue sa mise en œuvre. Compte tenu du fait que tout est compliqué avec les tests unitaires, et qu'il faut écrire un test d'intégration qui prend beaucoup de temps à programmer, toute la facilité du ping-pong disparaît.

Je peux dire que nous avons essayé de séparer les responsabilités pour la conception d'un script de test et la mise en œuvre du code correspondant. Un participant a proposé le scénario, dans cette partie du travail dont il était responsable, il avait le dernier mot. Et l’autre était responsable de la mise en œuvre. Cela a bien fonctionné. La qualité du scénario avec cette approche augmente.

Conclusion : hélas, le rythme de travail ne permet pas d'utiliser le ping-pong comme pratique de programmation en binôme en IaC.

3. Style fort. Pratique difficile. L’idée est qu’un participant devient le navigateur directif et que le second joue le rôle de pilote d’exécution. Dans ce cas, le droit de prendre des décisions appartient exclusivement au navigateur. Le conducteur imprime uniquement et peut influencer ce qui se passe avec un mot. Les rôles ne changent pas pendant longtemps.

Bon pour apprendre, mais nécessite de solides compétences générales. C'est là que nous avons hésité. La technique était difficile. Et ce n'est même pas une question d'infrastructure.

Conclusion : cela peut potentiellement être utilisé, nous ne renonçons pas à essayer.

4. Mobbing, swarming et tous les styles connus mais non répertoriés Nous ne le considérons pas, parce que Nous ne l’avons pas essayé et il est impossible d’en parler dans le cadre de notre travail.

Résultats généraux sur l'utilisation de la programmation par paires :

• Nous avons un rythme de travail inégal, ce qui prête à confusion.
• Nous nous sommes heurtés à des soft skills insuffisamment bonnes. Et ce domaine ne nous aide pas à surmonter nos lacunes.
• Les longs tests et les problèmes avec les outils rendent le développement en binôme difficile.

5. Malgré cela, des succès ont été enregistrés. Nous avons imaginé notre propre méthode « Convergence - Divergence ». Je vais décrire brièvement comment cela fonctionne.

Nous avons des partenaires permanents pour quelques jours (moins d'une semaine). Nous accomplissons une tâche ensemble. Nous restons assis ensemble pendant un moment : l'un écrit, l'autre s'assoit et regarde l'équipe d'assistance. Ensuite, nous nous dispersons pendant un certain temps, chacun fait des choses indépendantes, puis nous nous réunissons à nouveau, nous synchronisons très rapidement, faisons quelque chose ensemble et nous nous dispersons à nouveau.

Planification et communication

Le dernier bloc de pratiques grâce auquel les problèmes du système d'exploitation sont résolus est l'organisation du travail avec les tâches elles-mêmes. Cela inclut également l’échange d’expériences en dehors du travail en binôme. Examinons trois pratiques :

1. Objectifs à travers l’arbre des objectifs. Nous avons organisé la gestion globale du projet à travers un arbre qui va sans fin dans le futur. Techniquement, le suivi se fait dans Miro. Il y a une tâche : c’est un objectif intermédiaire. De là partent soit des objectifs plus petits, soit des groupes de tâches. Les tâches elles-mêmes viennent d'eux. Toutes les tâches sont créées et maintenues sur ce tableau.

Ce système fournit également un retour d'information, qui se produit une fois par jour lorsque nous nous synchronisons lors de rallyes. Avoir un projet commun devant tout le monde, mais structuré et totalement ouvert, permet à chacun d’être conscient de ce qui se passe et du chemin parcouru.

Avantages de la vision visuelle des tâches :

• Causalité. Chaque tâche mène à un objectif global. Les tâches sont regroupées en objectifs plus petits. Le domaine de l'infrastructure lui-même est assez technique. Il n'est pas toujours clair quel impact spécifique, par exemple, l'écriture d'un runbook sur la migration vers un autre nginx, a sur l'entreprise. Avoir la carte cible à proximité rend les choses plus claires.
  
  La causalité est une propriété importante des problèmes. Cela répond directement à la question : « Est-ce que je fais la bonne chose ? »
• Parallélisme. Nous sommes neuf et il est tout simplement physiquement impossible de confier tout le monde à une seule tâche. Les tâches d’un seul domaine ne suffisent pas toujours non plus. Nous sommes obligés de paralléliser le travail entre petits groupes de travail. En même temps, les groupes restent assis sur leur tâche pendant un certain temps, ils peuvent être renforcés par quelqu'un d'autre. Parfois, des gens se détachent de ce groupe de travail. Quelqu'un part en vacances, quelqu'un fait un rapport pour la conférence DevOps, quelqu'un écrit un article sur Habr. Savoir quels objectifs et quelles tâches peuvent être réalisés en parallèle devient très important.

2. Remplacement des présentateurs des réunions du matin. Dans les stand-ups, nous avons ce problème : les gens effectuent de nombreuses tâches en parallèle. Parfois, les tâches sont vaguement liées et on ne sait pas qui fait quoi. Et l’avis d’un autre membre de l’équipe est très important. Il s'agit d'informations supplémentaires qui peuvent changer le cours de la résolution du problème. Bien sûr, il y a généralement quelqu'un avec vous, mais les conseils et astuces sont toujours utiles.

Pour améliorer cette situation, nous avons utilisé la technique « Changer le Leading Stand-Up ». Maintenant, ils tournent selon une certaine liste, et cela a son effet. Quand c'est votre tour, vous êtes obligé de plonger et de comprendre ce qui se passe afin d'organiser une bonne réunion Scrum.

3. Démo interne. L'aide à la résolution d'un problème grâce à la programmation en binôme, la visualisation sur l'arbre à problèmes et l'aide lors des réunions Scrum le matin sont bonnes, mais pas idéales. En couple, vous n'êtes limité que par vos connaissances. L’arborescence des tâches permet de comprendre globalement qui fait quoi. Et le présentateur et ses collègues de la réunion du matin n'approfondiront pas vos problèmes. Ils pourraient certainement manquer quelque chose.

La solution a été trouvée en se montrant mutuellement le travail effectué et en en discutant ensuite. Nous nous réunissons une fois par semaine pendant une heure et montrons les détails des solutions aux tâches que nous avons effectuées au cours de la semaine dernière.

Lors de la démonstration, il est nécessaire de révéler les détails de la tâche et de s'assurer de démontrer son fonctionnement.

Le rapport peut être réalisé à l’aide d’une liste de contrôle.1. Entrez dans le contexte. D'où venait cette tâche, pourquoi était-elle même nécessaire ?

2. Comment le problème a-t-il été résolu auparavant ? Par exemple, il fallait cliquer massivement avec la souris, ou il était impossible de faire quoi que ce soit.

3. Comment nous l'améliorons. Par exemple : « Regardez, maintenant il y a scriptosik, voici le fichier readme. »

4. Montrez comment cela fonctionne. Il est conseillé d'implémenter directement un scénario utilisateur. Je veux X, je fais Y, je vois Y (ou Z). Par exemple, je déploie NGINX, je fume l'URL et j'obtiens 200 OK. Si l’action est longue, préparez-la à l’avance pour pouvoir la montrer plus tard. Il est conseillé de ne pas trop le casser une heure avant la démo, s'il est fragile.

5. Expliquez dans quelle mesure le problème a été résolu, quelles difficultés subsistent, ce qui n'est pas terminé, quelles améliorations sont possibles à l'avenir. Par exemple, maintenant CLI, il y aura alors une automatisation complète dans CI.

Il est conseillé à chaque intervenant de s'en tenir à 5 à 10 minutes. Si votre discours est évidemment important et prendra plus de temps, coordonnez-le à l'avance dans le canal de reprise.

Après le face-à-face, il y a toujours une discussion dans le fil de discussion. C’est ici qu’apparaissent les retours dont nous avons besoin sur nos tâches.

En conséquence, une enquête est menée pour déterminer l’utilité de ce qui se passe. Il s'agit d'un retour sur l'essence du discours et l'importance de la tâche.

Longues conclusions et quelle est la suite

Il peut sembler que le ton de l’article soit quelque peu pessimiste. C'est faux. Deux niveaux inférieurs de feedback, à savoir les tests et la programmation en binôme, fonctionnent. Pas aussi parfait que dans le développement traditionnel, mais cela a un effet positif.

Les tests, dans leur forme actuelle, ne fournissent qu'une couverture partielle du code. De nombreuses fonctions de configuration ne sont finalement pas testées. Leur influence sur le travail réel lors de l’écriture du code est faible. Cependant, les tests d'intégration ont un effet et permettent d'effectuer des refactorings sans crainte. C'est une grande réussite. De plus, avec le déplacement de l'attention vers le développement dans des langages de haut niveau (nous avons python, allez), le problème disparaît. Et vous n’avez pas besoin de beaucoup de contrôles pour la « colle » ; un contrôle général d’intégration suffit.

Le travail en binôme dépend davantage de personnes spécifiques. Il y a le facteur tâche et nos soft skills. Avec certaines personnes, cela fonctionne très bien, avec d’autres, cela fonctionne moins bien. Cela présente certainement des avantages. Force est de constater que même si les règles du travail en binôme ne sont pas suffisamment respectées, le fait même de réaliser des tâches ensemble a un effet positif sur la qualité du résultat. Personnellement, je trouve que travailler en binôme est plus facile et plus agréable.

Les moyens d'influencer le système d'exploitation de niveau supérieur - la planification et l'exécution des tâches produisent précisément des effets : un échange de connaissances de haute qualité et une qualité de développement améliorée.

De courtes conclusions en une seule ligne

• Les praticiens RH travaillent en IaC, mais avec moins d'efficacité.
• Renforcez ce qui fonctionne.
• Créez vos propres mécanismes et pratiques compensatoires.

Source: habr.com