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

Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

Embed Size (px)

Citation preview

Page 1: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

Retour d’expérience RATP

Intégrer le test de performance au cœur du processus de

développement agile. Challenges, techniques, résultats.

Page 2: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 3: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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.

Page 4: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

Architecture de l’application IBus

Page 5: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 6: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 7: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 8: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 9: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 10: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

La démarche de gouvernance de la performance

RATP - Moyens

GOUVERNANCE de la

Performance

OUTILS CONNAISSANCE

ACTEURS ET COMITÉS PROCESSUS

Page 11: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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 ?

Page 12: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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é

Page 13: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 14: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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)

Page 15: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 16: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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…

Page 17: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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)

Page 18: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

Suivi des risque Performance IBUS

Page 19: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 20: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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é)

Page 21: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

Les principaux enseignements

Page 22: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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

Page 23: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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)

Page 24: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

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)

Page 25: Retour d’expérience RATP - cftl.fr · Préparation de la performance Benchmarking et analyse des risques techniques Gestion de la CAPACITÉ Mesure de la capacité des systèmes

Merci pour votre attention

Nous seront heureux de répondre à vos questions !