après l'OVHgate

Comme vous le savez peut-être, le jeudi 9 novembre 2017 a été une terrible journée pour OVH et ses équipes. Pour résumer les 3 datacenters du site de Strasbourg (SBG) ont été complètement éteints durant 3 heures suite à un incident électrique, et les 7 datacenters du site de Roubaix (RBX) ont été quant à eux injoignables durant 2h30… Les 10 datacenters étaient HS sur la même période.

L’incident est donc majeur, et certains n’ont pas hésité à parler d’OVHgate.

Côté Daevel, la majeure partie de nos infras et clients est à Roubaix. Redondé et distribué comme il se doit, avec des clusters Ceph, MariaDB Galera, MongoDB, etc. Mais ça n’a pas suffi, ça n’a pas du tout suffi.

Y a qu’à monter un backup !

Dès lors qu’on comprend que l’incident risque de durer, on se dit qu’on va remonter un backup, ailleurs. D’ailleurs, c’est pour ça qu’on avait pris soin de faire toutes les sauvegardes de la prod de Roubaix vers Strasbourg, et inversement. Vous le sentez venir le #OhWait ?

Voilà, production et sauvegardes injoignables donc, malgré les 400km de distance.

Tant pis, on réinstalle ailleurs

Effectivement, la majeure partie de nos déploiements est scriptée, pour pouvoir installer de nouvelles machines en urgence si nécessaire. C’est parti !

Bon déjà, on est obligés de déployer chez nos fournisseurs habituels, vu que nous n’avons plus d’emails (le MX chez Vultr n’étant pas passé en prod…). Heureusement, nous sommes clients chez de nombreux hébergeurs, comme Gandi, Linode, DigitalOcean, et Vultr, donc on devrait s’en sortir.

mmm… il est où le serveur de déploiement déjà ? Parce que oui, nous avons opté pour Bcfg2, qui nécessite un serveur central, contrairement à Ansible (pourquoi déjà ???). Dans la même logique, tous nos dépôts Git sont également concernés.

C’est mort, mettons au moins une page d’erreur

Pour les clients qui le souhaitent, on pourrait au moins mettre en place une page d’erreur. Un petit serveur HTTP dans un coin, on change l’IP, et c’est plié. Après tout on a des serveurs DNS répliqués chez 4 hébergeurs distincts. Il suffit de changer la zone DNS sur le master, qui bien sûr est lui aussi injoignable.

Scénario catastrophe

Pour nous, perdre à la fois RBX et SBG, c’était le pire cas qu’on puisse rencontrer, on le savait, mais «ça n’arrivera jamais» qu’on se disait. Naïveté ? Paresse ? Manque de temps ? Probablement un peu des trois.

Comment éviter ça à l’avenir ?

C’est probablement le point le plus important, et c’est aussi pour ça que nous avons décidé de rédiger et publier nos choix techniques. Pour un peu plus de transparence, et éventuellement avoir d’autres regards sur nos choix.

Cet incident nous a permis de voir qu’il était nécessaire d’améliorer pas mal de points.

Revoir la communication

Sur le plan de la communication tout d’abord. Durant l’incident nous étions joignables uniquement par téléphone et via les réseaux sociaux, ce n’est pas suffisant.

• on doit mettre en place une page “statut”, pour pouvoir prévenir plus globalement les clients et éviter que nous passions notre temps à répondre au téléphone.
• prévoir un message d’attente spécifique sur le standard téléphonique.
• mettre en place de la haute disponibilité pour Mattermost, qui est devenu notre canal de communication de prédilection.
• faire en sorte que nous ayons toujours accès à nos emails. Le pire étant qu’on le fait déjà pour certains clients.
• ouvrir ce blog donc, pour expliquer nos choix techniques et pouvoir échanger plus facilement avec nos clients et confrères sur ces choix.

Rester opérationnels

Quoi qu’il arrive, il faut qu’on puisse continuer à travailler, mettre en place des solutions, même durant une crise.

• tous nos outils de déploiement doivent être redondés, toujours accessibles (c’est valable pour Bcfg2, Git, et APT).
• nous devons toujours avoir la main sur les DNS, et ne plus avoir un serveur DNS maître, dont tous les autres dépendent pour les mises à jour. Les serveurs esclaves en lecture seule, ça n’est pas suffisant.
• continuer à avoir accès au monitoring (Zabbix actuellement), pour mieux comprendre l’incident, et y réagir. Non, Pingdom n’est pas suffisant.

Mieux gérer les erreurs

Via notre CDN, nous aurions pû continuer à afficher certaines pages des sites, ou au moins afficher un message explicatif. Ça a fonctionné pour certains, mais pas partout. Notre CDN doit donc être plus facile à tester, et nous devons tester le mode “déconnecté” également.

Quitter OVH ?

Certains nous ont posé la question. Ce n’est pas à l’ordre du jour : des pannes majeures, on en a vu et on en verra chez tous les hébergeurs. Nous avons certainement des reproches à faire à OVH - comme avoir menti sur les niveaux de redondance de SBG - mais notre plus grosse erreur est d’avoir confié la responsabilité de la redondance à un seul fournisseur.

Désormais nous tâcherons de répartir cette charge à 3 fournisseurs, et nous expliquerons comment au travers de ce blog.