Migração certificada por testes para bases de código SAS corporativas
O seu parque SAS funciona. Milhares de programas, macros, formatos e tarefas agendadas foram refinados ao longo de anos, e boa parte do que fazem não está documentada em lugar nenhum além do próprio código. Levar isso para qualquer plataforma nova, por mais compatível que seja, traz um risco real: algo que antes estava certo passa a estar sutilmente errado, e ninguém percebe até que isso conte.
A Jenner Professional Services remove esse risco com uma disciplina simples. Antes de mudarmos qualquer coisa, construímos um registo completo e executável do que o seu sistema atual faz. Depois usamos esse registo para provar, teste a teste, que o sistema migrado faz o mesmo.
O resultado é uma migração que pode aprovar com provas em vez de confiança, e uma suíte de regressão que fica consigo para sempre.
Somos especialistas em SAS, como demonstra o facto de termos criado uma implementação completa dessa linguagem e desse sistema. Migrar para ele, porém, é apenas um dos caminhos que pode seguir connosco.
Podemos usar a nossa implementação de código compatível com SAS, e as nossas práticas orientadas por testes, para garantir uma migração bem-sucedida para Python ou R, para Snowflake ou Databricks, ou para outras soluções — incluindo o Siemens SLC.
Defendemos a migração para o Jenner porque é simultaneamente mais rápida, menos complexa e de menor custo para empresas que já têm uma infraestrutura SAS.
O Jenner executa a linguagem SAS, quase todos os procedimentos, a facilidade de macros, os gráficos e uma ampla gama de ligações de dados. Para a maior parte do código, migrar é apontar o Jenner para os mesmos programas. Mas uma base de código corporativa nunca é apenas a linguagem. É também tudo aquilo em que a linguagem toca:
autoexec.sas, ficheiros de configuração, opções de sistema (ENCODING, LOCALE, YEARCUTOFF, VALIDVARNAME, FMTSEARCH, SASAUTOS), variáveis de ambiente, SYSPARM, e o tamanho e o tempo de vida da biblioteca WORK.
Palavras-passe embutidas em instruções LIBNAME, cadeias codificadas com {SAS002}, credenciais em ficheiros incluídos por %include, tickets Kerberos ou SSO, e a questão de onde tudo isso deveria residir em vez disso.
Motores SAS/ACCESS para Oracle, DB2, Teradata, SQL Server, Snowflake, Hive e outros; SQL de passagem explícito e implícito; opções de motor que afetam resultados (DBCOMMIT, READBUFF, INSERTBUFF, BULKLOAD); mapeamento de tipos para datas, decimais e NULL; e comportamento que mudou discretamente quando o SQL passou a ser empurrado para a base de dados em vez de executado localmente.
Caminhos escritos no código, letras de unidade do Windows face a montagens Linux, nomes de ficheiro sensíveis a maiúsculas, partilhas NFS e SMB, comandos FILENAME PIPE e X, SYSGET e permissões de ficheiros.
Catálogos de formatos, macros compiladas ou armazenadas, índices, trilhos de auditoria, vistas, bibliotecas SPDE, ficheiros de transporte, conjuntos de dados cifrados ou comprimidos, e conjuntos de dados da era V6/V8 que precisam de ser regenerados em vez de copiados.
Blocos RSUBMIT do SAS/CONNECT, Grid, SAS/SHARE, Stored Processes, autorização pelo servidor de metadados, projetos do Enterprise Guide, tarefas geradas pelo DI Studio e ações CAS do Viya. Cada um tem um equivalente na nova plataforma, mas não um equivalente idêntico.
LSF, Control-M, cron, dependências entre tarefas, convenções de códigos de retorno, analisadores de logs que procuram texto NOTE/WARNING/ERROR específico, lógica SYSERR e SYSCC, e alertas FILENAME EMAIL.
Destinos ODS PDF, RTF, Excel e HTML, estilos PROC TEMPLATE, tagsets, tipos de letra, controladores de dispositivos gráficos, e relatórios que os consumidores a jusante interpretam por posição.
Arredondamento de vírgula flutuante nos limites, colação de ordenação e ordem dos empates, fluxos de números aleatórios (RANUNI, RAND, STREAMINIT) que não são reprodutíveis entre implementações, e procedimentos iterativos cujo caminho de convergência pode diferir dentro da tolerância.
Variáveis não inicializadas, remerging do PROC SQL, RETAIN implícito, avisos de truncagem tratados como normais, e comportamento não documentado que hoje calha produzir a resposta certa.
Python via SASPy, R, clientes Java e .NET sobre IOM, JDBC para o SAS/SHARE, Tableau e pandas a ler ficheiros .sas7bdat diretamente, e chamadas REST para o Viya.
Requisitos de validação em setores regulados (GxP, 21 CFR Part 11, gestão de risco de modelos), segurança ao nível da linha, tratamento de dados pessoais, trilhos de auditoria, e a ausência de controlo de versões em muitos parques SAS de longa data.
Nenhum destes pontos é invulgar. Todos podem ser encontrados antecipadamente e todos são testáveis. É exatamente esse o propósito do processo que se segue.
Inventariamos o parque antes de estimar o trabalho. Com análise automatizada da sua árvore de código, dos seus agendamentos e dos seus logs, produzimos um grafo de dependências de programas, macros, formatos, bibliotecas, ficheiros externos e ligações a bases de dados, e identificamos o que é realmente executado, o que está morto e de quem é cada coisa. Cada categoria acima é verificada e os achados são pontuados por esforço de migração.
Um relatório de inventário e risco com uma proposta a preço fixo para as fases seguintes. Se decidir não avançar, o relatório fica consigo.
Esta é a fase que torna fiável todo o resto, e é feita inteiramente no seu sistema SAS existente, antes de qualquer migração.
Para cada programa no âmbito, usamos análise assistida por IA para construir testes de caracterização: especificações executáveis do que o código faz hoje. Cada teste capta as entradas que um programa consome — conjuntos de dados, parâmetros de macro, ficheiros externos, extrações de bases de dados, definições de ambiente —, executa-o na sua instalação SAS atual e regista tudo o que produz: conjuntos de dados de saída, conteúdo do log, códigos de retorno, saída ODS, estado das variáveis de macro e efeitos colaterais como ficheiros escritos ou e-mails enviados.
É a IA que torna isto praticável à escala empresarial. Ler dez mil programas e inferir os casos-limite que cada um trata não é trabalho para pessoas com um prazo. Gerar os casos de teste, os dados de apoio e a lógica de comparação é exatamente o tipo de trabalho volumoso e repetitivo em que os modelos atuais são fortes, e cada teste gerado é validado ao ser executado contra o sistema que descreve. Se um teste não passar no seu SAS atual, não é um teste do seu sistema e é descartado.
As regras de comparação são definidas saída a saída. Os conjuntos de dados são comparados exatamente por omissão; as tolerâncias numéricas são declaradas explicitamente onde a vírgula flutuante ou os procedimentos iterativos tornam a igualdade bit a bit sem sentido; as comparações de logs são estruturais e não textuais, pelo que uma NOTE reformulada não faz falhar uma tarefa enquanto uma contagem de linhas alterada faz. Entradas não determinísticas como a data atual e as sementes aleatórias são controladas para que o mesmo teste dê a mesma resposta em qualquer dia. Quando não é possível usar dados de produção nos testes, construímos dados de apoio mascarados ou sintéticos que percorrem os mesmos caminhos de código.
Uma suíte de testes sob controlo de versões com cobertura medida em programas, macros e procedimentos, e uma linha de base de resultados registados do seu sistema atual. Esta suíte é sua. Está escrita para correr no Jenner, no SAS e em qualquer outro ambiente que fale a linguagem, e tem valor independentemente da migração: a maioria dos parques SAS nunca teve uma.
Com a linha de base estabelecida, a migração passa a ser um exercício de engenharia com uma definição clara de «concluído». Instalamos o Jenner no seu ambiente, resolvemos os pontos de ambiente encontrados na Descoberta (caminhos, bibliotecas, gestão de segredos, ligações a bases de dados, integração com o agendador) e corremos a suíte completa.
Cada falha é classificada numa de quatro categorias:
O código está correto e é o Jenner que está errado. O Jenner publica novas versões semanalmente; os defeitos encontrados em migrações de clientes são priorizados, e o teste que falha passa a fazer parte permanente da própria suíte de regressão do Jenner.
Um caminho, uma credencial, uma ligação ou uma opção que precisa de ser definida. Corrigido e executado de novo.
O código apoia-se em comportamento não documentado do SAS. Mostramos-lhe a linha concreta e o comportamento concreto, e escolhe entre alterar o código — com o teste a provar que a alteração é segura — ou o Jenner reproduzir a peculiaridade.
O resultado difere dentro de uma tolerância declarada, ou uma mensagem de log está redigida de outra forma. Documentado e aprovado, nunca aceite em silêncio.
A suíte corre continuamente à medida que os problemas são corrigidos, pelo que o progresso é um número e não uma opinião, e as regressões são apanhadas no mesmo dia em que são introduzidas.
Uma base de código migrada com a suíte completa a passar, ou com cada diferença remanescente decidida por escrito.
A certificação é o dossiê de provas que permite ao seu patrocinador, aos seus auditores e aos seus reguladores aceitarem a migração.
Corremos um período em paralelo em que as tarefas de produção são executadas nos dois sistemas e as saídas são comparadas automaticamente com as mesmas regras da suíte de testes. O dossiê de certificação inclui o inventário, a suíte de testes e a sua cobertura, a linha de base, os resultados da execução final, a decisão sobre cada diferença e a rastreabilidade de cada requisito ou programa até aos testes que o cobrem. Para clientes regulados, é estruturado para suportar validação IQ/OQ/PQ e auditoria.
Um dossiê de certificação assinado e uma recomendação de avançar ou não.
A comutação é planeada em torno das suas janelas de processamento em lote e da data de renovação da sua licença SAS, com um caminho de reversão testado. Os agendadores são reapontados, a monitorização e os alertas são confirmados, e o ambiente SAS é desativado no seu calendário.
A suíte de testes continua a correr depois da comutação. Como o Jenner publica semanalmente, recebe cada melhoria com a mesma prova de que nada de que depende mudou. A sua equipa é formada para estender a suíte à medida que a base de código cresce.
Produção no Jenner, um plano de desativação do SAS e uma suíte de regressão que continua a trabalhar para si.
A preço fixo e de curta duração. Produz a proposta para as fases seguintes, orçamentada pelo tamanho e pela complexidade medidos do seu parque e não por uma estimativa deles.
Normalmente entregues como um único projeto de âmbito fixo, com aceitação por marcos ligada aos resultados da suíte.
Disponível como serviço anual, depois de a suíte de testes ser entregue e a sua equipa formada para a estender.
$1,000 – $21,000
Em geral podem ser feitas remotamente, com uma duração que vai de uma semana a um mês.
$52,000 – $405,000
Exigem algum trabalho presencial e/ou perícia aprofundada no domínio, durando normalmente de dois a seis meses.
Todos os valores são em dólares dos Estados Unidos (USD).
Não inclui as taxas de licença do software; estas, porém, são muito simples e competitivas. Ver a página de preços.
Contactar os serviços profissionaisEnvie-nos uma descrição do seu ambiente SAS — plataforma, número aproximado de programas, produtos em uso, bases de dados e agendadores — e dimensionamos um projeto de Descoberta.