Pourquoi Rostelecom saurait-il tout et même un peu plus sur les adresses?Internet, avec toute son image numérique, est une chose créée dans le monde analogique. Et jusqu'à présent, pour que la maison dispose d'Internet haut débit, un câble doit être physiquement connecté à la maison.
C'est l'adresse de la maison qui est l'objet clé de l'identification dans le processus en plusieurs étapes de fourniture de services Internet.
L'adresse apparaît au moment où un client nous appelle chez Rostelecom pour lui demander s'il est possible de se connecter à Internet. L'opérateur doit connaître l'adresse du client afin de vérifier si le câble avec Internet est connecté à la maison. L'adresse est utilisée jusqu'au stade de l'assistance et du service du client existant. Lorsque vous contactez le service d'assistance technique à l'adresse du client, il est vérifié si le problème est local ou si l'accident est majeur et si le problème a affecté tout le trimestre.
Et bien sûr, à chaque étape du processus, la rapidité de la réponse au client est importante.
Dans cet article, nous parlerons de l'importance de l'adresse du client pour nos systèmes internes, pourquoi FIAS n'est pas une panacée et pourquoi le passeport unifié a été créé à la maison.
Plus le client reçoit rapidement la confirmation de sa capacité à se connecter à Internet, plus il a de chances de choisir Rostelecom. Le marché des services Internet est très concurrentiel et le moindre retard dans la réponse à la demande d’un client peut réduire sa fidélité et provoquer un passage à un autre opérateur de télécommunications plus efficace.
Simplifié, le processus métier de passage d'une application pour une connexion Internet est le suivant. Une application d'un client entre dans le système - il peut s'agir d'un site Web ou d'un autre système où les applications peuvent être gérées. Ensuite, la demande est envoyée au système de comptabilité technique linéaire pour vérifier la disponibilité de la connectivité technique au client à son adresse. S'il existe une possibilité technique, l'application est transmise au système de travail pour les installateurs qui connecteront le client à Internet. Une fois le service activé sur le réseau, l'application passe à la facturation, où le coût des services pour l'abonné est calculé. Les téléchargements mensuels sont constitués de la facturation pour l'envoi des factures et des lettres de réclamation aux débiteurs.
Tous ces systèmes d'information ont été développés et mis en œuvre avant la fusion de Rostelecom et, en règle générale, avant que le marché Internet ne devienne si hautement concurrentiel.
Les systèmes d'information existants ont fourni un processus continu de vente et de connexion des services de communication dans tout le pays, mais en même temps, l'intégration entre eux a été réalisée de manière semi-automatisée. Les systèmes étaient faiblement interconnectés et n'étaient pas conçus pour interagir dans un seul espace d'information. Chaque système utilise ses propres catalogues d'adresses, répertoires et principes pour identifier les objets.
Pour l'interaction efficace de tous les systèmes dans un seul processus commercial centralisé de vente et de service à la clientèle de Rostelecom, il était nécessaire de fournir un «protocole» commun de communication - un système de classification et d'identification des objets ciblés. Dans ce cas, le point de départ doit être précisément la propriété qui peut avoir une adresse, peut-être ne pas l'avoir, peut avoir un adressage alternatif, mais dans tous les cas, elle doit être déterminée de manière unique.
À ces fins, un projet a été lancé - le passeport unifié à domicile (ORPON), qui a assuré la transition de sources de données disparates, incomplètes et conflictuelles vers un espace d'adressage unique intégré dans lequel l'interaction entre les systèmes informatiques de toutes les succursales de Rostelecom se produit automatiquement, sans traitement manuel.
Comment était tout avant un répertoire d'adresses unique? Pourquoi FIAS ne rentre pas? Pourquoi tout est plus compliqué qu'il n'y paraît?
Lorsque l'entreprise a la tâche de créer un annuaire, alors tout semble très simple.
Tout d'abord, une adresse est quelque chose de familier à tout le monde, tout le monde y est confronté tous les jours, tout le monde sait écrire une adresse: comment Dieu la met dans l'âme.
Deuxièmement, après les quinze premières minutes d'étude de la question sur Internet, vous découvrirez qu'un annuaire d'adresses pour l'ensemble de la Russie a déjà été créé dans la taxe. Et tout ce qui vous reste à faire est de télécharger la base de données FIAS, de la télécharger dans la base de données et le répertoire d'adresses est prêt. D'une certaine manière, bien sûr, c'est le cas.
Il existe un système d'adresses fédérales d'informations, des adresses existent, elles sont régulièrement mises à jour et le Service fédéral des impôts publie régulièrement des mises à jour. Pour de nombreuses tâches, ce guide convient, par exemple, aux tâches du Service fédéral des impôts.
Mais la FIAS n'a pas pu résoudre les problèmes de Rostelecom. Il y a beaucoup plus d'adresses dans les répertoires d'adresses de Rostelecom que dans le répertoire des adresses fiscales, et Rostelecom apprendra à construire une nouvelle maison en moyenne plusieurs années plus tôt que cette maison ne figure dans le répertoire FIAS. Et il est important pour Rostelecom de connaître non seulement les adresses, mais d'associer sans ambiguïté une adresse à un objet immobilier et de déterminer toutes les caractéristiques significatives de cet objet: année de construction, matériau du mur, objet et 90 autres paramètres très importants.
Mais le principal problème était qu'au moment du démarrage du projet à Rostelecom, il y avait au moins 40 systèmes activement utilisés, chacun ayant son propre répertoire d'adresses, sa propre base de données avec des adresses, dont la comparaison avec la FIAS a donné environ 60% des adresses correspondantes et 40% des adresses dont l'administration fiscale ne sait rien.
Il était impossible de définir ces 40% d'adresses comme des «ordures», car environ le même pourcentage de la base d'abonnés se trouvait sur elles, et le rejet des adresses signifiait également le rejet des abonnés. Pour chaque adresse du décrochage, il fallait comprendre: une telle adresse existe-t-elle et cette adresse est-elle indépendante, ou s'agit-il d'un doublon d'une autre adresse? Ou peut-être s'agit-il d'une maison d'angle et nous avons affaire à un adressage alternatif?
Il fallait trouver une solution qui permettrait de connecter au moins 95% des adresses. Autrement dit, pour 35% des adresses qui n'étaient pas d'accord avec FIAS, il était nécessaire de trouver un algorithme qui leur permettrait de prendre des décisions à leur sujet. Cela devait être fait automatiquement. Pour traiter manuellement environ 40% de la base d'adresses de Rostelecom, il faudrait environ 120 années-homme. Et éliminer le problème du facteur humain avec l'aide de l'homme n'est pas la décision la plus sage.
Comment nous avons tout fait et pourquoi si longtemps
Dans le cadre du projet, deux tâches principales étaient requises: créer un répertoire d'adresses qui contiendrait toutes les bonnes adresses et ne contiendrait pas de déchets, et développer un système qui permettrait la maintenance en ligne du répertoire d'adresses dans l'état actuel dans tout le paysage informatique de Rostelecom.
Simplifié, le processus de mise en œuvre du projet peut être décrit comme une séquence des étapes suivantes:
- Auditez tous les systèmes qui utilisent des adresses dans leurs processus métier. Autrement dit, pour auditer l'ensemble du paysage informatique de Rostelecom.
- Définissez un scénario d'implémentation et des scénarios d'intégration d'un répertoire d'adresses de référence dans chaque région de macro.
- En fonction de certains scénarios d'implémentation et d'intégration, développez un progiciel.
- Déchargez les répertoires d'adresses de tous les systèmes dans le périmètre d'intégration, créez un répertoire d'adresses de référence sur la base de ces données et mappez les adresses locales aux références.
- Développer un annuaire de référence de l'immobilier et associer des adresses de référence à l'immobilier par une communication plusieurs-à-plusieurs
- S'intégrer à chaque système d'information
- Développer un processus de gestion des adresses et former des experts
- Appuyez sur le gros bouton rouge «Démarrer» et reproduisez la solution dans les 7 macro-régions de Rostelecom.
Vous pouvez parler de chacune de ces étapes pendant longtemps, chacune d'entre elles était intéressante à sa manière, mais dans le cadre de cet article, nous avons décidé de nous concentrer sur les deux aspects les plus intéressants, à notre avis, - la formation d'un algorithme d'analyse d'adresses et la naissance d'une architecture de solution.
Pour résoudre le problème des adresses, il était nécessaire de développer un algorithme sans ambiguïté et cohérent pour l'analyse des adresses, qui serait basé à la fois sur une base d'adresses de référence unique du FIAS et prendrait en compte les spécificités régionales des espaces d'adressage dans différentes régions de la Fédération de Russie.
Il n'a pas été possible d'automatiser complètement cet algorithme à l'aide des méthodes bien connues de Levenshtein et Yaro-Winkler. Par conséquent, avec la méthode automatisée d'analyse des adresses, l'algorithme développé pour évaluer les écarts réels autorisés des lignes d'adresse par rapport aux données de référence a également été appliqué.
Mais cela ne suffisait pas!
Pour la comparaison la plus précise des données d'adresse, il a été nécessaire d'analyser les données des systèmes de comptabilité technique. Ainsi, un pool d'attributs supplémentaires complètement non-adresse a été formé, qui faisaient partie de l'algorithme de confirmation de la qualité de l'analyse finale. Ces attributs étaient, par exemple, les coordonnées géographiques et les identificateurs d'équipement. Donc, si le même commutateur était lié à des adresses identifiées comme des doublons potentiels, c'était un marqueur qui leur permettait de «réduire» les adresses en un seul objet d'adresse de référence. La présence de ces informations supplémentaires nous a permis de collecter la base de données la plus complète de toutes les maisons «d'angle», qui reflète les spécificités de l'adressage alternatif dans la Fédération de Russie.
Mais malgré la présence d'un grand nombre d'informations complémentaires: données provenant des systèmes de comptabilité technique, listes de retour de correspondance, interconnexions entre les répertoires d'adresses des systèmes par les identifiants des abonnés, dans certaines branches la zone grise - une liste d'adresses qui ne pouvaient pas être identifiées de manière unique - pouvait atteindre jusqu'à 10%.
Mais que faire de la zone grise? Après tout, il comprenait non seulement des adresses incorrectement écrites, mais aussi les soi-disant "adresses technologiques" - des objets immobiliers où des équipements sont installés et des services sont fournis, mais ils sont situés complètement en dehors des limites des réseaux urbains et, par conséquent, n'ont pas d'adresses au sens traditionnel. Cette tâche a été distinguée dans une direction distincte et en utilisant toutes les méthodes connues de géoanalyse et d'analyse de données sémantiques, ces objets ont également été identifiés de manière unique et inclus dans le répertoire d'adresses de référence.
La création du répertoire d'adresses de référence est le résultat d'efforts titanesques, mais le résultat de ce travail a été d'augmenter la précision de la détermination de la faisabilité technique de la connexion à de telles maisons, ce qui signifie que l'objectif a été atteint.
Le deuxième aspect tout aussi difficile et intéressant du projet était lié au développement de l'architecture de la solution.
La naissance de l'architecture de la solution finale a été précédée de deux hypothèses erronées:
- Le répertoire d'adresses de Rostelecom peut être construit sur la base d'une plateforme MDM industrielle.
- Le répertoire d'adresses de Rostelecom peut être construit sur la base d'une plate-forme industrielle pour l'analyse et la normalisation des adresses.
Cette hypothèse et l'autre ont échoué. La solution industrielle MDM, possédant tous les avantages de la plateforme de gestion d'annuaire, ne pouvait pas se targuer d'algorithmes de normalisation pour les adresses russes, et de la possibilité de travailler avec l'adresse comme caractéristique d'un objet immobilier. Et comme mettre de l'ordre dans les adresses était un objectif clé du projet, c'était un inconvénient critique qui l'emportait sur tous les avantages considérables d'une puissante plate-forme MDM industrielle. De plus, cette solution ne disposait pas d'une plate-forme d'intégration à tolérance de pannes capable de fournir une intégration en temps réel avec des dizaines de nœuds du réseau interne selon différents scénarios d'intégration.
La deuxième approche pour construire l'architecture du répertoire d'adresses était basée sur l'idée de construire MDM basé sur le moteur d'analyse et de normalisation des adresses. Cela semblait être une solution logique, car le goulot d'étranglement de l'approche architecturale précédente était précisément la fonction de recherche et de mise en correspondance d'adresses, en les amenant à une forme standard et la possibilité de rechercher des doublons potentiels.
Néanmoins, l'architecture des produits pour l'analyse et la normalisation des adresses est axée sur la vitesse de traitement des tableaux d'adresses, la précision de la correspondance des chaînes d'adresses similaires, la minimisation de l'erreur inverse - ce sont les valeurs clés du produit pour la normalisation des adresses, qui sont souvent utilisées dans le traitement des adresses de listes de diffusion et dans des tâches similaires. L'idée principale de ces solutions est d'utiliser un répertoire d'adresses de référence unique - FIAS - et de ramener les listes reçues en entrée à la norme avec une probabilité calculée.
Les tâches de Rostelecom ont nécessité la création de son propre ouvrage de référence mis à jour en permanence, qui d'une part est basé sur le FIAS, mais la présence ou l'absence d'une adresse dans le FIAS n'est pas décisive pour reconnaître l'adresse de référence. Et c'était une tâche insoluble pour la plupart des systèmes de normalisation automatique des adresses.
À la suite de longues recherches, une solution de compromis avec une architecture hybride a été trouvée - une plate-forme MDM propriétaire intégrée au moteur de recherche HumanFactorLabs. Le choix de ce fournisseur a été déterminé par sa volonté de finaliser le mécanisme de recherche d'adresses pour une utilisation, en standard, du répertoire d'adresses Rostelecom, et de mettre en œuvre le mécanisme de synchronisation régulière du répertoire d'adresses Rostelecom avec FIAS. Ce raffinement nous a permis de fournir aux utilisateurs une recherche pratique et de haute qualité des adresses par ligne, et la construction d'une solution MDM basée sur les produits OpenSource a fourni une flexibilité dans les approches d'intégration au paysage informatique de Rostelecom. Dans le périmètre du paysage informatique de Rostelecom, il existe des systèmes hérités qui sont utilisés dans le processus métier, mais ne peuvent pas être substantiellement modifiés en raison de leurs limites de conception. L'abandon d'une solution industrielle vers un développement en interne a permis de maximiser l'adaptation de la plateforme MDM aux caractéristiques de l'environnement informatique, tout en conservant le concept architectural de base.
Pourquoi est-ce si difficile?
Compte tenu des spécificités de la construction du paysage informatique de Rostelecom, la première implémentation du système aurait dû avoir lieu directement dans le circuit industriel du paysage informatique de la macrorégion. Sur le circuit industriel, de nouvelles intégrations avec des systèmes clés du paysage informatique ont été introduites en opération pilote, ce qui a eu un impact sur la mise en œuvre technique de tous les processus commerciaux de Rostelecom PJSC: vente et connexion, mise en service de nouvelles installations de communication, modernisation des réseaux de distribution à domicile, installation, assistance sur les lignes 2 et 3, planification de la construction, reporting. Le risque d'une erreur de mise en œuvre était le blocage total du travail des flux d'informations entre les systèmes d'information de la macrorégion, l'arrêt de tous les processus métiers, la baisse des risques commerciaux et de réputation.
Par conséquent, avant la première mise en œuvre, chaque étape a été scrupuleusement vérifiée, chaque adresse et le système ont été mis en service, il a fallu 24 heures de service pendant deux semaines après le début.
Au moment du premier lancement, il semblait que toutes les difficultés étaient passées et qu'il y aurait alors simplement une réplication. Mais compte tenu du fait que chaque macro-région est dans un passé récent une entreprise distincte avec son propre paysage informatique spécifique, chaque «circulation» s'est transformée en une nouvelle mise en œuvre à part entière.
Technologies et outils utilisés
La structure modulaire du système est illustrée sur la figure.
CliquableÀ propos du processus technique
Les développeurs de projets n'écrivent pas seulement du code, mais sont des unités créatives à part entière: ils prennent des décisions techniques, proposent des idées pour la conception d'interfaces, la facilité d'utilisation du produit. Toute nouvelle fonctionnalité est discutée avec les développeurs, leur avis et leur expérience sont pris en compte. Toute tâche laisse une marge de développement à la créativité, de sorte que toutes les petites commodités sont facilement réalisables et ne nécessitent pas de confirmation dans un tas d'instances.
À propos du backend
Le projet actuel est basé sur la technologie Java EE et le serveur Web WildFly. Le projet est monolithique, bien qu'il passe maintenant par la planification de sa «séparation» en microservices séparés, car la charge sur le projet commence progressivement à culminer et nécessite une mise à l'échelle normale.
À propos de frontend
Le projet se développe depuis longtemps et utilise GWT du côté frontal. Et, bien que cette technologie soit lourde et obsolète d'ici 2019, elle vous permet de faire un certain nombre de choses que vous ne pouvez pas faire sur les frameworks JavaScript: écrire en Java et sur le client et sur le serveur, opérer sur les mêmes entités de base de données là-bas et là, il suffit de les cloner via JpaCloner.
Aucun DTO et autre paramètre ne passe de vide à vide. Cela vous permet de créer un produit à part entière avec une équipe de programmeurs relativement petite. Bien que cette technologie ne soit pas moins gênante: bogues dans Internet Explorer (et il existe des normes d'entreprise après tout), temps de compilation énormes, difficultés d'intégration avec les bibliothèques JavaScript modernes. Par conséquent, dans la nouvelle version du produit, il est prévu d'abandonner cette technologie au profit de quelque chose de plus moderne.
À propos des scénarios d'intégration
Le système met en œuvre plus de 20 scénarios d'intégration différents avec les systèmes d'information des consommateurs des répertoires ORPON.
Les scripts d'intégration vous permettent de transférer à la fois une adresse unique et une liste de masse d'adresses ou d'éléments d'adresse. Le système ORPON peut lancer le transfert d'une adresse et d'une liste d'adresses indépendamment, par exemple, lorsqu'un expert saisit une nouvelle adresse dans le système ou lorsque des modifications FIAS sont téléchargées, ou peut effectuer ces actions en réponse à une demande d'un système adjacent. Le transfert des répertoires, des attributs de l'immobilier - bien sûr.
Le scénario le plus inhabituel peut probablement être considéré comme le scénario de contrôle de la séquence des transferts d'adresse. Dans les processus commerciaux complexes, les connexions qui ont lieu en ligne sont très importantes à contrôler - à quels systèmes l'adresse doit-elle d'abord accéder afin d'éviter toute interruption de ces processus. Et nous devions également résoudre ce problème à l'aide de scripts standard.
À propos de l'infrastructure
ORPON n'est pas un système en temps réel à charge élevée - chaque système consommateur de répertoires d'adresses a sa propre copie du système de référence, et le système n'utilise pas ORPON pour rechercher l'adresse, mais va à sa propre base de données.
Dans ORPON, le système consommateur contacte si l'adresse demandée n'est pas trouvée dans le stockage local. Cette solution architecturale a permis de réduire considérablement la charge sur l'application et de fournir les caractéristiques techniques spécifiées de la réponse et de la stabilité à l'aide de clusters de deux serveurs. Le schéma d'infrastructure des composants du système est illustré dans la figure ci-dessous. Cliquable La composition des applications logicielles de chaque cluster est la suivante:
- Cluster SGBD PostgreSQL
- RedHat Enterprise Linux 7.7 (64 bits)
- Serveur PostgreSQL 11.4 (64 bits)
- Pacemaker ClusterLabs | Corosync
- Cluster de serveur d'applications
- RedHat Enterprise Linux 7.7 (64 bits)
- Serveur d'applications WildFly 17 (64 bits)
- Logiciel Citrix Balancer
- PAR OU PON
- Info-bulles de la plateforme de cluster et facteur logiciel
- Serveur d'applications WildFly 17 (64 bits)
- Logiciel Citrix Balancer
- Produit logiciel FACTOR
- "Conseils" sur les produits logiciels
Qu'est-ce que cela nous a donné
Il est souvent difficile de mesurer l'effet de la mise en œuvre des systèmes d'information, de nombreux changements se produisent immédiatement et il n'y a pas de réponse définitive - s'il y a eu un effet, et s'il y en a un, ce qui a causé les conséquences positives ou négatives. Surtout si vous soulevez un projet d'infrastructure situé au cœur même de votre paysage informatique.Nous avons eu de la chance et dans l'une des macro-régions, nous avons pu mener une expérience propre. Au cours de la période, il n'y a eu qu'un seul changement dans les processus organisationnels et informatiques, et ce fut l'introduction du répertoire d'adresses unifié - ORPON. L'ampleur de l'effet était énorme - le nombre de réponses positives à la vérification de la faisabilité technique de la connexion a augmenté de 22% après l'introduction du système. Avant la mise en œuvre dans la macro-région, il n'y avait pas de lien sans ambiguïté entre l'adresse dans le système, d'où provient la demande d'assistance technique et le système de comptabilité technique, où la possibilité est vérifiée - quelle adresse sera choisie était une loterie. De plus, il y avait beaucoup de doublons dans SLTU et l'équipement qui se trouvait dans la maison pouvait être distribué au hasard à plusieurs adresses, dont l'une a été choisie au hasard pour vérifier la faisabilité technique.La mise en œuvre du système a permis de réduire cette incertitude à 0, et donc d'éliminer la perte de clients au stade de la saisie de l'application sur le site RT.RU en raison d'erreurs dans la détermination de la faisabilité technique de la prestation du service à l'adresse.Lorsque nous avons reçu ces résultats, nous n'en avons pas cru nos yeux! Ces chiffres ont dépassé nos attentes les plus folles.Cet article a été préparé par l'équipe de gestion des données de Rostelecom