Blog

> Actualités > Wiki Déj’ : « Une vision commune des Dév jusqu’aux Ops ? » – Questions / réponses


Wiki Déj’ : « Une vision commune des Dév jusqu’aux Ops ? » – Questions / réponses

Les Wiki’Déj étant avant tout un moment d’échanges et de partages, la présentation s’est poursuivie par une discussion avec les participants dont voici quelques brides.

O.: Le « monitoring », ce n’est pas très clair pour moi ce terme. A quoi cela correspond ?

Stéphane : On va le voir un peu plus tard avec cette notion d’indicateurs : c’est de la surveillance. Le monitoring va

– de la surveillance technique. Je vérifie que mes ressources fonctionnent à un régime établi. Je monitore, je surveille que je sais analyser mes logs (ce que me dit mon application). Je monitore des indicateurs qui me disent si je respecte bien les seuils établis (charges par rapport au nombre de requêtes par seconde etc…).  

– au niveau business.

Un exemple du monitoring

Lorsque vous rencontrez un problème avec un équipement, vous prenez la documentation et vous appelez le service concerné. Votre interlocuteur va vous indiquer que « cette conversation peut être enregistrée ». Une fois votre appel terminé, vous allez recevoir automatiquement une demande de sondage où vous évaluez la qualité du service reçu.

C’est une illustration parfaite d’éléments de monitoring ou de surveillance. L’idée est de faire une boucle de rétroaction qui va permettre, grâce aux réponses qui vont être faites, de remonter les alertes et de pouvoir ensuite les corriger.  

D. : dans un contexte où la hiérarchie est moins stricte, comment cela se passe avec les rôles ? Comment se mettent en place les circuits de décision ?

Stéphane : A travers l’équipe et la confiance qui lui ait attribuée. Et cela fonctionne ! A partir du moment où il y a une véritable volonté de la part de le l’organisation de mettre en place cette démarche et ces nouveaux modes de prise de décision. Là on revient sur la notion d’agilité.

Les circuits sont courts et les consolidations sont effectuées à chaque étape. Imaginons que la boucle DevOps est comme un circuit : si l’on met des péages ou des arrêts obligatoires, il faut savoir pourquoi on les fait.

Une recherche américaine a défini trois types d’organisation :  

  • L’organisation décisionnaire où « le chef a toujours raison ». Souvent, tout le monde suit et lorsqu’une erreur est commise, quelqu’un doit être sanctionné.
  • L’organisation administrative où la structure hiérarchique, les rôles et les décisions sont très étendues. Le processus de validation est plus long et cela a tendance à déresponsabiliser tout le monde. Cette organisation ne permet pas de prendre des risques.

L’organisation où les membres du groupe montrent leur autonomie et la prouve grâce à des indicateurs et à l’expérience. Lorsqu’il y a une alerte, je suis informé et je sais corriger. Avec ces informations, on arrive à juste informer le comité transverse et vérifier qu’il n’y a pas d’incompatibilité. On doit démontrer que l’on est autonome et résilient.


D. : C’est un véritable changement de paradigmes. Que ce soit sur la responsabilité avec la notion de rôles, la multi-compétences et aussi l’acceptation de l’échec. C’est très intéressant !

Stéphane : La multi-compétences effectivement ! Elle s’organise en intra, que ce soit au niveau de l’équipe ou des pairs. Il faut une structure au niveau de l’organisation qui favorise à ceux qui le souhaitent de pouvoir montée en compétences : formations, retours d’expérience, accompagnement par un expert…

Les besoins sont différents en fonction des niveaux et des demandes des organisations.

R. : On voit qu’il y a un changement culturel à effectuer pour ceux qui souhaitent entamer une démarche DevOps. Avez-vous des retours d’expérience sur comment cela est vécu par le client final, qui lui, peut parfois rester sur des process plus classiques ? Avec des mises en production plus fréquentes, le client paraît un peu sorti du processus de validation de ce qu’on lui met à disposition.

Dans le cas de nos projets, le client final effectue sa propre recette pour valider qu’il n’y a pas de régression.

Stéphane : le client pour moi, on va le mettre comme « équipe de production ». C’est une équipe qui va produire et livrer quelque chose. Ici, il va mettre à disposition auprès des utilisateurs. Si je comprends bien ton contexte, la chaîne est : un prestataire qui livre un logiciel à un client. Celui-ci fait la recette et met à disposition auprès d’utilisateurs.

Pour moi, le premier travail à faire est de travailler de manière plus unifiée côté production entre le prestataire et le client. Visons les utilisateurs ! Concernant la fréquence, si quelqu’un qui produit une nouvelle fonctionnalité veut attendre 6 mois pour le faire, on met en place une procédure de 6 mois.

Dans ton cas, je pense que l’on est plus dans un processus de facturation que de validation et ce n’est plus une notion de production vis-à-vis de l’utilisateur. Le client final travaillera avec le prestataire pour établir le processus de validation le plus adapté.

Il ne faut pas oublier que sur des projets, la notion de temps est une notion de coûts et de ressources. Par exemple, si un développeur fait une erreur sur une fonctionnalité qu’il livre à un utilisateur et que l’on attend 3 mois pour la corriger, il ne se souviendra peut-être plus ou ne sera peut-être plus sur le projet. C’est une notion de charge corrective. Plus l’on va vite dans les processus pour mettre dans les mains du client, plus l’on voit rapidement si c’est efficace et si ça fonctionne.

O. : C’est là aussi où l’on revient sur le concept de l’erreur avec le fait de livrer plus vite ?

Stéphane : Non, la qualité ne doit jamais être au détriment de l’utilisateur final. On conserve les règles de base des bons principes. On ne va pas plus vite en diminuant la qualité, car il faudra repasser ensuite par des boucles correctives. Il s’agit plutôt de chercher à automatiser les tâches qui sont effectuées en manuel tout en les optimisant efficacement. Valider du code, ça s’appelle la couverture de code et ça se réalise à chaque ligne de code au niveau du développeur. Ensuite, on fait du test unitaire sous l’environnement de développement. Je prouve à tout moment que j’ai bien développé ma fonctionnalité en mettant un indicateur (log ou autre). Et lorsque ça ne fonctionne pas, je le dis aussi. La validation se fait le plus tôt possible et s’adapte à l’environnement associé. Chaque plateforme vérifie son niveau de conformité : plus on va vers la production, plus on travaille sur la redondance, la performance et la stabilité.

En cas de conflits, tout est écrit dans le code et on peut solutionner rapidement.

L’automatisation est la clé. Dans le DevOps, elle représente 30 %.

R. : Ce que j’ai remarqué, c’est que les freins proviennent plus souvent du client que de l’interne par rapport au produit que nous développons.

Stéphane : Dégrader la qualité, c’est pire que tout. Ça fait éclater la confiance que l’organisation peut avoir sur une équipe voir au sein de l’équipe.

C. : Nous, le développeur a tendance à se souvenir seulement de ce sur quoi il travaille sur le moment. Donc quand il a fini de développer quelque chose, il nous fait un package et nous demande tout de suite de valider pour que ce soit frais et bon. Tant que l’on n’a pas validé, il ne passe pas à la demande suivante. C’est un gain de temps !

Stéphane : Ce que j’aime bien dans cet exemple, on valide et on teste rapidement. C’est bon pour le développeur mais aussi pour vous qui validez, car c’est aussi frais pour vous et vous consolider votre jeu de test.

A quelle temporalité les packages et correctifs vont-ils en production ?

C. : sur notre projet (application de déclaration de paie), on met des mises à jour en production par rapport aux mises à jour législatives. Nos temporalités sont définies en fonction des évolutions législatives.

Je fais partie d’une équipe qui réalise de l’assistance aux utilisateurs sur l’applicatif.

Stéphane : cela mélange du planifié avec du non-planifié effectivement. Au niveau organisation, c’est toujours compliqué.

Le travail non-planifié fait partie du quotidien. En fonction du métier, il y aussi des tâches planifiées et il faut harmoniser.

Ce que je retiens surtout, c’est de travailler sur des petits incréments car cela permet de maîtriser ce que l’on fait, de mieux le communiquer (y compris à l’utilisateur). Les fréquences de déploiement en production sont liées à cette notion d’incrément.

L. : on gagne aussi au niveau de la non-régression !

Stéphane : et cette notion est très importante ! ça permet de voir si l’impact est mineur, majeur etc…

Là on revient sur de l’agilité au stade de la conception. Quand on fait une user storie, dans les tâches, on retrouve « qu’est-ce que l’on doit prouver ? Faire ? » Donc ça veut dire les tests derrière.


On espère que cela vous a éclairé un peu plus sur le concept de DevOps, et on vous donne rendez-vous pour le dernier volet de la trilogie avec le CI/CD !

Si vous souhaitez aller plus loin, voici quelques références transmises par Stéphane  :


Morgan

À propos de l'auteur

Morgan | Actuellement Consultante RH pour Philae, j'ai débuté ma carrière sur la partie recrutement. Aimant le contexte ingénierie / conseil, J'ai intégré Philaë en 2016 en tant que Responsable des Ressources Humaines. J'interviens à la fois sur le recrutement de nos futurs collaborateurs, et sur leur accompagnement RH. J'accompagne aussi l'entreprise sur les projets RH et leur pilotage.