Retour d expérience RATP. Intégrer le test de performance au cœur du processus de développement agile. Challenges, techniques, résultats.

Transcription

1 Retour d expérience RATP Intégrer le test de performance au cœur du processus de développement agile. Challenges, techniques, résultats.

2 Les intervenants Alexis Bourgeois Chef de projet MOE (front web) Anis Zouaoui CTO Bruno Duval VP Pro. Services Pilote et coordonne la mise en service de l application ibus Assurance de Qualité Technique Fournit l outil de test de charge et de performance

3 L application IBus Le projet IBus Refonte d une applications existante destinées à la population machiniste BUS Objectifs Un portail unique pour toute l entreprise pour renforcer la cohésion de groupe (plus d éditorial en doublon) Rationaliser et homogénéiser des systèmes conformes aux normes RATP S inscrire dans une perspective d évolution des habitudes utilisateurs (diversités des supports mobiles) Services proposés Etre tenu informé des travaux en cours sur les voies de circulation Consulter ses horaires de service Echanger un service avec un collègue Echanger des messages avec son manager en s affranchissant du mail Poser des congés Etc.

4 Architecture de l application IBus

5 Les challenges liés à la performance Plus de utilisateurs Les utilisateurs accèdent à leurs services plusieurs fois dans la journée Des heures de pic de fréquentation précises Pics de pages vues / heures

6 Le coût d un problème de performance détecté tardivement Mise en production d une nouvelle application suivie de problèmes de performances Fonctionnement ok en interne mais très lent depuis l extérieur de l entreprise Impact technique : 10 experts (applicatif, infrastructure, réseau, externes) mobilisés pendant 8 jours pour auditer le système soit 80 jours/h Impact fonctionnel : une expérience qui met à mal la vision de l application et affaiblit l adhésion des utilisateurs

7 Intégrer la performance dans le processus de développement Volonté de la RATP de maitriser la performance : Tout au long du cycle de vie des projets (THINK, BUILD, RUN) De bout en bout (de la vue utilisateur à la vue technique) Une nécessité pour assurer la qualité et la pérennité des applications Une obligation pour répondre à l «effet Google» : tout le monde s attend à ce que l application marche et soit rapide

8 La performance: un défit à plusieurs dimensions Performance Perçue Usage Charge interne, Charge externe, Vieillissement de données, batchs Applications Pools, threads, connections, cache, algorithmique, bonne pratiques, synch/asynch, compression, échanges, indexation, etc. Ressources Dimensionnement, OS, cpu, mémoire, réseaux, disques, volumétrie, etc.

9 La démarche de gouvernance de la performance RATP Gestion des EXIGENCES DIMENSIONNEMENT des architectures Gestion de la CAPACITÉ Définition des exigences en terme de performance Définition des modèles de charges Dimensionnement des architectures techniques Préparation de la performance Benchmarking et analyse des risques techniques Mesure de la capacité des systèmes critiques (en terme de performance, disponibilité, stabilité) Prédiction de la capacité future du système THINK BUILD RUN THINK BUILD RUN THINK BUILD RUN TESTS de performance AUDITS de performance SURVEILLANCE de la performance Les différents types tests pour mesurer, analyser et prévoir la performance Outillage, processus et organisation en place Les audits techniques (BD, OS, applicatif, réseau, disque, etc.) Contexte et moyen mis en œuvre Les types de surveillance en place (réseaux, système, applicatif, temps de réponse) Couverture de la surveillance THINK BUILD RUN THINK BUILD RUN THINK BUILD RUN

10 La démarche de gouvernance de la performance RATP - Moyens OUTILS CONNAISSANCE GOUVERNANCE de la Performance ACTEURS ET COMITÉS PROCESSUS

11 Tests de performance et Agilité : 2 dimensions Méthode de développement Agile Traditionnelle En cascade Comment intégrer le test de performance dans un processus Agile? Méthode de test Agile Traditionnelle En cascade Comment être plus Agile dans les tests de performance?

12 Tester en mode agile Un testeur de performance se doit d être agile, même si on le présente au management comme du «en cascade», design, exécution des tests, analyses Analyser les problèmes de performance «en silos», de manière très spécialisée ne permet pas un diagnostic précis ; il faut avoir une approche globale, itérative L infrastructure de test de performance doit supporter cette agilité

13 Organisation à la RATP: collaboration impérative Equipes développement MOE (CdP) Equipes testeurs 1 définition Définition des des scénarios scenarios fonctionnels fonctionnels 2 Echange sur les fonctionnalités couteuses en Perf. (Batch, BDD) 3 Implémentation des scenarios retenus 4 Lancement campagne de tests sur environnement iso production 5 Analyse des résultats obtenus et propositions d amélioration 5 6 Lancement campagne de test en environnement de production Mise en Service

14 Résultats obtenus Tests de performance avant optimisation (1 ère itération) Tests de performance après optimisation (dernière itération) Gain de performance = x4

15 Intégrer le test de performance dans un processus Agile : la théorie La performance devrait aller de soit dans un processus de développement Agile Une application fonctionnelle à chaque itération La mesure de la performance à chaque itération Le suivi des indicateurs de performance dans le temps L ajout de nouvelles fonctionnalités impacte les performances, etc Organisation cible Un ingénieur de performance travaille en continu Le retour sur investissement est obtenu par la détection des problèmes de performance tôt dans le processus

16 Intégrer le test de performance dans un processus Agile : la pratique Dans le processus de développement Agile Les fonctionnalités passent toujours devant la performance C est logique: pour tester la performance, il faut d abord avoir les fonctionnalités Conséquences Les test de performance sont la plupart du temps réalisés en fin de cycle de développement On manque de temps pour réaliser des test de performance systématiquement

17 La pratique : l impossibilité de réaliser des test de performance complets à chaque sprint L impact sur le projet Plus d itérations = plus de tests = plus de charge Immobilisation des environnements pendant les tests Des cycles de développement plus courts, donc moins de temps pour tester Comment tester sur un environnement de production en service? Le coût du test de performance systématique en Agile devient trop important La clé est dans: L analyse du risque lié à la performance pour prioriser l effort de test Le positionnement de jalons tout au long du projet (par exemple : 20%, 50%, 80%, 100%) L automatisation des tests Intégrer le sujet de la performance dès le début du projet pour tous les membres de l équipe Inscrire la performance (SLAs)

18 Suivi des risque Performance IBUS

19 Automatisation des tests de performance Pour limiter le coût du test de performance en environnement agile Le prévoir au plus tôt Idéalement prévoir une intégration dans le serveur d Intégration Continue (Jenkins par exemple) L automatisation des tests de performance est plus complexe que celle des tests fonctionnels Design plus complexe Analyse souvent très difficile car ne nombreux paramètres entrent en jeux Pas de résultat simple du type «Passe / Rejeté» Il est souvent difficile de comparer 2 tests La part de «l humain» reste toujours importante, notamment pour les nouvelles applications dont on connait moins le comportement

20 Impact sur la maintenance et priorisation Prévisions de 10% d évolution par an par rapport à la charge de mise en place (trains de maintenance) Impact direct sur la maintenance des scénarios dans les mêmes proportions Dans le contexte de la RATP, la maintenance des scénarios est estimée à 3 k /an par application Nécessité de prioriser l effort de test de performance sur les applications critiques Plus globalement, au regard du temps consommé par les tests de charge, on les priorise : Pour les applications critiques (impact métier ou impact d image) Pour les application non critiques ayant des composants communs avec une infrastructure critique (par exemple : équipements réseau type reverse proxy, brique logicielle type serveur web mutualisé)

21 Les principaux enseignements

22 Sur la performance en mode Agile Le test de performance est trop complexe pour être exécuté en totalité à chaque sprint Les équipes de test doivent travailler en étroite collaboration avec les équipes de développement L automatisation des tests est une clé pour limiter leur coût, mais la maintenance de cette automatisation a un coût

23 Sur le test de charge et de performance Il est primordial de bien sélectionner les applications pour lesquelles on réalise des tests de performance et de prévoir le coût associé à la maintenance de ces derniers De même, porter une attention particulière aux fonctionnalités critiques (batch, traitement complexe, etc) qui pourraient dégrader les performances globales Les tests de performance de go/no go (pré mise en service) doivent être menés : sur le(s) environnement(s) de production ou équivalent (équivalent d une action de maintenance) avec des scénarios fonctionnels en cohérence avec les comportements des navigateurs web (gestion des caches par exemple, parallélisation) avec des injecteurs de charge dédiés afin de reproduire un comportement proche des futurs usages applicatifs (position géographique des utilisateurs, bande passante, etc)

24 Sur le test de charge et de performance L étude de la performance continue après la mise en service : car les systèmes continuent à évoluer (volumétrie, usage, etc) car on veut suivre les éventuelles dégradations de performance pour pouvoir mettre en place des solutions perfectives (et idéalement pro actives) Des solutions simples pour mesurer les performances : Mesure temps de réponse de la production côté serveur web (vision serveur) Mise en place de sonde externe indépendante du réseau d entreprise qui mesure le temps de réponse de l application en production (vision client)

25 Merci pour votre attention Nous seront heureux de répondre à vos questions!