Карта сети: кто останется без интернета, если оборвётся эта трасса

Спросите у любого небольшого провайдера, где проходит магистраль до дальнего района. Ответ будет: «Спросите у Сергея». Сергей знает — он её и строил. Проблема в том, что Сергей один, а трасс десятки, и когда в семь утра обрывается волокно, счёт идёт на минуты: нужно понять, что именно оборвалось, кого это задело и что говорить абонентам, которые уже звонят.

Схема сети при этом обычно существует. В виде файла у того же Сергея.

Что должно быть на карте

Карта сети полезна не сама по себе, а когда на ней лежат три слоя разом:

• Узлы. Шкафы, муфты, подстанции, опоры — с типом, адресом и оборудованием, которое в них стоит.
• Трассы. Отрезки между узлами: длина, тип прокладки (воздушка, канализация, подвес), количество волокон.
• Абоненты. Привязка домов и клиентов к узлу, через который они подключены.

Без третьего слоя карта остаётся картинкой для отдела. С ним она отвечает на главный вопрос аварии: кто именно сейчас без связи.

Как перенести то, что уже нарисовано

Никто не будет заново расставлять тысячу точек мышкой. Обычно у оператора уже есть схема — в Яндекс.Конструкторе, Google Earth или другом редакторе карт, и её можно выгрузить одним файлом.

При импорте важны две вещи. Во-первых, типы узлов почти всегда закодированы в названиях: «ТШ-14» — телекоммуникационный шкаф, «ТП-7» — подстанция. По этим префиксам тип проставляется автоматически, вручную остаётся поправить единицы. Во-вторых, координаты в таких файлах записаны в порядке «долгота, широта» — перепутанные местами, они аккуратно расставят всю сеть где-нибудь в Сомали. Это первое, что стоит проверить на трёх точках после импорта.

Практический ориентир: перенос схемы на тысячу узлов и почти девятьсот трасс — работа на день, а не на месяц. Основное время уходит не на импорт, а на сверку типов и слияние дублей.

Авария: от точки к списку абонентов

Ради этого сценария всё и делается.

flowchart LR
  A[Пропала связь<br/>у группы абонентов] --> B[Общий узел<br/>на карте]
  B --> C[Список затронутых<br/>адреса и клиенты]
  C --> D[Оповещение<br/>и наряд бригаде]
  C --> E[Поддержка знает<br/>что отвечать]

Оператор выбирает узел или трассу — и получает не абстрактную «зону», а перечень домов и клиентов, которые за ней стоят. Дальше это превращается в рассылку («авария на участке, ориентировочное время восстановления») и в наряд бригаде. Поддержка в этот момент перестаёт гадать: на входящий звонок видно, что абонент попадает в известную аварию.

Обратный сценарий не менее полезен: пришли три обращения из разных домов — карта показывает, что у них общий узел, и это не три независимые проблемы, а одна.

Опоры и чужая инфраструктура

Отдельный слой, о котором вспоминают, когда приходит счёт: опоры и каналы, принадлежащие сетевой компании. За них платят по договору, и цена вопроса — десятки и сотни тысяч рублей в год.

Здесь карта работает как документ. Когда каждая опора отмечена и связана с трассой, разговор с владельцем инфраструктуры перестаёт быть спором двух мнений: видно, сколько опор реально задействовано, какие из них уже входят в действующий договор, а какие предъявлены повторно. Без карты доказать это нечем.

Несколько юрлиц на одной карте

Если под одной платформой живут несколько операторов, карта должна показывать сотруднику только его сеть. Тонкость в том, что скрыть достаточно не только список: трасса принадлежит организации через свои узлы, и проверять доступ нужно при открытии каждого объекта, а не только при показе перечня. Иначе объект остаётся доступен по прямой ссылке — и это ровно тот класс ошибок, который обнаруживается позже всего.

С чего начать

Не нужно сразу оцифровывать всю сеть. Порядок, который работает:

1. Перенести магистраль и узлы агрегации — их немного, а зависит от них большинство.
2. Привязать дома к узлам: это даёт список затронутых абонентов, ради которого всё и затевалось.
3. Добавить распределительную сеть по районам, начиная с тех, где чаще аварии.
4. Последними — опоры и договорные слои, когда карта уже используется ежедневно.

Признак, что карта «взлетела», простой: во время аварии в неё заглядывает не только Сергей.

Как это работает в СмИТ Биллинге

Карта не отдельная программа с собственной базой, а слой поверх той же системы: узлы, трассы, оборудование, зоны покрытия и заявки лежат рядом с абонентами, поэтому вопрос «кого затронет» — это запрос, а не воспоминание монтажника.

Слои включаются по отдельности: отдельно магистраль и распределение, отдельно опоры и колодцы, отдельно точки подключения и открытые заявки. При аварии на трассе видно не «участок в районе», а конкретные дома и учётные записи за ней.

Зоны покрытия с карты работают и на продажи: форма на сайте по адресу сразу отвечает, есть ли там сеть, — и заявка либо уходит в воронку подключения, либо в список «хотим, но пока не дотянулись».

Схемы по теме все схемы →

Последовательность Путь RADIUS-пакета Архитектура Runtime-архитектура