Почему оператор перестает понимать собственную сеть

Автор: Евгений Мошняцкий, коммерческий директор НТЦ АРГУС 

Современная телеком-сеть давно перестала быть набором оборудования, кабелей и каналов связи. Это система физических, логических ресурсов и сервисов, где оборудование, порты, каналы, транспортные сегменты, маршруты, схемы резервирования и услуги постоянно влияют друг на друга. Поэтому для управления сетью важно видеть не только отдельные объекты, но и связи между ними: какой ресурс участвует в каком сервисе, какие изменения уже произошли в сети и какие участки действительно доступны для подключения или модернизации.

Для управления такой сетью используются системы технического учета ресурсов, мониторинга, планирования, управления услугами, заявками, жизненным циклом сетевых активов и работой выездных инженеров. Каждая из них отвечает за свой участок управления и содержит важную часть информации о состоянии сети. Однако наличие данных еще не означает наличие управляемости. Если сведения о ресурсах, сервисах, работах и изменениях остаются разрозненными, у оператора может быть много данных о сети, но не быть единой модели, на которую можно опираться при принятии решений.

В сетях такие разрывы начинают влиять не только на эксплуатацию, но и на экономику развития инфраструктуры и кабельного хозяйства. Первое, где этот разрыв становится заметен, - связь между сервисами и ресурсами сети.

Разрыв между сервисной и ресурсной моделью сети

Сначала такие расхождения могут выглядеть как локальные проблемы учета или актуализации данных. Однако в современных мультисервисных сетях они быстро выходят за рамки эксплуатации и начинают влиять на работу услуг, выполнение SLA и планирование нагрузки. 

Системы управления услугами продолжают считать сервис доступным, даже если его маршрут уже деградировал или переведен на резервную схему, системы мониторинга фиксируют перегрузку оборудования или каналов, но не связывают ее с конкретными сервисами и абонентами, а системы планирования используют усредненные или устаревшие данные о загрузке сети. В результате теряется сквозное понимание взаимосвязи между услугой, ресурсами и фактическим состоянием сети.

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

Если такая модель не выстроена, значительная часть эксплуатационной аналитики до сих пор строится на ручной сверке данных между инвентаризационными системами, мониторингом, заявками, локальными схемами сети и фактической информацией от специалистов, которые выполняют работы на сети. Чтобы понять реальное состояние участка сети или оценить влияние аварии, перегрузки либо модернизации на сервисы и SLA, приходится поднимать историю обращений, уточнять, какие работы уже были выполнены, сверять учетные данные с фактической коммутацией и при необходимости проводить дополнительное обследование. Это увеличивает время диагностики, усложняет подготовку к модернизации и снижает предсказуемость подключения новых сервисов. Особенно заметно эта проблема проявляется в планировании емкости сети. 

Почему начинает ошибаться планирование емкости сети

Так возникает ситуация, когда оператор не имеет достоверного представления о фактической доступности ресурсов сети. Например, часть волокон, каналов или портов может числиться свободной, хотя уже используется для действующих сервисов или резервирования. Возможна и обратная ситуация, когда ресурсы продолжают считаться занятыми только в учетной модели. В результате становится сложнее оценивать возможности для новых подключений, планировать использование существующей емкости и принимать решения о развитии сети на основе актуальных данных. Такие расхождения обычно появляются не одномоментно: они накапливаются после проектных изменений, работ на сети, аварийных переключений и модернизаций.

Когда изменения в сети перестают возвращаться в модель данных

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

Проблема появляется тогда, когда результат этих изменений не возвращается в общую модель данных. Например, во время строительства может измениться маршрут прокладки или схема подключения, при аварийном переключении - фактическая связность участка, при модернизации - состав оборудования, портов или транспортных ресурсов. Со временем учетная модель постепенно расходится с реальным состоянием сети.

Чем больше таких изменений проходит через эксплуатацию, тем сложнее поддерживать актуальность данных вручную. На этом уровне уже недостаточно организационной дисциплины или разовой актуализации: модель управления должна обеспечивать актуальность данных и их согласованность между процессами. 

Почему точечных связок между системами становится недостаточно

Разделение систем по задачам само по себе не является проблемой. В этом смысле ODA задает правильный ориентир: разные функциональные контуры могут развиваться отдельно, но работать в общей логике управления сетью. Задача заключается не в том, чтобы «сшить» любые существующие системы между собой ради самой интеграции, а в том, чтобы связать технический учет, управление ресурсами, жизненный цикл ИТ- и сетевых активов, заявки, полевые работы, сервисы и изменения на сети в единую управляемую модель.

Такой подход позволяет не только фиксировать объекты, но и управлять их состоянием, доступностью, использованием и влиянием на услуги. Именно здесь OSS-система становится не просто хранилищем данных о ресурсах, а инструментом управления сетью.

Заключение. Управляемость как ресурс

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

Поэтому сегодня ключевым фактором становится не количество используемых OSS-систем и не объем собираемых данных, а способность поддерживать достоверную и непротиворечивую модель сети. Именно она позволяет превращать информацию о ресурсах, сервисах и изменениях в управленческие решения, а не в постоянный процесс поиска, уточнения и перепроверки данных.