Très peu d'entre nous dans le secteur de l'hébergement Web auront jamais besoin d'évoluer au niveau des services comme Dropbox. Cela dit, lorsqu'un service de la taille de Dropbox fait un faux pas qui mène à une panne, il convient de prêter attention aux causes et à l'impact pour voir s'il y a des leçons potentielles à tirer.
Le 10 janvier, Dropbox s'est déconnecté. Les utilisateurs n'ont pas pu synchroniser leurs dossiers et n'ont donc pas pu accéder à leurs fichiers sur de nombreux appareils. Le service a été interrompu pendant une grande partie du vendredi soir, et les utilisateurs ont eu du mal à accéder à leurs fichiers tout au long du week-end.
Bien sûr, les médias étaient pleins de spéculations sur les causes potentielles de la panne, beaucoup se concentrant sur une éventuelle attaque DDoS. Le lundi suivant, Dropbox a publié une déclaration qui est entré en détail sur les causes de la panne, ce qui a rejeté l'idée d'une attaque par des pirates et a plutôt blâmé un processus de mise à jour défectueux.
Le jour de la panne, Dropbox exécutait une sauvegarde planifiée du système d'exploitation. Comme vous pouvez l'imaginer, la mise à jour des milliers de serveurs utilisés par Dropbox n'est en aucun cas une tâche facile. Une grande partie du processus est automatisée avec des scripts, ce qui peut avoir été la cause du temps d'arrêt.
La leçon clé ici, telle que détaillée par le chef de l'infrastructure chez Dropbox, Akhil Gupta, est que si vous allez effectuer une mise à niveau, vous devez être absolument certain de l'état du serveur. Pour éviter que la même erreur ne se reproduise, Dropbox a implémenté un niveau supplémentaire de vérifications, afin que le serveur vérifie son propre état avant d'exécuter des commandes, plutôt que d'exécuter aveuglément des instructions entrantes, indépendamment de ce qu'il fait lorsqu'il les reçoit.
Il n'est pas mentionné dans l'autopsie de l'incident, mais la panne aurait probablement pu être évitée grâce à des tests plus rigoureux. La panne de Dropbox rappelle ce qui peut se produire lorsqu'une entreprise fait évoluer rapidement son infrastructure. La mise à l'échelle devient l'objectif principal, et les tests tombent dans la dérive dans une certaine mesure.
Une approche plus rigoureuse des tests et de la vérification des scripts d'automatisation a peut-être attrapé le «bug subtil» avant de faire des ravages.
À propos de Graeme Caldwell - Graeme travaille en tant que distributeur entrant pour InterWorx, un panneau de contrôle d'hébergement Web révolutionnaire pour les hôtes qui ont besoin d'évolutivité et de fiabilité. Suivez InterWorx sur Twitter à @interworx, Comme eux sur Facebook et consultez leur blog, http://www.interworx.com/community.
