L'Approche des Applications Critiques par le Modèle PROLOGISM

Transcription

1 Le Livre Blanc Des Applications Critiques L'Approche des Applications Critiques par le Modèle PROLOGISM Résumé Les applications informatiques critiques sont celles dont la qualité de service est vitale pour l'entreprise. A ce titre, elles nécessitent une attention particulière et une approche appropriée, tant pour leur développement que pour leur exploitation. Le modèle PROLOGISM formalise cette approche et les exigences des applications critiques : Exigences de qualité de service : Disponibilité, Performance, Fiabilité, Sécurité, Capacité Exigences de maîtrise du cycle de vie : Maintenabilité et évolutivité, Exploitabilité, Robustesse Un cadre méthodologique, des techniques de traitement et des bonnes pratiques appropriées aux applications critiques complètent le modèle. Le bénéfice d'une approche propre aux applications critiques est démontré. Des exemples d'utilisation du modèle sont présentés. Copyright PROLOGISM, décembre 2002

2 Avant Propos Vous avez dit application critique? En règle générale, une application informatique contribue à l exécution d un processus métier de l entreprise. Lorsque l'application porte sur un processus vital pour l'entreprise (son activité, son image, ses revenus ) et que ce processus dépend étroitement, voire totalement, du bon fonctionnement de l'application, on parlera d application critique. Un exemple classique est celui des automates bancaires qui distribuent des billets et des informations. Si leur fonctionnement n était pas parfaitement fluide, si l on observait des interruptions, un temps de réaction trop long, si tout incident ne pouvait être corrigé qu au prix d un déplacement, etc., les clients auraient renoncé depuis longtemps à faire appel à leurs services. La régularité de fonctionnement la qualité de service d une application critique est aussi importante que son adéquation aux besoins fonctionnels. Une approche et des profils particuliers? Pour mettre en œuvre de telles applications, la stricte division du travail entre informaticiens, aux développeurs, la compréhension des aspects fonctionnels et la capacité d écrire "le maximum de code" dans le minimum de temps, sans se préoccuper du reste, aux exploitants, la responsabilité du bon fonctionnement de l application livrée, par l ajustement de la taille des infrastructures, et l utilisation d outils transverses de surveillance et de sécurité, n est pas de mise. Elle ne permet pas de garantir que le résultat observé "au quotidien" sera à la hauteur des exigences de qualité. Il est nécessaire de faire appel à des développeurs capables d'anticiper les problèmes d'exploitation, de les prévenir ou de construire à l avance les outils permettant d'y remédier. Anticiper, c est une affaire de bonnes habitudes, pratiquement de réflexes : dès les spécifications, les impératifs de qualité de service sont pris en compte au même titre que les besoins fonctionnels proprement dits. Prévenir, c est une affaire de techniques : il faut connaître et appliquer celles qui ont démontré leur efficacité et réduisent, d'expérience, les risques de dysfonctionnement. Démontrer que l'on peut recenser ces bonnes pratiques, capitaliser sur ces techniques, en s'inscrivant dans un cadre méthodologique, tel est l objet du présent livre blanc. Antoine Rachlin Directeur Général et co-fondateur de PROLOGISM Le Livre Blanc des Applications Critiques 2

3 Sommaire 1. Cadre méthodologique Notre définition d une application critique Notre définition des exigences propres aux applications critiques 4 2. Modèle Prologism d exigences des applications critiques Présentation du modèle Dimension économique du modèle Intérêt du modèle Interdépendances des exigences Postulats de base du cadre méthodologique Principes généraux de la méthodologie Techniques de traitement des applications critiques Recueil de bonnes pratiques : un aperçu d exemples vécus Application critique en phase Production (secteur : Grande distribution) Application critique en phase Projet (secteur : Banque) Application critique en phase Réingénierie (secteur : Transactions financières sécurisées) Application critique en phase Production (secteur : Opérateur de prise de paris) Application critique en phase Réingénierie (secteur : Banque) 19 Le Livre Blanc des Applications Critiques 3

4 1 Cadre méthodologique 1.1 Notre définition d'une application critique «Une application critique est une application dont la qualité de service est une exigence vitale : une défaillance de cette qualité de service entraîne l'abandon du service luimême» Pour l'informaticien, cette définition se traduit ainsi : «Les spécifications techniques répondant aux exigences d'une application critique, nécessitent autant voire davantage d'efforts que celles répondant aux exigences fonctionnelles» Une application critique doit satisfaire à : Un niveau élevé d'exigences de qualité de service en phase de production, Un niveau élevé d'exigences de maîtrise du cycle de vie de l'application. 1.2 Notre définition des exigences propres aux applications critiques Les exigences propres aux applications critiques sont de deux types : Exigences de qualité de service de l'application (qui expriment en général les préoccupations des maîtrises d'ouvrage et des utilisateurs) : Disponibilité, Performance, Fiabilité, Sécurité 1, Capacité. Exigences de maîtrise du cycle de vie de l'application (qui expriment en général les préoccupations des informaticiens) : Maintenabilité et évolutivité, Exploitabilité, Robustesse. 1 La sécurité constitue une exigence particulière. En effet : - la sécurité est une exigence critique de toute application, qu'elle soit critique ou non. - les sept autres critères du modèle doivent être systématiquement examinés dans la conception de toute solution de sécurité. Le Livre Blanc des Applications Critiques 4

5 Fiabilité Disponibilité Performance L'application doit rendre le service sans erreur : Ne pas perdre de données sensibles (ex: mouvements financiers) Ne pas fournir une réponse erronée à l'utilisateur (ex: refuser une transaction qui devrait être autorisée ou l'inverse, ou répondre avec les données d'un autre utilisateur) Maintenir l'intégrité physique des données (ex: lors du traitement d'une requête, si après avoir modifié des données, la réponse ne peut finalement pas être envoyée à l'utilisateur à cause d'un incident, les données doivent être rétablies dans leur état initial) L'application doit rendre le service attendu au moment voulu. Pour une application critique, on parle de haute disponibilité, ou encore mieux de disponibilité continue. Le taux de disponibilité attendu doit être formalisé (de la même façon que les besoins fonctionnels) et peut être variable selon certaines conditions, comme les plages horaires par exemple. La disponibilité peut aussi couvrir la continuité de services (plan de survie informatique, plan de secours/reprise, ) L'application doit rendre le service dans les délais prévus en toutes circonstances. Par exemple, la performance d'une application transactionnelle est mesurée par : Son temps de réponse, c'est-à-dire le temps que prend le service dans son ensemble à répondre à la requête d'un utilisateur ou d'un client Le respect des échéances Capacité Sécurité L'application doit rendre les services indépendamment des volumes et des flux, dans les limites prévues, et réagir de façon appropriée en cas de débordement. Dans le meilleur des cas, une application critique ne devrait pas avoir de limite autre que la capacité de la plate-forme hardware; sa capacité est alors infinie. Outre la mise en œuvre des techniques classiques de protection (confidentialité, intégrité, preuve), la sécurité doit être prise en compte lors de la réalisation même des programmes. Celle-ci ne doit reposer sur aucune hypothèse quant au contenu de ce qu'elle reçoit de l'extérieur. Par exemple, l'application ne doit accepter que les données strictement conformes au format autorisé (ex: les débordements de mémoire font partie des procédés utilisés par les hackers). Exploitabilité L'application doit pouvoir être supervisée et administrée sans impact sur la qualité de service. A cet effet, dès la conception, l'application elle-même doit intégrer les préoccupations de : Surveillance (détecter les dysfonctionnements en temps réel) Suivi du fonctionnement (analyser a posteriori son fonctionnement pour être capable de prévoir) Diagnostic des incidents (pour réparer le plus vite possible) Manipulation sans risque (arrêt/relance de l'ensemble et des différents composants, déplacement de l'application d'un environnement vers un autre, etc.) Maintenabilité & Evolutivité L'application doit pouvoir être corrigée et pouvoir évoluer fonctionnellement sans impact sur la qualité de service, dans des délais et coûts maîtrisés. On doit pouvoir mettre en œuvre les modifications sans perturber le service (ex: mises en exploitation à chaud). Les applications critiques sont fréquemment utilisées pour des services nécessitant une réactivité particulière (adaptation à la concurrence, réaction sécuritaire, saut technologique, ). La phase de conception doit anticiper la nature des évolutions potentielles. Robustesse L'application doit réagir face aux incidents en maîtrisant leurs conséquences. La conception de l'application doit par exemple prévoir : Le passage automatique en mode dégradé La priorisation de tâches L'arrêt "propre" de l'application La réinitialisation automatique La maîtrise des conditions de retour à la normale Le Livre Blanc des Applications Critiques 5

6 2 Modèle Prologism d'exigences des applications critiques 2.1 Présentation du modèle Le modèle PROLOGISM formalise en un diagramme les exigences propres aux applications critiques, comme l'illustre la Figure 1 ci-après. Figure 1 - Fondements du modèle PROLOGISM Le Livre Blanc des Applications Critiques 6

7 2.2 Dimension économique du modèle Le modèle PROLOGISM comporte une troisième dimension essentielle, la dimension économique (qui n'apparaît pas sur la Figure 1 par souci de simplification). Les coûts des différentes solutions à mettre en œuvre doivent être appréciés en fonction du niveau d'exigence qu'elles permettent d'atteindre. Outre le coût initial d'étude et de réalisation, l'impact sur les coûts d'exploitation et d'évolution est à prendre en considération. L'approche des applications critiques par le modèle PROLOGISM et la maîtrise des méthodes et techniques de traitement associées, confèrent une vision globale et "préventive", permettant d'anticiper : les effets d'une solution sur l'ensemble des critères (cf. 2.4 Interdépendances des exigences), son impact en termes de coûts (investissement et coûts récurrents). En outre, à coût égal, la préférence sera donnée à une solution ayant un impact favorable sur plusieurs critères du modèle. Sur le cycle de vie complet d'une application, l'expérience montre que cette démarche "systémique" permet d'atteindre des niveaux élevés de satisfaction aux exigences du modèle, pour un coût global inférieur à celui obtenu par une démarche "analytique" standard. La Figure 2 ci-après illustre ce propos. On notera que plus le niveau de conformité recherché est élevé, plus on tirera profit de cette approche propre aux applications critiques. Figure 2 : Illustration de l'avantage économique d'une approche propre aux applications critiques Le Livre Blanc des Applications Critiques 7

8 2.3 Intérêt du modèle Le modèle PROLOGISM permet de mesurer le niveau de conformité d'une application par rapport aux exigences des applications critiques : soit dans le cadre du développement d'une nouvelle application : représentation des objectifs et de la cible, représentation des priorités relatives. soit dans le cadre de l'audit d'une application existante, par exemple : représentation de la perception différenciée de l'application par les différents acteurs (maîtrise d'ouvrage, utilisateurs, informaticiens), représentation des résultats de l'audit de l'application : o o en situation actuelle de production, en situation prévisionnelle de montée en charge. Les figures ci-dessous illustrent deux exemples de restitution de résultats. Figure 3 - Deux exemples de restitution de résultats par le modèle PROLOGISM Réalisation de l'application WebChain : phase de pré-intégration Résultats intermédiaires Audit de l'application Focus en production Perception de la qualité de service par les acteurs (synthèse) Le Livre Blanc des Applications Critiques 8

9 2.4 Interdépendances des exigences Les méthodes et techniques à mettre en œuvre pour garantir la conformité d'une application critique aux exigences du modèle ne sont pas indépendantes les unes des autres. Pour une application donnée, deux exigences peuvent être "antagonistes" : la prise en compte d'une exigence seule peut induire, si l'on n'y prend garde, une dégradation, immédiate ou latente, du niveau de satisfaction d'une autre exigence. La démarche méthodologique vise à contrecarrer ces effets. A l'inverse, pour une application donnée, deux exigences peuvent être "convergentes" : la prise en compte d'une exigence seule peut induire, sans qu'on le cherche, une amélioration, immédiate ou latente, du niveau de satisfaction d'une autre exigence. La démarche méthodologique vise à renforcer ces effets. Il n'existe pas de règle absolue d'antagonisme ou de convergence "systématique" entre deux exigences. Les interdépendances entre exigences varient pour chaque projet ou application. Toutefois, l'expérience montre qu'il existe des relations de cause à effet "naturelles" entre certaines exigences. C'est ce retour d'expérience qui est présenté par la Figure 4 et le tableau ciaprès. Cette considération est essentielle. Elle signifie qu'il ne s'agit pas simplement de décliner une méthode propre à chacune des exigences, mais bien d'adopter une approche "systémique" qui s'adresse à chacune des exigences autant qu'à ses interdépendances avec les autres. Figure 4 - Impact d'actions non maîtrisées d'amélioration d'une exigence sur les autres exigences L'intervention sur les seuls critères de maintenabilité & évolutivité pourra avoir un impact : positif sur la disponibilité et la fiabilité, négatif sur la performance et la sécurité, neutre ou indéterminé sur la capacité, l'exploitabilité et la robustesse Le Livre Blanc des Applications Critiques 9

10 Le tableau ( 2) ci-après illustre de façon succincte les antagonismes et convergences "naturels" entre les exigences propres aux applications critiques. Quel est l'impact sur Performance Capacité Disponibilité Fiabilité Sécurité Exploitabilité Maintenabilité & Evolutivité Robustesse Performance ( 3 ) ( 3 ) 0 Quand on intervient sur Capacité Disponibilité Fiabilité Sécurité Exploitabilité Maintenabilité & Evolutivité Robustesse convergence naturelle forte + convergence naturelle moyenne 0 neutralité (pas d'interdépendance notoire) ou indétermination a priori - antagonisme naturel moyen -- antagonisme naturel fort L'identification des interdépendances entre exigences est une composante majeure de l'évaluation économique d'un projet. Par exemple, entre deux solutions de coût sensiblement égal, on privilégiera celle qui induit simultanément l'amélioration, immédiate ou latente, de plusieurs exigences ("mutualisation" du coût). (2) Dans ce tableau, on prend pour hypothèse que l'application a été conçue et développée dans les règles de l'art (3) Après avoir acquis la certitude que le code a été optimisé dans les règles de l'art, la seule façon de faire progresser les performances consiste souvent à transgresser ces mêmes règles. Le plus souvent, on observe alors une baisse de la capacité et de la maintenabilité. Le chapitre 4 présente un exemple illustrant ce phénomène. Le Livre Blanc des Applications Critiques 10

11 2.5 Postulats de base du cadre méthodologique «Un panel de méthodes, de techniques, de bonnes pratiques, voire d'outils, concourent à la satisfaction des exigences propres aux applications critiques» Il convient de les sélectionner et de les appliquer en fonction du contexte propre à un projet. Certaines techniques et bonnes pratiques sont évoquées au Chapitre 3. «Les exigences propres aux applications critiques doivent être prises en compte dès les phases de spécification et de conception d'une application» L'expérience montre que plus la prise en compte de ces exigences est tardive, plus la gravité des conséquences augmente, et ce d'autant plus que l'application est "critique". Ces conséquences sont généralement de deux types : Nécessité d'effectuer une ré-ingénierie majeure et déstructurante de l'application : augmentation non maîtrisée des coûts d'étude et développement et retard de la mise en service de l'application, Nécessité de contourner les faiblesses intrinsèques de l'application par la mise en œuvre d'un excédent de ressources humaines, matérielles et logicielles en production : augmentation non maîtrisée des coûts de production. Une démarche méthodologique, qui prend en compte les exigences propres aux applications critiques en amont du projet, a pour avantage de : Minimiser le coût global de l'application, Accélérer la mise en service de l'application et anticiper ainsi les bénéfices recherchés. Le Livre Blanc des Applications Critiques 11

12 2.6 Principes généraux de la méthodologie D une façon générale, la satisfaction de chacune des exigences décrites aux paragraphes précédents doit être une préoccupation constante, et ce d autant plus qu il s agira d applications critiques. Cette préoccupation s'exprime en deux grands principes : La bonne décision au bon moment, La mise en place d'un processus itératif. L a bonne décision au bon moment Le poids et l'importance de chacune des exigences varient suivant la phase du cycle de vie de l'application critique. Parce que certaines des exigences sont antagonistes, les choix mal pesés peuvent être générateurs de difficultés ultérieures importantes. Des arbitrages peuvent être nécessaires pour fixer le niveau de service acceptable en réponse à chacune des exigences, dans le respect des objectifs fixés au cahier des charges de l application. Ne pas avoir pris la bonne décision au bon moment peut s avérer catastrophique pour une application critique, et peut conduire à des surcoûts importants, voire à l impossibilité d atteindre le niveau de service attendu. Pour s assurer que chacune des exigences aura effectivement été examinée en temps utile et à bon escient, on s appuiera sur le tableau cidessous, qui quantifie, pour chacune des phases d un projet, le niveau d attention qu il convient d accorder à chacune d elles. Niveau d'attention requis selon la phase du projet Performance Capacité Disponibilité Fiabilité Sécurité Exploitabilité Maintenabilité & Evolutivité Robustesse Spécifications Conception Développement et tests unitaires Tests d'intégration et benchmarks préoccupation majeure + préoccupation forte 0 préoccupation normale Le Livre Blanc des Applications Critiques 12

13 L a mise en place d'un processus itératif D une façon générale, les applications critiques se caractérisent par un très haut niveau de complexité, et une grande difficulté à évaluer, a priori, le comportement aux limites du système dans son ensemble. En particulier, il n est pas rare, par exemple, que les phases de test en charge révèlent des limites jusqu alors inconnues de certains des constituants (middleware, OS, hardware, ). Cette situation particulière conduit fréquemment à devoir reconsidérer, «sous la contrainte», certains choix de conception ou de développement, et ce, très tardivement. L expérience montre en effet qu il est généralement nécessaire que ce soit l application qui s adapte à ces contraintes imprévues, même si elles ne lui sont pas attribuables. En conséquence, il convient d anticiper au mieux l éventualité de ces itérations dans le processus de développement, de façon à en limiter au maximum les effets. Cela implique que l on attache une importance toute particulière à la modularité de l application, et ce au sens large, lors des phases de spécification et de conception, comme l'indique le tableau suivant : Phase Principes à respecter pour une bonne modularité Spécifications Prendre en compte les contraintes techniques dans le découpage fonctionnel : Prévoir un module indépendant pour chaque goulet d étranglement potentiel Prévoir un module indépendant pour chacun des «services techniques» communs Conception Séparation verticale des fonctions Séparation horizontale des types de traitement Plus grande indépendance possible entre les modules Prévoir la multi-instanciation et la délocalisation physique de chacun des modules Le Livre Blanc des Applications Critiques 13

14 3 Techniques de traitement des applications critiques Des techniques contribuent aux "bonnes pratiques" du domaine des applications critiques. Elles sont nées de l'expérience des spécialistes. Le tableau ci-dessous en illustre quelques-unes. Fiabilité Disponibilité Performance Spécialiser les fonctions : un module traite une fonction ; une fonction n'est traitée que dans un module Spécifier intégralement et en détail les interfaces entre modules Outils d'analyse de code-source Outils d'industrialisation des tests Non-propagation des fautes logicielles : contrôles de complétion, tests de code retour Logging Capacité La modularité, associée à des mécanismes de routage et de répartition des flux, reste la technique la plus efficace. Economie d'échelle sur les traitements en les regroupant : Fenêtrage Bufferisation Identifier les goulets d'étranglement. Dimensionnement du matériel : utilisation d'outils de capacity planning. Répartition des fonctions sur les serveurs. Plates-formes matérielles spécifiques (systèmes à tolérance de panne, systèmes en cluster, systèmes distribués, site de secours) Maintien croisé des données "up-todate" entre systèmes distribués, opérationnels ou de secours Mécanismes de modularité des process applicatifs (multi-processing, indépendance des process, autosurveillance et relance des process entre eux) Mécanismes de redémarrage à chaud rapide pour optimiser le temps de rétablissement du service Anticipation des cas de "plantages" applicatifs afin qu'ils ne soient pas bloquants ("solidité" des programmes) Choix et dimensionnement des composants matériels Modularisation des traitements applicatifs et optimisation des routes de communication entre les modules Mécanismes d'équi-répartition des flux entre les composants matériels, et pareillement entre les modules applicatifs Anticipation au cours du développement des temps de traitement des différents modules Choix des algorithmes Logging des temps d'exécution Sécurité Au-delà de la mise en œuvre des solutions classiques de sécurité (firewalls, contrôles d'accès, antivirus, single sign-on, SSL, etc.) : Analyse de tout ce qui rentre dans l'application, et contrôle totalement strict de saisie avec émission d'alerte de sécurité Piste d'audit : trace à prendre le plus en amont possible dans le programme logiciel Exploitabilité Les modules doivent proposer : Un système de journalisation des événements interfaçable avec les outils de supervision du marché Un traitement de transaction (je reçois une question, je traite, je réponds) qui mesure son temps de réponse et loggue le résultat Un dialogue d'entrée/sortie (interprocess, accès base de données) qui possède son traitement d'erreur dont le comportement est associé au niveau de gravité des incidents Une commande externe d'arrêt "propre" Un système de configuration indépendant de la plate-forme Maintenabilité & Evolutivité On obtient les meilleurs résultats en modularisant de façon intelligente : Séparation verticale des fonctions Séparation horizontale des types de traitements (couches de télécommunication, présentation et traitement de messages, traitement applicatif, accès aux bases de données) La plus grande indépendance possible entre les modules Prise en compte des cas d'erreurs dans les procédures de communication inter-process (que fais-je si je dois interroger un module et qu'il n'est pas là?) Utilisation des méthodes et outils de conception facilitant cette modularisation. Robustesse Surveillance continue de l'état des ressources. Surveillance applicative de l'exécution des process par module. Connaissance de l'état du système. Autodiagnostic Choix des traitements de secours et addition de modules liés aux règles fonctionnelles : Interprétation de l'état du système Evaluation Choix de la meilleure solution avec capacité de retour d'une solution dégradée à la solution la moins dégradée compte tenu de l'état du système Orientation vers les modules de secours (substitution d'une solution différée à un mode temps réel) Exécution des modules de secours Le Livre Blanc des Applications Critiques 14

15 4 Recueil de bonnes pratiques : un aperçu d'exemples vécus 4.1 Application critique en phase Production (secteur : Grande distribution) Application : Application mettant à la disposition de la clientèle une carte privative avec un ensemble de services associés, dont le paiement aux caisses des hypermarchés. Symptôme : Le système est perméable aux fraudes. Objectif : Pouvoir détecter le plus rapidement possible les fraudes sur la carte privative, sans nuire au bon fonctionnement de l application. Diagnostic : La grande maintenabilité de l application, liée à la modularité du logiciel permet de mettre très rapidement en production les outils de mesure manquants. Technique : Développement et mise en œuvre d un outil d exploitation permettant d émettre une alarme en cas de suspicion de fraude suivant une situation donnée. Le fraudeur a été appréhendé grâce à cette technique. Nota Bene : Les exemples présentés dans ce chapitre sont volontairement simplifiés, leur objectif étant d'illustrer de façon concise l'approche associée au modèle PROLOGISM. Le Livre Blanc des Applications Critiques 15

16 4.2 Application critique en phase Projet (secteur : Banque) Application : Diffusion sur l intranet de l entreprise d indicateurs à destination des commerciaux en agence, ou de leur hiérarchie. Les indicateurs sont des tableaux, affichés dans un navigateur, comparant les résultats avec les objectifs attendus utilisateurs naviguent dans une vingtaine de tableaux personnels, soit environ pages HTML produites régulièrement. Objectif : Garantir un temps de réponse acceptable pour l utilisateur lors de la navigation à travers ses indicateurs. Diagnostic : La capacité du réseau qui plafonne parfois à 64Kbit/s est la ressource critique. Itération du processus Impact prévisible : Les performances du sous-système de chargement des documents dans la base de l intranet, pourraient fortement se dégrader. Nouvel Objectif : Améliorer les performances du sous-système impacté. Diagnostic : La multiplication des fichiers, du fait de leur plus petite taille, est le siège du dysfonctionnement constaté. Technique : Limiter la taille de chaque page HTML à 10Ko en séparant le contenu de la présentation et en minimisant le code Javascript de mise en forme Le contenu des tableaux est en brut dans les pages HTML. Le navigateur Web du poste client assure la mise en forme en interprétant le Javascript. Technique : Réordonnancement des traitements ; dosage très minutieux entre multithreading et multiprocessing. Le Livre Blanc des Applications Critiques 16

17 4.3 Application critique en phase Réingénierie (secteur : Transactions financières sécurisées) Application : Dans le cadre du remplacement d'un réseau national de services et transactions financières par une nouvelle génération d'infrastructure, on s applique à optimiser le sous-système chargé de faire l interface entre les deux infrastructures : il s agit d une passerelle X.25/IP. Symptôme : La recette a isolé un nombre conséquent d anomalies. La fiabilité du système livré par le sous-traitant est remise en cause. Objectif : Permettre aux équipes du maître d œuvre de se réapproprier le sous-système pour être capables d en assurer la ré-ingénierie : re-factoring du code, livraison d'une version fiable, intégration dans le système global, maintenance évolutive et corrective. Diagnostic : Le code a été écrit par des spécialistes réseau, d un seul bloc, pratiquement sans aucune fonction dans l unique objectif de performance. La maintenabilité du code est très faible, à tel point que les développeurs n ont pas pu correctement déboguer l application. Technique : Création de fonctions réutilisables, indépendantes et documentées. La perte de performance mesurée est négligeable. La recette a pu alors se dérouler dans les meilleures conditions. Le Livre Blanc des Applications Critiques 17

18 4.4 Application critique en phase Production (secteur : Opérateur de prise de paris) Application : Application de prise de paris en ligne, sur laquelle il a été procédé à une mise à jour logicielle et à l ajout de 2 processeurs supplémentaires sur la machine de production, afin d anticiper une augmentation prévue des visites sur le site liée à un événement planifié. Symptôme : La capacité de traitement de l application est divisée par deux suite à la mise à jour logicielle et à l'ajout des deux processeurs. Objectif : Revenir à la capacité initiale, celle d'avant l'upgrade. Diagnostic : Isolation du process "bottleneck" grâce à la prise de mesures sur le système en charge. L analyse des mesures prises sur le process fautif montre que le siège du dysfonctionnement réside dans l algorithme du traitement et non dans l architecture du système. Technique : Profiling du process "bottleneck" : la consommation CPU du process fautif est divisée par 10. Résultat induit observé : augmentation de la performance, le temps de réponse de la transaction responsable de la sur-consommation est divisé par 10. Le Livre Blanc des Applications Critiques 18

19 4.5 Application critique en phase Réingénierie (secteur : Banque) Application : Application de reporting de masse visant à analyser la rentabilité des clients dans le temps, à destination de utilisateurs : cible: rapports pdf et excel de 25Ko objectif de temps de traitement batch pour rapports: 6h30 Symptôme : Forte instabilité en production du programme de chargement d'une base documentaire sur l'intranet. Temps de traitement trop longs. Objectif : Assurer le chargement des documents pendant la fenêtre de traitement impartie à l application sur la machine cible, partagée entre plusieurs applications Diagnostic : Le programme en cause est écrit dans un langage de script propriétaire, surcouche d une API Java. Technique : Réécriture du programme en Java. Ajout de messages de logs et traitement en reprise de certaines erreurs Pour accélérer les tests, l API Java est désassemblée pour identifier la fonction de chargement la plus rapide. Le Livre Blanc des Applications Critiques 19

20 Remerciements Ce document doit beaucoup aux observations de nos clients qui ont accepté d'en lire les premières ébauches et de nous faire part de leur réaction. Nous tenons à remercier ici : Marc Becheret, Directeur Technique Adjoint, Cegetel Philippe Blin, Directeur de l'informatique, Services Financiers de La Poste Charles Canetti, Directeur des Systèmes d'information, Geodis Monique Castaignède, Responsable Sécurité des Systèmes d'information, Pari Mutuel Urbain Serge Druais, Directeur des Systèmes d'information, Thales Daniel Jondet, Responsable Etudes et Développement e-banking, Crédit Lyonnais Jean-Christophe Lambert, Système d'information Canaux d'accès à Distance, Société Générale 11 rue des Bergers Paris contact@prologism.fr tél : fax : PROLOGISM est une filiale du Groupe SI-LOGISM