Выбор метода обнаружения сбоев на сети для расширения OSS-комплекса крупного оператора связи функциональностью Fault Management

В большой сети оборудования оператора связи одна ошибка может повлечь ряд сбоев и отказов устройств. Для быстрого выявления проблем на сетях существуют аппаратно-ориентированные системы мониторинга и корреляции событий. Такие системы известны под общим названием Fault Management Systems (FM). Система FM или система управления отказами имеет набор функций, которые, в минимальной реализации – обнаруживают, а в расширенной – изолируют и исправляют неисправности в телекоммуникационной сети, осуществляют хранение отчетной информации в базе знаний событий. Работа таких систем сопровождается проведением последовательных диагностических тестов, исправлением ошибок, фиксированием условий и сохранением информации о причинах возникновения ошибок, а также локализацией и отслеживанием неисправностей.

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

В предыдущей статье [1] мы обсуждали построение стека систем (продуктов), направленного на создание решения для полной автоматизации бизнес-процессов [2] обработки заявок на подключение услуг (процессы группы Fulfillment карты бизнес-процессов оператора связи еТОМ), обработки и устранения инцидентов/проблем (процессы группы Fulfillment карты еТОМ). Модель (рисунок 1) была построена, в соответствии со стандартами концепции Frameworx (бывшая NGOSS), разработанной некоммерческой организацией TM Forum, что обеспечило возможность беспроблемной интеграции отдельных систем в комплексное OSS-решение [3].

Приведем перечень систем развиваемого комплекса с кратким описанием. Оператор использовал две приобретенные ранее системы: система управления заказами (Order Management System), далее СУЗ, и система управления взаимоотношениями с клиентами (Customer Relationship Management), далее УВК. В системе управления заказами СУЗ производится учет поступающих заявлений на подключение услуг клиенту и организация нарядов на инсталляцию оборудования. Функциональность системы УВК позволяет накапливать информацию о новых и старых клиентах, вести учет контактных данных, записей о предоставляемых услугах и формировать отчеты.

Ядром комплекса является система технического учета ТУ (Inventory). Система ТУ предназначена для автоматизации процессов учета, обработки и анализа информации по линейно-техническим объектам, сооружениям сети и услугам с помощью современных информационных технологий.

Система автоматизации БП технической поддержки ТП (Problem Handling на карте e TOM) – это система, предназначенная для автоматизации БП приема обращений, обработки инцидентов и проблем, возникающих у клиентов и на сети оператора. Система ТП представляет полную совместимость по концепции Frameworx, объединяя функциональ- ность трех уровней технической поддержки (от приёма заявки до выезда), что обеспечивает управление всем жизненным циклом инцидента/наряда.

СУРС, система управления рабочей силой (Workforce Management [4] на карте e TOM) предназначена для обеспечения оптимального использования выездных работников оператора связи под задачи подключения/настройки или устранения неисправностей на адресе у клиента.

Решением по автоматизации процесса настройки, поиска нового сетевого оборудования и активации услуг выступает система взаимодействия с оборудованием СВО (Resource Interaction), призванная решить весь комплекс задач по взаимодействию с оборудованием на сети оператора. Система образует связующее звено между сетевыми ресурсами, платформами предоставления услуг и IT-инфраструктурой оператора.

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

В первом случае, при поступлении обращения клиента по проблеме в УВК оператора, инженер технической поддержки в клиенте системы ТП увидит информацию по предоставляемой услуге в полном объеме, и при необходимости, создаст наряд на выполнение ремонтных работ, который в свою очередь попадет в систему СУРС.

Во втором случае, при фиксировании заявления на подключение клиента в системе СУЗ, реализуется процесс бронирования и подбор линейных данных подключаемой услуги в ТУ; система взаимодействия с оборудованием (СВО) активирует порты сетевого оборудования на этой линии до абонентского уровня доступа; по полученным данным происходит формирование задания и назначение инсталлятора в СУРС.

Рис. 1. Расширение области автоматизации БП.

Основные цели, которые преследует оператор, устанавливая себе систему FM – это повышение качества предоставляемых услуг и лояльности клиентов, соблюдение условий договора об уровне обслуживания (service level agreement, SLA) устранение проблем в кратчайшие сроки.

Есть два варианта направлений возникновения проблем:

• 1.    Обращение клиентов. В этом случае система должна сопоставлять информацию по обращениям, проверять принадлежат ли услуги этих клиентов портам одного оборудования. Должна выдавать оперативно максимум информации по оборудованию

• 2.    Отказ сетевого элемента. Сетевое устройство (например, коммутатор, маршрутизатор или сервер) выходит из строя. Система должна анализировать не только причину поломки, но и затронутые узлы сети и услуги. Клиент должен быть оповещен о недоступности услуги, и, желательно, оперативно.

Система Fault Management [5] построена на методе корреляции событий, которому принадлежат три основных аспекта:

• 1.    Функциональный. Метод корреляции фокусируется на функциях и возможностях каждого сетевого элемента.

• 2.    Топологический. Процесс корреляции учитывает схему подключения сетевого оборудования.

• 3.    Временной . Корреляция событий происходит с учетом времени поступления событий в систему.

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

Метод правил (Rule Based) - самый примитивный принцип построения системы FM. Он включает в себя два функциональных блока: сервер и базу данных. Оборудование в сети настроено отправлять сообщения со своими статусами состояний в случае их изменения. Сообщения с метками предупреждений или ошибок проходят процедуру анализа, сравнения с информацией, хранящейся в БД, так называемой, базой знаний. В базе знаний содержатся наборы правил, которые используются для логического вывода события. Если сообщение об ошибке от оборудования подошло под условие какого-либо правила, то, согласно ему, из БД будет «подтянута» информация с рекомендациями и историей по работе с оборудованием для дальнейшей передачи администратору сети. Такая реализация системы FM выполняет роль «грубого» фильтра, пропускающего любые предупреждения или аварийные сообщения, дополняя полезной информацией или отсеивая повторные. Преимущество данного подхода заключа- ется в относительной простоте настройки правил, которые интуитивно понятны для человека. Из недостатков: в системе должно содержаться очень большое количество правил, что затрудняет работу. Такой метод целесообразно использовать на сети хорошо известного оборудования с известными ошибками.

В Методе зависимостей (Codebook) система оперирует наборами событий, которые могут вести к аварии. Метод схож с Rule-based, но представляет собой следующий шаг совершенствования системы. Система, построенная на таком принципе выполняет опрос оборудования с целью сбора статистики для поиска зависимостей, приводящих к проблемам. Если зависимости найдены, то система, отсеивая повторяющиеся данные, информирует оператора о проблеме. Преимущество данного подхода в том, что сеть оборудования находится под постоянным мониторингом и многие проблемы выявляются до возникновения аварий. Однако, такая система «консервативна» и сложна для внесения изменений в настройки.

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

Прецедентный метод (Case-based) – более сложный метод организации системы устранения проблем на сети, но имеющий явное преимущество за счет своей гибкости. Метод организации системы предполагает, что в базе будет храниться только информация о конфигурации оборудования и история успешных действий оператора, которые привели к устранению проблемы в подобных ситуациях ранее. Если совпадение проблемы с устраненной ранее будет обнаружено, то система самостоятельно повторит эти действия для устранения возникшей вновь.

С учетом требований оператора и уже имеющегося функционирующего OSS-комплекса, оптимальным выбором будет Rule-based метод. Этот метод сравнительно прост. Построенная на его основе система не будет нагружать сеть, выполняя лишь пассивный прием аварийных сообщений и, благодаря своей минимальной функциональности, легко интегрируема в СВО (рис. 1).

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

Рассмотрим на примере алгоритм работы стека систем. Пусть сетевое оборудование сигнализировало о неисправности. Тогда:

• 1.    Информационное сообщение должно быть проанализировано в системе FM по установленным правилам о типах неисправностей и создано уведомление оператору сети.

• 2.    Через систему СВО должен быть получен доступ к системе ТУ, с помощью которой проблема анализируется на предмет массовости затронутых услуг.

• 3.    Полученная информация передана в систему ТП, в которой происходит автоматическое создание группового повреждения (или единичного). Уведомление о повреждении должны получить координаторы технической поддержки и после оценки подтвердить наряд на выездные ремонтные работы.

• 4.    На все обращения клиентов, пользующихся услугами затронутыми групповым повреждением, операторы должны оперативно давать консультации в УВК, на основе информации из системы ТП

• 5.    В случае, если проблема (программно или физически, с помощью ремонтных работ) устранена, то доступность услуг должна быть протестирована в системе СВО. Затем, групповое повреждение должно быть закрыто в ТП, а информация о проведенных восстановительных работах зафиксирована в виде отчёта.

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

Дооснащение системы СВО OSS-комплекса оператора функциональностью Fault Management повысит качество предоставляемых услуг и, как следствие, повысит лояльность клиентов оператора.