La Démarche IT Performance (par Yann Le Thieis)

Avec L’accord de son auteur (Yann Le Thieis), je vous partage un bel article sur la démarche performance IT.

Yann Le Thieis, est un expert Indépendant IT :

• CV
• Blog
• Article

---

Partage de l’article :

Les enjeux de la performance

Parmi les qualités attendues d’un système d’information, la performance est une des plus attendues. Elle est peut-être la plus perceptible ou du moins une des plus sensibles du point de vue des utilisateurs quand elle n’est pas au rendez-vous.

Pourtant, c’est encore souvent aujourd’hui une exigence non fonctionnelle qui n’est pas formulée en amont. Le niveau de performance est vérifié très tardivement dans le cycle projet, lors de la finalisation du produit ou encore en préproduction. Le principal argument donné étant « A quoi cela sert de tester la performance hors du contexte de production du SI ? ».

Plus alarmant encore, le constat d’un système ne répondant pas aux exigences de performance ne se fait qu’en production. Un audit de performance est alors requis et les conséquences peuvent alors être très lourdes, que ce soit du point de vue financier, des délais, d’image de marque…

Les enjeux de la performance répondent à des critères de qualité et de satisfaction. Il en va de l’image de l’entreprise. Au-delà de ces enjeux, la performance apporte aussi des bénéfices dans la rationalisation des ressources, en productivité et pérennise le service de l’application.

Une application web qui répond mal à la charge induite par les utilisateurs va voir diminuer la rétention de ces derniers et l’entreprise perdre en conversion de ses clients.

La non performance coûte cher…

Gérer la performance a un coût mais la démarche curative de résolution des problèmes de performance amène avec elle une évolution exponentielle des coûts de retour en arrière. Il ne faut pas se leurrer, le tuning d’un système en production ne résout pas les problèmes de performance et la multiplication des ressources machines n’est jamais une solution s’il n’y a pas le contrôle du besoin en consommation de ces ressources.

Si l’on reste dans une démarche curative pour la résolution des problèmes de performance rencontrés en production, alors :

• L’évolution des coûts de retour en arrière est exponentielle.
• Les délais de mise en production sont allongés.

 

Le risque de la non performance

Augmentation exponentielle du coût de retour en arrière

La démarche IT performance

Les tests de performance et notamment les tests de charge sont généralement pratiqués sur des environnements au plus proche de la cible, c’est à dire aussi proche que possible des conditions de la production. Ces tests permettent de se rassurer sur la capacité de l’application web à tenir ses promesses et de répondre aux exigences techniques définies dans le dossier d’architecture. Est-ce que l’application va tenir la charge imposée par le nombre d’utilisateurs attendus ? Au-delà ? Est-ce que les temps de réponses seront au rendez-vous et contenus ? L’application, va t’elle pouvoir faire face à un afflux supplémentaire inattendu d’utilisateurs ? Comment l’application se comporte sous la charge sur une longue période ? Est-elle robuste à la panne ? Autant de questions auxquelles les tests de charge permettent d’y répondre. Ces tests sont nécessaires et imposés en fonction du risque encouru en cas de défaut.

Les tests de charge, tels que décrits ci-dessus, font bien sûr partie de la démarche IT performance, mais se situent en bout de chaine dans le cycle (ou les cycles) de développement d’une application. Ils permettent d’évaluer le nombre d’utilisateurs que pourra supporter votre application, d’atteindre un haut degré de confiance avant le lancement de l’application en production.

La démarche IT performance, comme nous allons le voir, vise à identifier et à actionner tous les leviers possibles de sécurisation de la performance, si nécessaires, tout au long du cycle de développement de l’application.

Par exemple, des tests récurrents de performance, pratiqués avec une charge moindre mais constante d’un test à l’autre, permettent d’évaluer la non régression des performances de l’application sur certaines fonctionnalités. Ces tests peuvent se pratiquer bien en amont de la mise en production, à chaque fin de sprint pour un produit développé en mode agile, à chaque release …

La démarche performance, au fond, c’est quoi ?

La démarche performance est une démarche transverse. Elle est inter-filières et concerne toutes les disciplines d’un projet. Elle fait intervenir la performance au plus tôt et se déroule tout au long du cycle de vie du produit, de l’analyse des exigences au suivi des indicateurs de performance en production. Elle doit donc s’intégrer dans la démarche ou plutôt la stratégie du projet.

Il y a une notion de progression dans les tests qui peuvent être pratiqués, de développement itératif des tests de performance au fur et à mesure de l’implémentation et de modifications de fonctionnalités critiques du produit. On peut parler alors de plateforme de performance continue (PPC).

Une réponse au niveau du risque performance

La mise en œuvre complète d’une démarche IT performance ne doit pas être systématique, elle doit être adaptée aux enjeux et aux risques de non performance pour tel ou tel produit. Elle doit donc répondre au niveau du risque de performance de l’application.

Par exemple, si nous définissons le risque sur 3 niveaux d’importance, comment la démarche IT performance y répond ?

Une réponse au niveau du risque

Risque 0 – Consultation :

• Pas de risque performance détecté, l’équipe de tests est consultée pour valider.

Risque 1 – Tests en cible :

• Un risque performance est détecté.
• L’équipe de tests est consultée pour valider.
• Challenge des exigences.
• Consultation des acteurs.
• Définition des objectifs.
• Le RACI et le planning sont définis.
• La campagne est programmée sur un environnement cible iso-production.

Risque 2 – Tests en phase Réalisation du projet :

• Définition des objectifs de tests en phase de DEV (tuning, non régression, dimensionnement, …).
• Une ou plusieurs campagnes programmées (mode itératif).
• TNR : Tests de non régression des performances applicatives.

Risque 3 – Conseil et tests en phase Etude

• Aide au choix de solutions et architecture.
• Tests de POC.

En fonction d’un niveau de risque nous n’actionnons pas systématiquement tous les leviers de performance à notre disposition. La réponse doit être adaptée !

Adapter le périmètre au niveau du risque performance

Pour pouvoir répondre au niveau du risque performance, il faut pour cela impliquer les bons acteurs au bon moment !

adaptation du périmètre

1. L’équipe de tests doit être sollicité par le projet dès la phase « Etude » si le risque performance est détectée.
2. Tous les acteurs doivent être consultés à minima.
3. La démarche performance vise à prévenir la détection de problèmes de performance trop tard, lors de tests en phase d’intégration en Exploitation.

1. Solliciter l’expertise de tests de performance en phase amont du projet

Comment et quand solliciter la cellule de tests de performance ?

sollicitation expertise de performance

Un déclencheur pour ne pas oublier d’intégrer le processus des Tests de performance dans le processus projet :

• Inclure des questions sur les exigences et les tests de performance dans l’outil de scoring existant pour les chefs de projet Etude.

Si un risque est détecté au niveau du scoring, il faut alors solliciter la cellule de tests dans la phase d’Etude projet pour challenger les exigences de performance et avoir une évaluation du coût et des actions à mener en fonction :

• Des choix de solutions.
• Des objectifs.
• Des fonctionnalités attendues de l’application (à défaut des scénarios métier).

La sollicitation de la cellule de tests en début de projet doit être vu comme une demande d’accompagnement (mode support de la cellule de tests de performance pour son expertise).

Enfin, l’équipe de tests vous accompagne en début de réalisation du projet dans la définition des entrants. Elle intervient pour reformuler les besoins et les exigences qui seront à prendre en compte dans le processus des tests de performance.

2. Consulter et impliquer les différents acteurs en phase amont du projet

impliquer les acteurs

Il faut faire intervenir les différents acteurs dès le début de la phase de réalisation du projet afin d’apporter leur support à la définition de la stratégie des tests dans la globalité, de définir les actions, charges et rôles de chacun ainsi que la planification. C’est à ce moment-là, aussi, qu’une attention particulière doit être portée sur les environnements de tests et en l’occurrence les environnements utilisés par les différents tests de performance qui pourront avoir lieu.

Dans tous les cas, tous les “contributeurs” doivent être consultés à minima pour permettre éventuellement l’émergence d’exigences qui pourraient ne pas être décelées par l’équipe projet.

3. Intégrer la démarche performance dans le cycle de vie du projet

phases projet

• Définition précise des objectifs de performance.
• Aide à la décision.
• Répondre aux objectifs de performance par l’architecture.
• Suivi régulier des niveaux de performance sous charge unitaire.
• Campagne de tests de performance.
• Monitoring et supervision.

Le risque performance est maîtrisé dans une démarche projet !

La performance fait partie des besoins exprimés par le client qui sont traduits en exigences. Il faut maîtriser ces exigences de performance pour garantir une qualité de service alignée sur les exigences métier et les engagements associés (SLA).

Optimiser le code produit

Une des activités projet qui peut être fortement impactée en cas de défaut de performance est celle du développement du code de l’application. Si rien n’est fait pour sécuriser, dans une certaine mesure, le code produit vis à vis des performances, alors nous pouvons être confronté à un retour arrière important pouvant aller jusqu’à une refonte complète du code de l’application.

Optimiser les performances pour répondre aux objectifs

Le code est évalué et optimisé suite à des audits d’experts ou par des revues de code croisées entre développeurs de l’équipe comme cela se fait en application de méthodes agiles de développement. Cet audit de code peut être automatisé par l’application de règles de contrôle dédiées dans le cadre d’une plateforme d’intégration continue (PIC).

La sensibilisation des développeurs à la performance par de la formation et en capitalisant sur l’expérience projet de l’équipe de développement permet aussi une nette amélioration de la qualité et de la performance du code.

Dans un déroulement de projet en itérations, l’automatisation des tests dans le cadre de la mise en place d’une plateforme de performance continue (PPC), permet aux développeurs d’avoir la main sur l’évolution des performances applicatives et de contrôler les régressions de performance des composants développés.

Ne pas oublier que l’optimisation des performances n’est pas toujours compatible avec la maintenabilité du code : il s’agit d’optimiser pour répondre aux objectifs et non pas optimiser pour optimiser !

Répondre aux exigences de performance requiert des expertises couvrant le spectre des domaines des compétences projets et exploitation.

Ce qu’il faut retenir d’une démarche IT Performance ? Les points principaux

Une démarche IT Performance permet d’adapter le périmètre des tests de performance au niveau du risque encouru. Elle doit être intégré au plus tôt dans la stratégie du produit. Le risque performance est maitrisé dans une démarche projet. Enfin, plus que tout, la démarche IT Performance implique un large spectre de compétences et est une activité transverse, la première action à réaliser sera donc de sensibiliser tous les acteurs d’un projet.

---