Wie wir das Adressverzeichnis von Rostelecom erstellt haben

Warum sollte Rostelecom alles und noch ein bisschen mehr über Adressen wissen?

Das Internet mit all seinen digitalen Bildern ist eine Sache, die in der analogen Welt geschaffen wurde. Bisher muss ein Kabel physisch mit dem Haus verbunden sein, damit das Haus über Highspeed-Internet verfügt.

Es ist die Adresse des Hauses, die im mehrstufigen Prozess der Bereitstellung von Internetdiensten das zentrale Identifikationsobjekt darstellt.

Die Adresse wird in dem Moment angezeigt, in dem ein Kunde bei Rostelecom anruft und fragt, ob eine Verbindung zum Internet hergestellt werden kann. Der Betreiber muss die Adresse des Kunden kennen, um zu überprüfen, ob das Kabel mit dem Internet mit dem Haus verbunden ist. Die Adresse wird bis zum Support- und Servicestadium des bestehenden Kunden verwendet. Wenn Sie sich an den technischen Support unter der Adresse des Kunden wenden, wird überprüft, ob das Problem vor Ort vorliegt oder ob der Unfall schwerwiegend ist und ob das Problem das gesamte Quartal betroffen hat.

Und natürlich ist bei jedem Schritt des Prozesses die Geschwindigkeit der Reaktion auf den Kunden wichtig.

In diesem Beitrag werden wir darüber sprechen, wie wichtig die Kundenadresse für unsere internen Systeme ist, warum FIAS kein Allheilmittel ist und warum der Unified Passport zu Hause erstellt wurde.

Je schneller der Kunde eine Bestätigung über die Verbindung zum Internet erhält, desto wahrscheinlicher ist es, dass er sich für Rostelecom entscheidet. Der Markt für Internetdienste ist hart umkämpft und die geringste Verzögerung bei der Beantwortung von Kundenanfragen kann die Kundenbindung verringern und einen Wechsel zu einem anderen, effizienteren Telekommunikationsbetreiber provozieren.

Vereinfacht ausgedrückt lautet der Geschäftsprozess zum Übergeben eines Antrags auf eine Internetverbindung wie folgt. Eine Anwendung von einem Client betritt das System - es kann sich um eine Website oder ein anderes System handeln, auf dem Anwendungen verwaltet werden können. Anschließend wird die Anforderung an das lineare technische Abrechnungssystem gesendet, um die Verfügbarkeit der technischen Konnektivität für den Kunden an seiner Adresse zu überprüfen. Wenn es eine technische Möglichkeit gibt, wird die Anwendung für Installateure, die den Client mit dem Internet verbinden, an das Arbeitssystem übertragen. Nachdem der Dienst im Netzwerk aktiviert wurde, wechselt die Anwendung zur Abrechnung, in der die Kosten der Dienste für den Abonnenten berechnet werden. Monatliche Downloads ergeben sich aus der Rechnungsstellung für den Versand von Rechnungen und Forderungsschreiben an Schuldner.

Alle diese Informationssysteme wurden vor dem Zusammenschluss von Rostelecom und in der Regel vor dem starken Wettbewerb auf dem Internetmarkt entwickelt und implementiert.

Die vorhandenen Informationssysteme ermöglichten einen kontinuierlichen Verkaufs- und Verbindungsprozess von Kommunikationsdiensten im ganzen Land, gleichzeitig wurde die Integration zwischen ihnen in einem halbautomatischen Modus durchgeführt. Die Systeme waren schwach miteinander verbunden und nicht für die Interaktion innerhalb eines einzigen Informationsraums ausgelegt. Jedes System verwendete seine eigenen Adresskataloge, Verzeichnisse und Prinzipien zur Identifizierung von Objekten.

Für die effektive Interaktion aller Systeme in einem einzigen zentralisierten Geschäftsprozess von Verkauf und Kundenservice von Rostelecom war es erforderlich, ein gemeinsames "Kommunikationsprotokoll" bereitzustellen - ein System zur Klassifizierung und Identifizierung adressierbarer Objekte. In diesem Fall sollte der Ausgangspunkt genau die Eigenschaft sein, die eine Adresse haben kann, möglicherweise nicht, möglicherweise eine alternative Adressierung hat, aber in jedem Fall muss sie eindeutig bestimmt werden.

Zu diesem Zweck wurde ein Projekt gestartet - der Unified Passport at Home (ORPON), der den Übergang von unterschiedlichen, unvollständigen, widersprüchlichen Datenquellen zu einem einzigen integrierten Adressraum sicherstellte, in dem die Interaktion zwischen IT-Systemen aller Rostelecom-Niederlassungen automatisch und ohne manuelle Bearbeitung erfolgt.

Wie war alles vor einem einzelnen Adressverzeichnis? Warum passt FIAS nicht? Warum ist alles komplizierter als es scheint?

Wenn das Unternehmen die Aufgabe hat, ein Verzeichnis zu erstellen, scheint alles sehr einfach zu sein.
Zuallererst ist eine Adresse jedem vertraut, jeder ist jeden Tag damit konfrontiert, jeder weiß, wie man eine Adresse schreibt: wie Gott sie in die Seele legt.

Zweitens werden Sie nach den ersten fünfzehn Minuten des Studiums des Themas im Internet feststellen, dass in der Steuer bereits ein Adressverzeichnis für ganz Russland erstellt wurde. Sie müssen nur noch die FIAS-Datenbank herunterladen, in die Datenbank hochladen und das Adressverzeichnis ist fertig. In gewisser Weise ist dies natürlich der Fall.

Es gibt ein bundesweites Informationsadressensystem, in dem Adressen vorhanden sind, die regelmäßig aktualisiert werden und das vom Bundessteuerdienst regelmäßig aktualisiert wird. Dieser Leitfaden ist für viele Aufgaben geeignet, zum Beispiel für die Aufgaben des Bundessteueramtes.

Aber FIAS konnte die Probleme von Rostelecom nicht lösen. In den Adressverzeichnissen von Rostelecom gibt es viel mehr Adressen als im Steueradressverzeichnis, und Rostelecom erfährt im Durchschnitt einige Jahre früher, wie ein neues Haus gebaut wird, als dieses Haus im FIAS-Verzeichnis aufgeführt ist. Und für Rostelecom ist es wichtig, nicht nur Adressen zu kennen, sondern eine Adresse eindeutig mit einem Immobilienobjekt zu verknüpfen und alle wesentlichen Merkmale dieses Objekts zu bestimmen: Baujahr, Wandmaterial, Verwendungszweck und 90 weitere sehr wichtige Parameter.

Das Hauptproblem bestand jedoch darin, dass es zu Beginn des Projekts in Rostelecom mindestens 40 aktiv genutzte Systeme gab, die jeweils über ein eigenes Adressverzeichnis verfügten und über eine eigene Datenbank mit Adressen verfügten, deren Vergleich mit dem FIAS etwa 60% der übereinstimmenden Adressen ergab und 40% der Adressen, von denen das Finanzamt nichts weiß.

Es war unmöglich, diese 40% der Adressen als "Müll" zu definieren, da sich ungefähr derselbe Prozentsatz der Teilnehmer auf ihnen befand und die Ablehnung der Adressen auch die Ablehnung der Teilnehmer bedeutete. Für jede Adresse aus dem Dropout musste verstanden werden: Existiert eine solche Adresse und ist diese Adresse unabhängig oder handelt es sich um ein Duplikat einer anderen Adresse? Oder ist es ein Eckhaus und es handelt sich um eine alternative Adressierung?

Es musste eine Lösung gefunden werden, mit der mindestens 95% der Adressen verbunden werden konnten. Das heißt, für 35% der Adressen, die nicht mit FIAS übereinstimmten, war es erforderlich, einen Algorithmus zu entwickeln, mit dem sie Entscheidungen über sie treffen können. Dies musste automatisch erfolgen. Die manuelle Verarbeitung von ca. 40% der Rostelecom-Adressbasis würde ca. 120 Mannjahre in Anspruch nehmen. Und das Problem des menschlichen Faktors mit Hilfe des Menschen zu beseitigen, ist nicht die klügste Entscheidung.

Wie wir das alles gemacht haben und warum so lange

Im Rahmen des Projekts waren zwei Hauptaufgaben erforderlich: ein Adressverzeichnis zu erstellen, das alle guten Adressen und keinen Müll enthält, und ein System zu entwickeln, das die Online-Pflege des Adressverzeichnisses im aktuellen Zustand in der gesamten IT-Landschaft von Rostelecom ermöglicht.

Vereinfacht kann der Projektdurchführungsprozess als eine Abfolge der folgenden Schritte beschrieben werden:

• Prüfen Sie alle Systeme, die Adressen in ihren Geschäftsprozessen verwenden. Das heißt, die gesamte IT-Landschaft von Rostelecom zu prüfen.
• Definieren Sie ein Implementierungsszenario und Integrationsszenarios eines Referenzadressverzeichnisses in jedem Makrobereich.
• Entwickeln Sie basierend auf bestimmten Implementierungsszenarien und Integrationsszenarien ein Softwarepaket.
• Entladen Sie Adressverzeichnisse von allen Systemen im Umkreis der Integration, erstellen Sie ein Referenzadressverzeichnis auf der Grundlage dieser Daten und ordnen Sie lokale Adressen Referenzadressen zu.
• Erstellen eines Referenzverzeichnisses von Immobilien und Verknüpfen von Referenzadressen mit Immobilien durch Kommunikation von vielen zu vielen
• In jedes Informationssystem integrieren
• Entwickeln Sie einen Adressverwaltungsprozess und schulen Sie Experten
• Drücken Sie die große rote Schaltfläche „Start“ und replizieren Sie die Lösung in alle 7 Makroregionen von Rostelecom.

Sie können über jeden dieser Schritte lange sprechen, jeder von ihnen war auf seine Weise interessant, aber im Rahmen dieses Artikels haben wir beschlossen, uns auf die beiden unserer Meinung nach interessantesten Aspekte zu konzentrieren - die Bildung eines Adressanalyse-Algorithmus und die Entstehung einer Lösungsarchitektur.
Um das Adressproblem zu lösen, musste ein eindeutiger und konsistenter Algorithmus für das Adress-Parsing entwickelt werden, der sowohl auf einer einzigen Referenzadressbasis des FIAS als auch auf den regionalen Besonderheiten der Adressräume in verschiedenen Regionen der Russischen Föderation aufbaut.

Mit den bekannten Methoden von Levenshtein und Yaro-Winkler konnte dieser Algorithmus nicht vollständig automatisiert werden. Daher wurde neben der automatisierten Methode der Adressanalyse auch der entwickelte Algorithmus zur Beurteilung der tatsächlich zulässigen Abweichungen der Adresszeilen von den Referenzdaten angewendet.

Aber das war nicht genug!

Für den genauesten Vergleich von Adressdaten mussten die Daten der technischen Abrechnungssysteme analysiert werden. Auf diese Weise wurde ein Pool von zusätzlichen Attributen gebildet, die keine Adressen enthielten und Teil des endgültigen Algorithmus zur Bestätigung der Parsingqualität waren. Solche Attribute waren beispielsweise Geokoordinaten und Gerätekennungen. Wenn also derselbe Schalter mit Adressen verknüpft war, die als potenzielle Duplikate identifiziert wurden, war dies eine Markierung, die es ihnen ermöglichte, Adressen in ein Referenzadressobjekt zu "reduzieren". Das Vorhandensein solcher zusätzlichen Informationen ermöglichte es uns, die umfassendste Datenbank aller „Eckhäuser“ zu erfassen, die die Besonderheiten der alternativen Adressierung in der Russischen Föderation widerspiegelt.

Aber trotz des Vorhandenseins einer großen Menge zusätzlicher Informationen: Daten des technischen Abrechnungssystems, Korrespondenzrückgabelisten, Querverbindungen zwischen Adressverzeichnissen von Systemen nach Teilnehmeridentifikatoren, könnte die Grauzone - eine Liste von Adressen, die nicht eindeutig identifiziert werden konnten - in einigen Zweigen bis zu 10% erreichen.

Aber was tun mit der Grauzone? Schließlich enthielt es nicht nur falsch geschriebene Adressen, sondern auch die sogenannten „Technologischen Adressen“ - Immobilienobjekte, bei denen Geräte und Dienstleistungen bereitgestellt werden, die sich jedoch vollständig außerhalb der Grenzen städtischer Arrays befinden und dementsprechend keine Adressen im herkömmlichen Sinne haben. Diese Aufgabe wurde in einer eigenen Richtung herausgearbeitet und unter Verwendung aller bekannten Methoden der Geoanalyse und semantischen Datenanalyse wurden solche Objekte auch eindeutig identifiziert und in das Referenzadressverzeichnis aufgenommen.

Die Erstellung des Referenzadressverzeichnisses war das Ergebnis von Bemühungen der Titanen, aber das Ergebnis dieser Arbeit war es, die Genauigkeit der Bestimmung der technischen Machbarkeit der Verbindung mit solchen Häusern zu erhöhen, was bedeutet, dass das Ziel erreicht wurde.

Der zweite ebenso schwierige und interessante Aspekt des Projekts betraf die Entwicklung der Lösungsarchitektur.

Der Geburt der endgültigen Lösungsarchitektur gingen zwei falsche Hypothesen voraus:

1. Das Adressverzeichnis von Rostelecom kann auf der Basis einer industriellen MDM-Plattform aufgebaut werden.
2. Das Adressverzeichnis von Rostelecom kann auf der Grundlage einer industriellen Plattform für Adressanalyse und -normalisierung erstellt werden.

Sowohl diese als auch die andere Hypothese waren ein Misserfolg. Die industrielle MDM-Lösung, die alle Vorteile der Verzeichnisverwaltungsplattform aufweist, konnte sich nicht mit Normalisierungsalgorithmen für russische Adressen und der Fähigkeit rühmen, mit der Adresse als Merkmal eines Immobilienobjekts zu arbeiten. Und da die Adressbestellung ein zentrales Ziel des Projekts war, war dies ein entscheidender Nachteil, der alle erheblichen Vorteile einer leistungsstarken industriellen MDM-Plattform aufwog. Darüber hinaus verfügte diese Lösung nicht über eine ausfallsichere Integrationsplattform, die eine Echtzeitintegration mit Dutzenden von Knoten des internen Netzwerks gemäß verschiedener Integrationsszenarien ermöglichen würde.

Der zweite Ansatz zum Erstellen der Architektur des Adressverzeichnisses basierte auf der Idee, MDM basierend auf der Engine zum Parsen und Normalisieren von Adressen zu erstellen. Dies schien eine logische Lösung zu sein, da der Engpass des vorherigen Architekturansatzes genau darin bestand, Adressen zu suchen und abzugleichen, sie auf ein Standardformular zu bringen und nach potenziellen Duplikaten zu suchen.

Nichtsdestotrotz konzentriert sich die Architektur der Produkte zur Adressanalyse und -normalisierung auf die Geschwindigkeit der Verarbeitung von Adressfeldern, die Genauigkeit des Abgleichs ähnlicher Adresszeichenfolgen und die Minimierung des Umkehrfehlers - dies sind die Schlüsselwerte des Produkts zur Adressnormalisierung, die häufig bei der Verarbeitung von Adressen und Adressen von Mailinglisten verwendet werden in ähnlichen Aufgaben. Die Hauptidee dieser Lösungen besteht darin, ein einziges Referenzadressverzeichnis (FIAS) zu verwenden und die am Eingang empfangenen Listen mit einer berechneten Wahrscheinlichkeit in den Standard einzubeziehen.

Die Aufgaben von Rostelecom erforderten die Erstellung eines eigenen, ständig aktualisierten Nachschlagewerks, das zum einen auf dem FIAS basiert, zum Erkennen der Referenzadresse jedoch nicht das Vorhandensein oder Fehlen der Adresse im FIAS bestimmt. Und dies war eine unlösbare Aufgabe für die meisten automatischen Adressnormalisierungssysteme.

Als Ergebnis langwieriger Suchen wurde eine Kompromisslösung mit einer Hybridarchitektur gefunden - eine proprietäre MDM-Plattform, die in die HumanFactorLabs-Suchmaschine integriert ist. Die Wahl dieses Lieferanten wurde durch seine Bereitschaft bestimmt, den Adressensuchmechanismus für die Verwendung des Rostelecom-Adressverzeichnisses als Standard abzuschließen und den Mechanismus der regelmäßigen Synchronisation des Rostelecom-Adressverzeichnisses mit FIAS zu implementieren. Diese Verfeinerung ermöglichte es uns, Benutzern eine bequeme und qualitativ hochwertige Suche nach Adressen nach Leitung zu ermöglichen, und der Aufbau einer auf OpenSource-Produkten basierenden MDM-Lösung bot Flexibilität bei den Ansätzen zur Integration in die Rostelecom-IT-Landschaft. Im Umkreis der IT-Landschaft von Rostelecom gibt es Legacy-Systeme, die im Geschäftsprozess verwendet werden, aber aufgrund ihrer Designeinschränkungen nicht wesentlich geändert werden können. Der Übergang von einer industriellen Lösung zu einer Eigenentwicklung ermöglichte eine maximale Anpassung der MDM-Plattform an die Merkmale der IT-Umgebung, wobei das grundlegende Architekturkonzept unverändert blieb.

Warum ist es so schwer?

Angesichts der Besonderheiten beim Aufbau der IT-Landschaft von Rostelecom sollte die erste Implementierung des Systems direkt im industriellen Kreislauf der IT-Landschaft der Makroregion erfolgen. Im industriellen Bereich wurden neue Integrationen mit Schlüsselsystemen der IT-Landschaft in den Pilotbetrieb eingeführt, die sich auf die technische Umsetzung aller Geschäftsprozesse der Rostelecom PJSC auswirkten: Verkauf und Anbindung, Inbetriebnahme neuer Kommunikationseinrichtungen, Modernisierung der Heimverteilungsnetze, Installation, Support in den Zeilen 2 und 3 Bauplanung, Berichterstattung. Das Risiko eines Umsetzungsfehlers bestand in der vollständigen Blockierung der Arbeit von Informationsflüssen zwischen den Informationssystemen der Makroregion, dem Herunterfahren aller Geschäftsprozesse, dem Rückgang von Umsatz- und Reputationsrisiken.

Daher wurde vor der ersten Implementierung jeder Schritt gewissenhaft überprüft, jede Adresse und das System in Betrieb genommen, und es war ein 24-Stunden-Dienst für zwei Wochen nach dem Start erforderlich.

Zum Zeitpunkt des ersten Starts schienen alle Schwierigkeiten überwunden zu sein, und dann würde es einfach eine Replikation geben. Unter Berücksichtigung der Tatsache, dass in der jüngsten Vergangenheit jede Makroregion ein separates Unternehmen mit einer eigenen spezifischen IT-Landschaft ist, wurde aus jeder „Auflage“ eine vollständige neue Implementierung.

Verwendete Technologien und Werkzeuge

Der modulare Aufbau des Systems ist in der Abbildung dargestellt.


Anklickbar

Über den technischen Ablauf

Die Projektentwickler schreiben nicht nur Code, sondern sind vollwertige kreative Einheiten: Sie treffen technische Entscheidungen, bieten Ideen für das Interface-Design und die Benutzerfreundlichkeit des Produkts. Jedes neue Feature wird mit den Entwicklern besprochen, deren Meinung und Erfahrung werden berücksichtigt. Jede Aufgabe lässt einem Entwickler Raum für Kreativität, so dass kleine Annehmlichkeiten einfach zu realisieren sind und nicht in wenigen Fällen einer Bestätigung bedürfen.

Über das Backend

Das aktuelle Projekt basiert auf der Java EE-Technologie und dem WildFly-Webserver. Das Projekt ist monolithisch, obwohl es gerade die Planung seiner „Trennung“ in separate Mikrodienste durchläuft, da die Belastung des Projekts allmählich zu einem Höchstwert wird und eine normale Skalierung erforderlich ist.

Über das Frontend

Das Projekt hat sich schon lange entwickelt und nutzt GWT auf der Front-End-Seite. Und obwohl diese Technologie bis 2019 umfangreich und veraltet ist, können Sie eine Reihe von Vorgängen ausführen, die Sie mit JavaScript-Frameworks nicht durchführen können: Schreiben Sie in Java und auf dem Client und auf dem Server, und arbeiten Sie dort und auf den gleichen Datenbankentitäten dort, klonen sie nur durch JpaCloner.

Kein DTO und andere Parameter werden von leer nach leer verschoben.Auf diese Weise können Sie mit einem relativ kleinen Team von Programmierern ein vollwertiges Produkt erstellen. Obwohl diese Technologie nicht weniger problematisch ist: Fehler im Internet Explorer (und es gibt auch Unternehmensstandards), enorme Kompilierungszeiten, Schwierigkeiten bei der Integration in moderne JavaScript-Bibliotheken. Daher ist in der neuen Version des Produkts geplant, diese Technologie zugunsten von etwas Modernerem aufzugeben.

Informationen zu Integrationsszenarien

Das System implementiert mehr als 20 verschiedene Integrationsszenarien mit den Verbraucherinformationssystemen von ORPON-Verzeichnissen.

Mithilfe von Integrationsskripten können Sie sowohl eine einzelne Adresse als auch eine Massenliste von Adressen oder Adresselementen übertragen. Das ORPON-System kann die Übertragung einer Adresse und einer Liste von Adressen unabhängig voneinander initiieren, beispielsweise wenn ein Experte eine neue Adresse in das System eingibt oder wenn FIAS-Änderungen heruntergeladen werden, oder es kann diese Aktionen als Antwort auf eine Anforderung von einem benachbarten System ausführen. Die Übertragung von Verzeichnissen, Eigenschaften von Immobilien - natürlich.

Das wahrscheinlich ungewöhnlichste Szenario kann als das Szenario der Steuerung der Reihenfolge der Adressübertragungen angesehen werden. In komplexen Geschäftsprozessen ist es sehr wichtig zu steuern, welche Verbindungen online hergestellt werden - zu welchem ​​der Systeme die Adresse zuerst gehen muss, um eine Unterbrechung solcher Prozesse zu vermeiden. Und wir mussten dieses Problem auch mit Standardskripten lösen.

Über die Infrastruktur

ORPON ist kein hoch geladenes Echtzeitsystem - jedes Verbrauchersystem von Adressverzeichnissen verfügt über eine eigene Kopie des Referenzsystems, und das System verwendet ORPON nicht zur Suche nach der Adresse, sondern wechselt in eine eigene Datenbank. In ORPON kontaktiert das Verbrauchersystem, wenn die angeforderte Adresse nicht im lokalen Speicher gefunden wird. Diese architektonische Lösung ermöglichte es, die Belastung der Anwendung erheblich zu reduzieren und die angegebenen technischen Eigenschaften der Reaktion und Stabilität mithilfe von Clustern aus zwei Servern bereitzustellen. Das Infrastrukturdiagramm der Systemkomponenten ist in der folgenden Abbildung dargestellt. Klickbar Die Software-Anwendungen der einzelnen Cluster setzen sich wie folgt zusammen:

• PostgreSQL DBMS Cluster
• RedHat Enterprise Linux 7.7 (64-Bit)
• PostgreSQL Server 11.4 (64-Bit)
• ClusterLabs-Schrittmacher | Corosync
• Anwendungsserver-Cluster
• RedHat Enterprise Linux 7.7 (64-Bit)
• WildFly-Anwendungsserver 17 (64-Bit)
• Citrix Balancer-Software
• DURCH ODER PON
• Tooltips für Cluster-Plattformen und Softwarefaktor
• WildFly-Anwendungsserver 17 (64-Bit)
• Citrix Balancer-Software
• Softwareprodukt FACTOR
• Tipps zum Softwareprodukt

Was hat es uns gegeben?

Es ist oft schwierig, die Auswirkungen der Implementierung von Informationssystemen zu messen, viele Änderungen treten sofort ein und es gibt keine eindeutige Antwort - ob es einen Effekt gab und ob es einen gab, was die positiven oder negativen Konsequenzen verursachte. Insbesondere, wenn Sie ein Infrastrukturprojekt erstellen, das sich im Herzen Ihrer IT-Landschaft befindet.

Wir hatten Glück und konnten in einer der Makroregionen ein sauberes Experiment durchführen. Im Laufe der Zeit gab es nur eine Änderung in den Organisations- und IT-Prozessen, und dies war die Einführung des Unified Address Directory - ORPON. Das Ausmaß des Effekts war enorm - die Anzahl der positiven Reaktionen auf die Prüfung der technischen Machbarkeit der Verbindung stieg nach Einführung des Systems um 22%. Vor der Implementierung in der Makroregion gab es keine eindeutige Verbindung zwischen der Adresse im System, von der die Anforderung des technischen Supports stammt, und dem technischen Abrechnungssystem, in dem die Möglichkeit geprüft wird - welche Adresse ausgewählt wird, war eine Lotterie. Darüber hinaus gab es in SLTU viele Duplikate, und die Geräte im Haus konnten nach dem Zufallsprinzip auf mehrere Adressen verteilt werden, von denen eine nach dem Zufallsprinzip ausgewählt wurde, um die technische Durchführbarkeit zu überprüfen.Die Implementierung des Systems ermöglichte es, diese Unsicherheit auf 0 zu reduzieren und infolgedessen den Verlust von Kunden bei der Eingabe der Anwendung auf der RT.RU-Website aufgrund von Fehlern bei der Bestimmung der technischen Machbarkeit der Erbringung der Dienstleistung an der Adresse zu vermeiden.

Als wir diese Ergebnisse erhielten, trauten wir unseren Augen nicht! Diese Zahlen haben unsere kühnsten Erwartungen übertroffen.

Dieser Artikel wurde vom Rostelecom-Datenverwaltungsteam erstellt