Fiche Pratique Février 2013 PRA - PCA L automatisation du PRA 1. Synthèse Club des Responsables d Infrastructures et de Production Pour assurer la reprise d activité dans des conditions conformes aux objectifs établis à l avance, l automatisation du PRA doit faciliter l obtention du Recovery Time Objective (RTO) et du Recovery Point Objective (RPO) prédéterminés. L automatisation doit également contribuer à réduire le nombre d erreurs humaines qui risquent de se produire dans ces situations de crise exceptionnelles et dans un environnement incertain où les intervenants se trouvent soumis à un stress important. Ceci étant, un sinistre partiel peut survenir à n importe quel moment, et le nombre de scénarios de reprise d activité est très élevé. L automatisation du PRA est-elle possible? Est-elle rentable? Le cas envisagé dans le scénario d automatisation pouvant ne jamais se produire en réalité. Il faut distinguer l automatisation du pilotage. L automatisation a pour objet de réduire au maximum les interventions humaines et de rendre ainsi plus rapide la reprise d activité. Alors que le pilotage consiste à maitriser le déroulement des opérations, à synchroniser les différentes actions de la reprise d activité et à en conserver une trace de l exécution. L automatisation de la reprise d activité n est pas possible en totalité. Elle ne peut s appliquer qu à certaines étapes du PRA. Le tableau ci-contre résume les possibilités d automatisation pour chaque étape du PRA. En cas d incident pendant les opérations de reprise, la reprise d activité devient manuelle, d où l intérêt du pilotage. Etape Escalade d alerte Détermination des impacts du sinistre Prise de décision de basculer en secours Reprise d activité sur le secours Contrôle technique et fonctionnel Fonctionnement en secours Retour à une situation normale En association avec le Automatisation Logiciel d appel automatique de convocation d intervenants Logiciel d analyse d impacts (serveurs, applications, processus) sur la CMDB avec cartographie applicative et des flux L automatisation n est pas possible ni souhaitable Le degré d automatisation est partiel et dépend des environnements (systèmes d exploitation) La reprise technique est plus facilement automatisable que la reprise métier Le contrôle technique est plus facilement automatisable que le contrôle fonctionnel métier Automatisable au même niveau que le fonctionnement normal 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 entraînement des intervenants par des tests et exercices 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 produire dans des situations de forte tension. Mieux maîtriser les opérations de reprise d activité 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 applications unitaires et d équipements (serveurs, stockage, matériels réseau) eux-mêmes organisés en des ensembles complexes (clusters, fermes, Clouds, etc.). La remise en service d une telle masse de systèmes devient parfois difficilement 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. 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 largement selon les circonstances. En ce qui concerne le pilotage du PRA, le principal problème est la synchronisation des actions opérationnelles. 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 procé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 reprise d activité : SRM de VMware, Dataguard de HP, etc. D autres logiciels permettent de piloter le PRA : efront d efront, PARAD de Devoteam, etc. Actuellement, 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écuter. 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. 2
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 comporte 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 applicative. 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 largement 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. 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émentaires, 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 impacté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 automatisation, ce qui impose soit d avoir relancé la supervision, soit de disposer d un processus d automatisation capable d analyser lui-même la situation. 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
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 possibilité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 applications 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 pendant 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 à mobiliser. 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érationnels 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édition 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 passer est essentiel. On lutte contre la montre, il faut prendre les bonnes décisions avec les bonnes informations. 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 remonte directement des Métiers qui signalent l indisponibilité 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é automatiquement. 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 simplicité prime et pousse vers des fiches «réflexes» ou d aide à la prise de décision. Dans une situation de panique, 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 finalement 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. 4
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 automatisable. Mais il faut disposer de plaques techniques et fonctionnelles cohérentes et homogènes. Plus la plateforme 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 automatisation. La reprise d activité des environnements consolidés de type Unix propriétaires se rapproche de la reprise d activité sur un mainframe. Le redémarrage est très automatisé, 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écuter. 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 infrastructure d échanges est une application à part entière (ESB, EAI), il est possible de l utiliser pour réaliser les synchronisations. 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 automatisable 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 automatisables, 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 fonctionnement 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
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. On peut atteindre un haut niveau d automatisation technique, mais on ne peut pas automatiser l expertise qui conduit à la prise de décision de la bascule en PRA ni 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. Le système d exécution du PRA est donc basé sur un écosystème complexe de processus ( gestion d incidents, 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 responsable 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. Finalement, le pilotage des PRA ne prime-t-il pas sur leur automatisation? La puissance n est rien sans maitrise! Rédaction : Groupe de Travail PRA-PCA - Assistance Editoriale : Renaud Bonnet, CRiP - Création Fred.lameche - www.anousdejouer.fr 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.