Continuité D'activité

Club des Responsables dInfrastructure et de Production
en association avec
Le Club de la Continuit dActivit
LOBSERVATOIRE
IVRE BLANC
des Directeurs dInfrastructures et de Production

PRA
Dfinitions, Concepts, Bonnes Pratiques & Enqute
LUC VRIGNAUD FRANOIS TETE
Fvrier 2011
Table des matires

-Avant-propos : le groupe de travail PRA -ditorial de Luc Vrignaud (CRIP), pilote du GT PRA -ditorial de Franois Tte (CCA), copilote du GT PRA -Les participants Chapitre 1 : Continuit, PRA, et compagnie : introduction Chapitre 2 : Architecture et cohrence applicative 2.1 Introduction 2.2 Architecture 2.3 Bonnes pratiques 2.4 En conclusion 5 6 7 8 9 16 16 18 23 26
26 26 26 27 27
2.4.a Mettre en place une gestion du PRA par groupe dapplications (pour les reprises : rejeu, limination des doublons, etc.) 2.4.b Crer des points stables 2.4.c Revoir lurbanisation du SI 2.4.d Sen remettre aux constructeurs ( ?...) 2.4.e Un mix de ces quatre pistes
Chapitre 3 : Dclenchement du PRA et gestion de crise 3.1 Introduction 3.2 Rsum du chapitre 3.3 La gense : Le PRA naquit de lincident majeur 3.4 La gestion de crise : une organisation et un processus
3.5 Les critres de dclenchement 3.6 Des outils pour tablir ses priorits 3.7 Une organisation des quipes au service du PRA 3.8 Communication cible de crise 3.9 Retour une situation normale 3.10 Quelques leons tirer
3.5.a Un objectif de temps 3.5.b Un objectif de service 3.4.a Organisation 3.4.b Processus
28 28 28 29 30
32 36 38 39 40 41
32 35 30 31
Chapitre 4 : Validation probante du PRA 4.1 Introduction 4.2 Rsum du chapitre 4.3 Dfinitions 4.4 Quelques critres pour qualifier un exercice probant 4.5 cueils et bonnes pratiques Chapitre 5 : Maintien en Condition Oprationnelle du PRA 5.1 Introduction 5.2 Rsum du chapitre 5.3 Principes du MCO 5.4 MCO dun PRA froid 5.5 MCO dun PRA chaud 5.6 MCO dun PRA en haute disponibilit 5.7 Enjeux et gouvernance 5.8 cueils et bonnes pratiques Chapitre 6. Contrat de service et PRA 6.1 Introduction 6.2 Rsum du chapitre 6.3 Points prendre en compte en amont de la rdaction du contrat de service
6.4 La caractrisation des niveaux de service
6.3.a Cas gnral, que le contrat soit interne ou externe 6.3.b Zoom sur lexternalisation du PRA 6.3.c Primtre de lexternalisation du PRA
42 42 42 42 44 46 48 48 48 48 49 50 51 51 52 54 54 54 54
56
56 57 57 55 55 55
PAGE 3
6.5 Pilotage du contrat de service 6.6 cueils et bonnes pratiques
6.4.a La contractualisation des niveaux de service du MCO du PRA 6.4.b La contractualisation des niveaux de services applicables aux oprations de tests du PRA 6.4.c La contractualisation des niveaux de services en cas de dclenchement du PRA
58 58
Chapitre 7 : Le vocabulaire PRA dans ce Livre Blanc Conclusion Annexes A propos du CCA Club de la Continuit dActivit A propos du CRIP Club des Responsable dInfrastructures et de Productivit
60 65 66 69 71
Table des figures

Figure 1 : Figure 2 : Figure 3 : Figure 4 : Figure 5 : Figure 6 : Figure 7 : Figure 8 : Figure 9 : Figure 10 : Figure 11 : Figure 12 : Figure 13 : Figure 14 : Figure 15 : Figure 16 : Figure 17 : Figure 18 : Figure 19 : le plan de continuit dentreprise le plan de continuit dactivit les diffrentes solutions de secours les cots : indisponibilit/reprise dactivit niveaux de maturit dun PRA PCA et gestion de crise architecture de secours froid architecture de secours chaud architecture de secours en haute disponibilit le processus de gestion de crise la pyramide descalade schma simplifi du processus oprationnel de gestion de crise RPO et RTO le RTO par type de secours : secours froid le RTO par type de secours : secours chaud le RTO par type de secours : secours en haute disponibilit le BIA classification des processus matrice technique dimpact 9 10 12 13 15 17 19 20 21 30 31 31 32 33 33 34 36 37 37
PAGE 4
AvantPropos
La veille dun incident, le ROI dun systme de scurit est nul, le lendemain il est infini Dennis Hoffman de RSA
Le groupe de travail PRA rassemble des membres du CRiP et des adhrents du Club de la Continuit dActivit (CCA). Il fonctionne comme un observatoire des plans de reprise dactivit, avec une dimension avant tout oprationnelle ; une approche qui se veut complmentaire des dmarches dtudes prospectives proposes par dautres groupes de travail du CRiP. Le paradoxe et la difficult qui caractrisent le domaine des PRA restent entiers : le retour sur investissement (ROI) et la rduction des cots psent dun ct ; les obligations rglementaires et la scurit tirent de lautre. Tout est illustr dans la petite citation de Dennis Hoffman. La difficult pour le groupe de travail PRA a consist ne pas proposer le nime rapport sur la ncessit dun PRA/PCA, sur les obligations rglementaires et lgales, sur la maturit des technologies, etc., mais apprhender certains sujets plus spcifiques et concrets, dans un objectif damlioration de nos pratiques : - Dfinitions et types darchitectures, - Gestion de la cohrence applicative, - Dclenchement du PRA et Gestion de crise, - Valeur probante dun PRA, - Maintien en Condition Oprationnelle, - Ngociation dun contrat doutsourcing du PRA, - Les concepts et le vocabulaire. Lobjectif de ce livre blanc est bien de partager des retours dexpriences, des schmas, des abaques, du vocabulaire... transposables au domaine dactivit de chacun. Paralllement cette approche, le groupe a lanc un questionnaire auprs de ses membres pour estimer approximativement la maturit des grands comptes franais en matire de PRA, tant en termes de stratgie quen termes dinnovation. Bonne lecture tous
FRANOIS TETE & LUC VRIGNAUD
PAGE 5
PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute
le groupe de travail PRA
LiVRE BLANC
Edito rial
Bonjour tous, Aprs plusieurs mois de participation collgiale son laboration, nous vous livrons enfin le livre blanc sur les plans de reprise dactivit. Nous avons voulu offrir au lecteur un panorama de lexistant sur les PRA. Cependant depuis le lancement du groupe de travail, nous assistons une mutation des stratgies selon plusieurs axes : Lvolution des technologies dans les offres des fournisseurs (par exemple les nouvelles solutions de haute disponibilit chez les fournisseurs de baies de stockage, la gnralisation de la sauvegarde sur disques et lemprise croissante de la dduplication, les nouveaux usages de la virtualisation dans une optique de rsilience, etc.). Un accroissement de la contrainte dj exerce par les rgulateurs dans les domaines de la reprise et de la continuit dactivit (audits internes, audits par commissaires aux comptes, directive Solvency II, directive Ble 2, ) Le constat dune difficult grandissante maintenir en condition oprationnelle des infrastructures de secours complexes nonutilises. Lapparition dune nouvelle offre : le cloud computing. Au cours de nos changes, nous avons tous senti que ces nouvelles orientations mergeaient dun besoin de service grandissant, lui-mme issu de linterconnexion de nos partenariats, de lintensification de nos changes internationaux, dune complexification globale du fonctionnement des entreprises dans un environnement mondialis. Cela ma rappel les propos changs lors dune table ronde du dernier salon itiForums en juin 2010 : La nouvelle problmatique des risques : quelles consquences pour la continuit dactivit ? . Si je devais rsumer la teneur des dbats tenus ce jour-l, je titrerais Leffet papillon : bte noire de la gestion du risque ? . En deux mots : dans les dix dernires annes, se sont multiplis des phnomnes extrmes et peu probables (attentats du 11 septembre 2001, ouragan Katrina, crise mondiale de 2008, volcan islandais Eyjafjll, phnomnes climatiques extrmes, ) qui ont impact toutes les entreprises diverses chelles. On est pass de la gestion du risque la gestion de lincertitude ; avec un vieux constat : tout est interconnect et interdpendant. Ces vnements nous rappellent donc quil est judicieux de concevoir la continuit dactivit en cherchant en premier lieu dterminer ce qui est critique des processus et des hommes ; et ceci indpendamment de causes pouvant survenir. Le PRA, au fil de cette volution, passe du statut dassurance risques au statut de process oprationnel indispensable la continuit dactivit de lentreprise. Bonne lecture tous
LUC VRIGNAUD, Pilote du Groupe de travail PRA MACIF
PAGE 6
Bonjour tous, La notion de secours informatique suite un sinistre est ne en France, suite aux vnements de Mai 68. Les dirigeants de trois grandes socits industrielles franaises prirent alors conscience du risque de blocage qui menaait toute entreprise. Ils dcidrent en consquence de crer un centre informatique de secours mutualis, qui vit le jour dans les annes 1970 : le GT2I. Il faut rendre ici hommage son crateur Jol Moreau. Devenues conscientes du risque, les directions informatiques se mirent dvelopper des plans de secours informatique. On parlait alors essentiellement de sinistre physique : incendie, inondation, ... Le secours consistait raliser des sauvegardes quotidiennes sur bandes magntiques. Externaliser plusieurs centaines de bandes engendrait un gros travail logistique, et la faible fiabilit des supports magntique posait de nombreux problmes. Les moyens de secours informatiques taient en gnral mutualiss et fournis par des socits spcialises. Les mtiers de lentreprise taient rarement consults pour dterminer leurs besoins quant la disponibilit des applications sur lesquelles reposait leur activit. Les informaticiens dcidaient leur place. Les mtiers participaient tout de mme aux exercices de secours, et donnaient leur avis sur les conditions de reprise dactivit. Que de chemin parcouru depuis. Dautres types de sinistres ont tre pris en compte : ils touchaient les locaux de lentreprise, puis les hommes. Les plans de continuit dactivit de lentreprise (PCA) se sont dvelopps. Le plan de secours informatique devenu plan de reprise dactivit informatique (PRA) a t intgr dans ces PCA. Les conditions de reprise dactivit dtermines par les mtiers et valides par la direction gnrale ont ncessit des solutions de secours de plus en plus sophistiques. La technologie, ayant considrablement volu, a facilit ces volutions. Certains thmes de maturit diffrente restent couvrir au sein des entreprises : Le maintien en condition oprationnelle des PRA La validation probante des PRA afin dtre sr quils fonctionneront le jour o se produira rellement un sinistre La reprise dactivit partielle par domaine applicatif La prise en compte de la continuit dactivit dans la conception dapplications La prsence indispensable dhommes clefs pour assurer la reprise dactivit dans le dlai prvu Ce livre blanc vous donnera des pistes. Le bonheur est dans le PRA
FRANOIS TETE, Prsident dhonneur et Secrtaire Gnral CLUB DE LA CONTINUIT DACTIVIT
PAGE 7
Edito rial
LiVRE BLANC
LES PARTICIPANTS
Les pilotes du groupe de travail : LUC FRANOIS VRIGNAUD TETE MACIF DEVOTEAM Nous remercions particulirement pour leur participation active : THIERRY SOLEIMAN RENAUD FLORIAN ALAIN RIC GERARD BECAULT BELLI BONNET CARRIERE CESAR TOMAN VILLERS CNP ASSURANCES AIR FRANCE CRiP SOLUCOM EDF GDF / SUEZ AEROPORT DE PARIS
Nous remercions pour leurs contributions : LUDOVIC GERARD THIERRY DIDIER GUY JOSE ANTONIO THIERRY FRDRIC MARIE-JOSE CHRISTIAN PATRICIA BEY FOURNET HARENG PLAT PRUDHOMME RODRIGES SELTZ SEVESTRE VANBAELINGHEM VALLY VIOLETTE INA CREDIT IMMOBILIER DE FRANCE SOLUCOM CNAV GROUPE CASINO POLE-EMPLOI PSA PEUGEOT CITRON CARREFOUR MINISTERE EDUCATION NATIONALE ARMEE DE TERRE THALES
Merci tous
PAGE 8
Avec laimable autorisation de F Cointe. http://www.fcointe.com/
Le PRA : Lassurance de linutile ?
La Continuit dActivit sintgre dans la stratgie globale de lentreprise, et sert des objectifs de natures diffrentes : Garantir la continuit de lactivit de lentreprise Assurer la conformit rglementaire (Ble II, Solvency II, etc.) Rduire les cots de la gestion des risques Amliorer la scurit, la protection de ses donnes Dmontrer la prennit de lentreprise sur les marchs Devenir un partenaire plus attractif de par son niveau de rsilience Les grandes orientations concernant la continuit dactivit sont gnralement dcrites dans un document de stratgie dentreprise (politique de continuit), qui se voit dclin en plans de continuit dactivits (PCA), et dont le maillage dpend de la taille de lentreprise (plans applicables aux primtres entreprise, direction, dpartements, filiales, etc.) et des types de sinistres pris en compte.
Figure 1 : le plan de continuit dentreprise
Le PCA rsulte le plus souvent dune analyse dimpacts des risques majeurs capables daltrer la continuit dactivit des mtiers de lentreprise. Ces risques peuvent tre de divers types : destruction de donns, perte par sinistre du site de production, dni de service, incident doprateur tlcom, perte dnergie lectrique, vandalisme numrique et bien dautres.
PAGE 9
CONTINUIT, PRA, ET COMPAGNIE : INTRODUCTION
LiVRE BLANC
Le Plan de Continuit dActivits se dcline gnralement en deux niveaux

Un PCI (plan de continuit des infrastructures) qui dpend : - des caractristiques des solutions matrielles mises en uvre (avec ou sans redondance), - de lorganisation du Maintien en Condition Oprationnelle, de la disponibilit dastreintes (volet RH voir Libre Blanc du CCA Plan de Continuit dActivits et gestion de crise : guide pratique lattention des DRH, 2010, CCA1), - dun ventuel PCA mtiers (PCM). Une organisation qui sappuie sur des dispositifs dexception : - une organisation de crise gnrale de lentreprise, intgrant des sous-volets de gestion de crise par sous-systmes : dont le Systme dInformation, - un PCA Mtiers (PCM) : des palliatifs mtiers pour maintenir lactivit pendant la remise en tat, - un PRA informatique : des solutions matrielles et organisationnelles pour reconstruire rapidement la partie du systme dinformation vitale pour lentreprise.
Figure 2 : le plan de continuit dactivit
Le prsent livre blanc se focalise sur le PRA du SI et les moyens associs en termes de processus, mais nabordera pas les multiples aspects des technologies disponibles ligibles au PRA. Si le nombre darchitectures existantes crot danne en anne (architectures physiques, virtuelles, dmatrialises, architecture simple sans secours, avec sauvegarde locale, en PRA froid, en PRA chaud, en haute disponibilit, en tolrance de pannes, ) celles-ci peuvent se caractriser plus simplement par leur niveau de service.
PAGE 10
1. Tlchargeable sur le site du CCA http://www.clubpca.eu/
Dans la suite du prsent livre blanc nous avons choisi de nous limiter la typologie suivante :
Type de secours Haute disponibilit Reprise des donnes A la dernire transaction Reprise des traitements Sans interruption si lapplication est conue pour cela, sinon quelques minutes Solution de secours Clustering et mirroring sur un environnement ddi Rplication cohrente des donnes entre site de production et site de secours, environnement de secours ddi Sauvegardes sur mdias mis hors site, environnement de secours mutualis ou ddi
A chaud
De quelques minutes quelques heures
Infrieur 4 heures
A froid
De 12 36 heures suivant lheure du sinistre
De deux cinq jours
Nous nous sommes attachs prciser dans chaque chapitre les particularits de chaque type de PRA au regard des charges de MCO (maintien en condition oprationnelle) associes, du niveau de maturit requis en termes de MCO, des rgles doutsourcing ou encore des facilits de validation (test et exercice) du PRA.
Haute disponibilit
Pour la haute disponibilit, les quipements (serveurs et baies de stockage affects une application) du site de production et du site de secours cooprent en permanence pour assurer aux utilisateurs un service continu. Le dispositif maintient la cohrence des traitements et des donnes sur les baies de stockage entre le site primaire et le site de secours. Les donnes places sur les baies de stockage sont rpliques dans les deux sens pour quil ny ait pas dinterruption de service. Le dispositif de haute disponibilit impose une architecture technique et applicative spcifique, prise en compte ds la conception, et dans laquelle des serveurs sont ddis au secours et actifs en permanence, ou passifs mais automatiquement activs ds la dtection de lincident (ex : modle maitre/esclave avec heartbeat). Parfois, la puissance disponible sur le deuxime site est moindre que celle installe sur le site principal. Dans cette situation, il y a possibilit de dgradation des temps de rponse en cas dindisponibilit dun des deux sites, puisque le site rest actif prend en charge lensemble de lactivit et risque alors de se retrouver surcharg.
Remarque : La haute disponibilit ninclut pas la tolrance de panne. Le basculement en mode secours dans un dispositif de haute disponibilit peut engendrer une rupture temporaire de service (sans perte de donnes) alors que dans un modle de tolrance de panne il nexiste ni perte de donnes, ni coupure du service (et ceci grce des architectures matrielles spcifiques, avec des technologies du type partage de mmoire, de contexte, et autres).
PAGE 11
LiVRE BLANC
Secours chaud
Le secours chaud sappuie sur une recopie des donnes en continu du site de production vers le site de secours (en mode synchrone ou asynchrone). Les systmes dexploitation et les logiciels applicatifs sont identiques sur les deux sites mais les montes de version se font selon un contrat de service. La rplication des donnes des applications est gre, par des moyens spcifiques. Les serveurs de secours nentrent en activit quen cas de situation de secours rel ou de test. En dehors de ces priodes, ils sont dormants et nont pas accs aux donnes rpliques.
Secours froid
Le secours froid fonctionne par transfert des systmes dexploitation, des logiciels et des donnes des applications vers un site de secours. Ce transfert est ralis par sauvegarde puis restauration partir de supports de sauvegarde externaliss (bandes le plus souvent). La configuration de secours nest active quen cas de secours rel ou de test. En dehors de ces priodes, les serveurs et baies de stockage sont dormants ou utiliss dautres usages.
Figure 3 : les diffrentes solutions de secours
Ne pas confondre haute disponibilit et PRA

Un PRA peut recourir de nombreuses solutions techniques pour rpondre aux objectifs prcdemment noncs par la matrise douvrage : solution en mode actif/passif, solution de rpartition de charge (load-balancing), solution de rplication synchrone ou asynchrone, solution de reconstruction de serveurs, solution de virtualisation de serveurs, solution de sauvegarde des transactions, boot-on-SAN, solution de restauration des sauvegardes.
PAGE 12
NB : Il ne faut donc pas confondre haute disponibilit et PRA ! La disponibilit rpond une exigence de continuit de service. Le PRA couvre les aspects de reprise dactivits aprs incident et/ou sinistre.
Il nexiste donc pas une solution, mais des solutions de PRA au regard des prrequis de la maitrise douvrage. Il faut aussi rester conscient que le souhait dune haute disponibilit de bout en bout reste souvent difficile raliser et maintenir. De plus, la continuit a un cot qui doit toujours rpondre aux enjeux et risques quelle couvre. Le choix dune solution de continuit dactivits par lentreprise est fonction dune part du temps accept dindisponibilit dun service et dautre part des cots associs cette indisponibilit (criticit de lapplication).
Figure 4 : les cots : indisponibilit/reprise dactivit
PAGE 13
LiVRE BLANC
Maturit des rpondants

Exploitation du questionnaire 1er trimestre 2010 Un panel de 20 grandes entreprises
Taille des entreprises en nombre de collaborateurs : - 1 000 : 1 000 10 000 : +10 000 : Nombre de datacenters : 02: 34: +4 : - 2 km : 2 10 km : +10 100 km : +100 km : 0 20 % : +20 40 % : +40 60 % : +60 80 % : Volumtrie SAN globale : 1 10 To : +10 100 To : +100 500 To : +500 To : 0% 25 % 50 % 25 % 27 % 45 % 27 % 8% 31 % 31 % 30 % 12 % 25 % 38 % 25 % 17 % 25 % 58 %
Distance moyenne entre datacenters :
Volumtrie du stockage SAN utile au PRA rapporte la volumtrie SAN totale :
Plan PRA :
Disponible dans 90 % des cas et test au moins 1 fois par an (maximum 3 fois par an) Plan PCA : Disponible dans 60 % des cas et test en moyenne 1 fois par an (maximum 2 fois par an) Niveau de service aprs dclenchement du PRA : Iso-production : 25 % Fonctionnement en mode dgrad, 80 % du nominal : Autres (selon engagement) : 15 % Dclenchement dun plan PRA sur les 3 dernires annes : Non : Oui : 75 % 25 % (causes: incidents sur infrastructure et problmes lectriques) 60 %
PAGE 14
Figure 5 : niveaux de maturit dun PRA
Suite lexploitation des questionnaires, nous avons dtermin que les rpondants se situaient un niveau de maturit compris entre 3 et 4.
PAGE 15
LiVRE BLANC
ARCHITECTURE ET COHRENCE APPLICATIVE

La cohrence est comme le chaos : toute relative Luc Vrignaud
2.1 Introduction
Du besoin de continuit la conception de larchitecture
La mise en place dun PCA, et celle du PRA qui en dcoule, constitue dabord une dcision stratgique pour une entreprise, mme si parfois des rglements externes le lui imposent (par exemple la Loi de Scurit Financire LSF, les directives du Comit de la rglementation bancaire et financire CRBF). Une fois la dcision de mettre en place un PRA prise, les choix stratgiques rsident dans les solutions retenir. Les choix organisationnels et darchitecture dcoulent dune analyse des impacts (financiers, sur limage de marque de lentreprise, rglementaires, consquences dune perte de productivit) relatifs une rupture dactivit (partielle ou totale) touchant les processus critiques de lentreprise, et des rponses quon choisit de leur donner. Un premier niveau dtude permet gnralement de prciser le primtre des processus ou activits secourir. Le besoin des mtiers en termes de continuit dactivits doit tre spcifi comme tout autre besoin. Certains critres ou notions, trs techniques, peuvent paraitre vidents du ct des fournisseurs de ressources (le service informatique ou sa composante production), mais tre inconnus ct client. Il y a donc lieu daider les mtiers sur ces aspects.
On peut ainsi dfinir avec les mtiers

> Les risques contre lesquels chaque mtier veut se prmunir (perte du datacenter, perte dun immeuble, arrt de production, perte dintgrit des donnes, mouvement social, etc.). La rponse nest pas obligatoirement la mme pour chaque risque. La garantie 100 % tout risque nexistant pas, il convient de hirarchiser les types de risques et de prciser les risques rsiduels acceptables, cest--dire noncouverts par le PRA. Les limites de la couverture assure par le PRA devront tre connues de la direction gnrale qui doit les valider. > Pour chaque processus mtier (y compris les fonctions support comme linformatique ou la facturation), les applications majeures ou critiques et les flux dchanges indispensables associs. > Il existe au moment du sinistre un fort risque de perte de donnes, dindisponibilit, en dcoule un impact sur lactivit, limage, etc Chaque mtier value ces lments pour classer les applications par criticit. > La dure maximale acceptable darrt des applications informatiques pour chacun des mtiers. Cette dure est spcifie sous la forme dun Dlai Maximal dInterruption Admissible (DMIA) qui se voit ensuite traduit en une rponse technique le Recovery Time Objective (RTO) qui prcise le temps maximum que doit prendre la remise en fonction.
PAGE 16
> Le niveau tolrable de dgradation du service en cas de fonctionnement en mode secours (exprim par exemple en pourcentage du SI secouru, ou en pourcentage de perte de capacit de traitement). En contrepoint, une autre valeur indique la dure acceptable de fonctionnement en mode dgrad (de quelques minutes plusieurs jours). > Lexistence de points de cohrence entre les applications qui communiquent entreelles, et ce afin de faciliter la resynchronisation des flux entre applications au moment de la reprise (voir infra). Une ngociation sera souvent ncessaire lissue dune premire expression du besoin mtier pour arbitrer entre le niveau de service attendu du SI et les limites du budget. Elle permet de repositionner le niveau relatif de couverture du plan de continuit Mtiers (PCM) par rapport au PRA.
Figure 6 : PCA et gestion de crise
PAGE 17
> Le volume maximal de perte de donnes admissible par les mtiers, volume spcifi sous la forme dune Perte Maximale de Donnes Tolrable (PMDT) ou dune Perte de Donnes Maximale Admissible (PDMA). PMDT et PDMA se verront traduits en une rponse technique le Recovery Point Objective (RPO) li la stratgie de sauvegarde, et qui prcise la dure maximale durant laquelle des donnes ont t perdues en cas de sinistre.
LiVRE BLANC
Traduire le besoin en solution avec le mtier

Un sinistre informatique provoque un saut dans lespace et dans le temps. Saut dans lespace : la reprise aura lieu un autre endroit. Saut dans le temps : il y aura eu une interruption, la reprise aura lieu une heure diffrente. La reprise dactivits se fera en fonction du type de secours ( froid, chaud, haute disponibilit) dans un dlai de quelques minutes quelques jours. Suite au sinistre, les traitements en cours se sont arrts brutalement. A la reprise dactivit, on doit viter de perdre des flux reus et de renvoyer des flux qui engendreraient des doublons (commandes, virements, ordres, ...). Les diffrentes solutions seront compares sur la base des besoins exprims. Il sera ncessaire de revenir vers le mtier pour prciser certains points : Peut-on revenir en arrire et rejouer des traitements ? Peut-on se rfrer des points de synchronisation ? La reprise applicative peut-elle tre automatise ? Lautomatisation technique de la reprise dactivits nest pas envisageable, du fait des milliers de cas possibles dpendant du moment du sinistre. Par contre il est indispensable dautomatiser les procdures, sous forme de listes de tches ou descriptifs, pour reprendre lactivit dans un temps court. La problmatique de la cohrence applicative dpend du type de solution de secours ( froid, chaud, en haute disponibilit) et de la conception de lapplication.
2.2 Architecture
Secours froid
Le secours froid constitue la plus simple des solutions de reprise dactivits, mais aussi celle laquelle recourir lorsque tout a chou. Dailleurs, une solution de PRA de type haute disponibilit ou chaud doit toujours tre accompagne dun secours froid. Dans cette configuration, le site de production et le site de secours sont indpendants. Le site de secours reproduit lidentique tout ou partie de larchitecture du site secourir. Les donnes sont restitues sur le site de secours par des sauvegardes de recours suite au sinistre. Les sauvegardes de recours sont des sauvegardes exhaustives, cohrentes et externalises ncessaires au secours. Elles doivent tre prises, idalement, un point de synchronisation dit point propre . La reprise dactivits se fait partir de ce point dancrage. Le plan de continuit mtiers (PCM) doit prvoir la reprise des traitements, en relation troite avec linformatique.
PAGE 18
Figure 7 : architecture de secours froid Les donnes restaures sur le site de secours sont intgres puisquissues de la prise de sauvegardes de recours. Les traitements effectus entre la dernire sauvegarde et le moment de lincident sont rejous, soit manuellement, soit partir des logs. Le PCM doit contrler la cohrence du point de reprise et supprimer les doublons dans les traitements refaits. En effet les mtiers possdent une plus grande connaissance pratique de leurs donnes que les quipes informatiques, ce qui les qualifie pour avoir la main sur ces oprations. Les programmes doivent tre prvus pour tre rejous. Ce cas idal prsuppose lexistence dun point de synchronisation souvent problmatique dfinir. Les traitements transactionnels et batch associs fonctionnent en gnral en permanence. Il est de ce fait difficile davoir un point unique de synchronisation des sauvegardes. Plusieurs techniques peuvent tre utilises pour assurer cependant la cohrence applicative : Des techniques de type boite noire aviation pour garder une trace des principales actions effectues entre le point de sauvegarde et le sinistre. Des techniques pour lapplication des logs des bases de donnes, si ils ont t externaliss. Attention aux interactions en cascade entre systmes multi-sites et / ou multipartenaires. Le plan de continuit mtiers, en association avec le service informatique doit dterminer, suite au sinistre, les modalits de la reprise dactivits. Ltude pralable peut amener renoncer la saisie des donns perdues, voire admettre un dlai de rgnration des donnes perdues conformment la convention de service ngocie avec le client, sur la base de lanalyse de risques.
PAGE 19
LiVRE BLANC
Vu le nombre de cas envisageables, la diversit des situations et des architectures, lautomatisation de la reprise dactivits nest pas possible techniquement. Des procdures manuelles de reprise et de contrle restent absolument ncessaires.
Secours chaud
Le site de production et le site de secours sont interconnects et darchitecture identique pour la partie secourue. Les donnes sont rpliques sur le site de secours.
Figure 8 : architecture de secours chaud La cinmatique du droulement de la reprise dactivits se droule comme suit, aprs la survenance du sinistre : Coupure de la rplication entre les deux sites. Lancement des procdures de sauvegarde totale des donnes sur le site de secours (mesure conservatoire et optionnelle pour pallier une perte totale des disques et des sauvegardes de production). Attention la dure de la sauvegarde. Lancement des procdures les plus appropries la reprise par domaine applicatif : - Activation de linfrastructure de secours et contrle de lintgrit technique de cette infrastructure. - Excution des procdures de reprise des donnes et contrle de lintgrit fonctionnelle. - Excution des procdures de reprise dactivits des traitements par domaine applicatif. - Les traitements et les donnes sont resynchroniss. Redmarrage des traitements sur le domaine applicatif de priorit la plus leve la moins leve, selon les procdures de reprise appropries (ouverture progressive des flux par domaine applicatif).
PAGE 20
Le site de secours devient site de production pour toutes les activits vitales de lentreprise. Il est quip lidentique de tous les lments secourus du site principal (robotiques, stockage, outillage, rseau, scurit).
Haute disponibilit
Le site de production et le site de secours sont interconnects, darchitecture identique, et fonctionnent comme un site de production unique. Les donnes sont obligatoirement identiques en permanence sur les deux sites. La haute disponibilit implique lautomatisation du basculement la dernire transaction avant sinistre. En gnral, la production se trouve rpartie sur les deux sites (fonctionnement en mode dual-site). Mais lexigence de certaines applications vis--vis des performances (temps de propagation des donnes), implique que la production se fasse parfois sur un seul site. Si les performances sont acceptables on prfrera mettre la rplication des donnes en mode synchrone. Actuellement la distance intersites pour ce mode de fonctionnement ne saurait excder une cinquantaine de km. La haute disponibilit repose souvent sur une architecture renforce au niveau de chacune des couches suivantes : Serveurs (physiques ou virtuels) : ils sont redonds et distants. Stockage de donnes : les baies sont distantes et rpliques. Rseau : il est totalement redond, y compris sur les deux sites. Ressources/environnement (lectricit, climatisation) : ils doivent tre redonds.
Figure 9 : architecture de secours en haute disponibilit

PAGE 21
LiVRE BLANC
Les techniques de haute disponibilit peuvent se prsenter sous diffrentes chelles, de la simple redondance locale des serveurs avec ventuellement redondance des donnes, la mise en place de clusters distants avec baies de stockages en rplication. Cette dernire formule prsente tout son intrt pour faire face au risque de sinistre dune salle. Le plus souvent on utilise deux sites distants. Selon les attentes, les contraintes de maintien en condition oprationnelle on orientera son choix vers : 1. Dclarer un site comme principal et lautre de secours (la production ne fonctionne effectivement que sur le site principal). 2. Avoir les deux sites actifs simultanment (la production est rpartie sur les deux sites). Les deux sites doivent-ils tre de puissance identique ? Pas forcment, mais comme nous allons le voir une diffrence de capacit de traitement entre les deux sites posera toujours des problmes en cas de sinistre. - Cas 1 : les deux sites sont de puissance identique, alors le site de secours reprend en totalit lactivit du site principal. - Cas 2 : les deux sites ne sont pas de puissance identique, alors le site survivant ne peut pas assurer lensemble des traitements cumuls. Il faut donc prvoir soit un dlestage (fonctionnement dgrad) ; soit des moyens pour augmenter rapidement la puissance. (Il est possible de ngocier des cls dactivation de puissance (Power on Demand) en cas de PRA [ex : Capacity on Demand sur z Series chez IBM]) Dans les deux cas, si les systmes et applications sont prvus pour, le basculement est automatique et rapide (de quelques secondes quelques minutes). Par contre, selon la conception de lapplication, le basculement peut ncessiter la rouverture des sessions de travail. Ct donnes, des procdures de reprise doivent tre prvues avec les mtiers pour prendre en compte : La vrification et la reprise des transactions manuelles en cours au moment du basculement. La vrification et la reprise des batch en cours au moment du basculement. En cas dchec, la restauration des donnes simposera. La reprise froid partir des sauvegardes, mme dans ce type darchitecture, reste un ultime secours. Tableau comparatif entre la haute disponibilit intersites (deux sites distincts), inter-salles (deux salles au sein du mme btiment), inter-btiments (deux btiments sur un mme site).
PAGE 22
Le choix pourra se faire en fonction des possibilits de ralisation et du niveau de couverture recherch pour chaque risque.
Haute disponibilit Avantages / Inconvnients Performances Facilit de MCO Disponibilit
Inter-salles
Bonnes (Rplication synchrone)
+++
Facilit par la proximit
++
Risques dus lenvironnement partag (nergie, climatisation, rseau, accs, localisation perte du btiment, ...)
Inter-btiments
Bonnes (Rplication synchrone) Bonnes (Rplication synchrone) (NB : perte de temps en traitement batch) Dgradation selon distance (Rplication asynchrone)
+++
Facilit par la proximit
++
Lenvironnement commun est rduit. Selon larchitecture des rseaux et des ressources, le risque peut aussi tre rduit
+++
Intersites < 50 km
Plus dlicat du fait de lloignement
Lindpendance des sites augmente avec la distance
++
Intersites >50 km
Difficults du fait de lloignement > Ncessite du personnel comptent sur site
Meilleure indpendance des sites vis--vis de sinistres rgionaux
+++
Retour une situation normale (commune aux trois types de PRA)

Le retour une situation normale peut tre rapide (de lordre de la semaine) ou prendre plusieurs mois et se fait comme suit : Prparation dun site de production nominal la reprise (rparation/construction, recette). Resynchronisation/restauration des donnes. Fonctionnement normal.
2.3 Bonnes pratiques Dcouper le SI en plaques secourables homognes

Les SI modernes ne fonctionnent plus en silos : il est illusoire de chercher un point de synchronisation global pour le PRA. La question est donc comment dcouper le SI en plaques secourables homognes ?
PAGE 23
LiVRE BLANC
Il ny a quasiment plus aujourdhui dapplication ou mme de chane applicative fonctionnant en stand-alone : les changes multilatraux sont trs nombreux, rarement documents exhaustivement (en tous cas, leur criticit reste rarement dfinie) et concrtement, cela sest traduit ces dernires annes par la multiplication des projets EAI / bus applicatifs qui viennent dailleurs simplifier le secours, sils le prvoient ds le dbut. Du coup, il est quasiment impossible de dfinir un point de synchronisation global quotidien pour toutes les applications, ce qui conduirait arrter toutes les bases en mme temps pendant X heures, le temps de les sauvegarder et encore moins sil faut dfinir plusieurs de ces points par jour, en fonction de la dure dinterruption la plus exigeante. En consquence : il faut imprativement dcouper le SI en plaques prsentant des changes de flux minimum, et si possible regroupant des applications avec des besoins (dure maximale dinterruption admissible DMIA / PDMA) proches.
Utiliser des solutions techniques facilitant la synchronisation des sauvegardes / jeux de donnes rpliqus du PRA
Pour limiter la fentre ncessaire la synchronisation, il est dsormais possible de sappuyer sur les outils de snapshot ou quivalent. On passe de quelques heures quelques secondes dindisponibilit de la base de donnes. On est sr den possder une version cohrente (au sens du SGBD). Il est donc beaucoup plus facile de trouver un point de cohrence fonctionnelle. En utilisant en plus les outils de journalisation de la plupart des applications / SGBD, on se limite la rplication synchrone de volumes limits de donnes. La plupart des outils de SGBD savent dsormais grer la notion de groupes cohrents : cela demande nanmoins un travail de conception en amont (dfinition des dpendances entre bases), puis dimplmentation technique, en allant jusquaux tests. Dans le cas particulier des architectures orientes services (SOA) : mme sil est toujours possible de mettre en place des clusters au niveau des SGBD et des serveurs dapplication (Websphere, Tomcat), il ny a pas de solution idale pour secourir les queues managers . Il faut imprativement intgrer la dimension secours ds ltude darchitecture, et prvoir les mcanismes de resynchronisation des files dattente, qui aujourdhui ne sont pas automatiques.
A noter le cas particulier de la corruption de donnes : Plus on met en place des mcanismes visant une faible perte de donnes, plus on augmente les risques en cas de corruption. Le secours se retrouve corrompu quasi-instantanment en cas de problme et du coup, il faut imprativement mettre en place des mcanismes complmentaires pour remonter dans le temps de faon toujours synchrone : par exemple, en conservant un historique des snapshots synchroniss sur 24h (ce type dopration prsente un impact significatif sur les besoins de stockage).
Ne pas oublier que les Mtiers sont toujours indispensables lors de la validation de la cohrence fonctionnelle du PRA
Malgr tous les efforts fournis au niveau technique par les quipes de la DSI, seuls les mtiers sont in fine en mesure de confirmer la validit fonctionnelle et lexhaustivit des donnes restaures : les derniers contrles doivent donc revenir aux mtiers (par exemple : par un rapprochement de balances gestion / comptables dans le cas de reprise de donnes financires).
PAGE 24
De plus, sauf exception, toutes les applications ne sont pas secourues avec les mmes exigences : il y a donc forcment des besoins de resynchronisation manuelle . Et enfin, entre les plaques secourables dfinies plus haut, il faut forcment assurer une resynchronisation : en rejouant des fichiers, en saisissant des donnes manuellement, ou par dautres procds du mme type.
Impliquer les Mtiers ds la conception de larchitecture pour prparer la validation des PRA
Comme nous avons faire des ensembles dapplications vitales, il nest pas acceptable pour la matrise douvrage de prendre des risques inconsidrs pour effectuer un test. Une architecture de type PRA froid est gnralement isole du rseau de production principal, il est alors possible deffectuer des tests sur un rseau de secours indpendant. La difficult rside gnralement dans la mise en uvre des flux hors primtre PRA. Ce test reste alors partiel. Un PRA chaud se fait gnralement sur des machines du rseau de production. Le test le plus pertinent consiste basculer les utilisateurs nominaux sur les applications en PRA. Mais la difficult rside dans la fentre de basculement choisir pour viter un arrt de service (par exemple basculement de nuit). Larchitecture doit intgrer des mcanismes qui garantissent quaucune perte de donnes naura lieu lors dun basculement programm. Un PRA haute disponibilit sans perte de donnes peut se tester par des basculements intersites. On vitera par mesure de prcaution les priodes dactivit les plus charges. Larchitecture physique des sites, la distance entre sites, le type de connexion (fibre noire) doivent tre conu pour cela.
Parmi les points prendre en compte, relevons aussi

> Lapplication teste forme-t-elle un ensemble cohrent ? - Problmatique de cohrence des sauvegardes ou des copies de donnes entre elles (diverses technologies savrent parfois ncessaires, ou il existe plusieurs serveurs coordonner et de nombreux intervenants). - Problmatique du moment de linterruption. Par exemple, si celle-ci met fin de manire anticipe un traitement batch, il sera ncessaire de repartir avec des donnes dans ltat o elles se trouvaient au dbut de ce batch. > Les procdures de redmarrage doivent tre prvues avec des sauvegardes /copies durcies indpendantes du moment du sinistre. > Inclure cette conception dexploitation des sauvegardes et des attentes en termes de RTO et RPO dans la rflexion sur le choix de larchitecture. Selon la criticit les solutions sont varies (cot) mais la base de rflexion reste valable. > Consulter les documentations des constructeurs dcrivant les processus de duplication et copie des donnes, les engagements des infogrants/hbergeurs, etc. > Gestion des flux et historisation des messages/fichiers. > Sentrainer faire des tests (voir infra).
PAGE 25
LiVRE BLANC
2.4 En conclusion
Comment passer du chaos lordre ? Voil qui pourrait rsumer la vocation dun chapitre sur la gestion de la cohrence applicative. En ces temps de complexit grandissante des SI, quelle est la solution optimale pour assurer un PRA ? Pas de rponse dfinitive, mme si nous le dplorons, mais pour clore ce chapitre nous vous proposons quelques pistes de rflexion complmentaires.
2.4.a Mettre en place une gestion du PRA par groupes dapplications (pour les reprises : rejeu, limination des doublons, etc.)
Une telle dmarche savre judicieuse dans un environnement o les groupes dapplications sont bien compris et matriss par les mtiers. De plus, dans certains cas le mtier possde des contrats de service dfinissant les changes avec dautres groupes dapplications ou mtiers (les scnarios de reprise sont alors intgrs au niveau fonctionnel, ou bien la reprise concerne des blocs fonctionnels plutt que des blocs techniques). Cette gestion du PRA doit tre prise en compte et formalise pour chaque application, voire dplace vers un outil ou une application spcialise (ce qui dpend de la taille du groupe dapplications, de la complexit du service, de la connaissance fonctionnelle, etc.)
2.4.b Crer des points stables

Pour toutes les applications interdpendantes, cette procdure consiste prendre : une mme image des applications et de leurs donnes des moments choisis, ou des images synchronises (groupe de cohrence ou consistency group). Mais crer des points stables savre une procdure complexe et contraignante. Procdure Complexe : elle demande une dfinition rigoureuse des diffrents lments concerns et de leurs interdpendances lors de sa conception et de sa mise en place, et risque de ntre valable que pour des primtres limits. Procdure Contraignante : elle impose le respect dun horaire de prise dimages lensemble fonctionnel qui a t dfini (avec probablement la ncessit dun microfigement coordonn), elle peut limiter les volutions futures (chaque volution induit de nouveaux changes, donc des changements de primtre, de nouvelles interactions intgrer dans lannuaire des points stables, etc.) Si ces calendriers de figement sont contraignants (figements temporaires) on en limitera le nombre, ce qui savrera prjudiciable une faible perte de donnes. Mais lide est intressante, surtout si on la rapproche de la prcdente dans un plan de groupes dapplications et de points stables par groupes dapplications.
2.4.c Revoir lurbanisation du SI

Il sagit dinstituer ou damliorer le zonage des changes inter-applicatifs pour faciliter les reprises intra-zone (chacun chez soi) et interzones (ouverture progressive vers lextrieur). On peut envisager pour une telle pratique la mise en place doutils
PAGE 26
de gestion spcialiss dans chaque zone et des points de passage auditables (monitoring des Firewalls + traitement des logs par exemple) complts par des outils globaux de gestion des flux et des reprises. Encore une piste prometteuse mais non universelle et qui suppose de longs mois de conception et probablement des annes de mise en place (pour les grands groupes multi-datacenters).
2.4.d Sen remettre aux constructeurs ( ? ...)

Une autre solution consiste sappuyer sur les dveloppements technologiques et logiciels de nos fournisseurs (de stockage essentiellement), si ces technologies apportent une solution fiable, universelle et globale. La rponse est vidente avec ce dont nous disposons en 2010. Explications : Il existe des rponses (partielles), par la cration de groupes de cohrence associs des procdures de rplication journalise, ou au travers de boitiers de type RecoverPoint par exemple. Mais rien duniversel qui prenne limage de lensemble dun SI et la transfre dans un endroit sr, prte pour relancer toute lactivit de lentreprise. Heureusement pour ce type de scnario quelques exclusions sont assez faciles dterminer : - les applications peu sensibles, - celles dont les donnes voluent peu ou rarement, - et les applications scurises par une solution de pleine haute-disponibilit. Cellesci devront cependant se coordonner avec les arrts ventuels de leurs partenaires pour la cration de points stables.
Les limites : lextension du primtre gr (et rput cohrent) se trouve limite par les contraintes de volumtrie, de dbits rseaux, ou une nouvelle fois de coordination dapplications trop nombreuses. Et pour lheure, le constat reste que la technologie rpond trs bien aux besoins de cohrence application par application mais ne prend que partiellement en compte les contraintes de cohrence entre applications. De plus, pour atteindre une relle cohrence fonctionnelle cette technologie doit tre intgre ds la conception de larchitecture afin den tirer le meilleur parti. Cela peut poser des problmes de compatibilit ou dvolutions ultrieures.
2.4.e Un mix de ces quatre pistes

Bien videmment, lorsque le SI est htrogne avec un fort historique, on va sinspirer des quatre approches, les panacher pour arriver LA solution.
PAGE 27
LiVRE BLANC
DCLENCHEMENT DU PRA ET GESTION DE CRISE

L o il y a danger, crot aussi ce qui sauve Hlderlin
3.1 Introduction
Pour importants quils soient, les aspects techniques du PRA nen constituent quune partie. Le jour o survient un accident grave ou un sinistre, il faut dcider, et dcider vite, de la mise en uvre ou pas des moyens techniques pralablement dfinis, puis grer la situation de crise jusqu sa rsolution. Il sagit donc bien dans ce chapitre denvisager lorganisation pralable mettre en place. En effet, choisir de dclencher le PRA ne va pas de soi. Laccident nest peut-tre pas si grave. Et mme grave, ne saurait-on y remdier plus rapidement, avec une moindre perte de donnes, quen recourant au PRA ? Dans cette situation, qui donc prendra la dcision de dclencher les oprations de secours ? En sappuyant sur quels critres pertinents, dfinis auparavant par qui ? Noublions pas que dans le monde des plans de reprise informatiques, comme dans celui de lAssurance, la difficult consiste toujours bien prvoir les risques, et pondrer leur probabilit doccurrence selon la gravit de leurs ventuels impacts. Qui sera ensuite charg de lapplication des diffrentes parties de ce plan, pas seulement au sein du service informatique, mais aussi du ct des mtiers et de la direction gnrale ? Pour rpondre de faon efficace ces questions le jour du sinistre, un travail en amont simpose : qualification des process critiques, hirarchisation des priorits, tablissement dun organigramme clair pour les prises de dcision, gestion prvisionnelle des ressources humaines, prparation des communications autant de tches effectuer avant pour ne pas aggraver les consquences pendant. Cet ensemble de garde-fou ne garantit pas que le jour venu tout se droulera bien, mais il fournit un cadre au sein duquel agir. Or, dans une situation critique, par dfinition stressante, pouvoir sappuyer sur des procdures claires et compltes constitue un bon moyen dattnuer le choc.
3.2 Rsum du chapitre

Ce chapitre porte essentiellement sur des points dorganisation. Un PRA suppose de mettre en place une architecture physique pour la reprise, comme nous lavons vu, mais aussi une architecture humaine sous la forme dune organisation et de processus pour traiter au mieux la difficile conduite des oprations en situation de crise. Nous explorerons ici les diffrentes composantes de cette organisation, en partant des retours du terrain. Ceux-ci nous montrent que de nombreuses entreprises ont mis au point un processus de gestion de crise structur pour dcider de lactivation des PRA et les conduire bien.
PAGE 28
Ce processus couvre trois domaines essentiels : 1 - Diagnostics, dcisions, actions 2 - Organisation 3 - Communication Il rpond ainsi aux questions : qui, quand, quoi, o, comment. Ce chapitre : Prsente dabord le principe de lescalade qui conduit transformer lincident en incident majeur, moment partir duquel se pose la question de dclencher le PRA. Donne donne voir comment dans lorganisation de crise se structurent les responsabilits, et qui dcide du dclenchement du PRA. Couvre la question des critres de dclenchement du PRA par type dincidents, et celle des outils capables de lier ces incidents lactivit de lentreprise. Les deux dernires parties portent sur le partage des tches entre quipes durant la crise, et sur les stratgies de communication mettre en place.
NB : Ce chapitre traite de la partie Informatique du PRA et ne couvrira pas les aspects mtiers (PCM).
3.3 La gense : Le PRA naquit de lincident majeur

La gestion des incidents
La gestion des incidents est un processus critique qui vise dtecter les incidents le plus tt possible, puis cibler le support technique appropri pour les rsoudre dans les dlais les plus brefs. Les objectifs de la gestion des incidents se rsument comment suit : Rsoudre les causes dinterruptions de service le plus rapidement possible, en rduisant autant que possible leur impact ngatif sur lactivit de lentreprise (des solutions de contournement sont envisageables). Sassurer du maintien des niveaux de qualit de service et de disponibilit. Sassurer que les correctifs idoines ont t appliqus sur lensemble du SI pour viter la reproduction des incidents connus. Disposer dun recueil (Base de donnes, fiches, procdures) regroupant ces correctifs pour gagner en ractivit si lincident se reproduit.
Procdure dincident majeur

La procdure dincident majeur concerne les incidents critiques qui menacent la capacit maintenir lactivit ou le fonctionnement efficace de lentreprise. Bien que ces incidents continuent de suivre le cycle de vie normal de la gestion dincidents,
PAGE 29
LiVRE BLANC
la procdure dincident majeur dcrit les niveaux de coordination, descalade, de communication et de ressources quexigent ces vnements de haute priorit et de caractre exceptionnel. La procdure de gestion de crise vise fournir un cadre pour la prise en charge de ce type dincidents.
ITIL et les PRA : Pour plus dinformation voir article complmentaire en Annexe.
3.4 La gestion de crise : une organisation et un processus
Figure 10 : le processus de gestion de crise
3.4.a Organisation
Pour rpondre lapparition dun incident majeur ou critique (sinistre), une Cellule Technique Oprationnelle (CTO), constitue de collaborateurs appartenant une ou plusieurs cellules techniques (N2-N3), prend en charge ltablissement du diagnostic et tente de rtablir le service aux utilisateurs au plus vite. Il arrive cependant que le dlai de rsolution sallonge. Lexprience montre en effet que les personnes en charge de lincident ont souvent une approche optimiste du temps de rsolution ncessaire. Alors se pose la question : partir de quel moment faut-il basculer vers le PRA en arrtant ou non la rsolution de lincident ? Qui prend la dcision ? Le niveau de validation dpend de la solution (diffrent entre un PRA en haute disponibilit et un PRA froid) mais en gnral la CCD (cellule de crise dcisionnelle) porte cette responsabilit. Cette dernire prend en charge la coordination, le suivi et la communication durant toute la dure de la crise. La CCO se compose doprationnels mtiers, elle a pour fonction de coordonner les oprations, de piloter le CTO, dorganiser les plans dactions, de collecter et danalyser les options soumettre la CCD, puis de faire excuter ces dcisions. Cette CCO reste mobilise durant toute la dure de la crise Il est souhaitable que la CCD soit compose de personnels autoriss prendre les dcisions les plus importantes, et valide en dernier recours le dclenchement du PRA et la communication qui sensuit. Selon la criticit du mtier, il peut tre opportun davoir une astreinte managriale par domaine (cadre de permanence).
PAGE 30
Un exemple de formalisation de crise
Figure 11 : la pyramide descalade
3.4.b Processus
Pour illustrer linteraction des entits susnommes dans le circuit de prise de dcisions, nous vous proposons un schma simplifi du processus oprationnel :
Figure 12 : schma simplifi du processus oprationnel de gestion de crise

PAGE 31
LiVRE BLANC
NB : Il nest pas utile que les diffrentes cellules soient physiquement prsentes (conf call ou autre).
Il est possible davoir des arbres de dcisions disposition de la CCD pour diminuer le dlai de prise de dcision et justifier lorientation prise. Lorganisation de ces cellules doit aussi faire lobjet dexercices. La difficult tant souvent dassurer la prsence de certains cadres dcisionnaires.
3.5 Les critres de dclenchement

Les critres de prise de dcision varient en fonction de la nature du PRA ( froid, chaud, en haute disponibilit) et dpendent gnralement de deux facteurs cl : Le respect des objectifs de temps La capacit restaurer le niveau de service convenable La prise de dcision est toujours difficile surtout lorsque le dlai ncessaire la Production pour restaurer le service est mal connu. Vaut-il mieux partir tout de suite sur un PRA, avec des pertes de donnes et de disponibilit connues et en partie lies la nature du PRA en place (PDMA) ou temporiser parce quun contournement serait ventuellement possible ? Un PRA en haute-disponibilit, dans lequel les pertes de donnes approchent de zro, rend plus simple cette prise de dcision quun PRA chaud ou froid, dans lesquels les impacts en perte de donnes existent, et sont parfois trs lourds. Dailleurs, dans le cas dun PRA en haute disponibilit, la prise de dcision perd de son importance puisquil existe des procdures dautomatisation de la bascule ou dintervention ponctuelle dun oprateur selon une procdure prdtermine.
3.5.a Un objectif de temps

Un PRA doit satisfaire deux exigences dfinies par la Matrise douvrage (MOA): le dlai maximal dinterruption Admissible (DMIA) et la perte de donnes maximale admissible (PDMA). En complment de quoi, la matrise duvre (MOE) fixe le dlai de reprise vis (RTO : Recovery Time Objective) et le point de reprise informatique vis (RPO : Recovery Point Objective). Attention bien dterminer quand dmarre le chronomtre du DMIA : Constat de lincident par lutilisateur, ou Constat avr par la CTO, ou Dcision de la CCD.
Figure 13 : RPO et RTO

PAGE 32
La fin du RTO est dcide par la CCD suite constat des mtiers ayant valid la reprise fonctionnelle des applications.
Il est conseill de se mettre daccord avec les mtiers sur la dure de prise de dcisions.
NB : Dans les schmas suivant les pavs bleu, orange et jaune de la zone RTO illustrent le diffrentiel temporel du dmarrage RTO selon les rgles dfinies par lentreprise.
Figure 14 : le RTO par type de secours : secours froid
NB : La rfection des travaux dj faits consiste appliquer lensemble des traitements intervenus entre la dernire sauvegarde de recours utilise et le moment du sinistre.
Figure 15 : le RTO par type de secours : secours chaud
PAGE 33
NB : Ces paramtres RTO et RPO serviront dlments de base pour prendre la dcision de basculer.
LiVRE BLANC
Figure 16 : le RTO par type de secours : secours en haute disponibilit
Le point de non-retour est le point partir duquel il ne faut plus retourner en arrire (mme en cas de retour la normale sur le site primaire) mais continuer imprativement la bascule engage. En effet, le risque associ au retour ltat initial devient progressivement plus important que celui associ la continuation de la procdure de PRA en cours. Il faut alors toujours aller vers un tat connu, fiable et stable en utilisant le PRA test.
Exemple de critres et escalade par type de sinistre physique ou logique Sinistres physiques
Type de sinistre physique Critres Si certitude de coupure de lalimentation lectrique suprieure 12 heures ouvres Problme lectrique Coupure lectrique gnralise touchant les salles informatiques quelle que soit la dure estime de redmarrage. Si non matrise en 5mn dun incendie proche ou lintrieur du btiment Informatique Dans tous les cas Si le matriel dune salle informatique a t touch Si intrusion non matrise dans lenceinte du btiment informatique Dans tous les cas Si impact sur le fonctionnement du SI (tlphonie, rseau, serveurs, ) Si dure probable dinterruption suprieure 4 heures ouvres Si temprature suprieure 25 dans locaux informatiques et si certitude de dfaillance de la climatisation suprieure 4 heures Dans tous les cas Passage de niveau 1 en niveau 2 : (voir tableau supra) Alerte du responsable dastreinte Escalade
Incendie Dgagement intempestif de CO/gaz inertes Dgts des eaux Intrusion dans le btiment Evacuation force du personnel Vandalisme Coupure de laccs tlcoms dans les locaux darrive tlcoms Climatisation de la salle informatique Blocage daccs au btiment informatique
PAGE 34
Sinistres logiciels en heures ouvrables

Type dincident ou panne logicielle Critres Si le transactionnel ne peut pas tre lanc en consultation ET si certitude darrt suprieur 4 heures ou si aprs 2 heures danalyse/ intervention de la maintenance, le redmarrage en 2 heures nest pas certain Si certitude darrt suprieur 4 heures Raction
Incident ou panne qualifi de priorit 1 impactant uniquement linformatique
Passage de niveau 1 en niveau 2 : Alerte du responsable dastreinte DSI
Obligation darrter les moyens informatiques
Sinistres logiciels en heures non-ouvrables

Type dincident ou panne logicielle Critres Sil nest pas possible de terminer le plan de production ou Si le transactionnel ne peut pas tre lanc en consultation ET si certitude darrt suprieur 4 heures ou si aprs 2 heures danalyse/ intervention de la maintenance, le redmarrage en moins de 2 heures nest pas certain Si certitude darrt suprieur 4 heures Raction
Incident ou panne qualifi de Priorit 1 (rsolution en moins de 4 heures) impactant uniquement linformatique
Passage de niveau 1 en niveau 2 : Alerte du responsable dastreinte DSI
Obligation darrter les moyens informatiques
NB : Les chiffres en gras correspondent des paramtres spcifiques qui varient pour chaque entreprise
3.5.b Un objectif de service

Si lentreprise est tourne vers la satisfaction client, sa solution de continuit dactivits le sera aussi. Ainsi, lentreprise recherchera les solutions qui lui assurent de continuer satisfaire ses engagements pour chacun des risques auxquels elle aura choisi de se prparer. Pour dfinir la nature de ces engagements et les spcifier clairement : Chaque direction mtier doit identifier ses processus mtiers, et dsigner les plus critiques. Chaque direction mtier fixera ses propres objectifs oprationnels en cas de sinistre, tels que rpondre aux clients moins de 24 heures aprs laccident, honorer les commandes avec au plus un jour de retard, etc. Les services support (au premier rang desquels ceux attachs aux systmes dinformation) valuent leurs propres contributions ces processus mtiers, et les objectifs oprationnels en cas de sinistre correspondants. Lexamen dtaill des contrats de service est abord dans le chapitre 6.
PAGE 35
LiVRE BLANC
3.6 Des outils pour tablir ses priorits

La Matrice BIA (Business Impact Analysis/Analyse dImpact Mtiers)
La matrice dAnalyse dImpact Mtiers est la pierre angulaire sur laquelle btir la stratgie associe un PRA. Elle consiste identifier les processus, les systmes, les fonctions, les missions critiques pour lentreprise. Cette analyse doit adresser un objectif majeur : minimiser limpact dun incident en termes financiers directs ou indirects, viter la dtrioration de limage de marque de lentreprise, assurer le respect de ses obligations rglementaires (Solvency, Ble II), garantir sa prennit sur les marchs boursiers, assurer le respect de ses obligations contractuelles avec ses clients, limiter la perte de productivit. Elle sinscrit dans une dmarche qui comporte trois phases : - Etude de risques (Probabilit / Impact) - Analyse des Impacts Mtiers - Besoins de reprise
Figure 17 : le BIA
Cette opration se base sur diffrentes approches mais pourrait idalement inclure les items suivants : Un dcoupage des missions, des fonctions, des process de lentreprise Une description des processus, listant les processus entrants et sortants et leurs interactions avec les processus tiers Une description des temps maximaux dinterruption admissibles (DMIA) avant impact sur le mtier avec les objectifs de reprise (RTO) correspondant Une valuation des impacts financiers et oprationnels dcoulant de linterruption Une description des ressources techniques et humaines ncessaires pour supporter ces processus Une description des impacts juridiques possibles Une description des incidents passs et de leurs impacts Avant datteindre une maturit suffisante dans la description complte de la matrice dAnalyse dImpact Mtiers, une approche plus simple peut suffire ; condition quelle inclue les DMIA souhaits par les mtiers et valids par la DG.
PAGE 36
La DSI peut proposer aux mtiers trois niveaux de reprise dactivits : Un niveau or correspondant au secours haute disponibilit Un niveau argent correspondant au secours chaud Un niveau bronze correspondant au secours froid Les RTO / RPO correspondants ces trois solutions sont proposs aux mtiers avec leurs cots associs.
Figure 18 : classification des processus
Il existe dautres types de matrices, comme la matrice technique dimpacts mtiers utilise plutt par les oprationnels au sein des DSI :
Figure 19 : matrice technique dimpact
Elle permet de mesurer rapidement limpact dun incident technique (panne dun serveur, perte dun rack, dysfonctionnement dune baie de stockage, ) sur une population particulire, sur un applicatif, sur la convention de service.
PAGE 37
LiVRE BLANC
3.7 Une organisation des quipes au service du PRA

Le niveau de service demand dans le cadre du PRA dtermine lorganisation de crise retenue. Tout est question dengagement. Dans le cadre dun PRA froid, limpact de la dcision de dclenchement est fort (arrt de processus, perte de donnes, ). Cependant, le dlai de reconstruction tant de lordre de plusieurs jours, on dispose dassez de temps pour consacrer plusieurs heures la prise de dcision, et donc le temps de consulter divers experts. Dans le cadre dun PRA chaud, la prise de dcision seffectue dans un dlai de 30 minutes pour une dure maximum dinterruption de 4 heures. Raison pour laquelle les organisations qui disposent de ce type de PRA tablissent gnralement des astreintes 24 h/24 et 7 j/7 ; astreintes oprationnelles, mais aussi dcisionnelles appeles Permanences managriales . A noter : Pour bien dcider, il faut disposer des lments dapprciation adquats. Les outils de supervision, de pilotage, jouent un rle essentiel dans lalimentation en informations de cette chaine de dcision, et ce avant toute analyse humaine plus pousse. Pour les entreprises qui disposent de PRA en haute disponibilit, la prise de dcision est souvent rduite voire automatique. Cette situation rsulte du faible impact du basculement en haute disponibilit en termes de DMIA et de PDMA.
NB : Dans le cas des bascules automatiques, il faudra sassurer de disposer dindicateurs dtats en consquence (alarme sur bascule).
La bonne organisation mettre en place pour le dclenchement dun PRA peut se composer de : Une quipe en charge du PRA qui travaille avec les quipes de production prsentes sur site au moment de la survenue du sinistre. Des astreintes au niveau dcisionnel comme oprationnel. Un accord avec la DRH concernant les conditions de travail en situation de crise : heures supplmentaires, drogation la dure lgale quotidienne de travail, travail le dimanche ou la nuit (voir livre CCA). Ce qui nous emmne rappeler que ce sujet devrait tre couvert dans le cadre du volet Ressources Humaines du PCA/PRA selon 3 axes : Faire connatre : tablir un dispositif et des dmarches RH spcifiques sappliquant en cas dincident majeur impactant lentreprise. Savoir faire : formation et organisation des quipes exploitant le SI en heures non-ouvrables. Faire adhrer : dfinir les rgles du jeu applicables dans le cadre dune situation exceptionnelle (astreintes, rmunration, compensations). Il sagit de trouver un quilibre entre la stratgie de continuit, les besoins mtiers et les ressources disponibles dans la situation de crise.
PAGE 38
3.8 Communication Cible de crise

Pour viter quune communication dfectueuse ne laisse le client interne ou externe dans un flou potentiellement ravageur il faut anticiper en ayant tabli lavance des rgles de communication interne et externe. La communication dans ce type de situation savre primordiale : pour viter le sentiment de ne pas tre tenu au courant, viter les spculations, dgonfler les rumeurs, il est ncessaire de communiquer frquemment, rgulirement et clairement.
NB : Un devoir de rserve doit tre systmatiquement rappel aux collaborateurs.
Communication Interne
Il est ncessaire davoir prvu lavance une communication interne destine lensemble des employs de lentreprise, quils soient directement impliqus ou non. Les informations communiquer sont valides par la CCD. Ces informations sont transmises par le DRH ou ses dlgus. Les moyens utiliser : messagerie, intranet, alertes SMS, courriers, cascades tlphoniques. Certaines entreprises disposent aussi dun site internet de crise (Accs scuris) hberg chez un tiers. Pour pallier une dfaillance de la messagerie interne, il peut tre ncessaire de disposer dune messagerie de crise externe. Les SMS sont privilgier. Les messages dalertes comportent usuellement les lments suivants : Historique Incident : Niveau de criticit: Fort/Moyen/Faible Niveau de vigilance (attaque scurit) : Site Impact : Impact Mtiers : Impact Utilisateur: Cartographie de limpact: Processus Incident Dclench : Heure du dclenchement : Dlai de rtablissement estim : Frquence de communication :
Communication avec les partenaires et externes (mdias, )

Lexercice de communication reste dlicat car souvent li des aspects contractuels de fourniture de service. Il faut en gnral accepter en toute transparence (et toute confiance) dalerter sur la nature de lincident (sa gravit, ses impacts, ), tout en rassurant le partenaire sur un vnement quil ne peut valuer et qui touche son activit. Llment cl des changes reste le suivi des oprations en conformit avec le dlai de reprise estim et ngoci. Ce volet, souvent sensible, ressort de la responsabilit dune cellule de communication dentreprise ddie sous la responsabilit de la CCD.
PAGE 39
LiVRE BLANC
A retenir pour une communication efficace : - Alerter sans alarmer - Communiquer rgulirement - Informer de faon claire et transparente
3.9 Retour une situation normale
Une fois le PRA activ et la bascule vers les moyens de secours effectue, il reste parcourir lautre moiti du chemin, souvent la plus dlicate, car la moins teste. La dcision de revenir une situation normale est prise par la CCD sur avis de la CCO. Le retour arrire nest pas toujours dcrit dans le PRA car il dpend de la nature du sinistre : Retour envisageable sur le site de production aprs quelques jours ou quelques semaines, par exemple lissue du temps de rhabilitation du site suite un dgt des eaux. On considre gnralement quil est acceptable de ne plus disposer de PRA pendant cette phase. Mais il faut alors muscler les scurits et veiller particulirement la mise horssite des sauvegardes. Retour impossible sur le site de production, par exemple destruction totale du site dans un incendie. Il est alors ncessaire de revoir limplantation des applications sur dautres datacenters existants (rserve despace) et ceci dans un dlai raisonnable afin de restaurer le niveau de service en cas de nouveau sinistre majeur. Avant de retourner en situation normale, il faut sassurer davoir un systme de sauvegarde externalise. Nous avons vu que dans un PRA les ruptures de disponibilit et les pertes de donnes dpendent du niveau de service choisi : froid, chaud, en haute-disponibilit. Cependant, le retour en arrire tant une opration programme, et non pas provoque par un incident, on essaiera den rduire les effets au maximum, en se fixant une dure dinterruption minimale et connue, et une perte de donnes nulle. Comme pour la bascule en PRA, le retour en production normale doit aussi faire lobjet de tests.
PAGE 40
3.10 Quelques leons tirer

La principale difficult en situation de crise consiste souvent conserver les bons rflexes : 1) suivre les procdures dfinies, 2) canaliser les nergies : viter les nouvelles ides intempestives, se mfier du stress, vrifier que les quipes se reposent, 3) sparer clairement les oprationnels des dcisionnaires : avoir un relais entre les deux, 4) effectuer des points davancement rguliers (suivre une main-courante), 5) communiquer, communiquer et communiquer, diffremment selon les cibles et clairement.
Maturit des membres du CRiP

Exploitation du questionnaire
Qui prend la dcision de basculer en PRA ? CCD : DSI : DG : 67% 22% 11%
En Synthse: le manque de formalisation est souvent mise en avant : tant au niveau des processus, de la communication que sur lorganisation RH.
Disposez-vous dun diagramme descalade clairement tabli et diffus ? OUI : NON : 62% 38%
Quelle matrice daide la dcision utilisez-vous ? Critres dfinis dans le PCA : Convention de service : Dcision mtier : 25% 35% 40%
Disposez-vous dune communication prtablie : Oui : Non : 60% (communication interne) 40%
Dans le cas dun dclenchement de PRA de nuit avec rappel de salaris : quelle organisation, quel amnagement RH, ... avez-vous mis en place ? Dispositif exceptionnel prvu par les RH : Rgulation post-incident : 50% 50%
PAGE 41
LiVRE BLANC
VALIDATION PROBANTE DU PRA

Les tuiles qui protgent de la pluie ont toutes t poses par beau temps Proverbe chinois
4.1 Introduction
Lorsquun sinistre se produit, la cellule de crise dcisionnelle se pose toujours la mme question : le PRA est-il oprationnel ? Assurera-t-il la reprise de lactivit dans le dlai prvu ? Les tests et exercices constituent le seul moyen dapporter une rponse crdible ces questions. On peut mme affirmer quun PRA non test rgulirement est un PRA qui nexiste pas. Dans cette logique, quelle suite de tests et dexercices probants faut-il dfinir et raliser afin dacqurir la quasi-certitude quau moment voulu le PRA fonctionnera ?

Aprs avoir dfini tests et exercices, ainsi que leurs buts respectifs, ce chapitre dgage un certain nombre de critres pour qualifier une validation probante. Ces critres sont indpendants du type de secours ( froid, chaud ou en haute disponibilit).
4.3 Dfinitions
Test et exercice (dfinitions issues du Livre Blanc du Club de la Continuit dActivit : Lexique structur de la continuit dactivit) : Il est ncessaire de faire une distinction entre test et exercice : Le test est destin apprcier la validit dune modification (innovation, mise niveau, correction, ) et produit un rsultat binaire (russi ou non russi). Le test a un caractre exploratoire qui peut conduire un chec. Lexercice constitue un entrainement, et correspond lentretien dun savoir-faire, la rptition dune mise en situation matrialise par un scnario de sinistre. Il sert maintenir le niveau de comptence de lensemble des participants, et prparer les utilisateurs finaux.
Type dexercice
Lorganisation dun test ou exercice rsulte souvent dun compromis entre le risque pris lors de sa ralisation et le caractre probant que lon en attend. En consquence, une grande majorit des tests prsentent un primtre plus rduit que celui dune crise relle, par exemple ils ne dbutent pas de faon inopine, mais sont prpars lavance et planifis. Pour les plans de secours froid et chaud (comme nous le verrons plus bas, la haute disponibilit constitue un exemple part), lexercice sera simul ou rel, prpar ou impromptu. Un plan de validation complet du PRA doit prendre en compte ces quatre types dexercices.
PAGE 42
Les exercices de type prpars et simuls sont videmment les premiers pratiquer de par leur faible caractre perturbateur.
Exercice simul Exercice rel La date de lexercice est connue de tous les participants. La production est arrte, le secours prend le relais (Primtre en fonction des dcideurs). La date de lexercice est inconnue de tous les participants. La production est arrte, le secours prend le relais (Primtre en fonction des dcideurs).
Prpar
La date de lexercice est connue de tous les participants. Il ny a pas darrt de la production.
La date de lexercice est inconnue de tous les participants. Inopin Le fonctionnement en mode secours est valid, mais il ny a pas darrt de la production.
Les exercices de type prpars et rels vrifient que le fonctionnement sur le site de secours seffectue dans des conditions acceptables. Les exercices de type simuls et inopins vrifient la ractivit des participants dans des conditions proches des conditions relles, mais sans faire courir de risque au bon fonctionnement de la production.
Exercice hors-production et exercice en production

Le risque li lexcution dun exercice hors-production ou en production diffre videment, mais ces deux types de simulations ne relvent pas du mme niveau dexigence. - Les exercices horsproduction offrent plus de souplesse dans les tests et lentrainement des populations concernes. Ils contribuent rendre les gens moins frileux lide de faire le grand saut de lexercice en production. Cependant ils ne prparent pas avec le maximum defficacit les quipes ragir une situation de crise relle. - Les exercices en production : sont idaux (de par leur nature) car effectus en situation relle. Ils ncessitent cependant une prparation plus dlicate : bascule en heures non-ouvrables (le soir, la nuit ou le week-end), et un retour-arrire vers la production normale sans perte de donnes.
NB : Le passage dun mode dexercice lautre dpend de la maturit du PRA, du niveau de comptence atteint par les quipes, de la confiance dans les processus mis en place, mais aussi de la volont de rpondre des contraintes oprationnelles fortes.
On note ainsi que certaines entreprises du CRiP, par exemple celles qui se trouvent fortement soumises des rgulations bancaires, ou encore des services publics, excutent souvent des exercices de PRA en conditions relles. La dure de lexercice varie alors selon le mode de bascule (ex : bascule technique le week-end et fonctionnement rel en mode PRA durant la semaine ; bascule en HD ; ).
PAGE 43
LiVRE BLANC
Dans ce cas, la ralisation et la validation de lensemble des cahiers de tests techniques et fonctionnels sur le site de secours constituent un pralable au GO/NOGO pour lexcution du test du PRA en production. Lactivit mtier peut ensuite sexcuter dans ce nouvel environnement devenu similaire lenvironnement de production. La phase de retour arrire, pour revenir sur le site de production primaire, est toujours critique car elle oblige respecter deux tapes prliminaires : 1 - Qualifier les donnes enregistres sur le site de secours pour sassurer de la cohrence entre les deux sites. 2 - Resynchroniser les donnes sans perte pour les mtiers (mise jour des donnes commerciales, des annuaires, des messageries, ).
Frquence annuelle des exercices

Il nexiste pas de rgles tablies, cependant, comme le dit bien la formule : si rien nest obligatoire, il est fortement conseill de Les retours dexpriences du CRiP montrent quun PRA froid ncessite au minimum un exercice par an. Quand au secours chaud, il impliquerait idalement deux exercices par an. La haute disponibilit demanderait des tests plus frquents (selon les organisations, les montes de version applicatives permettent aussi de tester la bascule). Il est envisageable de fonctionner 50 % du temps sur chaque environnement (mois pairs et impairs par ex.).
Dure des exercices

Les exercices se droulent gnralement sur une dure courte, de lordre dune journe une semaine. Il est souhaitable de tester les PRA sur une priode plus longue. En effet, certains incidents ne se produiront quau-del des premires 24 heures. Un exemple : sur le site de secours, ont t installes des licences logicielles provisoires, uniquement pour faire des tests. Suite la bascule sur le site de secours, et en labsence de rgularisation rapide de ces licences, les applications cessent de fonctionner au bout de quelques jours. Selon Gartner, 60 % des entreprises ne prvoient pas de plan de continuit dactivits audel de sept jours (Janvier 2008. Source : 359 professionnels de la gestion des risques et de la scurit informatique aux Etats-Unis, en Grande Bretagne, et au Canada.)
4.4 Quelques critres pour qualifier un exercice probant

Remarque
Probant : en franais, fait rfrence une preuve. Langlais ne possde pas dquivalent. On parle dans cette langue de confiance et dacquisition dassurance. Les lments de validation et de qualification de lexercice doivent imprativement tre mis par crit avant le dbut de lexercice, ce qui permettra que la validation seffectue selon des critres connus. Les mtiers doivent valider ces critres avant lexercice.
PAGE 44
Pour valuer la valeur probante des exercices de PRA nous proposons une liste non exhaustive de critres ligibles. Ces critres visent un double but : parfaire le PRA suite un exercice ; valuer la maturit du PRA avant son dclenchement. 1. Le primtre du PRA sest-il avr adquat aux besoins ngocis avec les mtiers partir de leurs exigences : applications secourues, processus de gestion de crise, nombre de personnes impliques ? 2. Le scnario de sinistre pris en compte tait-il raliste et valid par la direction des risques ou son quivalent ? 3. Les conditions de reprise dactivits observes (RTO, RPO) ont-elles t conformes aux conditions attendues par les mtiers (DMIA, PMDT) ? 4. Lentrainement des dcideurs et des oprationnels : Limplication des responsables (et de leurs remplaants) pour dcider du dclenchement a-t-elle t satisfaisante ? Limplication des hommes cls oprationnels a-t-elle t satisfaisante ? Les hommes cls oprationnels sont-ils en nombre suffisant pour assurer le bon droulement du PRA tout moment ? 5. Les dernires mises jour du PRA ont-elles t testes ? 6. Les exercices ont-ils t rejous par une autre quipe ? En effet, les procdures crites doivent toutes tre r-excutables par des personnes ne les ayant pas crites. 7. Les conditions de stress des participants taient-elles suffisantes ? 8. Les exercices ont-ils rvl des erreurs ? Dans le cas contraire, on se demandera si lobservation a t suffisamment fine. Ou on considrera avoir russi un exercice probant. Ces erreurs doivent tre diagnostiques, faire lobjet dun plan dactions correctives, et ce plan doit faire lui-mme lobjet dun rapport dexcution. 9. Les conditions darrt simulant le sinistre comportaient-elles assez dlments alatoires pour viter que lexercice ne se droule dans des conditions trop propres et donc peu ralistes ? Pourra-t-on ventuellement reprendre lactivit avec une perte de donnes ? 10. Des exercices inopins avec une prparation limite ont-ils t raliss ? 11. Le test/exercice a-t-il t contrl par des observateurs internes ou externes indpendants ? 12. La dure de lexercice a-t-elle t suffisante pour caractriser un scnario de sinistre raliste ? Un jour ne suffit peut tre pas ?
PAGE 45
LiVRE BLANC
NB : Ces critres ne sont pas des conditions ncessaires et suffisantes pour qualifier de probant un exercice. Pour ce faire, il doit atteindre les objectifs pralablement tablis par une entit de lentreprise (Risques, Mtiers) diffrente de la DSI. Il doit aussi faire lobjet dun compte rendu valid et sign par les parties prenantes. Rappel : Les correctifs apports suite aux incidents doivent faire lobjet dun procs-verbal de mise en place annexs au compte rendu. NB : Le risque pris lors de la ralisation dun exercice de PRA ne doit pas tre suprieur au risque que lon cherche couvrir !
Cependant, lexercice inopin est celui qui se rapproche le plus des conditions relles, et par consquent le plus probant.
4.5 cueils et bonnes pratiques

Quelques leons tirer : De limportance des procdures : bien crites, bien jour, bien testes, bien contrles. Ce qui nest pas crit nexiste pas ! Ce qui nest pas jour ne sert rien ! De limportance du pilotage : coordonner les actions, consolider les informations, dmarches primordiales afin dviter les initiatives individuelles intempestives et pour permettre que les arbitrages ncessaires soient rendus conformment aux procdures. Quelques cueils viter : viter les bruits de fond : pas de correctifs juste avant lexercice rel, partir dune situation stabilise. Le Maintien en Condition Oprationnelle est un travail permanent, il ne seffectue pas uniquement les jours dexercice (des tests techniques pralables doivent tre effectus pour assurer la russite de lexercice). Veiller ne pas fatiguer excessivement les quipes, prvoir des remplaants.
PAGE 46

Le SI est-il test partiellement ou totalement au cours de vos exercices ? Production complte : Production partielle : Quel est le primtre des tests ? Par brique dinfrastructure : Par applicatifs mtiers : 50 % 50 % 53 % 47 %
Ce qui a t test est-il reproductible par dautres personnes ? Oui : Non : Ne sait pas : 60 % 20 % 20 %
Les tests / exercices sont-ils contrls par des observateurs internes ou externes indpendants ? Oui : Non : 80 % 20 %
Les conditions de reprise dactivits (RTO, RPO) sont-elles mesures ? RTO mesur : RPO mesur Ne sait pas : 48 % 26 % 26 %
Faites-vous des exercices inopins ou seulement un moment propice ? Moment propice : Inopin : Quel est le niveau de prparation des tests ? Prpar : Inopin : Ne sait pas : 79 % 16 % 5% 80 % 16 %
Raisons pour lesquelles il ny a pas de tests inopins ? Manque maturit : 21 % Trop lourd : 21 % Impratif de production : 14 % Veto de la Direction Gnrale : 7% Pas de tests suffisant : 7% Test de gestion de crise inopin uniquement : 7 % Pas de demande : 7% Ne sait pas : 7%
PAGE 47
LiVRE BLANC
MAINTIEN EN CONDITION OPRATIONNELLE DU PRA

Ce qui nest pas crit nexiste pas ! Ce qui nest pas jour ne sert rien ! Confucius
5.1 Introduction
Si lexercice de PRA permet de valider les procdures, les process, et les types darchitectures techniques de reprise, la plus grande difficult dans le temps reste de maintenir le PRA jour ! Deux solutions complmentaires pour garantir ce bon entretien : la frquence leve des exercices (voir statistiques dans les chapitres prcdents) et le maintien continuel en condition oprationnelle (MCO). Tous les oprationnels partagent une mme prconisation : il faut traiter le Maintien en Condition Oprationnelle des PRA la mme frquence que les livraisons en production. Une contrainte de plus diront certains mais la gestion du risque (encore une fois) est mre de suret Selon les types de PRA, la mthode change.

Nous considrerons dabord ici les bonnes pratiques gnrales du Maintien en Condition Oprationnelle, en insistant particulirement sur la dimension dynamique qui doit caractriser cette opration. Nous dclinerons ensuite les spcificits propres au MCO des trois architectures de PRA de rfrence que nous avons dj dfinies. Nous rappelons ensuite que ce MCO participe la gouvernance globale du SI, et que sil existe des bonnes pratiques, il existe aussi des cueils.
5.3 Principes du MCO

Le PRA ne doit pas rester fig dans le temps. Il suit et prend en compte tous les changements qui concernent le SI : les patchs, les livraisons applicatives, les volutions de linfrastructure, les changements de personnes et de fonctions dans lentreprise, les volutions des conditions de reprise dactivits ... Toute volution dans lentreprise sera loccasion de se demander comment doit voluer le PRA pour sy adapter. Ltape pralable consiste dfinir le contenu du Maintien en Condition Oprationnelle du PRA et les moyens de contrler sa bonne excution : Mise jour des applications et des flux dchanges associs. Tenue jour des procdures de gestion de crise majeure.
PAGE 48
Tenue jour des procdures techniques : de restauration, de synchronisation des donnes et de bascule des changes. Maintien des comptences ncessaires la bonne conduite du PRA : acteurs des cellules de crise, personnels soumis aux astreintes oprationnelles, personnels soumis aux astreintes de la matrise douvrage. Dterminer les types de changements grer et la mthode applicable chaque type de changement: volution des quipements et des OS, des changes, Inclure les corrections des erreurs mises en vidence au cours des exercices prcdents. Le Maintien en Condition Oprationnelle du PRA doit tre trait de la mme faon que celui de la Production. Ainsi toute analyse dimpacts en production (voir cellule de mise en production du type CAB - Change Advisory Board - ou autre) suite modifications (livraisons, incidents, ) devra prendre en compte le PRA. On devra sassurer du dploiement lidentique des modifications et volutions sur tous les sites informatiques hbergeant le PRA, internes comme externes, pour maintenir la cohrence des architectures. Lors de nouveaux dploiements, la question du test unitaire de compatibilit entre sites reste dfinir : test technique unitaire ou test de plus grande ampleur impliquant les mtiers (exercices). Une attention particulire sera porte aux environnements multipartenaires de par les dpendances et incidences quils induisent dans le PRA. Il faut bien garder lesprit que toute priode de transition, toute modification ou volution non-encore propage globalement, met le PRA en tat dinstabilit. Durant une phase de modification, il existe, selon la stratgie employe (mise jour synchrone /asynchrone), le besoin de dfinir un dlai de validation. Durant ce dlai, toute bascule en PRA devient critique, car ltat du site secondaire gnrera des incidents corrigs par le MCO sur le site primaire. Pendant cette priode dinstabilit : - tout exercice est proscrire. - si un sinistre a lieu, il faut mettre niveau le second site avant toute autre opration. La CTO/CCO devra imprativement fournir la CCD un tat du site de bascule avant dclenchement du PRA. La suite du chapitre dcrit le Maintien en Condition Oprationnelle par type de solution de secours.
5.4 MCO dun PRA froid

Dans une architecture de type PRA froid, le secours se trouve gnralement isol du rseau de production. Il nest pas ncessaire dans ce cas dappliquer les changements intervenus sur lenvironnement de production de manire synchrone sur lenvironnement de PRA. Une erreur dans la gestion des changements nimpacte pas la Production.
PAGE 49
LiVRE BLANC
Dans cette situation, il est souvent admis dcraser ce qui tait install sur le site de secours selon deux stratgies majeures et complmentaires : - Vision image (ghost, RDP, PVS, NIM, ) - Vision applicative (sauvegarde complte applicative,). La question cl reste de sassurer de la disponibilit technique et oprationnelle de linfrastructure du site distant, par exemple par une surveillance minimale des serveurs, clusters, dispositifs de stockage prsents sur ce site. Une des difficults du modle du PRA froid consiste maintenir sur le site de secours un volant de ressources disponibles ou mobilisables compatibles en termes de plateforme et de capacits (RAM, CPU, stockage) avec les exigences de la production. A dfaut, il faut prvoir des procdures de commandes acclres dquipements avec les fournisseurs (attention au dlai dapprovisionnement). Ces ressources de secours peuvent tre chez un prestataire spcialis (site mutualis). Mise disposition, maintien niveau, priodes de tests, sont alors dfinies par contrat. Si lon dispose de deux sites, une rpartition judicieuse entre ressources de production et autres (dveloppement, intgration, etc..) peut galement satisfaire les besoins de secours, avec des ressources connues, mises jour, mobilisables et surtout non dormantes, ce qui diminue dautant le cot dinfrastructure du secours froid. Dans tous les cas cela suppose de disposer dune cartographie complte et jour des ressources, y compris des ressources dormantes.
5.5 MCO dun PRA chaud

Un PRA chaud fonctionne gnralement avec des machines installes sur le mme rseau que celui de la production. En gnral les deux environnements (production et secours) sont parfaitement symtriques dun point de vue machines et donnes (rplication). En revanche, il faut se poser la question de la continuit des sauvegardes : aprs la reprise en PRA, combien de temps lapplication peut-elle se passer de sauvegarde ? Faut-il reprendre aussi le catalogue des sauvegardes ou redmarrer zro aprs la reprise ? Quel est le niveau de scurit de linfrastructure de sauvegarde/restauration aprs bascule sur lenvironnement de secours ? Pour conserver le niveau de service du PRA, il est ncessaire de synchroniser les poses de versions applicatives entre les deux environnements (dlai de pose infrieur 4 heures). Pour cela il faut sassurer que lors de la rplication des donnes, les environnements soient totalement compatibles (ex. structures de bases de donnes). Il arrive que lon fasse les montes de version dabord sur lenvironnement de PRA, puis quon bascule les utilisateurs nominaux sur les applications de cet environnement afin deffectuer ensuite les mises jour sur lenvironnement de production. Larchitecture doit alors prvoir des mcanismes qui garantissent une perte de donnes nulle.
PAGE 50
Avantage : Le PRA est test rgulirement. Le temps dindisponibilit pour les utilisateurs est faible.
Le MCO dun PRA chaud requiert une gestion des changements plus rigoureuse que celle dun PRA froid. Il faudra sassurer par tests unitaires de la bonne installation des volutions sur le site secondaire. Attention aux carts non tests !
5.6 MCO dun PRA en haute Disponibilit

Plus simple ou moins simple ? Un systme en haute disponibilit facilite la vie des utilisateurs ; et celle des administrateurs ? Le Maintien en Condition Oprationnelle se montre souvent plus sensible dans ce cas que dans les deux prcdents, car il nest jamais conseill davoir des versions de composants (firmware, correctifs, applications, ) diffrentes concourant un service en haute disponibilit ! Selon les architectures ce type de solution serait mme plus sensible aux corruptions de donnes. Si le MCO est facilit pour les poses de versions applicatives, certaines oprations ncessitent toutefois larrt complet du systme (exemple : changement de version de base Oracle, dhyperviseur, et autres composants critiques). Normalement ce processus nimplique aucune interruption pour les mtiers, mais lexprience montre quil est parfois ncessaire de stopper les deux sites pour effectuer la mise jour de certains composants.
NB : Il faut sassurer que les constructeurs offrent des solutions de mise niveau rtrocompatibles.
5.7 Enjeux et gouvernance

Plus on peut prouver que son PRA est jour, plus on peut prouver la frquence et la russite de ses exercices, et plus il est simple de basculer. La crdibilit du process oprationnel du PRA constitue un facteur de qualit recherch par les auditeurs. Pour preuve : une question revient souvent lors dune gestion de crise suite sinistre : quelle est la maturit oprationnelle du PRA que nous allons dclencher ? La rotation infinie (et maitrise) du PDCA (Plan-Do-Check-Act) est bien connu de tous et doit rester un lment de solution ce MCO. Alors quelle organisation pour assurer ce processus ? Acteurs : Le MCO du PRA est de mme nature que le MCO de la production, il devrait donc tre assur par les mmes quipes.
PAGE 51
LiVRE BLANC
Pilotage : Chaque entreprise possde ses propres structures de pilotage mais au travers de notre questionnaire nous observons quelles restent la plupart du temps noyes dans la Production. Le MCO est laffaire de tous ! Cependant le pilotage du Maintien en Condition Oprationnelle du PRA est indispensable. Le pilotage du MCO du PRA est confi au responsable du plan de reprise dactivits. Il coordonne lensemble des acteurs intervenant sur le MCO : exploitants, responsables dapplications, responsable mtiers, gestionnaires de risques. Il contrle le travail de ces acteurs et valide le caractre oprationnel de cette maintenance par des tests et des exercices. Un comit de maintien en condition oprationnelle statue sur les budgets mettre en uvre pour assurer la mise niveau du PRA lors de la prise en compte de nouveaux risques ou lors de modifications des conditions de reprise demandes par les mtiers.
NB : Suite aux exercices, il est souhaitable de qualifier le caractre oprationnel du PRA dun domaine applicatif ou dune application.

Ecueils : Penser que le Maintien en Condition Oprationnelle du PRA sera effectu lors de la priode prparatoire de lexercice, ou pire : durant lexercice. Bonnes pratiques : Le Maintien en Condition Oprationnelle est laffaire de tous. Tout changement en production doit faire lobjet dune analyse dimpact sur le PRA (Voir Process de gestion des Changements et son CAB). Une rorganisation, si minime soit-elle, peut impacter de faon critique le Maintien en Condition Oprationnelle du PRA : penser revoir les process. Avoir une politique antistatique ;-) (pas dadresses IP en dur, des points de reprise dans les jobs, viter dtre dpendant dun seul oprateur sur une quelconque configuration,). Le Maintien en Condition Oprationnelle doit tre contraint par lexistence de points de validation au mme titre que toutes les modifications en production. Ne pas oublier la mise jour des habilitations, des certificats, des licences. Sassurer que les procdures techniques sont bien partages et connues des nouveaux entrants (faire la chasse aux bouts de ficelle ns de lhabitude et qui disparaissent avec le dpart des personnes). Faire un exercice en grandeur relle pour prouver que lactivit mtiers fonctionne sur lenvironnement de PRA.
En conclusion : Tout est interconnect et interdpendant avec le PRA.

PAGE 52

1- Quelle organisation pour le MCO ?

Qui a la responsabilit du MCO du PRA ? DSI : RPRA : Autres : Ne sait pas : 35 % 35 % 17 % 13 %
Quelle est lorganisation des quipes responsables du PRA ? Equipe ddie PRA : Noy la Production : Autres : 48 % 35 % 17 %
Quels outils sont utiliss pour le MCO du PRA ? Intranet Documentaire: Excel/Word : Progiciel : Microsoft Project : 30 % 17 % 17 % 9%
2- Comment le MCO est-il gr ?

Quel est le Primtre du MCO ? Production vitale : Production totale : Autres : 61 % 26 % 13 %
Quel est le dlai de mise jour du site de secours : Immdiat : Dpend du service : Dpend de la disponibilit : 30 % 22 % 9%
Comment est effectu le contrle des mises jour et de la cohrence ? Humain : Logiciel : Humain et logiciel : Autres : 43 % 22 % 13 % 22 %
Y-a-t-il Blocage possible de la mise en production si dfaut de PRA ? Oui : 48 % Non : 26 %
PAGE 53
LiVRE BLANC
CONTRAT DE SERVICE ET PRA

On ne devrait externaliser ou contractualiser que ce que lon maitrise ; sinon, on lapprend rapidement ses dpens Lexprience
6.1 Introduction
Dans quelle mesure la notion de contrat de service sapplique-t-elle aux PRA ? En cas de problme, qui assume quelles responsabilits ? Peut-on aller jusqu un engagement de rsultats ? La rdaction de ce chapitre diffre des prcdents par sa construction : interrogative, multiparagraphes, car la contractualisation reste souvent un exercice difficile. Difficile car sensible: dans sa description, dans les attendus, dans son mode de pilotage, dans lengagement juridique associ. Nous avons donc choisi daborder le sujet sous laxe des Questions/Points de vigilance qui permettra dapprhender plus sereinement le sujet.

Les contrats de service de PRA se concluent soit au sein dune entreprise, entre les diffrentes directions mtiers et la DSI, soit avec une socit de services externe, dans le cadre de loutsourcing/externalisation du PRA. Dans cette situation, plusieurs questions se posent : Quels sont les objectifs et le primtre du PRA ? Que doit-on dlguer un prestataire de services ? Quels engagements doit-on obtenir pour assurer le maintien en condition oprationnelle du PRA ? Quels engagements faut-il contractualiser pour la phase de dclenchement du PRA puis pour le support de linfrastructure de secours durant toute la priode de fonctionnement en mode secours ? Quel regard porter sur loutsourcing du PRA ? Une pratique encore rare, comme le prouvent les rponses notre enqute qui se trouvent en fin de ce chapitre.
6.3 Points prendre en compte en amont de la rdaction du contrat de service

Nos amis juristes interviennent souvent lors de cette difficile rdaction pour nous rappeler quen matire contractuelle, on doit clairement spcifier ce que lon attend ;
PAGE 54
et cest bien l que rside toute la difficult : ne rien oublier. Nous vous proposons quelques axes de rflexions avant rdaction.
Une ncessit : adapter le niveau de service (et donc le cot) du PRA aux enjeux mtiers rels (cf. BIA). On nexternalise que ce quon matrise, cela vaut aussi pour le PRA. Un PRA implique la reprise dun ensemble de services un niveau dtermin pour les activits vitales de lentreprise. Peut-on obtenir un engagement de rsultats qualifi ? Lexprience montre que la chose est rare, mais pas inexistante, et que la question doit-tre pose. Dans tous les cas, il faut dfinir prcisment ce qui tient aux engagements de moyens et aux engagements de rsultats. Attention, ces engagements sont prciser aussi bien lors dune ngociation en interne entre lquipe IT et les mtiers, que dans le cas dune ngociation avec un prestataire externe. Une bonne pratique universelle : ngocier des pnalits en cas de non-respect des engagements lis aux diffrentes composantes du PRA. Il faut formaliser des processus dalerte et de gestion de crise, que le PRA fonctionne en interne ou en externe en y incluant le prestataire.
6.3.b Zoom sur lexternalisation du PRA

A priori, quasiment tous les lments techniques du PRA sont ligibles lexternalisation : lhbergement, les infrastructures, les serveurs de secours, les procdures, les oprations de reprise dactivits, le maintien oprationnel du site de secours. A contrario, tous les aspects dcisionnels (organisation de crise) doivent tre conservs en interne. Il faut se poser la question du cot de revient dun PRA Interne et dun PRA externalis. Les modalits de mutualisation des moyens partags chez le prestataire de services sont-elles bien dfinies et contractualises ? (par exemple taux de mutualisation, rgles de priorit des workloads en cas de sinistre, etc.) Il faut maintenant compter sur une nouvelle offre, considrer pour des besoins peu levs : les cloud recovery services ou PRA dans le Cloud.
6.3.c Primtre de lexternalisation du PRA

Lexternalisation dune solution de haute-disponibilit impliquant un dual-site de production nest possible que dans le cadre de loutsourcing du pilotage total de la production. Sans quoi le partage des responsabilits et le maintien en condition oprationnelle peut rapidement devenir inextricable. En effet, une solution hautedisponibilit fonctionne souvent comme un systme unique rparti sur deux sites, on ne dlgue pas plus la gestion de la moiti dune telle architecture quon ne dlguerait celle dun demi-serveur
PAGE 55
6.3.a Cas gnral, que le contrat soit interne ou externe
LiVRE BLANC
Lexternalisation du secours chaud ou froid est envisageable en ce qui concerne le maintien en condition oprationnelle et la reprise dactivits. Le pilotage de la production sur le site de secours, suite accident ou sinistre, ne peut pas tre dlgu et doit rester de la responsabilit de lentreprise. Le client idal pour un PRA externalis ? Les SI les moins exigeants, ceux qui ne disposent pas de moyens prexistants, voire ceux qui nont pas encore mis en place de PRA. Il existe un certain nombre davantages dans cette situation : - Le prestaire apporte lexpertise technique. - La souplesse du dimensionnement, qui relve de la responsabilit du prestataire. - Labsence de gestion des infrastructures pour lentreprise. - Un aiguillon externe pour avancer : en effet, externaliser un PRA constitue un bon moyen de se forcer avancer en interne sur la dfinition de celui-ci si la chose na pas encore t faite.
6.4 La caractrisation des niveaux de service

De nombreuses directions (informatiques ou gnrales) se sont lances dans une dmarche de contractualisation interne et/ou externe des services. Ceci prend la forme de SLA (Service Level Agreement) et dOLA (Operationnal Level Agreement), bass sur des notions de KPI (Key Performance Indicator). Ces dmarches doivent inclure dsormais un chapitre sur les PRA. Dans ce cas, les critres de dclenchement du PRA sont associs des notions de niveaux de service (complmentairement au BIA) couverts sous des descriptifs du type Or/Argent/ Bronze ou autres. Contenu dun contrat SLA voire OLA : Le plus souvent, il dpend de lorganisation de lactivit de lentreprise. Quil sagisse dun contrat interne ou externe de PRA, celui-ci doit prendre en compte les particularits de fonctionnement des processus mtiers de lentreprise : les exigences diffrent totalement si elle fonctionne 7 jours sur 7 et 24 heures sur 24 ou 5 jours par semaine, de 8 h 18 h. Trois blocs caractrisent ltablissement dun tel contrat : 1. les modalits de gestion du maintien en condition oprationnelle du PRA, 2. les modalits de gestion et de conduite des tests, 3. les modalits de gestion du service en cas daccident ou de sinistre.
6.4.a La contractualisation des niveaux de service du MCO du PRA

Elle prcise lensemble des points suivants : La surveillance des serveurs et applications du PRA, par exemple quelle frquence sont-elles surveilles ? Les conditions de mise niveau des infrastructures et des applicatifs sur le site de secours pour prserver la cohrence avec le site principal (par exemple les mises jour sur le site PRA ne devront pas intervenir plus de quatre heures aprs celles appliques sur le site principal). Les modalits de contrle limplmentation de ces mises niveau.
PAGE 56
Les mesures prendre en cas dcart constat entre site principal et site de secours. La gestion dincidents, accompagne ventuellement de pnalits, et la remonte dincidents survenus sur le site de secours. Les habilitations et astreintes des personnels impliqus dans le PRA et leur gestion dans le temps. Les responsables de la tenue jour des procdures oprationnelles (exploitant, SI, mtiers, permanence managriale). La dfinition des arrts programms pour maintenance du site de secours. La gestion des drogations de disponibilit du PRA, par exemple sous la forme dun dlai de consignation (dure prvue dune intervention de maintenance sur le site de secours qui le rend indisponible) associ un dlai de restitution (en cas durgence, en combien de temps le site de secours peut-il tre restaur dans un tat utilisable dans le cadre du PRA, par exemple en revenant un tat antrieur lopration de maintenance). Dans tous les cas, linterruption de disponibilit du site de secours ne pourra pas excder son dlai de mise disposition tel que dfini contractuellement. En rsum, il peut exister des oprations de maintenance de longue dure sur le site de secours, qui se traduisent par son indisponibilit, du moment quil est possible de remettre rapidement ce site en service en cas durgence.
6.4.b La contractualisation des niveaux de services applicables aux oprations de tests du PRA
Elle devra prciser les points suivants : Nature et frquence des exercices de PRA, pnalits applicables en cas de nonrespect de ce calendrier. Les exercices de PRA programms se feront sans perte de donnes (exercices rels). En cas dexercice de PRA inopin, une perte de donnes infrieure x mn sera tolrable. Dfinition de la prparation de lexercice de PRA (revues des procdures, valuation des risques et actions visant les rduire, organisation des ressources,...) La ralisation et vrification de la bascule aller puis retour vers le site de secours selon la procdure adapte au contexte.
6.4.c La contractualisation des niveaux de services en cas de dclenchement du PRA

Plages de dclenchement. En concordance avec les horaires dactivit de lentreprise, par exemple : le PRA du site peut tre dclench 24h/24 et 7j/7, mais aussi seulement les jours ouvrs, etc. Le dlai de restitution du service est infrieur x heures. Ce point doit aussi prendre en compte les plages ouvres de lentreprise : si le sinistre a lieu un lundi matin, le redmarrage devra intervenir laprs-midi. Si le sinistre a lieu en fin de journe, le redmarrage pourra intervenir dans la matine suivante.
PAGE 57
LiVRE BLANC
Dlai de restitution des donnes et de reprise des flux perdus durant le sinistre (attention, certaines formes de rcupration sont de type SI et concernent des donnes brutes, dautres sont de type mtiers et demandent une rorganisation des donnes au sein des applications.) Les indicateurs de performances des processus en mode PRA doivent tre les mmes quen production normale aprs la priode de bascule de 4 h. Prciser la fourniture des services associs au fonctionnement en mode secours avec laccompagnement de proximit des acteurs participants. La remise en conformit du site de repli aprs exercice. Conditions du retour une situation normale (par exemple effacement scuris des donnes sensibles sur le site de secours). La ralisation du bilan des oprations et la dfinition, avec lensemble des acteurs, dun plan dactions correctives ou damlioration. Le dlai maximum de fonctionnement en mode PRA et les conditions de sortie chance. Lexternalisation ventuelle des sauvegardes sur le site de secours, voire la gestion des oprations de production sur ce site, si elles sont prises en charge par lquipe du prestataire externe.
6.5 Pilotage du contrat de service

Le contrat tant sign, reste piloter la relation client/fournisseur sur la base dun certain nombre daxes : Comment piloter les volutions contractuelles : juridiques, tiers, Quels indicateurs pouvez/devez-vous dfinir pour suivre le caractre oprationnel de linfrastructure ? Avez-vous dfini des indicateurs de suivi de la prestation ? Quelles sont les modalits juridiques intgres dans le contrat ? Avez-vous dfini des pnalits contractuelles en cas de non-conformit de la prestation ? Quid de clauses sur la rupture du contrat (dlais de rupture, modalits de passation vers un autre prestataire, transmission dinformations) ? Comble de malchance : vous venez de basculer en rel sur un site de PRA externalis, qui lui aussi subit un incident (malheureuse exprience effectivement vcue par un membre du CRiP) : existe-il des clauses contractuelles en cas de sinistre sur le site de secours ? Comment cela est-il gr ?

Bonnes pratiques : Il faut adapter le niveau de service (et donc le cot) du contrat de service PRA aux enjeux mtiers (cf. BIA) On nexternalise que ce que lon maitrise. Ecueils viter : Ne pas prvoir le secours du site de secours
PAGE 58

La contractualisation du PRA (interne ou externe) est devenue un standard 90% des rpondants ont formalis les engagements associs, en allant parfois jusqu un engagement de rsultat (10% des cas) Toutefois, seuls 30% ont dfini des pnalits en cas de non-respect de ces engagements Les tests du PRA constituent le principal indicateur de performance du PRA Dans 90% des cas, le dlai de reprise lors du test est le principal (voire unique) indicateur Test annuel systmatique, mais 30% font plus dun test par an (jusqu 4 !) 40% des tests proches dune situation relle / 35% des tests limits une bascule unitaire Indicateurs avancs dfinis dans seulement 20% des cas (ex : taux de succs des sauvegardes PRA en interne, taux de mutualisation des moyens en externe) Lexternalisation du PRA : une pratique encore peu dveloppe... 10% des rpondants seulement sappuient sur un prestataire de secours, la plupart sappuyant plutt sur leur infogrant actuel (PRA = extension de la production) malgr des apports varis et des freins assez limits Objectifs : solution complmentaire (45% des cas), rduction des cots (30%), apport dexpertise technique (15%), etc. Freins : cot, scurit des donnes, etc.
PAGE 59
LiVRE BLANC
LE VOCABULAIRE PRA DANS CE LIVRE BLANC

Ce qui se conoit bien, snonce clairement et les mots pour le dire arrivent aisment Boileau
Technologie permettant un serveur connect sur une baie SAN dinitialiser son systme dexploitation distance. Cette fonctionnalit permet, dans le cadre dun dual-site disposant dune rplication synchrone ou asynchrone des baies, de pouvoir redmarrer un serveur secondaire distant sur limage parfaite du serveur primaire (accs non concurrent). Cette solution rentre dans les PRA chaud. Attention cette solution reste fragile car en cas de corruption de donnes sur les disques primaires, le site de secours devient automatiquement inoprant.
> Boot on SAN
> Clustering / Cluster = Grappe

Solution dagrgation de serveurs (en grappe) permettant de mutualiser/rpartir la fourniture dun service sur des nuds indpendant. Cette technique permet daugmenter la disponibilit, et dassurer la monte en charge. Il existe des solutions de cluster matriels, logiciels (ex : Veritas Cluster Server) ou applicatif (ex : Oracle RAC)
> Cellule de Crise Dcisionnelle (CCD) Cellule de Crise Oprationnelle (CCO)

Source : AFNOR Elle est compose des responsables de chaque Direction utilisatrice concerne par le PCA. Elle comprend galement des membres de la Direction Gnrale, de la Direction des Services Gnraux, de la Direction des Ressources Humaines, de la Direction de la Communication, de la Direction Informatique et des responsables PCA. Son rle est de se runir en cas dincident grave pour dcider de dclencher ou non le PCA. Ses membres doivent tre assujettis des astreintes (service de garde) ou au moins tre disponibles tout moment et en tout lieu. Commentaires CCA : Il ny a pas lieu de distinguer comit et cellule de crise, si ce nest que le comit serait une runion ventuellement largie des membres de la cellule de crise. Par contre, selon la taille de lentreprise concerne, on peut distinguer cellule de crise dcisionnelle (CCD) et cellule de crise oprationnelle (CCO) pour lactivation des PCA et la mise en uvre des initiatives dcides par la CCD. Dans ce schma-l, la CCD peut prendre des dcisions stratgiques (ex : communiquer ou pas) et tactiques (choix de la modalit de mise en uvre).
> Cellule Technique Oprationnelle (CTO)

Elle est appele pour valuer la gravit de la situation suite la survenance dun incident qualifi de grave. Le rsultat de son analyse dcidera de la convocation de la CCD.
PAGE 60
> Dlai Maximal dInterruption Admissible (DMIA)

Source : Livre blanc lexique structur de la continuit dactivit Dlai Maximal dInterruption Admissible des activits aprs lequel lentreprise sexpose des pertes financires, dimage, une dsorganisation et des manquements contractuels. Dlai aprs lequel les systmes, applications, ou les activits doivent tre rtablis aprs une interruption (ex : 2 heures ; un jour ouvrable).
> Domaine applicatif / Groupe dapplication

Il sagit dun ensemble dapplications troitement lies entre elles, du fait des flux quelles changent et de leurs interactions. Suite sinistre, elles doivent reprendre leurs traitements de faon synchronise pour fournir les services attendus par les mtiers. Un exemple : le traitement de la paye et le paiement des salaires, qui sont usuellement deux applications spares pour viter les fraudes.
> Dual site

Le dual site regroupe deux sites de production se secourant rciproquement en cas de sinistre. Il est possible de rpartir sa production sur les deux sites. Ils fonctionnent souvent en haute disponibilit.
> Plan de continuit Informatique (PCI)

Partie strictement informatique du PRA.
> Plan de Continuit dActivits (PCA)

Source : Livre blanc lexique structur de la continuit dactivit Dfinit et identifie lensemble des moyens (organisation, procdures et matriels) requis pour se tenir prt faire face un sinistre ou une avarie majeure. Ces moyens doivent permettre dassurer la continuit de service et le retour en mode normal dans les meilleurs dlais possibles. Le Plan de Continuit peut tre conu diffrents niveaux. Par exemple, au niveau dune filiale ou dun mtier ou rpondant un scnario particulier (ex : pandmie grippale, incendie de locaux, etc.) : on parle alors de diffrents PCA. Lensemble de ces Plans de Continuit constitue le Plan de Continuit dEntreprise (PCE).
> Plan de Continuit Service (PCS)

Le Plan de Continuit de Service exprime les obligations rciproques des parties signataires, dcrit lorganisation et les dfinit pour remplir les engagements de la DIT de continuit de service.
> PCM : PCA Mtiers : Plan de Continuit Mtiers

Une sous-partie du PCA qui organise la continuit dactivits des mtiers en relation avec lensemble du PCA dont la partie informatique. Il dcrit un ensemble de procdures de fonctionnement mtiers, par exemple en mode dgrad. Il dcrit les contrles fonctionnels que doivent effectuer les mtiers la reprise dactivits.
PAGE 61
LiVRE BLANC
> PCE : Plan de Continuit dEntreprise

Le plan de continuit dentreprise PCE est compos : - de mesures de prvention, pour diminuer la probabilit doccurrence dune dfaillance, - de mesures de dtection et de raction, en ayant de bon rflexe, - de plans de secours, pour diminuer les consquences du sinistre Un plan de secours se dcompose en diffrents plans : - un plan de gestion et de communication de crise, - un PRA (plan de reprise dactivits) des moyens techniques (informatique, rseaux, autocom, tlphonie), pouvant ncessiter un site de secours, des plans de reconstruction de linfrastructure, ... - un PCA (plan de continuit dactivits) par mtiers de lentreprise, pouvant ncessiter un site de repli hbergeant les collaborateurs critiques des activits prioritaires, - un plan de fonctionnement en secours, - un plan de retour une situation normale.
Lquivalent traduit en vision Anglo-Saxonne : BCM= BIA + MCBS/RP + BCP Business Continuity Management = Business Impact Analysis and Risk Analysis + identification of Mission Critical Business Services that must be recovered in an event of a failure and Remediation Plan +Business Continuity Plan
BCP= EM+CM+CP+DRP+BRP Business Continuity Plan = Emergency Management + Crisis Management + Contingency Plans + Disaster Recovery Plans + Business Resumption Plans
> Perte de Donne Maximale Tolrable PDMT / PMDT / PDMA

Source : AFNOR (Perte de Donnes Maximale Admissible - PDMA) Pour une application quelle est la perte acceptable au niveau des donnes (lie aux sauvegardes) pour que celle-ci soit dun niveau acceptable pour les services utilisateurs. Selon les besoins exprims, le degr de fracheur des donnes correspond la perte des donnes considres comme acceptable entre larrt de lactivit et sa reprise. Par exemple, au dmarrage aprs sinistre, les donnes peuvent dater de la veille au soir, du matin ou de la minute du sinistre.
> Plan de Reprise dActivits PRA

Le PRA est un des plans constitutifs du PCA qui couvre le secours des moyens informatiques et tlcoms, lensemble des procdures et des dispositions prvues pour garantir lentreprise la reprise des applications et des donnes critiques suite un sinistre informatique. Il garantit la reprise des systmes dsigns comme critiques dans le temps minimum fix par le RPO.
> Rplication asynchrone

Modle de rplication dans lequel la synchronisation permanente des donnes nest pas exige. La rplication distance est ralise sans attendre laccus de rception sur le site metteur. Il ny a pas de contrainte de distance entre le site metteur et le site rcepteur, puisquil n y a pas dimpact sur le site metteur.
PAGE 62
> Rplication synchrone

Modle de rplication dans lequel les donnes sont en permanence strictement identiques sur les diffrents sites. La rplication distance est ralise lorsque laccus de rception dcriture sur le site distant est revenu sur lmetteur. Les limites de la physique font quil nest pas possible de raliser de rplication synchrone sur une distance suprieure 70 km, surtout en raison des consquences sur la dure des gros traitements batch. Attention, au niveau de rplication en mode synchrone : donne, transaction.
> Rsilience
Source : AFNOR Capacit dune organisation rsister un incident, un accident, une crise dans des environnements adverses, puis revenir un tat normal. Source : Joint Forum 2006 La capacit dun acteur de lindustrie financire, dune autorit financire ou dun systme financier absorber limpact dune perturbation oprationnelle majeure et poursuivre les oprations ou les services critiques. Commentaire CCA : Une nuance peut tre apporte en franais entre : Rsilience : qualit de celui qui se rtablit vite Robustesse : qualit de ce qui reoit des coups sans trop en souffrir En anglais Robustness nest pas employ. Un bon PCA concoure la robustesse ; un bon PRA la rsilience.
> Retour une situation normale

Source : AFNOR Capacit dune entreprise, aprs un choc extrme, accepter et traiter de nouvelles oprations, un rythme au moins gal celui qui prcde la catastrophe. Commentaires CCA : Lorsquil sagit de retrouver une production ou un rythme pour les exploitations dfinis de manire contractuelle, on peut parler dun retour une situation nominale. Dune manire gnrale, le fait davoir vcu une crise apporte des renseignements permettant damliorer la situation antrieure. Il est prfrable de parler dun retour une situation normale plutt que dun retour la normale. Le retour la production nominale est un objectif de court terme et la prise en compte des enseignements de la crise (faiblesses, vulnrabilits quelle a rvles) est un objectif de moyen ou long terme.
> RTO : Recovery Time Objective

Le RTO dfinit le dlai de reprise informatique partir duquel les services sont restaurs. Il sagit de la traduction informatique de lexpression du besoin mtiers. Par exemple : quatre heures, une journe. Attention bien dterminer le point de dpart du chronomtre : dcision de la CCD ou moment de survenance du sinistre.
PAGE 63
LiVRE BLANC
> RPO : Recovery Point Objective

Le RPO dfinit le point temporel stable antrieur au sinistre partir duquel la reprise dactivits a lieu. Il sagit de la traduction informatique de lexpression du besoin mtiers. Par exemple : date de la dernire sauvegarde cohrente. Date de la dernire transaction synchrone valide.
> Sauvegarde de production / de recours / darchivage

> Sauvegarde de production Les sauvegardes dexploitation sont effectues pour assurer des restaurations suite des problmes dexploitation : travaux refaire, crash du serveur. Elles nont pas besoin dtre mises hors du site de production. Elles doivent tre au contraire faciles daccs pour rparer des incidents de production. Le nombre de versions et leur priode de rtention sont dfinis par la MOA. > Sauvegarde de recours suite un sinistre informatique Les sauvegardes de recours sont effectues pour assurer : la reprise dactivits sur le site de secours le fonctionnement en production sur le site de secours pendant plusieurs mois si ncessaire Elles doivent tre : effectues un point dancrage des restaurations mises hors du site de production, le plus tt possible aprs leur cration oprationnelles quoi quil arrive exhaustive (donnes, logiciels, documentation) contrles > Sauvegarde darchivage Les sauvegardes darchivage sont effectues pour rpondre des demandes ponctuelles dinformation en gnral pour des besoins rglementaires.
> Sauvegarde des transactions

Enregistrement systmatique de toutes les mises jour ralise sur une base de donnes (logging) ou dispositif quivalent (attention, cette notion volue avec la gnralisation des ESB). En cas de besoin, on peut rappliquer les mises jour sur une base de donnes restaure dans un tat antrieur.
> Sinistre rgional

Sinistre majeur couvrant une importante zone gographique (sisme, tempte, inondation centennale). Ces sinistres de par leur ampleur induisent des impacts sur la vie humaine, les moyens de communication, Les solutions de secours de type campus ou de proximit ne protgent pas contre un sinistre rgional.
PAGE 64
Conclusion
Au bout de la patience, il y a le ciel Proverbe africain
Laventure rdactionnelle de ce livre touche sa fin et nous souhaiterions rappeler que ce document constitue une approche technique, qui naurait de sens sans lexistence, les attentes, les exigences, de continuit des mtiers. Pensez leur transmettre ce document. Il sera intressant denvisager dans un prochain livre blanc daborder la notion de Plan de Continuit dActivits (PCA) charge des mtiers. Car cest ce couple Mtiers/DSI qui doit converger vers une approche commune dans lcriture de La Solution raisonnable et acceptable en matire de risques et de cots pour lentreprise. Et ce sans oublier que le PRA, si complet soit-il, ne peut jamais couvrir tous les risques. Et ce sans oublier non plus que si puissants soient les moyens techniques actuels, la reprise dactivits ne pourra jamais tre absolument garantie. Il est indispensable dy sensibiliser la direction gnrale. Il ne faut pas oublier quun systme dinformation est un cosystme en perptuelle volution, et que le PRA doit en tre le reflet. Alors quelque soit la cause du sinistre, il y aura en situation de crise des ajustements apporter pour lesquels seul lentrainement et lagilit des hommes de lart pourront rpondre. Gardons lesprit, quen marge de tout cela, Monsieur PRA doit rester un homme de bon sens, qui revient toujours aux fondamentaux : quelle est la priorit ? Quel est le cur de mtier, Je citerai en exemple ce PCA o en cas de sinistre de lentreprise, lactivit principale est assure par un comptable avec un carnet de chque. Faites simple mais pas simpliste. Pour finir, aprs lavnement du web 2.0, larriv dans nos entreprises des collaborateurs 2.0 (gnration Y), lmergence de linterconnexion par le cloud, on assiste maintenant la venue du Telco 2.0, phnomne de convergence des rseaux et des services. Alors dans cette mouvance internationale, le PRA 2.0 mergera t-il ?
PAGE 65
LiVRE BLANC
Annexes
Liens
Livre Rouge sur la continuit dactivit : Livre FFIEC sur le BCP
http://www.redbooks.ibm.com/redbooks/pdfs/sg246547.pdf http://www.ffiec.gov/ffiecinfobase/booklets/bcp/bus_continuity_plan.pdf
Ouvrages
Livre blanc du Club de la Continuit dActivit : Lexique structur de la Continuit dActivit
http://www.clubpca.eu
Guide des bonnes pratiques de la Continuit dActivit lattention des Directions des Ressources Humaines
http://www.clubpca.eu
Articles Complmentaires
ITIL et la continuit dActivit
Source internet : http://www.newsitweb.info/nov06/itil_nov06.html
Lobjectif principal du processus de gestion de la continuit des services est de remettre en conditions oprationnelles les infrastructures informatiques pour supporter les fonctions mtiers de lentreprise en cas de destruction partielle ou totale des quipements. Il ne sagit pas forcment de tout reprendre (dailleurs ITIL propose une option de reprise qui peut paratre singulire mais qui pourtant est de toute premire importance: ne rien faire). En effet, le plan de reprise intgre la notion de fonction mtier vitale pour concentrer les efforts sur les fonctions les plus critiques et ignorer sil le faut, dautres fonctions annexes.
Les tapes du processus

Quatre tapes structurent le processus de gestion de la continuit des services. Elles permettent de dvelopper puis de dployer les mthodes et les moyens qui permettront de garantir laccs linformation, en respectant les contraintes dalignement et lquilibre entre investissements et risques couvrir. Lancement : ds la prise de conscience au sein de la DSI et de lentreprise, ITIL recommande de cadrer linitiative en dfinissant le primtre de couverture, les ressources et les organisations impliques.
PAGE 66
Implmentation : partir de la stratgie de continuit dcide, lorganisation projet est mise en place pour dfinir le planning dimplmentation et laborer les techniques de reprise pour lensemble des solutions couvertes par le plan. Les activits de cette tape sont: mise en place de lorganisation, planning dimplmentation, dveloppement des dispositifs de secours, dploiement des mesures de rduction des risques, dveloppement des procdures de reprise et tests de reprise. Gestion oprationnelle : en mode production, le processus veille la sensibilisation des ressources et la formation des experts identifis. Le processus de gestion des changements sassure que toute modification pouvant impacter la reprise est analyse et intgre aux solutions de secours. Les activits de cette tape sont: ducation et sensibilisation, audits, plans de tests, gestion des changements et formations.
Les options de reprise

Six options de reprise sont proposes par le rfrentiel ITIL. Elles permettent dadapter la stratgie de reprise aux contraintes et aux exigences des directions mtiers. Ne rien faire : cas des solutions dont lentreprise peut se dispenser en cas de sinistre majeur. Solution de contournement manuelle : la direction mtier dispose dun dispositif ou dune mthode qui lui permet de continuer son activit sans loutil informatique. Partenariat rciproque : solution de partenariat entre deux organisations de lentreprise ou entre deux socits sur un dispositif de secours mutuel. Reprise progressive : aussi appele cold stand by, cette option propose une reprise sous 72 heures. Elle concerne les applications non critiques. Linfrastructure de secours est construite sur demande en cas de sinistre. Reprise intermdiaire : aussi appele warm stand by, et ddie aux fonctions critiques, cette option se positionne sur une reprise comprise entre 24 et 72 heures. La solution de secours, de type mutualise, est affecte lentreprise au moment du sinistre. Reprise immdiate : pour les fonctions vitales, il est parfois ncessaire de garantir une reprise sous des dlais trs courts. Ce qui suppose la mise disposition dun environnement de secours ddi. Cette option est parfois appele hot stand by car les donnes y sont gnralement dj prsentes au moment du dclenchement du plan de reprise. Toutes ces options peuvent bien videmment cohabiter pour offrir un plan de reprise adapt chaque exigence mtier. La communication, la disponibilit et les mises jour des procdures de reprise sont capitales pour obtenir de cet investissement le retour escompt.
PAGE 67
Exigences et stratgie : cest le travail danalyse (impact et risques) qui doit amener lquipe projet dfinir les stratgies de reprise. Les objectifs du processus y sont dfinis en accord avec les exigences des directions mtiers. Trois fonctions composent cette tape: analyse dimpact, analyse des risques, stratgie de continuit.
LiVRE BLANC
Les avantages du processus

Au del du fait que la DSI et lentreprise nont pas forcment dalternative la mise en uvre dun plan de reprise, ce processus apporte la garantie que les fonctions vitales de lentreprise continueront pouvoir fonctionner mme en cas de sinistre majeur. Dans sa dmarche de gouvernance et dalignement, le DSI dispose dun processus cl pour llaboration de sa stratgie. Pour les directions utilisatrices : le processus de gestion de la continuit des services prend en compte, ds la deuxime tape de son cycle, limpact dun arrt prolong du service. Il sagit ensuite de dvelopper des solutions adaptes chaque profil en fonction du risque, de limpact et de lexigence. La direction mtier dispose donc dun service align ses besoins en matire de continuit, et sur lequel la DSI sengage sur les rsultats. Pour la DSI : le rfrentiel ITIL apporte les bonnes pratiques ncessaires un dispositif auquel la DSI ne peut plus chapper. Les pressions concurrentielles sur lentreprise entrainent obligatoirement lexigence de continuit. La DSI peut ici capitaliser sur des pratiques largement utilises dans de nombreuses entreprises en adaptant le rfrentiel ses propres
PAGE 68
A propos du
Le Club de la Continuit dActivit
Association rgie par la loi de 1901, dote dun Bureau et dun Conseil dAdministration Cre en 2007, pour changer sur la Gestion de la Continuit dActivit (GCA) Runit des entreprises et des administrations de toutes tailles, de tous secteurs, de tous pays (une centaine dadhrents) Ouverte tous praticiens concerns : Responsable de la Continuit dActivit (entreprise, administration), Directeur des risques, Professeur, Etudiant (maitrise) Son objet est de runir tous les praticiens uvrant dans le domaine de la Gestion de la Continuit dActivit afin de : Partager leurs visions : retour dexprience, bonnes pratiques Parfaire leurs matrises : solutions, rglementation, normes Prenniser leurs actions : intgration de la Gestion de la Continuit dActivit dans la stratgie de lentreprise Notre mode de fonctionnement A linitiative dun adhrent voulant approfondir et confronter son exprience, une runion dchanges et de retour dexprience est organise (matinale de la continuit). A lissue de cette runion, un document tat de lart est produit et un groupe de travail peut tre constitu pour approfondir le sujet. Ce groupe produira un livre blanc et les rsultats seront prsents lors dune matinales de la continuit.
> Les matinales du CCA

2 octobre 2008 : Validation probante du PRA 11 dcembre 2008 : Site de repli interne ou externe 16 septembre 2008 : Retour dexprience sur la pandmie grippale 11 dcembre 2008 : la crise conomique et la continuit 28 avril 2009 : le cloud computing et la continuit dactivit 1er dcembre 2009 : Quelles responsabilits au sein dune organisation en matire de gestion de la continuit dactivit? 19 janvier 2010 : La normalisation des PCA 23 mars 2010 : Ralisation dun exercice de gestion de crise en direct 1er juin 2010 : Certification PCA : Comment faire certifier son dispositif de gestion de la continuit dactivit et par qui? 12 octobre 2010 : la supply chain et la continuit dactivit 9 dcembre 2010 : le retour dexprience de trois sinistres rels 10 fvrier 2011 : la prsentation du livre blanc PRA, rsultat du groupe de travail PRA 22 mars 2011 : le manuel de la continuit dactivit destin au DRH issu du groupe de travail PCA et RH Date non planifie : Exercice de gestion de crise
Tous les secteurs dactivits sont concerns

Le mtier de Responsable PCA s'est progressivement cr, d'abord au sein des entreprises bancaires et financires; contraintes par des obligations rglementaires, et s'largit aujourd'hui vers les autres secteurs d'activit. Des acteurs provenant de divers horizons (Assurances & Banques, Tlcommunications, Services, Conseils, Industrie) se sont allis afin de fonder en Octobre 2006 le CCA. Aujourdhui le CCA compte plus de 50 socits adhrentes reprsentant 90 membres actifs.
Membres du bureau du CCA (2010 2011)

Olivier CREHANGE, Prsident - BPCE olivier.crehange@bpce.fr Franois TTE, Prsident dhonneur - Devoteam francois.tete@devoteam.f Pierre Dominique LANSARD, Vice Prsident - France Tlcom pierredominique1.lansard@orange-ftgroupe.com PAGE 69 Herv MOLINA, Trsorier - Groupe La Poste herve.molina@laposte.fr
11 Groupes de travail
Concepts & vocabulaires de la Gestion de la Continuit dActivit - Elaboration dun lexique structur de tous les concepts en regroupant tous les vocabulaires employs aux USA, UK et France. Proposition de dfinition et commentaire du CCA Contact : Franois TTE - franois.tete@devoteam.com Pandmie grippale > gestion des grands risques - Elargir aux grands risques. Le groupe convient quil serait judicieux de poursuivre les rflexions sur le thme des grands risques, ceux sur lesquels leffort de comprhension des phnomnes et des enjeux ncessite une rponse globale, la fois dans lentreprise mais galement au niveau du pays. Contact : Pierre Dominique LANSARD pierre-dominique1.lansard@orange-ftgroup.com Juridique - Regroupement des textes juridiques concernant la continuit dactivit PCA et RH - Elaboration dun guide de bonnes pratiques de la Continuit dActivit lattention des RH. Contact : Guy PLAGNARD - guy.plagnard@cnp.fr PRA - Elaboration du prsent livre blanc PRA Contact : Franois TTE - franois.tete@devoteam.com PCA - Elaboration dun livre blanc PCA Contact : Patrick MORRISSEY - pmorrissey@auditware.fr Pr normalisation - Etude des normes existantes ; Proposition dune liste de critres pour valuer un PCA Contact : Pierre Dominique LANSARD pierre-dominique1.lansard@orange-ftgroup.com. Risque pnal et juridique en Continuit dActivit -La vocation du groupe de travail est dapprhender la responsabilit de lentit qui met en uvre le plan de continuit, de sa dfaillance, voire de son absence. Contact : Jean-Michel Icard jmicard@gmail.com Accompagnement de crise du leader (en cration) - sa solitude dans laction urgente - le recours des mthodes de crise - ladaptation du pilotage de lactivit dans lurgence - lidentification des dcisions rdhibitoires (sans retour possible en arrire) - la communication au service de la continuit dactivit - les conflits dintrt entre les stakeholders - tout moyen aidant le dcideur maintenir la continuit de lactivit de son organisation pendant laction. Contact : Hubert DUNANT hubert.dunant@emat.terre.defense.gouv.fr La continuit dactivit et la supply chain (en cration) - Partager nos visions et dmarches sur les briques fondamentales de la continuit dactivit des flux et des activits logistiques - Alerter sur des exigences croissantes sur le management des risques de la supply chain Le ROI (Return Of Investment) dun PCA (en cration) La performance, les rsultats attendus qui peuvent facilement tre chiffrs, intressent directement les responsables dentreprise ; les dispositifs de matrise des risques qui leur sont proposs ont un cot immdiat, et intrt plus difficilement chiffrable. Quelle approche peut-on avoir pour tudier simultanment les potentialits ngatives et positives dun projet ou dune activit future ?
Valoriser sa fonction
Sbastien GAVALDA Responsable PCA - Groupe Crdit Coopratif
> Adhrez au CCA

Ladhsion au CCA est ouverte tous les praticiens de la Continuit dActivit : RPCA, RSSI, DSI, Direction des Risques, Direction de la Conformit, Direction de la Production, et tous les responsables ayant des missions lies la Continuit dActivit.
Ce qui ne cote rien na pas de valeur
Nicolas COUPE Responsable PCA - MAIF
Echange dans un cercle de confiance
Eric DOYEN RSSI - Crdit Immobilier de France
Pour toute information, nhsitez pas :

Visiter notre site Internet : www.clubpca.eu Nous adresser un mail : contact@clubpca.eu Nous envoyer un courrier : 73 rue Anatole France, 92300 Levallois Perret
tre plus performant dans son mtier
Olivier CREHANGE Responsable PCA - BPCE
Apport de la richesse dexprience dautres entreprises en participant des groupes de travail

PAGE 70
Guy PLAGNARD Responsable PCE - CNP Assurances
A propos du
Investir dans la production
Le Club des Responsables dInfrastructure et de Production

Les responsables dinfrastructure et de production viennent dabord au CRiP pour y travailler ensemble laborer les contenus qui les aideront devenir plus performants dans leur mtier. Ils y viennent aussi pour se rencontrer et pour se frquenter, mais notre club a avant tout pour vocation de crer des outils de travail et dexpertise. Le noyau dur de nos activits se renforce, mais reste le mme : des confrences thmatiques plus frquentes, une production ditoriale renforce, des groupes de travail plus nombreux. Le tout en conservant lgard des fournisseurs une stricte indpendance, condition imprative pour que nos changes se droulent avec le degr de confiance ncessaire entre nous. Cette faon de procder nous garantit que chacun dentre nous apportera au CRiP sans rserves lexpression de son savoir-faire tout autant que celle des questions quil se pose. Tant mieux. Nous sommes une communaut de travail, et ces questions refltent la vraie vie de lentreprise, celle qui nous intresse.
Thmatiques
Le credo du CRiP : Indpendance par rapport aux fournisseurs et socits de consulting

Partager nos expriences
Philippe SERSOT Prsident du CRiP CTO CA-CIB
Jai trouv trs intressante linitiative du CRiP de runir des Responsables de production en charge dinformatiques clientes varies dans un cercle o ninterviennent pas les fournisseurs. Cela permet de confronter ses propres ides aux retours dexpriences dautres socits plus avances sur certains sujets. Une dmarche dautant plus indispensable que nous nous trouvons, dans le mtier de la production informatique, particulirement exposs des situations de grands changements, tels que la virtualisation dans ses multiples dimensions ou le cloud computing. Japprcie particulirement ce souci dapporter, partager et recevoir tout en mme temps ces indispensables retours dexprience.
Jean-Paul AMOROS GDF SUEZ CTO/Directeur de la Production Informatique, membre du Bureau Excutif du CRiP
Le Bureau excutif
Prsident : Philippe SERSOT CA-CIB - CTO Vice-prsidents : Marc LIMODIN LA BANQUE POSTALE Directeur des Techniques et Infrastructures Franois STEPHAN - THALES Directeur Technique Eric STERN ORANGE-FRANCE TELECOM Responsable Expertise Environnement Technique Nol CAVALIERE PSA PEUGEOT-CITRON Responsable de lArchitecture Technique Claude CORIAT RENAULT Responsable Stratgie et Politiques Techniques Jean-Paul AMOROS - GDF SUEZ CTO /Directeur de la Production Informatique Olivier MAUPATE - IT Director Pascal PICCHIOTTINO BOUYGUES TELECOM Responsable Dpartement Infrastructure SI Rseau Frdric DIDIER CREDIT FONCIER Directeur Production Informatique Secrtaire : Michel GROSBOST Trsorier : Gilles ALBERT SOCIETE GENERALE Technology Strategy Manager
PAGE 71
Plus de 115 grandes entreprises franaises adhrent ou sont en cours dadhsion au CRiP
TOTAL MAAF LOREAL GROUPAMA SI DARVA CREDIT AGRICOLE SA ADP GSI AEROPORTS DE PARIS ERDF GIE ALLIANZ INFORMATIQUE EIFFAGE AIR LIQUIDE MINISTERE DES FINANCES RENAULT CCR ASSET MANAGEMENT AREVA LA FRANCAISE DES JEUX SWISS LIFE KEOLIS AUCHAN INTERNATIONAL TECHNOLOGY AVIVA SOCIETE GENERALE AXA TECH LAFARGE BRED MUREX NEXTER GROUP NORBERT DENTRESSANGLE BOUYGUES TELECOM CASINO THALES GROUP CNES VALLOUREC MANPOWER FRANCE RTE FRANCE BIC CHOREGIE FRANCE TELEVISIONS CA SITS DISNEY DIRECTION DES DOUANES CREDIT IMMOBILIER DE FRANCE DANONE DCNS CNP ASSURANCES INA CPSIAT ARMEE DE TERRE CREDIT FONCIER EDF ESSILOR INTERNATIONAL FM LOGISTIC LOUIS VUITTON MALLETIER GENERALI GDF SUEZ SFR SI2M (MALAKOFF MEDERIC) VENTE PRIVEE.COM I-BP AIR FRANCE MACIF ARAMICE MINISTERE DE LINTERIEUR CARREFOUR GROUPE IMS GROUP NATIXIS GROUPE ADEO OECD ORANGE FT GROUPE PMU ARKEMA RESEAU FERRE DE FRANCE RHODIA SAINT GOBAIN SANOFI AVENTIS CA SILCA CAISSE DES DEPOTS LA BANQUE POSTALE GCE TECH (CAISSE EPARGNE) CREDIT AGRICOLE CIB CANAL + APHP PSA PEUGEOT-CITROEN RATP ALSTOM SCOR STIME POLE EMPLOI DEXIA LA POSTE MINISTERE DE LA DEFENSE SNCF GENERALE DE SANTE VOLVO IT SPIE DIM TECHNIP ETAM SUPERMARCHES MATCH EULER HERMES PRAXIS SERVIER GROUPE PREVOIR PIERRE FABRE AGIRC-ARRCO COFACE BUREAU VERITAS COFIDIS CFAO VALEO Etc
Le CRiP (Association Loi 1901) compte 115 grandes entreprises ou entits utilisatrices des technologies de linformation, adhrentes ou en cours dadhsion. Il rassemble une communaut de plus de 900 membres, responsables dinfrastructure ou de production. Le CRiP est un cercle de confiance, lieu dchanges et dinformations entre les diffrents membres confronts aux mmes dfis financiers, technologiques et organisationnels.
PAGE 72
Objectifs
- Etre plus performant dans les mtiers de linfrastructure et de la production - Partager nos visions et retours dexpriences - Echanger et travailler sur les technologies les ressources humaines les organisations et processus les approches financires des projets les relations avec les offreurs - Promouvoir notre fonction au sein des entreprises - Sappuyer sur les travaux du CRiP pour asseoir une position au sein de notre entreprise - Crer un rseau de communication rapide et efficace entre dirigeants.
Charte dEthique et dEngagement du CRiP

Le Club des Responsables dInfrastructure et de Production est constitu sur la base de valeurs et de principes daction et de comportement, fonds sur des rapports de confiance permanents entre ses membres. Les membres sont les reprsentants des socits adhrentes du CRiP.
Principes daction
Respect de la loyaut Les membres du CRiP ont pour principe la loyaut lgard des autres participants afin dinstaurer et de maintenir des relations de confiance durables. Participation active Les socits adhrentes au CRiP et leurs reprsentants membres du CRiP sengagent contribuer activement la vie du Club en apportant leur exprience et leur savoir-faire aux travaux collectifs. Les socits adhrentes sengagent - rpondre dans un dlai convenable aux diffrents questionnaires qui pourraient leur tre envoys - faire participer au moins un de leurs reprsentants au moins un groupe de travail - favoriser la participation de leurs reprsentants aux plnires du CRiP - promouvoir le CRiP au sein de leur organisation Les membres reprsentants sengagent - se comporter en ambassadeur du CRiP et promouvoir le CRiP auprs de leurs pairs et des fournisseurs - participer activement dans la mesure de leurs comptences, de leurs moyens, et de leurs autorisations internes aux confrences CRiP/ itiForums, soit en tant que membre dun comit de programme, travers un tmoignage, une table ronde ou en aidant la production de contenu.
Principes de comportement
Confidentialit Chaque membre du CRiP sengage ne pas divulguer des tiers les informations professionnelles prsentes, sauf accord explicite des membres metteurs et du bureau excutif du Club. Chacun des participants, membre permanent ou occasionnel, sinterdit dutiliser directement ou indirectement, des fins personnelles, des informations sensibles quil pourrait dtenir dans le cadre du Club. Conflits dintrts Chaque membre du CRiP se doit dviter toute situation de conflit entre les intrts du Club et ses intrts personnels ou ceux de ses proches. Le Club est un club dutilisateurs. Cependant certains de ses membres peuvent appartenir des socits adhrentes qui possdent dans leurs missions une offre de service pour les autres adhrents. Il est impratif dans ce cas que les reprsentants membres de ces dites socits aient un comportement irrprochable et nutilisent pas ce cercle de confiance pour promouvoir les offres de services de la socit qui les emploie.
PAGE 73
16 Groupes de travail sont actifs ce jour

Le mode de fonctionnement
Actuellement, 16 groupes de travail thmatiques se runissent tout au long de lanne. Les groupes sur les thmes Rseaux, Mobilit & Collaboratif et Matrise des cots viennent dtre crs. Les travaux de ces groupes sont prsents lensemble des membres deux fois par an lors des plnires et loccasion de la Convention annuelle du CRiP au sein ditiForums.
STOCKAGE
Anim par Franois DESSABLES
Architecte SAN Stockage PSA PEUGEOT-CITRON
MTIERS
Anim par Marc LIMODIN
Directeur des Techniques et des Infrastructures LA BANQUE POSTALE
Objectifs :
Identifier et partager les bonnes pratiques dans le domaine du stockage, tablir le cadre dusage des diffrentes technologies.
Objectifs :
Thmes :
Traiter de lvolution des mtiers de linfrastructure et de la production, des problmatiques de ressources humaines et des problmatiques dorganisation.
- Virtualisation du stockage/de la sauvegarde - Dduplication - Sauvegarde sur disques - Rplication CRiP Thmat ique - Convergence LAN-SAN Stockage - Architectures. Livre Blanc Analyse et Tendance du Stockage (dit en novembre 2009)
Thmes :
- Panorama des mtiers et de leurs changements, - Sous-traitance, - Gestion des ressources humaines de production. Livre Blanc Mtier (prvu en 2011)
14 dcembre
2011
EFFICACIT ENERGETIQUE et DATACENTER

Anim par Claude CORIAT
Responsables Stratgie et Politiques Techniques RENAULT
Objectifs :
Identifier les meilleures pratiques en production pour le datacenter de demain et pour loptimisation de la consommation des composants dinfrastructure
Anim par Eric STERN
Thmes :
Responsable Expertise Environnement Technique ORANGE FT
- Optimisation nergtique - PUE, dfinition dindicateurs - Outillages de mesure - Bonne gestion du froid - Green IT, design de site
Livre Blanc Analyse et Tendance, vers le Datacenter idal (dit en juin 2009 loccasion dItiforums)
CRiP Thmat ique Datacenter 10 novembre 2010
Dossier Technique Datacenters : Efficacit Energtique et indicateurs de performances (dit en mars 2010)
PAGE 74
LOW COST
Anim par Frdric DIDIER
Objectifs :
Directeur Production Informatique CREDIT FONCIER Inventorier les pratiques dinfrastructure de rupture capables de fournir des services bas cot et les pratiques associes.
VIRTUALISATION SERVEURS & POSTES DE TRAVAIL

Anim par Marie-Christine MOULLART
Responsable Exploitation / Direction Infrastructures et Support GENERALI
Thmes :
- Logiciels open source, - Bring-your-own-PC, - Appliances, - Diffrenciation des classes de service dans le datacenter, - Utilisation de services et matriels grand public.
Objectifs : Recenser les expriences et les solutions, analyser les enjeux, dcrire la dmarche projet. Thmes :
- Solutions, arguments en faveur de la virtualisation, bonnes pratiques, piges et limites, impacts sur les projets les hommes et les services, les gains financiers et de niveaux de services. Dossier Technique Hyperviseur (dit en Dcembre 2010)
CRiP Thmat ique Low Cost 6 avril 2011
CRiP Thmat ique Virtualisation Serveurs 19 mai 2010
CLOUD COMPUTING
Anim par Franois STEPHAN
Directeur IT Transformation THALES
ique CRiP Thmat de Travail s te os P n Virtualisatio 28 avril 2011
Objectifs :
Comprendre et analyser les technologies du cloud computing pour dterminer leurs conditions dusage.
BASES DE DONNES
Anim par Jean-Paul VEZARD
Objectifs : Thmes :
Ancien Responsable DBA la SOCIT GNRALE Etudier les problmes doptimisation des SGBD. - Mtrologie, - Solutions de tolrance aux pannes, - Mthodes de mutualisation, - SGBD open source.
Thmes :
- Dfinition des concepts, - Gains attendus et constats, - Scurit, - Typologie des usages, - Modles priv-public-mixte, - Retours dexpriences et roadmaps des membres du CRIP. Livre Blanc Analyse et Grandes Tendances du Cloud Computing (dit en juin 2010 loccasion dItiforums)
CRiP Thmat ique Cloud Compu ting 13 janvier 2011
z/OS
Anim par Bruno KOCH
Directeur Dlgu Architecture Systme Mainframe GCE TECH (CAISSE EPARGNE)
ARCHITECTURE TECHNIQUE DENTREPRISE

Anim par Alain BALAGUER
Objectifs :
Responsable Architecture
Objectifs :
Grer, optimiser et mieux matriser les cots sur Mainframe, identifier les bonnes pratiques, inventorier les volutions et optimisations possibles.
Thmes :
- Modles de facturations, - Panorama de loffre logicielle, - Rationalisation et consolidation, - Tendances du march.
Analyser les modles de standardisation et de mise en oeuvre de modules oprationnels pour la construction du SI.
Matrise des co ts z/OS 17 Novembre 2011
Thmes :
- Perception de larchitecture technique dentreprise, - Dfinition du mtier darchitecte technique, - Bonnes pratiques, - Rfrentiels et outils de cartographie. PAGE 75
PRA
Anim par Luc VRIGNAUD
Responsable Division Support et Scurit MACIF
Anim par Franois TETE,
CMDB
Prsident dhonneur et Secrtaire Gnral Club de la Continuit dActivit
Anim par Frdrick PAQUET
Responsable Outils et Process THALES
Objectifs :
Etablir le cadre technique et oprationnel des plans de reprises dactivit.
Objectifs :
Thmes :
Rassembler et documenter les bonnes pratiques de mise en place et dutilisation de CMDB
- Concepts et vocabulaire PRA, - Architectures, - Cohrence applicative, - Critres de dclenchement, - Maintien en conditions oprationnelles, - Validit probante dun PRA. Livre Blanc Plan de Reprise dactivits (PRA) (dit en fvrier 2011)
En association avec
Thmes :
- Primtre et niveau de dtail de la CMDB, - Fiabiliser ses donnes, - Gains attendus, - Piges viter lors de la cration dune CMDB, - Exemples concrets de rsultats de mise en place. Livre Blanc - Comment construire et tirer bnfice dune CMDB ? (dit en juin 2010 loccasion de la Convention CRIP)
CRiP Thmat ique PRA 10 fvrier 2011
CRiP Thmat ique CMDB 14 dcembre 2010
GOUVERNANCE ORCHESTRATION
Anim par Hugues FONDEUX
Objectifs :
Charg de Mission Evolution de lInfrastructure PSA PEUGEOT CITROEN Etudier lautomatisation des processus dexploitation informatique et tablir les bonnes pratiques associes.
Anim par Maryse NICLI
Responsable Dpartements Projets, Intgration et Correspondants Mtiers GENERALI
Objectifs :
Dterminer les conditions de mise en place de modles de gouvernance dans linformatique de production.
Thmes :
Thmes :
- Gestion de fermes de serveurs, - Provisioning, - Acclration des PRA, - Traitement automatis dincidents, - Outils du march, - Difficults rencontres, - Analyse de rentabilit.
- Oprations dalignement mtier, - Gouvernance des contrats, - Valeur ajoute dans des environnements fortement externaliss. Fiche Pratique Alignement Stratgique de la Production Informatique aux Mtiers de lEntreprise (dite en mars 2010)
ANALYSE DES COTS DE LA PRODUCTION

Anim par Sasun SAUGY
Objectifs :
Charg de Mission Infrastructure & Production MINISTERE DES FINANCES ET DE LECONOMIE tablir un modle standardis danalyse des cots qui prenne rellement en compte les spcificits de la Production
RSEAUX, MOBILIT, COLLABORATIF

Anim par Eric Cambos
Objectifs :
Network & Telecom Manager CREDIT AGRICOLE CIB Traiter de lensemble des problmatiques lies aux rseaux dentreprise, en particulier la gestion de la mobilit et lexploitation des outils de travail collaboratif
Thmes :
Thmes :
- Inventaire des bonnes pratiques - Analyse des modles existants - Mthodes de benchmarking des cots - Construction dun rfrentiel de cots Infrastructure et Production PAGE 76
- Haute disponibilit des rseaux - Convergence SAN-LAN - Le collaboratif - La mobilit, les nouveaux terminaux (tablettes, smartphones, ByoPC) - Rseaux et Cloud Computing
Les Observatoires des Directeurs dInfrastructure et de Production sont une initiative du CRiP. Ces observatoires regroupent lensemble des documents produits par les groupes de travail. A lusage des membres du CRiP, ces documents sont de plusieurs types : Enqute et Analyse des tendances Livre Blanc : les meilleures pratiques Guide de rdaction dappel doffre Fiches pratiques Les Enqutes et Analyses de tendances sont issues de questionnaires renseigns par les membres du CRiP. Lanalyse des rsultats recueillis permet de mesurer et dobserver lvolution des enjeux des CTOs et de leurs infrastructures. En outre, elle met en relief les grandes tendances lies aux principaux challenges des productions informatiques. Dans le cadre de lObservatoire des Directeurs dInfrastructure et de Production, chaque groupe de travail actif apporte une contribution importante dans llaboration de documents de rfrence. Actuellement, 16 groupes de travail CRiP sont actifs : DataCenter, Stockage, Could Computing, Low Cost, z/OS, Mtiers, CMDB, PRA, Architecture Technique dEntreprise, Virtualisation Serveur & Poste de Travail, Gouvernance, Bases de donnes, Efficacit Energtique, Orchestration, Rseaux, Mobilit & Collaboratif, et Matrise des Cots.
Les livrables du
Thmatiques
Depuis trois ans, bon nombre de documents ont t publis. Parmi les plus significatifs, on mentionnera : - Livre Blanc Enqute et Analyse des Tendances Serveurs - Enqute et Analyse des Oprations informatiques - Enqute et Analyse des tendances lies au Datacenter - Livre Blanc Meilleures Pratiques du DataCenter - Enqute et Analyse des Tendances du Stockage - Enqute et Analyse des Tendances CMDB - Dfinitions et Concepts, Enqute et Analyse des Tendances du Cloud Computing - Fiche Pratique Alignement Stratgique de la Production Informatique aux Mtiers de lEntreprise - Dossier Technique Datacenters : Efficacit Energtique et indicateurs de performances - Dossier dAnalyse Technologique : Les Hyperviseurs serveurs x86 Tous ces ouvrages produits ou en cours de production deviennent inluctablement une rfrence importante pour les CTOs. Ils permettent de saffranchir dtudes parfois longues et coteuses et de se benchmarker par rapport aux grandes tendances actuelles. Plus gnralement, ils constituent des outils reconnus pour lamlioration de la productivit.
Nicolas COURAUD Responsable de la coordination des travaux du CRiP
ItiForums Le rseau social des professionnels de lInfrastructure et de la Production

Une relation privilgie avec le
Thmatiques
Vritable associ du CRiP, ITIFORUMS est charg de la communication, de la production et de la diffusion des documents et vidos issus des travaux du CRiP, de lorganisation des vnements (Convention, CRiP Thmatiques, CERCLE i) , du rfrencement fournisseurs, de la relation avec les partenaires stratgiques du CRiP, et de la relation avec les partenaires fournisseurs du CRiP (prsence de porte-parole aux vnements propritaires, voyages dtude, etc..)
PAGE 77
LEtat de lArt et la Traduction Oprationnelle des Services et Technologies dans la vraie vie de lEntreprise
Des confrences Utilisateurs qui font le point sur les travaux du CRiP. Les thmes traits dans les sessions sont ceux des 16 groupes de travail actifs du CRiP. Chaque session fournit lauditeur les cls de comprhension de la technologie, prsente lEtat de lart et la traduction oprationnelle des technologies et services dans la vraie vie de lEntreprise travers des retours dexpriences utilisateurs.
Les bnfices pour lauditeur :

- se forger une opinion en toute indpendance travers la restitution des travaux du CRiP, Club utilisateur des Responsables dInfrastructure et de Production dont le crdo est lindpendance vis--vis des fournisseurs - dcouvrir travers des tmoignages utilisateurs limplmentation oprationnelle des technologies et solutions avec leurs composantes cls, leurs business cases, leurs bnfices : promesses et ralits, leurs cueils et freins - bnficier de lclairage sur les grandes tendances actuelles et le panorama de loffre par un cabinet danalyste de renomme internationale tel que Forrester Research qui est le partenaire stratgique du CRiP - rencontrer les acteurs majeurs du march loccasion des pauses et du cocktail qui clture ces sessions
Thmatiques Infrastructure et Production 2011
CONVENTION ANNUELLE
CNIT, Paris - La Dfense
21 & 22 Juin 2011
Les thmes abords :

- RSEAUX, MOBILIT ET COLLABORATIF - STOCKAGE & SAUVEGARDE - PRODUCTION ET INDUSTRIALISATION - VIRTUALISATION SERVEURS ET POSTES DE TRAVAIL - CLOUD COMPUTING - LOW COST - MAINFRAME & Z/OS - DATA CENTER FACILITIES, GREEN IT, HBERGEMENT - CONTINUIT DACTIVIT & PRA - ARCHITECTURE TECHNIQUE DENTREPRISE - BASES DE DONNES - GOUVERNANCE, MTIERS, PROCESS, ITIL, CMDB
Les CRiP Thmatiques programmes en 2011

13 janvier : 10 fvrier : 6 avril : 28 avril : 15 septembre : 13 octobre : 17 novembre : 14 dcembre : Cloud Computing PRA Low Cost Virtualisation Poste de Travail Mobilit et Collaboratif Industrialisation de la production - Alignement des mtiers Matrise des cots - z/OS Stockage
Programme & inscription sur

www.itiforums.com
PAGE 78
Contacts
Club des Responsables dInfrastructure et de Production contact@crip-asso.fr www.crip-asso.fr
En application de la loi du 11 mars 1957, il est interdit de reproduire intgralement ou partiellement le prsent ouvrage, sur quelque support que ce soit, sans autorisation du CRiP.
Cration : fred.lameche - www.anousdejouer.fr
www.crip-asso.fr
15 rue vignon 75008 PAriS

Continuité D'activité

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Continuité D'activité

Încărcat de

Drepturi de autor:

Formate disponibile

Club des Responsables dInfrastructure et de Production

Le Club de la Continuit dActivit

des Directeurs dInfrastructures et de Production

LUC VRIGNAUD FRANOIS TETE

Table des matires

6.5 Pilotage du contrat de service 6.6 cueils et bonnes pratiques

Table des figures

FRANOIS TETE & LUC VRIGNAUD

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

le groupe de travail PRA

LUC VRIGNAUD, Pilote du Groupe de travail PRA MACIF

FRANOIS TETE, Prsident dhonneur et Secrtaire Gnral CLUB DE LA CONTINUIT DACTIVIT

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

Avec laimable autorisation de F Cointe. http://www.fcointe.com/

Le PRA : Lassurance de linutile ?

Figure 1 : le plan de continuit dentreprise

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

CONTINUIT, PRA, ET COMPAGNIE : INTRODUCTION

Le Plan de Continuit dActivits se dcline gnralement en deux niveaux

Figure 2 : le plan de continuit dactivit

1. Tlchargeable sur le site du CCA http://www.clubpca.eu/

De quelques minutes quelques heures

De 12 36 heures suivant lheure du sinistre

De deux cinq jours

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

Figure 3 : les diffrentes solutions de secours

Ne pas confondre haute disponibilit et PRA

Figure 4 : les cots : indisponibilit/reprise dactivit

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

Maturit des rpondants

Distance moyenne entre datacenters :

Volumtrie du stockage SAN utile au PRA rapporte la volumtrie SAN totale :

Figure 5 : niveaux de maturit dun PRA

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

ARCHITECTURE ET COHRENCE APPLICATIVE

On peut ainsi dfinir avec les mtiers

Figure 6 : PCA et gestion de crise

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

Traduire le besoin en solution avec le mtier

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

Figure 9 : architecture de secours en haute disponibilit

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

Bonnes (Rplication synchrone)

Facilit par la proximit

Facilit par la proximit

Plus dlicat du fait de lloignement

Lindpendance des sites augmente avec la distance

Difficults du fait de lloignement > Ncessite du personnel comptent sur site

Meilleure indpendance des sites vis--vis de sinistres rgionaux

Retour une situation normale (commune aux trois types de PRA)

2.3 Bonnes pratiques Dcouper le SI en plaques secourables homognes

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

Parmi les points prendre en compte, relevons aussi

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

2.4.b Crer des points stables

2.4.c Revoir lurbanisation du SI

2.4.d Sen remettre aux constructeurs ( ? ...)

2.4.e Un mix de ces quatre pistes

PRA : Dfinitions, Concepts, Bonnes Pratiques & Enqute

DCLENCHEMENT DU PRA ET GESTION DE CRISE

3.2 Rsum du chapitre

3.3 La gense : Le PRA naquit de lincident majeur

Procdure dincident majeur