Зачем Ростелекому знать об адресах все и даже немного больше? Интернет, несмотря на весь свой цифровой имидж, — это вещь, созданная в аналоговом мире.
И до сих пор, чтобы в доме был высокоскоростной интернет, к дому необходимо физически подключить кабель.
Именно адрес дома является ключевым объектом идентификации в многоэтапном процессе предоставления интернет-услуг.
Адрес появляется в тот момент, когда к нам в Ростелеком звонит клиент с вопросом, можно ли подключиться к Интернету.
Оператору необходимо знать адрес клиента, чтобы проверить, проложен ли к дому интернет-кабель.
Адрес используется до этапа сопровождения и обслуживания существующего клиента.
При обращении в службу технической поддержки по адресу клиента проверяется, является ли проблема локальной, или авария носит массовый характер и проблема затронула весь квартал.
И конечно, на каждом этапе процесса важна скорость ответа клиенту.
В этом посте мы поговорим о том, насколько важен адрес клиента для наших внутренних систем, почему ФИАС не панацея и почему был создан Единый домашний паспорт. Чем быстрее клиент получит подтверждение о возможности подключения к Интернету, тем выше вероятность того, что он выберет Ростелеком.
Рынок интернет-услуг высококонкурентен и малейшая задержка с ответом на запрос клиента может снизить его лояльность и спровоцировать переход к другому, более отзывчивому оператору связи.
Упрощенно бизнес-процесс оформления заявки на подключение к Интернету выглядит следующим образом.
В систему поступает заявка от клиента — это может быть сайт или другая система, где можно обрабатывать заявки.
Далее запрос отправляется в систему линейного технического учета для проверки наличия технической возможности подключения клиента по его адресу.
Если есть техническая возможность, то приложение переносится в рабочую систему для монтажников, которые подключат клиента к сети Интернет. После включения услуги в сети приложение переходит в биллинг, где рассчитывается стоимость услуг для абонента.
Ежемесячные загрузки генерируются из счетов для отправки счетов-фактур и претензионных писем должникам.
Все эти информационные системы были разработаны и внедрены еще до объединения «Ростелекома» и, как правило, до того, как интернет-рынок стал настолько высококонкурентным.
Существующие информационные системы обеспечивали непрерывный процесс продаж и подключения услуг связи на всей территории страны, но при этом интеграция между ними осуществлялась в полуавтоматическом режиме.
Системы были слабо связаны друг с другом и не были предназначены для взаимодействия в рамках единого информационного пространства.
Каждая система использовала свои адресные каталоги, справочники и принципы идентификации объектов.
Для эффективного взаимодействия всех систем в едином централизованном бизнес-процессе продаж и обслуживания клиентов «Ростелекому» необходимо было обеспечить общий «протокол» общения — систему классификации и идентификации адресных объектов.
При этом отправной точкой должен быть объект недвижимости, который может иметь адрес, может не иметь его, может иметь альтернативную адресацию, но в любом случае должен быть определен однозначно.
В этих целях был запущен проект – Единый паспорт дома (ОРПОН), который обеспечил переход от разрозненных, неполных, противоречивых источников данных к единому интегрированному адресному пространству, в котором взаимодействие ИТ-систем всех филиалов Ростелекома происходит автоматически, без ручная обработка.
Как все было вплоть до единого адресного каталога? Почему ФИАС не подходит? Почему все сложнее, чем кажется?
Когда перед компанией стоит задача создания каталога, все кажется очень простым.Во-первых, адрес – это что-то знакомое каждому, каждый сталкивается с ним каждый день, каждый умеет писать адрес: как Бог на душу положит. Во-вторых, после первых пятнадцати минут изучения вопроса в Интернете вы узнаете, что налоговая инспекция уже создала адресный справочник по всей России.
А вам останется только скачать базу ФИАС, загрузить ее в базу и адресная книга готова.
В каком-то смысле, конечно, это правда.
Есть федеральная адресно-информационная система, в ней есть адреса, они регулярно обновляются, и ФНС регулярно публикует обновления.
Этот справочник подойдет для многих задач, например, для задач Федеральной налоговой службы.
Но ФИАС не смогла решить проблемы «Ростелекома».
В адресной книге "Ростелекома" адресов существенно больше, чем в адресной книге налоговой инспекции, а о строительстве нового дома "Ростелеком" узнает в среднем на несколько лет раньше, чем этот дом появляется в справочнике ФИАС.
И Ростелекому важно знать не просто адреса, а однозначно связать адрес с объектом недвижимости, определить все значимые характеристики этого объекта недвижимости: год постройки, материал стен, назначение и еще 90 очень важных параметров.
Но основная проблема заключалась в том, что на момент старта проекта у Ростелекома было не менее 40 активно используемых систем, каждая из которых имела свою адресную книгу, имела собственную базу адресов, сравнение которых с ФИАС дало около 60 % совпадающих адресов.
и 40% адресов, о которых налоговая ничего не знает. Эти 40% адресов нельзя было назвать «мусором», потому что они содержали примерно такой же процент абонентской базы, а отказ от адресов означает отказ и от абонентов.
Для каждого адреса из выборки необходимо было понять: существует ли такой адрес и является ли этот адрес независимым или это дубликат другого адреса? А может это угловой дом и мы имеем дело с альтернативной адресацией? Необходимо было придумать решение, которое позволило бы связать между собой хотя бы 95% адресов.
То есть для 35% адресов, несогласованных с ФИАС, нужно было придумать алгоритм, который бы позволял принимать решения по ним.
Это должно было произойти автоматически.
Чтобы вручную обработать около 40% адресной базы «Ростелекома», потребуется около 120 человеко-лет. И устранять проблему человеческого фактора с помощью человека – не самое мудрое решение.
Как мы все это сделали и почему это заняло так много времени
В рамках проекта необходимо было решить две основные задачи: создать адресную книгу, которая бы содержала все исправные адреса и не содержала мусора, и разработать систему, которая позволила бы онлайн-поддержание адресной книги в актуальном состоянии на протяжении всего срока службы.весь ИТ-ландшафт Ростелекома.
Упрощенно процесс реализации проекта можно описать как последовательность следующих шагов: Провести аудит всех систем, использующих адреса в своих бизнес-процессах.
То есть провести аудит всего ИТ-ландшафта Ростелекома.
Определить сценарий внедрения и сценарии интеграции справочника адресов в каждом макрорегионе.
На основе определенных сценариев внедрения и сценариев интеграции разработать программный комплекс.
Загрузите адресные книги всех систем внутри периметра интеграции, создайте на основе этих данных эталонную адресную книгу и сопоставьте локальные адреса с эталонными.
Разработать справочный справочник объектов недвижимости и связать ссылочные адреса с объектами недвижимости с помощью связи «многие ко многим».
Интеграция с каждой информационной системой Разработать процесс ведения адресов и обучить специалистов Нажмите большую красную кнопку «Старт» и тиражируйте решение на все 7 макрорегионов Ростелекома.
О каждом из этих шагов можно говорить долго, каждый из них был по-своему интересен, но в рамках данной статьи мы решили сосредоточить внимание на двух наиболее интересных, на наш взгляд, аспектах – формировании Алгоритм синтаксического анализа адресов и рождение архитектуры решения.
Для решения проблемы с адресами необходимо было разработать однозначный и последовательный алгоритм парсинга адресов, который базировался бы как на единой справочной базе адресов ФИАС, так и учитывал бы региональную специфику ведения адресных пространств в разных субъектах Российской Федерации.
Российская Федерация.
Полностью автоматизировать этот алгоритм с помощью известных методов Левенштейна и Яро-Винклера не удалось.
Поэтому совместно с автоматизированным методом разбора адресов был использован разработанный алгоритм оценки фактических допустимых отклонений адресных строк от справочных данных.
Но этого было недостаточно! Для максимально точного сравнения адресных данных нам пришлось проанализировать данные систем технического учета.
Таким образом был сформирован пул дополнительных неадресных атрибутов, которые вошли в итоговый алгоритм подтверждения качества парсинга.
Такими атрибутами были, например, геокоординаты и идентификаторы оборудования.
Итак, если один и тот же переключатель был привязан к адресам, которые были идентифицированы как потенциальные дубликаты, это был маркер, позволяющий «свернуть» адреса в один объект ссылочного адреса.
Наличие такой дополнительной информации позволило собрать наиболее полную базу данных по всем «угловым» домам, отражающую всю специфику альтернативной адресации в РФ.
Но несмотря на наличие большого количества дополнительной информации: данные систем технического учета, списки обратной корреспонденции, перекрестные ссылки между адресными книгами систем по идентификаторам абонентов, в некоторых филиалах серая зона - список адресов, которые не могли быть однозначно идентифицированные - могут достигать до 10%.
Но что делать с серой зоной? Ведь в него вошли не только неправильно написанные адреса, но и так называемые «технологические адреса» — объекты недвижимости, где установлено оборудование и оказаны услуги, но они расположены вовсе не в пределах городских территорий и, соответственно, не имеют адреса в традиционном смысле.
Данная задача была выделена в отдельное направление и с использованием всех известных методов геоаналитики и семантического анализа данных такие объекты также были однозначно идентифицированы и включены в справочник адресов.
Создание справочника адресов стало результатом титанических усилий, но результатом этой работы стало повышение точности определения технической возможности подключения к таким домам, а значит цель достигнута.
Второй, не менее сложный и интересный аспект проекта был связан с разработкой архитектуры решения.
Рождению окончательной архитектуры решения предшествовали две ошибочные гипотезы: Адресная книга «Ростелекома» может быть построена на базе промышленной MDM-платформы.
Адресная книга Ростелекома может быть построена на базе промышленной платформы парсинга и нормализации адресов.
Обе гипотезы оказались неудачными.
Промышленное MDM-решение, обладая всеми преимуществами платформы управления каталогами, не могло похвастаться алгоритмами нормализации русских адресов и возможностью работы с адресом как характеристикой объекта недвижимости.
А поскольку наведение порядка в адресах было ключевой целью проекта, это стало критическим недостатком, перевесившим все немалые преимущества мощной промышленной MDM-платформы.
Кроме того, это решение не имело отказоустойчивой интеграционной платформы, способной обеспечить интеграцию в режиме реального времени с десятками узлов внутренней сети при различных сценариях интеграции.
Второй подход к построению архитектуры адресного каталога был основан на идее построения MDM на основе движка парсинга и нормализации адресов.
Это казалось логичным решением, поскольку узким местом предыдущего архитектурного подхода была именно функция поиска и сравнения адресов, приведения их к ссылочному виду и возможность поиска потенциальных дубликатов.
Однако архитектура продуктов синтаксического анализа и нормализации адресов ориентирована на скорость обработки массивов адресов, точность выбора схожих адресных строк и минимизацию обратной ошибки — эти показатели являются ключевым значением продукта нормализации адресов, который часто используется при обработке списков почтовых адресов и подобных задачах.
Основная идея этих решений заключается в использовании единой справочной адресной книги - ФИАС - и приведении полученных на вход списков к стандарту с рассчитанной вероятностью.
Задачи «Ростелекома» требовали создания собственного, постоянно обновляемого справочного справочника, который, с одной стороны, основан на ФИАС, однако наличие или отсутствие адреса в ФИАС не является решающим фактором для признания адреса справочным.
И это была невыполнимая задача для большинства систем автоматической нормализации адресов.
В результате долгих поисков было найдено компромиссное решение с гибридной архитектурой — MDM-платформа собственной разработки, интегрированная с поисковой системой HumanFactorLabs. Выбор этого поставщика был обусловлен желанием доработать механизм поиска адресов для использования адресной книги Ростелекома в качестве стандарта, а также реализовать механизм регулярной синхронизации адресной книги Ростелекома с ФИАС.
Данное улучшение позволило предоставить пользователям удобный и качественный поиск адресов по строке, а построение MDM-решения на базе продуктов OpenSource обеспечило гибкость в подходах к интеграции с ИТ-ландшафтом «Ростелекома».
В периметре ИТ-ландшафта «Ростелекома» существуют устаревшие системы, которые используются в бизнес-процессе, но не могут быть существенно улучшены из-за конструктивных ограничений.
Переход от индустриального решения к собственной разработке позволил нам максимально адаптировать MDM-платформу к специфике ИТ-среды, сохранив неизменной базовую архитектурную концепцию.
Почему это так сложно?
Учитывая специфику построения ИТ-ландшафта «Ростелекома», первое внедрение системы должно было произойти непосредственно в промышленном контуре ИТ-ландшафта макрорегиона.На промышленном уровне в опытную эксплуатацию были введены новые интеграции с ключевыми системами ИТ-ландшафта, что отразилось на технической реализации всех бизнес-процессов ПАО «Ростелеком»: «Продажи и подключение», «Ввод в эксплуатацию новых объектов связи», «Модернизация домашних распределительных сетей», «Модернизация домашних распределительных сетей».
Монтаж, Поддержка по 2 и 3 линиям, Планирование строительства, Отчетность.
Риском ошибки внедрения стала полная блокировка информационных потоков между информационными системами макрорегиона, остановка всех бизнес-процессов, падение продаж и репутационные риски.
Поэтому перед первым внедрением каждый шаг, каждый адрес и ввод системы в эксплуатацию тщательно выверялись, что требовало круглосуточного дежурства в течение двух недель после запуска.
На момент первого запуска казалось, что все трудности преодолены и остальное можно будет просто тиражировать.
Но с учетом того, что каждый макрорегион в недавнем прошлом был отдельной компанией со своим специфическим ИТ-ландшафтом, каждый «тираж» превращался в полноценное новое внедрение.
Используемые технологии и инструменты
Модульная структура системы представлена на рисунке.
Кликабельно
О техническом процессе
Разработчики проекта не просто пишут код, а являются полноценными творческими единицами: принимают технические решения, предлагают идеи по дизайну интерфейса и удобству использования продукта.Любая новая функция обсуждается с разработчиками, учитывается их мнение и опыт. Любая задача оставляет простор для творчества разработчику, поэтому любое небольшое удобство легко реализуется и не требует подтверждения от кучи авторитетов.
О бэкэнде
Текущий проект основан на технологии Java EE и веб-сервере WildFly. Проект монолитный, хотя сейчас ведется планирование его «разделения» на отдельные микросервисы, поскольку нагрузка на проект постепенно начинает достигать пика, и он требует нормального масштабирования.
О фронтенде
Проект развивается уже довольно давно и использует GWT на стороне интерфейса.И, хотя это тяжелая и устаревшая к 2019 году технология, она позволяет делать ряд вещей, которые невозможно сделать в JavaScript-фреймворках: писать на Java и на клиенте, и на сервере, оперировать одними и теми же сущностями базы данных и там, и там.
туда, просто клонировав их через JpaCloner. Никакого DTO или другого смещения параметров с пустого на пустое.
Это позволяет создать полноценный продукт сравнительно небольшой командой программистов.
Хотя эта технология доставляет не меньше хлопот: ошибки в Internet Explorer (а там тоже есть корпоративные стандарты), огромное время компиляции, трудности с интеграцией с современными библиотеками JavaScript. Поэтому в новой версии продукта планируется отказаться от этой технологии в пользу чего-то более современного.
О сценариях интеграции
В системе реализовано более 20 различных сценариев интеграции с системами, потребляющими информацию из справочников ORPON. Сценарии интеграции позволяют передавать как одиночный адрес, так и групповой список адресов или элементов адреса.Система ОРПОН может инициировать передачу адреса и списка адресов самостоятельно, например, при вводе экспертом в систему нового адреса или при загрузке изменений ФИАС, либо выполнять эти действия в ответ на запрос соседнего система.
Перенос справочников и атрибутов объектов недвижимости – конечно.
Самым необычным сценарием, пожалуй, можно считать сценарий контроля последовательности передачи адреса.
В сложных процессах бизнес-подключений, которые происходят в режиме онлайн, очень важно контролировать, в какую систему в первую очередь должен идти адрес, чтобы избежать нарушения таких процессов.
И нам тоже нужно было решить эту задачу, используя стандартные сценарии.
Об инфраструктуре
ОРПОН не является высоконагруженной системой реального времени — каждая потребительская система адресных справочников имеет свою копию справочной системы, и для поиска адреса система не обращается к ОРПОН, а обращается к собственной базе данных.Потребительская система связывается с ORPON, если запрошенный адрес не найден в локальном хранилище.
Такое архитектурное решение позволило существенно снизить нагрузку на приложение и обеспечить заданные технические характеристики отклика и стабильности с помощью кластеров из двух серверов.
Инфраструктурная схема компонентов системы представлена на рисунке ниже.
Кликабельно
Состав программных приложений для каждого кластера следующий: Кластер СУБД PostgreSQL
RedHat Enterprise Linux 7.7 (64-разрядная версия)
PostgreSQL Server 11.4 (64-разрядная версия)
Кардиостимулятор ClusterLabs|Corosync
Кластер серверов приложений
RedHat Enterprise Linux 7.7 (64-разрядная версия)
Сервер приложений WildFly 17 (64-разрядная версия)
Программное обеспечение Citrix Balancer
ПО ИЛИ PON
Платформа «Кластер подсказок» и программное обеспечение «Фактор»
Сервер приложений WildFly 17 (64-разрядная версия)
Программное обеспечение Citrix Balancer
Программный продукт ФАКТОР
Программный продукт «Подсказки»
Что это нам дало?
Часто бывает трудно измерить эффект от внедрения информационных систем; происходит сразу много изменений и нет однозначного ответа - был ли эффект, а если вдруг был, то что вызвало положительные или отрицательные последствия.Тем более, если вы поднимаете инфраструктурный проект, расположенный в самом сердце вашего ИТ-ландшафта.
Нам повезло и в одном из макрорегионов нам удалось провести чистый эксперимент. За период времени в организационных и ИТ-процессах произошло только одно изменение – это внедрение Единого каталога адресов – ОРПОН.
Масштаб эффекта был колоссальным — количество положительных откликов на проверку технической связи увеличилось на 22% после внедрения системы.
До внедрения в макрорегионе не было четкой связи между адресом в системе, откуда приходит запрос на техническую возможность, и системой технического учета, где проверяется возможность - какой адрес будет выбран, это была лотерея.
Кроме того, в СЛТУ было много дубликатов и оборудование, находившееся в доме, могло быть случайным образом распределено по нескольким адресам, один из которых случайным образом выбирался для проверки технических возможностей.
Внедрение системы позволило снизить эту неопределенность до 0, и как следствие исключить потерю клиентов на этапе подачи заявки на сайте RT.RU из-за ошибок при определении технической возможности оказания услуги на сайте RT.RU. адрес.
Когда мы получили эти результаты, мы не могли поверить своим глазам! Эти цифры превзошли наши самые смелые ожидания.
Статью подготовила команда управления данными Ростелекома.
Теги: #базы данных #Большие данные #Анализ и проектирование систем #Ростелеком #управление данными в Ростелекоме #Геоинформационные услуги #адреса #ФИАС #единый домашний паспорт #ОРПОН
-
Ветер U100
19 Oct, 24 -
Сериал: Онлайн Просмотр Или Скачивание?
19 Oct, 24 -
Изобретение Favicon.ico
19 Oct, 24 -
Мерч! Мерч! Мерч! И... Единороги
19 Oct, 24 -
Личный Опыт Внедрения Системы Glpi. Часть 2
19 Oct, 24 -
24 Совета Для Разработчика Javascript
19 Oct, 24
