Date de début de l’incident: 26/01/2024 à 12h20Date de fin de l’incident : 05/02/2024 à 11h04Type d’incident : Critique
Précisons tout d’abord qu’une indisponibilité de la base de données d’ITEM ne concerne en rien les exemplaires créés dans le Sudoc ; ces deux processus sont distincts. Ainsi, l’absence de visualisation d’une demande dans le tableau de bord ne reflète pas un problème dans le traitement réel des opérations dans le Sudoc.
De même, il convient de distinguer les fichiers de traitement des informations relatives aux demandes. En cas d’incident sur la base de données, les fichiers de demande sont stockés sur les serveurs de l’Abes et peuvent être retrouvés à partir de leur numéro. Cependant, cela nécessite que l’utilisateur ait mémorisé ce numéro, car il n’est pas possible de retrouver une demande à partir de l’ILN et/ou du RCR. Une réflexion sera menée sur ce point.
Symptômes et impacts de l’incident
Le 26 janvier, un utilisateur constate que ses tableaux de bord sont vides et que le système lui demande de saisir son adresse e-mail après authentification, un comportement anormal puisque cela ne se produit habituellement qu’à la première connexion.
Mesures prises : fermeture de l’application ITEM et envoi d’un mail d’alerte aux professionnels des réseaux.
Le problème identifié révèle un dysfonctionnement de la base de données d’ITEM. Une recherche de solutions de restauration à partir des sauvegardes est entreprise. Cependant, au 29 janvier 2024, les sauvegardes journalières de la base de donnée s’avèrent vides … depuis le 26 février 2023, un problème dont la source réside dans un désaccord (mismatch) de version entre le serveur PostgreSQL (version 15.1) et l’outil de sauvegarde (version 14.4), qui empêchait la création de dumps valides. Rappelons qu’un dump représente un instantané de la base de données de l’application contenant toutes les informations relatives aux demandes créées (l’index, le type de demande, etc.).
Mesure prise pour résoudre le problème de compatibilité : mise à jour de l’outil de sauvegarde vers la dernière version (4.0.35)
Le dernier fichier de sauvegarde disponible datant du 26 février 2023, il s’ avère nécessaire de tester la capacité de restauration en environnement de développement. Il a tout d’abord fallu décider quelle base de données utiliser pour la relance d’ITEM : les sauvegardes du 26 février 2023 ou une base vide ? Ensuite, avant la réouverture en production, il a été nécessaire d’activer les traces SQL de PostgreSQL puis de mettre à jour le dumper vers la dernière version (4.0.35).
Causes et solutions
Du fait du manque de logs, la cause précise de l’incident n’a pas été identifiée avec certitude. Le principal soupçon réside dans un effet de bord d’un paramétrage spring ou d’un batch au sein d’ITEM.
À la suite de l’incident, des mesures ont été prises pour prévenir de futures occurrences similaires. Elles incluent la modification des emplacements de sauvegarde, l’ajout de sondes de surveillance, la notification de l’état des sauvegardes, la réalisation de tests de restauration réguliers, et la réparation du système de logs.
Une certitude : en cas de récidive de l’incident, l’Abes sera en mesure de restaurer plus rapidement – dans la journée en cours – les données relatives aux demandes.