Upload
nguyentruc
View
221
Download
3
Embed Size (px)
Citation preview
Retour d’expérience RATP
Intégrer le test de performance au cœur du processus de
développement agile. Challenges, techniques, résultats.
Les intervenants
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
Alexis Bourgeois Chef de projet MOE (front web)
Bruno Duval VP Pro. Services
Anis Zouaoui CTO
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.
Architecture de l’application IBus
Les challenges liés à la performance
Plus de 15 000 utilisateurs
Les utilisateurs accèdent à leurs services
plusieurs fois dans la journée
Des heures de pic de fréquentation précises
Pics de 40 000 pages vues / heures
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
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
La performance: un défit à plusieurs dimensions
Ressources
Dimensionnement, OS, cpu, mémoire, réseaux, disques, volumétrie, etc.
Applications
Pools, threads, connections, cache, algorithmique, bonne pratiques, synch/asynch, compression, échanges, indexation, etc.
Usage Charge interne, Charge externe, Vieillissement de données, batchs
Performance Perçue
La démarche de gouvernance de la performance
RATP
DIMENSIONNEMENT des architectures
Dimensionnement des architectures techniques
Préparation de la performance
Benchmarking et analyse des risques techniques
Gestion de la CAPACITÉ
Mesure de la capacité des systèmes critiques (en terme de performance, disponibilité, stabilité)
Prédiction de la capacité future du système
AUDITS de performance
Les audits techniques (BD, OS, applicatif, réseau, disque, etc.)
Contexte et moyen mis en œuvre
SURVEILLANCE de la performance
Les types de surveillance en place (réseaux, système, applicatif, temps de réponse)
Couverture de la surveillance
Gestion des EXIGENCES
Définition des exigences en terme de performance
Définition des modèles de charges
TESTS de performance
Les différents types tests pour mesurer, analyser et prévoir la performance
Outillage, processus et organisation en place
THINK BUILD RUN THINK BUILD RUN THINK BUILD RUN
THINK BUILD RUN THINK BUILD RUN THINK BUILD RUN
La démarche de gouvernance de la performance
RATP - Moyens
GOUVERNANCE de la
Performance
OUTILS CONNAISSANCE
ACTEURS ET COMITÉS PROCESSUS
Tests de performance et Agilité : 2 dimensions
Agile Traditionnelle
En cascade
Méthode de développement
Agile Traditionnelle
En cascade
Méthode de test
Comment intégrer le test de performance dans un processus
Agile ?
Comment être plus Agile dans les tests de performance ?
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é
Organisation à la RATP: collaboration impérative
MOE (CdP) Equipes développement
définition des scénarios fonctionnels 1
Mise en Service
Equipes testeurs
Définition des scenarios 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
Résultats obtenus
Tests de performance avant optimisation (1ère itération)
Gain de performance
=
x4 Tests de performance après optimisation (dernière itération)
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
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
Intégrer le test de performance dans un processus
Agile : la pratique…
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)
Suivi des risque Performance IBUS
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
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é)
Les principaux enseignements
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
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)
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)
Merci pour votre attention
Nous seront heureux de répondre à vos questions !