Cоглашение об уровне обслуживания

СДО СПбГУТ Системы управления инфокоммуникациями В начало ► Курсы ► 5 курс ► Системы управления инфокоммуникациями ► Cоглашение об уровне обслуживания ► Лекция 2 Лекция 2 Cоглашение об уровне обслуживания Определение SLA: формальное соглашение между двумя или более объектами права, которое достигнуто после работ по согласованию с целью определения характеристик услуги, ответственности и приоритета каждой из сторон. SLA может содержать положения о характеристиках, биллинге, предоставления услуги, а также правовые и экономические положения. Часть SLA, содержащую ссылку на QoS, называют "соглашениями о QoS". В оригинале – QoS Agreement. Эта часть SLA включает формальную, согласованную с объектами права, программу мониторинга, измерений и определения характеристик и параметров QoS. Основные положения SLA 1. Наличие письменного договора – документа между поставщиком услуг и пользователем. 2. Согласование качества услуг между пользователем и поставщиком услуг. 3. Приоритет пользователя в определении требований к качеству услуг. 4. Использование принципа единой ответственности из конца в конец. 5. Рассмотрение качества услуги службы, а не только сети. 6. Выражение характеристик качества услуги и их параметров (норм) понятным для пользователя способом. 7. Особое внимание к вопросам надежности. 8. Наличие среди характеристик качества услуг безопасности. 9. Наличие категорий качества, увязанных с тарифам на услуги. 10. Контроль поставщика услуг и пользователя за выполнением SLA в процессе предоставления услуги. 11. Наличие в SLA системы управления качеством услуг. 12. Применение к поставщику услуг штрафных санкций за невыполнение SLA. 13. Наличие примерного алгоритма выбора среди характеристик качества услуг и их параметров. 14. Наличие рекомендаций по организации запросов пользователей в отношении качества услуг. Последовательность реализации SLA Алгоритм выбора параметров Описание концепции SID Информационный каркас Для того, чтобы определить, какой информацией оперируют модели в eTOM, т.е. информационные объекты и связи между ними, используется информационная модель. Она описывает объекты, атрибуты, связи, действия над объектами. Описание информации возможно и другим способом, посредством составления списка объектов – глоссария, дополнив его при необходимости текстовым описанием. К недостаткам подобного подхода можно отнести сложности в описании отношений между объектами. При этом текстовое описание может оказаться непоследовательным и содержать перекрывающиеся по смысловому значению термины. В условиях отсутствия единого подхода к определению информации в системах OSS, усложняется процесс интеграции продуктов различных разработчиков. Появление третьего продукта в данном случае обяжет нас создавать еще один конвертор, для которого понадобится аналогичная процедура. В этой ситуации TMF принял решение о разработке общей для всех разработчиков эталонной информационной модели, именуемой «Shared Information and Data Model (SID, GB922). В модели данных SID TMF описал все объекты и информацию, участвующих в бизнес-процессах eTOM. В ходе создания SID был проведен анализ основных информационных моделей, выявлены лучшие/худшие области проработки, выбраны части существующих моделей, заимствуемые SID практически без изменений и области для самостоятельной разработки. SID представляет из себя общую информационную модель для участников рынка телекоммуникаций, независимую от платформы, языка и протокола реализации конкретной системы класса OSS/BSS. Для описания объектов и взаимосвязей между объектами, которые фигурируют в бизнес-процессах, необходим общий принцип определения и структурирования информации. Таким принципом является общая информационная модель. Данные в SID иерархически структурированы. На самом верхнем уровне находится такое понятие, как домен. Домен – это область управления. Домены соотносятся с концепцией eTOM на уровне 0. Всего было определено 8 доменов управления, 7 из которых соотносятся с областями eTOM и содержат соответствующие этим областям управления объекты, а восьмой домен содержит общие объекты, которые используются во всех остальных областях управления. Далее, на слайде N показаны домены SID и их отношение к модели TOM. Итак, имеется 8 доменов SID [1]: Маркетинг/Продажи. Данный домен содержит бизнес-сущности, которые используются в маркетинговой деятельности компании в процессе продаж. В маркетинговой деятельности применяются данные о сегментах рынка, в которых заинтересована компания, проводимых ею маркетинговых программах, стратегии и планах, информация о конкурентах и их продуктах. Бизнес-сущности этого домена служат для сбора и анализа информации о целевой аудитории для разработки маркетинговых стратегий и определения наиболее эффективного подхода для маркетинга существующих и новых предложений продуктов. В процессе продаж используется информация о каналах продаж, предложениях продуктов, мероприятиях по привлечению потенциальных клиентов и статистические данные по продажам. Продукт. Данный домен содержит бизнес-сущности, с помощью которых описываются характеристики и жизненный цикл продукта, а также стратегии и планирование продуктового портфеля, предложения продуктов, качество продуктов, статистика их использования, а также экземпляры продуктов, непосредственно предлагаемые клиентам. Клиент. Данный домен содержит бизнес-сущности для описания физических лиц и организаций, приобретающих продукты компании, и взаимодействия с ними. Домен содержит сущности, связанные с биллингом – выставлением счетов, сбором платежей и задолженностей, обработкой запросов клиентов по счетам, а также, при необходимости, последующей корректировкой балансов лицевых счетов. Услуга. Данный домен содержит бизнес-сущности, описывающие все аспекты услуг (в понимании eTOM) и их эксплуатации. Сущности этого домена используются бизнес-процессами карты eTOM, связанными с услугами, их разработкой и управлением, включая управление соглашениями о качестве обслуживания, активацию и конфигурацию услуг, управление решением проблем на уровне услуг, управление качеством и учет потребления. Домен также включает сущности для планирования развития услуг, улучшения их инфраструктуры и вывода услуг из эксплуатации. Ресурс. Данный домен содержит бизнес-сущности для описания сетевой и информационно-вычислительной инфраструктуры компании, а также различных аспектов ее развития и эксплуатации. Сущности домена используются бизнес-процессами карты eTOM, связанными с управлением ресурсами, и выполняют три важные задачи: во-первых, позволяют установить связь между продуктами компании, услугами и элементами инфраструктуры, обеспечивающими их представление. Во вторых гарантируют наличие и готовность всех необходимых ресурсов, обеспечивая эффективное исполнение функций по планированию, конфигурированию и мониторингу производительности ресурсов, выявлению и устранению сбоев, а также сбору данных об использовании ресурсов для их последующей обработки системами биллинга. Третьей задачей является обеспечение планирования развития ресурсов и совершенствования инфраструктуры, а также поддержка процессов планирования новых и совершенствования существующих услуг и вывода услуг из эксплуатации. Поставщик/партнер. Данный домен содержит бизнес-сущности для описания поставщиков и партнеров компании, а также взаимодействия с ними. Сущности домена используются процессами, связанными со стратегией и планированием системы поставок, взаимодействием с поставщиками/партнерами, управлением отношениями с ними, сбором и анализом данных о поставщиках/партнерах. Домен включает сущности для управления расчетами, биллингом и решением проблем в отношениях с поставщиками/партнерами. Управление предприятием. Данный домен соответствует одноименному блоку процессов карты eTOM и в настоящее время содержит ограниченный набор бизнес-сущностей для управления персоналом, обеспечения безопасности и гарантирования доходов предприятия. Общие бизнес-сущности. Данный домен объединяет бизнес-сущности, которые используются в двух или более основных доменах. Домен включает в себя несколько важных абстрактных суперклассов. Например, специфическое расширение (подкласс) сущности «Проблема» имеется во многих доменах в зависимости от объекта, с которым связана проблема: клиент, услуга, ресурс или поставщик/партнер. Потомками абстрактной сущности «Бизнес-взаимодействие» являются, в частности, сущность «Заказ клиента» домена «Клиент» и сущность «Соглашения об уровне обслуживания с поставщиком/партнером» домена «Поставщик/партнер». Для определения какие Агрегированные Бизнес-Категории (ABC) должны быть в пределах каждого из доменов, была разработана отдельная методика категоризации ABC. Все категории ABC (независимо от домена) разбиты на две группы, каждая из которых, в свою очередь разбита на отдельные категории: управляемые сущности (Managed Entity ABE) включает в себя следующие категории: Стратегия и план (strategy and plan); Управляемая сущность (managed entity); Спецификация управляемой сущности (managed entity specification). управляющая сущность (Management Entity ABE) включает в себя следующие категории: Взаимодействие (interaction) – взаимодействие с управляемой сущностью; Конфигурация (configuration) – внутренняя структура управляемой сущности; Производительность (performance) – измерение качества управляемой сущности; Тестирование (test) – подразумевает опрос управляемой сущности с целью определения ее состояния; Неисправность, неполадки (trouble) – проблема, ассоциированная с управляемой сущностью. Сюда входят аварийная сигнализация (alarms), простои (outages) и аварии (faults); Финансы (financial) – стоимость управляемой сущности; Срок использования (usage) – период времени, в течении которого используется управляемая сущность. Согласно данному принципу категоризации, были определены следующие ABC. Для доменов маркетинг/продажи, предприятие и общие бизнессущности категории еще не определены. Категории распределенные для остальных доменов приведены в нижеследующей таблице 2. Пропуски в таблице подразумевают одно из двух: либо домен не имеет точного соответствия категориям модели, либо ABC для данной категории еще не определены. Рассмотрим конкретную ABC из домена «Ресурс», с одноименным названием («Resource»), а если быть точнее, то одну из его составляющих – Физический Ресурс. В первую очередь определим ключевые сущности необходимые для четкого представления любого физического ресурса, вне зависимости от технологий, на которых от базируется, или от компании производителя: 1. Оборудование – например, маршрутизаторы или коммутаторы (на данный момент, модель физического ресурса в рамках модели SID нацелена в основном на оборудование, построенное по блочному принципу, когда любое сложное оборудование можно представить состоящим из определенного набора функциональных блоков). 2. Компоненты оборудования – например, плата (системная, сетевая и т.д.) или физический порт. 3. Контейнеры оборудования. Подразумевается, что существует оборудование, назначением которого является содержать в себе другое оборудование. Примерами такого оборудования могут быть блок или стойка. 4. Расположение оборудования. Например, маршрутизатор № 32423423 находится в стойке AS899, в серверной № 2 по адресу Московский пр., д.6. 5. Расположение различных физических элементов внутри оборудования – например, необходима возможность различать физические порты на разных сетевых картах в пределах одного маршрутизатора. 6. Вспомогательное оборудование – оборудование, необходимое для корректной работы основного оборудования, но не участвующее в реализации первичных функций основного оборудования. Например, для корректной работы и функционирования, маршрутизатору необходим источник питания, но непосредственно в реализации основной функции маршрутизатора (прием и перенаправление пакетов) источник питания не участвует. Следует отметить, что в представленной на нижеследующем рисунке упрощенной версии модели физического ресурса, данные объекты не показаны. Модель физического ресурса В модели физического ресурса введены две сущности – «Equipment» (оборудование) и «EquipmentComponent» (компонент оборудования). Между ними существует зависимость в виде агрегации «ComponentInEquipment». На концах агрегации могут быть использованы следующие значения: От 0 до n со стороны сущности EquipmentComponent: <> означает, что в состав оборудования может входить неопределенное количество компонентов; <<0>> означает, что оборудование может быть цельным и вообще не состоять из компонентов; От 0 до 1 со стороны агрегирующей сущности Equipment: <<1>> означает, что компоненты могут входить в состав одного и только одного оборудования. <<0>> означает, что компоненты могут существовать отдельно от оборудования (например, резервные сетевые платы, еще не задействованные и находящиеся на складе). Как было сказано выше, помимо оборудования и его составляющих, также существует понятие «контейнер», т.е. оборудование, которое содержит в себе другое оборудование (например, стойка, блок, статив и т.д.). На приведенном выше рисунке, возможность нахождения оборудования в конкретном маршрутизаторе отображается с помощью агрегации «EquipmentInHolder:» От 0 до n со стороны сущности «Equipment»: <> означает, что в одном контейнере может находиться неопределенное количество оборудования; <<0>> означает, что контейнер не содержит никакого оборудования (в стойке может находиться либо n маршрутизаторов, либо ни одного, т.е. стойка пуста); От «0» до «1» со стороны сущности «EquipmentHolder»: «0» означает, что оборудование может существовать вне контейнера; «1» означает, что оборудование содержится в данном контейнере. Категоризация доменов SID Категория бизнессущности Домен SID Заказчик Категория ABE Управляемые сущности Стратегия и план ______ Спецификация Взаимодействие Управляемая управляемой с управляемой Конфигурация Производительность ТестированиеНеисправности Финансы сущность сущности сущностью Заказчик Продукт Стратегический план, Продукт портфолио продукта Услуга Стратегия и план услуги Ресурс Стратегия и план ресурса План Поставщик/ поставщика/ партнер партнера Управляющие сущности Взаимодействие с заказчиком, Запрос (заказ) Статистика Заказчик SLA запрос счета заказчика заказчика заказчика _____ Проблема заказчика Сбор счетов заказчика, примененны тариф для выписки счета заказчику Цена продукта (предложени продукта на уровне 2) Спецификации продукта ____ Предложение Производительность продукта продукта Услуга, Спецификации применение услуги услуги ____ Конфигурация Производительность Тестирование Проблемы услуги услуги услуги услуги ___ Конфигурация ресурса, Производительность Проблема Тест ресурса топология ресурса ресурса ресурса _____ Ресурс Спецификация Коммуникация ресурса ресурса Поставщик/ партнер, SLA продукт поставщика/ поставщика партнера партнера Взаимодействие поставщика/ Заказ партнера, поставщика/ запрос счета партнера поставщика/ партнера Производительность поставщика/ партнера, статистика поставщика/ партнера ___ ____ ___ Проблема поставщика/ партнера Оплата поставщика/ партнера Современные сети связи и OSS/BSS системы На рисунке «Гипотетическая конфигурация современной сети мобильного NGN» представлена комплексная многоуровневая система, включающая в себя плоскости управления установлением соединений с коммутацией пакетов (протоколы H.248/EDGE), с коммутацией каналов (ОКС 7, MAP/ISUP), плоскость передачи пакетизированной речи в РМВ (протоколы прикладного уровня RTP/RTCP), O&M плоскость (протокол SNMP), плоскость транспортной IP сети для передачи трафика ОКС 7 – SIGTRAN. При этом, в процессе обслуживания вызова (ПОВ) имеет место взаимодействие протоколов передачи сигнальной информации различных стеков, например, ОКС 7, ISUP и H.248/EDGE. Поэтому направленность систем OSS на сквозную автоматизацию O&M процессов и операций определила основные сложности в решении подобных задач. Общим подходом к их решению является унификация доступа к компонентам ПО и создании универсального набора программных интерфейсов управления сетевыми элементами (NE – Network Elements). Такие задачи широко обсуждаются TMF, разработавшим архитектуру NGOSS, где апробируются подходы к построению компонентов системы эксплуатационного управления. Плоскости приведенной выше сети многоуровневой архитектуры также представлены на нижеследующем рисунке. Гипотетическая конфигурация современной сети мобильного NGN Плоскости многоуровневой архитектуры сети мобильного NGN Место OSS/BSS системы в сети оператора телекоммуникаций На приведенном ниже рисунке представлено место OSS/BSS системы в сети оператора телекоммуникаций. В общем виде представлена сеть оконечных пользователей, OSS/BSS система, непосредственно БД OSS/BSS системы, эксплуатационная платформа и ее взаимодействие с мультивендорной сетью оператора электросвязи. Место OSS/BSS системы в сети оператора телекоммуникаций Общий алгоритм взаимодействия OSS/BSS системы с сетью оператора телекоммуникаций Общий алгоритм взаимодействия OSS/BSS системы с сетью оператора телекоммуникаций является следующим [3],[4]: 1 – Со стороны оконечного пользователя выдается HTTP/SOAP запрос исследования сети, активации/деактивации услуг и диагностики системы, которая инициирует соответствующий процесс, вызывая эксплуатационную сетевую платформу. 2, 3 – Сетевая эксплуатационная платформа, в свою очередь, вызывает соответствующий обработчик процесса, имея в качестве исходных данных диапазон сетевых адресов, «SNMP community» и т.п. 4 – Эксплуатационная платформа получает отклик от обнаруженных сетевых устройств, включающие в себя значения типа объекта («SysObjectId») и запрашивает систему технического учета БД соответствующую спецификацию, например, «Маршрутизатор Cisco», «Коммутатор D-Link», «DSLAM» и т.д. 5, 6 – Для того, чтобы эксплуатационная платформа могла извлекать дополнительную информацию о конкретных моделях оборудования и ПО, администратор системы технического учета должен занести в БД спецификации соответствующих типов оборудования, содержащую общую для данной группы устройств информацию, например, количество и тип портов, типы слотов для карт расширения, дополнительные идентификаторы (OID) атрибутоа устройств/ПО данного типа. 7 – Полученные в результате исследования сети данные передаются в SNMP отклике к оконечному пользовательскому оборудованию. Данные могут описываться в виде XML и в зависимости от настроек системы и принятых решений, могут быть полностью или частично записаны пользователем в БД системы поддержки процессов эксплуатации, переданы в другие IT приложения и системы оператора. Автоматизация процессов эксплуатации сетей и оборудования телекоммуникаций Сетевая схема, представленная на рисунке «Инструментарий решения задачи автоматизации процессов решения задач эксплуатации сетей и оборудования» демонстрирует приложения, предназначенные для автоматизации решения задач эксплуатации сетей и оборудования. Здесь показано взаимодействие оконечных пользователей с такими OSS системами, как абонентский отдел и вторая линия комплексной технической поддержки операторов сетей электросвязи. При этом, обращение может реализовываться, как сто стороны ТФОП (римская цифра I – телефонное обращение), так и со стороны Общественного Интернета через личный кабинет пользователя, что показано на нижеследующем рисунке римской цифрой II. В рассматриваемой гипотетической конфигурации сети система КТП включает в себя следующие компоненты: Абонентский отдел, который наряду с традиционными функциями абонентского учета, а именно, ведение абонентской картотеки, активация/ деактивация абонентских услуг, ведение картографических и схемотехнических документов сети абонентского доступа, отвечает за прием и обработку обращений абонентов и генерацию инцидентов. При этом реализуется взаимодействие с сервером КТП, что представлено на рисунке «Инструментарий решения задачи автоматизации процессов решения задач эксплуатации сетей и оборудования» сообщениями 1 и 2 «Запрос информации о клиенте/отклик», 3 – передача инцидента на вторую линию КТП. Кроме того, OSS/BSS комплекс реализует проверку баланса абонента, состояние его счета, использование различных услуг, произведя обращение к соответствующему серверу. На этапе регистрации и передачи инцидента на 2-ю линию КТП, реализуется обращение к серверу КТП, который обращается к блоку «ProductLAB». По запросу выдается список продуктов (услуг), при реализации которых может иметь место данный инцидент. Блок «ProductLAB» отвечает за хранение списка продуктов, предлагаемых оператором электросвязи. 2-я линия КТП отвечает за задачи регистрации инцидентов. При регистрации инцидента, оператор 2-й линии КТП может воспользоваться инструментами тестирования ресурсов и услуг (для этого требуется интеграция с системой тестирования). Для диагностирования инцидента (например «Ошибка доступа в Интернет») оператор может воспользоваться интегрированной с сервером КТП базой знаний. База знаний по основным услугам, сетевым архитектурам и технологиям позволяет использовать уже существующий опыт и накапливать новый при решении инцидентов и проблем. В частности, на сетевой схеме, цифра под номером 6 показывает передачу сообщение «Создание проблемы» со 2-й линии КТП к серверу КТП. Взаимодействие с базой знаний должно выполняться автоматически для решения следующих задач управления инцидентами: 1. Сопоставление услуги и инцидента (возможен список услуг, если определенный инцидент может присутствовать в нескольких услугах); 2. На этапе приема отклика на запрос информации и клиенте (сообщение 3) от сервера КТП, абонентским отделом делается отметка о состоянии услуги (например, «Доступ в Интернет») и по рассматриваемому инциденту. По завершению анализа проблемы базой знаний/аналитики, она диспетчеризуется блоком КДГ на исправление соответствующей службе оператора электросвязи. Так, например, если при анализе инцидента «Ошибка доступа в Интернет» выявлена проблема «Ошибка процедуры DNS», то проблема может быть передана блоку «ГС и ТП» или «Выездные инженеры», если сетевая служба DNS централизована и сам сервер находится в другом административном районе города и не может быть настроен удаленно. После успешного устранения неисправности, сообщение «Закрытие проблемы» (10) передается от блока КДГ служб оператора электросвязи к серверу КТП. На данном рисунке также представлено взаимодействие сервера КТП с подсистемами БД «Линейная бухгалтерия», «Бюро ремонта», «Технический учет», что реализуется через общий модуль, который настраивается совместно с учетной записью сотрудника, отвечающего за администрирование системы. Общий модуль отвечает за взаимодействие соответствующих подсистем «толстого» клиента с группами объектов ТУ, КТП, системой пользовательских справочников и типов услуг. Инструментарий решения задачи автоматизации процессов решения задач эксплуатации сетей и оборудования Приложение, автоматизирующее службу технической поддержки оператора связи, должно быть интегрировано с приложением ТУ сети, чтобы сотрудник тех. поддержки мог видеть схемы подключения того или иного абонента. В частности, это относится к случаям, когда необходимо проверить техническую возможность подключения новых услуг/пакетов услуг. Домовая распределительная сеть PON Подключение абонентов по FTTB технологии, вариант A Подключение абонентов по FTTB технологии, вариант B На приведенных выше рисунках показано подключение абонентов и абонентских услуг по технологиям PON и FTTB. При этом возможно возникновение ситуации, когда подключение новых абонентов потребует задействования дополнительного шкафного сплитера, что невозможно из-за отсутствия доступной магистрали по данному ОРШ. При использовании технологии FTTB, отсутствие тех. возможности подключения нового абонента может означать отсутствие у оптического сетевого блока (ONU) свободного порта на стороне распределительной абонентской сети. Список литературы [1] – Бизнес-процессы и информационные технологии в управлении современной инфокоммуникационной компанией. А.В. Чукарин, К.Е. Самуйлов, Н.В. Яркина. – М.: Альпина Паблишер, 2016. – 512 c. [2] – Путь NGOSS: дао телекома, Атцик А., Гольдштейн А., Сизюхин К., Connect, № 6, 2009. [3] – Система эксплуатационного управления Аргус, Техническое описание, группа компаний Экран. [4] – Платформа эксплуатационного управления Сириус, общее описание, группа компаний Экран. [5] – Источники Интернет. Последнее изменение: Среда, 31 Май 2017, 11:27 ОСНОВНОЕ МЕНЮ Новости Расписания Контакты Сайт университета Электронная библиотека ЭБС iBooks ЭБС Лань ЭБС IPRbooks Руководство пользователя Установочная лекция Положениеи об ЭО и ДОТ Порядок оказания учебно-методической помощи КАЛЕНДАРЬ ◄ Январь 2018 Пн Вт Ср Чт ► Пт Сб Вс (Понедельник) (Вторник) (Среда) (Четверг) (Пятница) (Суббота) (Воскресенье) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 ЛЕГЕНДА СОБЫТИЙ Скрыть общие события Скрыть события курса Скрыть события групп Скрыть события пользователей НАВИГАЦИЯ В начало Личный кабинет Страницы сайта Мои курсы Безопасность жизнедеятельности Нормативно-правовая база деятельности в инфокоммун... Протоколы узлов коммутации Сетевые элементы NGN Системы документальной электросвязи Экология Архитектура систем коммутации Бизнес-процессы операторов связи Компьютерные сети передачи данных Протоколы, сервисы и услуги в IP-сетях Больше... Курсы 5 курс Технологии и оборудование производства программ те... Антикризисное управление 3D телевидение в мультимедиа технологиях Автоматизированные системы и средства для обеспече... Бизнес-планирование и риск-финансирование Внедрение системы менеджмента качества на предприя... Диагностика экономического состояния предприятия Инструментальные средства информационных систем Интегральная оптика Интеграция банковских услуг в почтовой связи Интегрированные системы проектирования и управления Системы управления инфокоммуникациями Участники Компетенции Оценки Общее Введение Cоглашение об уровне обслуживания Лекция 2 Общее описание программных компонент систем управл... Система технического учета Атрибуты объектов технического учета Общие принципы формирования и администрирования до... Общие принципы администрирования системы Блок контроля освоения дисциплины Информационные ресурсы дисциплины 1 курс 2 курс 3 курс 4 курс Справка Магистратура ИНФОРМАЦИОННЫЕ РЕСУРСЫ