PHPIndex a fait l’objet de quelques petites perturbations de service ces dernières 72 heures. Certaines étaient prévues, d'autres non. Voici quelques explications.

Au chapitre des perturbations « prévues » et « planifiées » (vous comprendrez plus bas pourquoi j’insiste sur ce point), je travaillais depuis quelques jours sur la migration vers un nouveau serveur. Ce point figurait dans ma roadmap après la refonte de PHPIndex, effective depuis le mois dernier. Si le site PHPIndex n’avait pas évolué depuis des années, il en était de même du serveur en charge de l’héberger. Et ceci, tant au niveau du hardware que de l’OS et des versions de PHP et de MySQL. La puissance CPU commençait à manquer cruellement. Et je ne parle pas de l’espace disque qui faisait vraiment défaut, m’obligeant régulièrement à faire du ménage (en particulier dans les fichiers de log d’Apache). Une mise à jour s’imposait donc ! C’est chose faite depuis hier 14h. Cela a entraîné une courte interruption de service, le temps d’intervertir l’adresse IP de l’ancien serveur avec celle du nouveau puis d’arrêter et de redémarrer les 2 machines.

Au chapitre des perturbations « non prévues », le centre d'hébergement de Redbus Interhouse situé à Courbevoie a subi mardi une panne électrique majeure. Deux coupures successives ont été enregistrées, la première vers 14h45 qui a duré quinze minutes et la seconde vers 15h20 qui a duré moins d'une minute. On pourrait être tenté de mettre cela sur le dos de ce bon vieux Murphy. Après tout, je savais que j’allais devoir rebooter tôt ou tard du fait de la migration. Mais ce problème a touché un nombre très important de sites. Redbus, c’est un peu le Big Brother de l’hébergement, l’hébergeur des hébergeurs, le « fort Knox du web hosting ». Et là où beaucoup se risquent à annoncer 99.999% de disponibilité, RedBus n’hésite pas à garantir 100% ! D’ailleurs, je ne résiste pas à l’envie de citer leurs propres propos concernant tout particulièrement la question de l’alimentation électrique :

Notre offre garantit à tous nos clients une alimentation électrique, de grande capacité, stable, redondante, avec des possibilités d'augmentation future. Un minimum d'1 KW par mètre carré est disponible, avec une isolation d'alimentation entre les clients, une maintenance permanente, et un générateur sur site entièrement redondée faite par deux sources distinctes jusqu'aux deux générateurs de secours et systèmes d'UPS (avec capacité d'évolution).
Toute notre infrastructure est construite sur un standard d'au moins N+1, ce qui signifie simplement que si 2 générateurs sont requis pour fournir une puissance non stop, alors, nous en installerons trois. Alors plutôt que de garantir 99,99% de disponibilité, nous en garantissons 100%.

Et quand vous réalisez que, sauf erreur de ma part, RedBus est maintenu sous perfusion par une double alimentation EDF et que le centre possède, en plus, pas moins de 3 générateurs de secours prêts à prendre le relais en cas de panne en moins de 40 secondes, des onduleurs assurant l’intérim entre temps…le problème de mardi laisse rêveur, d’autant plus qu’il s’est manifesté 2 fois ! Alors à propos de la garantie de 100% je serais tenté de répondre « et la marmotte elle emballe les barres de chocolat dans le papier d’alu »…

Bon, restons zen. Il parait que certains serveurs ont mal supporté le choc. Le serveur de PHPIndex n’a pas eu de mal à redémarrer. Et puis, cela conforte une fois de plus une théorie très personnelle. En Informatique, on a beau dupliquer N fois les procédures de sécurité (sauvegardes régulières, prévention des risques électriques, etc.), ces procédures fonctionnent toujours…tant que l’on en a pas réellement besoin. C’est ainsi. Par exemple, c’est uniquement en cas de problème que l’on se rend compte qu’une sauvegarde est incomplète, parce que la partition supposée l’héberger est pleine depuis des lustres et que personne n’a pris le temps de lire les logs ou bien parce que le script n’archivait pas le nouveau répertoire de données qui avait été ajouté le mois dernier, etc.

Pour prévenir, ou tenter de prévenir, ce genre de situation, un bon principe repose probablement sur la mise en situation. J’avoue qu’il m’arrive parfois de me dire « et si ce serveur tombait en panne, le disque en rade, quelles en seraient les conséquences ? ». Et je prends quelques minutes pour analyser la situation, consulter les procédures en place, etc. Pour l’anecdote, je l’avais fait l’année dernière, précisément en imaginant que je perdais le serveur de PHPIndex. Et bien ce fût pour moi instructif puisque je me suis aperçu que je n’arriverais pas à remonter le site à 100%. J’avais oublié d’ajouter à ma procédure de sauvegarde quotidienne, le dump de la base de données des forums. Comme par hasard, ces forums avaient été ouverts après…l’écriture de cette procédure. Et je n’avais pas pensé à la mettre à jour.

Bref, s’il est probablement possible de minimiser l’impacte d’un sinistre Informatique, je reste néanmoins convaincu que le risque zéro n’existe pas. Et RedBus en a fait l’amère expérience cette semaine. Et puisqu’il vaut mieux en rire, sans vouloir retourner le couteau dans la plaie, vous pouvez consulter…in memoriam…quelques liens pointant vers la superbe infrastructure électrique de RedBus ainsi que du capteur d’iris qui permet d’accéder au centre.

Faites des sauvegardes !