Le Cloud, faux ami mais surtout meilleur allié de la résilience

Daisy flower blooming on a sand desert

L’incendie d’OVH a montré que le Cloud n’était pas une assurance tous risques contre les interruptions d’activité et les pertes de données. Mais, à l’inverse, les caractéristiques du Cloud en font un allié précieux des plans de continuité d’activités des entreprises. Permettant leur démocratisation. Explications.

 

Jérôme Mollier-Pierret, Directeur de l’Infogérance SAP chez PASàPAS

L’incendie qui a touché le datacenter d’OVH, dans la nuit du 9 au 10 mars, a rappelé à des milliers d’entreprises en France une réalité que le terme Cloud a tendance à occulter : même sur ces environnements techniques supposément ultra-sécurisés et fonctionnant avec un haut niveau de redondance, la continuité d’activité relève bien de la responsabilité de chaque organisation. « Sans oublier le fait que le terme Cloud masque nombre de réalités différentes. Entre le SaaS (Software as a Service) et le IaaS (Infrastructure as a Service) par exemple, la nature des engagements proposés diffère largement », observe Jérôme Mollier-Pierret, le directeur de l’infogérance SAP chez PASàPAS. Donc, le niveau de résilience associé à chaque solution dépend à la fois de la nature des services mis en œuvre et de leurs interactions, mais aussi des niveaux d’engagement associés. « Attention aux raccourcis, qui ont conduit aux désillusions qu’ont connues certains clients d’OVH, hébergés sur le datacenter de Strasbourg », reprend le même Jérôme Mollier-Pierret.

 

La définition du niveau de risque acceptable est un élément clé. Même si des mécanismes de résilience existent dans le Cloud, il appartient aux entreprises clientes d’en vérifier la nature et de mesurer ce qu’elles peuvent en attendre.

 

Brian Passante, Responsable Cloud & Innovation de PASàPAS

Des préventions qui valent pour OVH évidemment, comme pour tous les acteurs du Cloud, hyperscalers y compris. « Chez Amazon Web Services (AWS), on peut aussi, comme chez OVH, acheter des services qui ne sont pas associés à des sauvegardes, donc qui n’offrent pas de garantie sur l’absence de perte de données », lance Brian Passante, le responsable Cloud & Innovation de PASàPAS. Pour ce dernier, le Cloud a tellement été vulgarisé et simplifié que certains décideurs en entreprise ont fini par oublier ce que le concept masquait. Des composants techniques, par nature faillibles. Et des humains en charge de leur exploitation, par essence susceptibles de commettre des erreurs. « Par ailleurs, derrière les discours sur les mécanismes de protection entourant leurs services et sur le niveau de redondance de leurs environnements techniques, les prestataires de Cloud cherchent à se déresponsabiliser au maximum de toute perte de données », reprend Brian Passante. D’où la focalisation du marketing des acteurs du Cloud sur le niveau de services offert (les 99,999999… qui ornent certains argumentaires).

 

Manier RPO et RTO

 

Toute prise en compte des pertes d’activité réelles, qui découleraient d’une interruption de service, même très courte, doit débuter par une étude des risques. « En partant du principe que l’incident va arriver, y compris un événement supposément rarissime comme la perte d’un datacenter », indique le responsable Cloud & Innovation de PASàPAS. En découle la conception de l’architecture des solutions Cloud, répondant aux différents risques identifiés lors de l’étude. En se basant sur deux indicateurs clefs en matière de résilience : le RPO et le RTO.

 

Le premier, qui signifie Recovery Point Objective, définit la quantité de données qu’il est acceptable de perdre, donc la fraicheur des sauvegardes dont on doit en permanence disposer. Le second, acronyme de Recovery Time Objective, matérialise la durée maximale tolérable d’interruption du service : il correspond à l’intervalle de temps maximum entre le début d’un incident et la reprise du service. Deux indicateurs qui doivent servir de socle à la conception des architectures et de cadre au plan de reprise d’activités (PRA), qui définit les actions à mettre en œuvre en cas d’incident afin de minimiser les perturbations sur l’activité.

 

« Si un maillon casse, comment préserver la chaîne ? »

 

Or, précisément, dans un contexte assemblant plusieurs services Cloud, la conception de ce PRA vire au casse-tête, et c’est amplifié lorsque plusieurs opérateurs sont en jeu – on parle alors de multi-cloud. Restaurer la totalité d’une chaîne applicative impliquant de multiples prestataires peut en effet s’avérer très complexe. Surtout quand cette chaîne intègre une ou plusieurs solutions SaaS sur lesquelles l’entreprise cliente n’a quasiment aucune prise. « Notre métier consiste à assembler un certain nombre de briques technologiques avec des niveaux de service associés différents afin de s’assurer que, si un de ces maillons casse, l’ensemble de la chaîne puisse redémarrer afin de préserver l’activité », résume Brian Passante.

 

Si la logique des applications composites que porte le Cloud amène de la complexité dans la construction des PRA, à l’inverse, le Cloud apporte un certain nombre de réponses dans la mise en œuvre de ces plans. « En particulier, grâce à un accès quasi-illimité à la ressource dans des délais très resserrés, dit Brian Passante. Par exemple, un stockage de 10 To peut être disponible en 10 secondes et il est efficient immédiatement ! » Surtout, les infrastructures alignées par les hyperscalers offrent un certain nombre de garanties de temps en cas de déclenchement du PRA suite à un incident. Là où, sur des infrastructures traditionnelles, la restauration simultanée de gros volumes de données – conséquence logique d’une mise en œuvre d’un plan de continuité d’activités – se traduit très souvent par une dégradation des performances obtenues lors des tests unitaires, ce qui vient mettre le temps de reprise (le RTO) en danger. La globalisation des infrastructures permet également de raisonner mondialement lors de la reprise.

 

Un PRA sans infrastructures inutilisées

 

Autre atout majeur du Cloud : le paiement à l’usage et uniquement à l’usage. Autrement dit, contrairement à ce qui se passait avec les environnements on-premise, un PRA opéré dans le Cloud ne nécessite pas de disposer d’infrastructures dormantes, uniquement exploitées en cas d’incident sur la production. Un atout qui permet à des PME de disposer de PRA évolués, là où l’exercice était plutôt réservé à de grandes entreprises auparavant. A condition toutefois de mettre en œuvre des technologies et des bonnes pratiques totalement nouvelles. Comme le right-sizing. « Auparavant, dans un PRA, la production était hébergée sur une machine et les développements et tests sur une seconde machine identique, capable de reprendre le flambeau en cas de défaillance de l’infrastructure principale, détaille Brian Passante. Dans le Cloud, la logique est toute autre : on va aligner 4 machines indépendantes les unes des autres, pour la production, les développements, les tests et la reprise d’activité. Mais, chacune sera dimensionnée au plus juste. Il faut s’écarter des modes de conception traditionnels, sinon le Cloud n’amène aucun bénéfice pour les clients. »

 

Autre bonne pratique essentielle : l’automatisation. En reposant sur l’infrastructure as code, qui vise à piloter des systèmes IT « via des scripts » donc, dans le cas présent, à rebâtir automatiquement une infrastructure après un incident, le PRA devient, lui-même, plus résilient. « Il est alors à l’abri des erreurs humaines et peut être tenu en permanence à jour », reprend le responsable. Autant de principes que PASàPAS a mis à profit pour développer son offre de reprise d’activité des environnements SAP, sur les trois grands environnements Cloud du marché (Amazon Web Service, Microsoft Azure et Google Cloud Platform).