Dans l’organisation DevOps, les performances et les responsabilités se partagent. Comment favoriser la collaboration entre les équipes, pour accélérer et sécuriser les mises en production ?

Dans un contexte de forte pression business, par exemple pour le e-commerce en période de pic en fin d’année (mais pas que : les appels d’échéances dans le secteur des assurances, le règlement des factures d’énergie, ou l’augmentation des déplacements et transports), vos équipes en charge de vos applications critiques (métiers, ingénieurs, testeurs, exploitants) peuvent rapidement se retrouver submergées d’informations avec les outils de monitoring traditionnels. Comment alors être sûr qu’elles utilisent la bonne information, au bon moment, pour prendre la bonne décision ? En favorisant les bonnes pratiques de collaboration, pour que chaque partie prenante de votre équipe DevOps améliore ses performances, individuellement et collectivement, sans régression.

Conseil n°1 pour chacun : la bataille ne se gagne pas tout seul

Les mauvaises décisions se prennent souvent par manque de communication entre les équipes, par exemple de développement et d’administration de base de données, ou même de marketing, et une méconnaissance des objectifs individuels de chacun. Dans les périodes de rush, chacun a tendance à se replier sur ses propres tâches, afin de s’assurer de faire ce qu’il faut, à son niveau, pour éviter un problème majeur. Mais c’est justement dans ces situations stressantes qu’il faut pouvoir s’appuyer sur des relations solides. La bataille ne se gagne pas seul, mais avec l’ensemble des équipes.

D’où l’importance de collaborer, en particulier quand il est question de performance, puisqu’une grande partie de l’information se répartit entre les différentes équipes. Plutôt qu’un micro-management par équipe et qu’un découpage trop détaillé, partagez la vision globale des projets et évolutions à venir avec les enjeux associés. Vous gagnerez en cohésion globale et permettrez de décider des KPI transverses et compréhensibles pour l’ensemble de vos équipes.

Conseil n°2 pour tous : une bonne équipe DevOps partage les responsabilités

La notion de responsabilité est indissociable de celle de la performance. Traditionnellement, il était d’usage, en cas de problème, de partir à la chasse aux coupables, chaque équipe se rejetant mutuellement la cause, usant souvent pour cela de simples indicateurs de disponibilité, malheureusement peu représentatifs de la réalité subie par les vrais utilisateurs. C’est justement contre tout cela que le concept de DevOps s’érige.

Dans le monde DevOps et du continuous delivery, chacun est en partie responsable. Tout le monde se partage la responsabilité d’un problème même s’il n’est pas directement concerné, et travaille ensemble à sa résolution afin d’éviter toute régression sur les performances au sens large. En d’autres termes, il s’agit d’être responsable du résultat de son travail, tout en veillant à supprimer les obstacles et les silos qui freinent l’ensemble du processus de production logicielle.

Conseil n°3 pour les métiers : concentrez-vous sur la performance attendue par vos utilisateurs

Les business analysts et les responsables de produits sont souvent évalués au nombre de fonctionnalités qu’ils mettent en production, plutôt qu’à leur valeur réelle pour les utilisateurs. Ce qui aboutit généralement à une jungle de fonctionnalités dans laquelle l’utilisateur se perd. En parallèle, on constate souvent un écart entre les idées innovantes proposées par les designers et leur faisabilité technique. Les développeurs se retrouvent alors avec des maquettes trop complexes, impossibles à intégrer dans les frameworks UI disponibles.

Ce qui fait défaut ici ? La connaissance et la prise en compte de ce que veulent réellement les utilisateurs finaux. Impliquez vos utilisateurs et vos ingénieurs dans vos processus. Concentrez-vous sur les 20 % de fonctionnalités qui importent aux 80 % de vos utilisateurs – et non l’inverse. Pensez léger, clean et responsive. Car il ne suffit pas d’un beau design et d’une bonne idée marketing pour séduire les utilisateurs : il faut aussi que les performances soient au rendez-vous.

Conseil n°4 pour les ingénieurs : plus de qualité en amont = moins de dette technique en aval

Les ingénieurs et les développeurs-architectes ont tendance à voir la performance par le prisme du nombre de story points qu’ils implémentent. Au risque parfois de laisser des erreurs communes subsister tout au long du cycle de vie applicatif, du design du prototype jusqu’à sa mise en production – fuites de mémoire, requêtes SQL trop nombreuses, sans compter sur les variables des contextes de production qui restent imprévisibles (pic d’activité, raccourcis officieux dans l’application, les performance réseaux et Internet…)

Les choses évoluent toutefois, avec l’approche par micro-services, qui permet de compartimenter et d’optimiser les développements en isolant les différentes fonctionnalités. À condition toutefois de faire des analyses de performance tout au long du processus de production, via des revues de code et d’architecture. Et non pas à posteriori, une fois que les utilisateurs sont déjà potentiellement impactés.

Intégrer une démarche qualité dès le départ permet d’éviter d’accumuler ensuite une dette technique, et de perdre du temps à corriger des bugs et à travailler sur des problématiques de support (sans parler des incontournables cellules de crises organisées !).

Conseil n°5 pour les testeurs : Mettez vos outils de développement et de tests au service de la Qualité

Même si les rapports de tests sont complets et réalisés avec des outils efficaces, la plupart n’ont tout simplement pas de sens pour les équipes d’ingénieurs. C’est pourquoi il est essentiel que testeurs et ingénieurs collaborent étroitement, afin de déterminer sur quels indicateurs ils doivent travailler et comment ils doivent les tester.

Cela demande de la part des testeurs de monter en compétences, en assimilant un certain nombre d’éléments contextuels pour voir plus loin que les simples problèmes fonctionnels. Familiarisez-vous simplement dans un premier temps avec Tomcat, JBoss, Spring ou encore ASP.NET., avec les pools de connexions, ou encore avec le nombre d’appels en base de données acceptables en fonction du type de transaction. Dans un second temps, partagez la vision de la Production de demain et des solutions technologies d’industrialisation IT telles que Docker, Jenkins, Mesos, Kubernetes ou OpenShift, pour n’en citer que quelques-unes… Des outils de développement existent aujourd’hui pour permettre aux testeurs de passer à la vitesse supérieure et de mieux communiquer, plutôt que de simplement créer des rapports d’incidents.

Le partage d’expertise : voilà la clé du succès !

Conseil n°6 pour les exploitants : faites des feedbacks

Il n’est pas rare que des applications soient mises en production, malgré quelques imperfections connues ou inconnues : nombre trop limité de connexions par défaut à la base de données, requêtes en base de données non optimisées, etc. Ce qui fonctionne sur la machine d’un développeur, sur une petite base de données de démo, ne fonctionnera assurément pas dans la vraie vie, en production, malgré les efforts de la Production à mettre la plus grosse base de données du marché à disposition. Les administrateurs systèmes et de base de données doivent bien sûr travailler en amont avec les ingénieurs et les développeurs pour déterminer la meilleure façon de procéder, avant la mise en production.

Mais c’est aussi aux équipes d’exploitation d’apprendre à collaborer avec les équipes d’ingénierie, de développement et de tests, et à leur fournir des feedbacks sur ce qu’est le monde réel en production. Et ce afin que, dès le départ, toutes les best practices soient appliquées et testées. L’expertise des équipes d’exploitation, et leur capacité à la communiquer, jouent un rôle fondamental dans la montée en compétence des membres d’une équipe DevOps.

__________
Jérôme Thomas est Sales Engineer chez Dynatrace