Como criamos o diretório de endereços da Rostelecom

Por que a Rostelecom saberia tudo e até um pouco mais sobre endereços?

A Internet, com toda a sua imagem digital, é algo criado no mundo analógico. E até agora, para que a casa tenha Internet de alta velocidade, um cabo deve estar fisicamente conectado à casa.

É o endereço da casa que é o principal objeto de identificação no processo de vários estágios da prestação de serviços de Internet.

O endereço aparece no momento em que um cliente liga para a Rostelecom perguntando se é possível conectar-se à Internet. O operador precisa saber o endereço do cliente para verificar se o cabo com a Internet está conectado à casa. O endereço é usado até o estágio de suporte e serviço do cliente existente. Ao entrar em contato com o serviço de suporte técnico no endereço do cliente, é verificado se o problema é local ou se o acidente é maciço e o problema afetou o trimestre inteiro.

E, é claro, em todas as etapas do processo, a velocidade da resposta ao cliente é importante.

Neste post, falaremos sobre a importância do endereço do cliente para nossos sistemas internos, por que o FIAS não é uma panacéia e por que o Unified Passport foi criado em casa.

Quanto mais rápido o cliente recebe a confirmação da capacidade de se conectar à Internet, maior a probabilidade de ele escolher a Rostelecom. O mercado de serviços de Internet é altamente competitivo e o menor atraso na resposta à solicitação de um cliente pode reduzir sua lealdade e provocar uma mudança para outro operador de telecomunicações mais eficiente.

Simplificado, o processo comercial de passar um aplicativo para uma conexão com a Internet é o seguinte. Um aplicativo de um cliente entra no sistema - pode ser um site ou outro sistema onde os aplicativos podem ser mantidos. Em seguida, a solicitação é enviada ao sistema de contabilidade técnica linear para verificar a disponibilidade da conectividade técnica ao cliente em seu endereço. Se houver uma possibilidade técnica, o aplicativo é transmitido ao sistema de trabalho para instaladores que conectarão o cliente à Internet. Depois que o serviço é ativado na rede, o aplicativo vai para o faturamento, onde é calculado o custo dos serviços para o assinante. Os downloads mensais são formados a partir do faturamento para o envio de faturas e cartas de reclamação aos devedores.

Todos esses sistemas de informação foram desenvolvidos e implementados antes da fusão da Rostelecom e, regra geral, antes que o mercado da Internet se tornasse altamente competitivo.

Os sistemas de informação existentes forneciam um processo contínuo de vendas e conexão de serviços de comunicação em todo o país, mas, ao mesmo tempo, a integração entre eles era realizada de forma semi-automatizada. Os sistemas estavam fracamente interconectados e não foram projetados para interação em um único espaço de informações. Cada sistema usou seus próprios catálogos de endereços, diretórios e princípios para identificar objetos.

Para a interação eficaz de todos os sistemas em um único processo comercial centralizado de vendas e atendimento ao cliente da Rostelecom, era necessário fornecer um "protocolo" comum de comunicação - um sistema para classificar e identificar objetos direcionados. Nesse caso, o ponto de partida deve ser precisamente a propriedade que pode ter um endereço, pode não ter, pode ter um endereço alternativo, mas, em qualquer caso, deve ser determinada exclusivamente.

Para esses fins, foi lançado um projeto - o Unified Passport at Home (ORPON), que garantiu a transição de fontes de dados díspares, incompletas e conflitantes para um único espaço de endereço integrado no qual a interação entre os sistemas de TI de todas as filiais da Rostelecom ocorre automaticamente, sem processamento manual.

Como foi tudo antes de um único diretório de endereços? Por que o FIAS não se encaixa? Por que tudo é mais complicado do que parece?

Quando a empresa tem a tarefa de criar um diretório, tudo parece muito simples.
Antes de tudo, um endereço é algo familiar para todos, todos enfrentam isso todos os dias, todo mundo sabe como escrever um endereço: como Deus o coloca na alma.

Em segundo lugar, após os primeiros quinze minutos de estudo da questão na Internet, você descobrirá que um diretório de endereços para toda a Rússia já foi criado no imposto. E tudo o que resta fazer é baixar o banco de dados FIAS, enviá-lo para o banco de dados e o diretório de endereços está pronto. De certa forma, é claro, é esse o caso.

Existe um sistema de endereços de informações federais, existem endereços nele, são atualizados regularmente e o Serviço Fiscal Federal publica regularmente atualizações. Para muitas tarefas, este guia é adequado, por exemplo, para as tarefas do Serviço Fiscal Federal.

Mas o FIAS não conseguiu resolver os problemas da Rostelecom. Nos diretórios de endereços da Rostelecom, há muito mais endereços do que no diretório de impostos, e a Rostelecom aprenderá sobre a construção de uma nova casa em média vários anos antes que essa casa apareça no diretório FIAS. E é importante que a Rostelecom conheça não apenas os endereços, mas associe inequivocamente um endereço a um objeto imobiliário e determine todas as características significativas desse objeto: ano de construção, material da parede, finalidade e 90 outros parâmetros muito importantes.

Mas o principal problema era que, no início do projeto em Rostelecom, havia pelo menos 40 sistemas usados ​​ativamente, cada um com seu próprio diretório de endereços, com seu próprio banco de dados com endereços, cuja comparação com o FIAS produzia cerca de 60% dos endereços correspondentes. e 40% dos endereços que a administração tributária não conhece.

Era impossível definir esses 40% dos endereços como "lixo", porque aproximadamente a mesma porcentagem da base de assinantes estava localizada neles, e a rejeição de endereços significava também a rejeição de assinantes. Para cada endereço da desistência, era necessário entender: esse endereço existe e esse endereço é independente ou é uma duplicata de outro endereço? Ou talvez seja uma casa de esquina, e estamos lidando com endereços alternativos?

Era necessário criar uma solução que permitisse conectar pelo menos 95% dos endereços. Ou seja, para 35% dos endereços que não concordam com o FIAS, era necessário criar um algoritmo que lhes permitisse tomar decisões sobre eles. Isso tinha que ser feito automaticamente. Para processar manualmente cerca de 40% da base de endereços da Rostelecom, levaria cerca de 120 homens-ano. E eliminar o problema do fator humano com a ajuda do homem não é a decisão mais sábia.

Como fizemos tudo e por quanto tempo

Dentro da estrutura do projeto, duas tarefas principais foram necessárias: criar um diretório de endereços que contenha todos os bons endereços e não contenha lixo e desenvolver um sistema que permita a manutenção on-line do diretório de endereços no estado atual em todo o cenário de TI da Rostelecom.

Simplificado, o processo de implementação do projeto pode ser descrito como uma sequência das seguintes etapas:

• Audite todos os sistemas que usam endereços em seus processos de negócios. Ou seja, para auditar todo o cenário de TI da Rostelecom.
• Defina um cenário de implementação e cenários de integração de um diretório de endereço de referência em cada região de macro.
• Com base em certos cenários de implementação e de integração, desenvolva um pacote de software.
• Descarregue os diretórios de endereços de todos os sistemas no perímetro de integração, crie um diretório de endereços de referência com base nesses dados e mapeie os endereços locais para os de referência.
• Desenvolver um diretório de referência de imóveis e associar endereços de referência a imóveis por meio de comunicação muitos-para-muitos
• Integre-se com cada sistema de informação
• Desenvolver um processo de gerenciamento de endereços e treinar especialistas
• Pressione o grande botão vermelho “Iniciar” e replique a solução nas 7 macrorregiões da Rostelecom.

Você pode falar sobre cada uma dessas etapas por um longo tempo, cada uma delas foi interessante à sua maneira, mas, no âmbito deste artigo, decidimos focar nos dois aspectos mais interessantes, em nossa opinião, - a formação de um algoritmo de análise de endereço e o nascimento de uma arquitetura de solução.
Para resolver o problema com endereços, foi necessário desenvolver um algoritmo inequívoco e consistente para análise de endereços, que seria baseado em uma única base de endereços de referência do FIAS e levaria em conta as especificidades regionais dos espaços de endereço em diferentes regiões da Federação Russa.

Não foi possível automatizar completamente esse algoritmo usando os métodos conhecidos de Levenshtein e Yaro-Winkler. Portanto, juntamente com o método automatizado de análise de endereços, o algoritmo desenvolvido para avaliar os desvios reais permitidos das linhas de endereço dos dados de referência também foi aplicado.

Mas isso não foi suficiente!

Para uma comparação mais precisa dos dados de endereço, foi necessário analisar os dados dos sistemas de contabilidade técnica. Assim, um conjunto de atributos adicionais completamente sem endereço foi formado, que faziam parte do algoritmo final de confirmação da qualidade da análise. Tais atributos foram, por exemplo, coordenadas geográficas e identificadores de equipamentos. Portanto, se a mesma opção estivesse vinculada a endereços identificados como possíveis duplicatas, esse seria um marcador que permitiria "recolher" endereços em um objeto de endereço de referência. A presença de tais informações adicionais nos permitiu coletar o banco de dados mais completo de todas as casas de “esquina”, o que reflete as especificidades de endereços alternativos na Federação Russa.

Mas, apesar da presença de uma grande quantidade de informações adicionais: dados técnicos de contabilidade, listas de retorno por correspondência, conexões cruzadas entre diretórios de endereços de sistemas por identificadores de assinantes, em algumas ramificações a zona cinza - uma lista de endereços que não puderam ser identificados exclusivamente - pode chegar a 10%.

Mas o que fazer com a zona cinzenta? Afinal, incluiu não apenas endereços escritos incorretamente, mas também os chamados "endereços tecnológicos" - objetos imobiliários onde o equipamento é instalado e os serviços são prestados, mas estão localizados completamente fora dos limites das matrizes urbanas e, portanto, não têm endereços no sentido tradicional. Essa tarefa foi destacada em uma direção separada e, usando todos os métodos conhecidos de geoanalítica e análise de dados semânticos, esses objetos também foram identificados e incluídos exclusivamente no diretório de endereços de referência.

A criação do diretório de endereços de referência foi resultado de esforços titânicos, mas o resultado deste trabalho foi aumentar a precisão da determinação da viabilidade técnica de conexão com essas casas, o que significa que o objetivo foi alcançado.

O segundo aspecto igualmente difícil e interessante do projeto estava relacionado ao desenvolvimento da arquitetura da solução.

O nascimento da arquitetura da solução final foi precedido por duas hipóteses errôneas:

1. O diretório de endereços da Rostelecom pode ser construído com base em uma plataforma MDM industrial.
2. O diretório de endereços da Rostelecom pode ser construído com base em uma plataforma industrial para análise e normalização de endereços.

Tanto essa quanto a outra hipótese foram um fracasso. A solução MDM industrial, com todas as vantagens da plataforma de gerenciamento de diretório, não podia se gabar de algoritmos de normalização para endereços russos e da capacidade de trabalhar com o endereço como uma característica de um objeto imobiliário. E como colocar a ordem nos endereços era um objetivo principal do projeto, essa era uma desvantagem crítica que superava todas as vantagens consideráveis ​​de uma poderosa plataforma MDM industrial. Além disso, essa solução não possuía uma plataforma de integração tolerante a falhas, capaz de fornecer integração em tempo real com dezenas de nós da rede interna, de acordo com vários cenários de integração.

A segunda abordagem para criar a arquitetura do diretório de endereços foi baseada na idéia de criar o MDM com base no mecanismo de análise e normalização de endereços. Essa parecia uma solução lógica, pois o gargalo da abordagem arquitetural anterior era precisamente a função de pesquisar e combinar endereços, trazendo-os para um formulário padrão e a capacidade de pesquisar possíveis duplicatas.

No entanto, a arquitetura dos produtos para análise e normalização de endereços concentra-se na velocidade de processamento de matrizes de endereços, na precisão da seleção de cadeias de endereços semelhantes, minimizando o erro reverso - esses são os principais valores do produto para normalização de endereços, que são frequentemente usados ​​no processamento de endereços de listas de e-mail e em tarefas semelhantes. A idéia principal dessas soluções é usar um único diretório de endereço de referência - FIAS - e trazer as listas recebidas na entrada para o padrão com uma probabilidade calculada.

As tarefas da Rostelecom exigiram a criação de seu próprio livro de referência atualizado continuamente, que por um lado se baseia no FIAS, mas a presença ou ausência do endereço no FIAS não é determinante para o reconhecimento do endereço de referência. E essa era uma tarefa insolúvel para a maioria dos sistemas automáticos de normalização de endereços.

Como resultado de longas pesquisas, foi encontrada uma solução de compromisso com uma arquitetura híbrida - uma plataforma MDM proprietária integrada ao mecanismo de pesquisa HumanFactorLabs. A escolha desse fornecedor foi determinada pela disposição de finalizar o mecanismo de busca de endereços para uso, como padrão, do diretório de endereços Rostelecom e implementar o mecanismo de sincronização regular do diretório de endereços Rostelecom com o FIAS. Esse refinamento nos permitiu fornecer aos usuários uma pesquisa conveniente e de alta qualidade por endereços por linha, e a construção de uma solução MDM baseada em produtos OpenSource proporcionou flexibilidade nas abordagens de integração com o cenário de TI da Rostelecom. No perímetro do cenário de TI da Rostelecom, existem sistemas legados usados ​​no processo de negócios, mas não podem ser modificados substancialmente devido às limitações de design. A mudança de uma solução industrial para o desenvolvimento interno tornou possível maximizar a adaptação da plataforma MDM às características do ambiente de TI, mantendo o conceito arquitetural básico inalterado.

Por que isso é tão difícil?

Dadas as especificidades da construção do cenário de TI da Rostelecom, a primeira implementação do sistema deveria ter ocorrido diretamente no circuito industrial do cenário de TI da macrorregião. No circuito industrial, novas integrações com os principais sistemas do cenário de TI foram introduzidas na operação piloto, o que afetou a implementação técnica de todos os processos de negócios da Rostelecom PJSC: Vendas e conexão, Comissionamento de novas instalações de comunicação, Modernização de redes de distribuição doméstica, Instalação, Suporte nas linhas 2 e 3, planejamento de construção, relatórios. O risco de um erro de implementação foi o bloqueio completo do trabalho dos fluxos de informações entre os sistemas de informação da macrorregião, o desligamento de todos os processos de negócios, a queda nos riscos de vendas e reputação.

Portanto, antes da primeira implementação, todas as etapas foram verificadas escrupulosamente, todos os endereços e o sistema foram colocados em operação, exigindo 24 horas de serviço por duas semanas após o início.

No momento do primeiro lançamento, parecia que todas as dificuldades haviam passado e, então, haveria simplesmente uma replicação. Mas, levando em consideração o fato de que cada macrorregião é, no passado recente, uma empresa separada com seu próprio cenário de TI específico, cada “circulação” se transformou em uma nova implementação de pleno direito.

Tecnologias e ferramentas usadas

A estrutura modular do sistema é mostrada na figura.


Clicável

Sobre o processo técnico

Os desenvolvedores do projeto não estão apenas escrevendo código, mas são unidades criativas completas: tomam decisões técnicas, oferecem idéias para design de interface, facilidade de uso do produto. Qualquer novo recurso é discutido com os desenvolvedores, sua opinião e experiência são levadas em consideração. Qualquer tarefa deixa um espaço para a criatividade do desenvolvedor, para que pequenas conveniências sejam facilmente realizadas e não exijam confirmação em várias instâncias.

Sobre o back-end

O projeto atual é baseado na tecnologia Java EE e no servidor da web WildFly. O projeto é monolítico, embora agora esteja apenas passando pelo planejamento de sua "separação" em microsserviços separados, porque a carga no projeto está gradualmente começando a atingir o pico e requer escala normal.

Sobre o frontend

O projeto está em desenvolvimento há muito tempo e usa o GWT no lado frontal. E, embora essa tecnologia seja pesada e desatualizada em 2019, ela permite que você faça várias coisas que não pode fazer nas estruturas JavaScript: escreva em Java e no cliente e no servidor, opere nas mesmas entidades de banco de dados existentes e lá, apenas clonando-os através do JpaCloner.

Nenhum DTO e outro parâmetro muda de vazio para vazio. Isso permite que você crie um produto completo com uma equipe relativamente pequena de programadores. Embora essa tecnologia não seja menos problemática: erros no Internet Explorer (e, afinal, existem padrões corporativos), tempos de compilação enormes, dificuldades na integração com as modernas bibliotecas JavaScript. Portanto, na nova versão do produto, está planejado abandonar essa tecnologia em favor de algo mais moderno.

Sobre cenários de integração

O sistema implementa mais de 20 cenários de integração diferentes com os sistemas de informações do consumidor dos diretórios ORPON.

Os scripts de integração permitem transferir um único endereço e uma lista em massa de endereços ou elementos de endereço. O sistema ORPON pode iniciar a transferência de um endereço e uma lista de endereços de forma independente, por exemplo, quando um especialista insere um novo endereço no sistema ou quando as alterações do FIAS são baixadas ou pode executar essas ações em resposta a uma solicitação de um sistema adjacente. A transferência de diretórios, atributos de imóveis - é claro.

O cenário mais incomum, provavelmente, pode ser considerado o cenário de controle da sequência de transferências de endereço. Em processos empresariais complexos, as conexões que ocorrem on-line são muito importantes para controlar - em quais sistemas o endereço deve ser acessado primeiro para evitar a interrupção de tais processos. E também precisávamos resolver esse problema usando scripts padrão.

Sobre infraestrutura

O ORPON não é um sistema carregado em tempo real - cada sistema consumidor de diretórios de endereços possui sua própria cópia do sistema de referência e o sistema não acessa o ORPON para encontrar o endereço, mas acessa seu próprio banco de dados.No ORPON, o sistema do consumidor entra em contato se o endereço solicitado não for encontrado no armazenamento local. Essa solução arquitetural permitiu reduzir significativamente a carga no aplicativo e fornecer as características técnicas especificadas da resposta e estabilidade usando clusters de dois servidores. O diagrama da infraestrutura dos componentes do sistema é mostrado na figura abaixo. Clicável A composição dos aplicativos de software de cada cluster é a seguinte:

• Cluster DBMS do PostgreSQL
• RedHat Enterprise Linux 7.7 (64 bits)
• PostgreSQL Server 11.4 (64 bits)
• Marca-passo do ClusterLabs | Corosync
• Cluster do servidor de aplicativos
• RedHat Enterprise Linux 7.7 (64 bits)
• Servidor de aplicativos WildFly 17 (64 bits)
• Software Citrix Balancer
• POR OU PON
• Dicas de ferramenta da plataforma de cluster e fator de software
• Servidor de aplicativos WildFly 17 (64 bits)
• Software Citrix Balancer
• Produto de software FACTOR
• Produto "Software" Dicas

O que isso nos deu

Muitas vezes, é difícil medir o efeito da implementação de sistemas de informação, muitas mudanças ocorrem imediatamente e não há resposta definitiva - se houve um efeito e se houve, o que causou consequências positivas ou negativas. Especialmente se você estiver criando um projeto de infraestrutura localizado no coração do seu cenário de TI.

Tivemos sorte e, em uma das macrorregiões, conseguimos realizar um experimento limpo. Durante o período, houve apenas uma mudança nos processos organizacionais e de TI, e essa foi a introdução do Diretório de Endereços Unificado - ORPON. A escala do efeito foi enorme - o número de respostas positivas para verificar a viabilidade técnica da conexão aumentou 22% após a introdução do sistema. Antes da implementação na macrorregião, não havia conexão inequívoca entre o endereço no sistema, de onde vem a solicitação de suporte técnico e o sistema de contabilidade técnica, onde a possibilidade é verificada - qual endereço será selecionado era uma loteria. Além disso, havia muitas duplicatas no SLTU e o equipamento que estava na casa poderia ser distribuído aleatoriamente em vários endereços, um dos quais foi selecionado aleatoriamente para verificar a viabilidade técnica.A implementação do sistema permitiu reduzir essa incerteza para 0 e, como resultado, eliminar a perda de clientes no estágio de entrada do aplicativo no site da RT.RU devido a erros na determinação da viabilidade técnica da prestação do serviço no endereço.

Quando recebemos esses resultados, não acreditávamos em nossos olhos! Esses números excederam nossas expectativas mais loucas.

Este artigo foi preparado pela equipe de gerenciamento de dados Rostelecom