Data Protection by The Numbers FD PDF

Ces documents sont protégés par le copyright © 2020 John Wiley & Sons, Inc.
Toute divulgation, toute distribution et tout usage non autorisés sont

strictement interdits.
La protection
des données
en chiffres
Édition spéciale Veeam
par Jason Buffington

Auteur de Data Protection
for Virtual Data Centers
Ces documents sont protégés par le copyright © 2020 John Wiley & Sons, Inc. Toute divulgation, toute distribution et tout usage non autorisés sont
La protection des données en chiffres pour les Nuls ®,
édition spéciale Veeam
Publié par
John Wiley & Sons, Inc.
111 River St.
Hoboken, NJ 07030-5774
www.wiley.com
© 2020 par John Wiley & Sons, Inc., Hoboken, New Jersey
Aucune partie de cette publication ne peut être reproduite, stockée dans un système de recherche documentaire ou
transmise sous quelque forme ou quelque moyen que ce soit, électronique, mécanique, photocopie, enregistrement,
numérisation ou autre, sauf dans la mesure permise par les articles 107 ou 108 du Copyright Act des États-Unis de
1976, sans l’autorisation écrite préalable de l’éditeur. Les demandes d’autorisation adressées à l’éditeur devront être
envoyées à Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011,
fax (201) 748-6008, ou en ligne à l’adresse http://www.wiley.com/go/permissions.
Marques déposées : Wiley, Pour les Nuls, le logo Dummies Man, The Dummies Way, Dummies.com, Making Everything
Easier et les présentations commerciales associées sont des marques déposées ou des appellations commerciales de John
Wiley & Sons, Inc. et/ou de ses filiales aux États-Unis et dans d’autres pays, et ne peuvent pas être utilisés sans autorisa-
tion écrite. Veeam est une marque déposée de Veeam Software. Toutes les autres marques déposées sont la propriété de
leurs détenteurs respectifs. John Wiley & Sons, Inc. n’est associé à aucun produit ou fournisseur mentionné dans ce livre.
LIMITE DE RESPONSABILITÉ/EXCLUSION DE GARANTIE : L’ÉDITEUR ET L’AUTEUR S’ABSTIENNENT DE TOUTE DÉCLARATION

OU GARANTIE EN CE QUI CONCERNE L’EXACTITUDE OU L’EXHAUSTIVITÉ DU CONTENU DE CET OUVRAGE ET EXCLUENT
EXPRESSÉMENT TOUTES GARANTIES, Y COMPRIS, MAIS SANS S’Y LIMITER, LES GARANTIES D’ADÉQUATION À UN USAGE
PARTICULIER. AUCUNE GARANTIE NE PEUT ÊTRE MISE EN ŒUVRE OU PROLONGÉE PAR L’INTERMÉDIAIRE D’UN DOCUMENT
COMMERCIAL OU PROMOTIONNEL. LES CONSEILS ET STRATÉGIES CONTENUS DANS CE LIVRE PEUVENT NE PAS CONVENIR
À TOUTES LES SITUATIONS. CET OUVRAGE EST COMMERCIALISÉ À LA CONDITION QUE L’ÉDITEUR NE FOURNISSE PAS DE
SERVICES JURIDIQUES, COMPTABLES OU D’AUTRES SERVICES PROFESSIONNELS. SI UNE ASSISTANCE PROFESSIONNELLE EST
NÉCESSAIRE, IL CONVIENT DE FAIRE APPEL AUX SERVICES D’UN PROFESSIONNEL COMPÉTENT. NI L’ÉDITEUR NI L’AUTEUR
NE PEUVENT ÊTRE TENUS POUR RESPONSABLES DES PRÉJUDICES POUVANT SURVENIR. LE FAIT QU’UNE RÉFÉRENCE À UNE
ORGANISATION OU UN SITE INTERNET SOIT MENTIONNÉE DANS LE PRÉSENT OUVRAGE SOUS FORME D’UNE CITATION ET/
OU D’UNE SOURCE POTENTIELLE DE RENSEIGNEMENTS SUPPLÉMENTAIRES NE SIGNIFIE PAS QUE L’AUTEUR OU L’ÉDITEUR
APPROUVE LES RENSEIGNEMENTS QUE L’ORGANISATION OU LE SITE INTERNET PEUT FOURNIR OU LES RECOMMANDATIONS
QU’IL PEUT FORMULER. EN OUTRE, LES LECTEURS DOIVENT GARDER À L’ESPRIT QUE LES SITES INTERNET CITÉS DANS LE
PRÉSENT OUVRAGE PEUVENT AVOIR ÉTÉ MODIFIÉS OU AVOIR DISPARU ENTRE SA RÉDACTION ET SA LECTURE.
Pour obtenir des informations sur nos autres produits et services, ou pour créer un livre personnalisé Pour les Nuls pour
votre entreprise ou organisation, veuillez contacter notre département de développement commercial aux États-Unis
au 877-409-4177, à l’adresse info@dummies.biz, ou vous rendre sur www.wiley.com/go/custompub. Pour plus d’infor-
mations sur l’exploitation sous licence de la marque Pour les Nuls pour des produits ou services, veuillez contacter
BrandedRights&Licenses@Wiley.com.
ISBN 978-1-119-67361-3 (pbk) ; ISBN 978-1-119-67362-0 (ebk)
Fabriqué aux États-Unis
10 9 8 7 6 5 4 3 2 1
Remerciements de l’éditeur
Nous sommes fiers de ce livre et des personnes qui ont participé à sa rédaction. Pour savoir com
ment créer un livre personnalisé Pour les Nuls pour votre entreprise ou organisation, veuillez contac-
ter info@dummies.biz ou vous rendre sur www.wiley.com/go/custompub. Pour plus d’informations
sur l’exploitation sous licence de la marque Pour les Nuls pour des produits ou services, veuillez
contacter BrandedRights&Licenses@Wiley.com.
Ci-dessous figurent quelques-unes des personnes qui ont contribué à la réalisation de ce livre :
Concepteur éditorial : Paul Levesque Rédacteur de projet : Vasanth Koilraj
Relectrice-correctrice : Becky Whitney Responsable éditorial : Rev Mengle
Sommaire
INTRODUCTION................................................................................................ 1
La pierre de Rosette de la protection des données............................. 1
À propos de ce livre.................................................................................. 2
Ce que vous trouverez dans ce livre...................................................... 2
Chapitre 1 : Métriques techniques : RPO, RTO et SLA................... 2
Chapitre 2 : Métriques opérationnelles : RA et BIA........................ 3
Chapitre 3 : Calculer le coût des temps d’arrêt............................... 3
Chapitre 4 : Métriques financières : CTP et ROI.............................. 3
Chapitre 5 : Dix clés pour améliorer vos discussions.................... 3
Icônes utilisées dans ce livre................................................................... 4
Et maintenant ?.......................................................................................... 4
CHAPITRE 1 : Métriques techniques : RPO, RTO et SLA................... 5

Délai optimal de reprise d’activité.......................................................... 5
Objectif de temps de restauration......................................................... 8
Allier le RPO et le RTO............................................................................... 9
Réaliser le RPO et le RTO avec le SLA................................................... 10
CHAPITRE 2 : Métriques opérationnelles : RA et BIA...................... 15

Analyse des risques : l’art de s’inquiéter.............................................. 15
Qu’est-ce qui pourrait alors mal tourner ?.................................... 16
Quelle est la probabilité ?................................................................. 17
Analyse d’impact sur les activités : combien cela coûtera-t-il ?........ 18
Toujours convertir les technologies en argent................................... 19
CHAPITRE 3 : Calculer le coût des temps d’arrêt................................ 21

Zoom sur quatre variables simples...................................................... 22
Données perdues.............................................................................. 23
Temps de panne................................................................................ 24
Les coûts humains............................................................................ 24
Rentabilité........................................................................................... 25
Mettre la formule en pratique.............................................................. 25
Calculer les coûts des temps d’arrêt pour un seul groupe ou
une seule charge de travail.............................................................. 26
Adapter la formule à votre entreprise........................................... 28
Sommaire iii
CHAPITRE 4 : Métriques financières : CTP et ROI............................... 31
Coût total de possession........................................................................ 31
Retour sur investissement..................................................................... 34
Calculer le ROI.................................................................................... 34
Déterminer quelle méthode de ROI est la plus précise.............. 36
Examiner le défi posé par la crédibilité du ROI............................. 37
Espérer que vos formules sont mises en question........................... 38
CHAPITRE 5 : Dix clés pour améliorer vos discussions.................. 41

Commencer par plus de discussions................................................... 41
Bien rédiger vos SLA du premier coup................................................ 42
Comprendre que les administrateurs de sauvegarde font
rarement de bons planificateurs de reprise après incident............. 42
Quantifier les défis informatiques en termes d’impact
opérationnel et financier....................................................................... 42
Admettre que ne rien faire coûte très cher........................................ 42
Réaliser que les temps d’arrêt coûtent plus que vous ne le
pensez....................................................................................................... 43
S’assurer que les parties prenantes discutent de vos formules...... 43
Prendre en compte les coûts accessoires........................................... 44
Accepter de voir les réglementations comme un avantage............. 44
Sortir vos données du site..................................................................... 44
iv La protection des données en chiffres pour les Nuls, édition spéciale Veeam
Introduction
L es chiffres mettent tout sur un même pied d’égalité.
Les métriques quantitatives vous permettent de comparer plusieurs

options de disponibilité et de protection de manière objective, sans le
parti pris de l’expérience, des préjugés ou de préférence du fournisseur.
Dans ce livre, nous nous intéresserons à plusieurs métriques. Nous
commencerons par définir chacune d’elles puis les intégrerons à la
réflexion sur le(s) type(s) de protection, de rétention et de disponibilité
des données dont vous pourriez avoir besoin dans différents scénarios.
La protection des données, dont la sauvegarde, est souvent considérée

comme un désagrément insoluble, source de complexité et de charge
budgétaire, qui apporte peu de fiabilité mais beaucoup de lassitude.
L’objectif de ce livre n’est pas de vous persuader d’acheter quoi que ce
soit. En effet, aucun fournisseur ou produit n’apparaît, à l’exception du
logo de Veeam sur la couverture (puisqu’il s’agit du sponsor de ce guide)
et des informations sur le produit sur la quatrième de couverture.
Veeam estime qu’il est essentiel de comprendre et d’adopter une
approche reposant sur des formules pour quantifier les capacités de
restauration technique, les impacts commerciaux et les enjeux finan-
ciers relatifs à la protection des données.
La pierre de Rosette de la protection des données

En substance, la célèbre pierre de Rosette fournit les mêmes informations
gravées sur la même face, en trois langues différentes. Grâce à elle, les
personnes capables de lire dans une langue pouvaient déduire la tra-
duction des autres langues et ainsi communiquer. Chacune des trois
« langues » de la protection des données dispose de ses propres termes,
priorités et acronymes à trois lettres. L’astuce consiste simplement à
pouvoir faire une traduction entre les langues propres à chaque
« tribu » :
»» Les professionnels de l’informatique s’appuient sur les délais

optimaux de reprise d’activité (RPO, recovery point objective) et les
objectifs de temps de restauration (RTO, recovery time objective) à
la base de leurs mesures de certains outils et technologies de pro-
tection des données.
»» Les professionnels chargés des opérations travaillent aux ana-
lyses d’impact sur l’activité (BIA, business impact analyses) et aux
Introduction 1
analyses des risques (RA, risk analysis) pour évaluer le degré de
préparation de l’organisation à résister aux crises de toutes sortes
(avec et sans prise en compte de la dimension informatique).
»» Les professionnels de la finance se préoccupent à peine de
concepts tels que les sauvegardes et les politiques informatiques,
mais ils se soucient des investissements et des rendements. Cela
implique qu’ils ont tendance à tout voir sous l’angle du coût total
de possession (CTP) et du retour sur investissement (ROI).
Si vous êtes un professionnel de l’informatique capable de traduire les

objectifs opérationnels et l’impact sur les activités en mécanismes
informatiques (et inversement), vous obtiendrez tout ce que vous
CONSEIL demandez pour l’informatique, voire une promotion au-delà du statut
de « simple » professionnel de l’informatique.
La protection des données en chiffres pour les Nuls vous aide à comprendre
chacune des trois langues de la protection des données en chiffres et à
les traduire entre elles.
À propos de ce livre
Pour poursuivre l’analogie avec la pierre de Rosette, ce livre est destiné
à aider les professionnels de l’informatique chargés de la protection des
données à faire preuve d’empathie, à communiquer et, enfin, à collabo-
rer avec les opérationnels et les pros de la finance au sein de leur orga-
nisation. Autrement dit, si vous pouvez traduire les exigences
opérationnelles, telles que le temps d’utilisation et l’impact sur les acti-
vités (en cas de panne des systèmes) en métriques, vous pouvez choisir
objectivement les technologies de protection des données appropriées.
Et si vous traduisez les temps d’arrêt et les pertes de données en réper-
cussions financières, puis quantifiez les économies de coûts ou la nou-
velle valeur perceptible, vous pouvez assumer le coût.
Ce que vous trouverez dans ce livre

Puisque nous comparons ce livre à une pierre de Rosette, vous trouverez
des chapitres sur chacune des trois langues de protection des données.
Chapitre 1 : Métriques techniques :

RPO, RTO et SLA
Le chapitre 1 commence là où la plupart des administrateurs de sauve-
garde et autres professionnels informatiques responsables de la protec-
tion des données doivent commencer, c’est-à-dire par la compréhension
2 La protection des données en chiffres pour les Nuls, édition spéciale Veeam
des temps d’arrêt et des pertes de données. Les RTO et les RPO sont à la
fois les véritables métriques de la protection des données et le moteur
du marketing de la protection des données. Nous allons expliquer com-
ment aborder ce concept en termes pratiques, puis nous concentrer sur
la mise en place de contrats de niveau de service (SLA) pertinents et
réalisables.
Chapitre 2 : Métriques opérationnelles :

RA et BIA
Le chapitre 2 couvre le domaine des experts de la continuité de l’activité
et de la reprise après incident, au service des groupes opérationnels, des
services métier et de la direction. Dans ce chapitre, nous aborderons les
BIA, les RA et « l’art de s’inquiéter ».
Chapitre 3 : Calculer le coût des temps d’arrêt

La mise en pratique d’une traduction des RTO/RPO (capacités) en BIA/
RA (besoins) revient à la capacité de quantifier le coût des temps d’ar-
rêt. Si la plupart des entreprises sous-estiment les fonctions informa-
tiques telles que la sauvegarde, c’est parce qu’elles comprennent peu ce
qu’implique la possibilité ou l’impossibilité de faire une restauration
pour leur organisation. Le chapitre 3 décompose le coût des temps d’ar-
rêt en quatre variables clés. Il donne ensuite un cadre au dialogue qui
peut réunir professionnels de l’informatique et opérationnels pour
adapter la formule générique à une formule qui mesure précisément
l’organisation.
Chapitre 4 : Métriques financières : CTP et ROI

La plupart des informaticiens ne peuvent tout simplement pas choisir
d’acheter une technologie les yeux fermés. Un certain niveau de justifi-
cation est nécessaire pour l’entreprise. Les coûts des solutions à envi-
sager sont tout aussi importants et généralement bien plus élevés que
les prix des composants à prendre en compte. Le chapitre 4 vous aide à
quantifier les coûts associés aux mécanismes de protection des données
(CTP) et à articuler efficacement les avantages comparatifs de la solu-
tion par rapport au coût du problème préalablement quantifié aux cha-
pitres 2 et 3.
Chapitre 5 : Dix clés pour améliorer

vos discussions
Mener une discussion qui concilie les objectifs techniques, opération-
nels et financiers tout en répondant aux objections à chacun d’eux n’est
pas chose aisée. Mettez ces défis en parallèle du lourd « fardeau » que
Introduction 3
représente la sauvegarde, et il y a de quoi être découragé. Le chapitre 5
met en avant dix facettes de ce processus et la construction de passe-
relles pour mener ces discussions plus facilement, ne serait-ce que pour
vous aider à obtenir une meilleure protection des données que vous avez
probablement déjà en ligne de mire.
Icônes utilisées dans ce livre

Des icônes sont utilisées dans ce livre pour vous signaler des éléments
qui méritent une attention particulière. Voici une liste de ces icônes et
leur description :
Certains points méritent d’être répétés, tandis que d’autres méritent

d’être retenus. Lorsque vous voyez cette icône, notez bien ce que vous
allez lire.
RAPPEL
Attention ! Cette information indique les sujets avec lesquels garder de

la distance car ils peuvent vous fragiliser, vous coûter beaucoup d’argent
ou vous faire perdre du temps.
MISE EN
GARDE
Cette icône indique les informations techniques a priori les plus inté
ressantes pour les planificateurs technologiques et les architectes.
INFOS
TECHNIQUES
Si vous voyez l’icône « Conseil », lisez attentivement : vous êtes sur le

point de découvrir comment économiser du temps et éviter des
contrariétés.
CONSEIL
Et maintenant ?
Les professionnels expérimentés de l’informatique savent souvent (par
instinct) qu’ils ont besoin d’une meilleure protection des données que
celle qu’ils utilisent déjà, mais beaucoup ne savent pas comment justi-
fier cet achat et y parvenir. Ce livre a pour but de vous aider à réorienter
le dialogue afin que les trois groupes impliqués s’entendent sur la
nature impérative du problème et la justification d’une meilleure
solution.
DANS CE CHAPITRE
»» Délai optimal de reprise d’activité (RPO)
»» Objectif de temps de restauration (RTO)
»» RPO et RTO sous le même énoncé de
problème
»» Contrat de niveau de service (SLA)
Chapitre 1
Métriques techniques :
RPO, RTO et SLA
L
orsque l’on compare la large gamme de technologies et de métho-
dologies de protection des données, les deux métriques techniques
qui offrent un point de comparaison sont le délai optimal de
reprise d’activité (RPO) et l’objectif de temps de restauration (RTO).
Pour présenter ces termes, prenons un scénario de sauvegarde nocturne
classique, avec une sauvegarde complète effectuée chaque week-end et
une sauvegarde incrémentielle réalisée tous les soirs après le départ des
utilisateurs.
Délai optimal de reprise d’activité

Le sujet du RPO doit être abordé avec les questions suivantes : « Com-
bien de données pouvons-nous nous permettre de perdre ? » et « À
quelle fréquence devrions-nous protéger les données ? » Le RPO peut
vraiment avoir de l’intérêt comme méthode de comparaison objective
des diverses technologies de protection des données et de disponibilité.
Souvent, le RPO est simplement considéré comme la quantité de don-

nées qui peut être perdue. Ce n’est que la partie émergée de l’iceberg,
mais vous pouvez commencer par là. Si vous effectuez une sauvegarde
tous les soirs, en supposant que rien ne se passe mal pendant la sauve-
garde ou la restauration, le maximum de données que vous pouvez
perdre en raison d’une panne informatique correspond à une journée de
données professionnelles. Si vos données sont composées uniquement
de documents Word ou Excel, vous ne perdez alors que les documents
CHAPITRE 1 Métriques techniques : RPO, RTO et SLA 5

qui ont été mis à jour ce jour-là. Si vos données correspondent à des
transactions telles que des dossiers financiers, les conséquences
peuvent être plus graves. Imaginez que vous travaillez dans une insti-
tution financière : au cours d’une journée, la plupart (sinon la totalité)
de vos comptes enregistrent une certaine activité incluant non seule-
ment des dépôts et des retraits, mais aussi des changements de valeur.
Si vous perdez l’équivalent d’une journée de ces transactions, le jeu de
données entier n’est plus valide.
Dans ces conditions, l’essentiel consiste à évaluer le potentiel de perte

de données de deux manières :
»» Le temps passé à recréer les données perdues

»» L’étendue des données qui seront perdues ou touchées
Pour développer ce point, supposons qu’une sauvegarde fiable ait lieu
chaque soir et que les opérations de restauration fonctionnent toujours,
ce qui est déjà une hypothèse hasardeuse. Nous expliquons plus loin
dans ce chapitre pourquoi cette hypothèse ne se vérifie pas en général.
Cependant, pour le moment, celle-ci nous sera utile pour l’exemple. En
gardant cela à l’esprit, prenons ces deux scénarios extrêmes :
»» Si le serveur venait à tomber en panne en début de jour

ouvrable, presque aucune donnée ne serait perdue depuis la der-
nière sauvegarde. La perte de données réelle avoisinerait zéro, car
presque rien n’aurait changé depuis le dernier point de restauration
ou événement de sauvegarde.
»» Si le serveur venait à tomber en panne à la fin du jour ouvrable,
toute la journée de données serait perdue, car aucune sauvegarde
(point de restauration) n’aura été créée depuis minuit la veille. La
perte de données serait équivalente à une journée entière.
Si vous faites la moyenne de ces deux situations extrêmes, vous pouvez

conclure que le serveur tombera toujours en panne à midi, soit au milieu du
jour ouvrable. D’un point de vue statistique, les entreprises qui
CONSEIL dépendent uniquement de la sauvegarde nocturne perdront en moyenne
la moitié d’une journée de données.
UN SERVEUR RESTE UN SERVEUR

Dans cet ouvrage, serveur désigne une plateforme physique, virtuelle ou
basée sur le cloud qui héberge des données afin de fournir des services
informatiques. Selon les analystes du secteur, 52 % des pannes informa-
tiques dans un datacenter proviennent d’un problème matériel. Aupara-
vant, cela correspondait à un seul serveur (physique) touché, mais
aujourd’hui la grande majorité de l’infrastructure physique prend en
charge la virtualisation, où 20 machines virtuelles (VM) peuvent se trou-
ver au sein d’un seul hôte physique, aggravant ainsi l’impact des temps
d’arrêt de manière exponentielle.
De fait, bien qu’il soit facile de déduire que les VM individuelles (sur site
ou sur cloud) ne souffriront pas de problèmes matériels individuels, le
risque que leur hôte rencontre un problème physique est beaucoup plus
important.
Pour comprendre tout l’enjeu du RPO, il faut se pencher en priorité sur

la définition de son O. Le RPO est un objectif (ou but). Il définit la quan-
tité de données que vous êtes prêt à perdre. Avec une sauvegarde noc-
turne, il est statistiquement probable que vous perdiez une demi-journée
de données. Mais si vous définissez votre RPO en milieu de journée et
que votre serveur tombe en panne l’après-midi, vous avez en réalité
perdu plus de données que prévu, ce qui vous éloigne de votre but ou
objectif. En réalité, cet objectif ne sera pas atteint près de la moitié du
temps. Ainsi, un RPO d’un jour sera le plus souvent défini, ce qui signi-
fie qu’une perte de données d’une journée entière est acceptable pour
l’entreprise dans la mesure où elle prend en compte que les sauvegardes
ont lieu uniquement la nuit.
Dans le cas d’une sauvegarde nocturne, l’unité de mesure pour le RPO

est exprimée en jours (par exemple, demi-journée ou journée com-
plète), car les opérations de sauvegarde se déroulent normalement quo-
tidiennement ou, plus précisément, toutes les nuits. Pour obtenir un
RPO (un but) adapté à la quantité de données que vous pouvez vous
permettre de perdre avec un ordre de grandeur inférieur à des jours, vous
devez protéger les données à une fréquence plus élevée que chaque nuit.
Cela exclut généralement de l’équation les sauvegardes seules et, par
association, les solutions uniquement sur bande. Les solutions basées
sur disque se répètent souvent toutes les heures, toutes les quelques
minutes ou secondes ou en temps réel. Le RPO devient essentiellement
la mesure de la fréquence de protection des données, quel que soit le
choix du support.
Dans le présent ouvrage, les trois mécanismes de protection des don-

nées les plus courants sont définis comme suit :
RAPPEL »» Sauvegarde : il s’agit d’une copie ponctuelle des données qui est
stockée sur le disque secondaire, les bandes ou dans le cloud afin de
conserver des versions antérieures. Les sauvegardes sont générale-
ment créées quotidiennement ou à une fréquence plus faible, elles
sont compressées ou dédupliquées pour économiser de l’espace au

fil du temps et sont généralement stockées pendant des mois ou des
années.
»» Snapshot : c’est un point dans le temps relativement récent repo-
sant sur une série de blocs dans le système de stockage de produc-
tion. Les snapshots peuvent être créés à intervalle de quelques
minutes ou heures, sont composés de pointeurs vers des modifica-
tions au niveau des blocs et sont généralement conservés dans le
système de stockage principal pendant quelques jours seulement.
»» Réplica : il s’agit d’une copie actuelle ou quasi actuelle de données
dans leur format original, mais se trouvant dans un autre emplace-
ment (par exemple hors site pour la continuité de l’activité/reprise
après incident). La réplication peut se produire en temps réel (syn-
chrone), en différé (asynchrone) ou selon un horaire récurrent, géné-
ralement mesuré en minutes ou en heures. À chaque étape, la copie
secondaire est remplacée par tout ce qui a changé par rapport à la
source d’origine.
Vous remarquerez que ces trois mécanismes de protection des données

se complètent et sont souvent utilisés ensemble (et doivent l’être).
Objectif de temps de restauration

Il faut aborder le RTO en commençant par se poser la question « Pen-
dant combien de temps pouvons-nous nous permettre de ne pas dispo-
ser de nos données ? », une question qui peut également être posée de
la manière suivante : « Pendant combien de temps nos services
peuvent-ils rester hors service ? » En suivant le même scénario de sau-
vegarde nocturne que dans la section précédente, le « délai optimal de
reprise d’activité », le RTO, est le but (objectif) à atteindre en termes de
temps nécessaire pour effectuer la restauration. La première question
est : « Combien de temps va prendre la restauration ? »
Dans l’exemple de sauvegarde nocturne précédent, le RPO est mesuré

en jours ou en jours partiels, car c’est la fréquence à laquelle un événe-
ment de protection des données (sauvegarde) se produit, soit chaque
nuit. Mais pour ce même exemple, le RTO est mesuré en heures, car il
s’agit d’une mesure de performance des composants de votre solution
elle-même. Si votre logiciel de sauvegarde et votre stockage secondaire
peuvent restaurer jusqu’à 2 téraoctets (To) par heure et que le serveur
de production dispose de 6 To de données, le temps de restauration des
données est d’environ 3 heures ou, plus précisément, 3 heures à partir
du démarrage de la fonction de restauration.
Si votre plus gros serveur contient 10 To de données et que votre stoc-
kage de protection peut restaurer 2 To par heure, et si vous êtes sûr de
pouvoir localiser immédiatement les bonnes bandes et que la restaura-
tion peut commencer peu après, alors vous êtes en mesure de définir un
RTO de 5 heures, ou 6 heures par précaution. Mais vous perdrez égale-
ment du temps entre le moment où la panne se produit et le moment où
vous lancez le processus de restauration (avec ou sans temps de dia-
gnostic sur le serveur d’origine). Par conséquent, vous définirez et
arrondirez probablement le RTO à une journée.
Pour vous aider à comprendre à quoi ressemblent les objectifs de

RTO réels, les études du secteur suggèrent que près de la moitié de tous
les serveurs aient un objectif de RTO inférieur à 15 minutes. (Voir la
figure 1-1).
Près de sept serveurs sur huit ont un RTO de six heures ou moins, ce qui,
Pourcentage de serveurs/services de production

RAPPEL
rentrant dans le cadre des RTO cibles des SLA
En tenant compte de toutes les applications de production/workloads de votre organisation
(y compris les workloads « haute priorité » et « normaux »), quel pourcentage environ de ces
serveurs/services de production rentre dans chacun des temps de restauration indiqués
ci-dessous (c.-à-d. le temps de restauration cible ou « souhaité » RTO/SLA par rapport à ce
que votre organisation a réellement fourni) ? (Moyenne, N=320)
46% < 15 minutes 74% < deux heures 88% < six heures
24% 22%
18%
10% 9%
5% 4% 4% 4%
Aucun Moins de De De De De De De 12 à Plus de

temps 15 minutes 15 minutes 1 heure 2 heures 4 heures 6 heures 24 heures 24 heures
d’arrêt à moins à moins de à moins de à moins de à moins de
d'une heure 2 heures 4 heures 6 heures 12 heures
Source : ESG Real World SLA and Availability Methods, décembre 2017
FIGURE 1-1 : Comment les temps de restauration s’accumulent.
selon les exemples précédents de ce chapitre, exclut une approche repo-

sant seulement sur les sauvegardes pour protéger des données. À la
place, près de la moitié des jeux de données de tous les serveurs com-
plètent les sauvegardes avec la réplication, et un tiers avec des snapshots.
Allier le RPO et le RTO

Mettons maintenant en commun les exemples vus dans ce chapitre.
Supposons que le serveur protégé dans ce scénario a subi une panne

mercredi à 16 h. Restaurer le serveur prendra la majeure partie de la
journée suivante. Si le personnel informatique est dans le même bureau,

vous pouvez de façon optimiste identifier ce qui a causé l’incident et, si
nécessaire, prendre des dispositions pour que les pièces de rechange
arrivent tôt jeudi matin. Le jeudi, le serveur sera réparé et les données
seront restaurées. D’ici jeudi soir, le serveur sera rétabli et fonctionnera
normalement. Le temps de restauration sera d’un jour ouvrable et (vous
l’espérez) correspondra au RTO.
Les conséquences négatives de ce scénario sont doubles pour les

utilisateurs :
»» Le jeudi est une journée perdue pour les utilisateurs, car ils ne
peuvent pas accéder à leurs données pendant le dépannage, le rem-
placement des pièces et la restauration.
»» Les données de mercredi sont probablement perdues, car le serveur,
quand il est restauré, le sera avec la dernière sauvegarde réussie
(celle du mardi soir). Tout ce qui a été créé le mercredi (après la sau-
vegarde du mardi) aura probablement été perdu lorsque le stockage
du serveur a échoué. Le point de restauration se trouvait à moins
d’un jour des données perdues (du mardi minuit au mercredi au
moment de la panne), ce qui correspond à nouveau, vous l’espérez,
au RPO défini.
Pour améliorer le RPO, vous devez procéder à la protection des données

à une fréquence plus élevée que tous les soirs. Pour ce faire, vous devez
vous tourner vers les mécanismes de réplication et de snapshot en com-
RAPPEL plément des sauvegardes (et non en remplacement).
Pour améliorer le RTO, vous devez disposer d’un support de restaura

tion plus rapide, qui sous-entend généralement un disque au lieu d’une
bande ou du cloud pour les opérations de restauration de routine. De
RAPPEL plus, la fréquence de protection peut également diminuer le RTO, car la
quantité de données à restaurer diminue à chaque itération.
Mais il ne suffit pas de mesurer le RPO et le RTO. Vous devez traduire les
capacités de RPO et de RTO de votre solution en élément prévisible qui
peut être compris et accepté par vos interlocuteurs commerciaux et
opérationnels dans l’entreprise. Vous devez mettre en place un accord
de service (SLA), comme décrit dans la section suivante.
Réaliser le RPO et le RTO avec le SLA

Lorsque vous aurez assimilé que le O dans les termes RPO et RTO désigne
l’objectif, vous rencontrerez l’un des principaux problèmes auquel nous
faisons face dans la plupart des plans de protection des données et de
MISE EN disponibilité. Un objectif est un but, non une promesse. La promesse
GARDE
tient à présenter vos capacités aux parties prenantes de l’entreprise, par
exemple en disant aux responsables des personnes qui dépendent du
serveur que tout « fonctionnera à nouveau dans un délai d’un jour
ouvrable et qu’il y aura une perte moyenne d’une demi-journée de don-
nées, mais potentiellement d’une journée entière de données ». Vous
pourriez dire à l’équipe de direction qu’avec une sauvegarde nocturne,
vous pourriez avoir un RPO d’une demi-journée de données perdues et
que le RTO pourrait être d’un jour ouvrable afin de réparer le serveur et
restaurer les données. Il s’agit cependant de buts basés sur des circons-
tances idéales.
Que se passe-t-il lorsque les circonstances ne sont pas idéales ? Dans le

scénario décrit impliquant la sauvegarde nocturne d’un serveur en
panne, nous émettons quelques hypothèses :
»» Vous pouvez réagir rapidement à la panne du serveur.

Si vous avez du personnel informatique sur place, il peut identifier
le problème presque immédiatement.
Si vous ne disposez pas de personnel informatique sur place,
toute la fenêtre de restauration sera plus longue, car rien ne peut
se passer tant que vous n’êtes pas sur place (ou connecté à
distance).
»» Le serveur est facilement réparable. Dans l’exemple, le serveur est
tombé en panne mercredi à 16 h.
Si des pièces sont disponibles, les réparations peuvent commen-
cer immédiatement.
Si vous vous trouvez sur la côte est des États-Unis, vous pouvez
commander les pièces auprès d’un fournisseur de la côte ouest
qui vous les enverra pendant votre nuit, et les réparations pour-
ront commencer le lendemain matin.
Si vous vous trouvez aussi sur la côte ouest des États-Unis, il fau-
dra peut-être un jour ouvrable de plus pour obtenir les pièces et
par conséquent, toutes les autres opérations prendront plus de
temps.
»» Chaque point de restauration (sur disque, bande ou cloud) est lisible.
Si la dernière sauvegarde de mardi soir est corrompue, vous ne
pourrez la restaurer que par l’intermédiaire de la copie de lundi.
Vous aurez perdu un autre jour de données (RPO) et vous perdrez
probablement du temps à essayer de restaurer les données de
mardi avant de pouvoir identifier la panne (RTO plus long).
Si vous effectuez des sauvegardes incrémentielles (uniquement
des modifications nocturnes) au lieu de sauvegardes différen-
tielles et que les données de lundi sont mauvaises, les données de
mardi seront pour la plupart non pertinentes. Les sauvegardes

incrémentielles de mardi contiennent les changements effectués
entre lundi et mardi. Sans une restauration réussie des données
de lundi, les changements de mardi peuvent être insignifiants.
Cela varie en fonction de la charge de production (ainsi que de la
tolérance du logiciel de sauvegarde pour les points de restauration
défectueux au sein de l’emplacement de stockage cible).
Si l’une des sauvegardes complètes du week-end est mauvaise,
alors celle du lundi et celle du mardi ne sont pas pertinentes, car
tout dépend de la dernière sauvegarde complète (qui est
inutilisable).
Ce n’est pas la meilleure des solutions, mais nous pouvons donner deux
scénarios de restauration de dernier recours :
»» Si les données incrémentielles quotidiennes ne sont pas écrasées

chaque semaine (c’est-à-dire que celles de ce mardi remplacent celles
de mardi dernier), vous pouvez restaurer la sauvegarde complète
d’une semaine plus tôt, puis les données incrémentielles ou différen-
tielles de la semaine précédente. En somme, lorsque le serveur est
réparé le jeudi après-midi (et qu’on y accède le vendredi matin), les
données seront telles qu’elles étaient le jeudi de la semaine précé-
dente, la dernière bonne copie.
»» Si les sauvegardes quotidiennes sont écrasées, les données ne seront
restaurées que pour la sauvegarde complète de la semaine précé-
dente. Toutes les données de la semaine précédente, ainsi que du
début de la semaine en cours, seront perdues (10 jours de données
dans cet exemple).
Ce ne sont pas des cas rares, ni un enchaînement catastrophique d’er-

reurs. Il ne s’agit que d’exemples qui montrent combien la réalité peut
facilement ne pas correspondre aux RPO et RTO idéaux définis par le
matériel et le logiciel de la solution de protection des données. C’est pour
ces raisons (lorsque la réalité ne correspond pas au RPO et au RTO
idéaux) que le SLA, l’assurance de vos capacités de restauration auprès
des unités commerciales, ne doit pas se limiter à la simple évocation du
RPO et du RTO des technologies elles-mêmes.
Vous devez prendre en compte les processus et les pièges potentiels de

la (des) solution(s) technique(s) et des processus de restauration que
vous envisagez :
RAPPEL
»» Temps de réaction : les sites sans personnel informatique doivent
inclure des RTO plus longs que ceux des sites avec personnel infor-
matique dans leur SLA, car ils doivent prendre en compte le temps
nécessaire pour se rendre sur place, ainsi que l’agencement, la
connectivité et le type de panne. Peut-être que le personnel
informatique peut se rendre en voiture ou en avion au site distant
depuis son site principal. Peut-être qu’un intégrateur local ou un
revendeur intermédiaire peut être dépêché. Dans quel cas, la mise
en place d’un contrat pré-négocié peut être nécessaire, avec un SLA
qui engage ce prestataire envers vous en termes de taux de réponse
à votre panne.
»» Temps de réparation : faut-il se procurer des pièces détachées ou
même des serveurs complets de secours différé ? D’où les pièces ou
serveurs peuvent-ils être expédiés ? Un contrat pré-négocié doit-il
être signé entre vous et un fournisseur ou un distributeur ?
»» RPO et RTO techniques : ceux-ci portent sur des questions concer-
nant le RPO et le RTO, ainsi que sur le taux de défaillance perçu des
supports.
Vous noterez que la technologie n’est mentionnée que pour le dernier

élément. Les premiers aspects d’un SLA de restauration de serveur
concernent les personnes et le processus, suivis par le matériel et l’ac-
cès. Dès que vous attaquez la partie technologique, vous serez proba-
blement davantage dans la zone de confort du professionnel de
l’informatique, même s’il reste des inconnues concernant la technolo-
gie. Ceci étant dit, une fois que le serveur est prêt à être restauré, le RTO
varie toujours selon que vous effectuez la restauration à partir du lundi
ou du vendredi :
»» Imaginez que vous commencez avec une sauvegarde complète, ce

qui implique une copie complète et autonome des données chaque
week-end.
»» Avec les sauvegardes différentielles, vous commencez par la sauve-
garde complète et ensuite vous superposez la sauvegarde différen-
tielle du jeudi soir (les changements depuis la dernière sauvegarde
complète). Mais une sauvegarde différentielle du jeudi aura sensible-
ment plus de données à restaurer que la sauvegarde différentielle
du lundi.
»» Avec les sauvegardes incrémentielles, vous voyez une augmentation
linéaire similaire du temps de restauration, car chaque sauvegarde
incrémentielle suivante est superposée sur la sauvegarde incrémen-
tielle précédente : du lundi au mardi, du mardi au mercredi, etc. Mal-
heureusement, dans ce monde imparfait, si un point de restauration
(sur bande, disque ou cloud) échoue, tout comme la sauvegarde
incrémentielle du mardi, alors les sauvegardes incrémentielles du
mercredi et du jeudi pourraient être inutilisables.
Tous ces exemples désastreux et peu encourageants sont simplement

présentés pour vous inciter à comparer les RPO et RTO présumés de

votre technologie de protection des données avec les mesures que vous,
en tant que professionnel de l’informatique responsable de la protection
des données, pouvez garantir à votre direction.
Voici le secret d’un SLA réussi : c’est ce que les commerciaux appellent une
tactique dilatoire, c’est-à-dire que ce que vous prévoyez de vendre est
inférieur à vos estimations. D’autres pourraient qualifier cette méthode
CONSEIL de sous-promesse et de surproduction. En tant que consultant et ingé-
nieur qui implémente l’informatique, j’appelle cela faire des plans pour
contrer la loi de Murphy.
Lorsque vous élaborez vos propres SLA, ne vous fiez pas aux RPO et RTO
indiqués sur le boîtier des technologies qui vous intéressent. Et surtout,
ne communiquez pas les RPO et RTO aux responsables de l’entreprise.
CONSEIL Faites le test. Partez du principe que quelque chose va mal se passer et
réfléchissez à la manière dont vous traiteriez les problèmes qui en
découlent. (Allez-y : poussez la réflexion jusqu’au bout et supposez que
tout va mal se passer, puis négociez avec les responsables de l’entreprise
dans des conditions réelles !)
LES SLA SONT AUTANT UN ART QU’UNE SCIENCE

Les SLA relèvent parfois plus de l’art que de la science, car pour obtenir
de bons SLA qui satisfont le personnel informatique et la direction de
l’entreprise, il faut une planification créative, généralement par des per-
sonnes qui ont déjà fait face à une panne informatique. L’équilibre doit
être trouvé entre deux types de perspectives :
• Si l’équipe informatique est trop prudente, elle peut fixer la barre

de performance du SLA à un niveau si bas que l’équipe de direction de
l’entreprise estime que le personnel informatique manque de
connaissance et de performance.
• Si l’équipe informatique est trop optimiste ou ambitieuse, la
barre de performance du SLA peut être si haute que même des res-
taurations bien exécutées risquent de ne pas respecter la mesure
définie dans le SLA.
Lorsque vous négociez votre SLA informatique avec les dirigeants de l’en-
treprise, pensez d’abord à animer une séance de réflexion avec vos
supérieurs informatiques pour définir les plans de restauration : identi-
fiez les éléments provoquant d’éventuelles pannes et vos mesures d’atté-
nuation lorsque le plan ne fonctionne pas. Ce n’est qu’une fois que vous
aurez mis en œuvre ce flux de travail que vous devrez parler des SLA aux
responsables de l’entreprise.
DANS CE CHAPITRE
»» Analyse des risques (RA)
»» Analyse d’impact sur les activités (BIA)
Chapitre 2
Métriques opération-
nelles : RA et BIA
L
e chapitre 1 présente certaines des métriques à votre disposition
pour évaluer vos technologies de protection des données. Ce cha-
pitre analyse dans quelle mesure vous pouvez utiliser ces métriques
dans un contexte opérationnel. Vous verrez comment les appliquer à
l’entreprise et comment payer les technologies que vous estimez
nécessaires.
Analyse des risques : l’art de s’inquiéter

Quelle est la probabilité qu’un problème survienne avec votre solution
de sauvegarde spécifique ?
Plus important encore, quels sont les risques que votre ressource de
production rencontre un dysfonctionnement ? Prenons l’exemple de
ma maison à Dallas au Texas. Quels sont les risques qu’il s’y produise
une inondation ? Une mousson ? Un tremblement de terre ? Ou encore
une tornade ?
Arrêtons-nous sur cette dernière question pour écarter la technologie

du processus. Il se trouve que je vis à Dallas, au Texas, à environ 650 km
de la grande étendue d’eau la plus proche, le golfe du Mexique. C’est
pour cette raison que je ne crains pas une mousson. Statistiquement
parlant, la probabilité que Dallas soit frappée par une mousson est en
CHAPITRE 2 Métriques opérationnelles : RA et BIA 15

fait nulle. En parlant d’eau, ma maison se trouve sur une plaine cente-
naire inondable, donc, statistiquement, mes terres seront inondées une
fois par siècle. Je pourrais me procurer une assurance inondation pour
ma maison, mais la probabilité est suffisamment faible pour que je
choisisse de ne pas le faire. Si je vivais à Houston, au Texas, qui est
beaucoup plus proche de la côte et où les inondations sont plus pro-
bables, j’envisagerais une assurance inondation. Cependant, comme la
probabilité est beaucoup plus élevée, je ne pourrais probablement pas
me le permettre, car les assureurs auront déjà intégré cette condition
dans les calculs de primes éventuelles.
Cet exemple est pertinent dans notre réflexion. L’assurance est un sec-
teur entier fondé sur le fait que les clients présument payer un peu
chaque mois afin d’éviter un impact financier potentiellement impor-
tant qui pourrait bouleverser leur vie par la suite. Le montant de l’assu-
rance versé dépend principalement de deux facteurs :
»» Quelle est la probabilité que la crise que vous anticipez se produise ?

»» Quel est l’impact financier que vous souhaitez atténuer ?
Des concepts tels que la protection et la disponibilité des données sont
similaires à l’idée d’une souscription à une assurance. Tout d’abord,
vous évaluez ce qui pourrait aller mal et estimez combien cela vous coû-
RAPPEL terait, puis vous payez quelque chose qui coûte sensiblement moins
cher que le moyen d’atténuer la crise.
Qu’est-ce qui pourrait alors mal tourner ?

La première étape de la planification de votre stratégie de protection et
de disponibilité des données consiste à examiner chacun des serveurs et
applications de votre environnement et de réfléchir à ce qui pourrait
mal se passer, dans le cadre de ce que l’on appelle formellement une
analyse des risques (RA).
Soyons fous : pensez à tout ce qui pourrait mal se passer. La règle la plus
importante dans cet exercice est de simplement énumérer toutes les
choses qui pourraient aller mal. Ne pensez pas (encore) à la probabilité
que quelque chose se produise, mais seulement à la possibilité que cela se
produise. N’hésitez pas à voir les choses en grand mais aussi au
microscope.
Dans le cas d’une application sur laquelle l’organisation s’appuie, vous

ne pouvez pas vous contenter de prendre en compte l’application elle-
même. Un utilisateur final ne se demande pas pourquoi il ne peut pas
RAPPEL accéder à ses données, car peu lui importe que l’application ait planté,
que le système d’exploitation ne réponde plus, que le disque dur ait
rencontré une panne, que le serveur DNS ne résolve pas les problèmes
correctement, qu’Active Directory ne laisse personne se connecter ou
que le navigateur ne lise pas la page correctement. Les utilisateurs ne
s’en soucient pas, puisque leurs données et leur productivité sont tou-
chées quelle qu’en soit la cause.
C’est le point de vue de l’utilisateur. Maintenant, réfléchissez aux pro-

blèmes importants. Votre entreprise est-elle dans une zone inondable ?
Si vous vous situez dans le sud de la Californie, êtes-vous près d’une
forêt exposée à des risques d’incendie ? Si vous vous situez dans le nord
de la Californie, quelles seraient les conséquences d’un tremblement de
terre ? Si vous êtes dans le Midwest, êtes-vous dans une zone exposée
aux tornades ? Plus au nord, quelles seraient les conséquences d’un
blizzard ? Sur la côte est, quelle est la probabilité d’un ouragan ? Si vous
vivez en Floride, vous vous demandez quand il va arriver et non s’il va se
produire.
Voici un exemple réel : il y a plusieurs années, je dirigeais un séminaire

sur la reprise après incident dans une ville de Floride. Mon mot d’ou-
verture était le suivant : « Selon le National Weather Service, cette ville
CONSEIL est dans l’œil d’un cyclone tous les 2,83 ans. Cela fait 3 ans que vous
n’avez pas été touchés. Vous avez du retard. » Mon conseil ? Soyez très
conscients des catastrophes potentielles auxquelles vous pourriez faire
face. Ne vous imaginez pas que, simplement parce qu’une situation ne
s’est pas encore produite, elle ne se produira pas.
Quelle est la probabilité ?

Je ne suggère pas que chaque professionnel de l’informatique se conver-
tisse en assureur dont le quotidien consiste à côtoyer les statistiques des
risques. Ce que je suggère, c’est que lorsque vous réfléchissez pour la
première fois à tous les désagréments qui pourraient arriver à vos don-
nées, serveurs, infrastructures et même aux personnes, commencez par
en faire la liste. Ensuite, après cette étape, armez-vous de sens pratique
et envisagez la probabilité raisonnable de chacun d’entre eux. Si je ne
souscris pas une assurance inondation, c’est parce qu’une inondation,
bien que possible, n’est pas probable là où je vis. Je ne peux pas sous-
crire une assurance contre la grêle à un prix raisonnable, car il est qua-
siment certain que cela m’arrivera.
Dans le domaine de la technologie, certaines catastrophes sont

inévitables :
»» Vous perdrez des disques durs.

»» Vous rencontrerez des pannes des cartes système.

»» Des applications vont planter.
»» Des bases de données seront corrompues.
»» Des utilisateurs écraseront accidentellement les données du mois
dernier avec les données de ce mois-ci et le regretteront ensuite.
Dans le monde de l’entreprise, certaines crises sont susceptibles de se

produire :
»» Quelqu’un peut voler du matériel appartenant à votre entreprise,

généralement un ordinateur portable.
»» Quelqu’un peut supprimer des données de manière malveillante
lors de son dernier jour de travail.
»» La salle des serveurs peut prendre feu ou être inondée à cause des
toilettes se trouvant juste au-dessus.
Dans la vie, les catastrophes naturelles peuvent affecter les installations

de votre entreprise.
Quelle est donc la probabilité de chaque événement de la liste ? Vous

n’avez peut-être pas de chiffres exacts, mais compilez les types d’élé-
ments contre lesquels vous vous protégez selon une probabilité relative
des uns par rapport aux autres. Cet exercice d’analyse des risques (RA)
n’est que la moitié du chemin que vous devez parcourir pour commen-
cer à planifier votre plan de protection des données et de disponibilité.
Analyse d’impact sur les activités :

combien cela coûtera-t-il ?
La protection des données et la disponibilité ne sont pas qu’une affaire
de technologie. En réalité, les deux tendent principalement à réduire
l’impact financier. Pour ce faire, il faut non seulement vous pencher sur
RAPPEL les technologies que vous pouvez utiliser et les conséquences néfastes
que vous craignez, mais aussi toutes les traduire en ramifications
financières.
Jetons un œil sur les crises technologiques et commerciales potentielles

énumérées dans la section précédente. Elles sont classées, de façon
approximative, en allant de la plus probable à la moins probable, à l’ex-
ception des utilisateurs finaux qui écrasent accidentellement des don-
nées précieuses (je vous garantis que des utilisateurs écraseront des
données). Examinons les deux extrémités de la liste. Tous les autres
éléments se classent entre elles, tant du point de vue de la probabilité
que de l’impact financier :
»» Scénario 1 : si je perds un disque dur dans un équipement de pro-
duction, les coûts physiques seront probablement à hauteur de
quelques centaines de dollars ou moins. Le niveau de productivité
perdue dépendra de l’utilisation du disque dur perdu, selon qu’il sert
de lecteur de données ou au système d’exploitation, et sera aggravé
par le nombre d’utilisateurs affectés. Par ailleurs, le temps écoulé
depuis la dernière sauvegarde déterminera la quantité de données
perdues que je pourrais avoir à recréer.
»» Scénario 2 : à l’autre extrémité de la liste, si mon installation de pro-
duction est inondée, toute la salle des serveurs, ainsi que de nom-
breuses autres ressources de production, ordinateurs de bureau,
composants d’infrastructure et même des photocopieuses et des
cafetières seront détruits. Mon activité peut se retrouver à l’arrêt
pendant des jours et, d’ailleurs, ne jamais repartir.
L’objectif d’une analyse d’impact sur les activités (BIA) est de quantifier
financièrement le coût de chaque type de crise. Partons du principe que
vous calculez le coût total d’une panne de disque dur, d’une perte de
CONSEIL productivité et du remplacement du disque à 1 000 $. Vous estimez qu’il
s’agit d’un événement très probable, donc vous devez chercher active-
ment une solution de protection des données ou de disponibilité qui
atténue cet impact de 1 000 $ pour l’entreprise en trouvant une solution
d’atténuation qui coûte moins de 1 000 $ et même, espérons-le, beau-
coup moins. De même, bien que vous estimiez qu’une inondation vous
coûterait 3 millions de dollars, il est vrai qu’elle est beaucoup moins
probable qu’une panne de disque dur. Cette probabilité statistique per-
met de déterminer ce que vous pourriez dépenser pour atténuer ce
risque.
Toujours convertir les technologies en argent

Le plus souvent, la personne qui remplit les chèques, en particulier les
chèques pour l’achat de nouveaux actifs comme les logiciels et le maté-
riel, ne se soucie pas des RPO et RTO ou des associations sauve-
gardes-snapshots ou disque-bande-cloud. En matière de projet de
protection des données, pour faire avancer les décideurs qui donnent la
priorité aux affaires, quantifiez toujours le risque ou le gain en argent,
et non en téraoctets, minutes ou évaluations subjectives.
Les projets de protection des données et de disponibilité comptent

parmi les sujets les plus faciles à présenter en termes financiers. La dis-
ponibilité ou, en d’autres termes, la productivité, peut être calculée en
tenant compte du coût des temps d’arrêt. La protection et la restaura-
tion peuvent être quantifiées en fonction de l’impact des données

perdues, car elles sont liées non seulement à une perte de productivité,
mais également à l’incapacité de respecter les mandats de conformité
réglementaires applicables.
En résumé, si vous pouvez affirmer objectivement qu’une heure de

temps d’arrêt équivaut à 10 000 $ et que la solution coûte 800 $, alors il
est facile de justifier de nouvelles solutions de protection des données
ou de disponibilité.
Le chapitre 3 traite précisément de ce sujet : Comment calculer le coût

des temps d’arrêt.
DANS CE CHAPITRE
»» Analyser les impacts intangibles des
temps d’arrêt et des pertes de données
»» Calculer le coût des temps d’arrêt à l’aide
de quatre variables simples
»» Mettre en pratique la formule du coût
des temps d’arrêt
»» Adapter la formule du coût des temps
d’arrêt à votre entreprise
Chapitre 3
Calculer le coût des
temps d’arrêt
T
out le monde « sait » que les temps d’arrêt et les pertes de don-
nées sont nuisibles, mais la plupart des gens ne savent pas com-
ment les quantifier. La Figure 3-1 montre les études du secteur
sur les principales préoccupations des cadres supérieurs en ce qui
concerne les temps d’arrêt et les pertes de données.
Malgré tout, vous êtes en mesure de quantifier en partie l’impact de

sorte à faire le lien entre l’argument des circonstances techniques et
celui des réalités opérationnelles.
CHAPITRE 3 Calculer le coût des temps d’arrêt 21

Impact résultant du temps d'arrêt des applications ou de la perte de données
Parmi les impacts suivants, lesquels votre entreprise peut-elle subir en raison
des temps d'arrêt des applications ou des pertes de données ?
Quels impacts sont les plus inquiétants selon vous ?
(En pourcentage de répondants, N = 320)
Perte de confiance des clients 16%
51%
Perte directe de chiffre d’affaires 23%
46%
Opportunités commerciales manquées 11%
41%
Perte de confiance des salariés 9%
41%
Atteinte à l’intégrité de la marque 8%
37%
Détournement des ressources des projets 9%
à long terme ou des projets stratégiques 33%
Conséquences juridiques 8%
28%
Retrait de certifications administratives 7%
ou sectorielles 21%
Chute du cours de l’action 2% Conséquences possibles
13%
les plus préoccupantes
Autre 6%
2% Toutes conséquences
Ne sait pas 6% possibles des temps
2% d’arrêt/pertes de données
Source : ESG Real World SLA and Availability Methods, décembre 2017
FIGURE 3-1 : Impacts intangibles des temps d’arrêt.
Zoom sur quatre variables simples

Lors de la quantification des coûts des temps d’arrêt, le principe consiste
à savoir comment convertir les problèmes technologiques en problèmes
financiers. Si vous pouvez quantifier financièrement l’impact d’un évé-
nement sur l’entreprise, vous aurez un tout autre dialogue avec les diri-
geants de l’entreprise (et responsables du budget) sur les raisons pour
lesquelles vous devez le résoudre. Pour entamer cette discussion, vous
devez comprendre le coût des temps d’arrêt. En d’autres termes, quand
un serveur tombe en panne, quel en est le coût pour l’entreprise ?
Si un serveur tombe en panne, vous devez regarder le passé et l’avenir

pour calculer l’impact. La Figure 3-2 montre un serveur qui tombe en
panne à 14 h un mercredi.
RAPPEL
Dans ce premier exemple, vous formulez ces trois hypothèses :
»» Le jour ouvrable s’étend exactement de 8 h à 17 h.

»» Vous disposez d’une sauvegarde restaurable datant de mardi soir.
»» Le serveur sera réparé d’ici la fin du jour ouvrable suivant (jeudi).
Mardi Mercredi Jeudi Vendredi
Données
perdues Temps de restauration
Panne
du serveur
FIGURE 3-2 : Temps d’arrêt, avant et après.
En gardant ces hypothèses à l’esprit, deux types de durées peuvent être

quantifiés : le temps de données perdues et le temps d’arrêt. Les sec-
tions suivantes examinent ces deux éléments plus en détail.
Données perdues
Si un serveur tombe en panne, toute nouvelle donnée depuis la dernière
sauvegarde restaurable est potentiellement perdue. Étant donné que le
serveur est tombé en panne à 14 h mercredi et que vous prenez en
compte une restauration fiable à partir d’une sauvegarde réussie mardi
soir, vous pouvez supposer que vous perdrez toutes les données qui ont
été modifiées entre 8 h et 14 h mercredi.
Dans la Figure 3-2, la flèche part du moment où la panne du serveur

s’est produite et pointe vers la gauche jusqu’à la dernière sauvegarde
réussie qui peut être restaurée de manière fiable, celle de la soirée pré-
cédente dans ce cas donné.
Si la dernière sauvegarde a échoué ou n’a pas pu être restaurée, la flèche

pointera vers la gauche jusqu’à ce qu’une sauvegarde réussie puisse être
restaurée. Toutefois, pour le moment, la perte de données correspond à
six heures ouvrables. Par conséquent, la formule se présente de la
manière suivante :
Td = Temps de données perdues, qui est de six heures dans ce cas
Vous quantifiez les données perdues avec une mesure de temps, car
dans l’exemple de base, vous supposez que si les utilisateurs finaux ont
mis six heures à créer les données à l’origine, ils auront besoin proba-
RAPPEL blement d’environ six heures supplémentaires de temps de travail pour
recréer les données.

Temps de panne
Comme le serveur est tombé en panne l’après-midi, vous supposez que
les utilisateurs finaux seront inactifs pour le reste de la journée et (dans
l’exemple) inactifs pendant tout le jour ouvrable suivant.
Dans la Figure 3-2, cette flèche part du moment où la panne du serveur

s’est produite et pointe vers la droite jusqu’à ce que le serveur soit com-
plètement remis en ligne, ce qui dans l’exemple correspond à la fin du
jour ouvrable suivant. Si c’est le cas, le temps de panne correspond aux
trois heures restantes du mercredi après-midi plus les neuf heures
ouvrables du jeudi. La formule se présente donc ainsi :
Tp = Temps de panne ou de perte de productivité, qui est de

12 heures dans l’exemple
On peut donc additionner ensemble, Tp + Td = 12 + 6. Et conclure que

l’impact total sur le temps de la panne du serveur est de 18 heures.
Maintenant, vous devez déterminer la valeur de ces 18 heures en argent.

Encore une fois, il y a deux types de coûts horaires à prendre en compte :
les coûts humains et la rentabilité. Voyons d’abord les coûts humains.
Les coûts humains

Si vous supposez qu’un utilisateur final est complètement inactif pen-
dant que les ressources informatiques sont hors service, alors l’entre-
prise paie de toute évidence le salaire ou le salaire horaire de cette
personne sans en tirer aucun avantage. Cela peut être quantifié de la
manière suivante :
Hr = Coût horaire du personnel concerné ($ par heure)
Dans un restaurant qui n’arrive pas à avoir assez de clients, vous pour-
riez réduire les pertes en renvoyant les serveurs et les cuisiniers chez
eux pour la journée. Mais si 15 membres du personnel qui coûtent cha-
cun 8 $ par heure à l’entreprise (ainsi que deux managers salariés payés
40 000 $ par an, ou 20 $ de l’heure) devaient rester inactifs, alors cela
reviendrait à (15 × 8 $) + (2 × 20 $) = 160 $ par heure pour le temps
d’inactivité.
Dans un bureau, il y a peut-être d’autres tâches que les employés

peuvent effectuer et ainsi, ne pas rester complètement inactifs. Dans ce
cas précis, il est possible de choisir de diviser les coûts salariaux par
deux pour montrer qu’ils sont à moitié impactés par opposition à une
inactivité et une absence de productivité.
Chaque entreprise est différente, mais vous devriez être en mesure
d’évaluer un montant horaire en $ pour un certain pourcentage de vos
coûts directs de rémunération des employés qui ne peuvent pas assu-
RAPPEL mer leur fonction principale en raison d’une panne informatique.
Rentabilité
Lorsqu’une équipe qui génère des revenus est impactée, les revenus le
sont également. Ainsi, si vous connaissez la rentabilité hebdomadaire
ou mensuelle d’une équipe, vous pouvez quantifier le profit qu’elle
génère ou non pendant une panne :
Re = Rentabilité ou perte horaire ($ par heure)
Une équipe peut générer un profit de 9 000 $ par jour, de sorte que sa
rentabilité horaire entre 8 h et 17 h est de 1 000 $ par heure.
Au sein d’une équipe soumise à des contrats de service, vous pouvez

être tenu de payer des amendes ou de récupérer des pertes si vous ne
fournissez pas le service escompté.
RAPPEL
Un service d’expédition est susceptible de ne pas perdre d’argent pour
quelques heures de temps d’arrêt, mais si une journée entière est per-
due, des frais de livraison accélérée peuvent être encourus afin de livrer
des biens en temps opportun le lendemain.
Là encore, chaque entreprise est différente, mais vous devriez être en

mesure d’évaluer le montant horaire de la valeur commerciale qu’une
équipe crée par jour ou par heure. Une partie de cette productivité est
RAPPEL perdue ou des pénalités sont encourues lorsque l’équipe est incapable
d’assumer sa fonction principale en raison d’une panne informatique.
En additionnant Hr et Re, vous obtenez le total en dollars par heure de

l’impact d’une panne informatique sur l’équipe. En utilisant le premier
exemple de chaque description, une équipe peut coûter 160 $ par heure
en étant simplement assise sans rien faire (Hr) et ne pas générer de
revenus (Re) s’élevant à 1 000 $ par heure. Ainsi, chaque heure coûte
1 160 $ à l’entreprise.
Mettre la formule en pratique

Dans cette section, nous nous pencherons sur une formule de base per-
mettant de mesurer la disponibilité des systèmes en termes financiers.
Prenez le temps total de perte de données plus le temps de panne et
multipliez-les par la valeur correspondant à ce qu’une heure représente

financièrement pour l’entreprise ou l’équipe, en tenant compte des
coûts humains ainsi que de la rentabilité ou des pertes :
Coût du temps d’arrêt = (Tp + Td) × (Hr + Re)
Tp = Temps, durée de la panne

Td = Temps, durée de la perte de données
Hr = Coût humain $/h (par personne)
Re = Rentabilité $/h
Dans les exemples, nous obtenons
Tp = 12 heures de panne
Td = 6 heures de données perdues
Hr = 160 $/heure pour une équipe inactive
Re = 1 000 $/heure de revenus perdus
Coût du temps d’arrêt = (12 heures + 6 heures) × (160 $/

heure + 1 000 $/heure)
Coût du temps d’arrêt = 18 heures × 1 160 $/heure

Coût du temps d’arrêt = 20 880 $
Cette entreprise perdra près de 21 000 $ si un serveur tombe en panne,

même s’il est restaurable à la fin de la journée suivante.
Vous disposez donc maintenant d’une formule, mais il reste encore du

travail à faire. L’idée ici est simplement d’aider à identifier les variables
dont vous aurez besoin pour quantifier le coût des temps d’arrêt.
Calculer les coûts des temps d’arrêt pour un

seul groupe ou une seule charge de travail
Il est temps d’explorer plus en profondeur le fonctionnement de la for-
mule (plutôt abstraite) dans la réalité. Prenons toujours le même scé-
nario de panne d’un environnement qui utilise une sauvegarde nocturne
comprenant une sauvegarde complète chaque week-end et des sauve-
gardes incrémentielles chaque nuit. Conformément au scénario que
nous avons utilisé dans ce chapitre, le serveur de production tombe en
panne mercredi à 14 h. Comme nous l’avons vu précédemment dans ce
chapitre, les utilisateurs sont impactés pour le reste de la journée de
mercredi et la restauration prend une bonne partie du jeudi. Le serveur
est à nouveau en marche jeudi soir, les utilisateurs sont satisfaits dans
l’ensemble et les affaires reprennent. Deux mois plus tard, cet incident
fera partie d’un passé lointain et sera considéré comme un léger désa-
grément. Certes, le serveur est tombé en panne, mais tout s’est remis à
fonctionner en une journée. Plutôt satisfaisant, n’est-ce pas ?
Faux ! Jetons un œil sur les chiffres :

Hr = Coût humain $/heure (pour l’équipe)
Re = Rentabilité $/heure
Sauvegarde nocturne = (1j + ½j) × (Hr + Re) × h/jour
Tp = RTO = 1 jour de restauration, y compris les pièces, la livraison

et l’installation
Td = RPO = en moyenne ½ jour (panne survenant tôt le matin ou tard
l’après-midi)
Hr = Coût humain $/heure (par personne)
Le temps de panne (Tp) ou l’objectif de temps de restauration (RTO)

sera probablement d’un jour ouvrable, ce qui inclut l’identification des
raisons de la panne du serveur, la réparation des composants et la res-
tauration des données. Si tout se passe bien, cela doit généralement
prendre un jour ouvrable. Si les choses ne se passent pas bien, cela peut
conduire à deux à trois jours de temps d’arrêt. Dans un monde parfait,
des pièces supplémentaires sont déjà disponibles, les techniciens sont
prêts à se mettre au travail et le serveur sera peut-être sera opération-
nel en quelques heures seulement.
Le temps de perte de données (Td) ou le délai optimal de reprise d’acti-

vité (RPO) doit statistiquement être d’une moitié de jour ouvrable.
Comme indiqué précédemment dans le chapitre, le serveur pourrait
tomber en panne au début d’un jour ouvrable, entraînant une perte de
données proche de zéro depuis la dernière sauvegarde nocturne, ou il
pourrait tomber en panne à la fin du jour ouvrable, entraînant une jour-
née complète de perte de données. En faisant une moyenne, mettons
que les données sont perdues à partir de la mi-journée.
Supposons que la panne n’impacte qu’un seul département au sein

d’une organisation plus vaste, pourquoi pas l’équipe de vente interne au
sein de la société. Diverses études estiment que l’employé de bureau
moyen aux États-Unis coûte 36 dollars de l’heure. La réalité d’une sta-
tistique aussi large, c’est qu’elle garantit d’être fausse pour vos effec-
tifs, mais elle sert de paramètre fictif pour le moment. Prenons
maintenant un jour ouvrable de 10 heures et admettons que cette équipe
génère un chiffre d’affaires annuel de 10 millions de dollars :


Hr = Coût humain $/heure (pour l’équipe)
Équipe de vente interne dont les données sont protégées via une
sauvegarde nocturne = (Tp + Td) × (Hr + Re) × h/jour
Tp = RTO = 1 jour de restauration, y compris les pièces, la livraison et

l’installation
Td = RPO = en moyenne ½ jour (panne survenant tôt le matin contre
tard le soir)
Hr = Coût humain = 36 $/heure/personne × 50 employés = 1 800 $/
heure
Re = Rentabilité = 10 M $/an = 3 850 $/heure (10 heures de travail
par jour, 5 jours par semaine)
Équipe de vente interne dont les données sont protégées via la

sauvegarde nocturne = (1j + ½j) × (1800 + 3850) × 10 h/jour
Impact sur les activités par panne de serveur = 84 750 $
Il ne s’agit pas d’une erreur de frappe. Si le serveur principal tombe en

panne pour un groupe moyen de 50 employés de bureau qui dégagent
des revenus (selon vos hypothèses antérieures), l’impact sur les activi-
tés pour cette organisation est de 84 750 $.
Adapter la formule à votre entreprise

Vous devez commencer par faire vos calculs. En vérité, il y a plus de fac-
teurs à prendre en compte. La direction doutera probablement de la
validité de la première évaluation de la formule du coût des temps d’ar-
rêt. Et ce n’est pas grave, parce qu’elle aura probablement raison.
Si vos utilisateurs ne parviennent pas à accéder à leur application prin-

cipale, ils peuvent rattraper leur retard sur leurs e-mails ou utiliser cer-
tains documents sur leurs postes de travail ou ordinateurs portables
locaux. Dans ce cas, considérez que les employés ne sont pas complète-
ment inactifs, mais simplement affectés par la panne. Si tel est le cas,
vous pouvez ajouter un multiplicateur à la formule pour indiquer que la
base d’utilisateurs fonctionne aux deux tiers de son efficacité. Ainsi, un
multiplicateur d’un tiers appliqué à la formule se traduit par un impact
sur les activités de seulement 28 250 $.
Dans le monde actuel des professionnels de l’information, vous pouvez
considérer que les utilisateurs ont une variété de tâches à réaliser. Entre
les applications de messagerie et de base de données (y compris la ges-
tion des contacts), ainsi que les applications bureautiques tradition-
nelles à partir d’un serveur de fichiers, vous pouvez considérer que
l’inconvénient sera mineur pour un pourcentage des utilisateurs. Cela
pourrait se traduit par un impact de 10 % pour 10 % des employés. Cela
signifierait littéralement que seulement cinq des 50 employés seraient
concernés et par conséquent, que le coût ne serait que de 8 475 $.
Toutefois, certains services n’ont pas de fonctions multiples avec les-

quelles ils peuvent équilibrer la balance. Dans l’exemple des ventes
internes, que se passerait-il si toutes les données se trouvaient dans une
seule application de base de données ou si l’équipe commerciale ne pou-
vait tout simplement pas travailler sans avoir accès à la base de don-
nées ? Dans ce cas précis, les commerciaux subiraient l’ensemble de
l’impact sur les activités (ce qui pouvait sembler au départ extrême) de
84 750 $.
L’impact sur les activités peut être encore plus significatif lorsque vous
partez du principe qu’en général, un serveur ne tombe pas en panne
qu’une seule fois. Bien que ces inconvénients mineurs puissent dispa-
RAPPEL raître petit à petit de la mémoire des utilisateurs, ils ne disparaissent
généralement pas du journal des événements de votre système. Vous
serez peut-être surpris d’apprendre qu’un serveur donné tombe en
panne deux fois par an, auquel cas vous doublerez tous les chiffres pré-
cédents (qui n’incluent toujours pas les coûts du matériel ou des
services).
Statistiquement, 18 % des serveurs subiront au moins une panne par an.
Mais même en cas d’une panne par an, si vous supposez qu’un serveur
traditionnel a une durée de vie de trois ans, vous devez multiplier le coût
par panne par le nombre de pannes par an par sa durée de vie en années :
Coût total par serveur = Cp × Ppa × DV
Cp = Coût par panne = résultat de la formule précédente

Ppa = Nombre de pannes par an (prenons seulement 18 % par an et
une panne par serveur)
Dv = Durée de vie prévue du serveur (généralement 3 ans)
Coût total par serveur = 84 750 $ x 0,18/an × 3 = 45 765 $
Voici le bilan : le serveur qui a été récemment acheté et déployé pour

aider l’équipe de vente interne de l’entreprise est considéré comme

fiable et bien géré. On peut donc supposer qu’il a 18 % de chances de
tomber en panne au moins une fois par an. Notez qu’en ajoutant la pro-
babilité statistique à l’équation, il s’agit maintenant d’une probabilité,
pas d’une possibilité (c’est-à-dire que c’est une question de quand et
non de si). Dans cette optique, l’entreprise doit prévoir que l’impact de
ce serveur sur l’activité de l’entreprise sera de 45 765 $ au cours de sa
durée de service.
Nous obtenons ainsi l’analyse d’impact sur les activités (BIA) pour ce
seul serveur. Nous avons pris le temps d’observer les données à la loupe
dans ce chapitre, mais dans la pratique, la BIA s’effectue plus vite que
vous ne le pensez. Généralement, lorsque vous cherchez quel type de
solutions de protection ou de disponibilité adopter pour votre serveur ou
plateforme d’application, vous devez d’abord comprendre le type de
risques contre lequel vous souhaitez vous protéger ainsi que l’impact
financier si un tel risque devait se produire.
DANS CE CHAPITRE
»» Coût total de possession (CTP)
»» Retour sur investissement (ROI)
»» Espérer que vos formules sont mises en
question
Chapitre 4
Métriques financières :
CTP et ROI
B
ien sûr, vous pouvez discuter de la protection des données et des
technologies de disponibilité en termes de coût d’impact, ce qui
sous-entend le coût commercial du statu quo. Il y a, bien sûr, le
facteur du prix de la solution, qui est différent selon la personne à laquelle
vous vous adressez.
Coût total de possession

Dans cette section, je tiens à souligner le fait que le prix est toujours
supérieur à celui qui est imprimé sur la facture. En réalité, dans de
nombreux scénarios de sauvegarde et de restauration, le coût le plus
important est celui de la main-d’œuvre.
Prenons l’exemple d’une solution de sauvegarde nocturne tradition-

nelle. Les coûts d’acquisition initiaux peuvent inclure :
Le serveur de sauvegarde (logiciel) 2 500 $

Des agents de sauvegarde (logiciel) 995 $ par serveur de production
Serveur de sauvegarde (matériel) 2 500 $
Lecteur de sauvegarde sur bande (matériel) 2 000 $
CHAPITRE 4 Métriques financières : CTP et ROI 31

Si vous comptez qu’un réseau traditionnel d’entreprise de taille
moyenne dispose de 25 serveurs, alors pour acheter une solution de
sauvegarde nocturne pour cet environnement, vous pourriez demander
37 000 $, sans compter les frais de services de déploiement.
Ne pas inclure la main-d’œuvre utilisée pour le déploiement est votre

première erreur, car vous « paierez » pour le déploiement, même si
vous le faites vous-même. Si vous passez un contrat avec un revendeur
MISE EN local ou un spécialiste de la sauvegarde, il y aura probablement un coût
GARDE
fixe pour le déploiement, ce qui, espérons-le, aboutira également à une
solution rapide et fiable, car le revendeur a sûrement une expérience
antérieure et des liens étroits avec votre fournisseur de logiciels de sau-
vegarde. Si vous décidez de le faire vous-même parce que vous ne sou-
haitez pas supporter les coûts de main-d’œuvre supplémentaires, vous
les paierez en temps voulu, soyez-en sûr (toute personne ayant déjà
réalisé un projet d’amélioration ambitieux pour sa maison peut en
témoigner). Votre propre personnel informatique, qui autrement tra-
vaillerait sur d’autres projets, devra s’occuper du déploiement à la
place. Le projet prendra probablement plus de temps si votre personnel
n’a pas déployé cette technologie particulière auparavant et, s’il ne suit
pas les meilleures pratiques, cela entraînera certainement le besoin de
faire appel à une main-d’œuvre supplémentaire ultérieurement.
Quoi qu’il en soit, en supposant que tout revient au même, comptez

huit heures pour le déploiement du serveur plus 30 minutes par serveur
de production pour l’installation de l’agent et la configuration des
scripts de sauvegarde. En faisant une moyenne entre un professionnel
de l’informatique interne à 75 $ de l’heure et un revendeur local, qui
peut facturer 250 $ de l’heure, on totalise 20 heures, ce qui équivaut à
environ 150 $ de l’heure, soit une main-d’œuvre totale supplémentaire
de 3 000 $.
Mais ce n’est pas tout. Vous devez également calculer le coût des sup-
ports. Si vous estimez que chacun des serveurs dispose de 5 To de stoc-
kage, vous disposerez alors de 125 To de stockage actif dans
l’environnement. À un taux d’utilisation moyen de 60 %, vous aurez
besoin d’environ 75 To de données pour être protégé. Avec un taux de
modification quotidien global de 5 % (plus pour les applications, moins
pour les partages de fichiers), vous créerez environ 4 To de nouvelles
données par jour. Les sauvegardes peuvent être stockées sur disque,
dans le cloud ou sur des bandes. Prenons des bandes pour cet exemple.
La plupart des logiciels de sauvegarde utiliseront une bande différente
pour chaque tâche quotidienne, plus quatre bandes hebdomadaires et 12
bandes par an. Par mesure de prudence, cela revient à 20 bandes à 100 $
chacune pour 2 000 $ supplémentaires de supports sur bande (sans
compter les coûts supplémentaires, comme le stockage hors site ou les
services).
Et ça n’est toujours pas fini. Il y aura également des coûts fixes, tels que
l’électricité, l’espace et le refroidissement. L’espace est associé aux
coûts de vos installations, mais le simple fait d’exécuter le nouveau
logiciel de sauvegarde sur une plateforme de serveur de produits pour-
rait consommer 500 watts (plus les 200 watts du lecteur de bande). Le
coût mensuel de l’alimentation pour ce seul serveur est de :
700 watts × 24 h/jour = 16 800 watts heures (Wh) ou

16,8 kilowatt-heures (kWh) par jour
16,8 kWh × 30 jours/mois = 520,8 kWh par mois
À 0,06 $ le kilowatt-heure, ce serveur coûtera 31,20 $ par mois, soit

375 $ par an. Vous devez également ajouter les coûts de main-d’œuvre
permanents pour les tâches suivantes :
»» Effectuer la rotation des bandes tous les jours, ce qui n’est pas beau-
coup, peut-être 10 minutes par jour ouvrable
»» Vérifier les tâches de sauvegarde, 10 minutes par jour ouvrable, plus
une heure de résolution des erreurs toutes les deux semaines
Vus de cette façon, ces chiffres ne sont pas significatifs, mais lorsque
vous les additionnez, vous obtenez 8 220 minutes, 137 heures, ou
3,4 semaines de travail par an, en gérant simplement les sauvegardes
(en supposant qu’à peu près tout fonctionne correctement la plupart du
temps) et sans inclure les restaurations. La main-d’œuvre nécessaire à
la gestion des sauvegardes de cet environnement représentera au moins
un mois par an, sans bénéfice de productivité, et coûtera 10 300 $.
Cela vous donne une vue d’ensemble, le coût total de possession (CTP) :
»» Achat initial : le prix d’achat initial de votre solution de sauvegarde

peut avoisiner 37 000 $, plus 3 000 $ pour l’installation.
»» Frais supplémentaires : les coûts opérationnels de la première
année s’élèveront à 12 800 $ supplémentaires.
»» Sur toute sa durée de service : en supposant que la plupart des
actifs matériels et logiciels ont une durée de vie d’environ trois ans,
vous pouvez ajouter la maintenance logicielle (15 %), la main-
d’œuvre nécessaire pour la mise à jour (la moitié du déploiement) et
de nouvelles bandes annuelles et quotidiennes (cinq par an) pour
les deuxième et troisième années. Les coûts fixes pour ces éléments
s’élèvent à 6 100 $ par an.

Ainsi, le CTP de cette solution de sauvegarde serait de 65 000 $, soit près
du double du prix d’achat initial et ne comprend pas la main-d’œuvre
pour les restaurations.
Retour sur investissement

Si le CTP est considéré comme étant le mauvais chiffre à prendre en
compte dans toute évaluation financière, alors le retour sur investisse-
ment (ROI) serait le bon. Repensez au début du chapitre 2 sur l’analyse
d’impact sur les activités (BIA), où nous posions la question « Quel est
le coût du problème ? »
Si un problème coûte 150 000 $, considérez ce montant comme une

perte d’argent quantifiable. Mais si vous résolvez le problème, l’entre-
prise récupère 150 000 $. Voyez cela comme une mise au poker ou une
pièce insérée dans une machine à sous : cet argent n’existe plus. Si vous
gagnez de l’argent lors de votre partie de poker ou en jouant aux
machines à sous, alors ce sont des gains, un actif. Bien entendu, si vous
pariez 5 $ et gagnez ensuite 5 $, vous n’avez pas vraiment gagné, seu-
lement atteint le seuil de rentabilité. De même, si votre problème tech-
nologique ou votre vulnérabilité coûte 150 000 $ et que vous récupérez
cette somme en dépensant 150 000 $ pour une solution de protection,
alors vous n’avez pas vraiment résolu le problème de la perte d’argent
pour l’entreprise, vous avez simplement choisi de le dépenser d’une
manière différente. Cela peut convenir à votre DAF, selon les pratiques
comptables, mais cela sort du champ d’application de ce livre.
Si vous avez dépensé 65 000 $ (CTP) pour résoudre un problème qui
coûterait 150 000 $ (BIA) à l’entreprise, vous avez résolu le problème.
Vous avez littéralement ajouté 85 000 $ au bénéfice net de l’entreprise,
RAPPEL car sans votre intervention, elle aurait perdu cet argent en raison des
pannes que vous avez atténuées. C’est là que le ROI entre en jeu : le
montant que vous avez fait économiser ou gagner à l’entreprise, par
rapport à celui que vous avez dû dépenser pour résoudre les problèmes.
Calculer le ROI
Vous pouvez quantifier le ROI de différentes façons :
»» Considérez-le comme une économie, soit 85 000 $ que vous avez

fait économiser à l’entreprise par rapport à ses coûts actuels.
Écartons complètement les serveurs de la discussion. Si vous pou-
viez prouver à votre comptable que vous pouvez lui faire économiser
85 000 $ avec une solution alternative sur un achat qu’elle a l’habi-
tude de payer 150 000 $ par an, la décision commerciale serait facile
à prendre.
»» Mesurez-le comme le pourcentage de BIA/CTP. Dans ce cas,
150 000 $ divisés par 65 000 $ donnent 2,3, soit un rendement de
230 %. D’autres inversent le pourcentage (CTP/BIA) pour obtenir le
pourcentage du problème que vous essayez de résoudre en effec-
tuant des dépenses. Dans ce cas, vous pouvez dépenser 43 % du
montant du problème pour le résoudre. Cela signifie également que
vous économisez 57 % sur vos pertes attendues.
»» Voyez tout cela en termes de fenêtres (temps) de rembourse-
ment. Si un problème coûte 150 000 $ sur trois ans, qui est la durée
de vie de l’actif, alors prenez en compte le temps nécessaire dans
cette fenêtre avant que la solution ne paie pour elle-même. Dans ce
cas, avec une moyenne de 50 000 $ par an, le coût de la première
année de 52 800 $ atteint le seuil de rentabilité, mais les deuxième
et troisième années passent de 50 000 $ à 6 000 $ par an, ce qui
permet d’économiser la quasi-totalité.
Le calcul réel du ROI consiste à prendre le bénéfice net (150 000 $ moins

les coûts de 65 000 $) de 85 000 $, puis à le diviser par les coûts, après
quoi vous le multipliez par 100 pour obtenir un pourcentage :
CONSEIL
(Bénéfice total − Coûts) ÷ Coûts
(150 000 $ − 65 000 $) ÷ 65 000 $
85 000 $ ÷ 65 000 $ = 1,31, ce qui représente un ROI de 131 %
DÉLAI DE RENTABILISATION
La vitesse à laquelle vous commencerez à voir les avantages de la solu-
tion que vous déployez est liée d’une certaine manière à son ROI. Lorsque
vous prévoyez x dollars sur la durée de vie du projet, regardez également
à quel moment vous verrez cet argent.
Comparez le moment où les coûts seront engagés au moment où les éco-

nomies commenceront à être visibles. Allez-vous simplement atteindre le
seuil de rentabilité pour la première année, puis constater des bénéfices
au cours des deuxième et troisième années (par exemple lorsque vous
déployez un nouveau composant qui résoudra un problème perma-
nent) ? Ou constaterez-vous des bénéfices la première année, mais moins
au cours des années suivantes, lorsque vous reporterez un problème ou
assumerez des coûts supplémentaires tout au long du projet ?
Une autre façon d’utiliser (et faire croître) l’argent plus tôt peut également
affecter les coûts globaux du projet.

Tout ROI positif représente une décision relativement bonne et tout ROI
négatif représente une décision relativement mauvaise. Prenons un
problème équivalent à un montant de 10 $ :
»» Dépenser 6 $ pour résoudre un problème valant 10 $ est une

bonne chose, car (10 $ − 6 $) ÷ 6 $ = 4 $ ÷ 6 $ = 0,66, soit un ROI de
66 %. Autrement dit, pour chaque dollar que vous dépensez de
cette façon, vous le récupérez, ainsi que 66 centimes
supplémentaires.
»» Dépenser 9 $ pour résoudre un problème valant 10 $ n’est pas
tout aussi avantageux, car (10 $ − 9 $) ÷ 9 $ = 1 $ ÷ 9 $ = 0,11, soit un
ROI de 11 %. Autrement dit, pour chaque dollar dépensé de cette
façon, vous ne gagneriez que 11 centimes de plus. Il y a probable-
ment d’autres façons pour l’entreprise d’investir ce dollar et de
gagner plus de 11 centimes en retour.
»» Dépenser 12 $ pour résoudre un problème valant 10 $ n’est évi-
demment pas une bonne idée : (10 $ − 12 $) ÷ 12 $= un ROI négatif
de 12 %. Autrement dit, pour un dollar dépensé, vous perdez
12 centimes de plus que ce que le problème initial coûtait déjà. Il
serait (évidemment) moins coûteux de continuer avec le problème
valant 10 $ que de le résoudre pour 12 $.
Le troisième exemple peut paraître trop évident, mais parfois les admi-
nistrateurs informatiques résolvent des problèmes de sauvegarde ou de
disponibilité de 10 $ avec des solutions à 12 $ (en raison de services
cloud mal utilisés, par exemple), car ils ne comprennent pas assez bien
le BIA ou le CTP ou ne connaissent pas les solutions alternatives à 6 $.
Déterminer quelle méthode de ROI

est la plus précise
Ce livre traite de la conversion des problèmes technologiques en évalua-
tions quantitatives, notamment financières. Après avoir traduit votre
problème de protection ou de disponibilité et votre (vos) solution(s)
potentielle(s) dans ce langage financier, vous pouvez le convertir d’une
dénomination (métrique ROI) à une autre, aussi facilement que si vous
transformiez le dénominateur d’une fraction en le multipliant ou en le
divisant par un nombre commun.
Je préfère parler en dollars réels, entre autres raisons parce que les DAF
et les autres fonctions comptables réduisent souvent les chiffres à leur
gré une fois que vous avez présenté deux faits numériques clés (même
si ce sont des faits défendables et non des opinions subjectives) :
»» Le problème coûte actuellement XX XXX $ à l’entreprise. (BIA)
»» Je peux résoudre le problème en dépensant YY YYY $. (CTP)
À partir de là, vous pourriez soustraire l’un de l’autre pour faire des
économies, ou vous pourriez trouver un ratio qui vous aiderait à mieux
les mettre en valeur. Toutefois, d’après certains résultats anecdotiques
tirés d’études, et l’expérience acquise au cours de nombreuses années
de support aux efforts de vente, il existe un problème de crédibilité à
prendre en compte. La section suivante porte sur cette question.
Examiner le défi posé par la

crédibilité du ROI
Bien que l’on sache que chaque fournisseur de technologie (ou d’autres
organisations commerciales) vante toujours les mérites de son merveil-
leux widget et les résultats incroyables de son ROI (ce qui est souvent
infondé), le ROI peut poser un problème de crédibilité.
En utilisant la méthode du ROI en pourcentage, mettons que le ROI

d’une solution est de 43 % : vous dépensez 70 $ pour résoudre un pro-
blème qui coûte 100 $. L’ennui, c’est que la solution coûte plus de la
moitié de ce que coûte le problème. Cela signifie que si votre évaluation
du coût du problème est perçue comme trop élevée (qualitativement,
pas nécessairement quantitativement) ou si vous avez sous-estimé un
élément dans votre CTP, alors le ROI descend en dessous de 43 % à
mesure que les coûts se rapprochent de ce que le problème coûte lui-
même. Si votre DAF est prête à parier qu’un problème ne se produira
pas aussi souvent que vous le prévoyez, elle pourrait en fait économiser
de l’argent (ou au moins atteindre le seuil de rentabilité) en supposant
simplement que le problème se produira, espérons-le, moins souvent
que vous ne vous y attendez. Le ROI du projet est insuffisant pour jus-
tifier la dépense initiale.
D’autre part, que se passe-t-il si vous n’avez besoin de dépenser que

5 $ pour économiser 100 $, ce qui donne un ROI de 1 900 % ? Cette
situation présente le problème inverse : cela semble trop beau pour être
vrai. Si vous avez une bonne crédibilité auprès du décideur financier,
vous passerez pour un héros et votre projet sera approuvé (bien qu’avec
autant de crédibilité entre vous et votre DAF, vous n’ayez peut-être pas
calculé de ROI spécifique pour commencer). Pour le reste d’entre nous
dans le monde réel, si cela semble trop beau pour être vrai, certains
décideurs financiers supposeront qu’en effet, ce n’est pas vrai (ou n’est
pas viable en tant que solution « légitime »). Il doit y avoir un facteur
coût significatif qui est soit considérablement gonflé dans le problème,

soit sous-estimé dans la solution. Quoi qu’il en soit, la solution n’est
pas perçue comme crédible. Après tout, quelle est la probabilité qu’un
achat dérisoire vous aide à résoudre un vrai problème ?
Voici une règle d’or qui, au premier abord, semble ridicule :
Un ROI de 25% peut être plus avantageux qu’un ROI de 60 %.

CONSEIL
Selon des anecdotes, l’expérience et quelques anciennes études, il

semble que le meilleur moyen de justifier une solution est de présenter
un ROI compris entre 20 et 25 %. Le bénéfice est suffisant pour que la
solution vaille probablement la peine d’être recherchée, alors que l’in-
vestissement est suffisamment substantiel pour que la solution puisse
être considérée comme raisonnable pour résoudre le problème. En uti-
lisant cette approche, il vous faut connaître les limites suivantes du
ROI :
»» Au-delà de 40 %, il peut manquer de crédibilité ou de légitimité.

»» En-dessous de 15 %, il peut ne pas offrir un bénéfice potentiel
suffisant.
L’un des conseils les plus intéressants que j’ai pu entendre au sujet du
ROI a été donné par une personne qui avait assisté à une séance sur le
ROI lors d’une conférence de DAF. Il y avait été dit que si une proposi-
CONSEIL tion importante incluait le CTP prévu et une analyse du ROI à sa pre-
mière soumission pour examen, elle serait approuvée plus de 40 % plus
souvent que celles n’incluant pas ces calculs. Si le même type de propo-
sition était rejeté en attendant l’analyse CTP/ROI ultérieure, puis sou-
mis à nouveau, il n’aurait que 15 % de chances d’être approuvé de plus
que des projets similaires dépourvus d’une telle analyse. Voici le pre-
mier conseil de réussite concernant le ROI : présentez l’évaluation du
CTP et du ROI avec la proposition initiale, car elle vous éclaire non seu-
lement sur la légitimité du projet, mais vous permet aussi de prendre
les devants pour éviter un gros obstacle au regard de ceux qui gèrent
l’argent.
Espérer que vos formules sont

mises en question
La mise en question de votre formule (de manière constructive) par
votre interlocuteur opérationnel/financier est la meilleure chose qui
puisse arriver lorsque vous présentez votre méthodologie et les justifi-
cations de BIA/CTP/ROI qui en résultent pour un projet. Lorsque vous
travaillez avec les responsables de votre entreprise et définissez la for-
mule que vous utiliserez dans votre processus, pensez à ces quelques
idées clés pour cadrer la discussion :
»» Rétrospectivement, le ROI n’est qu’une comparaison entre la BIA et

le CTP.
»» Le CTP est simplement une facture prospective, accompagnée de
quelques hypothèses simples sur les coûts fixes. Il est probable que
toute contestation à ce sujet entraîne des modifications mineures
des valeurs fixes, plutôt que des modifications plus importantes des
calculs.
»» La BIA est la plus susceptible de soulever des problèmes : vos inter-
locuteurs et les personnes concernées au sein de votre entreprise
ne sont pas d’accord avec la façon dont vous avez calculé le coût des
temps d’arrêt. (Voir l’exemple du chapitre 3.) C’est une excellente
nouvelle, car le groupe peut alors décider pourquoi la formule ne
s’applique pas à une unité d’affaires ou à une ressource technolo-
gique en particulier.
Si votre cercle de discussion peut convenir collectivement que lorsque le

serveur de base de données est en panne pendant une journée, les
employés peuvent rattraper leur retard sur leurs e-mails, ou vice versa
(et ainsi réduire une variable de moitié), alors l’équipe s’est emparée de
votre formule.
Si la personne du service RH peut fournir des montants horaires plus

précis dans un grand service (bien qu’il soit peu probable que vous
obteniez une liste des salaires individuels), votre équipe dispose alors de
valeurs fixes beaucoup plus précises sur lesquelles la direction du ser-
vice informatique et la direction opérationnelle s’entendront.
Pour résumer, chaque retour en arrière qui peut être discuté ou peaufiné
suscite l’adhésion et l’accord des autres parties. Lorsque vous disposez
de cinq variables à utiliser, la formule peut sembler académique. Mais si
vous obtenez des modificateurs plus précis et que les montants sont
intégrés sur la base de chiffres réels, il ne vous reste que les chiffres
technologiques, tels que ceux-ci :
»» À quelle fréquence le serveur tombe-t-il en panne ?

»» Quel est le coût du matériel de remplacement ?
»» Combien coûtent les bandes ?
Ces chiffres sont généralement facilement accessibles par la direction
du service informatique, de sorte que poser l’équation ne devrait pas

être un problème. À partir de là, vous disposez maintenant d’une nou-
velle BIA encore plus défendable et crédible aux yeux des autres parties
prenantes.
Le CTP provient de la facture et des prévisions. Le ROI est simplement

la comparaison mathématique de la BIA et du CTP.
RAPPEL Mais une fois que tout le monde a eu son mot à dire sur les valeurs
financières et l’impact relationnel de la formule, tout le monde se fie au
ROI, aussi élevé ou faible soit-il. Pour revenir à vos préoccupations au
sujet de la crédibilité présumée de la formule du ROI :
»» Si le ROI est moins attrayant (par exemple, le CTP correspond à 50 %

de la BIA), au moins tout le monde a pu comprendre la légitimité
des chiffres et vous avez plus de chances que le projet soit accepté.
»» Si le ROI est trop attrayant (pas crédible émotionnellement), le pro-
blème à régler est plus simple, à savoir collaborer avec le fournis-
seur lors de réunions annexes destinées à éduquer vos pairs à la
légitimité de la solution. Vous aurez alors une chance plus élevée de
faire sensation en dépensant 10 $ pour économiser 100 $.
Quoi qu’il en soit, en mettant en question les formules et variables ini-

tiales, les gens s’approprient votre projet et vous aideront à payer pour
ce que vous avez déjà en tête.
DANS CE CHAPITRE :
»» Parler plus
»» Poursuivre la discussion
Chapitre 5
Dix clés pour améliorer
vos discussions
N
ous terminons ce livre comme nous l’avons commencé, en sou-
lignant que les métriques sur les temps d’arrêt et les pertes de
données peuvent être exprimées en termes de technologies
informatiques, de préoccupations opérationnelles ou d’impacts finan-
ciers. Gérer tous ces éléments à la fois peut sembler intimidant, mais
l’astuce est simplement de comprendre la(les) personne(s) impliquée(s)
et de convertir les chiffres d’un ensemble de mesures à un autre.
Commencer par plus de discussions

Pour un processus opérationnel donné, il existe plusieurs parties pre-
nantes différentes. Les discussions doivent commencer par les trois
groupes clés : techniciens informatiques, responsables d’unité d’af-
faires et responsables financiers. Une fois que vous avez traduit les pro-
cessus opérationnels en impacts financiers et en besoins informatiques
requis, d’autres contributeurs doivent être conviés : les propriétaires
d’applications, les architectes d’infrastructure, le service juridique/
conformité et les cadres de direction. Oui, cela peut vous sembler fasti-
dieux, mais les amener à parler dès le départ accélérera rapidement la
sélection des solutions et le flux des achats, ainsi que la satisfaction
globale de l’organisation à l’égard du résultat obtenu.
CHAPITRE 5 Dix clés pour améliorer vos discussions 41

Bien rédiger vos SLA du premier coup
Entamer la discussion sur le SLA par une évaluation de la technologie
informatique actuelle limite inévitablement votre imagination et peut
réduire votre ouverture d’esprit aux besoins des unités opérationnelles
pour assurer la disponibilité ou la protection des données. À la place,
pensez d’abord aux attentes des métiers, puis évaluez vos capacités
informatiques comme moyens d’y répondre.
Comprendre que les administrateurs de

sauvegarde font rarement de bons
planificateurs de reprise après incident
Chaque stratégie de continuité de l’activité et de reprise après incident
comprend une capacité certaine de restauration des données. Mais ce
serait une erreur de supposer qu’un administrateur de sauvegarde dis-
pose du panel de compétences requises pour évaluer les processus opé-
rationnels et les impacts financiers nécessaires pour encadrer la partie
informatique d’une telle stratégie. Cependant, si vous renversez cet
argument, en apprenant comment discuter des attentes opérationnelles
et des enjeux financiers, vous n’êtes plus « seulement » un adminis-
trateur de sauvegarde.
Quantifier les défis informatiques en

termes d’impact opérationnel et financier
Les seules personnes qui ont un intérêt à se soucier des RPO et RTO sont
les administrateurs de sauvegarde et les fournisseurs de protection des
données. Pour les autres, les temps d’arrêt doivent être mesurés en
termes de capacités et d’impacts plutôt qu’en termes de vitesse et de
flux. Ce qui ne diminue en rien l’importance des mesures de la dispo-
nibilité et de la fréquence de protection des systèmes informatiques.
Mais il faut changer le vocabulaire et la taxonomie que vous employez
en tant que professionnel de l’informatique pour articuler les impératifs
associés à la modernisation de votre stratégie de protection des
données.
Admettre que ne rien faire coûte très cher

Si vous n’avez pas obtenu l’adhésion dans les trois langues sur l’impor-
tance d’une stratégie solide de protection des données, vous entendrez
probablement des commentaires tels que : « Nous ne pouvons pas nous
permettre de faire quoi que ce soit de plus maintenant. » Mais c’est
comme se plaindre qu’on ne peut pas se concentrer sur la facture d’eau
tout en regardant un robinet cassé avec une grosse fuite d’eau. Des
pannes de serveurs se produisent dans votre environnement aujourd’hui,
ce qui signifie que vous faites face à un temps d’arrêt et à des pertes de
données ce même jour. De plus, grâce au chapitre 3, vous pouvez calcu
ler ce que cette perte de données coûte à l’entreprise aujourd’hui. Inves-
tir dans un meilleur système de protection et de restauration des
données coûte beaucoup moins cher que de continuer à payer pour les
pertes de productivité causées par les temps d’arrêt et les pertes de
données.
Réaliser que les temps d’arrêt coûtent

plus que vous ne le pensez
La plupart des gens considèrent les temps d’arrêt comme un inconvé-
nient parce qu’ils ne les ont pas chiffrés. Alors, chiffrons-les. Si vous
commencez la discussion avec la vision conceptuelle de la formule du
chapitre 3, vous pouvez réduire les quatre variables au nombre de deux,
en convertissant Hr (coûts humains) et Re (rentabilité), plus les amendes
pertinentes ou d’autres frais ponctuels. À ce stade, les deux variables
restantes peuvent être détenues par le service informatique, ce qui vous
permet de vérifier les systèmes ou les journaux de gestion pour compter
les pannes, la durée de chaque panne et les temps de restauration pra-
tiques pour que tout soit à nouveau en service.
S’assurer que les parties prenantes

discutent de vos formules
La meilleure partie de toute discussion sur la formule vue au chapitre 3
vient d’une personne des services opérationnels ou financiers pour qui :
« Cela ne colle pas vraiment à cause de X. » Par exemple, si un système
de gestion des clients tombe en panne, les équipes de vente ne resteront
peut-être pas inactives (ou complètement improductives), mais plutôt
très limitées dans leurs possibilités. À ce moment-là, demandez :
« Dans quelle mesure sont-elles limitées ? Leur productivité a-t-elle
chuté de moitié ? Sont-elles seulement à un quart de leur productivité
habituelle ? Quel chiffre pouvez-vous me donner ? » Ce chiffre devient
alors un multiplicateur de Hr ou Re. La bonne nouvelle, c’est que main-
tenant votre formule devient la formule de l’équipe. Celle-ci souscrit désor-
mais à la validité de la formule pour quantifier les coûts des temps
d’arrêt.
CHAPITRE 5 Dix clés pour améliorer vos discussions 43

Prendre en compte les coûts accessoires
Tous les impacts des temps d’arrêt ou des pertes de données ne peuvent
pas être calculés en valeur numérique défendable. Et pourtant, des
impacts tels que l’érosion de la marque en raison d’une mauvaise répu-
tation ou une baisse du moral des employés à cause de systèmes peu
fiables sont absolument cruciaux. Pour certaines organisations, les
coûts accessoires sont le point de basculement entre un calcul fastidieux
de coûts fixes et la décision d’apporter des améliorations. Il faut l’ad-
mettre, plus vous montez dans la hiérarchie de la direction de l’organi-
sation, plus vous constatez que les coûts accessoires sont la motivation
réelle et que les calculs laborieux sont nécessaires pour justifier l’achat.
Quoi qu’il en soit, n’oubliez pas de tenir compte des impacts sur les
coûts accessoires lorsque vous obtenez un consensus sur les formules et
les calculs des coûts de base.
Accepter de voir les réglementations

comme un avantage
Les réglementations comprennent souvent un jargon minutieux, des
mandats irréalistes et un battage médiatique imprévisible qui agite tout
le monde, même si peu de gens, s’il y en a, prennent le temps de lire
eux-mêmes les documents. Cela dit, les réglementations ont souvent
l’avantage secondaire d’accroître la visibilité auprès des cadres supé-
rieurs : une fois que les responsables de niveau intermédiaire (ou de
niveau supérieur) ont discuté des aspects techniques, opérationnels et
financiers, ils trouveront très probablement des cadres dirigeants plus
motivés à préconiser le changement si les modifications contribuent
également à garantir la conformité réglementaire à laquelle l’organisa-
tion est tenue.
Sortir vos données du site

Trop d’organisations commencent leurs processus par des réunions,
des études et d’autres tâches administratives, mais leurs données
restent insuffisamment protégées tout au long de ces processus. Plus
tard, elles subissent une panne désastreuse, et rien n’a pu être sauvé, à
part un gros dossier rempli de projets qui n’ont pas (encore) été mis en
œuvre. Pour éviter cela, sortez vos données du site. Assurez-vous que
vos données sont viables, même si la solution actuelle n’est pas parti-
culièrement attrayante ou ne correspond pas à la façon dont vous allez
probablement la déployer par la suite dans une architecture de protec-
tion des données plus moderne. Mais au moins de cette façon, vous
aurez une chance d’obtenir ce dont vous avez besoin en cas d’incident
dès les premières étapes. Vous devez donc sortir vos données du site.
WILEY END USER LICENSE AGREEMENT
Go to www.wiley.com/go/eula to access Wiley’s ebook EULA.

Data Protection by The Numbers FD PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Data Protection by The Numbers FD PDF

Transféré par

Droits d'auteur :

Formats disponibles

Ces documents sont protégés par le copyright © 2020 John Wiley & Sons, Inc.

Toute divulgation, toute distribution et tout usage non autorisés sont

par Jason Buffington

LIMITE DE RESPONSABILITÉ/EXCLUSION DE GARANTIE : L’ÉDITEUR ET L’AUTEUR S’ABSTIENNENT DE TOUTE DÉCLARATION

ISBN 978-1-119-67361-3 (pbk) ; ISBN 978-1-119-67362-0 (ebk)

Fabriqué aux États-Unis

CHAPITRE 1 : Métriques techniques : RPO, RTO et SLA................... 5

CHAPITRE 2 : Métriques opérationnelles : RA et BIA...................... 15

CHAPITRE 3 : Calculer le coût des temps d’arrêt................................ 21

CHAPITRE 5 : Dix clés pour améliorer vos discussions.................. 41

Les métriques quantitatives vous permettent de comparer plusieurs

La protection des données, dont la sauvegarde, est souvent considérée

La pierre de Rosette de la protection des données

»» Les professionnels de l’informatique s’appuient sur les délais

Si vous êtes un professionnel de l’informatique capable de traduire les

Ce que vous trouverez dans ce livre

Chapitre 1 : Métriques techniques :

Chapitre 2 : Métriques opérationnelles :

Chapitre 3 : Calculer le coût des temps d’arrêt

Chapitre 4 : Métriques financières : CTP et ROI

Chapitre 5 : Dix clés pour améliorer

Icônes utilisées dans ce livre

Certains points méritent d’être répétés, tandis que d’autres méritent

Attention ! Cette information indique les sujets avec lesquels garder de

Si vous voyez l’icône « Conseil », lisez attentivement : vous êtes sur le

Délai optimal de reprise d’activité

Souvent, le RPO est simplement considéré comme la quantité de don-

CHAPITRE 1 Métriques techniques : RPO, RTO et SLA 5

Dans ces conditions, l’essentiel consiste à évaluer le potentiel de perte

»» Le temps passé à recréer les données perdues

»» Si le serveur venait à tomber en panne en début de jour

Si vous faites la moyenne de ces deux situations extrêmes, vous pouvez

UN SERVEUR RESTE UN SERVEUR

Pour comprendre tout l’enjeu du RPO, il faut se pencher en priorité sur

Dans le cas d’une sauvegarde nocturne, l’unité de mesure pour le RPO

Dans le présent ouvrage, les trois mécanismes de protection des don-

CHAPITRE 1 Métriques techniques : RPO, RTO et SLA 7

Vous remarquerez que ces trois mécanismes de protection des données

Objectif de temps de restauration

Dans l’exemple de sauvegarde nocturne précédent, le RPO est mesuré

Pour vous aider à comprendre à quoi ressemblent les objectifs de

Pourcentage de serveurs/services de production

Aucun Moins de De De De De De De 12 à Plus de

FIGURE 1-1 : Comment les temps de restauration s’accumulent.

selon les exemples précédents de ce chapitre, exclut une approche repo-

Allier le RPO et le RTO

Supposons que le serveur protégé dans ce scénario a subi une panne

CHAPITRE 1 Métriques techniques : RPO, RTO et SLA 9

Les conséquences négatives de ce scénario sont doubles pour les

Pour améliorer le RPO, vous devez procéder à la protection des données

Pour améliorer le RTO, vous devez disposer d’un support de restaura­

Réaliser le RPO et le RTO avec le SLA

Que se passe-t-il lorsque les circonstances ne sont pas idéales ? Dans le

»» Vous pouvez réagir rapidement à la panne du serveur.

CHAPITRE 1 Métriques techniques : RPO, RTO et SLA 11

»» Si les données incrémentielles quotidiennes ne sont pas écrasées

Ce ne sont pas des cas rares, ni un enchaînement catastrophique d’er-

Vous devez prendre en compte les processus et les pièges potentiels de

Vous noterez que la technologie n’est mentionnée que pour le dernier

»» Imaginez que vous commencez avec une sauvegarde complète, ce

Tous ces exemples désastreux et peu encourageants sont simplement

CHAPITRE 1 Métriques techniques : RPO, RTO et SLA 13

LES SLA SONT AUTANT UN ART QU’UNE SCIENCE

Pour améliorer le RTO, vous devez disposer d’un support de restaura