CONTINUITÉ MÉTIER ET
SECOURS INFORMATIQUE
Convergences et Divergences
Webinar – 5 février 2015
Dominique Nadjar & David Ab...
Pour plus d’informations :
www.hapsis.fr
Cabinet de conseil indépendant créé en 2002 par
des professionnels de la sécurité...
© Copyright Hapsis 2015. Tous droits réservés
QUISOMMES-NOUS?
LES CHIFFRES CLES :
2
© Copyright Hapsis 2015. Tous droits réservés
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objectiv...
© Copyright Hapsis 2015. Tous droits réservés
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objectiv...
© Copyright Hapsis 2015. Tous droits réservés
INTRODUCTION
En fonction de l’organisation de la structure, la responsabilit...
© Copyright Hapsis 2015. Tous droits réservés
DÉFINITIONS : PCA vs PSI
Plan de Continuité des Activités (PCA) / Business C...
© Copyright Hapsis 2015. Tous droits réservés
Introduction & Définitions
Inventaire des souffrances
Recovery Time Objectiv...
© Copyright Hapsis 2015. Tous droits réservés
INVENTAIRE DES SOUFFRANCES
• Remise en cause des RTO recensés dans le cadre ...
© Copyright Hapsis 2015. Tous droits réservés 9
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTSE...
© Copyright Hapsis 2015. Tous droits réservés
DÉFINITIONS : RTO & RPO
La durée d'interruption maximale admissible constitu...
© Copyright Hapsis 2015. Tous droits réservés
RTO EXPRIMÉ
 Amnésie (et/ou désintéressement ?)
 Surévaluation par rapport...
© Copyright Hapsis 2015. Tous droits réservés
- [PCA] Après consolidation du BIA, il ressort que les RTO de SOFIX et SUMMO...
© Copyright Hapsis 2015. Tous droits réservés
• Classification Gold, Silver,
Bronze, ou P1, P2, P3, ou
Vitale, Critique,…)...
© Copyright Hapsis 2015. Tous droits réservés
IMPACT DE LA MUTUALISATION DES
INFRASTRUCTURES INFORMATIQUES
• Application u...
© Copyright Hapsis 2015. Tous droits réservés 15
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTS...
© Copyright Hapsis 2015. Tous droits réservés
TESTS & EXERCICES
Tests de
repli
utilisateur
Tests
d’accès à
distance
Tests
...
© Copyright Hapsis 2015. Tous droits réservés 17
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTS...
© Copyright Hapsis 2015. Tous droits réservés
REGLEMENTATION
Un contexte règlementaire flou et souvent méconnu des équipes...
© Copyright Hapsis 2015. Tous droits réservés
FACTEURS DE COMPLEXITE ET IRRITANTS
Non respect des normes et standards inte...
© Copyright Hapsis 2015. Tous droits réservés 20
FACTEURSDE
COMPLEXITE
CONCLUSIONINTRODUCTION
RECOVERYTIME
OBJECTIVE
TESTS...
© Copyright Hapsis 2015. Tous droits réservés
CONCLUSION
GUIDE POUR DEVELOPPER UN PARTENARIAT EFFICACE
Responsable PCA Res...
© Copyright Hapsis 2015. Tous droits réservés
MERCI !
POUR ALLER PLUS LOIN …
Contactez-nous :
David Abgrall : david.abgral...
Prochain SlideShare
Chargement dans…5
×

WEBINAR : Comment amener RPSI et RPCA vers une situation coopérative ?

677 vues

Publié le

La réussite d'un projet PCA repose en grande partie sur la qualité des échanges entre le Responsable de Projet PCA et le représentant des équipes informatiques en charge de la mise en œuvre des solutions de secours techniques.

De la compréhension des besoins métiers, jusqu’à la prise en compte des contraintes associés à l’exploitation du système d’information, les sujets communs ne manquent pas.

Il est donc essentiel, pour les différents contributeurs, d’avoir un langage commun et de partager les mêmes objectifs.

Sur la base d’études de cas concrètes, ce webinar vous proposera des solutions pragmatiques visant à aboutir à la mise en place d’un espace commun de coopération efficient.

Inscrivez-vous gratuitement à cette session (60 minutes) et découvrez comment amener le RPSI et le RPCA vers une situation coopérative.

Publié dans : Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
677
Sur SlideShare
0
Issues des intégrations
0
Intégrations
9
Actions
Partages
0
Téléchargements
20
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

WEBINAR : Comment amener RPSI et RPCA vers une situation coopérative ?

  1. 1. CONTINUITÉ MÉTIER ET SECOURS INFORMATIQUE Convergences et Divergences Webinar – 5 février 2015 Dominique Nadjar & David Abgrall Consultant manager PCA - Hapsis
  2. 2. Pour plus d’informations : www.hapsis.fr Cabinet de conseil indépendant créé en 2002 par des professionnels de la sécurité informatique. QUI SOMMES-NOUS ? La mission de Hapsis a pour objectifs d’identifier, de quantifier et de gérer des risques par la mise en œuvre de processus de sécurité dont l’efficacité est renforcée par des compétences et des comportements adéquats. La diversité de nos compétences permet de couvrir un large spectre des besoins des clients. © Copyright Hapsis 2015. Tous droits réservés QUISOMMES-NOUS? 1
  3. 3. © Copyright Hapsis 2015. Tous droits réservés QUISOMMES-NOUS? LES CHIFFRES CLES : 2
  4. 4. © Copyright Hapsis 2015. Tous droits réservés Introduction & Définitions Inventaire des souffrances Recovery Time Objective Tests et Exercices Facteurs de complexité Conclusion AU SOMMAIRE : 3 SOMMAIRE
  5. 5. © Copyright Hapsis 2015. Tous droits réservés Introduction & Définitions Inventaire des souffrances Recovery Time Objective Tests et Exercices Facteurs de complexité Conclusion 4 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  6. 6. © Copyright Hapsis 2015. Tous droits réservés INTRODUCTION En fonction de l’organisation de la structure, la responsabilité du PCA et celle du PSI peuvent être dissociées. Si le Plan de Secours Informatique est logiquement pris en charge par la DSI, la responsabilité du secours métier (hors ressources DSI) est souvent localisé dans une entité fonctionnelle distincte. Dans ce cas précis le développement d’un partenariat efficace PCA/PSI peut être difficile et remettre en cause l’atteinte des trois principaux objectifs de ce partenariat :  Contribuer à l’alignement du niveau de secours du Système d’Information sur les exigences des métiers  Définir et mettre en œuvre des solutions techniques qui supportent la reprise des activités  Obtenir une meilleure visibilité sur le niveau de secours du SI et des applications Problématique : Comment amener RPSI et RPCA à coopérer efficacement ? FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES 5
  7. 7. © Copyright Hapsis 2015. Tous droits réservés DÉFINITIONS : PCA vs PSI Plan de Continuité des Activités (PCA) / Business Continuity Plan (BCP) Le Plan de Secours Informatique permet de couvrir un sinistre sur un site informatique via la mise en place d’une architecture spécifique et de procédures techniques. Organisationdecrise DatacenterSite utilisateurs DatacenterSite utilisateurs PCA PRU PSI DRP PRA PCIT Le Plan de Repli Utilisateur permet de couvrir un sinistre sur un site utilisateurs via la mise en place de stratégies de repli et des procédures fonctionnelles. • Le PCA met le processus métier au cœur de la solution et s’assure de la mise à jour et du caractère opérationnel du PSI. • Le PSI a pour objectif de maintenir la disponibilité et l’accessibilité du système d’information en cas de sinistre. 6 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  8. 8. © Copyright Hapsis 2015. Tous droits réservés Introduction & Définitions Inventaire des souffrances Recovery Time Objective Tests et Exercices Facteurs de complexité Conclusion 7 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  9. 9. © Copyright Hapsis 2015. Tous droits réservés INVENTAIRE DES SOUFFRANCES • Remise en cause des RTO recensés dans le cadre du Business Impact Analysis par la DSI • Peu de visibilité sur le niveau de secours du SI et de ses applications • Absence de référentiel applicatif • Incompréhension/questionnement sur les RTO mesurés par la DSI (Tests unitaires vs Tests Globaux) • Peu de solutions techniques proposées dans le catalogue de la DSI • Surévaluation des RTOs exprimés par les métiers (Syndrome de la liste au Père Noël) • Apparition ponctuelle d’applications inconnues (suite à une mise à jour du BIA) • Demandes récurrentes de mise en œuvre de solutions techniques pour le secours utilisateurs (Accès à distance, VDI, création de Masters…) • Difficulté pour tester le secours d’applications mutualisées sur un même socle technique avec des responsables métiers différents Responsable PCA Responsable PSI • Manque de rigueur / refus de coopérer • Rétention d’information • Retard technologique / Innovation faible SA PERCEPTION DU PSI SA PERCEPTION DU PCA • Chronophage • Utilité réduite • Connaissance technique faible 8 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  10. 10. © Copyright Hapsis 2015. Tous droits réservés 9 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES Introduction & Définitions Inventaire des souffrances Recovery Time Objective • Parlons-nous le même langage ? Tests et Exercices Facteurs de complexité Conclusion
  11. 11. © Copyright Hapsis 2015. Tous droits réservés DÉFINITIONS : RTO & RPO La durée d'interruption maximale admissible constitue le temps maximal acceptable durant lequel un processus métier ou une ressource (généralement informatique) peuvent être interrompus après l’occurrence d’un sinistre entraînant une interruption majeure de service. RTO (Recovery Time Objective) - DIMA (Durée d’Indisponibilité Maximale Admissible) La perte de données maximale admissible quantifie les données qu'un système d'information peut être amené à perdre par suite d’un incident. Usuellement, elle exprime une durée entre l’incident provoquant la perte de données et la date la plus récente des données qui seront utilisées en remplacement des données perdues. Cette durée est exprimée généralement en heures ou minutes. RPO (Recovery Point Objective) - PDMA (Perte de Données Maximale Admissible) Activation du secours Reconstruction Synchronisation DIMA Sauvegarde Sauvegarde Sauvegarde PDMA 10 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  12. 12. © Copyright Hapsis 2015. Tous droits réservés RTO EXPRIMÉ  Amnésie (et/ou désintéressement ?)  Surévaluation par rapport au besoin réel  Besoin de connaître le niveau de secours en place - [PCA] Quelle est votre durée d’interruption maximale admissible pour l’application SOFIX ? - [Métier] Bah je dirais 2 heures… - [PCA] Vous aviez répondu 1 jour l’an dernier… - [Métier] Ah bon ? Qu’est ce que l’on a aujourd’hui? RPCA & Métiers : Le syndrome de la liste au Père Noel  Rappeler la définition du RTO et les enjeux de cette démarche (Revue du secours en place => coûts à prévoir en cas d’upgrade)  Challenger le RTO avec le niveau de criticité de l’activité ou du processus métier que supporte l’application (Business Impact Analysis) Problématiques Axes de résolutions 11 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  13. 13. © Copyright Hapsis 2015. Tous droits réservés - [PCA] Après consolidation du BIA, il ressort que les RTO de SOFIX et SUMMOT doivent passer à 2 heures. - [PSI] 2 heures c’est pas possible pour les infrastructures de SOFIX. D’autant plus que lorsque l’application tombe, les métiers/utilisateurs mettent 1 semaine à s’en apercevoir, preuve que ce n’ est pas critique. Et pour SUMMOT, je n’ en ai jamais entendu parler… RPCA & RPSI : Le Père Noel ne fera pas de cadeaux ce coup ci…  Remise en cause brutale de l’expression de besoin métier  BIA truffé d’applications inconnues de la DSI  Obtenir des preuves que le métier ne supporte plus cette situation (Mails incidents, impacts Financier ou autre afin de forcer le dialogue et revoir l’architecture de l’application)  Exiger la mise en œuvre d’un référentiel applicatif à jour et maintenu par la DSI qui spécifie le RTO sur lequel la DSI s’engage mais aussi le RTO mesuré dans le cadre des tests  Nettoyer la liste des applications avant de la présenter au RPSI. Prévoir des ateliers de travail en cas d’absence de référentiel applicatif. Problématiques Axes de résolutions RTO EXPRIMÉ 12 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  14. 14. © Copyright Hapsis 2015. Tous droits réservés • Classification Gold, Silver, Bronze, ou P1, P2, P3, ou Vitale, Critique,…) • Classification héritée de l’infrastructure qui héberge l’application • Engagement de la DSI sur un RTO pour chaque niveau • RTO « contractuel » dont le respect ne sera prouvé que grâce aux tests RTO RÉEL OU MESURÉ « La DSI m’assure que le RTO actuel de SOFIX est de 6 heures. Que dois-je réellement comprendre? » RTO THEORIQUE Niveau de service ou de classification de criticité de l’application RTO MESURE Résultat de tests effectués par la DSI RTO « Sorti du Chapeau » Indisponible ou non mesuré • Mesuré dans le cadre d’un test applicatif unitaire OU • Mesuré dans le cadre d’un exercice de simulation de perte de datacenter 1 2 3 13 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  15. 15. © Copyright Hapsis 2015. Tous droits réservés IMPACT DE LA MUTUALISATION DES INFRASTRUCTURES INFORMATIQUES • Application utilisée par plusieurs métiers distincts ayant des besoins en secours différents. • L’application a été conçue en premier lieu pour des besoins « SILVER » Métiers Applications Infrastructures RTO GOLD RTO SILVER RTO GOLD RTO SILVER 1 2 Cas n° 1 • Plusieurs applications hébergées sur un même socle technique et utilisées par des métiers distincts ayant des besoins en secours différents. Cas n° 2 14 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  16. 16. © Copyright Hapsis 2015. Tous droits réservés 15 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES Introduction & Définitions Inventaire des souffrances Recovery Time Objective Tests et Exercices • Rappel des contributions Facteurs de complexité Conclusion
  17. 17. © Copyright Hapsis 2015. Tous droits réservés TESTS & EXERCICES Tests de repli utilisateur Tests d’accès à distance Tests Unitaires Tests DRP Globaux SecoursMétierSecoursInformatique • Mise à jour et déploiement de masters/image système et validation des zonings • Déploiement d’applications spécifiques à la demande des métiers • Fournitures/déploiement d’équipements réseau ou autre en cas de repli interne • Support utilisateur • Tests de charge / nombres de connexions simultanées possibles • Ouvertures de flux • Support utilisateur La DSI intervient en tant que contributeur du PCA Le RPCA intervient en tant contributeur • Mobilisation des métiers pour réaliser les tests de validation fonctionnels de l’application en environnement de secours et lors du retour en production • Remontée des résultats de tests auprès des métiers avec mise en évidence des RTOs non validés 16 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  18. 18. © Copyright Hapsis 2015. Tous droits réservés 17 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES Introduction & Définitions Inventaire des souffrances Recovery Time Objective Tests et Exercices Facteurs de complexité • Sinon c’est trop simple Conclusion
  19. 19. © Copyright Hapsis 2015. Tous droits réservés REGLEMENTATION Un contexte règlementaire flou et souvent méconnu des équipes informatiques « ensemble de mesures visant à assurer, selon divers scénarios de crises, y compris face à des chocs extrêmes, le maintien, le cas échéant de façon temporaire selon un mode dégradé, des prestations de services essentielles de l'entreprise puis la reprise planifiée des activités ». Dans le cas d’une sous-traitance (infogérance…) cette méconnaissance renforcée par :  La multiplicité des clients  La multiplicité des environnements règlementaires  Méconnaissance des choix d’architectures du SI lié  A la complexité du SI  A la multiplicité des plateformes Parmi les éléments qui conditionnent la définition d’un schéma directeur IT, les problématiques de règlementation liées à la continuité d’activité ne sont pas ou peu prises en compte. Extrait du règlement CRBF 97-02 18 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  20. 20. © Copyright Hapsis 2015. Tous droits réservés FACTEURS DE COMPLEXITE ET IRRITANTS Non respect des normes et standards internes • Utilisation d’applications développées en interne par les métiers et hébergées sur un NAS • Stockage de données sensibles sur un poste utilisateur en local plutôt que sur le réseau comme préconisé Organisation et structure de l’entreprise Business Unit 1 Business Unit 3 DSI (Infrastructures) DSI 1 (Applications) Business Unit 2 DSI 2 (Applications) • Echanges plus complexes lorsque la DSI est fractionnée (entités distinctes pour la gestion des applications et des infras) avec des interlocuteurs intermédiaires. • Difficulté pour la DSI d’organiser un test d’applications mutualisées sur un même socle technique avec des responsables métier différents (parfois même issus de départements différents). Applications complexes ou soumises à de nombreuses migration/refonte • Plusieurs noms utilisés et désignant une seule et même application • Architecture applicative complexe (nombreux composants, plusieurs instances, modules derrière une même application) 19 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  21. 21. © Copyright Hapsis 2015. Tous droits réservés 20 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES Introduction & Définitions Inventaire des souffrances Recovery Time Objective Tests et Exercices Facteurs de complexité Conclusion
  22. 22. © Copyright Hapsis 2015. Tous droits réservés CONCLUSION GUIDE POUR DEVELOPPER UN PARTENARIAT EFFICACE Responsable PCA Responsable PSI • Exiger la mise en œuvre d’un référentiel applicatif complet et à jour (et prendre part aux réflexions et réunions projets associées) • Partager les principes d’architecture et de résilience du SI et les contraintes associées (rôle d’éducateur) • Partager les résultats des tests unitaires/globaux en précisant la « nature » des RPOs et si besoin les composants applicatifs non testés • Utiliser les besoins du PCA métiers pour établir un schéma directeur du secours du SI • Disposer d’une « Charte Continuité d’Activité » formalisant les principes directeurs en matière de continuité et les engagements réciproques • Etablir une instance bipartite PCA/PSI pour fluidifier les échanges (via des réunion mensuelles) et établir un dialogue constant, ne se limitant pas à la transmission d’une liste de besoins « bruts » • Partager un référentiel applicatif commun et engager un processus d’amélioration continue pour l’harmonisation des dénominations • Clarifier les questions budgétaires et de refacturation • Argumenter/Justifier les besoins métiers (impacts financiers, nouveaux objectifs stratégiques ou autres…) • Veiller à fournir des documents propres à la DSI (listes d’applications sans doublons avec informations techniques et mode d’accès pour nouvelle application détectée) • Profiter des campagnes BIA pour sensibiliser les métiers aux bonnes pratiques (stockage de données et hébergement d’applications, mise à jour des référentiels) • Partager les exigences, contraintes et insatisfactions métiers liées à l’usage du SI (ex: problèmes de performance) • Maintenir un Gap Analysis entre besoins exprimés et situation réelle ET SURTOUT : 21 FACTEURSDE COMPLEXITE CONCLUSIONINTRODUCTION RECOVERYTIME OBJECTIVE TESTSET EXERCICES INVENTAIREDES SOUFFRANCES
  23. 23. © Copyright Hapsis 2015. Tous droits réservés MERCI ! POUR ALLER PLUS LOIN … Contactez-nous : David Abgrall : david.abgrall@hapsis.fr Dominique Nadjar : dominique.nadjar@hapsis.fr Tel : 01 53 16 30 60 www.hapsis.fr CONTACT 22 DES QUESTIONS ?

×