Yphise optimise en Coût Valeur Risque l informatique d entreprise

Transcription

1 Comprendre comment réussir la continuité de service Mars 2008 Xavier Flez Propriété Yphise 1

2 Constat Nous voyons dans beaucoup de DSI des opérations métier critiques sur lesquelles les engagements de reprise ne sont pas établis ou pas adéquats Ce qui se traduit par : «en cas de sinistre on mettrait tout le monde sur le pont» Notons que dans le cas de SI (Systèmes d Information) complexes au fil de l eau, la reprise peut être malgré tout impossible sans dommage grave pour le métier Une articulation mal gérée entre BCM (Business Continuity Plan) et IT SCM (IT Service Continuity Management) 2

3 Rappel : concepts et vocabulaire Le BCM (Business Continuity Management) est le processus de gestion des sinistres au niveau de l entreprise. Il se décline par business line ou processus métier La reprise se fait selon un BCP (Business Continuity Plan) ou PRA (Plan de Reprise des Activités) L IT SCM désigne le volet informatique du BCM. C est la reprise du fonctionnement du système d information La reprise se fait selon un IT SCP (IT Service Continuity Plan) ou PS (Plan de Secours) ITIL distingue correctement ces deux niveaux (déjà en v2) 3

4 Problèmes pour avancer (1/2) Beaucoup de projets «continuité de service» ne passent pas l arbitrage des priorités du CoDir compte tenu des demandes plus urgentes des métiers Lorsque ces projets sont lancés, nous voyons de nombreux échecs Des préconisations refusées parce que trop coûteuses (centre de secours avec un secondaire mirroré) Mise en place d un centre de secours qui bute sur de réelles difficultés technicoéconomiques pour un résultat qui ne suffit pas forcément à garantir la reprise de l activité, en particulier : corruption de données, c est-à-dire nécessité de reconstituer l activité à partir de données plus ou moins anciennes opérations métier implémentées par des SI indépendants ou gérés comme tels 4

5 Problèmes pour avancer (2/2) Enfin, lorsque ces projets arrivent à sortir un IT SCP, des difficultés remettent en cause rapidement son utilité Maintien dans la durée compte tenu des évolutions permanentes de l infrastructure et des applications Organisation des responsabilités et de leurs interventions 5

6 D ITIL v2 à ITIL v3 et ISO (1/2) En schématisant un peu, ITIL v2 était sur une logique de mise en place d un centre de secours L IT SCM consistait en un projet dont la finalité était concrètement sa mise en place ITIL v3 et ISO repensent le sujet (tout en conservant les bons concepts d ITIL v2) La continuité de service est d ailleurs un excellent exemple pour illustrer «l approche service» de cette nouvelle génération du Service Management 6

7 D ITIL v2 à ITIL v3 et ISO (2/2) Dans ITIL v3, la continuité de service est située dans le Service Design. On part de l opération métier, on construit la nomenclature de services utiles La notion de sinistre s apprécie selon ce qui est important en terme de continuité pour le métier sur ses opérations Processus métier (ex logistique) Opération métier (ex appro) Catalogue de services On passe d une «logique projet» à une «logique de gestion d un catalogue de services» Service Métier Service Service Voyons concrètement cela... CMDB SI 7

8 Rappel 1 : les notions de RPO et RTO La continuité de service est une exigence métier non fonctionnelle de type SEF (Sécurité, Exploitabilité, Flexibilité) qui s analyse en termes de RTO et RPO RTO = durée d interruption du métier Opération métier RPO = données perdues à la reprise 8

9 Rappel 2 : la notion de sinistre Un sinistre «casse» une opération métier sur laquelle il faut reprendre selon un RTO ou RPO défini et il faut pour cela des moyens planifiés (IT SCP). C est la distinction avec l incident Une erreur fondamentale est de restreindre le sujet à quelques événements «graves» : incendie, inondation, attentat. La notion de sinistre n est pas liée à un type d événement Ex. un serveur tombe ; sa relance peut provoquer des incohérences dans le SI compte tenu de flux applicatifs entre serveurs ou vers l extérieur ; il faut un plan de reprise qui va exiger des saisies, synchronisations, contrôles précis, dont des actions du métier ; c est un sinistre 9

10 La situation «simple» avec laquelle on a longtemps vécu Partons du cas «simple» : une opération métier exécutée par une application sur une base de données Pour repartir, il faut remettre à disposition l infrastructure + données selon le RPO et RTO voulus Les moyens seront dimensionnés selon l exigence de RPO et RTO : infrastructure AH, salle blanche, configuration primaire secondaire, mirroring, centre de secours Un point important est que l IT SCM fait intervenir une seule responsabilité de type Production (en simplifiant un peu) Processus métier (ex logistique) Opération métier (ex appro) SI centralisé SI centralisé = une application sur Interne une base 10

11 La continuité de service est devenue un problème à 2 niveaux (1/2) Considérons une opération métier exécutée par un SI distribué, avec un flux de services ou applications sur différentes bases (on complique encore en considérant plusieurs SI ou parties indépendantes du point de vue de leur gestion) Pour repartir, il faut toujours remonter l infrastructure + données Processus métier (ex logistique) Opération métier (ex appro) mais cela ne suffit plus... SI distribué Interne SI partenaire CMDB CMDB SI distribué = flux de services ou applications (synchrones ou asynchrones) sur différentes bases 11

12 La continuité de service est devenue un problème à 2 niveaux (2/2)... il faut en plus contrôler, resaisir ou resynchroniser les données ; cela a deux conséquences importantes 1. Les exigences de RPO et RTO peuvent impacter la conception des applications 2. L IT SCP va le plus souvent nécessiter des procédures métier qui peuvent être sophistiquées (il n est pas du tout transparent pour le métier) Au final, l IT SCP ne fait plus intervenir une seule responsabilité comme précédemment mais deux : de type Production ; de type RSI (Responsable de SI métier) 12

13 Conséquences pour l IT SCM L IT SCP peut toujours évidemment comporter une mise en place de dispositifs techniques de type primaire secondaire, salle blanche ou centre de secours ; mais cela ne suffit pas La construction de l IT SCP nécessite potentiellement une intervention dans chaque projet applicatif en analyse, conception, puis vérification On n est plus sur un projet IT SCM unique La construction et l exécution de l IT SCP nécessitent d articuler des responsabilités Production et RSI... c est pour cela que l on a besoin d ITIL v3 ; le problème étant posé regardons comment il le traite 13

14 La traduction des responsabilités en services (1/2) Idée fondatrice : le Service Management selon ITIL v3 ou ISO nous propose de traduire la notion de responsabilité en services Articuler des responsabilités revient à gérer une nomenclature ou catalogue de services Processus métier (ex logistique) Opération métier (ex appro) Catalogue de services Un service définit un engagement. Le fonctionnement d une DSI articule ces services Service Métier Service Service CMDB SI 14

15 La traduction des responsabilités en services (2/2) Gérer les deux niveaux de responsabilité nécessaires à la continuité de service amène à distinguer naturellement deux types de services L IT SCM va reposer sur des services de type Production et des services de type Application L IT SCP agrègera des morceaux gérés par ces deux types Processus métier (ex logistique) Service Prod HA Opération métier (ex appro) Service Métier Appro Service App Suivi CMDB SI distribué 15

16 Les rôles, missions et activités de l IT SCM (1/4) Gérer la continuité de service consiste à mettre en place un IT SCM (le processus qui construit et gère l IT SCP) structuré ainsi C est un schéma de principe, l organisation finale dépend du contexte Processus métier (ex logistique) Service Prod HA CMDB Opération métier (ex appro) Service Métier Appro Service App Suivi SI distribué Service Continuity Manager Coordination IT SCP Relation d ensemble avec le BCM Vérification et Validation de l IT SCP Suivi préventif et correctif d ensemble RSI Accompagnement de chaque projet pour Analyse, Conception, prise en compte et Vérification du besoin de continuité (RPO et RTO) Gestion des parties de l IT SCP pour contrôler, reconstituer, resynchroniser (dont procédures métier) Suivi préventif et correctif utiles Production Gestion d un infrastructure selon des objectifs donnés de RPO et RTO Gestion des parties de l IT SCP pour remise en place infrastructure + données selon RPO et RTO donnés Suivi préventif et correctif utiles Structuration du processus d ITSCM - rôles, missions, activités 16

17 Les rôles, missions et activités de l IT SCM (2/4) A ce stade, il est important de constater deux points essentiels 1. On est passé d une logique de projet ponctuel de mise en place d un IT SCP (ITIL v2) à un processus d IT SCM cadré par le catalogue de services (ITIL v3) 2. On a les principes pour dépasser les conflits de responsabilité et traiter les «trous» si souvent constatés Le schéma précédent est un exemple simplifié en terme de services ; la réalité est... 17

18 Les rôles, missions et activités de l IT SCM (3/4) Plusieurs RSI Processus métier (ex logistique) Plusieurs SI = CMDB Opération métier (ex appro) Besoin d optimisation des coûts par distinction HA et Std au niveau Production Service App Ordre Service Métier Appro Service App Suivi Service App Transport Service Prod Std Service Prod HA Service Prod Std CMDB SI Paris SI Rome CMDB 18

19 Les rôles, missions et activités de l IT SCM (4/4) La complexité du réel, avec l enjeu d optimisation des coûts, amène à industrialiser les services, donc à la gestion explicite du catalogue de services (on ne peut sur chaque projet applicatif réinventer l ensemble des dispositifs de la continuité de service) La solution d ensemble de la maitrise de la continuité de services est donc bien le processus d IT SCM cadré par le catalogue de services C est «l approche service» telle que conçue par le Service Management ITIL v3 ou ISO

20 Avancer sur l IT SCP (1/2) La construction de l IT SCP fait donc passer d un enjeu de «projet IT SCP» à celui d établissement des rôles que nous avons vu, avec pour chacun la définition des savoir-faire utiles à leurs interventions On est sur un projet de conduite du changement à l intérieur d une DSI, avant d être sur des sujets techniques Un grand intérêt de ce changement de perspective est de pouvoir avancer de façon beaucoup plus pragmatique pour deux raisons... 20

21 Avancer sur l IT SCP (2/2) 1. On ne part pas d une perspective technique (le centre de secours) mais de ce qui intéresse les métiers à savoir leurs opérations C est-dire ce sur quoi ils savent arbitrer et mettre de l argent 2. Notre expérience montre qu on favorise également le pragmatisme des solutions, c est-à-dire à la fois utiles et efficaces, pour le métier et donc une nette optimisation des coûts Utile. Ex. Du centre de secours mirroré à une salle blanche + sauvegardes + procédure Mais aussi efficace. Ex. Réflexion précise lors d un projet sur le traitement de quelques cas limites dans une configuration primaire secondaire avec centre de secours 21

22 Merci 22