Les joies des problèmes IT

Je vais écrire un billet un peu inhabituel, aujourd’hui. Je dis souvent qu’il ne faut jamais compter sur la fiabilité des ordinateurs. C’est tellement vrai que depuis une semaine, j’enchaîne les problèmes techniques sur mes serveurs, les uns après les autres. Aucune relation entre les problèmes, ce sont juste de fâcheux concours de circonstance qui nous font perdre des dizaines de milliers d’euros de chiffre d’affaire.

Reprenons depuis le début. Les serveur de mon entreprise sont loués chez une entreprise française très connue, leader européen de l’hébergement. Nous avons actuellement 5 serveur chez eux, sachant qu’on en a eu jusqu’à 7 en même temps. Ce n’est pas une infrastructure de folie, mais le coût tourne quand même autour du millier d’euros mensuel.

Historique

Avant de parler des problèmes qui s’enquillent depuis une semaine, voici un petit récapitulatif rapide des problèmes rencontrés ces 2 dernières années (je ne liste là que les problèmes techniques pour lesquels l’hébergeur a fait des erreurs ; je ne liste pas les quelques problèmes qui ont été résolus en moins de 2 heures) :

22 décembre 2008
Problème disque dur.
Retards de communication et mauvaise prise en charge par l’hébergeur.
18h30 d’interruption de service.
15 jours de location serveur offerts.

26 mai 2010
Problème carte mère.
Mauvaise gestion du load-balancing par l’hébergeur.
10 heures d’interruption de service.
10 jours de location serveur offerts.

07 juillet 2010
Problème disque dur.
Mauvais diagnostic technique par l’hébergeur.
8 heures d’interruption de service.
14 jours de location serveur offerts.

25 novembre 2010
Problème carte mère.
Mauvaise gestion du load-balancing par l’hébergeur.
4 jours d’indisponibilité de service.
Un mois de location serveur offert.

Dans tous ces cas, l’hébergeur garantissait un délai de rétablissement garanti de 4 heures. C’est la raison pour laquelle des pénalités de retard furent appliquées.
Pour la petite histoire, j’ai aussi un serveur personnel chez cet hébergeur. Et il a aussi connu 2 changements de disques et un changement de carte mère dans le même intervalle.

L’emmerdement maximal

Juste pour montrer comment les choses peuvent s’additionner pour provoquer des interruptions de service à répétition, voici ce qui s’est passé ces derniers jours :

Jeudi dernier, notre serveur d’intranet (emails, wiki, buglist, …) se met soudainement dans un état bizarre. Après investigation, on soupçonne la machine d’avoir été hackée.
Pour info, nos systèmes tournent sous Ubuntu, qui propose des version avec support à court terme et d’autres avec support à long terme. Le serveur en question, installé à une époque avec une version LTS (long terme), avait été mis à jour par notre ancien administrateur système sans qu’il ne me prévienne. Cette mise-à-jour l’avait fait passer sur une version avec support à court terme. Grave erreur, car au lieu d’avoir un serveur stable pendant 5 ans, on s’est retrouvé sans le savoir avec un serveur qui ne recevait plus de nouveaux patchs de sécurité au bout d’un an et demi. Ce qui devait arriver arriva, et un hacker en profita.
Résultat : Réinstallation complète de la machine, une demi-journée sans email ni outils de travail collaboratif.

En même temps qu’on réinstallait ce serveur, on a remarqué qu’il était devenu impossible de se connecter par SSH sur l’un de nos serveurs frontaux. Comme on avait d’autres chats à fouetter sur le moment (imaginez une boîte de 30 personnes, dont des commerciaux, qui viennent vous voir sans arrêt parce que les emails ne fonctionne pas…), on s’en est occupé lundi. Très bizarrement, le serveur fonctionnait correctement au niveau HTTP. Les services répondaient correctement. Mais alors pourquoi le SSH est-il tombé ? Cette machine aurait-elle été corrompue elle aussi ? Son système était bien plus récent, mais les derniers patchs kernels n’étaient pas pris en compte car notre administrateur n’avait pas rebooté le serveur après la dernière mise-à-jour. On a essayé d’utiliser le système de KVM mis à disposition de l’hébergeur, qui doit permettre de prendre la main sur le serveur comme si on avait un clavier et un écran branchés directement dessus, mais le bousin n’a jamais voulu fonctionner.
Résultat : Réinstallation complète de la machine, une journée et demi à faire tourner nos sites avec un serveur frontal de moins, ce qui dégrade la qualité du service.

Juste histoire de rire, on a redémarré un autre serveur frontal après l’avoir mis à jour. Et évidemment, le système a fait un fsck (vérification du système de fichier, pour ceux qui n’ont pas l’habitude des systèmes Unix).
Résultat : 20 minutes d’attente avant que le serveur ne finisse de redémarrer, et une grosse frayeur en attendant.

Hier, nous décidons de mettre à jour notre serveur de base de données. Contrairement aux serveurs frontaux qu’on peut arrêter s’il le faut (en redirigeant les requêtes vers les autres frontaux), ce serveur contient nos bases MySQL centralisées. S’il s’arrête, ce sont tous nos services qui s’arrêtent. Il s’agit donc d’une machine haut de gamme, plutôt chère, avec de la redondance de partout (disques en RAID 1, alimentation électrique redondée, deux interfaces réseau). Pour ne pas bloquer nos sites à un moment de fort trafic, on prend la décision de faire la mise-à-jour et le redémarrage à 4 heures du matin. La mise-à-jour se passe bien, mais au redémarrage du serveur, rien de répond. L’explication finit par arriver : un des disques est mort. Mais la machine ne peut pas redémarrer ; c’est bien la peine d’avoir des disques en RAID…
Le technicien qui intervient sur la machine la place est mode « rescue », pour nous permettre de récupérer les données du disque. Mais nous ne recevrons jamais les identifiants nous permettant de nous y connecter. Le plus amusant, c’est qu’après leur avoir dit «OK, on vous donne le feu vert, dépêchez-vous de changer le disque, ça fait déjà 4 heures que le serveur est planté !», on a attendu 45 minutes pour qu’un autre technicien se penche dessus… et remette la machine en mode rescue au lieu de changer le disque ! Hop, encore une heure de perdue.
Résultat : Le temps d’attendre que le disque soit changé, qu’on réinstalle le système et qu’on rapatrie les données, on a eu 10 heures d’interruption de service.

Quel bilan en tirer ?

1. Le matériel n’est pas fiable. Ce n’est pas parce qu’on vous change un disque dur qu’il ne va pas vous lâcher de nouveau un an et demi après.
2. L’hébergeur fait de son mieux pour satisfaire ses clients. Mais vu la masse de clients qu’il a, il lui est sûrement plus rentable d’offrir 10 jours de location si les délais sont un peu dépassés que de mettre en place tout l’infrastructure nécessaire pour que ce genre de cas n’arrive pas.
3. Corollaire du point précédent, ce n’est pas parce qu’un serveur « haut de gamme » coûte plus cher et qu’il propose une garantie de temps de réparation plus courte, que les administrateur vont effectivement s’en occuper avec un plus grand soin. Ils font de leur mieux sur toutes leurs interventions. S’ils se plantent dans le changement de disque d’un serveur d’entrée de gamme à 50€/mois, ils pourront se planter tout autant quand il faudra changer le disque d’un serveur à 400€/mois.
4. Il ne faut pas compter sur les pénalités de retard. Un service indisponible pendant plusieurs heures, et ce sont des milliers d’euros de manque à gagner (sans compter les pertes d’image, de référencement, l’insatisfaction de nos propres clients). En contrepartie, quelques jours de location gratuite, c’est totalement négligeable.
5. Les solutions techniques qui devraient justement servir à assurer la continuité de service ne sont pas fiables. Pour nous, un problème de carte mère (changée en 2 heures) s’est transformé en problème de mise-à-jour des tables de routage du load-balancing (effectuée au bout de 4 jours). Alors que le load-balancing est justement là pour réorienter les requêtes quand un serveur tombe en panne !
6. La sécurité informatique est un serpent de mer insaisissable. Il y aura toujours plus de hackers compétents que d’experts en sécurité dans votre entreprise. Mais si vous n’êtes pas assez important pour intéresser les vraies méchants hackers (ceux qui en ont après les informations confidentielles que vous possédez), vous ne serez la cible potentielle que de ceux qui cherchent des machines à infecter pour en faire des relais de spam ou pour infecter d’autres machines. Un firewall bien configuré et des patchs de sécurité parfaitement à jour (sur le système et sur les applications) vous épargneront la plupart des soucis. Par contre, si vous avez des données critiques, faites appels à des professionnels ; la sécurité, c’est un métier.
7. La loi de Murphy fait que lorsque vous pensez avoir vécu le pire, les choses vont encore empirer. Il faut réfléchir au pire scénario possible, et mettre en place des mesures préventives. Et même là encore, il se passera un truc auquel vous n’avez pas pensé.

En conclusion : Vous êtes seul responsable de votre architecture technique. Ne comptez pas sur la fiabilité théorique qui vous est annoncée, et encore moins sur les garanties qu’un hébergeur est censé vous offrir. Au final, c’est vous qui perdrez de l’argent en cas de problème. À vous de mettre en place les bonnes stratégies, à base de sauvegardes, d’archivages, de serveurs de remplacement.

Et si ça vous dépasse, faites appel à des infogérants. Ça coûte cher, mais il y a une raison à ça.