Le contexte Cette Conférence CRiP Thématique a été organisée par le Groupe de travail PRA/PCA, piloté par François Tête (président du CCA, Club Continuité d’Activité) et Pascal Antier (ADP). L’événement était parrainé par Jean-François Pasquier, Group IT Infrastructure Director chez Tarkett. Six témoignages d’entreprises, déjà engagées ou démarrant un projet de PRA/PCA, ont illustré les diverses facettes, la méthodologie, les aspects techniques mais également fonctionnels – autant de paramètres nécessaires pour rendre un PRA le plus opérationnel possible. Pas de recette miracle, même si quelques invariants existent, car chaque PRA est spécifique à chaque entreprise. Le PRA n’est plus un problème technique qui doit être seulement traité par les spécialistes de la DSI. Les Directions Métier sont de plus en plus impliquées, pour s’assurer que le PRA réponde aux attentes ‘business’ en cas de sinistre. Si les métiers aimeraient tendre vers le zéro-RTO, il faut mettre en regard les coûts induits avec les risques métier encourus. Les éléments techniques ont été abordés dans cette journée. Mais les témoignages ont permis de partager diverses expériences sur des éléments souvent plus importants, parfois intangibles, de l’optimisation du PRA.

30#Mai 2014

L’omniprésence de l’informatique dans l’activité de l’entreprise rend les directions générales de plus en plus exigeantes sur la nécessité de restreindre au minimum, voire supprimer totalement les interruptions non planifiées du S.I. Certes, la notion de PRA (plan de reprise d’activité) est aussi vieille que l’informatique elle-même, ou presque. Mais son périmètre a évolué. Désormais, les directions Métier s’invitent à la table des discussions sur la définition, les tests et l’audit du PRA, qui doit progressivement s’élargir du PRA au PCA. Mais l’objectif du zéro-RTO est-il réaliste, non seulement techniquement, mais également financièrement ?

PRA / PCA

L’Es

sentie

l

En quelques phrases• Qu’est-ce que les métiers sont prêts à payer ?

L’enjeu est de placer le curseur entre les risques et les moyens de les contingenter.

• Le PRA est un projet graduel qu’il faut stratifier, et pour lequel il faut trouver le bon niveau de granularité.

• L’adhérence entre applications nous oblige à traiter ces applications en blocs homogènes. Nous sommes pris entre deux feux : limiter le nombre de blocs en y intégrant le plus d’applications possibles, ou bien multiplier le nombre blocs avec peu d’applications, donc plus souples à basculer.

• C’est le critère « revenu généré par l’application » qui détermine son niveau de criticité.

• Le métier définit les scénarios, les plans de tests, et effectue puis valide les tests.

• Se préoccuper du ‘fail-over’ sur le site secondaire ne suffit pas : il faut également penser au retour vers le site primaire lorsque l’incident est clos.

• Un audit n’est réussi que s’il apporte de la valeur ajoutée à toutes les parties prenantes.

• Grâce au travail de tous sur le PRA, nous avons constaté une baisse de 10% de nos incidents classés ‘sévérité 1’ sur 3 ans, malgré la croissance des volumes applicatifs sur la période.

Club des Responsablesd’Infrastructures et de Production

CRiP Thématique

Mieux maîtriser et maintenir les PRA : les nouveaux enjeux de la continuité d’activitédu 16 avril 2014

1

2

Ce qu’il faut retenir

Comment tendre vers la continuité d’activité ?

Le groupe de travail PRA/PCA du CRiP a déjà

classifié les notions de PCI/PRA/PCA… Pour la

plupart des entreprises, rependre son activité après

un sinistre c’est bien, mais continuer son activité

malgré un sinistre c’est encore mieux. La continuité

d’activité dépasse le cadre de l’IT, elle doit traiter les

problèmes liés aux employés, aux postes de travail,

aux bâtiments, aux fournisseurs. C’est une cellule

de gestion de crise qui va mobiliser tous les maillons

critiques de l’entreprise (y compris l’informatique,

mais pas seulement) pour passer le cap de l’incident

pour lequel la cellule aura décidé d’activer le Plan de

Continuité. « Il est important de disposer des Business

Continuity Plans, car en cas de sinistre la cellule de

crise va interagir avec la DSI pour déclencher le PCIT

» commente un intervenant. Il faut prévoir le scénario

du pire, comme l’avoue un autre intervenant : « Nous

avons identifié les tâches les plus importantes à

réaliser même en cas de black-out total. Nous avons

défini les traitements à réaliser manuellement jusqu’au

rétablissement de l’informatique ».

L’objectif de réduction des RPO et RTO trouve des

réponses techniques, ce que confirme un témoin :

« Le PRA c’est une chose, la continuité de service

en est une autre. Les technologies permettent de

s’approcher du zéro RTO, mais à quel prix ? ». Et,

autre question préalable, toutes les applications de

l’entreprise doivent-elles tendre vers le zéro-RTO ? Un

des témoins explique : « Sous l’égide de la Direction

Financière, nous avons catégorisé nos applications

en 3 blocs : mission critique, business critique et

business standard ». Mais dans certains cas, les

contraintes géographiques rendent impossible,

ponctuellement ou non, un RTO nul, et même pour

une application critique : « Ce processus critique pour

notre métier implique 127 applications et plus de 100

serveurs. Avec 2 datacenters distants de 800 km

pour pallier un incident régional, comment faire pour

avoir un RPO même presque égal à zéro ».

Gérer le PRA comme un projet à part entière

Tous les intervenants reconnaissent que le PRA/PCA doit être géré comme un projet, et disposer d’un sponsorship de niveau managérial pour pouvoir disposer des moyens humains et financiers. Pour l’un, « le projet commence 6 mois avant la date du test. Le week-end du test mobilise une équipe de 220 personnes ». Chez un autre, « chaque année le projet de test démarre pendant l’été pour un test réel en novembre. Une semaine de préparation intensive avant le jour J permet de minimiser les risques ». Pour un troisième, « la préparation mobilise 8 ETP sur un an pour réaliser plus de 400 tests unitaires. L’exercice de bascule dure 36 heures, dont 12 sur site unique, et implique 120 intervenants IT». Un autre témoin, disposant d’une équipe de production d’une dizaine de personnes, a dû « renforcer les équipes pour passer le cap, et maintenir le PRA en état de marche une fois le test terminé ». La planification du test du PRA est donc un véritable projet qui doit adresser plusieurs facettes. Pour l’un des intervenants, il faut « effectuer une préparation rigoureuse des exercices sur 5 axes : technique, fonctionnel, organisationnel, logistique et sous l’angle de la communication ». Ce que confirme un autre témoin : « On a besoin d’une précision chirurgicale des équipes du projet. Il faut être hyper carré pour éviter de se perdre dans les détails, ou oublier les objectifs d’ensemble du PRA ». Mais même si le projet DRP est reconnu comme important pour l’entreprise, « il entre en conflit avec la vraie production, les vrais nouveaux projets, le périmètre est mouvant ». L’organisation de tests de PRA a parfois rendu évidente la création de profils de Business Relationship Managers (BRM): « Entre le business et l’IT, les équipes n’ont ni le même langage, ni les mêmes objectifs. Le BRM aide à fluidifier la gestion des incidents durant le PRA ». Une fois le test réalisé, « un plan d’amélioration global est découpé en plans d’améliorations spécifiques à chaque business ». On peut ainsi faire entrer le PRA dans un processus d’amélioration continue.

L’implication croissante des métiers

L’objectif ultime d’un PRA n’est pas tant de redémarrer le système d’information que de relancer a minima les applications critiques, de reconnecter les utilisateurs, et de pouvoir assurer à l’entreprise une Reprise d’Activité. Cela suppose que quelqu’un ait défini des applications, ou des blocs d’applications par type de criticité. Certains ont réalisé ce travail de classification sous l’égide du Directeur Financier Groupe. Pour d’autres, « c’est le revenu généré par l’application qui détermine son niveau de criticité ». Tous les intervenants ont convenu que les métiers sont de plus en plus impliqués dans le PRA et les exercices annuels. Pour l’un, « c’est le business qui définit les scénarios, les plans de tests, qui réalise et valide les tests ». Pour un autre, « les plans de tests sont conçus et testés par les métiers. Sinon ce sont les études qui s’y collent ».

Selon l’activité de l’entreprise, on peut même être amené à intégrer plusieurs fonctions transverses comme « les finances, les ressources humaines, la gestion des marchandises, le développement, les magasins ». Une fois le test engagé, « tous les domaines fonctionnels se connectent, et ce sont eux qui lors d’une conférence téléphonique donnent leur GO/NOGO à la poursuite du test, ou au repli en condition ‘normale’ ». Cela va sans dire, pour limiter, voire éviter les risques sur la production, les tests se déroulent le week-end de façon générale. Malgré tout, « c’est de plus en plus difficile de trouver un créneau sur lequel tous les intervenants sont disponibles ». Et « pendant le test, aucun impact métier n’est toléré ».

Jusqu’où doit-on tester son PRA ?

Chacun doit faire le grand écart entre la complétude des tests, les coûts humains induits et le risque encouru si le test est incomplet. Doit-on aller jusqu’à simuler un sinistre réel non planifié, ou rester dans le cadre d’un exercice au périmètre bien défini par avance ? Pas de dogme sur le sujet. Si l’un « active le PRA une semaine par an en production sur toutes les bases de production SAP », un autre « ne bascule pas réellement la production pendant le test. Elle est momentanément fermée aux clients durant la bascule ». Si certains jouent le jeu jusqu’au bout « simulant un sinistre en coupant les réseaux, sans toucher aux bases de données », la majorité préfère procéder à un test planifié, qui permet de procéder à « un arrêt propre des applications, des outils d’exploitation, des bases de production ».

La question de prévenir les utilisateurs fait débat, un intervenant avoue même « avoir renoncé à les prévenir désormais, car au moment du premier test, une surcharge d’incidents avait été signalée, dont une grande partie n’avait pas trait au PRA ». Pour éviter de mauvaises surprises lors du grand test annuel, certains imposent des tests préalables unitaires par application ou bloc d’applications, d’autres réalisent « des tests réguliers de bascule de ‘clusters’ de bases de données », et mettent « leurs pilotes d’exploitation en condition de PRA sur le site de secours tous les mois ». En parallèle, des exercices d’alerte inopinés permettent de « simuler en combien de temps les acteurs se mettent en ordre de marche pour redémarrer le site secondaire durant la journée, la nuit ou le week-end ». Une fois le test réalisé, les enseignements en sont tirés, pour agir sur les points faibles, et aller plus avant lors de l’exercice suivant. L’un souhaite « élargir le périmètre du test aux serveurs hors SAP (serveur de fichiers, serveurs d’infrastructure, serveurs d’accès distants …) » tandis que l’autre « se mettra dans des conditions plus proche d’un sinistre réel ». Le facteur financier s’invite à la réflexion pour un troisième : « Nous effectuons actuellement deux tests annuels, mais nous nous demandons si nous n’allons pas espacer les tests ».

Quelles perspectives pour le PRA ?

Cette journée riche en retours d’expérience a été focalisée sur la vision du PRA côté datacenter. La table ronde finale a permis de soulever quelques points annexes. A la question « qui lance le PRA dans l’entreprise», la réponse quasi-unanime était : « Aujourd’hui c’est la DG qui décide de lancer le projet PCA, même si la DSI fait des choses dans son coin ». Mais un intervenant souligne que, pour les tests, « c’est plutôt la DSI qui décide, car la DG ne voit pas tous les impacts découlant d’un PCA ». La question de l’accès des utilisateurs en cas de PRA peut trouver une réponse dans le travail à distance (sous réserve d’accords préalables et de la sécurisation des accès réseau), et avec l’accès d’une partie des utilisateurs à des centres de repli spécialisés.

De l’avis des intervenants, les sinistres logiques (tels une corruption de base de données, un virus ou une intrusion) ne sont pas redevables de PRA. Ils sont plutôt assimilables à des incidents d’exploitation. Néanmoins, en fonction de la profondeur ou de la virulence de l’incident « logique », il est envisageable de recourir au PRA, en espérant que les sauvegardes

L’Es

sentie

lC

RiP

Th

ém

atiq

ue

Mie

ux

ma

îtrise

r et

ma

inte

nir

les

PR

A :

les

no

uve

au

x e

nje

ux

de

la c

on

tinu

ité d

’ac

tivité

3

4

En application de la loi du 11 mars 1957, il est interdit de reproduire ; sous forme de copie, photocopie, reproduction, traduction ou conversion, le présent ouvrage que ce soit mécanique ou électronique, intégralement ou partiellement, sur quelque support que ce soit, sans autorisation du CRiP.

Club des Responsables d’Infrastructures et de Production24 rue Erlanger 75016 Paris - contact@crip-asso.fr www.crip-asso.fr

Réd

actio

n : P

hilip

pe R

oux

& P

ierr

e M

angi

n, C

RiP

- C

réat

ion

Fred

.lam

eche

- w

ww

.ano

usde

joue

r.fr

Digital Technology & Innovation

UnitedKingdom

Le sujet est d’importance. Le groupe de travail PRA/PCA a rédigé une fiche destinée à « préciser à l’audité le contenu d’un audit de la continuité d’activité » et « prendre en compte l’audit de la continuité d’activité, plutôt que se limiter à l’audit du PRA / PCA ». La fiche portera sur « le Système de Management de la Continuité d’Activité – SMCA » et « les services rendus aux clients selon la norme ISAE 3402 ». Faisant suite au standard SAS 70, la norme ISAE 3402 (International Standards for Assurance Engagements) permet aux utilisateurs de prestations externalisées d’obtenir une assurance sur la fiabilité du dispositif de contrôle interne de leurs prestations de services (voir : isae3402.com). La démarche d’audit doit souvent affronter des freins psychologiques de

la part de certains qui y voient un outil répressif. Et d’ailleurs, cette question se pose : l’audit doit-il être réalisé en externe ou en interne (sous réserve de disposer de compétences certifiées) ? Pour garder son degré d’indépendance, l’auditeur interne est de préférence rattaché directement à la Direction Générale et au comité d’audit. Une des clés de la réussite est « de construire des relations solides. Il faut démontrer la valeur ajoutée, faire accepter le jeu par la DSI dans une relation gagnant/gagnant, et éviter un audit répressif en aidant la DG à faire avancer le PRA ». De toutes façons, « avant de démarrer l’audit réel, on fait un diagnostic et on bâtit un programme de travail », car in fine « un audit n’est réussi que s’il apporte de la valeur ajoutée à toutes les parties prenantes ».

Comment audIteR son PRa ?

aient été immunisées. Dans les perspectives d’évolution du PRA, quel impact peut jouer le Cloud (public)? Les intervenants ont admis manquer, à ce jour, de retour d’expérience sur le sujet. Le Cloud offrira-t-il une solution de PRA low-cost ? Comment pourra-t-il satisfaire les contraintes de qualité de service demandées par les directions métier ? Et comment s’engager sur un RPO court sans devoir répliquer fréquemment les données vers le Cloud de secours ? La volatilité du Cloud n’obligera-t-elle pas à la multiplication des tests ?

Certaines technologies, comme Hadoop ou les ‘clusters’ de serveurs de calcul HPC par exemple, ne font plus dépendre leur disponibilité sur les seuls

composants matériels. La perte d’un nœud ne compromet pas l’aboutissement de l’application. C’est elle qui gère sa disponibilité et pallie les défaillances matérielles. Mais est-il concevable de réécrire les applications d’un PRA pour leur faire gérer elles-mêmes la haute disponibilité ? Le Software Defined Datacenter (SDDC) apportera- t-il des réponses à l’évolution du PRA ?

Si les évolutions technologiques repoussent les frontières du possible, les contraintes du business déplacent les limites de l’impossible « pour tangenter l’asymptote du zéro-RPO et zéro-RTO ». Ce qui laisse à penser que le sujet du PRA/PCA a encore de beaux jours devant lui.