Vous arrivez au bureau lundi matin et un serveur essentiel ne répond plus.
Premier réflexe :
« Pas de panique, nous avons des sauvegardes. »
C’est une bonne nouvelle.
Mais ce n’est pas encore la réponse à la question qui préoccupe les personnes qui attendent devant leur écran :
« Quand est-ce qu’on peut recommencer à travailler ? »
Car sauvegarder ses données, pouvoir remettre son environnement informatique en fonctionnement et continuer à travailler malgré une panne sont trois choses différentes.
Et toutes les entreprises n’ont pas besoin du même niveau de réponse.
La vraie question est donc peut-être moins technique qu’elle n’en a l’air : combien de temps votre entreprise peut-elle réellement se permettre d’être arrêtée ?
Une sauvegarde, c’est un peu comme avoir un double des clés
Imaginez que vous fermiez votre porte d’entrée avant de vous rendre compte que vos clés sont restées à l’intérieur.
Bonne nouvelle : vous avez un double.
La mauvaise nouvelle ?
Il se trouve à 80 kilomètres de là.
Vous n’avez pas perdu vos clés. Vous savez même exactement où se trouve la solution.
Mais vous êtes quand même devant la porte.
C’est une distinction importante lorsqu’on parle de sauvegarde informatique.
Savoir que ses données existent encore quelque part ne nous dit pas encore dans combien de temps elles seront à nouveau utilisables par l’entreprise.
Il faut pouvoir y accéder, les restaurer et remettre en fonctionnement ce qui permet de les exploiter.
C’est pourquoi la question :
« Est-ce que nous avons des backups ? »
mérite presque toujours une deuxième question :
« Très bien. Et si nous devons les utiliser demain matin, que se passe-t-il ? »
Sauvegarder les fichiers est indispensable. Mais l’entreprise travaille avec plus que des fichiers
Prenons une PME qui dispose de documents, dossiers clients, fichiers administratifs et autres données nécessaires à son activité.
Les sauvegarder est évidemment essentiel.
Et conserver des sauvegardes externalisées permet d’éviter que toutes les copies dépendent du même environnement.
Mais les collaborateurs ne travaillent pas avec une collection de fichiers posée quelque part.
Ils travaillent avec un environnement informatique.
Des serveurs ou services doivent fonctionner. Des applications doivent être disponibles. Des accès doivent être rétablis. Les différents éléments doivent à nouveau pouvoir fonctionner ensemble.
C’est là que la différence entre avoir une copie et retravailler devient très concrète.
On peut parfaitement avoir protégé ce qui compte et malgré tout avoir besoin de temps pour reconstruire l’environnement qui permet de l’utiliser.
La sauvegarde répond donc à une question essentielle.
Mais elle ne répond pas nécessairement à toutes les autres.
Et si, plutôt que d’improviser, on préparait l’accident avant qu’il arrive ?
Revenons à notre lundi matin.
Le serveur ne répond plus.
Dans une entreprise qui n’a réfléchi qu’à la sauvegarde, une partie des décisions commence à ce moment-là :
- Que faut-il remettre en service ?
- Dans quel ordre ?
- De quoi avons-nous besoin ?
- Qu’est-ce qui est prioritaire ?
- Comment allons-nous reconstruire l’environnement ?
Pendant ce temps, l’horloge tourne.
Un plan de reprise d’activité, ou PRA, cherche justement à déplacer une partie de cette réflexion avant l’incident.
On envisage les scénarios suffisamment sérieux pour perturber l’activité et on prépare la manière dont l’entreprise pourra retrouver un état de fonctionnement.
La nuance est importante.
On ne cherche plus seulement à conserver les données. On prépare la reprise.
Avoir les plans de la maison plutôt qu’un carton avec ses affaires
Pour vulgariser la différence, imaginons qu’un sinistre rende votre maison momentanément inutilisable.
Avoir mis vos objets importants en sécurité est précieux.
Vous ne les avez pas perdus.
Mais si votre objectif est de reconstruire rapidement la maison, disposer uniquement des objets ne suffit pas.
Il est beaucoup plus utile d’avoir également une représentation de la maison telle qu’elle était organisée : ses pièces, ses installations, la manière dont les éléments fonctionnaient ensemble.
Certains systèmes de sauvegarde utilisés dans une logique de reprise vont dans cette direction.
Ils ne se limitent pas nécessairement à conserver quelques fichiers individuellement. Selon l’environnement mis en place, ils peuvent capturer beaucoup plus largement l’état d’une infrastructure à un moment donné afin d’en faciliter la restauration.
L’objectif est simple :
ne pas devoir tout reconstruire élément par élément lorsqu’on est précisément dans la situation où chaque heure compte.
La technologie devient alors intéressante non pas parce qu’elle est sophistiquée, mais parce qu’elle sert un scénario qui a été réfléchi à l’avance.
Mais « le plus rapidement possible », ça veut dire quoi ?
C’est ici que la discussion devient réellement intéressante avec un dirigeant.
Une heure d’interruption n’a pas la même conséquence partout.
Dans une entreprise, quelques collaborateurs peuvent continuer autrement pendant que le problème est résolu.
Dans une autre, la production s’arrête.
Ailleurs, les commandes ne peuvent plus être traitées.
Ou vingt personnes se retrouvent avec une partie essentielle de leur travail bloquée.
La question n’est donc pas :
« Quel est le meilleur plan de reprise ? »
Elle est plutôt :
« Combien de temps pouvons-nous raisonnablement accepter que cette activité soit indisponible ? »
Une fois cette réponse connue, on peut commencer à dimensionner les moyens qui se justifient réellement.
Parce qu’entre une entreprise capable d’absorber plusieurs heures d’interruption et une autre pour laquelle quelques minutes deviennent déjà problématiques, la réponse technique ne devrait pas être la même.
Et si attendre la reprise était déjà trop long ?
Il existe alors un troisième niveau de réflexion.
Imaginons qu’une partie de votre activité dépende tellement de votre infrastructure qu’un arrêt est difficilement acceptable.
Même une reprise très bien préparée implique encore une idée : quelque chose s’arrête, puis on le remet en fonctionnement.
Un plan de continuité d’activité, ou PCA, pose une question différente :
« Peut-on concevoir cette partie de l’infrastructure pour qu’une défaillance donnée ne provoque pas nécessairement l’arrêt de l’activité ? »
C’est ici que certaines architectures redondantes peuvent prendre tout leur sens.
Et pour comprendre leur logique, oublions quelques instants les serveurs.
Un avion bimoteur ne transporte pas son deuxième moteur dans la soute
Imaginez un avion équipé de deux moteurs.
Le principe n’est pas d’avoir un moteur qui travaille pendant que le deuxième attend dans une caisse, prêt à être installé si le premier rencontre un problème.
Les deux font déjà partie du système en fonctionnement.
La redondance est pensée dès le départ pour éviter qu’une défaillance donnée entraîne automatiquement l’arrêt de l’ensemble.
C’est cette logique qui permet de comprendre certaines infrastructures hyperconvergées.
Plusieurs serveurs peuvent fonctionner ensemble et participer simultanément à l’environnement informatique.
Si l’un d’eux connaît une défaillance, les mécanismes prévus permettent aux ressources restantes de continuer à assurer les services concernés.
Autrement dit, dans les scénarios couverts par l’architecture, la panne d’un serveur ne doit plus nécessairement devenir la panne de l’entreprise.
Et c’est une différence fondamentale.
Faut-il alors installer deux armoires remplies de serveurs ?
Non plus.
À ce stade, on pourrait pousser le raisonnement très loin.
Si plusieurs serveurs apportent de la redondance, pourquoi ne pas en mettre davantage ? Puis doubler encore les équipements réseau ? Les alimentations ? Les différents composants critiques ?
Et finalement installer deux armoires entières remplies de serveurs et de matériel informatique, au cas où ?
Techniquement, on peut toujours chercher à éliminer davantage de points de défaillance.
Économiquement, la question est différente :
« Jusqu’où est-il pertinent d’aller pour cette entreprise ? »
Chez PVS, travailler avec plusieurs serveurs fait partie des architectures que nous mettons couramment en place.
Mais toutes les entreprises n’ont pas besoin du même niveau de continuité.
Un serveur indisponible pendant un certain temps peut représenter un désagrément acceptable pour l’une et provoquer l’arrêt d’une activité critique pour une autre.
C’est pourquoi la première question ne devrait pas être :
« Jusqu’où pouvons-nous pousser la redondance ? »
mais :
« Si cet élément tombe, qu’est-ce qui s’arrête réellement dans l’entreprise ? »
Et juste après :
« Combien de temps pouvons-nous accepter que cela reste arrêté ? »
C’est la réponse à ces questions qui permet de déterminer jusqu’où il est pertinent d’aller.
La technologie vient après la conséquence métier. Pas avant.
Un plan catastrophe qui date de trois ans est-il encore votre plan catastrophe ?
Préparer un scénario de reprise ou de continuité est une chose.
Encore faut-il qu’il corresponde toujours à l’entreprise le jour où il devient nécessaire.
Parce qu’une infrastructure évolue.
Un serveur est remplacé. Une application apparaît. Une autre disparaît. Des volumes de données augmentent. Des services migrent. L’organisation change.
Un scénario parfaitement cohérent au moment de sa conception peut donc progressivement ne plus correspondre à l’environnement qu’il est censé protéger.
Le pire moment pour le découvrir serait évidemment le jour où l’on doit réellement s’en servir.
C’est pourquoi, chez PVS, les éléments liés aux plans de reprise et de continuité mis en place sont suivis et maintenus dans le cadre de Trust.
L’objectif n’est pas simplement d’avoir réfléchi une fois au scénario catastrophe.
C’est de faire en sorte que cette réflexion continue à correspondre à l’infrastructure réelle de l’entreprise lorsqu’elle évolue.
Autrement dit : la continuité ne se commande pas une fois. Elle s’entretient.
Sauvegarder. Reprendre. Continuer.
Ces trois verbes permettent finalement de distinguer assez simplement les différents niveaux de réflexion.
Sauvegarder : pouvoir récupérer
On protège les données et les éléments nécessaires pour éviter qu’un incident signifie leur disparition définitive.
L’externalisation des sauvegardes participe à cette logique en évitant de faire reposer toutes les copies sur le même environnement.
Reprendre : préparer le retour à un état de fonctionnement
On ne se demande plus seulement ce qui doit être conservé.
On prévoit aussi comment l’entreprise retrouvera un environnement fonctionnel après un scénario catastrophe, avec des priorités et des mécanismes de restauration adaptés.
Continuer : éviter que certaines défaillances arrêtent l’activité
Lorsque l’interruption elle-même est difficilement acceptable, on peut concevoir certains éléments de l’infrastructure afin qu’ils tolèrent la défaillance d’un composant prévu sans interrompre les services concernés.
Ce niveau de continuité n’est pas nécessaire partout.
Mais là où quelques heures, voire beaucoup moins, représentent déjà un problème majeur, la question mérite d’être posée.
Et dans tous les cas : maintenir le plan
Une stratégie de reprise ou de continuité n’est réellement utile que si elle correspond toujours à l’environnement qu’elle doit protéger.
C’est pourquoi sa maintenance fait partie du sujet, au même titre que sa conception.
Le scénario catastrophe mérite d’être écrit avant la catastrophe
Il est évidemment impossible de prévoir chaque incident.
Mais on peut parfaitement réfléchir aux conséquences avant qu’elles se produisent.
- Que se passe-t-il si ce serveur devient indisponible ?
- Quelles activités sont touchées ?
- Qu’est-ce qui doit repartir en premier ?
- De quoi avons-nous besoin pour restaurer l’environnement ?
- Combien de temps l’entreprise peut-elle fonctionner autrement ?
- À partir de quel moment l’interruption devient-elle réellement critique ?
Ces questions permettent ensuite de déterminer si l’entreprise a principalement besoin d’une bonne stratégie de sauvegarde, d’un véritable plan de reprise ou si certaines fonctions justifient également une réflexion de continuité.
Chez PVS, c’est dans cette logique que nous abordons ces scénarios : partir de ce qui doit continuer à fonctionner dans l’entreprise pour déterminer ensuite ce qu’il est pertinent de mettre en place techniquement.
Parce qu’une infrastructure plus complexe n’est pas automatiquement une meilleure infrastructure.
La bonne infrastructure est celle dont le niveau de résilience correspond aux conséquences réelles d’une interruption.
Alors, vos données sont sauvegardées ?
Parfait.
C’est une première réponse essentielle.
Maintenant, imaginez que votre infrastructure tombe demain matin.
Combien de temps faut-il pour que vos collaborateurs puissent recommencer à travailler ?
Si la réponse est connue, préparée et cohérente avec les besoins de l’entreprise, vous ne disposez déjà plus seulement d’une sauvegarde. Vous avez commencé à réfléchir à la reprise.
Et si la réponse est :
« Cette activité ne peut pas se permettre de s’arrêter. »
alors la question suivante n’est peut-être plus de savoir comment redémarrer plus vite.
Elle devient :
« Comment concevoir l’infrastructure pour qu’une panne ne signifie pas automatiquement un arrêt ? »
