Nouvelles Chroniques d'Amethyste

Penser au Sens, pas au Verbe

RTO et RPO

Poster un commentaire

En cas de sinistre dans un système informatique on a deux façons de réagir:

  • On peut basculer sur un système de secours
  • On reconstruit l’environnement

 

Il n’y a pas un bon ou un mauvais choix, il dépend de votre situation: criticité du système, facilité de reconstruction, coût ou difficulté de maintenir un système doublon…

Dans tous les cas, deux indicateurs doivent être évalués et pris en compte:

  • RTO (Recovery Time Objective)
    Durée maximale d’interruption admissible
  • RPO (Recovery Point Objective)
    Durée maximale d’enregistrement des données qu’il est acceptable de perdre

Le RTO nous dit de combien de temps on dispose pour rendre fonctionnel à nouveau le système. Il est évident que le système de paiement en ligne d’un site e-commerce est un point critique. Son RTO devra être très bas.

L’envoie du mail de confirmation de la commande est par contre sans doute moins urgent. Le système peut passer en mode dégradé où certaines fonctionnalités sont momentanément indisponibles.

Cet indicateur doit être définit avec le client. S’il est très bas on s’orientera typiquement vers un système redondant vers lequel basculer.

 

Le RTO comprend en réalité plusieurs choses:

  • Délai pour détecter l’incident (on l’oublie souvent)
  • Délai de prise de décision (on l’oublie systématiquement)
  • Mise en œuvre du plan de secours
  • Délai de relance de l’application (chauffe, DNS, synchronisations de données…)

 

S’il y a interruption de service, il y a probablement perte de données. Le RTO mesure la durée maximale pendant laquelle on peut se permettre perdre des données.

La question est évidemment de savoir combien coûtent les données perdues en terme d’argent bien sûr, mais aussi d’image de marque, de responsabilité juridique ou autre.

 

La clef pour gérer ce problème est de faire des sauvegardes régulières.

Par exemple si les données changent peu, sont peu nombreuses, peu volumineuses, le RPO aura tendance à s’allonger. Une sauvegarde complète toutes les 24 heures peut devenir acceptable.

Si les données sont très volumineuses, une sauvegarde complète peut être contraignante. On peut envisager des sauvegardes différentielles. Bien sûr il faudra alors un certain un délai pour reconstruire les données en cas de sinistre. On augmente donc un peu le RTO.

Un autre problème est que parfois, même des sauvegardes différentielles nécessite d’arrêter momentanément le système de sauvegarde. Comment le gérer?

 

On doit penser à tout cela. La maîtrise des RTO et RPO est donc largement une question de choix d’architecture de la solution. Il n’y a pas de solution universelle.

La première chose à faire avant de se lancer dans la mise en place d’un plan de reprise est donc de dialoguer avec le client et les utilisateur pour bien définir les contraintes et identifier les systèmes critiques. Que doit t’on relancer en priorité, dans quel ordre?

On est pas non plus obligé de parler de RTO/RPO pour le système global. Le plus souvent on le défini à l’échelle de sous systèmes. Une application peut souvent fonctionner dans un mode dégradé, mais où les fonctions essentielles sont reconstituées.

Dans le cas d’un site de vente il est évident que le site web sera plus critique que la confirmation des commandes.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s