C2L2 Consulting, Spécialiste Qualité du SI et Centre de Formation : Tests Fonctionnels & Performance, Diagnostic, Tuning, Surveillance, Sécurité et Gouvernance.

Tests de Robustesse sur Incident PRI

Éprouver une Architecture sur Incident

Pour reproduire les conditions d'un Incident de production d'une application stratégique nous validons la  robustesse et  la capacité d'une architecture, par exemple multi-tiers en clustering, à supporter la défaillance d'un de ses éléments. Nous simulons, dans un environnement dédié, une charge équivalente à une journée type, tout en déclenchant différents types d'Incidents techniques ou logiciels. En conséquence, il faut utiliser un plan de tests adapté aux outils spécialisés capables de simuler et éprouver les différents scénarios correctifs d'exploitation d'un Plan de Reprise sur Incident.

Test de robustesse, d'endurance, de fiabilité

il s'agit d'un Plan de Charge au cours duquel on va simuler une charge importante d'utilisateurs sur une durée relativement longue, pour vérifier si le système testé est capable, comme lors d'une défaillance d'un de ces éléments, de continuer à assumer et supporter une activité intense. Nous identifions ainsi les dégradations des performances et les sollicitations sur les ressources applicatives et système.

Nous appliquons nos méthodologies courantes :

Étude de stratégie de Tests de Performance

• Pré-requis d'informations
• Complexité de l'infrastructure
• Évaluation de l'application à tester
• Type de tests de charge
• Conception du modèle de charge et plan de test

Scripting et Démarrage Tests de Performance

• Installation des outils
• Préparation du modèle de charge
• Injection du modèle de charge
• Collecte des métriques et Analyse en temps réel
• Présentation des résultats (synthèse)
• Préconisations et solutions

Évaluation du Plan de Tests de Robustesse

La stratégie de test consiste à vérifier, lorsque le service de production d'une application est en défaillance sur un de ces éléments comment l'architecture se comportera et quelles seront les dégradations observées ainsi que les actions possibles à mener pour régler l'incident.

Il s'agit d'identifier les différents composants de l'architecture, les principaux éléments constitutifs de l'application et de son exploitation, ainsi que de nommer les différents correspondants qui pourront être sollicités (disponibilité pour intervenir)  lors de la  phase des tests de charge pour mener les actions correctives éventuelles.

Pré-requis d'informations

• Identification et disponibilité des interlocuteurs responsables de l'infrastructure
• Identification de la structure de gestion de crise sur Iincident
• Documents et procédures existantes

Complexité Infrastructure

• Présentation de l'architecture technique précise de la pré-production
• Disponibilité de la plate-forme
• Durée maximale de l'intervention pour corriger l'incident

Evaluation de l'application à tester

• Perte de données maximale admissible (selon le scenario de test)
• Plan de sauvegarde
• Interdépendance flux applicatifs SIO (Other)
• Stratégie d'organisation des processus fonctionnels vitaux du SI
• Analyse des risques et des besoins stratégiques pour la continuité de service

Conception du modèle de charge du Plan de Tests de Robustesse

• Définition des transactions (scripts) et des profils utilisateurs
• Définition des scénarios à construire
• Choix et mise en place des indicateurs techniques
• Définition d'un planning détaillé

Livrables

• Planification des différentes actions devant être exécutées
• Rapport de la simulation menée

Estimation des Charges

• Réunion et rédaction des documents :nb j
• Vérification de l'intégrité des schémas  : nb j