Pular para o conteúdo principal

Operação e implantação

Safari é a interface de controle do Sombra. Cada mudança de cobertura fica no request persistido; cada carga mantém uma execução auditável cujo estado evolui entre pendente, executando, concluída ou falha. O snapshot de receptores de uma publicação concluída é imutável.

No primeiro acesso administrativo, use Criar primeiro acesso e confirme o código enviado a um endereço autorizado. Depois que o External ID criar a identidade local no tenant Lapis, use Entrar; informar um e-mail ainda não cadastrado na tela de sign-in resulta corretamente em “conta não encontrada”.

Sequência de implantação​

  1. quando a identidade mudar, reconciliar no tenant External ID exclusivo da Lapis os registros, redirects, scope, roles e o user flow com ops/identity/bootstrap-external-id.ps1; o Sombra não possui login;
  2. fornecer ao processo a senha administrativa SQL já vigente, obtida por um canal seguro; rotação é uma operação separada;
  3. confirmar main limpa e idêntica a origin/main e executar localmente as validações Bicep, .NET e Angular antes da primeira mutação Azure;
  4. enviar o snapshot CNPJ ao caminho imutável identificado por SHA-256, parar o worker e reconciliar a infraestrutura;
  5. publicar e iniciar explicitamente o worker proprietário das migrações;
  6. publicar a API e aguardar ready, que só responde 200 depois da edição CNAE configurada, da publicação-base correspondente ao snapshot e à política versionada, da publicação SQL corrente e de sua contagem exata no Search;
  7. publicar o web app por último, já apontando para um backend pronto;
  8. executar ops/smoke/production-smoke.sh nos domínios públicos e reconciliar o SHA servido por web, API e worker.

O Bicep referencia o App Service Plan e a zona DNS como recursos existentes. Um deploy do Sombra não altera SKU, capacidade, sites legados ou os registros da landing sombra.lapis.ind.br.

Os domínios já ativos não são reconfigurados no deploy normal. A flag CONFIGURE_CUSTOM_DOMAINS=true é reservada ao bootstrap inicial de DNS e certificados. Se o deploy falhar depois de parar o worker, o script tenta reiniciá-lo antes de sair.

Critérios de saúde​

  • Web, API e worker respondem seus health checks;
  • uma rota protegida da API devolve 401 sem token;
  • o catálogo contém uma edição CNAE ativa que passou pela validação estrutural;
  • cada execução conclui ou deixa erro reprocessável, nunca estado órfão;
  • em estado ready, o alias do Search aponta para a geração da última ingestão concluída e sua contagem reconcilia com a publicação SQL correspondente;
  • as filas independentes de ingestão e cruzamento estão acessíveis;
  • no aceite público, uma análise iniciada pelo Sombra retorna receptores e registra a edição CNAE, a publicação de receptores, a versão do motor e a trilha explicável de cada candidato usadas;
  • o pico de memória do plano permanece abaixo do limite operacional.

Aumento de cobertura​

O operador publica outra política com percentual/teto maior. A seleção determinística preserva os itens anteriores, o worker percorre a fonte por streaming e promove uma nova geração completa do índice depois de gravá-la. Não se cria outro serviço nem um caminho especial para “escala”.

O adaptador inicial lê um snapshot CNPJ normalizado e com limite operacional. A cobertura integral exige publicar os arquivos completos da RFB nesse mesmo contrato e elevar conscientemente os limites de leitura e armazenamento; ela não é obtida apenas alterando o percentual enquanto esses guardrails estiverem ativos.

Limites e recuperação​

  • PDF: 30 MiB por arquivo e por request multipart;
  • snapshot CNPJ inicial: 100 MiB e 100 mil registros lidos;
  • crawler CNAE: 2.500 páginas e validação de mínimos por nível;
  • planos expostos no Safari: 100 ou até 3.000 selecionados;
  • consultas de receptores: até 100 resultados por busca; a interface envia o termo ao servidor, portanto não pesquisa apenas no primeiro lote local;
  • o processamento admite cinco tentativas; uma sexta entrega de recuperação terminaliza no SQL uma tentativa interrompida e faz o runtime mover a mensagem para ingestion-commands-poison ou matching-commands-poison.

Para reprocessar uma poison, primeiro corrija a causa indicada na execução SQL, e, na mesma transação administrativa controlada, devolva seu status a Pending e zere AttemptCount; só então republique o envelope original na fila correspondente. Sem o reset a execução é consumida como no-op depois da quinta tentativa. Nunca promova o alias ou marque a execução como concluída manualmente. Se uma promoção Search falhar, o worker restaura o alias da última publicação SQL concluída.