Les pannes sont inévitables dans le monde moderne en réseau avec des dépendances numériques étendues. Une disponibilité fiable ne se caractérise pas par l’absence d’incidents, mais par la capacité d’une entreprise à atténuer les effets d’un incident, à effectuer un rétablissement rapide et à remettre en route des processus à valeur ajoutée dans les plus brefs délais. Cet article montre comment transformer l’incertitude en continuité d’activité grâce à une bonne préparation, à une conception architecturale prévoyante et à une gestion consciente des incidents potentiels.
J’avais l’intention d’intituler cet article « Les faiblesses cachées du cloud », mais j’ai changé d’avis car en cas de panne de cloud de grande ampleur, les conséquences sont tout sauf cachées. Dans certains domaines, comme l’explique mon ami Paul Bevan, ancien Head of Infrastructure Research chez Bloor Research aujourd’hui à la retraite, les entreprises transfèrent leurs charges de travail vers le cloud et partent du principe que le processus est terminé. Elles traitent la transformation du cloud comme si la responsabilité était désormais hors de leur portée et ne nécessitait plus d’attention.
Mais bien sûr, la migration vers le cloud, et en particulier vers le cloud public, est bien plus complexe. Le modèle de responsabilité partagée est un concept opposé à cette approche quelque peu naïve.
Les pannes de cloud ne sont pas rares dans le monde hyperconnecté d’aujourd’hui et pour les services complexes. Malgré la conception avancée des plateformes hyperscalers, des perturbations peuvent survenir, dont les causes vont des mises à jour logicielles, des erreurs de configuration et des problèmes de réseau aux pannes de courant, aux erreurs humaines ou aux réactions en chaîne des services dépendants.
Étant donné que les entreprises déplacent de plus en plus leurs charges de travail critiques vers des environnements cloud, même une courte période d’indisponibilité peut avoir des conséquences à long terme et un impact sur la disponibilité, la confiance des clients, la perception du public et la stabilité des revenus. Les incidents révèlent une vérité qui dérange : une mise à disposition de services résilients ne peut pas être externalisée : les mécanismes correspondants doivent être intégrés dans l’architecture.
En cas de panne majeure du cloud, les conséquences se font immédiatement sentir dans tous les secteurs. Les applications deviennent plus lentes, les interfaces de programmation d’applications (API) ne répondent plus, le traitement des données s’arrête et les services liés aux clients ne sont plus disponibles (les sites web génèrent des messages d’erreur).
L’impact immédiat sur l’activité comprend la perte de données transactionnelles, la perte de productivité et l’atteinte à la réputation. Pour les administrations, les services de santé, le commerce électronique et, en particulier, les services financiers, un temps d’arrêt de quelques minutes ou millisecondes peut entraîner des pertes de revenus, des infractions aux règles de conformité, le non-respect des accords sur les niveaux de service (SLA) et des problèmes d’intégrité des données.
Cependant, les principaux facteurs de coût sont le temps de récupération, la perte de clients et l’augmentation des efforts opérationnels nécessaires pour revenir à la normale.
Pour contrer ces risques, les entreprises ont traditionnellement recours à différentes stratégies de réduction des risques, notamment le déploiement de zones de disponibilité multiples (Multi-AZ), la réplication des données, les configurations de reprise après sinistre (DR) ou même les stratégies multicloud.
Même si ces mesures sont utiles dans une certaine mesure, elles n’offrent pas une sécurité absolue. Une approche multicloud peut par exemple s’accompagner de latence, d’exigences complexes en matière de gouvernance, de besoins en formation et de coûts d’exploitation supplémentaires. De même, un plan de sauvegarde ou de reprise après sinistre ne peut que protéger les données, mais ne garantit pas nécessairement la disponibilité ou des opérations de basculement et de reprise d’activité transparentes. En d’autres termes : les plans de récupération traditionnels peuvent être trop lents et trop lourds pour certaines des architectures actuelles, puissantes, orientées données et basées sur des événements.
Ou pour le formuler autrement : la redondance seule ne garantit pas la disponibilité. Ce qui compte, c’est la qualité de la conception de ces systèmes, leur automatisation et les tests réguliers en conditions de panne.
La haute disponibilité (High availability, HA) est une pierre angulaire dans une architecture de cloud résiliente. L’objectif est de garantir des temps d’arrêt minimaux. Pour ce faire, il faut concevoir des systèmes qui continuent de fonctionner même si un, deux ou tous les services sont en panne.
Pour mettre en pratique la théorie, les entreprises doivent être actives et utiliser des techniques telles que l’ingénierie du chaos (Chaos Engineering). Il s’agit de simuler des pannes dans des environnements de production afin d’observer comment les systèmes se comportent dans des situations critiques. L’identification des vulnérabilités avant que les incidents réels ne se produisent permet aux entreprises d’optimiser leur architecture et leurs mécanismes de réaction.
Netflix est considéré comme l’un des précurseurs de l’ingénierie du chaos. L’entreprise a utilisé cette approche pour garantir la disponibilité de sa plateforme de streaming malgré les fréquents changements d’infrastructure. Des approches similaires peuvent aider les entreprises à gagner la confiance dans leurs concepts de cloud, indépendamment du fournisseur.
La mise en place d’une architecture de cloud compatible HA (avec des mécanismes de basculement et de reprise éprouvés) a un coût : dépenses financières supplémentaires et complexité opérationnelle. Les ressources redondantes, les déploiements dans plusieurs régions et les basculements automatisés nécessitent des investissements supplémentaires.
J’ai récemment commenté un article en ligne dans lequel il était dit que les services de cloud computing devaient garantir la « résilience » dans leur conception. Tout d’abord, résilience et HA ne sont pas la même chose. Veuillez vérifier les définitions vous-même ! Les deux termes ne doivent pas être confondus ou assimilés. De plus, j’ai décrit le scénario suivant dans mon commentaire :
J’ai entendu des conversations similaires dans de nombreuses entreprises. Le résultat a été le même dans la plupart des cas, et un seul point a fait l’objet d’un consensus : le coût est le facteur décisif.
De nombreuses entreprises sont sous pression pour maintenir leurs coûts de cloud computing à un niveau bas. Cela conduit souvent à ce que la résilience soit reportée ou pas du tout mise en œuvre en raison de restrictions budgétaires. En outre, les architectures cloud-natives s’accompagnent de dépendances à plusieurs niveaux (microservices, conteneurs, API) qui nécessitent des stratégies de disponibilité coordonnées.
Le principal défi consiste à trouver un équilibre entre rentabilité et fiabilité. Les priorités commerciales doivent donc être conciliées d’une manière ou d’une autre avec la conception technique. Toutes les charges de travail n’exigent pas une disponibilité de 99,999 %, comme c’est le cas pour les systèmes critiques. Il est donc judicieux d’établir ailleurs dans le cloud un minimum de haute disponibilité qui permette à l’entreprise de maintenir les services les plus importants dans un état de basculement.
Un cloud résilient n’est pas un point sur une liste de contrôle, mais nécessite une culture de préparation aux situations d’urgence. Face à l’évolution des écosystèmes numériques, les entreprises doivent penser au-delà des sauvegardes et des redondances. Construire la disponibilité, c’est combiner une architecture solide avec des tests rigoureux, de la transparence et de la gouvernance.
Indépendamment de la plateforme, chaque défaillance offre l’occasion de reconsidérer les hypothèses précédentes et d’améliorer la conception. La question n’est pas de savoir si une panne se produira, mais de savoir dans quelle mesure votre entreprise est préparée à y faire face si une telle situation se produit.
Chez T-Systems, nous travaillons avec des entreprises de différents secteurs pour concevoir et mettre en œuvre des architectures cloud hautement disponibles, sécurisées, souveraines et pérennes. Notre approche combine des connaissances approfondies en matière d’ingénierie cloud avec des cadres HA éprouvés, l’observabilité et la récupération automatisée.
En tant que partenaire de confiance des principaux hyperscaleurs tels qu’Amazon Web Services (AWS), Microsoft Azure et Google Cloud Platform (GCP), nous aidons les entreprises à tirer le meilleur parti de chaque écosystème, à gérer la complexité, à optimiser les coûts et à gagner en fiabilité.
Des évaluations stratégiques de la conception et de l’architecture à la migration, l’optimisation et la gouvernance continue, T-Systems permet aux entreprises de construire une base pour des opérations numériques ininterrompues et une transformation durable.
L’optimisation de la disponibilité ne consiste pas à éviter les pannes, mais à être prêt à les affronter.
