¿Por qué Rostelecom lo sabría todo e incluso un poco más sobre direcciones?Internet, con toda su imagen digital, es algo creado en el mundo analógico. Y hasta ahora, para que la casa tenga Internet de alta velocidad, un cable debe estar físicamente conectado a la casa.
La dirección de la casa es el objeto clave de identificación en el proceso de múltiples etapas de la prestación de servicios de Internet.
La dirección aparece en el momento en que un cliente nos llama a Rostelecom para preguntarnos si es posible conectarse a Internet. El operador necesita saber la dirección del cliente para verificar si el cable con Internet está conectado a la casa. La dirección se utiliza hasta la etapa de soporte y servicio del cliente existente. Al contactar al servicio de soporte técnico en la dirección del cliente, se verifica si el problema es local o si el accidente es masivo y el problema ha afectado a todo el trimestre.
Y, por supuesto, en cada paso del proceso, la velocidad de la respuesta al cliente es importante.
En esta publicación, hablaremos sobre la importancia de la dirección del cliente para nuestros sistemas internos, por qué FIAS no es una panacea y por qué el pasaporte unificado se creó en casa.
Cuanto más rápido el cliente reciba la confirmación de la capacidad de conectarse a Internet, mayor será la probabilidad de que elija Rostelecom. El mercado de servicios de Internet es altamente competitivo y la menor demora en responder a la solicitud de un cliente puede reducir su lealtad y provocar un cambio a otro operador de telecomunicaciones más eficiente.
Simplificado, el proceso empresarial de pasar una solicitud para una conexión a Internet es el siguiente. Una aplicación de un cliente ingresa al sistema; puede ser un sitio web u otro sistema donde se pueden mantener las aplicaciones. A continuación, la solicitud se envía al sistema de contabilidad técnica lineal para verificar la disponibilidad de conectividad técnica para el cliente en su dirección. Si existe una posibilidad técnica, la aplicación se transmite al sistema de trabajo para los instaladores que conectarán el cliente a Internet. Después de activar el servicio en la red, la aplicación pasa a facturación, donde se calcula el costo de los servicios para el suscriptor. Las descargas mensuales se forman a partir de la facturación por el envío de facturas y cartas de reclamo a los deudores.
Todos estos sistemas de información se desarrollaron e implementaron antes de la fusión de Rostelecom y, por regla general, antes de que el mercado de Internet se volviera tan altamente competitivo.
Los sistemas de información existentes proporcionaron un proceso continuo de ventas y conexión de servicios de comunicación en todo el país, pero al mismo tiempo, la integración entre ellos se llevó a cabo en un modo semiautomatizado. Los sistemas estaban débilmente interconectados y no estaban diseñados para la interacción dentro de un único espacio de información. Cada sistema utilizaba sus propios catálogos de direcciones, directorios y principios para identificar objetos.
Para la interacción efectiva de todos los sistemas en un único proceso centralizado de ventas y servicio al cliente de Rostelecom, era necesario proporcionar un "protocolo" común de comunicación: un sistema para clasificar e identificar objetos específicos. En este caso, el punto de partida debe ser precisamente la propiedad que puede tener una dirección, puede que no la tenga, puede tener un direccionamiento alternativo, pero en cualquier caso debe determinarse de manera única.
Para estos fines, se lanzó un proyecto: el Pasaporte unificado en el hogar (ORPON), que aseguró la transición de fuentes de datos dispares, incompletas y conflictivas a un único espacio de direcciones integrado en el que la interacción entre los sistemas de TI de todas las sucursales de Rostelecom se produce automáticamente, sin procesamiento manual.
¿Cómo fue todo antes de un directorio de una sola dirección? ¿Por qué FIAS no encaja? ¿Por qué todo es más complicado de lo que parece?
Cuando la empresa tiene la tarea de crear un directorio, todo parece muy simple.
En primer lugar, una dirección es algo familiar para todos, todos se enfrentan a esto todos los días, todos saben cómo escribir una dirección: cómo Dios la pone en el alma.
En segundo lugar, después de los primeros quince minutos de estudiar el tema en Internet, descubrirá que ya se ha creado un directorio de direcciones para toda Rusia en el impuesto. Y todo lo que le queda por hacer es descargar la base de datos FIAS, subirla a la base de datos y el directorio de direcciones estará listo. En cierto modo, por supuesto, este es el caso.
Existe un sistema de direcciones de información federal, existen direcciones en él, se actualizan periódicamente y el Servicio Fiscal Federal publica actualizaciones regularmente. Para muchas tareas, esta guía es adecuada, por ejemplo, para las tareas del Servicio de Impuestos Federales.
Pero FIAS no pudo resolver los problemas de Rostelecom. En los directorios de direcciones de Rostelecom hay muchas más direcciones que en el directorio de direcciones de impuestos, y Rostelecom aprenderá sobre la construcción de una nueva casa en promedio varios años antes de que esta casa aparezca en el directorio de FIAS. Y es importante que Rostelecom conozca no solo las direcciones, sino que asocie inequívocamente la dirección con la propiedad y determine todas las características significativas de este objeto: año de construcción, material de la pared, propósito y otros 90 parámetros muy importantes.
Pero el problema principal era que en el momento del inicio del proyecto en Rostelecom había al menos 40 sistemas utilizados activamente, cada uno de los cuales tenía su propio directorio de direcciones, tenía su propia base de datos con direcciones, cuya comparación con el FIAS arrojó aproximadamente el 60% de las direcciones coincidentes y el 40% de las direcciones de las cuales la oficina de impuestos no sabe nada.
Era imposible definir el 40% de las direcciones como "basura", porque aproximadamente el mismo porcentaje de la base de suscriptores se encontraba en ellas, y el rechazo de las direcciones también significaba el rechazo de los suscriptores. Para cada dirección de la deserción, era necesario comprender: ¿existe tal dirección y esta dirección es independiente o es un duplicado de otra dirección? ¿O tal vez es una casa de la esquina, y estamos tratando con direcciones alternativas?
Era necesario encontrar una solución que permitiera conectar al menos el 95% de las direcciones. Es decir, para el 35% de las direcciones que no estaban de acuerdo con FIAS, era necesario idear un algoritmo que les permitiera tomar decisiones sobre ellas. Esto tenía que hacerse automáticamente. Para procesar manualmente aproximadamente el 40% de la base de direcciones de Rostelecom, tomaría alrededor de 120 años-hombre. Y eliminar el problema del factor humano con la ayuda del hombre no es la decisión más sabia.
Cómo lo hicimos todo y por qué tanto tiempo
Dentro del marco del proyecto, se requerían dos tareas principales: crear un directorio de direcciones que contendría todas las direcciones correctas y no contener basura, y desarrollar un sistema que permitiera el mantenimiento en línea del directorio de direcciones en el estado actual en todo el panorama de TI de Rostelecom.
Simplificado, el proceso de implementación del proyecto se puede describir como una secuencia de los siguientes pasos:
- Audite todos los sistemas que usan direcciones en sus procesos comerciales. Es decir, auditar todo el panorama de TI de Rostelecom.
- Defina un escenario de implementación y escenarios de integración de un directorio de direcciones de referencia en cada macro región.
- Basado en ciertos escenarios de implementación y escenarios de integración, desarrolle un paquete de software.
- Descargue directorios de direcciones de todos los sistemas en el perímetro de integración, cree un directorio de direcciones de referencia sobre la base de estos datos y asigne direcciones locales a referencias.
- Desarrollar un directorio de referencia de bienes inmuebles y asociar direcciones de referencia con bienes inmuebles mediante comunicación de muchos a muchos
- Integrarse con cada sistema de información.
- Desarrollar un proceso de gestión de direcciones y capacitar a expertos.
- Presione el botón rojo grande "Inicio" y reproduzca la solución en las 7 macro regiones de Rostelecom.
Puede hablar sobre cada uno de estos pasos durante mucho tiempo, cada uno de ellos fue interesante a su manera, pero en el marco de este artículo decidimos centrarnos en los dos aspectos más interesantes, en nuestra opinión, la formación de un algoritmo de análisis de direcciones y el nacimiento de una arquitectura de solución.
Para resolver el problema con las direcciones, fue necesario desarrollar un algoritmo inequívoco y coherente para el análisis de direcciones, que se basaría tanto en una base de direcciones de referencia única de la FIAS como en las especificaciones regionales de los espacios de direcciones en diferentes regiones de la Federación Rusa.
No fue posible automatizar completamente este algoritmo utilizando los conocidos métodos de Levenshtein y Yaro-Winkler. Por lo tanto, junto con el método automatizado de análisis de direcciones, también se aplicó el algoritmo desarrollado para evaluar las desviaciones permisibles reales de las líneas de dirección de los datos de referencia.
¡Pero esto no fue suficiente!
Para la comparación más precisa de los datos de dirección, fue necesario analizar los datos de los sistemas de contabilidad técnica. Por lo tanto, se formó un grupo de atributos adicionales que no pertenecen a la dirección, que formaron parte del algoritmo de confirmación de calidad de análisis final. Dichos atributos eran, por ejemplo, geocoordenadas e identificadores de equipos. Por lo tanto, si el mismo conmutador estaba vinculado a direcciones identificadas como posibles duplicados, este era un marcador que les permitía "colapsar" las direcciones en un objeto de dirección de referencia. La presencia de dicha información adicional nos permitió recopilar la base de datos más completa de todas las casas "de la esquina", que refleja los detalles de direccionamiento alternativo en la Federación de Rusia.
Pero a pesar de la presencia de una gran cantidad de información adicional: los datos de los sistemas de contabilidad técnica, las listas de devolución de correspondencia, las conexiones cruzadas entre los directorios de direcciones de los sistemas por los identificadores de suscriptor, en algunas ramas, la zona gris, una lista de direcciones que no se pudo identificar de manera única, podría alcanzar hasta el 10%.
¿Pero qué hacer con la zona gris? Después de todo, incluía no solo direcciones escritas incorrectamente, sino también las llamadas "direcciones tecnológicas": objetos de bienes raíces donde se instalan equipos y se brindan servicios, pero están ubicados completamente fuera de los límites de los conjuntos urbanos y, en consecuencia, no tienen direcciones en el sentido tradicional. Esta tarea se destacó en una dirección separada y utilizando todos los métodos conocidos de geoanalítica y análisis de datos semánticos, dichos objetos también se identificaron de forma única y se incluyeron en el directorio de direcciones de referencia.
La creación del directorio de direcciones de referencia fue el resultado de esfuerzos titánicos, pero el resultado de este trabajo fue aumentar la precisión para determinar la viabilidad técnica de conectarse a tales casas, lo que significa que se logró el objetivo.
El segundo aspecto igualmente difícil e interesante del proyecto estaba relacionado con el desarrollo de la arquitectura de la solución.
El nacimiento de la arquitectura de la solución final fue precedido por dos hipótesis erróneas:
- El directorio de direcciones de Rostelecom se puede construir sobre la base de una plataforma MDM industrial.
- El directorio de direcciones de Rostelecom se puede construir sobre la base de una plataforma industrial para el análisis y la normalización de direcciones.
Tanto esta como la otra hipótesis fueron un fracaso. La solución industrial MDM, que tiene todas las ventajas de la plataforma de administración de directorios, no puede presumir de algoritmos de normalización para direcciones rusas, y la capacidad de trabajar con la dirección como característica de un objeto inmobiliario. Y dado que poner orden en las direcciones era un objetivo clave del proyecto, este era un inconveniente crítico que superaba todas las ventajas considerables de una poderosa plataforma MDM industrial. Además, esa solución no tenía una plataforma de integración tolerante a fallas que pudiera proporcionar integración en tiempo real con docenas de nodos de la red interna de acuerdo con varios escenarios de integración.
El segundo enfoque para construir la arquitectura del directorio de direcciones se basó en la idea de construir MDM basado en el motor para analizar y normalizar direcciones. Esto parecía una solución lógica, ya que el cuello de botella del enfoque arquitectónico anterior era precisamente la función de buscar y hacer coincidir direcciones, llevándolas a una forma estándar y la capacidad de buscar posibles duplicados.
Sin embargo, la arquitectura de los productos para el análisis y la normalización de direcciones se centra en la velocidad de procesamiento de matrices de direcciones, la precisión de la selección de cadenas de direcciones similares, minimizando el error inverso: estos son los valores clave del producto para la normalización de direcciones, que a menudo se utilizan en el procesamiento de direcciones de listas de correo y en tareas similares La idea principal de estas soluciones es utilizar un único directorio de direcciones de referencia, FIAS, y llevar las listas recibidas a la entrada al estándar con una probabilidad calculada.
Las tareas de Rostelecom requerían la creación de su propio libro de referencia actualizado continuamente, que por un lado se basa en el FIAS, pero la presencia o ausencia de la dirección en el FIAS no es determinante para reconocer la dirección de referencia. Y esta era una tarea sin solución para la mayoría de los sistemas de normalización automática de direcciones.
Como resultado de largas búsquedas, se encontró una solución de compromiso con una arquitectura híbrida: una plataforma MDM patentada integrada con el motor de búsqueda HumanFactorLabs. La elección de este proveedor se determinó por su disposición a finalizar el mecanismo de búsqueda de direcciones para usar, como estándar, el directorio de direcciones de Rostelecom e implementar el mecanismo de sincronización regular del directorio de direcciones de Rostelecom con FIAS. Este refinamiento nos permitió proporcionar a los usuarios una búsqueda conveniente y de alta calidad de direcciones por línea, y la construcción de una solución MDM basada en productos OpenSource proporcionó flexibilidad en los enfoques de integración con el panorama de TI de Rostelecom. En el perímetro del panorama de TI de Rostelecom, existen sistemas heredados que se utilizan en el proceso comercial, pero que no pueden modificarse sustancialmente debido a sus limitaciones de diseño. Al alejarse de una solución industrial hacia el desarrollo interno, fue posible maximizar la adaptación de la plataforma MDM a las características del entorno de TI, manteniendo el concepto arquitectónico básico sin cambios.
¿Por qué es tan difícil?
Dadas las particularidades de la construcción del panorama de TI de Rostelecom, la primera implementación del sistema debería haber ocurrido directamente en el circuito industrial del panorama de TI de la macro región. En el circuito industrial, se introdujeron nuevas integraciones con sistemas clave del panorama de TI en la operación piloto, lo que tuvo un efecto en la implementación técnica de todos los procesos comerciales de Rostelecom PJSC: Ventas y conexión, Puesta en servicio de nuevas instalaciones de comunicación, Modernización de redes de distribución doméstica, Instalación, Soporte en las líneas 2 y 3, planificación de la construcción, informes. El riesgo de un error de implementación fue el bloqueo completo del trabajo de los flujos de información entre los sistemas de información de la macroregión, el cierre de todos los procesos de negocios, la caída de los riesgos de ventas y reputación.
Por lo tanto, antes de la primera implementación, cada paso se verificaba escrupulosamente, cada dirección y el sistema se ponía en funcionamiento, requería un servicio de 24 horas durante dos semanas después del inicio.
En el momento del primer lanzamiento, parecía que se habían superado todas las dificultades y luego simplemente habría una replicación. Pero teniendo en cuenta el hecho de que cada macro región es en el pasado reciente una compañía separada con su propio panorama de TI específico, cada "circulación" se convirtió en una nueva implementación completa.
Tecnologías y herramientas utilizadas
La estructura modular del sistema se muestra en la figura.
ClickableSobre el proceso técnico
Los desarrolladores del proyecto no solo escriben código, sino que son unidades creativas completas: toman decisiones técnicas, ofrecen ideas para el diseño de la interfaz, facilidad de uso del producto. Cualquier característica nueva se discute con los desarrolladores, se tiene en cuenta su opinión y experiencia. Cualquier tarea deja un espacio de desarrollo para la creatividad, por lo que cualquier conveniencia pequeña se realiza fácilmente y no requiere confirmación en un montón de casos.
Sobre el backend
El proyecto actual se basa en la tecnología Java EE y el servidor web WildFly. El proyecto es monolítico, aunque ahora solo está pasando por la planificación de su "separación" en microservicios separados, porque la carga en el proyecto está comenzando gradualmente a su pico y requiere una escala normal.
Sobre frontend
El proyecto se ha desarrollado durante mucho tiempo y utiliza GWT en el lado frontal. Y, aunque esta tecnología es pesada y desactualizada para 2019, le permite hacer una serie de cosas que no puede hacer en los marcos de JavaScript: escribir en Java y en el cliente y en el servidor, operar en las mismas entidades de bases de datos allí y allí, solo clonándolos a través de JpaCloner.
Sin DTO y otros cambios de parámetros de vacío a vacío. Esto le permite hacer un producto completo con un equipo relativamente pequeño de programadores. Aunque esta tecnología no es menos problemática: errores en Internet Explorer (y hay estándares corporativos después de todo), tiempos de compilación enormes, dificultades con la integración con las bibliotecas JavaScript modernas. Por lo tanto, en la nueva versión del producto, se planea abandonar esta tecnología en favor de algo más moderno.
Sobre escenarios de integración
El sistema implementa más de 20 escenarios de integración diferentes con los sistemas de información al consumidor de los directorios ORPON.
Los scripts de integración le permiten transferir una dirección única y una lista masiva de direcciones o elementos de dirección. El sistema ORPON puede iniciar la transferencia de una dirección y una lista de direcciones de forma independiente, por ejemplo, cuando un experto ingresa una nueva dirección en el sistema o cuando se descargan los cambios FIAS, o puede realizar estas acciones en respuesta a una solicitud de un sistema adyacente. La transferencia de directorios, atributos de bienes inmuebles, por supuesto.
El escenario más inusual, probablemente, puede considerarse el escenario de controlar la secuencia de transferencias de direcciones. En los procesos comerciales complejos, es muy importante controlar las conexiones que se realizan en línea: a qué sistemas debe dirigirse primero la dirección para evitar la interrupción de dichos procesos. Y también necesitábamos resolver este problema usando scripts estándar.
Sobre infraestructura
ORPON no es un sistema en tiempo real de alta carga: cada sistema de directorios de direcciones del consumidor tiene su propia copia del sistema de referencia, y el sistema no usa ORPON para buscar la dirección, sino que va a su propia base de datos.
En ORPON, el sistema del consumidor contacta si la dirección solicitada no se encuentra en el almacenamiento local. Esta solución arquitectónica permitió reducir significativamente la carga en la aplicación y proporcionar las características técnicas especificadas de la respuesta y la estabilidad utilizando clústeres de dos servidores. El diagrama de infraestructura de los componentes del sistema se muestra en la figura a continuación. Se puede hacer clic La composición de las aplicaciones de software de cada clúster es la siguiente:
- Clúster DBMS PostgreSQL
- RedHat Enterprise Linux 7.7 (64 bits)
- PostgreSQL Server 11.4 (64 bits)
- Marcapasos ClusterLabs | Corosync
- Clúster del servidor de aplicaciones
- RedHat Enterprise Linux 7.7 (64 bits)
- Servidor de aplicaciones WildFly 17 (64 bits)
- Software Citrix Balancer
- POR O PON
- Información sobre herramientas de la plataforma de clúster y factor de software
- Servidor de aplicaciones WildFly 17 (64 bits)
- Software Citrix Balancer
- Producto de software FACTOR
- "Consejos" de productos de software
Que nos dio
A menudo es difícil medir el efecto de la implementación de los sistemas de información, se producen muchos cambios de inmediato y no hay una respuesta definitiva: si hubo un efecto y, si lo hubo, qué causó las consecuencias positivas o negativas. Especialmente si está planteando un proyecto de infraestructura que se encuentra en el corazón de su panorama de TI.Tuvimos suerte y en una de las macro regiones pudimos realizar un experimento limpio. Durante el período de tiempo, solo hubo un cambio en los procesos organizacionales y de TI, y esta fue la introducción del Directorio de direcciones unificadas - ORPON. La escala del efecto fue enorme: el número de respuestas positivas para verificar la viabilidad técnica de la conexión aumentó en un 22% después de la introducción del sistema. Antes de la implementación en la macro-región, no había una conexión inequívoca entre la dirección en el sistema, de donde proviene la solicitud de soporte técnico y el sistema de contabilidad técnica, donde se verifica la posibilidad: qué dirección se seleccionará fue una lotería. Además, había muchos duplicados en SLTU y el equipo que estaba en la casa se podía distribuir aleatoriamente a varias direcciones, una de las cuales se seleccionó al azar para verificar la viabilidad técnica.La implementación del sistema permitió reducir esta incertidumbre a 0 y, como resultado, eliminar la pérdida de clientes en la etapa de ingresar a la aplicación en el sitio web RT.RU debido a errores en la determinación de la factibilidad técnica de proporcionar el servicio en la dirección.Cuando recibimos estos resultados, ¡no creíamos en nuestros ojos! Estos números excedieron nuestras expectativas más salvajes.Este artículo fue preparado por el equipo de gestión de datos de Rostelecom