Laisse-moi te raconter la 3187ième journée de ma vie de développeur web. J’arrive au bureau tranquille, frais comme un radis, je n’ai pas encore posé mes affaires qu’un de mes collègues, Aurélien, me dit « Yann on a un problème ». Sans plus attendre, j’ai fait demi-tour et ai dit « Bon je reviens demain ». J’ai bien entendu été m’assoir à ma place en me demandant ce qu’il allait encore me tomber dessus aujourd’hui (mais en réalité, j’adore ça!).

Et c’est à ce moment-là que je commence à voir les nouvelles tomber. Il y a un incendie dans le data center d’OVH à Strasbourg.

Avant de me lancer à corps perdu pour me rendre compte de l’impact de cet évènement sur nos sites web, je décide d’aller voir se qu’il se dit sur Twitter ou autre, afin de prendre un peu la température (oui moi je n’hésite pas à faire des mauvais jeux de mots). Les premières images que j’ai pu voir me laissaient penser que l’entièreté du DC (Data Center) allait partir en fumée, ça avait l’air hyper grave !

Je savais qu’on avait un ou deux serveurs qui tournaient sur ce DC mais pas encore quel site était impacté. Après une analyse un peu laborieuse due au fait que la console OVH ne rendait pas une partie des informations (petite pensée à ceux qui ont vécu ce moment), on a pu déterminer précisément quelle machine ne donnait plus signe de vie et que ça impactait deux de nos sites internet (relativement importants). Et évidement, on n’avait pas de backup de la veille (je simplifie car c’est plus compliqué que ça) et donc on se retrouvait dans la même situation que pas mal de personne au final (ceux qui n’avaient pas de backup quoi) !

A la base, et c’est toute l’ironie de la situation, on a changé de gamme de serveur vers du VPS à cause des problématiques de sauvegarde des Hosting Reseller. Deux jours plus tard, tout brulait. Heureusement, vu que c’était une nouvelle machine, on avait encore « l’ancienne » qui était toujours disponible dans un autre data center. Dans notre malheur on a eu de la chance. On a pu remonter relativement rapidement les sites web, simplement en repointant les DNS, avec un différentiel de données de seulement deux ou trois jours. Le pire, c’est qu’on ne savait même pas si on allait pouvoir récupérer les données. Il fallait absolument que le service fonctionne à nouveau et on s’attendait à avoir des problèmes dans la synchronisation des données.

L’impact pour nos clients a donc été une indisponibilité de service temporaire et une perte de données de deux jours.

Lors de mes premières années de dev en entreprise, je voulais absolument tout savoir, tout maîtriser, être le meilleur et je suivais des heures et des heures de tuto. Je lisais plein de trucs, je n’arrêtais jamais. Mais à l’époque, je ne connaissais rien et j’ai commis des erreurs. Je détestais tellement ça d’ailleurs, que j’ai acquis une mémoire phénoménale sur tous les cas de merdouillage possibles d’un projet web. C’est là que j’ai pondu ma première règle d’or qui était de « toujours faire un backup de DB avant de toucher à la prod ». Grâce à elle, j’ai sauvé la vie de pas mal de développeurs, et sans doute la mienne plusieurs fois au passage.

Oui à l’époque on touchait à la prod sans vergogne.

La plupart des serveurs que j’achète sont hébergés chez OVH. J’ai toujours trouvé qu’ils répondaient parfaitement à mes besoins et que les prix étaient vraiment très abordables. C’est aussi un choix qui s’est fait dans la continuité de ce que mes prédécesseurs avaient mis en place.

La société (OVH) a toujours fourni d’excellents moyens de backup, en tout cas pour les offres mutualisées. Il était possible d’accéder à un backup très facilement et d’avoir quelque chose comme du J-10 au niveau fichiers et bases de données. Je me souviens que ça m’avait sorti du pétrin quelques fois. Au niveau VPS, on peut configurer soi-même les backups, il n’y a pas vraiment de limite. Par contre, ce n’est pas automatique contrairement aux offres mutu (et on est très bien au courant en tant que dev), mais il y a toujours eu des options de backup pour un coût additionnel, allant jusqu’au système (snapshot). Donc les solutions et possibilités de backup ont toujours été présentes, elle ont sans doute évolué mais pour autant que je me souvienne, cela à toujours fait partie de l’écosystème d’OVH. Je pense donc qu’OVH est un bon hébergeur et qu’il propose tout ce dont nous avons besoin pour la réalisation de nos projets web.

Au fil du temps il peut se passer plein de trucs. Tu peux changer de boîte, changer d’infra, prendre des vacances, avoir de nouveaux collègues, des priorités qui changent, une nouvelle mission, bref. Il y a forcément un moment où la gestion des backups va être mise au second plan voire carrément passer à travers les mailles du filet. À l’heure actuelle, pose-toi ces questions, est-ce que tu sais si tous les sites internet dont tu as la charge sont backupés ? Qui s’occupe de ces backups ? Où sont-ils stockés ? Est-ce que tu y as accès ? Ou encore, est-ce qu’ils sont sécurisés ?

Moi j’ai perdu le fil et je ne sais pas donner une réponse fiable à toutes ces questions. En plus, j’ai le sentiment que je n’ai même plus vraiment besoin des backups. Souvent j’ai l’impression que c’est ponctuel pour sauvegarder la DB avant de réaliser une opération dessus ou bien pour une migration de serveur, surtout avec l’utilisation de Git ou une bonne partie du code source est « sauvegardé ».

Veiller à ce tout soit bien configuré et planifier des backups sont quand même des tâches ingrates. C’est un travail que tu vas faire et dont tu n’auras possiblement jamais besoin. Logiquement ce travail est donc négligé, ça arrive en fin de développement, lorsqu’on va mettre en production. Si on est tard le soir on se dit « Bah on fera ça demain », le lendemain, tu as un million de choses qui te tombent dessus, en plus, on s’imagine avoir une copie du site en dev ou en préprod donc aucun risque, bref… Les backups tombent un peu aux oubliettes.

Les backups, on pourrait penser que dans certains cas on peut s’en astreindre ou peut-être moins s’en préoccuper. Lorsqu’on monte des infrastructures redondées par exemple, c’est-à-dire lorsque le site est servi par plusieurs serveurs via un load balancer en amont qui est capable de savoir si un serveur est disponible et d’y envoyer le trafic. Quand on réussit à mettre ce genre d’infra en place, il y a une disponibilité qui est beaucoup plus élevé, et la nécessité d’avoir des backups est logiquement moins élevée. Mais les évènements de cette année nous le prouvent, rien n’est infaillible. On ne peut que diminuer le risque d’avoir besoin de backup mais dans la réalité, rien ne prévaut d’en faire, et pas seulement des données, car pour le coup, si tu as une infrastructure spécifique, c’est tout le paramétrage de celle-ci que tu dois en plus sauvegarder.

L’indisponibilité et la perte de données sont deux problématiques liées aux incidents sur Data Center, et malheureusement, ça se répercute directement sur nos clients, avec un service qui n’est plus disponible ou encore un manque à gagner qui se répercute directement sur le chiffre d’affaires. De notre côté, au niveau de l’entreprise, ça aussi un impact, on doit fournir du service pour analyser et réparer les dégâts, donc on perd aussi de l’argent et en plus ça bouscule les plannings. Et en agence de com, bousculer les plannings c’est comme faire tomber un domino, si tu vois ce que je veux dire.

Avant l’incident on avait clairement du mal à vendre des heures pour s’occuper de bien faire les backups et préparer des plans d’action pour quand ce genre d’incident se produit et même si c’est toujours un peu le cas, maintenant on a quelques arguments en plus et ça met un peu de poids dans la balance pour sensibiliser les clients.

A l’agence, on a donc commencé à faire un travail pour fournir un service plus résilient et pouvoir répondre plus efficacement aux pannes de Data Center. Même si on a encore pas mal de chemin à faire, on ne peut pas dire qu’on reste passifs par rapport à cela. Quelques mois après cet incident, je vais te dire ce qu’on a mis en place, le coût en ressource et ce que ça change dans notre façon de faire par rapport à avant.

La disponibilité de service, ou le fait qu’une application ou un site web est toujours disponible malgré les défaillances des infrastructures où elles sont hébergées. C’est le problème le plus complexe à résoudre et le plus coûteux. Je l’aborde également en premier, car si tu as du backup mais pas de serveur, tu n’es pas plus avancé.

Afin de répondre à la problématique, sans changer radicalement l’infrastructure, on a fait le choix de partir sur de l’IP Fail Over (IP flottante), c’est rapide à mettre en place et ça ne coûte presque rien. Grâce à ça, on peut décider à tout moment de faire pointer l’IP vers le service de notre choix (par service, j’entends serveur). Dans notre cas, on a des serveurs répartis dans plusieurs endroits géographiques donc c’est très intéressant.

Donc l’idée, c’est qu’en cas d’incident majeur, comme un incendie par exemple, on se connecte à la console d’OVH, pour autant qu’elle soit aussi accessible (j’en vois déjà certains venir) et de switcher les IP flottantes qui pointent vers le DC en feu vers un autre DC.

Ce n’est pas parfait comme solution, car derrière (par défaut en tout cas), il n’y a pas la configuration du site qui est faite, donc si on repointe l’IP, le site ne tourne pas. Bon par contre on peut presque garantir qu’il tournera à nouveau dans les dix minutes, c’est déjà beaucoup plus rassurant. Également, s’il n’y a pas une action humaine (toujours pour repointer l’IP) rien ne va le faire automatiquement, donc ce n’est pas super non plus. Par contre, je pense qu’on pourrait se servir de l’API d’OVH branché à notre service de downtime pour basculer automatiquement, mais ça va encore demander pas mal d’heures de recherche. En tout cas, grâce à cela on peut transformer plusieurs heures, voire plusieurs jours d’indisponibilité en quelques minutes pour un coût relativement bas. A titre d’information, une IP Fail Over chez OVH coûte 2€, je dis ça je ne dis rien.

Pour certains clients, on a acheté deux serveurs dans deux endroits géographiques différents et on monte les sites en miroir, on a déjà fait quelques tests, un switch prend quelque chose comme 30 sec, c’est hyper rapide et totalement transparent pour l’utilisateur. Les connexions aux machines (SSH) utilisent les mêmes clés, donc on ne perd même pas de temps à établir de nouvelles connexions aux machines, pour autant d’avoir préalablement configuré le truc de cette façon et que cette méthode soit une bonne chose (en terme de sécurité, mais ça c’est encore une autre affaire).

Néanmoins, je pense que la solution idéale serait de monter une architecture avec l’application disponible depuis plusieurs centres de données, dans des régions différentes et d’avoir un répartiteur de charge. En plus d’avoir de la disponibilité, on a également une base pour faire de la mise à l’échelle. Évidement cette solution est plus coûteuse et plus technique à mettre en place, mais c’est sur quoi mes futures recherches s’orienteront.

La perte de données, pour certains sites, c’est le plus grave. Si tu as un shop en ligne, tu peux perdre des commandes, avoir des problèmes dans la gestion des stocks, avoir des différences de chiffre par rapport aux données de la plateforme de facturation ou l’outil comptable. Pour un service de ressources humaines où tu as des offres d’emplois sur lesquelles les gens peuvent venir postuler, tu peux perdre les échanges sur un candidat, les rendez-vous planifiés, les CV, lettres de motivation, etc… Tu l’auras compris, c’est tout simplement une catastrophe et il n’y a presque aucune solution pour contrer cela, mais l’une d’entre elle est le backup.

Chez Binsfeld, je suis le premier à m’être penché sur le sujet et j’avais entendu beaucoup de bien de S3, le service de stockage d’AWS (Amazon). Après avoir fait un peu de recherche et pas mal de tests, j’ai rapidement trouvé des solutions.

Pour faire des backups chez AWS, il y a pas mal de notions à avoir pour arriver à ses fins, ce n’est pas juste « cliquer sur deux boutons ». Il y a l’interface à prendre en main, les droits avec IAM, l’installation d’un programme à faire sur le VPS, des commandes à construire, des tâches à planifier, le côté facturation, donc le coût sera surtout au niveau du temps d’apprentissage. Ce qui est chouette, c’est que le service propose un « Free Tier » c’est-à-dire qu’on peut tester certaines choses pendant un certains temps sans devoir payer.

Pour chaque projet nous ouvrons donc un Bucket, sorte d’espace dans le S3. Ensuite on crée deux dossiers, un pour stocker les fichiers du site et l’autre pour la DB.

Au niveau fichier, on configure une tâche planifiée qui envoie tous les jours à une heure précise les fichiers qui ont été changés (supprimés/ajoutés/modifiés). Il y a le versionning, c’est-à-dire qu’on peut voir l’évolution du fichier dans le temps, c’est plutôt cool, même si je ne m’en suis pas encore servi.

Pour la DB c’est la même chose à la différence qu’on l’envoie plus souvent et qu’on ne va pas la versionner mais plutôt avoir une logique de nom de fichier avec la date et l’heure. Pour la plupart des projets, on fait du J-10 maximum et pour certains projets on a des tâches cron qui sauvegardent la DB toutes les 30 minutes. Mais on pourrait très bien sauvegarder la DB à chaque action spécifique sur le site comme un achat par exemple. Tout dépend jusqu’où on décide d’aller et l’impact sur l’infra.

Un des points fort d’AWS est que c’est simple et efficace, on dirait qu’ils ont tout misé là-dessus. Une fois que les clés de sécurité d’accès au Bucket sont définies et que le programme de transfert de fichiers est installé et configuré, envoyer ou récupérer (genre de rsync) tout un projet est super rapide. J’ai fait des tests réels avec des WordPress qui contiennent plusieurs milliers de fichiers et j’arrive à restaurer les fichiers en quelques minutes.

Couplé avec l’IP FO, nous sommes donc capables de basculer de serveur et de lancer en une seule commande une reconstruction du site, en récupérant la dernière version du code applicatif, les fichiers clients et en ré-important la dernière sauvegarde de la base de données.

La mise en œuvre prend du temps, je dirais qu’il faut une bonne demi-journée pour tout mettre en place de A à Z, faire des tests de restauration et de transfert, mais une fois que c’est fait, normalement ça ne bouge plus et tu peux dormir sur tes deux oreilles.

Ce n’est pas parfait, il y a toujours un risque de perte de données tant qu’on ne fait pas de la sauvegarde en temps réel, mais au moins on peut garantir une restauration plus ou moins rapide avec des données qui ne dépassent pas la journée. La prochaine étape pour moi sera sans doute de regarder pour avoir un SGBDD redondé sur un autre DC, ça ne m’étonnerait qu’à moitié que AWS propose ce genre de service.

En neuf ans de boîte, je n’ai pas connu beaucoup d’incident, en tout cas, pas des incidents où tu perds à la fois le serveur et les données, c’est extrêmement rare. Si tu suis un peu l’actu, il y a régulièrement des pannes et pas seulement chez OVH, il y a Google, Facebook, Netflix et ces pannes durent parfois plusieurs heures.

Pour moi, c’est juste un calcul mathématique à faire. Si tu prends le site de la friterie du coin, il a y 0 conséquence si le site est down pendant deux jours, et ce n’est sûrement pas ce client à qui tu vas pouvoir vendre 2000 euros de matos informatique et autant en prestation de service pour gérer ce cas. Au contraire d’un eshop qui a basé 100% de son business en ligne, pour lui, payer 4000 par an n’est pas problématique s’il fait 1000 euros de chiffre par jour, et c’est logique.

En tant qu’agence, on va toujours essayer de proposer le choix le plus rentable en concertation avec nos clients. Dans certains cas, ce n’est pas juste une question de chiffre d’affaire, parfois c’est l’image de marque qui est mise sur la table, la crédibilité, la confiance de la boîte auprès de ses clients, donc malgré l’aspect purement technique du sujet, il y a beaucoup de « politique » derrière et des enjeux réels.

Lorsque ce genre d’évènement arrive, ce qui est vraiment essentiel, que ce soit dans le traitement du problème en interne ou encore dans la relation client, c’est de communiquer de manière totalement transparente et agir au mieux dans l’intérêt de tous.

Des incidents comme celui-là se reproduiront encore, c’est surtout la manière de répondre à ces situations qui fait toute la différence. Pour moi, c’est dans l’apprentissage technique, je passe des centaines d’heures à chercher des solutions pour les problématiques que je rencontre au quotidien. Le métier de développeur web ou le monde de l’informatique est tellement vaste et évolue tellement vite que tu peux perpétuellement t’améliorer, toujours proposer de nouvelles solutions. Je conclurais ce très long article par cette citation de moi-même.

« Il n’y a presque rien que tu ne puisses pas faire pour empêcher que ton site soit down. »