Quand la sauvegarde nocturne fait tomber vos services

Un service de synchronisation d’agendas et de contacts, utilisé chaque jour par toute l’équipe, tombe en panne toutes les nuits vers 3h du matin. Chaque matin, il faut le relancer manuellement. Le système de surveillance envoie bien une alerte « service indisponible », mais ne dit rien sur la cause. Pour comprendre ce qu’il se passe, il faut mobiliser la seule personne qui connaît l’infrastructure par cœur, pendant plusieurs heures.

Cet article raconte comment on a diagnostiqué ce problème (et deux autres au passage) et ce que cette expérience montre sur la différence entre « surveiller » et « comprendre ».

Après une migration, des anomalies sans lien apparent

Une quarantaine de services venaient d’être migrés vers une nouvelle architecture, répartis sur deux serveurs. La migration s’était bien passée. Mais les semaines suivantes ont révélé des anomalies : un service de synchronisation s’arrêtait chaque nuit sans explication, une base de données redémarrait en boucle sans jamais se stabiliser et des lenteurs intermittentes apparaissaient sur certains services sans cause évidente.

Vu de l’extérieur, ces trois problèmes semblaient décorrélés. Rien ne laissait penser qu’ils avaient un point commun.

Un système de surveillance basique était déjà en place sur les services les plus importants. Il envoyait des alertes quand un service tombait et faisait bien son travail : chaque matin, l’alerte « service indisponible » arrivait pour le service d’agendas. Mais ces alertes ne disaient qu’une chose : c’est en panne. Jamais pourquoi. Le système de collecte de journaux, qui aurait pu aider à creuser, n’avait pas encore été remis en service après la migration.

Ce qu’on a découvert en creusant

Le diagnostic a été fait manuellement : lecture des journaux du serveur, recoupement des horaires entre événements, tests de correction un par un. Voici les deux problèmes les plus parlants parmi les six identifiés ce jour-là.

Un service qui tombe chaque nuit sans explication

Chaque matin vers 3h, le service de synchronisation d’agendas et cinq autres applications s’arrêtaient silencieusement. Aucune erreur dans leurs propres journaux. Juste un trou dans l’activité.

En recoupant les horaires, la cause est apparue : la sauvegarde automatique nocturne du serveur provoquait un redémarrage bref du moteur qui fait tourner les applications. Ces applications étaient configurées avec une règle de relance héritée de l’ancienne architecture, qui disait « redémarre-moi, sauf si quelqu’un m’a arrêté volontairement ». Le redémarrage du moteur mimait un arrêt volontaire et les applications refusaient de repartir.

Le diagnostic a pris 30 minutes, mais uniquement parce que la personne qui a enquêté savait que les sauvegardes tournaient à 3h. Sans cette connaissance, la recherche aurait pu prendre des heures. Ce service était indisponible chaque nuit depuis la migration, soit plusieurs jours, sans que la cause ne soit identifiée.

Une base de données bloquée en boucle de redémarrage

La base de données d’une application de gestion documentaire ne parvenait plus à démarrer. Elle redémarrait en boucle, indéfiniment.

La cause : une incompatibilité entre la couche de stockage du serveur et le fonctionnement interne de la base de données. Un fichier temporaire, nécessaire au démarrage, ne pouvait pas être créé correctement dans cet environnement. La correction a consisté à isoler ce fichier temporaire dans un espace mémoire dédié, sans toucher aux données elles-mêmes.

Temps de diagnostic : 20 minutes. Mais cette panne durait probablement depuis la migration, sans que personne ne s’en rende compte : la base de données n’était pas couverte par le système de surveillance en place.

Avec du recul : ce qu’on aurait fait autrement

Le diagnostic a fonctionné, mais il a reposé sur deux choses fragiles : du temps d’expert et une connaissance implicite de l’infrastructure. Voici ce qui aurait changé avec les bons outils en place.

Le constat est net : la surveillance de disponibilité (« est-ce que ça marche ? ») est la base. Elle était en place et a fait son travail. Mais elle ne répond pas à la question qui compte vraiment quand un incident survient : « pourquoi ça ne marche pas ? ». Et quand une seule personne détient la connaissance nécessaire pour répondre à cette question, chaque incident expose l’organisation à une dépendance forte sur un individu.

Ce que ça change concrètement pour une PME

Sur ce cas précis : environ 2 heures de diagnostic manuel par un expert qui connaît l’infrastructure. Un service indisponible chaque nuit depuis plusieurs jours. Une base de données en panne depuis une durée indéterminée. Et des lenteurs dont l’impact réel reste inconnu, faute de mesures.

Avec les bons outils en place, les alertes auraient été immédiates et le diagnostic de chaque problème aurait pris quelques minutes, y compris pour quelqu’un qui découvre l’infrastructure.

Cette situation se retrouve dans de nombreuses PME : une seule personne « sait comment ça marche », les outils de surveillance sont partiels, souvent limités à un « ça tourne / ça ne tourne pas ». On pare au plus pressé. Et des pannes silencieuses s’accumulent, parce que personne n’a les moyens de les voir.

La vraie question n’est pas « est-ce que je surveille mon infrastructure ? ». C’est plutôt : « est-ce que je peux comprendre rapidement la cause d’un incident , sans dépendre d’une seule personne ? »

Surveiller et comprendre : deux niveaux différents

Le monitoring répond à « est-ce que ça marche ? ». C’est la base et elle est souvent au moins partiellement en place. Mais quand un service tombe, la question utile est « pourquoi ? ». C’est là que la majorité des organisations sont démunies, surtout quand la connaissance de l’infrastructure repose sur une seule tête.

Ce cas le montre bien : le problème n’était pas l’absence de surveillance, mais l’absence de compréhension. Si vous avez un doute sur votre propre capacité à diagnostiquer rapidement un incident, c’est le bon moment pour évaluer ce point concrètement.