Que sont les tests d’exploitabilité ?

Définition des tests d’exploitabilité :
Dans une entreprise (E1), l’entité responsable des applications et SI est à 99,8% nommée « la production ». Sa responsabilité concerne le fait de s’assurer et surveiller que ces applications sont en ligne (pour des sites Web par exemple), soient accessible par les clients et que les commandes effectués par ces mêmes clients puissent arriver et être traitées par les gens de l’entreprise E1.
La plupart du temps les « gens d’la prod’ » sont totalement invisible au commun des mortels que nous sommes. Ils sont présents le jour et la nuit et restent plutôt invisible.
Si un jour vous les croisez vous pourrez les remercier pour leur travail car il n’est pas si facile et vraiment très peu valorisé dans la plupart des sociétés.

« Mais quel rapport avec les tests tonton MAT ? »

Et bien, depuis quelques années déjà, (a long long years ago – façon début de légende), « les gens d’la prod’ » ne sont plus seul ! Un service, se situant juste avant la production, est souvent en charge de TESTER les applications avant de les confier à la production. Ce service est souvent nommé « Exploitation, pré-exploitation ou pré-production » (cela dépend de l’entreprise).
Ce service est donc en charge de vérifier certains aspects des applications qui seront ensuite installées par le service « production ».
Pour comprendre les tests devant être effectués par l’exploitation il faut tenter de comprendre un peu plus le travail journalier des « gens d’la prod’ ».

La « production » est donc focalisée sur la disponibilité et la qualité des services qu’elle doit délivrer, tout en garantissant la capacité à prendre en compte les évolutions du SI. Elle est la garante de la « mise en production » des modules faisant partie du SI de l’entreprise, ainsi que de la surveillance de ces modules. Ceci au niveau, performance, disponibilité, sauvegarde, etc.

Il existe des indicateurs pour mesurer tous ces points à vérifier et surveiller. Ils sont mesurés par rapport à des métriques claires et cohérentes en ligne avec les besoins métier. La plupart du temps ces indicateurs se trouvent réunis dans un document nommé SLA (Service lLevel Agreement) ou OLA (Operation Level Agreement). Il existe des outils dédiés pour mesurer la performance de ces indicateurs, mais j’u reviendrai plus tard.

Pour surveiller ces indicateurs, la production s’appuie donc sur des processus clairement définis et adoptés (espérons le du moins) dont l’objectif est le même pour remplir ses missions. Les missions principales sont :
Maintien de la disponibilité des services

• Piloter
• Exploiter et administrer

Maintien de l’intégrité de l’infrastructure

• Maintenir l’infrastructure
• Intégrer en production
• Supporter

Qualité et cohérence des processus

• Manager
• Mesurer et améliorer
• Capitaliser

Assurer la mise en production de nouvelles applications
Ainsi, la préoccupation permanente de la production est la recherche de l’excellence opérationnelle. Pour l’obtenir, elle applique les quatre règles visant à garantir l’intégrité de son périmètre :

• Tous les outils standards (ou défini comme tel) et uniquement les outils standards sont implémentés et utilisés
• Tous les projets sont initialisés via un processus formel dans lequel la production intervient pour l’intégration en production
• Seuls les systèmes testés techniquement sont sous la responsabilité de la Production
• Faire face aux risques majeurs. Et pour cela établir un Plan de Retour à l’Activité (PRA)

our que ces quatre règles puissent être vraie il faut que le service « exploitation » tests plusieurs points avant que les applications ne passent dans le service « production ». La recette d’exploitation a donc pour rôle, en tant que partie de la recette technique, de vérifier et homologuer l’exploitabilité de la solution à mettre en œuvre et sa conformité aux normes d’exploitation instaurées par la production.

Ci-dessous je développe les différents types de tests d’exploitation. Il en existe surement d’autres ou bien certain de ces tests sont déjà pris en compte par la production. Quoiqu’il en soit ces tests doivent être réalisés. Et ceci, par le service que vous voulez !

Le périmètre des tests d’exploitation concerne les :

Tests de conformité aux normes d’exploitation :

• Vérification de la conformité aux normes et standards d’exploitation des procédures et documentations
• Vérification de la prise en compte des consignes d’exploitation et de support (gestion des incidents et gestion des problèmes)

Test du plan de production / plan de bascules :

• Validation des documentations des plans de production
• Recette du plan de production
• Vérification des procédures de mise en production (change management)
• Validation de l’ordonnancement

Tests des procédures de supervision :

• Vérification de la conformité des messages d’erreur aux normes et standards
• Tests de détection et de gestion des anomalies
• Validation et diffusion des documentations applicatives et systèmes

Tests de robustesse :

• Tests de charge
• Crash test
• Reprise de traitement
• Mode dégradé

Tests des servitudes de production :

• Recette des sauvegardes / restauration et procédures
• Recette des purges, historisation et archivage ainsi que les procédures

Plan de Capacité :

• Vérification de la mise à jour du plan de capacité
• Vérification du trafic réseau et des classes de services

Tests du PRA (le plus sympa à tester)

Ci-dessous je détaille plus avant chaque test. Quand je parle de plan de tests je veux signifier que les tests sont tous rédigés et exécutés dans un référentiel de tests (TESTLINK, QUALITY CENTER, etc.). Si cela n’est pas le cas « c’est le mal ! ». Plaisanterie mise à part, TOUS les types de tests doivent être basés dans un référentiel de tests. Au final, tous ces types de tests représentent les exigences devant être pris en compte et à ce titre devenir des exigences de tests dans le référentiel de tests.
Bien entendu une stratégie des tests d’exploitabilité doit être définie (vous n’y échapperez pas bande de canaille !).
Mais voyez plutôt mes autres articles sur le sujet.

Tests de conformité aux normes d’exploitation :
Les normes d’exploitation regroupent les règles et conventions qui régissent :

Les normes d’exploitation regroupent les règles et conventions qui régissent :

• L’installation d’une application en tant qu’ensemble de programmes permettant d’assurer une tâche ou une fonction particulière
• Le nommage, la définition et l’installation d’un environnement en tant qu’instance d’une application avec ses différents composants (logiciels, interfaces, traitements, bases de données, etc.) s’inscrivant dans un contexte d’utilisation en relation avec la gestion de cette application : production, développement, intégration, recette, etc.
• Le nommage et la définition d’un traitement ou d’un job (ou batch) en tant qu’opération automatisée (script, programme, etc.)
• Les normes d’écriture des scripts (shell) lanceurs ou applicatifs
• Le nommage et la définition d’une chaîne d’ordonnancement regroupant les traitements dans un ensemble cohérent et interdépendant (Crontable ou ordonnanceurs d’un éditeur)
• La définition des interfaces en tant que flux entrant ou sortant d’une application
• Les normes et définitions des sas de transfert en tant que lieu d’échange de fichiers inter-applications

Le plan de tests d’exploitabilité listera donc la conformité des points suivants :

• Recette du dossier d’exploitation :
  • Schéma d’architecture technique de l’application
  • Nommage et description de l’arborescence applicative (binaires, données, logs, …)
  • Description et nommage des composants de l’application (serveurs, bases de données, logiciels, …)
  • Nommage des tablespaces, schémas et objets Oracle des SGBD de l’application
  • Identification et nommage des users applicatifs
  • Description des flux de l’application
  • Consignes de reprise
  • Description du fonctionnement en mode dégradé
  • Description des répertoires à purger, historiser et archiver (consignes, fréquences, rétention, …)
  • SLA de l’application

Recette du dossier d’ordonnancement :

• Schémas des chaînes d’ordonnancement applicatifs
• Description des chaînes job par job (batch ou chaine de batch)
• Calendriers de planification des chaînes
• Description des interfaces
• Liste des codes retour
• Description des cas d’erreur
• Procédures de reprises
• Gestion des logs

Recette du dossier de supervision :

• Description des processus sensibles de l’application
• Description et seuils de volumétrie des  tablespaces
• Description et seuils de volumétrie des filesystems à surveiller
• Consignes d’exploitation sur anomalies

Recette du dossier de sauvegarde :

• Noms et description des polices de sauvegarde (arborescence, type, fréquence,  …)
• Noms et descriptions des chaînes de sauvegardes (type, planning, rétention,…)
• Schémas des chaînes de sauvegarde

Test du plan de production :
Le plan de production décrit et prépare le déploiement de l’application devant être installée dans le SI de E1. Il comprendra les composants applicatifs packagés sous une forme respectant les normes E1 et permettant un déploiement tel quel, quel que soit l’environnement concerné. La documentation fournie en phase de test d’exploitabilité sera complétée des éléments suivants :

• Packages fonctionnels
  Check-lists de déploiement
  Dossiers d’installation
  Procédures de mise en œuvre en production
  Procédures et plannings de changements en production (formations, mise à jours contrats maintenance, …)

L’installation des composants cibles applicatif ou techniques de l’application sera réalisée conformément aux guides d’installation applicatifs fourni et / ou aux spécifications d’architecture.

Le plan de test du plan de production comprendra :

• Validation des documentations de déploiement
• Recette des check-lists de déploiement
• Recette de la documentation d’installation
• Tests des procédures de mise en œuvre en production
• Validation des ordonnancements batchs (fenêtres de déclenchement, périodicité, temps de traitement, conformité de la gestion des codes erreurs, …)
• Recette fonctionnelle de l’environnement

Tests des procédures de supervision :
Ils consistent à simuler des cas d’erreur construits selon les composants à superviser identifiés dans la documentation d’exploitation.
Ces tests ont pour but de vérifier la validité de la détection des anomalies et la conformité des messages d’erreur ainsi que la bonne application des consignes de gestion de ces anomalies :

• Vérification de la conformité des messages d’erreur aux normes et standards
• Tests de détection et de gestion des anomalies
• Validation des consignes
• Validation et diffusion des documentations applicatives et systèmes

Tests de robustesse :
En complément des tests de performance qui valident la conformité de l’application aux exigences de temps de réponse et d’optimisation système, les tests de robustesse doivent permettre de valider la conformité du comportement en charge de l’application aux exigences d’exploitation d’E1.

Les cas de tests permettront la restitution de l’ensemble des attendus recensés :

Tests de charge en mode nominal (utilisation CPU, I/O, volumétrie, …)

• Reprise de traitement batch sur incident de production
• Crash test (comportement et stabilité sur arrêt d’un serveur)
• Temps de bascule sur instance Oracle passive
• Performances en mode dégradé (max 50% en clustering sur perte d’1 nœud)

Tests des servitudes de production :
Les tests des servitudes de production tests le fonctionnement des sauvegardes/restauration et leur conformité avec les procédures et modalités décrites dans la documentation afférente.

Les cas de tests identifiés restitueront la couverture des exigences suivantes (informations figurants pour exemple – à adapter selon le contexte / projet / SLA de E1) :

• Sauvegarde des données (schémas Oracle, documents GED, traces, etc.)
  Sauvegarde application (exécutables, fichiers de configuration, briques techniques, etc.)
  Sauvegarde système (création d’images du système d’exploitation vierge d’application, etc.)
  Sauvegarde Oracle à chaud en mode begin backup
  Sauvegardes SAN durée max 15 mm
  Durée de restauration données + application 2h max
  Durée de restauration système complet 8h max
  Validation de l‘intégrité des éléments restaurés

Tests de PRA :
Un Plan de Reprise d’Activité est mis en œuvre après un sinistre majeur (perte de salle machine, incendie, attentats, inondations et autres catastrophe naturelle ou d’origine humaine). Il doit permettre un retour à l’activité dans des délais définis. Souvent, ce retour ce fait en mode dégradé, de manière temporaire jusqu’au retour en mode normal (arrivée de nouveaux serveurs, réplication du SI effective, etc.).
Dans le PRA figure donc le RACI (le qui fais quoi, comment et quand ?) ainsi que les actions devant être mises en œuvres ainsi que leurs ordonnancement clairement définis, approuvés par tous les acteurs du PRA avec les procédures réellement appropriées par tous.

Certes, il n’est pas facile de tester l’intégralité d’un PRA mais néanmoins certaines situations doivent être répétées pour qu’il n’y ai aucune surprise pour aucun des acteurs dans les moments de crise – le PRA est là pour cela, sinon il ne sert à rien. Pour exemple, au moment de l’incendie (et inondation dans la foulée) du Crédit Lyonnais à Paris il y a quelques années, des pertes de données importantes ont été subies car ce type de risques / sinistres majeurs n’avait pas été assez pris en compte (entre autre).

Les cas de tests devront être choisis avec soins en ayant à l’esprit le ratio : risques / coûts / occurrence.

Par expérience, exécuter les tests de PRA quand tous les acteurs sont averties et sur le pont ne sert strictement à rien ! Pour cela, seul le DSI, le responsable de la production et un observateur externe doivent être au courant. Le résultat des tests sera ainsi très représentatifs de l’état de préparation et d’appropriation du PRA par les acteurs impliqués (et au final très amusant à vivre pour un consultant externe ;-).
Pour finir, il faut savoir que c’est souvent le service en charge de l’exploitation qui est en charge de développer et administrer les batchs, chaine de batch et autres ordonnanceurs. Ainsi, ils leurs incombent de développer et tester ces shells. Mais aussi d’administrer certaines plateformes et environnements. Cela dépend surtout de l’organisation de l’entreprise (E1).
Par conséquent, des tests spécifiques sont nécessaires pour vérifier et valider ces activités :
Tests de batch (des jobs et des jobstream) :

• Tests unitaires – lancement, vérification du traitement désiré, vérification des fichiers log, traces, etc.
• Tests d’intégration dans les plateformes et environnements

Tests de l’ordonnancement des batchs :

• Tests unitaires
• Tests d’intégration dans les plateformes et environnements

Tests des plateformes et environnements :

• Installations des outils nécessaires
• Création et paramétrages

Logique exploitation