Club des Responsables

Fiche Pratique d’Infrastructures et de Production En association avec le

PRA - PCA

L’automatisation
du PRA
1. Synthèse
Pour assurer la reprise d’activité dans des conditions Etape Automatisation
conformes aux objectifs établis à l’avance, l’automatisation
Escalade d’alerte · L ogiciel d’appel automatique
du PRA doit faciliter l’obtention du Recovery Time Objec- de convocation d’intervenants
tive (RTO) et du Recovery Point Objective (RPO) prédéter-
minés. L’automatisation doit également contribuer à réduire Détermination des · Logiciel d’analyse d’impacts
le nombre d’erreurs humaines qui risquent de se produire impacts du sinistre (serveurs, applications, processus)
sur la CMDB avec cartographie
dans ces situations de crise exceptionnelles et dans un
applicative et des flux
environnement incertain où les intervenants se trouvent
soumis à un stress important. Prise de décision de · L’automatisation n’est pas possible
Ceci étant, un sinistre partiel peut survenir à n’importe quel basculer en secours ni souhaitable
moment, et le nombre de scénarios de reprise d’activité Reprise d’activité sur le · L e degré d’automatisation est partiel
est très élevé. L’automatisation du PRA est-elle possible ? secours et dépend des environnements
Est-elle rentable ? Le cas envisagé dans le scénario d’auto- (systèmes d’exploitation)
matisation pouvant ne jamais se produire en réalité. · La reprise technique est plus
facilement automatisable que
Il faut distinguer l’automatisation du pilotage. L’automatisa- la reprise métier
tion a pour objet de réduire au maximum les interventions Contrôle technique et · L e contrôle technique est plus
humaines et de rendre ainsi plus rapide la reprise d’activité. fonctionnel facilement automatisable que
Alors que le pilotage consiste à maitriser le déroulement le contrôle fonctionnel métier
des opérations, à synchroniser les différentes actions de la
Fonctionnement en · Automatisable au même niveau
reprise d’activité et à en conserver une trace de l’exécution. secours que le fonctionnement normal

L’automatisation de la reprise d’activité n’est pas possible Retour à une situation · Le retour à une situation normale
en totalité. Elle ne peut s’appliquer qu’à certaines étapes du normale est planifié. Il est exécuté dans des
conditions préparées à l’avance.
PRA. Le tableau ci-contre résume les possibilités d’auto-
Le pilotage reste nécessaire.
matisation pour chaque étape du PRA.

Février En cas d’incident pendant les opérations de reprise, la L’entraînement des intervenants par des tests et exercices
2013 reprise d’activité devient manuelle, d’où l’intérêt du pilotage. facilite l’automatisation de la reprise d’activité.
2. Contexte
L’automatisation du PRA vise à répondre aux enjeux
suivants :
• Réduire les temps de reprise en conformité avec
les besoins métier, en particulier en déléguant aux
machines la réalisation de tâches fastidieuses et/
ou répétitives.
• Simplifier les opérations de reprise pour éviter les
erreurs humaines qui risquent toujours de se pro-
duire dans des situations de forte tension.
• Mieux maîtriser les opérations de reprise d’acti-
vité dans des environnements techniques dont
la complexité ne cesse d’augmenter. En effet,
aujourd’hui, un même service applicatif peut
reposer sur des dizaines de logiciels, d’appli-
cations unitaires et d’équipements (serveurs,
stockage, matériels réseau) eux-mêmes orga-
nisés en des ensembles complexes (clusters,
fermes, Clouds, etc.). La remise en service d’une
telle masse de systèmes devient parfois difficile-
ment réalisable sans l’assistance d’automates,
particulièrement sous délai contraint.
• Les offres Cloud et les environnements hautement
virtualisés fonctionnent aujourd’hui avec un haut
degré d’automatisation, donc le PRA doit en béné-
ficier lui aussi, et s’automatiser.
• L’automatisation dispense dans une certaine
mesure d’assurer des astreintes pour l’ensemble
des compétences pointues qui pourraient s’avé-
rer nécessaires au moment de déclencher le PRA.
L’automatisation permet de confier une partie de
l’expertise aux automates.
2
Le PRA totalement automatisé n’existe pas, mais
un certain niveau d’automatisation existe déjà.
Cependant, tout ne peut pas et ne doit pas être
automatisé. Par exemple, la prise de décision de
basculer en secours reste une décision purement
humaine qui demande une appréciation spécifique
des circonstances du sinistre, de sa nature, de ses
conséquences, et dépend du délai qui précède cette
prise de décision, délai qui varie lui-même très large-
ment selon les circonstances.
En ce qui concerne le pilotage du PRA, le principal
problème est la synchronisation des actions opéra-
tionnelles. Le pilotage nécessite un « maître de céré-
monie », qui donne l’ordre du lancement des actions
devant être exécutées en plusieurs endroits. Ce mode
de fonctionnement souligne le besoin d’un outillage
du « runbook » (compilation systématique de pro-
cédures et d’opérations à effectuer pour réaliser
une tâche ou une série de tâches) ainsi que de
disposer d’un ordonnanceur avec des gestions de
dépendance entre actions. Des logiciels du marché
existent pour automatiser certaines parties de la re-
prise d’activité : SRM de VMware, Dataguard de HP,
etc. D’autres logiciels permettent de piloter le PRA :
eFront d’eFront, PARAD de Devoteam, etc. Actuel-
lement, ces logiciels pilotent l’exécution de PRA
construits sur des cas de sinistre prédéterminés.
Ils formalisent l’ordonnancement de la reprise
d’activité. Ils pilotent toutes les actions à exécu-
ter. Les outils d’automatisation et de pilotage sont
complémentaires et peuvent être utilisés ensemble,
le logiciel de pilotage maîtrisant le déroulement de
toutes les actions dont celles automatisées par un
logiciel d’automatisation.
3. Problématique
Suite à un sinistre informatique, peut-on automatiser tout
ou partie de la reprise d’activité sur un site de secours ?
La difficulté la plus importante de l’automatisation, c’est
la resynchronisation des plaques applicatives et/ou
fonctionnelles et des échanges entre les composants
suite à la reprise. En effet, l’opération de reprise com-
porte deux phases qu’il faut bien isoler car elles posent
des problèmes totalement différents : les procédures de
reprise technique et les procédures de reprise applica-
tive. Ce sont les secondes qui posent des problèmes de
synchronisation complexes.
Ce point étant établi, il faut y ajouter plusieurs remarques.
a. Pour prendre en compte des sinistres partiels de plus
en plus fréquents, les scripts complets de reprise sont
découpés en modules qui sont comme autant d’îlots de
reprise relativement indépendants les uns des autres.
La difficulté consiste avant tout pour chacun de ces
îlots à déterminer des plaques de reprise homogènes.
Les échanges entre applications étant nombreux, cela
ne va pas de soi, et il faut une grande connaissance
des interactions entre composants au sein de blocs
fonctionnels.
Le PRA se compose lui aussi de plusieurs phases lar-
gement hétérogènes : on n’y règle pas les mêmes
familles de problèmes, on n’y pratique pas les mêmes
méthodes, on n’y mobilise pas les mêmes ressources.
Cette hétérogénéité interdit d’envisager une réponse
unique d’automatisation qui serait valable de bout en
bout.
Il faut donc bien isoler :
• Une phase de déclenchement préparatoire avant le
point de non-retour (abandon de toutes tentatives
de reprise sur le site de production nominal),
• Une phase de reconstruction de l’infrastructure du
secours,
• Une phase de reprise métier.
3
Ce découpage doit avoir été prévu dans la procédure
d’automatisation. Les différents modules peuvent même
s’exécuter en parallèle, mais il faut que l’automatisation
prenne en compte ce mode de fonctionnement.
b. La démarche d’automatisation doit avoir prévu les
différences entre situations d’exercice et situations de
PRA réel (fortuit, suite à sinistre). Dans le « runbook »,
certaines actions estampillées exercices (sauvegardes
complémentaires,  synchronisations  complémen-
taires, etc.) sont exécutées en cas d’exercice, mais pas
forcément lors de la survenue d’un incident fortuit dans
lequel les exigences de retour à la normale dans des
délais contraints imposent parfois de shunter certaines
étapes. L’automatisation doit être conçue de façon à
permettre le débrayage de ce qui n’est pas strictement
indispensable.
c. Lors d’un PRA fortuit, une des principales difficultés
consiste à savoir quelle partie du SI se trouve impactée,
alors que dans un exercice ou un test de PRA, ce
périmètre se trouve déjà connu (sauf en cas d’exercice
avec détermination aléatoire des composants impac-
tés, ce qui reste rare). Ce sujet de la détermination des
composants du SI impactés n’est pas couvert par
l’automatisation, mais par la supervision. Il faut donc
savoir quoi redémarrer au moment de lancer l’automa-
tisation, ce qui impose soit d’avoir relancé la supervi-
sion, soit de disposer d’un processus d’automatisation
capable d’analyser lui-même la situation.
4. Analyse
La reprise d’activité se décompose en différentes phases :
escalade d’alerte, gestion de crise et détermination des
impacts du sinistre, décision de basculer sur le secours,
reprise, contrôle de la reprise d’activité, fonctionnement
en secours et retour à une situation normale. Les possi-
bilités d’automatisation sont décrites par phase dans les
paragraphes suivants.
La mise en place de ces possibilités d’automatisation
est progressive. On commence avec des tests d’appli-
cations isolées. Ensuite des tests réels le week-end pour
prouver que les procédures de bascule fonctionnent.
Puis des tentatives de fonctionnement en secours pen-
dant une semaine, puis un mois pour valider les clôtures
de fin de mois. On arrive ainsi à un processus beaucoup
plus mature.
La participation des utilisateurs métier est très importante.
Si les métiers ne portent pas l’exercice, l’automatisation
du PRA ne fonctionnera jamais.
• Escalade d’alerte :
Des processus d’escalade avec des seuils d’alerte en
fonction de la gravité de l’incident sont déterminés à
l’avance. Il faut appréhender l’impact global de l’incident
grave / du sinistre pour choisir les compétences à mobi-
liser.
Certaines entreprises mettent en place un système de
gestion « d’incidentologie ». Il s’agit d’un mécanisme
d’escalade systématique déterminé en fonction de la
durée prévue de l’incident et des préconisations des
Métiers qui ont indiqué leur durée de réaction souhaitée.
Quand la durée de reprise est dépassée, on sort de «
l’incidentologie » pour aller vers un sinistre qui possède
une gestion particulière. Les automates d’appel envoient
alors des messages au niveau des intervenants opéra-
tionnels et décisionnels.
Il vaut mieux prendre une bonne décision un peu tard
qu’une mauvaise un peu vite. Selon la nature du sinistre,
il existe des workflows différenciés. Les scripts d’expédi-
tion d’alertes évitent de nombreuses erreurs humaines.
• Gestion de crise et détermination des impacts
du sinistre :
Mesurer les impacts réels de ce qui vient de se pas-
ser est essentiel. On lutte contre la montre, il faut
prendre les bonnes décisions avec les bonnes infor-
4
mations. Existe-t-il des outils permettant de faire des
évaluations simples afin de clarifier la prise de décision ?
Peut-on automatiser la recherche des impacts ?
La CMDB ou des outils de cartographie IT à jour peuvent
aider à ce genre d’analyse. Lors d’un incident majeur, cette
analyse n’a pas forcément lieu d’être car l’information re-
monte directement des Métiers qui signalent l’indisponi-
bilité de leurs outils et permettent d’évaluer l’ampleur du
problème en cours. Attention cependant, l’information
remontée des Métiers s’apparente plus à une alerte qu’à
une réelle analyse d’impacts.
Certaines entreprises utilisent cependant des outils
de gestion des impacts. Suite à un incident grave,
l’impact sur les Métiers est déterminé automatique-
ment. Cela ne permet pas de réparer plus vite, mais de
prévenir les Métiers des conséquences du sinistre sur
leur activité, y compris en ce qui concerne des éléments
auxquels les équipes présentes n’auraient pas forcé-
ment pensé. Il faut, pour ce faire, disposer d’une CMDB
reliée aux cartographies applicatives qui remontent
jusqu’aux processus métier. Cela reste assez théorique,
si la partie cartographie n’est pas très détaillée et bien à
jour. Le maintien en condition opérationnelle permanent
de ces dispositifs est primordial pour qu’ils remontent
une information de qualité au jour de l’incident.
Il serait contreproductif de chercher à automatiser des
processus de gestion de crise dans une période où les
équipes se trouvent forcément « chahutées ». La sim-
plicité prime et pousse vers des fiches « réflexes » ou
d’aide à la prise de décision. Dans une situation de pa-
nique, il faut pouvoir réagir simplement. L’automatisation
totale peut être contre-productive.
Il faut aussi se laisser le temps de prendre la bonne
décision. Par exemple, un début d’incendie, qui finale-
ment n’en était pas un, a arrêté les climatisations, éteint
les serveurs, etc. La décision de déclencher le PRA a
été évoquée, suite à l’arrêt brutal des serveurs. Mais la
cellule de crise s’est laissée le temps de prendre une
décision, et le site de production a redémarré plus vite
que la mise en service du site de secours. Le passage
en secours n’a pas été précipité. L’analyse humaine est
très importante.
• Décision de basculer en secours
La prise de décision de basculer sur le site de secours
reste de la compétence des cellules de crise. Cette opé-
ration n’est donc pas automatisable mais seulement
pilotable.
• Reprise d’activité technique, reprise applicative
et reprise métier
La reprise n’est pas un bloc homogène, elle comporte
trois éléments : reprise technique, reprise applicative et
reprise métier.
La reprise d’activité technique est très largement auto-
matisable. Mais il faut disposer de plaques techniques et
fonctionnelles cohérentes et homogènes. Plus la plate-
forme est complexe, plus il sera difficile d’automatiser
sa reprise technique. Cependant, en ce qui concerne
la reprise technique, la boîte à outils est désormais
bien fournie. Bien qu’au sein d’un même silo technique
(Mainframe, Unix propriétaires, Windows) il existe des
solutions, il n’en existe pas réellement de transverses :
chaque silo technique propose son approche de l’auto-
matisation.
La reprise d’activité des environnements consolidés de
type Unix propriétaires se rapproche de la reprise d’acti-
vité sur un mainframe. Le redémarrage est très auto-
matisé, avec un fort enchaînement des tâches de redé-
marrage. Dans des environnements fortement virtualisés
avec VMware, même situation. De façon générale,
l’automatisation du PRA se trouve simplifiée par lesé-
volutions des systèmes. Il y a dix ans, conduire un PRA
était beaucoup plus complexe. Actuellement, nous
avons beaucoup d’outils d’automatisation technique.
Les interventions manuelles s’en trouvent réduites.
En termes de reprise applicative, automatiser la reprise
d’une application isolée ne pose guère de problèmes,
mais il semble difficile d’automatiser la reprise d’un
ensemble d’applications interdépendantes, et encore
plus d’automatiser la reprise des flux, opération qui
demande en règle générale une intervention humaine.
Pour traiter des milliers de flux, il faut avoir défini des
points de synchronisation, avec des actions à exécu-
ter. Cela peut être automatisé mais au prix d’un énorme
travail de préparation. Il y a là un problème de temps
et de moyens, qui demande de mobiliser en amont les
ressources métier pour la mise au point. Si l’infrastruc-
ture d’échanges est une application à part entière (ESB,
5
EAI), il est possible de l’utiliser pour réaliser les synchro-
nisations. L’automatisation repose alors sur des scripts
avec des tableaux relativement simples. L’ouverture des
flux et la synchronisation des processus restent plus
complexes.
La reprise d’activité métier est plus faiblement automa-
tisable car beaucoup plus coûteuse et très difficile dès
qu’il y a de l’asynchronisme dans les flux.
• Contrôle technique et fonctionnel de la reprise
d’activité
Les contrôles techniques et fonctionnels sont automa-
tisables, et il est souhaitable de les automatiser. Les
contrôles techniques se font au moyen de scripts et des
outils de supervision. En ce qui concerne les contrôles
métier on utilisera surtout les scripts. Mais ce contrôle par
script reste partiel et on demandera toujours à quelques
utilisateurs métier de valider la cohérence des données.
Les équipes métier doivent donc être informées à l’avance
de l’existence de cette phase de contrôle pour désigner
des groupes de validation.
Lors de la reprise, les utilisateurs qui n’appartiennent pas
à ces groupes de validation devront être tenus écartés
de l’application tant que sa reprise n’a pas été validée.
• Fonctionnement en secours
Nous nous retrouvons ici dans le domaine du fonction-
nement normal de la Production. Les outils de pilotage
et d’automatisation doivent être opérationnels comme
sur le site nominal.
• Retour à une situation normale
Le retour à une situation normale est planifié. Il est
exécuté dans des conditions préparées à l’avance. Le
pilotage reste nécessaire. L’automatisation utilisée pré-
cédemment est utilisable dans un contexte plus simple.
5. Conclusion
Comme nous l’avons vu, l’automatisation complète du
PRA en tant que tel semble difficilement réaliste au regard
de la difficulté de qualification du niveau de criticité de
l’incident. Cependant une approche «EPAO» ( Exécution
des PRA assistée par ordinateur ) semble acceptable
dans l’objectif de raccourcir le temps d’exécution de la
bascule.
Retenons que, comme pour un système de contrôle
industriel, le système d’automatisation du PRA doit
disposer d’un asservissement fort sur l’état du SI.
Cela rend sa conception délicate.
Le système d’exécution du PRA est donc basé sur un
écosystème complexe de processus ( gestion d’inci-
dents, gestion de crise, bascule d’infrastructures, … )
qui nécessite une aide au pilotage. Les outils ne sont
actuellement pas encore totalement matures sur cette
vision transverse. Cela donne de la valeur au respon-
sable PRA /PCA, mais l’oblige à exercer un vrai rôle de
coordinateur …
La confusion dans l’action serait-elle une garantie de
clarté dans la réalisation ? L’art difficile du PRA nécessite
maitrise, répétition et coordination. Le succès n’existe
qu’à ce prix.

Rédaction : Groupe de Travail PRA-PCA - Assistance Editoriale : Renaud Bonnet, CRiP - Création Fred.lameche - www.anousdejouer.fr
On peut atteindre un haut niveau d’automatisation tech-
nique, mais on ne peut pas automatiser l’expertise qui Finalement, le pilotage des PRA ne prime-t-il pas sur leur
conduit à la prise de décision de la bascule en PRA ni automatisation ? La puissance n’est rien sans maitrise !
la validation par les Métiers de la reprise d’activité, car,
sur ce point, ce sont les Métiers qui ont toujours la main.
L’automatisation du PRA doit être prise en compte dès
la conception de l’application.

Club des Responsables d’Infrastructures et de Production

15 rue vignon 75008 PARIS - contact@crip-asso.fr www.crip-asso.fr

Club de la Continuité d’Activité

73 rue Anatole France 92300 LEVALLOIS PERRET - contact@clubpca.eu www.clubpca.eu

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.