Résilience du cloud, 9 principes
Pannes partielles, dégradations de service, problèmes locaux… Gartner avance 9 principes pour maximiser la résilience du cloud.
Résilience du cloud, il est temps de réviser certaines idées reçues ! « Le cloud n’est pas résilient comme par magie. Les bogues logiciels, et non les pannes physiques, sont à l’origine de presque toutes les pannes du cloud, assure Chris Saunderson, Distinguished Analyst, Gartner. Dans le cloud, les pannes n’impliquent presque jamais l’ensemble du fournisseur de cloud, et les pannes de service ne sont pas susceptibles d’être totales. Au lieu de cela, des pannes partielles, des dégradations de service, des problèmes de service individuels ou des problèmes locaux sont typiques. »
L’équipe I&O doit comprendre les caractéristiques et les causes courantes des pannes de cloud. La plupart des pannes sont partielles, insiste l’analyste. Elles ont tendance à être intermittentes ou à impliquer une dégradation des performances lorsqu’elles sont moins immédiatement perceptibles et qu’il existe des différences de résilience entre les services proposés par les fournisseurs de cloud.
Pas de résilience absolue, mais une approche basée sur 9 principes
« La résilience n’est pas un état binaire, observe Chris Saunderson. Personne ne peut prétendre à une résilience absolue -ni vous, ni aucun fournisseur de cloud. Les cloud doivent être aussi résilients, voire plus, que les infrastructures sur site, mais seulement si l’équipe I&O les utilise de manière résiliente. »
Gartner recommande aux responsables I&O de se concentrer sur neuf principes clés pour améliorer la résilience du cloud. Pour commencer, un alignement métier : aligner les exigences de résilience sur les besoins de l’entreprise. Sans cet alignement sur les exigences, les équipes ne répondront pas aux attentes en matière de résilience ou dépenseront trop. Ensuite, une approche basée sur les risques : adopter une approche basée sur les risques pour la planification de la résilience qui s’étend au-delà des événements catastrophiques. « Mettez davantage l’accent sur les défaillances les plus courantes que les organisations ont le plus grand contrôle pour atténuer ! »
Etablir une cartographie des dépendances : « créez des graphiques de dépendances qui cartographient tous les composants middleware, bases de données, services cloud et points d’intégration afin qu’ils puissent être architecturés et configurés pour la résilience et inclus dans la planification de la fiabilité et de la reprise après sinistre. »
Disponibilité, reprise après incident
Autre point important, la disponibilité continue : l’approche de disponibilité continue se concentre sur le maintien des applications, des services et des données disponibles à tout moment et à tous les niveaux de service, sans temps d’arrêt et avec un impact limité en cas de panne.
S’intéresser aussi à la résilience par conception : l’application elle-même doit être résiliente par conception. « La résilience des infrastructures à elle seule ne suffit pas à fournir les services sans interruption attendus par les utilisateurs finaux. »
Quid de l’automatisation de la reprise après incident : la mise en œuvre d’une reprise après sinistre (DR) entièrement (ou presque entièrement) automatisée -soit via les propres outils de l’organisation, soit via des outils DR tiers natifs cloud- fournit la base nécessaire pour atteindre les objectifs agressifs de temps de récupération (RTO) et permet à DR d’être testé en routine.
Des alternatives plutôt qu’un basculement à l’identique
Tenir compte des normes de résilience : adopter des normes de résilience au-delà de l’architecture et de la reprise après sinistre. Les systèmes résilients exigent que les équipes se concentrent sur la qualité, l’automatisation et l’amélioration continue, et qu’elles insufflent la qualité tout au long du cycle de vie d’une application.
Bien sûr, privilégier les solutions cloud-native : les fournisseurs de cloud disposent d’une gamme importante de solutions qui peuvent être utilisées pour améliorer la résilience. « Lorsque cela est possible, essayez de tirer parti de ces solutions plutôt que d’essayer d’inventer leurs propres alternatives et d’ajouter encore plus de complexité. »
Enfin, un focus sur les fonctions métier : « plutôt que de limiter la réflexion au simple ‘basculement’ à l’identique, explorez des alternatives, telles que des alternatives informatiques légères ou des substitutions d’applications légères qui fournissent le strict minimum de fonctionnalités critiques pour l’entreprise requise. »
