Votre application auto-hébergée peut-elle reconstruire sa recherche ? Une checklist de préparation opérationnelle

La recherche est une dépendance opérationnelle, pas seulement une fonctionnalité d’interface

La recherche peut sembler être une fonctionnalité standard d’une application : un champ dans l’en-tête, un filtre sur une page d’enregistrements ou un moyen de trouver du texte dans des fichiers téléversés. Sur le plan opérationnel, il peut s’agir d’un système distinct, avec ses propres données, sa configuration, ses traitements et ses modes de défaillance.

Cette distinction est importante lors d’une restauration, d’une migration ou d’un incident. Restaurer la base de données principale peut restaurer les utilisateurs, les enregistrements et les références aux documents, tout en laissant la recherche vide, obsolète ou incomplète. Un service de recherche séparé peut nécessiter la restauration d’un snapshot, une reconstruction à partir des enregistrements sources, ou les deux. La recherche dans les fichiers peut en outre dépendre d’un stockage de pièces jointes accessible et d’outils d’extraction de texte.

Considérez la recherche comme récupérée uniquement lorsque les utilisateurs peuvent trouver les enregistrements et le contenu des documents appropriés, tandis que les utilisateurs sans autorisation ne peuvent pas découvrir des informations protégées via les résultats, extraits, décomptes ou surbrillances. Le simple fait qu’un service réponde à des requêtes ne prouve pas, à lui seul, que l’expérience de recherche est rétablie.

• Définissez la recherche comme une dépendance dans le plan de récupération de l’application, au même titre que la base de données, le stockage de fichiers, l’identité et la configuration réseau.
• Fixez un objectif de récupération pour une recherche utilisable, et non uniquement pour le démarrage du processus de recherche.
• Désignez un responsable des décisions de récupération de la recherche, de l’exécution de la reconstruction et des tests d’acceptation.
• Documentez si la recherche est nécessaire au travail courant immédiatement après la récupération ou si elle peut être restaurée dans une phase ultérieure.

Cartographiez l’ensemble du chemin de recherche avant de décider quoi sauvegarder

Commencez par une carte des flux de données plutôt que par une hypothèse sur l’architecture d’un produit. Pour chaque élément recherchable, suivez son parcours jusqu’à son apparition dans un résultat. L’enregistrement faisant autorité peut résider dans une base de données relationnelle ; un binaire téléversé peut résider dans un volume de fichiers ou un stockage objet ; le texte extrait peut être stocké séparément ; et un index peut être conservé dans la base de données ou dans un cluster de recherche dédié.

Identifiez également le chemin de requête. L’application peut interroger sa propre base de données, envoyer une requête à un service de recherche distinct, appliquer les règles d’autorisation dans l’application ou s’appuyer sur des attributs de contrôle d’accès indexés. Ces détails déterminent si une reconstruction est faisable et où une défaillance des autorisations pourrait exposer des données.

Une carte utile distingue la source de vérité durable des artefacts dérivés. Elle doit couvrir à la fois les enregistrements structurés et les pièces jointes, car restaurer les métadonnées d’un fichier n’équivaut pas à restaurer le fichier ou le texte qui en a précédemment été extrait.

• Enregistrements faisant autorité : quelles tables de base de données, collections ou API contiennent le titre, le corps, le statut, le propriétaire et les données d’accès de référence ?
• Pièces jointes : où les fichiers originaux sont-ils stockés et sont-ils inclus dans la procédure de sauvegarde et de restauration de l’application ?
• Contenu extrait : le texte est-il généré lors du téléversement, enregistré dans le stockage principal, enregistré dans le système de recherche ou généré uniquement lors de l’indexation ?
• Index : s’agit-il d’un index plein texte de base de données, d’un index de moteur de recherche distinct ou d’une combinaison ?
• Traitement : quels workers, files d’attente, webhooks, tâches planifiées ou commandes manuelles créent et mettent à jour les entrées d’index ?
• Service de requête : quel composant exécute les recherches et de quelle configuration, quels identifiants et quel chemin réseau a-t-il besoin ?
• Autorisation : où les restrictions au niveau de l’enregistrement, du document et du champ sont-elles appliquées ?

Classez l’index : faisant autorité, dérivé ou partiellement dérivé

La question centrale de la récupération n’est pas de savoir si une application possède un index. Elle consiste à déterminer si l’index peut être recréé à partir de données sources conservées et accessibles, à un coût acceptable et dans un délai acceptable.

Un index dérivé peut généralement être reconstruit lorsque les enregistrements de référence, les fichiers et les règles de transformation requises sont conservés. Un snapshot de recherche peut néanmoins avoir de la valeur, car il peut accélérer la restauration, préserver une configuration opérationnelle ou éviter une reconstruction importante. Mais il ne constitue pas l’unique copie des données métier.

Un index faisant autorité ou partiellement faisant autorité exige davantage d’examen. Il peut contenir du texte enrichi, des embeddings, des données historiques, des autorisations, des annotations ou d’autres éléments qui ne peuvent pas être régénérés à partir des données applicatives restaurées. Si ces informations sont nécessaires à une recherche correcte, l’index et sa configuration associée deviennent critiques pour les sauvegardes. Ne supposez pas qu’un snapshot de moteur de recherche contient chaque dépendance : les fichiers externes, les bases de données applicatives et les informations externes d’identité ou d’autorisation peuvent rester en dehors de celui-ci.

Pour les clusters de recherche dédiés, la configuration compte autant que les documents. Elastic indique que les snapshots peuvent inclure des données, de la configuration et des données internes de fonctionnalités, selon le cas d’usage. À l’inverse, l’API Reindex d’Elastic exige que les documents sources soient conservés avec _source activé et ne copie pas les paramètres ni les modèles d’index source vers la destination. Un runbook de reconstruction doit donc identifier les mappings visés, les choix de shards et de réplicas, les modèles et la configuration d’ingestion avant le début des travaux.

• Dérivé : l’ensemble du contenu recherchable et des attributs d’accès peut être régénéré à partir des enregistrements principaux et des fichiers conservés.
• Faisant autorité : une partie du contenu recherchable ou des métadonnées requis existe uniquement dans l’index ou son snapshot.
• Partiellement dérivé : les enregistrements principaux peuvent être reconstruits, mais l’enrichissement, le contenu extrait, les signaux de classement ou les données d’accès peuvent ne pas être reproductibles.
• Inconnu : aucun responsable ne peut démontrer la source, la transformation et la procédure de reconstruction. Traitez cela comme une lacune avant l’adoption ou la mise en production.

Examinez les déclencheurs d’indexation, les files d’attente et la gestion des échecs

Une reconstruction d’index échoue souvent non pas parce que le moteur de recherche est indisponible, mais parce que le processus qui l’alimente ne s’exécute jamais ou abandonne silencieusement du travail. Identifiez chaque événement censé créer, mettre à jour ou supprimer un élément recherchable : création d’enregistrement, modifications, téléversements de pièces jointes, changements d’autorisations, déplacements entre projets ou espaces, suppressions et actions de rétention.

Identifiez ensuite comment ces événements sont transmis. Une application peut indexer de manière synchrone pendant une requête utilisateur, placer le travail dans une file asynchrone, exécuter une tâche planifiée ou exiger une commande administrateur. Chaque modèle a des implications de récupération distinctes. Le travail en file nécessite une politique claire après une restauration : le rejouer, l’abandonner et effectuer une reconstruction complète, ou restaurer l’état de la file si cet état est nécessaire et fiable.

Le comportement en cas d’échec mérite un test direct. OpenSearch indique qu’un processeur d’ingestion défaillant arrête le pipeline par défaut et que le document n’est pas indexé, tandis qu’une gestion optionnelle des échecs peut modifier ce comportement. Sa documentation décrit également la journalisation des échecs et les métriques d’ingestion avec des compteurs d’échecs. Quelle que soit la technologie choisie, les opérateurs doivent pouvoir répondre de manière observable à la question suivante : combien d’éléments ont été soumis, réussis, échoués, réessayés et restent en attente ?

• Listez chaque déclencheur d’indexation, y compris les changements d’autorisation et de suppression.
• Consignez le worker ou l’ordonnanceur responsable de chaque déclencheur et la manière dont il est démarré après restauration.
• Déterminez si les files d’attente sont durables, sauvegardées et sûres à rejouer après une restauration.
• Identifiez les journaux d’erreurs, métriques ou vues d’état qui signalent les travaux d’indexation échoués et en attente.
• Définissez le comportement de nouvelle tentative et le chemin d’escalade pour les éléments ayant échoué définitivement.
• Testez si un élément supprimé ou soumis à des restrictions d’accès est rapidement supprimé ou mis à jour dans la recherche.

Testez la recherche filtrée par autorisation comme un contrôle d’autorisation des données

L’autorisation de recherche doit être évaluée au niveau du résultat. Un utilisateur peut se connecter avec succès et disposer d’un rôle général approprié, tout en recevant un titre, un extrait, une surbrillance, un nombre de résultats ou le texte d’une pièce jointe pour un enregistrement précis auquel il n’est pas autorisé à accéder.

OWASP ASVS exige des autorisations explicites pour des éléments de données spécifiques et l’application de l’autorisation dans une couche de service de confiance, y compris des règles d’accès spécifiques aux données et aux champs. Appliquez ce principe à l’ensemble de l’expérience de recherche, et pas seulement à l’ouverture d’un résultat après son affichage.

C’est particulièrement important après une reconstruction. Si les données d’autorisation sont indexées, elles peuvent être obsolètes ou absentes. Si le filtrage est effectué dans l’application, vérifiez que chaque chemin de requête l’applique. Contrôlez la recherche globale, la recherche avancée, l’autocomplétion, les recherches enregistrées, les exports, les API, les notifications d’arrière-plan ainsi que toute fonctionnalité d’IA ou de récupération qui consomme des résultats de recherche.

• Créez des comptes de test représentant un utilisateur standard, un responsable, un administrateur et, le cas échéant, un utilisateur externe ou restreint.
• Créez ou identifiez des enregistrements présentant volontairement des règles d’accès différentes, y compris une pièce jointe restreinte.
• Recherchez des termes uniques provenant de titres, de texte principal et de contenus de fichiers protégés.
• Vérifiez que les utilisateurs non autorisés ne voient aucun résultat, extrait, surbrillance, décompte ni suggestion révélant du contenu protégé.
• Modifiez l’accès à un élément connu, puis mesurez et vérifiez la façon dont le changement atteint la recherche.
• Répétez les tests après une restauration et après une reconstruction complète de l’index.

Intégrez les pièces jointes et l’extraction de texte dans la conception de récupération

La recherche dans les fichiers constitue un problème de récupération distinct de la recherche dans les enregistrements. Une application peut indexer uniquement les noms de fichiers et les métadonnées, ou extraire le texte de documents pris en charge. Dans ce dernier cas, une reconstruction réussie dépend de la disponibilité, de la lisibilité et, si nécessaire, de la nouvelle fourniture des binaires d’origine au processus d’extraction.

Le plugin ingest-attachment d’OpenSearch est un exemple de ce modèle : il utilise Apache Tika pour extraire du contenu et des métadonnées des fichiers, qui peuvent ensuite être stockés dans un champ de pièce jointe. La documentation d’Apache Tika sur les formats indique clairement que la prise en charge dépend du format et distingue l’extraction des métadonnées de celle du contenu textuel. Votre jeu de tests doit donc représenter les fichiers dont les personnes dépendent réellement, plutôt qu’un simple document texte pratique.

La politique d’extraction affecte l’exhaustivité. Le processeur de pièces jointes d’OpenSearch possède une limite de caractères extraits configurable ; une limite différente peut modifier le contenu qui devient recherchable. Consignez ces limites et les implications en ressources de tout changement. Documentez également le traitement des fichiers chiffrés, des numérisations sans texte exploitable, des téléversements corrompus, des formats rares et des fichiers rejetés par la politique. Une reconstruction ne peut pas récupérer du texte qui n’a jamais pu être extrait, qui n’a jamais été conservé ou qui n’a jamais été indexé avec succès.

• Restaurez et vérifiez l’accès au stockage de pièces jointes d’origine avant de déclarer la recherche dans les fichiers récupérable.
• Maintenez un corpus de test représentatif : documents bureautiques courants, PDF, texte brut, feuilles de calcul, présentations, fichiers numérisés et formats spécialisés importants utilisés par l’équipe.
• Consignez les formats pris en charge et volontairement non pris en charge, ainsi que le comportement attendu pour chacun.
• Consignez les limites d’extraction, les paramètres linguistiques le cas échéant, ainsi que les restrictions de taille ou de sécurité.
• Testez une phrase connue située vers la fin d’un long document représentatif afin de détecter toute troncature.
• Mesurez séparément les décomptes d’extractions et d’indexations échouées, et ceux d’indexation réussie des métadonnées.

Exécutez un test de récupération de la recherche qui mesure une récupération utilisable

Une déclaration écrite de sauvegarde ne prouve pas que la recherche peut être récupérée. NIST SP 800-184 met l’accent sur la planification de la récupération, l’élaboration de playbooks, les tests et l’amélioration. Intégrez la recherche à ce cycle au moyen d’un exercice reproductible.

Utilisez un environnement de test isolé et autorisé. Restaurez les données applicatives principales et les pièces jointes depuis un point de récupération sélectionné, restaurez ou recréez le service de recherche et sa configuration, puis suivez le chemin documenté de reconstruction ou de restauration de snapshot. OpenSearch précise que les snapshots de cluster prennent du temps et ne constituent pas des vues parfaitement simultanées d’un cluster actif ; définissez donc quelle limite de cohérence est acceptable et comment vous gérerez les changements survenant pendant l’activité de sauvegarde.

Le test doit se terminer par des éléments probants, et non par un statut de processus au vert. Comparez les résultats attendus et réels pour un échantillon contrôlé d’enregistrements et de pièces jointes. Confirmez à la fois les résultats positifs pour les utilisateurs autorisés et l’absence de résultats protégés pour les utilisateurs non autorisés. Consignez le temps écoulé pour restaurer les données principales, rendre l’infrastructure de recherche prête, terminer l’indexation, résorber tout retard et réussir la validation. Ce total correspond à la fenêtre de récupération pratique de la recherche.

• Choisissez un point de récupération et documentez son heure et la limite de données attendue.
• Restaurez les enregistrements de référence, les données utilisateur et d’autorisation nécessaires à l’application, ainsi que le stockage de pièces jointes.
• Restaurez le service de recherche depuis un snapshot ou reconstruisez-le à partir de sources conservées, conformément à la conception documentée.
• Réappliquez les modèles d’index, mappings, pipelines d’ingestion, paramètres et configuration d’accès nécessaires avant ou pendant la reconstruction, selon le cas.
• Suivez les totaux d’éléments, la profondeur de file, les échecs de processeur et l’état d’avancement pendant tout l’exercice.
• Validez les recherches de termes exacts sur des enregistrements connus, les phrases attendues dans les pièces jointes et les éléments modifiés ou supprimés.
• Exécutez les tests d’autorisation sur tous les chemins de requête importants.
• Consignez les temps écoulés, exceptions, interventions manuelles et lacunes non résolues ; mettez à jour le runbook avant le test suivant.

Intégrez les services et la configuration de recherche aux enregistrements de sauvegarde, migration et changement

La nécessité de sauvegarder un index lui-même relève d’une décision de conception, et non d’une règle universelle. Un index entièrement dérivé, doté d’une reconstruction testée, peut être recréé plutôt que sauvegardé comme chemin de récupération principal. Un index volumineux, un processus d’extraction lent ou un index partiellement faisant autorité peuvent justifier des snapshots pour réduire l’indisponibilité ou préserver des informations impossibles à recréer.

Si des snapshots sont utilisés, incluez les éléments qui les rendent exploitables. Elastic indique que les snapshots peuvent préserver la configuration et des données internes de fonctionnalités, tandis que la perte des index système ou de l’état du cluster peut entraîner la perte de configuration et d’état des fonctionnalités. Vérifiez précisément ce que le périmètre de snapshot retenu inclut dans votre déploiement, au lieu d’appliquer une hypothèse générique. Pour OpenSearch, tenez compte du fait que le moment d’un snapshot ne correspond pas à une vue parfaitement simultanée à un instant donné.

Le même inventaire soutient les migrations et la gestion des changements. Une modification des mappings, analyseurs, pipelines d’ingestion, limites d’extraction, comportements de file, autorisations ou politiques de rétention peut modifier la qualité de recherche et le comportement de récupération. Capturez la configuration souhaitée sous une forme contrôlée et reproductible, et mettez à jour le runbook de récupération chaque fois que la conception de recherche change.

Airbip propose un déploiement géré d’applications du catalogue sous forme de charges de travail Docker sur des serveurs cloud Airbip, ainsi que la gestion du cycle de vie des services et des sauvegardes quotidiennes, hebdomadaires et mensuelles configurables. Ces capacités peuvent soutenir le volet infrastructure d’un déploiement applicatif. L’équipe applicative doit toujours déterminer ce que stocke l’application choisie, comment sa recherche est construite et qui valide la récupération des données, pièces jointes, autorisations et comportements de recherche.

• Inventoriez les sauvegardes de base de données, les sauvegardes de pièces jointes, les snapshots de recherche, les exports de configuration et les secrets ou identifiants requis par la procédure de récupération.
• Documentez la rétention, les attentes de point de récupération et le responsable de la restauration pour chaque artefact.
• Consignez les hypothèses de compatibilité des composants applicatifs, de base de données, d’extraction et de recherche avant de les modifier.
• Décidez si la restauration de snapshot, la reconstruction complète ou une combinaison par étapes constitue le chemin privilégié.
• Exigez une revue de l’impact sur la recherche pour les modifications de schéma, de traitement de fichiers, d’autorisation et de flux d’indexation.
• Conservez un enregistrement daté du dernier exercice de récupération réussi et des lacunes constatées.