Document de déroulement de projet PDF

3. DÉROULER Sommaire 3.1 Animer une campagne 3.1.1 TOSC 3.1.2 Signalement des vigilances 3.1.3 Présentation des bugs 3.1.4 Gestion des liens avec les équipes 3.3.1 Supervision 3.3.2 Sauvegarde / Restauration 3.3.3 Test du plan de production 3.3.4 Les tests de FEX (Fiches d’EXploitation)...

3. DÉROULER Sommaire 3.1 Animer une campagne 3.1.1 TOSC 3.1.2 Signalement des vigilances 3.1.3 Présentation des bugs 3.1.4 Gestion des liens avec les équipes 3.3.1 Supervision 3.3.2 Sauvegarde / Restauration 3.3.3 Test du plan de production 3.3.4 Les tests de FEX (Fiches d’EXploitation) 3.3.5 Les tests de sécurité 3.2 Les tests d'installation 3.2.1 Procédures d'installation 3.2.2 Les tests de vérification de bon fonctionnement 3.2.3 Procédures de retour arrière 3.4.1 Typologie des tests : à la cible, aux limites, endurance, surcharge 3.5 Les tests divers (à la demande du projet) 3.6 Les procédures de migration des données 3.1 Animer une campagne Objet Liste des participants (variable selon les projets) : – les participants usuels : CDP, intégrateurs, MOE, IIA, KAT, pilotage prod ; – les participants occasionnels : MOA, bureaux métiers, MOE, techniques, ES, EA, PTS, etc. 3.1.1 TOSC Ordre du jour : – avancée des travaux de la campagne ; – points de blocage et bugs non résolus ; – révision du calendrier prévisionnel ; – divers ; – date de la prochaine réunion. Animation du TOSC : - Préparation en amont (anticipation des futurs points de blocage/points importants/points sensibles). Ex : préparation JDD, fiches de tests, disponibilité des plateformes, etc. ; - Partager l’avancement des travaux, les durées estimées pour dérouler les DI, les blocages, le reste à faire ; - Questionner l’ensemble des sujets en suspens, les tests attendus, repointer le calendrier, confirmer la LEP/MEP ; - Les acteurs de la campagne d’III (…) notamment les durées estimées pour dérouler les travaux et les différents tests demandés par la MOE. Compte-rendu du TOSC / Invitation : - Contenu du CR, rédaction, relecture, et transmission du CR (mailing list à maintenir) rapidement aux différents participants (y compris aux absents) + invitation au prochain. Reporting de la météo : – Reporting hebdomadaire à destination du bureau de l’intégration, élaboré tous les mercredis par les différentes équipes d’III. Il a pour but de rapporter de façon condensée et succincte les travaux effectués sur une semaine ; – Alertes : points de blocage ; – Vigilances : points d’attention (risques) ; – Arbitrage attendu ; – Travaux en cours et à venir. Tests de performances Hiérarchie et référent : bureau de l’intégration. 3.1.2 Signalement des vigilances Présentation VVV et ZZZ Création d’un bug Affectation du bug Ajout d’une pièce jointe Clôture et fermeture du bug La fiche process INT-23 décrit les modalités de traitement d’un bug créé par une équipe transverse : OOO système/réseaux, DBA, Supervision, Annuaire, etc. 3.1 Animer une campagne 3.1.3 Présentation des bugs 3.1.4 Gestion des liens avec les équipes MOE applicatives : Annuaires, MAMA, Référentiel, SISI, CASI Annuaires, MAMA, Référentiel, SISI, CASI Les outils de réservation de ressources : GitLab et PADON 3.1 Animer une campagne 3.1.4 Gestion des liens avec les équipes Les tests d'installation Dans l’IHM JJZZ, une phase peut être considérée comme une tâche ou un travail. Lorsque l’on crée une phase, les informations ci-dessous sont demandées : Titre : Nom que l’on donne à la phase. Type : installation, tests, performance, etc. Description : texte plus détaillé que le simple titre, utile pour s’y référer. Copier les anomalies d’une phase (oui ou non) : reprend les anomalies d’une phase précédente. Exportable (oui ou non) : oui => la phase apparaîtra dans le bilan d’III. non => la phase n’apparaîtra pas dans le bilan d’III. Calendrier des travaux (avec dates de début et de fin). Version des composants : associe la phase avec une version de paquet entrée en GGG. Catégorie : possibilité de classifier les phases (PF, Appli et tests par exemple). Rattacher un ticket GitLab : permet, au besoin, de créer un ticket GitLab (installer une plateforme par ex) associé à la phase. 3.2 Les tests d'installation Les types de phases sont très variés et correspondent à tous les travaux nécessaires lors d’une phase d’III, par exemple : - Test d’installation de plateforme ou d’application ; - Tests divers (unitaires, VNR) ; - Travaux transverses (OOO réseau/système, DBA, etc.) Cette liste est non exhaustive et dépend du projet, du type palier (technique ou fonctionnel), investigations suite à incident, etc. Lorsqu’un palier est long et/ou conséquent, les phases peuvent être nombreuses et de nature différente. JJZZ offre la possibilité de les classifier en catégories, rendant ainsi plus aisée la lecture de l’ensemble des phases. Le wiki d’III sert à rédiger et à partager toutes sortes d’informations concernant les projets. Il permet aussi (et surtout !) de tracer nos travaux, très utile lorsque l’on veut retrouver les renseignements sur un palier (si ça s’est bien passé… ou pas !). Utile aussi pour reprendre les travaux d’un collègue absent ou en congé. Exemple : 3.2 Les tests d'installation WIKI 3.2.1 Procédures d'installation Pour rédiger une page wiki, un guide de syntaxe est disponible, un bac à sable est aussi mis à disposition pour s’entraîner. Pour un chargé de projet et/intégrateur, certains travaux nécessitent une expertise dans un domaine précis (réseau, système, DBA). Ces travaux sont réalisés par des équipes transverses (par opposition aux équipes applicatives). Et lors du déroulement d’un palier, GitLab permet notamment d’effectuer des réservations auprès de ces équipes. Lors de la création d’une phase, une option propose la création d’un ticket GitLab ou la liaison d’un ticket GitLab déjà existant. Lors de la demande de création, les renseignements suivants sont demandés : Projet : projet sur lequel vous travaillez Action : création ou liaison Modèle du ticket : différents modèles suivant les travaux et équipes transverses Date d’échéance : important à positionner, surtout si le travail demandé est urgent. 3.2 Les tests d'installation GitLab 3.2.1 Procédures d'installation Outre effectuer la réservation, GitLab permet de faire un suivi des travaux demandés. Les étiquettes sont modifiées suivant le statut : A faire, bloqué, en attente, terminé, etc. La personne assignée à la tâche est indiquée. La date d’échéance est indiquée (important si la tâche est urgente). De plus, la zone « activité » permet un dialogue entre le CdP demandeur et la personne assignée. Il est possible de poster du texte et/ou des pièces jointes (copie d’écran ou autre). A noter : toutes modifications sur le ticket GitLab (changement statut, questions/réponses dans « activité » fait l’objet d’un mail : le suivi est réactif et facilité. 3.2 Les tests d'installation GitLab 3.2.1 Procédures d'installation PADON est une application de réservation. Contrairement à GitLab, elle ne sert pas à réserver une équipe dédiée mais des contributeurs (composants transverses) tels que les référentiels ou ENSU. Cette réservation est obligatoire pour les campagnes de performance pour : Être certain(e) de pouvoir utiliser ce contributeur à un moment T ; Prévenir les personnes en charge de ce composant que les tests de performances vont faire appel au contributeur avec une forte charge. A noter : PADON n’est pas accessible depuis JJZZ. PADON 3.2.1 Procédures d'installation VVV est une plateforme qui propose de nombreux services. - Les sources des applications peuvent y être déposés (versioning par subversion) ; - Les statistiques (bugs du projet) ou mediawiki sont accessibles depuis l’accueil VVV ; - Un gestionnaire de documents (Alfresco) et un serveur FTP sont aussi disponibles ; - L’une des principales fonctionnalités pour un Chargé de Projet et/ou Intégrateur est la gestion de bugs (ZZZ) : détails en page suivante. 3.2 Les tests d'installation VVV 3.2.1 Procédures d'installation ZZZ est un système de gestion et suivi de bogues. Il permet la création, le suivi, la clôture d’anomalies, et ce, par projet. Le bogue peut être de différente nature (plateforme, applicatif, documentaire, etc.) Sont indiqués : Les personnes concernées : rapporteur, responsable, en copie, etc. La typologie et l’importance du bogue. Les textes explicatifs et les PJ : logs, fichiers de conf, copie écran, etc. Le statut : ouvert, assigné, résolu, fermé. Anomalies 3.2.1 Procédures d'installation A noter : chaque modification (ex : commentaire supplémentaire) fait l’objet d’un mail transmis aux personnes concernées. A la fin d’une campagne d’III et avant la MEP, une réunion (Go-NoGo) est organisée entre les partenaires (MOA, MOE, Direction de la Prod, III et Exploitants) pour décider de partir en MEP (ou non) ou partir en MEP avec réserves. Une réserve peut être émise pour différentes raisons : un test manquant ; un dysfonctionnement qui sera réglé par une DT post-MEP ; etc. Cette réserve sera indiquée dans une phase JJZZ, elle fera ensuite partie du bilan d’III (généré par JJZZ) qui fera office de support pour le Go-NoGo. Réserves 3.2.1 Procédures d'installation Comme nous l’avons déjà vu plus haut, les phases correspondent à une tâche ou un travail. Les tests d’installation (plateforme ou application) sont primordiaux et ont une conséquence directe sur le bon déroulement de l’installation en Production. Dans le détail, nous recevons en III un paquet (par la GGG) associé à une DI (potentiellement d’autres documents d’installation). Les renseignements et les commandes issus de la DI doivent être précis (nom serveur, adresse IP, commandes Linux etc.). Chaque erreur doit être remontée (via ZZZ) afin que les documents soient corrigés avant d’être livrés en Prod. Lorsqu’une installation est effectuée (sans erreurs), le fonctionnement de l’application doit être testé via des tests unitaires. Si le test d’installation est OK, il est aussi important de tester le retour arrière. En effet, si, pour une raison ou une autre, un dysfonctionnement arrive lors de la mise en Prod, les exploitants doivent recourir au retour arrière afin de rétablir la disponibilité de l’application. Le retour arrière consiste donc à un retour dans une version de l’application qui fonctionnait. Il peut être composé d’un ensemble de commandes faisant appel au paquet de la version précédente, cela nécessite aussi parfois une restauration de BDD. 3.2.3 Procédures de retour arrière Définition classique : L'objectif de la supervision informatique est de détecter, de diagnostiquer et de résoudre de manière proactive tous les risques et les incidents potentiels pouvant survenir sur un système supervisé et entraîner une interruption de service. Au sein de la DDD, plusieurs outils permettent la surveillance du SI (serveurs, composants système, BDD, applications, réseaux, etc). Ces outils ont un fonctionnement différent, mais sont complémentaires. - Surveillance par anticipation - SISI - Dynatrace - Surveillance en temps réel - CASI (PSN) - Surveillance a posteriori - Metris 3.3 Les tests d’exploitabilité 3.3.1 Supervision SISI est une application qui propose une supervision vue coté serveurs. Elle collecte des métriques locales via des sondes installées sur des serveurs, et restituent des indicateurs en les comparant avec des critères (seuils) définis par la MOE. Une alerte est associée à l’indicateur et cette alerte est émise en fonction de la sévérité de l’indicateur (unknown, critique, warning). Si OK, pas d’alerte émise. Entre 150 et 200 composants sont surveillés (Oracle, Tomcat, espace disque, etc.) sur 5 000 serveurs. Toutes les 5 minutes, environ 128 000 collectes sont effectuées. SISI 3.3.1 Supervision Dynatrace est un APM (Application Monitoring Performance). Un agent est installé sur tous les serveurs à monitorer et les surveillances sont remontées vers un serveur central. Beaucoup de critères, comme les flux de données et les dysfonctionnements applicatifs sont surveillés. Cette application est principalement destinée aux projets sensibles. Dynatrace 3.3.1 Supervision CASI est une IHM présentant la santé des applications en temps réel. Elle permet la supervision de bout en bout, vue par application. Les scénarii sont fournis par la MOE, et CASI réagit suivant les temps de réponse : OK, warning ou KO. Les scénarii (succession de pages html, représentant l’action d’un utilisateur) sont joués toutes les 10 min. CASI (PSN) 3.3.1 Supervision Metris est un outil de métrologie et permet une analyse a posteriori des données. Les métriques techniques (CPU, RAM, stockage) sont issues de SISI et permettent le capacity planning (déterminer la capacité de production nécessaire à une organisation pour répondre à une demande). Les données applicatives sont issues des projets, elles sont restituées le lendemain sous forme de tableau de bord et sont destinées aux dirigeants (chefs de bureau entre autres…). Ce sont principalement des statistiques, comme les données de connexion. Metris 3.3.1 Supervision La quasi totalité des projets utilise aujourd’hui TiNa pour ses sauvegardes (données fichiers et base de données). 2 types de sauvegardes pour les fichiers : FS : le client TiNa installé localement réalise les sauvegardes. NDMP : pour des données sur HNAS, effectué par le HNAS lui‑même. La sauvegarde DOIT être testée et validée, de même que la restauration. 3.3.2 Sauvegarde / Restauration La mise en place de la sauvegarde doit être explicite dans la DI du KAT / DT_LX. La sauvegarde se décompose dans le DEX sur les chapitres : B1.1.4 : configuration de TiNa. C5 : documentation + expression de besoin de la sauvegarde. La mise en place de la sauvegarde nécessite des pré-requis transverses qui doivent être indiqués dans le C5. 3.3.2 Sauvegarde / Restauration Pour valider la sauvegarde : Créer un ticket GitLab pour les DBA. – Demander la vérification de la sauvegarde. Pour valider la restauration : S’assurer d’une modification en BDD « visible ». Créer un ticket GitLab pour les DBA. – Demander la restauration de la dernière FULL ou avec restauration jusqu’à une date/heure donnée. Vérifier que la modification a disparue. 3.3.2 Sauvegarde / Restauration Le plan de production décrit l’ensemble des traitements exécutés selon une périodicité qui leur est propre. Il est configuré dans un ordonnanceur (VTOM, cron, CPPS). Il peut nécessiter ou non un jeu de données spécifique. 3.3.3 Test du plan de production Tester le plan de production doit permettre de vérifier : Le bon lancement des batchs et leur (non-)concurrence, et donc la bonne configuration de l’ordonnanceur. Estimer la durée des traitements selon la volumétrie des données. Valider les appels aux autres applications (et donc la matrice ZRRR par la même occasion). S’assurer de la qualité des logs et de leur exploitabilité. 3.3.3 Test du plan de production Les FEX Les Fiches d’EXploitation sont dans le DEX C6. Elles décrivent des gestes d’exploitation de nature très différente : action sur erreur d’un batch, processus de reprise de données, gestes sur certains types d’incidents, etc. Comme tout geste d’exploitation décrit dans un livrable, ces fiches doivent être validées et suivent le processus normal d’III (test, bug, relivraison) avant LEP. 3.3.4 Les tests de FEX (Fiches d’EXploitation) Les tests de sécurité Il peut arriver que des applications fassent l’objet de tests de sécurité : faille, intrusion, etc. Ces tests sont menés par l’EEE de Bordeaux et réalisés sur la plateforme d’III. D’une durée en général de 2 semaines, ces tests nécessitent une planification adaptée au calendrier des paliers de l’application concernée. L’III aura à fournir un certain nombre d’éléments (DEX, users, etc.) en amont de ces tests. 3.3.5 Les tests de sécurité 3.4 Les tests de performance L’objectif d’un test de performance est de simuler la sollicitation que l’application connaîtra en production afin de mesurer son comportement et de vérifier que celui-ci est conforme aux attentes du projet. Il y a donc trois éléments essentiels pour réaliser un test de performance : Simuler Mesurer Comparer SIMULER Il s’agit de déterminer et de s’appuyer sur les fonctionnalités les plus pertinentes selon : Utilisation de la fonctionnalité Fonctionnalité coûteuse Fonctionnalité critique Quantifier le niveau de sollicitation Trouver une mesure capable de définir un niveau d’utilisation objectif et représentatif d’une activité. Parmi toutes les possibilités, on retient le « nombre de services rendus par seconde », qu’on appelle « débit transactionnel » ou « tr/s ». Il faut alors déterminer un modèle d’usage de l’application qu’on appelle « periode », selon des scenarii d’utilisation de l’application. MESURER Il faut définir des critères d’acceptabilité : Efficacité : les pages de l’application n’ont pas toutes le même coût à produire, il faut donc poser des critères réalistes par page et quantifier le temps de réponse selon une échelle représentative de la fiabilité de la constance des temps de réponse : le T95 Fiabilité : la fiabilité de la réponse est associée à un taux d’erreur Efficience : on surveille en parallèle la consommation des ressources systèmes. COMPARER En plus de la reproductibilité d’un test, il est important de définir des seuils de temps de réponse : bon, acceptable, inacceptable. Exemple : Typologie des tests Test à la cible : simuler une période sur une heure, avec une montée en charge vers le débit transactionnel attendu sur 20 minutes. Test aux limites : simuler la période sur 1 h en augmentant linéairement le débit transactionnel pour tenter d’atteindre 3 x le débit transactionnel cible et observer quand les performances se dégradent. Test d’endurance : simuler 75 % du débit transactionnel sur une longue période, et vérifier les dérives sur le temps. Test de surcharge : vérifier qu’après un pic de charge (2x la cible), l’application continue de répondre nominalement. Les tests divers Les tests réalisés en III doivent non seulement garantir l’exploitabilité de l’III, mais également être adaptés au projet, au palier et à ses enjeux. La typologie des tests d’III doit donc s’adapter et profiter de l’environnement « iso-prod » et impliquer des applications partenaires au besoin. Ces tests ne doivent pas être une seconde recette. 3.5 Les tests divers (à la demande du projet) Il est du ressort du CdP de sélectionner, trier, proposer ou refuser des tests. Ces tests doivent être représentatifs d’une activité en production et garantir son fonctionnement en environnement iso-prod. Charge au CdP de prévoir les tests dans son calendrier, et au besoin de contacter suffisamment en amont les équipes d’autres projets éventuellement concernés pour valider leur disponibilité. Les procédures de migration des données Ce sujet est très large, assez rare, et sans être exhaustif, peut recouvrir : Migration de serveurs de base de données Migration de base de données (version ou changement du SGBD) Migration de fichiers plats Un changement d’équipement type SAN ou HNAS Et bien d’autres... Les processus de migration sont à adapter selon les scénarios possibles, l’indisponibilité autorisée, la complexité de la procédure, etc. Migration de serveur de BDD La migration de serveurs de base de données concerne le changement de serveur de base de données dans le cas d’un palier MCT. Cette migration peut être liée à - un changement de socle Linux, - une migration de serveur physique vers une VM, - un changement de VM, etc. - un changement de SGBD ou de version du SGBD. Migration de BDD Ce cas recoupe une migration d’un précédent SGBD (Oracle, MySQL ou autre) vers PostgreSQL. Dans le cas d’Oracle, il est préférable de partir de la version 19, car il existe des procédures de migration vers PGSQL. Ce scenario interdit l’utilisation d’une reprise de données par sauvegarde/restauration, et peut nécessiter le développement d’une procédure spécifique. Migration de fichiers plats Sauf très vieille plateforme, ce cas est rarissime, et sera forcément l’objet d’une procédure spécifique. Les données sur disques importantes ne doivent pas être stockées localement mais sur HNAS, ce qui simplifie le cas de migrations de plateformes, les données HNAS restant disponibles. Fichiers plats Changement de SAN ou HNAS Ce cas est également rarissime, mais peut être simple à gérer s’il est pris en compte au niveau de la migration matérielle, l’impact sur des applications étant bien trop important si chaque application devait mettre en place une procédure de migration spécifique. Il en restera quand même des travaux de câblage et de configuration de l’OS pour monter les disques ou partages. SAN ou HNAS En conclusion Ces processus restent dans l’ensemble assez rares. Le cas le plus simple restera la restauration d’une sauvegarde avec interruption du service.