Les utilisateurs saluent la façon dont Amazon Web Services (AWS) répond désormais aux problèmes techniques. Une amélioration positive selon eux, alors que le service de Cloud Computing a souffert le 1er avril d’une panne de 3 heures de son datacenter localisé en Virginie du Nord.
L’accès aux API (interfaces de programmation), qui permettent notamment aux utilisateurs de communiquer avec les services Amazon - et ainsi de les contrôler -, est resté sans réponse pendant 3 heures jeudi matin dernier. Dans une réponse, applaudie par les utilisateurs du service, Amazon s’est livré à une explication longue et détaillée du problème, mentionnant également les faux pas du groupe dans le diagnostic de la panne.
Mise en production mal maîtrisée
“Alors que nos procédures de déploiement auraient dû empêcher ce type de panne, nos équipes ont tardé à diagnostiquer l’origine du problème et à réparer. Nos équipes techniques auraient dû comprendre plus facilement l'origine du dysfonctionnement et ainsi réparer la panne”, souligne Amazon. Le service de monitoring d’Amazon explique qu’une mise à jour logicielle de la couche de contrôle d’Amazon EC2 n’a pas été correctement testée, mais a toutefois été mise en production, provoquant dans la foulée la panne.
Selon Amazon, les machines virtuelles déjà actives n’ont pas pas affectées, mais les utilisateurs étaient dans l’incapacité de contrôler leurs environnements et d’activer ou de désactiver les serveurs pendant la coupure. Une flexibilité et une mise à l’échelle citée par Amazon comme la vertu première de son service, et dont de nombreuses entreprises dépendent pour absorber leur pic de trafic.
Un faible impact
Globalement, ce hoquet de 3 heures n’a pas eu d’impact majeur sur les activités des entreprises utilisant AWS. Toutefois, les utilisateurs saluent la justesse de la réponse d’Amazon et accueille chaleureusement les modifications dans les procédures de réponse aux pannes, comparé au mutisme traditionnel du groupe. Mitch Garnaat, consultant spécialisé dans les services Amazon, accueille même la gestion de la crise par Amazon comme un soulagement. “Cette réponse marque des points et a atteint son but”, commente-t-il dans un email.
Garnaat s’attend, en cas de panne, à recevoir des mises à jour régulières, un diagnostic rapide et détaillé ainsi que de l’information annexe sur des schémas de résolution type. Selon lui, les lacunes historiques d’Amazon en termes de communication sont la conséquence de l'identité du groupe, qui est celle d’un revendeur d’abord, avant d’être celle d’un fournisseur de services IT. Comme tous les revendeurs, affirme-t-il, Amazon craint, et ce de façon légitime, de dévoiler au grand jour des informations sur ses activités, cherchant également à protéger les données de ses utilisateurs, comme les données liées aux cartes de crédit. Dans le monde de la distribution, en effet, les consommateurs ne souhaitent pas connaître les procédures. “Dans cet univers, les seules personnes que ce niveau d’information intéresse sont les concurrents. Dès lors pourquoi faire des efforts ?”, souligne-t-il.
Il s’agit d’un point de vue différent de celui d’un fournisseur de services, qui lui a tout intérêt à jouer la transparence. “AWS est utilisé par différents types de clients avec différents types de contraintes. Je pense qu’Amazon s’efforce désormais de proposer des réponses appropriées”, ajoute Garnaat.
Un maximum d'infos sur chaque litige
“C’est exactement ce que j’attends d’un compte-rendu d’incident”, commente John Kinsella, fondateur de Protected Industries, spécialisée notamment dans les services de sécurité liés au Cloud Computing. Dans cette situation, il affirme avoir besoin d’un maximum d’informations sur chaque litige. Car, quand les services sont inopérants, il est fortement exposé. Avec un maximum d’informations, il peut davantage prendre en charge les clients mécontents.
“Minimiser l’information est simple. C’est quand un fournisseur ne me donne pas suffisamment d’information et que les utilisateurs essaient de deviner la nature du problème que les ennuis commencent”, explique Kinsella, en rappelant avoir été victime la semaine dernière d’une panne du service vCloud Express de Terramark (en bêta) qui l’a laissé sur le carreau pendant 8 heures.
En tant qu’utilisateur de EC2 et des services AWS, Kinsella confirme ne pas avoir été affecté par la panne Amazon.
Adapté d’un article de Carl Brooks, SearchCloudComputing.com
En complément :
- Amazon : un premier client du Cloud victime d'une attaque par déni de service
Tous les services du MagIT sur