Product Lifecycle Management. Популярно о процессах управления жизненным циклом телекоммуникационных услуг
Все мы пользуеся услугами связи для самых разных целей: получить доуступ к любимым сайтам и блогам, пообщаться с любимыми, друзьями и коллегами, провести переговоры, посмотреть любимые телепередачи или онлайн трансляции, отправить почтовые сообщения. Эра телеккомуникаций подарила нам невообразимые возможности и огромный спектр новейших товаров и услуг. Одними из ключевых услуг являются непосредственно телекоммуникационные: доступ в интернет, голосовая связь, телевидение и могие другие. Я работаю в сфере телекоммуникаций и хотел бы рассказать как рождаются телекоммуникационные услуги, как они развиваются и обслуживаются и как умирают.
Наверное, следует начать с терминологии. Под услугой мы понимаем коммерческий продукт (product), который предоставляется конечному пользователю, имеет стоимость и условия обслуживания, подразумевает наличие договора на его предоставление. Вы можете видеть, что на рынке представлено множество телекоммуникационных услуг по самым разным ценам и на самых разных условиях, но все они обеспечиваются узким спектром телекоммуникационных сервисов (service). Сервисы могут быть базовыми и дополнительными, и все они обеспечиваются стеком информационных систем и телекоммуникационного оборудования. Чтобы лучше понять различия между продуктом и сервисом можно привести пример: доступ в интернет является сервисом, а доступ в интернет со скоростью 10Mbps по цене 600р в месяц является продуктом.
Так как сервисы являются основой бизнеса предприятий связи, обеспечение процессов управления их жизненным циклом является очень важной функцией. Построение PLM (product lifecycle management) процессов всегда начинается с разработки модели сервисов. Существует множество методологий, но самой распространенной является модель TMForum SID (Shared Information Data). Я хочу на примере этой модели рассказать как появляются сервисы. Начать следует с метамодели, которая в упрощенном виде выглядит следующим образом:
В модели представлены три класса сущностей. Сущность класса Customer Facing Service (CFS) это сервис, который непосредственно использует конечный пользователь, например пресловутый доступ в интернет. Сервис CFS является минимальной атомарной единицей для создания коммерческого продукта. Сущность класса Resource Facing Service (RFS) это сервис, который предоставляется телекоммуникационным оборудованием или информационной системой и обспечивает существование сервиса CFS, например одним из таких сервисов для обеспечения доступа в интернет является авторизационный сервис AAA сервера. Как правило, конечный пользователь ничего не знает о сервисе RFS. Сущность класса Resource это спецификаци телекоммуникационного оборудования или информационной системы, обеспечивающей сервис RFS. Важно отметить, что структура сервисов может быть иерархичной и иметь множественную вложенность.
Управление моделью сревисов и их жизненным циклом осуществляется в информационной системе с неожиданным названием сервисный каталог (service catalogue), так же её называют технологический каталог. Сервисный каталог, неспроста, занимает центральное место в стеке систем сервисного уровня информационных систем предприятия по TMForum TAM (Telecomm Application Map), так как он является именно тем стыком между технологиями и коммерцией. На базе моделей и спецификаций сервисов, заложенных в каталоге, работают такие информационные системы сервсиного стека, как Service Order Management, Service Inventory, Service Provisioning, Service Assurance и другие. Важно понимать, что когда я говорю о системах, я подразумеваю роли. Зачастую, одна промышленная информационныя система может исполнять сразу несколько ролей. Такие системы предлагают многие производители решений для телекоммуникаций, как Oracle, Amdocs, Comptel, HP и другие.
На этом закончим с теорией и перейдем к практике – попробуем построить модель сервисов. Давайте представим, что мы установили новый сетевой элемент и опубликовали его спецификацию. Для примера я выбрал SIP сервер, который может быть, как отдельностоящей системой, так и частью, например, IMS. SIP сервер предоставляет голосовую связь по IP каналам. SIP телефония имеет огромные преимущества перед аналоговой или цифровой, т.к. может полноценно использоваться в облаках. Другими словами, мы можем позволить абоненту воспользоваться сервисом из дома (имея нашу локальную сеть), мобильного телефона (по локальной сети мобильного оператора или с использованием GPRS/LTE), из любой точки мира по IP каналу (например, WiFi в Starbucks где-нибудь в Лондоне). В общем и целом сервис сугубо облачный и конвергентный.
Получив спецификацию SIP сервера мы, в первую очередь, должны выяснить какие сервисы RFS он предоставляет, чаще всего это:
Далее следует определить сервис CFS, который потом ляжет в основу множества коммерческих продуктов с различными опциями и условиями предоставления. В качестве примера, можно все пять сервисов RFS объединить в один сервис CFS с опциями:
Важно понимать, что не только сервис CFS может иметь опции, но и сервисы RFS также.
Все опции и параметры сервиса составляют его спецификацию. В спецификации также описываются зависимости, взаимоисключения, кардинальность и функции по управлению сервисом (как правило по CRUD – create, read, update, delete). В результате мы построили полноценную сервисную модель с определенными упрощениями.
Теперь стоит остановиться на функциях управления, которые на общепринятом языке называются Fulfillment Functions. Для сервиса каждая функция описывает, как минимум правила его дизайна, активации на сети, сохранения в системе инвентаризации и постановку на мониторинг. За последовательность и корректность исполнения всех функций отвечает система Service Order Management, а непосредственно сущность, которой она управляет это сервисный заказ или Service Order. Существует базовая методология описания функций управления: design, assign, activate.
В следующей статье, я попробую, также кратко, осветить процесс создания коммерческих продуктов на базе созданной сервисной модели.
Products, CFS and RFS
Products, CFS and RFS
At the time of writing a number of traditional Communication Service Providers (CSPs) are “morphing” into total digital players. This is seen as a means to address the dynamic, competitive ICT Market and to allow Value Added OTTs (VAOTTs) to be a part of the CSP’s value chain. As King Canute (Cnut) “discovered” it is somewhat a challenge to hold back the tide. The same is being seen with the competitors that are snapping at the heels of the CSPs.
To help CSPs, the adoption of a Catalog will help by providing a much needed “truth table” of what Products and Resources will be required to entertain and deliver Products to the end customer (e.g. Retail, Wholesale, etc..). A Catalog helps with Product creation and the end to end lifecycle of Products supported by the CSP.
A central and unified Catalog is an enabler facilitate the consolidation of the “home grown” IT estate (e.g. numerous Databases, manual processes, non-standard technologies, etc..) and to serve as a catalyst for further business growth by offering flexibility with Product creation and deployment.
From a high level perspective, a Catalog can be split into the following parts:-
-Product (e.g. Sales Catalog, Product Catalog, Services Catalog, etc..) that highlights what can be ordered and consumed)
-Services, (e.g. configuration and technical details) and
Resources (e.g. what needs to be setup with the Network)
The Services are basically Customer Facing Services (CFS) and Resource Facing Services (RFS). Generally, CFS is tied, or linked, to a Product and RFS is connected with the required resource.
VBR/ Wallis Dudhnath
TMF Forum and the SID (Shared Information Data) model
Below is a high level description of eTOM, SID and TAM.
-Business Process Framework (earlier known as eTOM – enhanced Telecommunication Operation Map) captures the key and typical business processes that a Communication Service Provider (CSP) will support so that they can become “digital” CSP with agile qualities.
At a high level there is “operations” and this covers: Fulfillment, Assurance and Billing (FAB). FAB processes ensure that Services can be delivered and that they can be charged / billed (usage).
-Shared Information Data (SID): A model that abstracts information in the Network. Promotes integration.
-Telecommunication Application Map (TAM): Description of the software stack for the OSS/BSS environment. Helps to list the software artifacts that are used with the AS-IS software stack.
-Integration Framework: API Gateways and Enterprise Service Bus (ESB) / Enterprise Application Integration.
Что такое CFS в морских перевозках?
Указание термина CFS в морском коносаменте означает, что стоимость услуг данных CFS терминалов не включены в морскую перевозку и должны быть оплачены дополнительно к морскому фрахту, о чем дополнительно в домашнем коносаменте в той же 13 графе может быть также указано «LCL Charges at destination are for receivers’ account».
Таким образом, если Вы заказали морскую перевозку малогабаритного груза на условиях EXW или FOB (условие оплаты фрахта Freigh Collect указывается в 17 графе домашнего коносамента), то локальные услуги в Одессе, включены в стоимость доставки сборного груза Вашего агента (рекомендуем уточнять эту информацию в момент заказа перевозки у Вашей транспортной компании).
Если же Вы получаете груз на условиях CIF Одесса, то скорее всего, Ваш отправитель доставит груз на условиях CFS Odessa, и расходы на Container Freight Station Вам нужно будет дополнительно оплачивать агенту в стране назначения, о чем Вы получите уведомление в Arrival Notice (уведомление о прибытии) агента по прибытию груза в порт назначения.
F.S. Mackenzie объединяет собственные офисы в ЕС и сеть агентов по всему миру, что позволило нам накопить огромный международный опыт.
ЦЕНЫ НА ПЕРЕВОЗКИ ИЗ США
Цены на перевозки грузов из Америки у разных транспортных компаний могут сильно отличаться, и мы поможем разобраться с этим.
ЦЕНЫ НА ПЕРЕВОЗКИ ИЗ КИТАЯ
Стоимость доставки товара из Китая зависит от множества факторов, таких, как вид транспорта, объем и вес груза и маршрут.
CFS vs O(1) scheduler
Думаю многие слышали, что помимо стандартного O(1) планировщика в linux, появился CFS(Completely Fair Scheduler; «абсолютно справедливый планировщик»), над которым работает Ingo Molnar. Собственно эту заметку я хотел бы посвятить сравнению этих двух планировщиков и краткому рассмотрению их основных алгоритмов. В конце заметки можно немного почитать по FreeBSD’шный планировщие ULE.
действительно, извлечение очередного процесса из дерева иногда требует ребалансинга, вставка процесса в деревно требует обхода по одной ломаной и возможного ребалансинга. но этот недостаток проявляет себя только при очень большом n, что с очень малой долей вероятности встретится на десктопах, но может встретится на больших work stations. отсюда можно сделать вывод: статвить этот планировщик на нагруженные сервера/work stations и прочие машинки, расчитанные на работу с большим количеством одновременно запущенных процессов/тредов, пока что не стоит.
а проявляет себя этот недостаток так:
| Ingo заявил, что имея 1000 запущенных тасков(таск — процесс или тред), в системе увеличится стоимость переключения контекста(context switching) на 20%. Это дерево из 10 уровней. В худшем случае может добавиться ещё 5 уровней, что приведёт к 30% увеличению стоимости. Это не смертельно, но и хорошим поведением это тоже не назовёшь. |
к недостаткам же O(1) scheduler’a можно отнести недостаточно хороший, ‘справедливый’ ребалансинг по ядрам. вот, что говорит сам Ingo в этом комментарие:
| Проще всего описать это на простом примере: если я на своей машие запускаю glxgears, она будет использовать ровно 50% CPU. Если я буду использовать SD планировщик(он же O(1) scheduler) и запущу на нём CPU hog вместе с glxgears, оба таска разделят CPU ресурсы. CPU hog получит 60% процессорного времени, а glxgears — 40%. Если же я буду использовать CFS, оба таска получат по 50% процессорного времени. |
CFS действительно лучше лучше распределяет процессорное время и раскидывает таски по ядрам(проверенно на личной практике).
Также к плюсам CFS можно отнести заметно меньшее время отклика, нежели у O(1). Это подтверждают тесты, сделанные Михаилом Пиатровски. посмотреть результаты можно здесь. Таким образом, CFS можно смело ставить на десктоп, где нет огромного количества одновременно запущенных процессов.
прежде всего отмечу, что CFS доступен для ядер начиная с версии 2.6.20.
взять патч по версию ядра >= 2.6.20 можно здесь.
далее за ходим в каталог с linux sources и накладываем патч:
также для разработки CFS планировщика выделен отдельный git-репозиторий. стянуть клон репозитория можно отсюда.
каждый cpu имеет 3 очереди, проиндексированные по приоритетам. 2 очереди используются для имплементации таких sheduling-classes, как прерывания, риал-тайм и разделение времени. последняя очередь используется для idle-класса.
политика переключения очередей аналогична O(1) shceduler, т.е. когда одна очередь опустеет, она тут же заменяется другой. следовательно время переключения не зависит от кл-ва процессов.
также ULE использует гибкие и эффективные политики на SMP системах, по словам Jeff’a раскидывая таски между CPU (цит.) «как минимум не менее ‘справедливо’, чем это делает ‘абсолютно справедливый планировщик’».
подробнее про ULE: ULE.pdf и здесь.
собственно, это была пробная заметка, тк она является первой в этом блоге. отсюда есть несколько вопросов к прочитавшим: интересно ли вам было бы почитать более(гораздо) подробно про реализацию CFS и стоит ли в дальнейшим переводить какие либо цитаты, вставленные в контекст заметки с английского?
спасибо за внимание.
ZSmart Управление выполнения задач
ZSmart Order Management (OM) позволяет операторам связи автоматизировать продукты и сервисы нового поколения от различных поставщиков. Модуль управляет всем сервисом управления технических заявок от принятия заявки до ее исполнения. После получения оригинального сервисного ордера из внешних систем, таких, как система управления взаимоотношения с клиентами, заявка форматируется согласно предустановленному шаблону.
Далее, аудит и затем передача в систему управления взаимоотношения с клиентами для исполнения. Система передает и выполняет весь процесс обеспечения, базирующийся на информации о заявке. После завершения сервисного обеспечения заказ архивируется.
ZSmart OM может легко интегрироваться с ZSmart Inventory Management, ZSmart Workforce Management и ZSmart Povisioning Management, позволяя создавать автоматическую конфигурацию и активацию.
Ключевые особенности
• Шаблон заявки: уточнение запрошенной информации, форматов и правил ограничения заявки;
• Принятие заявки: создание заявки с помощью шаблона;
• Контроль заявки: контроль за выполнением заявки;
• Передача заявки: передача заявки в систему управления взаимоотношений с клиентами для выполнения;
• Выполнение заявки: уведомление о выполнении, выполнение заявки и его архивация;
• Выполнение соглашение об уровне предоставления услуги: согласно лимиту соглашения, указанному в заявке, можно контролировать соблюдение времени выполнения заявки;
• Сервисный дизайн: позволяет CFS и RFS спецификациям быть примером для актуальной ресурсной информации и для приложения соответствующих бизнес-правил;
• Сервисная конфигурация: генерация информации по сервисной конфигурации, генерация экземпляра службы данных, создание рабочей заявки;
• Сервисная активация: выполнение задания, указанного в рабочем наряде.
Преимущества
• Оптимизированная и автоматизированная меж доменная активации заказа;
• Улучшенный клиентский опыт благодаря сокращению времени исполнения;
• Сокращение времени выхода на рынок для новых сервисов с помощью унифицированных бизнес процессов и механизмов;
• Сокращение выпадения заказов через управление конечным жизненным циклом заказов и передачу информации;
• Минимизированная интеграция и операционные расходы и более высокая эффективность процесса;
