R-01
Le serveur lui-même
Mémoire épuisée, disque plein, processus bloqué, service qui ne redémarre pas. Les pannes qui n'ont rien à voir avec ton code.
Pas un bogue dans une page : le site en entier est à terre. Une erreur de serveur, une page blanche, un délai qui n'en finit pas. Ton hébergeur dit que c'est ton site, ton développeur dit que c'est l'hébergeur, et pendant ce temps personne ne répare rien.
Le renvoi de balle01
Quand un serveur tombe, la pire perte de temps n'est pas technique : c'est que chacun a intérêt à ce que ce soit la faute de l'autre. L'hébergeur ne veut pas admettre une panne chez lui, le développeur ne veut pas rouvrir un code qu'il a livré il y a un an. Toi, tu es au milieu, et ton site est toujours à terre.
Aujourd'hui, il se peut que j'héberge ton site, ou même que ce soit moi qui l'aie monté : ça arrive. Ce qui ne change jamais, c'est l'intégrité, et c'est mon vrai positionnement. Si la panne vient de mon côté, je te le dis, sans détour. Je fais tout pour ne pas me tromper, mais je suis humain et tout peut lâcher : le jour où c'est ma faute, je l'admets et je la répare, parce que je ne brûlerai pas ma réputation pour te cacher une erreur. Je regarde ce qui est réellement cassé, je te le dis, et je le répare, que ce soit une base de données corrompue, une mémoire épuisée, un disque plein, un certificat échu ou une configuration qui a dérapé.
Ce que je regarde
Mémoire épuisée, disque plein, processus bloqué, service qui ne redémarre pas. Les pannes qui n'ont rien à voir avec ton code.
Table corrompue, connexions saturées, requête qui bloque tout le reste. La cause silencieuse d'une bonne moitié des sites qui rament ou tombent.
Un certificat échu qui bloque tout accès, un DNS mal propagé après un déménagement. Ça met un site entier à terre en silence.
Le site qui tient les jours normaux et tombe le jour de ta grosse promotion. On trouve le goulot avant la prochaine.
Existent-elles vraiment ? Se restaurent-elles ? Une sauvegarde jamais testée n'est pas une sauvegarde : c'est un espoir.
Une mise à jour système, un déploiement, un réglage modifié la veille. La panne a presque toujours une date.
Comment ça marche
L'adresse du site, ton hébergeur, l'erreur exacte si tu en as une. Pour un serveur à terre, c'est souvent le palier Urgence : diagnostic sous 2 h.
Je remonte à la cause réelle, pas à ce qui paraît. Je te dis vite si c'est réparable en place ou s'il faut restaurer.
Je relève le service, je corrige la cause, et je vérifie que ça tient sous une vraie charge avant de te rendre la main.
Ce qui est tombé, pourquoi, l'état de tes sauvegardes, et les gestes qui évitent la récidive.
Si je ne peux pas prendre ton cas, je te le dis tout de suite et je te rembourse en entier. Je ne prends pas ton argent pour te faire attendre.
À quelle profondeur
Le site est à terre maintenant. On le relève d'abord, on soigne la cause ensuite. Pour un serveur down, c'est souvent le palier Urgence.
Il tient, mais tu ne lui fais plus confiance : sauvegardes jamais testées, disque qui se remplit, site qui ralentit. Le Bilan te dit ce qui va lâcher, et quand.
Tu ne veux plus apprendre la panne par un client fâché : un œil dessus en continu.
Avant qu'on commence02
Si tu as une équipe d'infrastructure à l'interne et des dizaines de serveurs, tu as besoin de processus et d'astreinte organisée, pas d'un gars seul. Je conviens à l'entreprise qui a un serveur, deux peut-être, dont tout dépend, et personne dont c'est le métier de le surveiller.
Et sur un hébergement mutualisé fermé, je fais avec les accès que ton hébergeur donne : parfois la vraie réparation est de son côté, et je ne peux pas la faire à sa place. Dans ce cas, je te le dis, je te donne le diagnostic écrit pour le lui mettre sous le nez, et tu arrêtes de te faire renvoyer la balle. C'est déjà la moitié du travail.