A sua aplicação auto-hospedada consegue reconstruir a pesquisa? Uma lista de verificação de prontidão operacional

A pesquisa é uma dependência operacional, não apenas uma funcionalidade da interface

A pesquisa pode parecer uma funcionalidade padrão de uma aplicação: uma caixa no cabeçalho, um filtro numa página de registos ou uma forma de encontrar texto em ficheiros carregados. Do ponto de vista operacional, pode ser um sistema separado, com os seus próprios dados, configuração, tarefas de processamento e modos de falha.

Esta distinção é importante durante uma restauração, migração ou incidente. Restaurar a base de dados primária pode restaurar utilizadores, registos e referências a documentos, mas deixar a pesquisa vazia, desatualizada ou incompleta. Um serviço de pesquisa separado pode exigir a restauração de um snapshot, uma reconstrução a partir dos registos de origem, ou ambas. A pesquisa em ficheiros pode depender adicionalmente de armazenamento de anexos acessível e de ferramentas de extração de texto.

Considere a pesquisa recuperada apenas quando os utilizadores conseguem encontrar os registos e conteúdos de documentos adequados, enquanto os utilizadores sem permissão não conseguem descobrir informações protegidas por meio de resultados, excertos, contagens ou destaques. Um serviço responder a consultas não é, por si só, prova de uma experiência de pesquisa recuperada.

• Defina a pesquisa como uma dependência no plano de recuperação da aplicação, juntamente com a base de dados, o armazenamento de ficheiros, a identidade e a configuração de rede.
• Estabeleça um objetivo de recuperação para uma pesquisa utilizável, não apenas para o arranque do processo de pesquisa.
• Atribua um responsável pelas decisões de recuperação da pesquisa, pela execução da reconstrução e pelos testes de aceitação.
• Documente se a pesquisa é necessária para o trabalho de rotina imediatamente após a recuperação ou se pode ser restaurada numa fase posterior.

Mapeie todo o percurso da pesquisa antes de decidir o que deve ter backup

Comece por um mapa de fluxo de dados, em vez de uma suposição sobre a arquitetura de um produto. Para cada item pesquisável, acompanhe como se torna um resultado. O registo autoritativo pode residir numa base de dados relacional; um ficheiro binário carregado pode residir num volume de ficheiros ou em armazenamento de objetos; o texto extraído pode ser guardado separadamente; e um índice pode estar na base de dados ou num cluster de pesquisa dedicado.

Identifique também o percurso da consulta. A aplicação pode consultar a sua própria base de dados, enviar um pedido para um serviço de pesquisa separado, aplicar regras de permissão na aplicação ou depender de atributos de controlo de acesso indexados. Estes detalhes determinam se uma reconstrução é viável e onde uma falha de permissões pode expor dados.

Um mapa útil distingue a fonte de verdade durável dos artefactos derivados. Deve abranger tanto registos estruturados como anexos, porque restaurar metadados sobre um ficheiro não é equivalente a restaurar o ficheiro ou o texto anteriormente extraído dele.

• Registos autoritativos: Que tabelas, coleções ou APIs da base de dados contêm o título, corpo, estado, proprietário e dados de acesso canónicos?
• Anexos: Onde são guardados os ficheiros originais e estão incluídos no procedimento de backup e restauração da aplicação?
• Conteúdo extraído: O texto é gerado no momento do carregamento, guardado no armazenamento primário, guardado no sistema de pesquisa ou gerado apenas durante a indexação?
• Índice: É um índice de texto completo da base de dados, um índice de motor de pesquisa separado ou uma combinação?
• Processamento: Que workers, filas, webhooks, tarefas agendadas ou comandos manuais criam e atualizam entradas do índice?
• Serviço de consulta: Que componente executa pesquisas e de que configuração, credenciais e percurso de rede necessita?
• Autorização: Onde são aplicadas as restrições ao nível do registo, documento e campo?

Classifique o índice: autoritativo, derivado ou parcialmente derivado

A questão central da recuperação não é saber se uma aplicação tem um índice. É saber se o índice pode ser recriado a partir de dados de origem retidos e acessíveis, a um custo aceitável e dentro de um prazo aceitável.

Um índice derivado pode, em geral, ser reconstruído quando os registos canónicos, ficheiros e regras de transformação necessárias são retidos. Um snapshot de pesquisa pode continuar a ser valioso porque pode encurtar a restauração, preservar a configuração operacional ou evitar uma grande reconstrução. Mas não é a única cópia dos dados empresariais.

Um índice autoritativo ou parcialmente autoritativo exige maior escrutínio. Pode conter texto enriquecido, embeddings, dados históricos, permissões, anotações ou outro material que não pode ser regenerado a partir dos dados restaurados da aplicação. Se essas informações forem necessárias para uma pesquisa correta, o índice e a sua configuração associada tornam-se críticos para backup. Não presuma que um snapshot do motor de pesquisa contém todas as dependências: ficheiros externos, bases de dados da aplicação e informações externas de identidade ou autorização podem ficar fora dele.

Para clusters de pesquisa dedicados, a configuração importa tanto quanto os documentos. A documentação da Elastic sobre snapshots e restauro (https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore) indica que os snapshots podem incluir dados, configuração e dados internos de funcionalidades, consoante o caso de utilização. Por outro lado, a API Reindex da Elastic (https://www.elastic.co/docs/api/doc/elasticsearch/v8/operation/operation-reindex) exige documentos de origem retidos com _source ativado e não copia as definições ou modelos do índice de origem para o destino. Assim, um runbook de reconstrução tem de identificar os mapeamentos pretendidos, os shards (fragmentos), as réplicas, os modelos e a configuração de ingestão antes do início do trabalho.

• Derivado: todo o conteúdo pesquisável e os atributos de acesso podem ser regenerados a partir de registos primários e ficheiros retidos.
• Autoritativo: algum conteúdo ou metadado pesquisável necessário existe apenas no índice ou no respetivo snapshot.
• Parcialmente derivado: os registos principais podem ser reconstruídos, mas o enriquecimento, conteúdo extraído, sinais de classificação ou dados de acesso podem não ser reproduzíveis.
• Desconhecido: nenhum responsável consegue demonstrar a origem, transformação e procedimento de reconstrução. Trate isto como uma lacuna antes da adoção ou entrada em produção.

Inspecione os gatilhos de indexação, as filas e o tratamento de falhas

Uma reconstrução do índice falha frequentemente não porque o motor de pesquisa está indisponível, mas porque o processo que o alimenta nunca é executado ou descarta trabalho silenciosamente. Identifique cada evento que deve criar, atualizar ou remover um item pesquisável: criação de registos, edições, carregamento de anexos, alterações de permissões, movimentações entre projetos ou espaços, eliminação e ações de retenção.

Em seguida, identifique como esses eventos são entregues. Uma aplicação pode indexar de forma síncrona durante um pedido do utilizador, colocar trabalho numa fila assíncrona, executar uma tarefa agendada ou exigir um comando de administrador. Cada modelo tem implicações distintas para a recuperação. O trabalho em fila necessita de uma política clara após uma restauração: repeti-lo, descartá-lo e realizar uma reconstrução completa, ou restaurar o estado da fila se esse estado for necessário e fiável.

O comportamento em caso de falha merece um teste direto. A documentação do OpenSearch sobre falhas de pipelines (https://docs.opensearch.org/latest/ingest-pipelines/pipeline-failures/) indica que um processador de ingestão com falha interrompe o pipeline por predefinição e o documento não é indexado, enquanto o tratamento opcional de falhas pode alterar esse comportamento. A documentação também descreve registo de falhas e métricas de ingestão com contagens de falhas. Independentemente da tecnologia escolhida, os operadores necessitam de uma resposta observável para: quantos itens foram submetidos, concluídos com êxito, falharam, foram repetidos e continuam pendentes?

• Liste todos os gatilhos de indexação, incluindo alterações de permissões e eliminações.
• Registe o worker ou agendador responsável por cada gatilho e como é iniciado após a restauração.
• Determine se as filas são duráveis, têm backup e podem ser repetidas em segurança após uma restauração.
• Localize os registos de erro, métricas ou vistas de estado que identificam trabalho de indexação falhado e pendente.
• Defina o comportamento de repetição e o caminho de escalonamento para itens que falham permanentemente.
• Teste se um item eliminado ou com acesso restringido é removido ou atualizado na pesquisa atempadamente.

Teste a pesquisa filtrada por permissões como um controlo de autorização de dados

A autorização de pesquisa deve ser avaliada ao nível do resultado. Um utilizador pode iniciar sessão com êxito e ter uma função ampla apropriada, mas ainda receber um título, excerto, destaque, contagem de resultados ou texto de anexo de um registo específico ao qual não tem permissão para aceder.

O OWASP ASVS exige permissões explícitas para itens de dados específicos e aplicação da autorização numa camada de serviço fidedigna, incluindo regras de acesso a dados específicos e ao nível do campo. Consulte a secção de autorização do OWASP ASVS 5.0: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x17-V8-Authorization.md. Aplique esse princípio a toda a experiência de pesquisa, e não apenas à abertura de um resultado depois de este ser apresentado.

Isto é particularmente importante após uma reconstrução. Se os dados de permissões forem indexados, podem estar desatualizados ou em falta. Se a filtragem ocorrer na aplicação, verifique que todos os percursos de consulta a aplicam. Verifique a pesquisa global, a pesquisa avançada, o preenchimento automático, pesquisas guardadas, exportações, APIs, notificações em segundo plano e qualquer funcionalidade de IA ou recuperação que consuma resultados de pesquisa.

• Crie contas de teste que representem um utilizador normal, um gestor, um administrador e, quando relevante, um utilizador externo ou restrito.
• Crie ou identifique registos com regras de acesso deliberadamente diferentes, incluindo um anexo restrito.
• Pesquise termos únicos de títulos protegidos, texto do corpo e conteúdos de ficheiros.
• Verifique que utilizadores não autorizados não veem qualquer resultado, excerto, destaque, contagem ou sugestão que revele conteúdo protegido.
• Altere o acesso a um item conhecido e, em seguida, meça e verifique como a alteração chega à pesquisa.
• Repita os testes após uma restauração e após uma reconstrução completa do índice.

Inclua anexos e extração de texto no desenho da recuperação

A pesquisa em ficheiros é um problema de recuperação separado da pesquisa em registos. Uma aplicação pode indexar apenas nomes de ficheiros e metadados, ou pode extrair texto do corpo de documentos suportados. Neste último caso, uma reconstrução bem-sucedida depende de os binários originais estarem disponíveis, legíveis e serem fornecidos novamente ao processo de extração quando necessário.

O plugin ingest-attachment do OpenSearch é um exemplo deste padrão: utiliza o Apache Tika para extrair conteúdo e metadados de ficheiros, que podem depois ser armazenados num campo de anexo. Consulte a documentação do plugin: https://docs.opensearch.org/latest/install-and-configure/additional-plugins/ingest-attachment-plugin/. A documentação de formatos do Apache Tika (https://tika.apache.org/3.2.2/formats.html) deixa claro que o suporte é específico de cada formato e distingue a extração de metadados da extração de conteúdo textual. Por isso, o seu conjunto de testes deve representar os ficheiros dos quais as pessoas realmente dependem, em vez de incluir apenas um documento de texto conveniente.

A política de extração afeta a completude. O processador de anexos do OpenSearch tem um limite de caracteres extraídos que pode ser configurado; um limite diferente pode alterar o que se torna pesquisável. Registe esses limites e as implicações de recursos de qualquer alteração. Documente também o tratamento de ficheiros encriptados, digitalizações sem texto utilizável, carregamentos corrompidos, formatos pouco comuns e ficheiros rejeitados por política. Uma reconstrução não consegue recuperar texto que nunca foi extraível, nunca foi retido ou nunca foi indexado com êxito.

• Restaure e verifique o acesso ao armazenamento de anexos original antes de declarar a pesquisa em ficheiros recuperável.
• Mantenha um corpus de teste representativo: documentos de escritório comuns, PDFs, texto simples, folhas de cálculo, apresentações, ficheiros digitalizados e formatos especializados importantes utilizados pela equipa.
• Registe formatos suportados e deliberadamente não suportados, bem como o comportamento esperado para cada um.
• Registe limites de extração, definições de idioma quando aplicável, e quaisquer restrições de tamanho ou segurança.
• Teste uma frase conhecida perto do fim de um documento representativo longo para detetar truncamento.
• Meça contagens de falhas de extração e indexação separadamente da indexação bem-sucedida de metadados.

Execute um teste de recuperação da pesquisa que meça a recuperação utilizável

Uma declaração escrita sobre backups não é prova de que a pesquisa pode ser recuperada. O NIST SP 800-184 enfatiza o planeamento da recuperação, o desenvolvimento de playbooks, os testes e a melhoria. Consulte a publicação do NIST: https://csrc.nist.gov/pubs/sp/800/184/final. Integre a pesquisa nesse ciclo com um exercício repetível.

Utilize um ambiente de teste isolado e autorizado. Restaure os dados primários da aplicação e os anexos a partir de um ponto de recuperação selecionado, restaure ou recrie o serviço de pesquisa e a respetiva configuração e, em seguida, siga o percurso documentado de reconstrução ou restauração de snapshot. O OpenSearch observa que os snapshots de clusters demoram tempo e não são vistas perfeitamente simultâneas de um cluster em produção; consulte a documentação de snapshots e restauro: https://docs.opensearch.org/latest/tuning-your-cluster/availability-and-recovery/snapshots/snapshot-restore/. Defina que limite de consistência é aceitável e como irá tratar alterações que ocorram durante a atividade de backup.

O teste deve terminar com evidências, não com um estado de processo verde. Compare resultados esperados e reais para uma amostra controlada de registos e anexos. Confirme tanto os resultados positivos para utilizadores autorizados como a ausência de resultados protegidos para utilizadores não autorizados. Registe o tempo decorrido para restaurar os dados primários, deixar a infraestrutura de pesquisa pronta, concluir a indexação, eliminar qualquer atraso acumulado e passar a validação. Esse total é a janela prática de recuperação da pesquisa.

• Escolha um ponto de recuperação e documente a sua hora e o limite esperado dos dados.
• Restaure os registos canónicos, os dados de utilizadores e autorização necessários à aplicação e o armazenamento de anexos.
• Restaure o serviço de pesquisa a partir de um snapshot ou reconstrua-o a partir de fontes retidas, de acordo com o desenho documentado.
• Reaplique os modelos de índice, mapeamentos, pipelines de ingestão, definições e configuração de acesso necessários antes ou durante a reconstrução, conforme apropriado.
• Acompanhe os totais de itens, a profundidade da fila, as falhas de processadores e o estado de conclusão durante todo o exercício.
• Valide pesquisas por termos exatos para registos conhecidos, frases esperadas em anexos e itens alterados ou eliminados.
• Execute testes de permissões em todos os percursos de consulta relevantes.
• Registe tempos decorridos, exceções, intervenções manuais e lacunas não resolvidas; atualize o runbook antes do próximo teste.

Inclua os serviços e a configuração de pesquisa nos registos de backup, migração e alterações

A necessidade de fazer backup do próprio índice é uma decisão de desenho, e não uma regra universal. Um índice totalmente derivado com uma reconstrução testada pode ser recriado em vez de ter backup como percurso principal de recuperação. Um índice grande, um processo de extração lento ou um índice parcialmente autoritativo podem justificar snapshots para reduzir indisponibilidade ou preservar informações que não podem ser recriadas.

Se forem utilizados snapshots, inclua os elementos que os tornam utilizáveis. A Elastic indica que os snapshots podem preservar configuração e dados internos de funcionalidades, enquanto a perda de índices de sistema ou do estado do cluster pode significar perda de configuração e estado de funcionalidades. Consulte a documentação da Elastic sobre snapshots e restauro: https://www.elastic.co/docs/deploy-manage/tools/snapshot-and-restore. Verifique exatamente o que o âmbito do snapshot selecionado inclui na sua implementação, em vez de aplicar uma suposição genérica. No OpenSearch, tenha em conta que o momento do snapshot não é uma vista pontual perfeitamente simultânea.

O mesmo inventário apoia migrações e gestão de alterações. Uma alteração a mapeamentos, analisadores, pipelines de ingestão, limites de extração, comportamento de filas, permissões ou políticas de retenção pode alterar a qualidade da pesquisa e o comportamento de recuperação. Registe a configuração pretendida de forma controlada e reproduzível e atualize o runbook de recuperação sempre que o desenho da pesquisa mudar.

A Airbip disponibiliza implementação gerida para aplicações de catálogo como workloads Docker em servidores cloud da Airbip, juntamente com gestão do ciclo de vida do serviço e backups diários, semanais e mensais configuráveis. Essas capacidades podem apoiar o lado de infraestrutura de uma implementação de aplicação. A equipa da aplicação continua a precisar de determinar o que a aplicação escolhida armazena, como a sua pesquisa é construída e quem valida a recuperação de dados, anexos, permissões e comportamento de pesquisa.

• Faça o inventário de backups da base de dados, backups de anexos, snapshots de pesquisa, exportações de configuração e segredos ou credenciais necessários ao procedimento de recuperação.
• Documente a retenção, as expectativas de ponto de recuperação e a responsabilidade pela restauração de cada artefacto.
• Registe pressupostos de compatibilidade para componentes de aplicação, base de dados, extração e pesquisa antes de os alterar.
• Decida se a restauração de snapshot, a reconstrução completa ou uma combinação faseada é o percurso preferencial.
• Exija uma análise do impacto na pesquisa para alterações ao esquema, tratamento de ficheiros, autorização e fluxos de trabalho de indexação.
• Mantenha um registo datado do último exercício de recuperação bem-sucedido e das lacunas encontradas.