Black-out AWS : le Cloud au ras-du-sol ?

Le 28 février dernier, un branle-bas de combat généralisé a été sonné : de nombreux sites web se sont retrouvés difficilement accessibles, dont certains géants de l’audience : Expedia, Slack, Business Insider ou encore Coursera font notamment partie des sites qui ont été impactés.

Le point commun à ces sites ? AWS.

En effet, pendant plus de 11 heures, les services AWS disponibles sur la plaque USA Nord-Est ont connu de fortes indisponibilités, et ce, que ce soit S3, RDS, ou les autres services proposés (pour avoir un aperçu, référez-vous à l’image titre : il s’agit d’une capture d’écran faite le 28 à 23h30 – au moment de la capture, la “panne” était en cours depuis plus de 5 heures).

Au final, cette panne s’est éternisée (pour quiconque s’est habitué à la disponibilité “traditionnelle” des services Cloud), et marque surtout un coup médiatique dur à encaisser pour AWS qui est le leader incontesté en termes de parts de marché du marché IaaS.

S’agit-il de LA catastrophe, l’évènement thermo-nucléaire qui met fin au Cloud comme alternative crédible aux services d’hébergement et d’exploitation traditionnels, et qui se pose comme un moyen “moins fiable” que l’hébergement on-premises ?

Désolé pour les amateurs de suspens, mais pensez plutôt au bug de l’an 2000 : du bruit médiatique, mais un ancrage dans la réalité beaucoup plus aléatoire.
L’origine de la panne provient… d’un employé qui, constatant une diminution de la qualité de service d’un service, a lancé les procédures requises pour résoudre le problème.
Mais une erreur de syntaxe a paralysé le système.

Donc non, les scénarios évoquant une attaque par déni de service géante, ou encore une défaillance matérielle des équipements AWS, faisaient fausses route.

C’est une “simple” erreur humaine qui est à l’origine d’une demie-journée d’angoisse pour les utilisateurs et les responsables informatique.

AWS n’est donc pas, dans les faits, “moins fiable” que les autres fournisseurs, qu’ils soient Cloud ou non. On notera par exemple que dans la communication officielle, Amazon pointera que certains des services impactés n’avaient pas été redémarrés depuis plusieurs années (non, il n’y a pas de faute de frappe).

Sans rentrer dans le détail de l’affaire -chose qui n’est, de toute façon, pas possible sans être dans le secret du fonctionnement d’AWS-,  il est possible de tirer plusieurs enseignements pour garantir un recours serein au Cloud :

Aujourd’hui, le pire scénario “probable” est l’indisponibilité du service.

La priorité d’un responsable informatique est d’assurer l’accessibilité des services qu’il propose à ses utilisateurs, qu’ils soient internes ou externes à l’entreprise. Pour cela, il est nécessaire de recourir à un fournisseur offrant une qualité de service satisfaisante pour ses besoins, mais qui présente un historique avéré de robustesse.
Qu’il s’agisse d’un grand (AWS, Microsoft, IBM,…) ou d’un moins grand (OVH, Outscale, Ikoula,…), l’historique existe, et il est nécessaire de le vérifier.

Un Cloud, ou des Clouds ?

Le Cloud et ses méthodes de provisioning font souvent oublier que l’on peut faire appel à des structures disposant de dizaines de millions de serveurs répartis dans le monde; il est très facile de perdre pied et tout repère au vu des quantités de données et de serveurs hébergés. Cette affaire AWS le montre bien : aujourd’hui, un seul fournisseur qui tousse, c’est une partie non négligeable du web qui faiblit.

Pour assurer ce besoin de disponibilité identifié plus haut, il faut donc se poser la question : malgré la qualité de disponibilité offerte par le Cloud, est-ce que je peux me permettre de ne recourir qu’à un seul fournisseur? Le cas échéant, chez qui aller, et surtout pour quelles raisons?

Ne pas oublier son PCA/PRA

Malgré les avantages du Cloud, cela ne dispense pas d’identifier et de mettre en place un Plan en cas de faiblesse (temporaire ou non) du fournisseur. Ainsi, ce Plan peut aussi bien consister en une activation momentanée de ressources chez un autre fournisseur Cloud, ou d’autres ressources non Cloud.

L’important ici est d’identifier les actions à mener lorsqu’une indisponibilité survient.

Au grand minimum, il faut anticiper le recours à des ressources Cloud du même fournisseur, mais distante géographiquement de la zone principalement utilisée afin de limiter les risques d’indisponibilité.

Mettre en place son propre suivi des ressources

La panne AWS a été globale, et a touché l’ensemble des services AWS.

Le meilleur exemple n’est pas à trouver des clients, mais bien du côté d’AWS : le tableau de bord de santé était lui même impacté, et ne présentait pas un état actualisé ni fidèle de l’ampleur de la panne. Sans Twitter, AWS ne pouvait pas communiquer auprès de ses clients sur l’état de résolution de la panne.

Dans ce cas, que faire?

Un tableau de bord personnalisé, reposant sur des sondes logicielles pour vérifier l’état du service et sa performance, permettra de valider les annonces du tableau de bord du fournisseur Cloud, mais aussi de mettre en oeuvre une gestion plus dynamique de l’allocation des ressources Cloud.

La mutualisation des ressources, humaines et techniques, permet d’avancer plus vite

La panne AWS montre deux choses :

⇒ Lorsqu’un élément est en panne, potentiellement toute la structure est en panne.

⇒ Lorsqu’un élément est en panne, toute la structure humaine se met en oeuvre pour résoudre la panne.

Entre la survenance de la panne AWS, et le début d’un retour à la normale de l’ensemble des services, il s’est écoulé entre 1 heure et 3 heures.

Les effets ont été totalement résorbés au bout de 11 heures.

Cette panne, d’une ampleur considérable, a pu être partiellement résolue rapidement considérant l’ampleur du désagrément et des services concernés. Le nombre d’ingénieurs et de techniciens dédiés à l’exploitation du Cloud chez AWS est sans comparaison avec ce qu’une entreprise, même un Grand Compte, est capable d’employer pour ses propres services informatiques.

De même, considérant les échelles en jeu, les acteurs du Cloud ont mis en place les procédures et les organisations permettant de gérer au plus vite le rétablissement des ressources en cas de défaillances, avec des équipes dédiées à ces questions car il s’agit d’un véritable risque portant sur son coeur de métier; ce type d’organisation est difficilement concevable pour une entreprise, car le risque n’est pas justifié par rapport à l’activité principale de l’entreprise cliente.

Pour conclure, cette panne est loin de signer l’arrêt de mort du Cloud.

En revanche, elle doit faire prendre conscience qu’avec le recours de plus en plus systématisé aux ressources Cloud, il est indispensable d’anticiper “le pire”, et de prendre les mesures adéquates pour se protéger.

La flexibilité du Cloud permet de mettre en oeuvre une approche finement adaptée aux exigences d’une entreprise : au lieu de mettre en oeuvre une politique informatique globale, il faut adapter pour chaque activité la réponse au besoin, et de mettre en oeuvre une réponse adaptée. Pour le coeur de métier de l’entreprise, une interruption de service n’est pas envisageable; en revanche, il est plus facile de gérer une indisponibilité sur une activité annexe.

C’est en utilisant la flexibilité et la robustesse du Cloud qu’il est possible de maximiser la disponibilité.

Ne vous laissez pas aveugler par cette panne d’AWS : le Cloud reste votre meilleur allié pour assurer la disponibilité de vos services informatiques auprès des utilisateurs.