|
|
  |
Главная страница / Архитектура отрасли OSS, BSSНа вопрос о возможности третьей мировой войны армянское радио ответило, что войны не будет, но борьба за мир будет такой кровопролитной, что уничтожит всех. Анекдот советского периода В настоящее время на страницах технических журналов все чаще появляется аббревиатура OSS (Operating Support Systems). Однако сама проблема создания OSS и их интеграции «в кровь и плоть» оператора обсуждается крайне редко. Задача предлагаемой статьи – проанализировать ценность OSS с точки зрения современных систем эксплуатации. OSS как новый виток идеологии систем управления Несмотря на весь пафос новизны в области OSS, сами принципы, концепции и понятия, связанные с этими системами, отнюдь не новы. Системы поддержки функционирования (OSS) предприятий связи представляют собой существенное расширение давно известной концепции построения глобальных систем управления (TMN – Telecom-munications Management Network), очень популярной в 90-е годы. Прогресс в области компьютеров, развертывание компьютерных сетей, переход к высокоскоростным системам передачи и коммутации, создание значительных информационных ресурсов развитых стран – все это кардинально преобразило современный деловой мир. По мере того как часть функций управления и обслуживания деятельности предприятий перекладывалась на плечи машин, формировалась концепция глобальной системы управления предприятиями – BSS (Business Support Systems), в основу которой были положены различные методы оптимизации процессов на предприятии. Однако данная концепция не была телекоммуникационной, ибо для нее не имеет значения, о каких процессах идет речь, – важна их оптимизация. Поэтому BSS начали внедряться во многих отраслях современной экономики, оптимизируя банковскую сферу, транспортные издержки, поставки сырья и пр. Усиление централизованного контроля, неизбежное при внедрении BSS, как нельзя лучше легло на специфику современной глобализации и укрепления роли транснациональных компаний. Последние разрослись до такой степени, что для управления ими потребовались автоматизированные системы, и концепция BSS оказалась весьма кстати. В России внедрение BSS в различных отраслях промышленности и сферы услуг началось после укрупнения предприятий и усиления вертикали власти, что также обусловило дальнейшую централизацию управления и глобализацию отраслей. В ходе реализации объявленной в тот период ОАО «Связьинвест» стратегии на укрупнение предприятий связи, BSS (в первую очередь на основе Oracle) пришли и в связную отрасль. Вместе с тем связисты исторически тяготели к вопросам управления своими сетями, но управлению иному – управлению технологией, устройствами передачи и коммутации, сегментами сетей, ресурсами оператора и пр. Именно под эти задачи в далекие 80-е была сформулирована концепция TMN, которая с переменным успехом развивалась до последнего времени как чисто «связистское изобретение». В ее основу была зудование связи буквально напичкано процессорами, обеспечивающими удаленную диагностику состояния оборудования, при помощи компьютерных технологий можно решить задачу диагностики, реконфигурации, т. е. управления всеми устройствами в сети. Однако цель данной концепции заключалась в повышении эффективности работы сети, а не операторской компании как предприятия. Концепция BSS вдохнула в умы разработчиков систем управления в телекоммуникациях новую идею – объединить задачи управления бизнесом и задачи управления сетью. Так на стыке двух задач родилась концепция OSS, которая, с одной стороны, содержала все наработки TMN, с другой – обеспечивала жесткую экономическую связку BSS/OSS, с третьей – включала новые тенденции, опыт и некоторые качественные дополнения, которые всегда сопутствуют синтезу двух независимых идей. Как всякая новая технология, OSS сразу стала раздавать авансы «замечательного будущего» телекоммуникационного мира, полностью подконтрольного и управляемого небольшим количеством самых талантливых специалистов, своеобразной технократической элиты. Подобные перспективы привлекают многих. Они приятны начальнику или руководителю предприятия, который теперь по своему желанию может контролировать работу любой системы, подразделения или специалиста. OSS позволяет устранить любые «не технологичности» в работе сети и решать кадровые проблемы под девизом «У нас незаменимых нет!» Авансы OSS радуют ученых, которые при объединении вопросов управления бизнесом (где деньги) и управления сетями (где наука) закономерно ожидают, что наконец-то удастся воплотить давнюю мечту. OSS привлекает системных интеграторов, которые на новом поле в полной мере могут продемонстрировать свое искусство соединять разнородные системы в одно целое. Она манит коммерческих спекулянтов, поскольку дешевых OSS не может быть, а производителям программного обеспечения обещает существенный рост оборотов. Словом, глядя на сложившуюся ситуацию в отрасли, сложнее найти противников OSS, чем ее сторонников. В такой революционной обстановке очень вероятны поспешные решения, которые могут нанести существенный вред. Внедрение OSS, в отличие от внедрения BSS, затрагивает саму основу работы сети связи – аппаратные и программные средства. Сбой в BSS чреват финансовыми потерями, сбой в OSS – потерями сегментов сети. Таким образом, при всей привлекательности OSS, ошибка при ее внедрении может иметь самые тяжелые последствия. Поэтому сейчас самое время разобраться во всех плюсах и минусах OSS, попытаться предугадать возможные ошибки. Пока есть время, пока не начались активные действия. Эта статья – всего лишь отражение одной точки зрения со стороны практики эксплуатации сетей связи, не претендующее на истину в последней инстанции. Ее цель – начать честное обсуждение вопросов построения OSS в прессе, без «посягательств на святое». OSS – всего лишь очередная концепция и, как любая другая, – явление временное, а не предмет поклонения. Теоретическая стороообразно начать с теоретической стороны OSS. Здесь нет смысла перечислять все стандарты, рекомендации ITU-T, ETSI и пр. Достаточно сказать, что OSS как концепция довольно хорошо документирована не только в международных стандартах, но и в материалах отечественной прессы, правда, имевших явно описательный характер. Так что любой, кто заинтересуется стандартами OSS или решениями, присутствующими на рынке, легко найдет все необходимые материалы в Интернете. Интересно другое – изолированность вопросов построения OSS от всей современной проблематики эксплуатации. Скорее всего, это свидетельство новизны концепции OSS, поскольку любая новая концепция должна быть максимально агрессивной – только тогда у нее есть будущее. Возможно, по этой причине авторы публикаций, посвященных принципам построения систем OSS, старательно обходят вопрос о том, что, по здравому смыслу, OSS должна быть частью системы эксплуатации. Сейчас же все наоборот – существуют OSS и все остальные проблемы, в результате все материалы и статьи об OSS наводят на мысль об «управлении ради управления», а не ради решения задач эксплуатации в целом. Чтобы не заблуждаться по поводу места OSS в современной системе эксплуатации, достаточно вспомнить уже приводившуюся на страницах Сonnect! иерархию приоритетов в современных системах связи. Эксплуатация, к которой относятся вопросы эксплуатационных измерений, создания системы управления сетью, некоторые частные вопросы (например, синхронизации), связана с конкурентоспособностью предприятия опосредованно, через влияние на параметры качества предоставления услуг. Без учета проблематики качества система эксплуатации вырождается. Например, измерения на сети связи без контроля качества превращаются в «измерения ради измерений» и носят либо случайный, либо низкоэффективный характер. Так же и концепция управления легко приобретает черты самодостаточности. Организация технической эксплуатации сетей связи должна осуществляться в соответствии с основными принципами, изложенными в рекомендациях МСЭ-Т М.10, М.20, М.21, М.60, М.70, М.495, руководящих документах отрасли по технической эксплуатации различных видов оборудования связи, а также с требованиями к системе эксплуатационной поддержки оборудования электросвязи, определяемыми Приказом Минсвязи РФ и МАП РФ №2, 23 2001 г. Классическим разделением задачи построения автоматизированной системы эксплуатации (АСОТЭ) является разделение ее на две основные подсистемы: автоматизированного управления (АСОТУ) и автоматизированного обслуживания (АСОТО). Основными функциональными подсистемами АСОТО являются: • подсистема поддержания и восстановления работоспособности; • информационно-измерительная подсистема; • подсистема обеспечения эксплуатационными запасами. Концепция построения АСОТУ в последнее время значительно эволюционировала и в области стандартов, и в области непосредственных программно-аппаратных средств реализации, что и привело к развитию концепции OSS. построения систем связи выдвигает на первый план вопросы контроля качества услуг в сети, существует возможность модернизации концепции АСОТЭ, за счет ее дополнения еще одной подсистемой – системой контроля качества (СКК, или QoS), основанной на принципах формирования политики контроля качества оператора. В результате в современной системе эксплуатации должны присутствовать уже не две, а три подсистемы. Все указанные подсистемы и их компоненты тесно взаимосвязаны друг с другом. Например, поиск неисправностей требует использования подсистем управления Fault и измерительных приборов. Контроль качества услуг может осуществляться с помощью системы управления Fault и Service, информационно-измерительной компоненты АСОТО и на основе политики в области качества СКК. Можно найти и другие связи подсистем в рамках интегрированной системы эксплуатации. Таким образом, если отвлечься от революционной ситуации и рекламной шумихи вокруг OSS, то можно увидеть, что, несмотря на высокую функциональность, OSS – всего лишь возможный вариант реализации некоторых задач эксплуатации систем связи, и у нее должны существовать альтернативы в других подсистемах эксплуатации. OSS и мода современных телекоммуникаций Еще один аспект проблематики OSS – мода на новую технологию. В настоящее время, в связи с переходом к информационному обществу, веяниям моды подверглись даже технические стороны жизни. В частности, грянувшая «мода на OSS» рассчитана на повышение престижа тех, кто поставляет такие решения, и на более эффективную работу с теми, кто их покупает. Влияние факторов моды и престижа в современных телекоммуникациях – тема отдельного исследования. Но в контексте нашей проблемы можно констатировать тот факт, что мода на OSS, как это зачастую случается с модой вообще, существенно мешает конструктивному обсуждению и в целом выхолащивает саму идею. Так, в погоне за престижностью многие системные интеграторы под OSS понимают вовсе не комплексные системы управления. К тому же в погоне за той же модой некоторые производители стали подделывать свои решения в области локальных систем управления под терминологию OSS, создавая компромиссные варианты: внутренне это простая система управления классического построения, но внешне смотрится как OSS. Например, основным качеством OSS является независимость от типа оборудования и его производителя. И по этой причине решения типа «OSS для оборудования Cisco» или «система управления OSS компании Nortel для оборудования компании Nortel» – не более чем новые маркетинговые флаги эффективных, но классических систем управления. С другой стороны, стремясь «не отстать», многие операторы начали «внедрять OSS» в виде отдельных частных решений, называя OSS то, что иногда лишь отдаленно напоминает системы управления оборудованием. Подобные процессы могут привести как к положительным, так и к отрицательным последствиям. Положительным является то, что отечественные операторы через OSS и вопросы управления сетью нлее чем десятилетнего сна в вопросах построения эксплуатации. Отрицательное следствие – операторы запутаются и внедрят что-то иное, чем необходимую для них систему управления. Что может дать OSS системам эксплуатации? Рассмотрев все стороны явления новой технологии OSS на отечественном рынке перейдем к вопросу о ее ценности для текущего состояния связи России и целесообразности на данном этапе внедрения OSS для российских телекоммуникаций и эффективности OSS с точки зрения современного состояния и задач развития систем эксплуатации в целом. Такой подход показывает, что системы OSS могут дать многое для современного построения систем эксплуатации. Прежде всего следует определить место OSS в системе эксплуатации. Отметим, что только тесная связь контроля качества и системы эксплуатации может ускорить ее развитие и повысить ценность. Любые новые концепции построения системы эксплуатации оцениваются по параметрам качества работы сети. При проявлении негативных тенденций система эксплуатации модернизируется, и улучшается качество. Для выполнения перечисленных задач используется широкий спектр инструментов современных систем эксплуатации: • инструментарий (от плоскогубцев до тестовых телефонных трубок); • измерительные диагностические средства, в том числе встроенные средства диагностики и приборы; • системы мониторинга и локальные системы управления отдельных фирм-производителей; • многоуровневые и мультивендорные системы управления уровня OSS. Весь указанный инструментарий в той или иной степени используется на сети любого современного оператора России, за исключением OSS. Принципы построения систем эксплуатации распределяются на два уровня. Решения первых двух уровней ориентированы на распределенные системы эксплуатации, когда интеллектуальные ресурсы, пункты сбора отчетности, обработки данных и пр. распределены по сети. Решения последних уровней формируют централизованную систему эксплуатации с единым центром диагностики и управления. Основное преимущество распределенной системы по сравнению с централизованной – оперативность реагирования при возникновении в сети неисправности. Однако централизованные системы выигрывают в части статистической обработки результатов и возможностей прогнозирования поведения сети. Многоуровневое построение систем эксплуатации обеспечивает также хорошие показатели развертывания, эффективности и распространенности на сетях операторов в мире. Анализ современных тенденций однозначно свидетельствует о повсеместном переходе к централизованным системам, обладающим множеством преимуществ, в частности: • устранение рутинных и регламентных процедур; • полная информация в динамике состояния сети; • оперативные выборки данных в режиме; • наличие средств активного выявления причин нарушений работы сети; • системная борьба с пиратством на сети; • максимальная эффективность работы. Несмотря на явную необходимость эсистемам, вопрос об эффективности OSS остается открытым. Совершенно не очевидно, что именно они являются идеальным инструментом для централизации систем эксплуатации. Отечественные операторы только начали осваивать технологию специализированных систем мониторинга, поэтому к оценке OSS следует подходить очень осторожно, ориентируясь на более простые и эффективные на данном этапе системы мониторинга. Отечественные операторы еще не достигли такого уровня, когда внедрение OSS даст необходимый и востребованный системой эксплуатации функционал. Вне «выращивания» проблематики OSS в рамках существующей эксплуатации самые новые системы управления могут стать бесполезной игрушкой. Практическая сторона – внедрение OSS Как уже было отмечено, система OSS по своей идеологии должна быть независимой от используемого на сети оборудования, т. е. являться мультивендорной системой. В противном случае это уже не OSS, а замаскированная локальная система управления или мониторинга. При большом количестве разнородного оборудования нескольких компаний-производителей возникает первая проблема – раскрытие форматов данных от оборудования. Обычный запрос в компанию-производитель о структуре формата данных от сенсора некорректен, поскольку эта информация может быть использована в ущерб надежности функционирования сети и работе гарантийного оборудования. На первый взгляд тупиковая проблема решается с помощью стандартизированных платформ OSS (NetBoss, Micromuse, Telesoft и т. д.), ценность которых не только в удобном интерфейсе и настройках экспертной системы, но и в фактическом признании их производителем. Однако стоимость их весьма высока – до 200–300 тыс. долл. И это лишь начало, поскольку после закупки идет этап их кастомизации под конкретные задачи и оборудование оператора. На этапе настройки возникает вторая проблема – адаптация к реальному оборудованию. Здесь, как это ни странно, противником OSS выступает бурный научно-технический прогресс, который в отрасли связи выражается в постоянной модернизации программного обеспечения. Скорость обновления ПО уже дошла до отметки полной его замены каждые полгода. В такой ситуации построение систем OSS выглядит следующим образом: купив платформу, заказчик начинает ее подстройку путем программирования программных блоков, раскрытия и уточнения форматов данных, сопряжения и модификации различных форм отчетности. Процесс этот длительный и мучительный, в нем занят большой коллектив программистов, который в конце концов предоставляет конечный продукт... и в этот момент более половины сети модернизируется, слетают форматы данных, обновляются все служебные поля программного обеспечения, и процесс начинается снова. В подобной гонке без финиша процесс построения систем OSS напоминает пресловутый ремонт Жванецкого, который «невозможно закончить, его можно только прекратить...» Постоянная погоня за модернизацией программного обеспечения сенсоров оборудования подрывает саму идею OSS, поскольку у заказчика оспользоваться какими-либо преимуществами системы – она постоянно в развитии. В результате OSS как единое целое не может быть создана – разворачиваются лишь «локальные острова» системы, позволяющие чем-то управлять, но не обеспечивающие оператору самого важного – возможности взглянуть на сеть в целом. В конце концов, преодолев множественные препятствия, спустя годы и миллионные затраты, оператор достигает вожделенного результата. В целом на «вживление» системы OSS с учетом процесса кастомизации уходит от 3 до 10 лет, в зависимости от проблемности сети. Если в течение этого срока оператор меняет свою техническую политику, сам факт построения системы OSS становится спорным. Оператор инвестирует достаточно большие средства, не имея результата долгое время, а зачастую утратив всякую надежду получить его в ближайшей перспективе. В итоге проект закрывается, что иногда приводит даже к судебным разбирательствам. На рис. 5 показано эволюционное развитие системы эксплуатации – от системы мониторинга до полнофункциональной OSS. На первом этапе создается система мониторинга, которая не «привязана» к форматам данных сенсоров оборудования и может быть развернута за несколько месяцев, что позволяет немедленно приступить к выполнению функций единой системы централизованной эксплуатации. Таким образом, отдача инвестиций начинается практически сразу. На втором этапе рассматриваются задачи для активной компоненты, т. е. для той системы, которая должна влиять на работу сети, осуществлять гибкое реконфигурирование и т. д. Для нее требуется сопряжение с оборудованием сети и, как следствие, длительный процесс внедрения. В то же время уровень интеграции будет определяться задачами, дополнительными к уже действующей сети. Следовательно, может быть достигнута значительная оптимизация инвестиций. Если за отправную точку взять не систему мониторинга, а локальную систему управления, эффективность процесса повысится, так как уже на первом этапе будет присутствовать и пассивная, и активная компонента. Еще раз о загадочной российской почве Завершая общее рассмотрение проблем, связанных с внедрением OSS, добавим несколько слов о специфике российского рынка и российской эксплуатации. Опыт автора и его коллег показывает, что не всякая идея (или продукт системного плана) «приживается» на российской почве. Для этого она должна соответствовать представлениям российской инженерной школы о тех или иных функциях. Увы, очень часто системы мониторинга и управления импортного производства не могут применяться в России без существенной доработки. Здесь сказывается разница менталитетов, особенно в области инженерных подходов. Для отечественной инженерной школы характерно использование специалистов-универсалов с широким охватом и серьезной подготовкой не только в области телекоммуникаций, но и в математике, моделировании, программировании, физике и пр. Российские специалисты «пытливы умом», полны желания изучать новые направлжные специалисты более «узкие», ориентированы на определенный круг задач, где являются более высококвалифицированными профессионалами. Отечественные специалисты очень часто жалуются на то, что импортные системы управления «тупые», не обеспечивают ожидаемых дополнительных функций. Одновременно то, что не вызывает трудностей у импортного специалиста (перечни стандартов, методик расчета и моделирования, новые понятия и пр.), для российских коллег может представлять серьезную задачу. В результате рано или поздно возникает вопрос о доработке любых программных продуктов исследовательского плана под отечественный менталитет. Поскольку системы платформы OSS – сплошь импортные продукты, возникает проблема адаптации. Иногда даже самый простой вопрос о русификации ПО системы OSS может поставить в тупик ее производителя. Но если с локальными системами управления ситуация не столь критична, то при наличии связки OSS/BSS поддержка русского языка особенно важна, так как опосредованно «завязана» на различные системы учета и бухгалтерские документы. Оптимальный вариант адаптации – создание отечественной платформы OSS, однако вряд ли хоть одна уважающая себя компания – производитель оборудования вскроет под сомнительную национальную разработку форматы управления своими устройствами. Здесь возможен компромисс – совместные разработки или широкая кастомизация решений. Альтернатива OSS и возможные пути синтеза Тем не менее тенденция к построению централизованных систем эксплуатации, безусловно, верное направление развития современной российской связи. Но если эффективность систем OSS в сложившейся ситуации считать спорной, то какая альтернатива существует у операторов? Как мы уже сказали, построение централизованной системы эксплуатации может быть начато с развертывания систем локальных систем управления и систем мониторинга, затем происходит постепенный переход к системам уровня OSS с учетом устранения избыточности требований к активной компоненте системы или уровню интеграции. Суть такого решения – максимальная практичность. Система мониторинга развертывается не вследствие принятия той или иной стратегии, а непосредственно для решения той или иной эксплуатационной задачи. К таким решениям можно отнести: • системы технического учета кабельных линий связи; • центральные бюро ремонта на ГТС; • распределенные системы охраны объектов связи; • системы контроля качества услуг в мультисервисных сетях и пр. Подобные системы создаются «на злобу дня» и начинают выполнять задачи эксплуатации централизованными методами. В результате оператор приобретает опыт работы с централизованными системами эксплуатации, имея достаточно времени для интеграции новой эксплуатационной подсистемы в административную структуру предприятия. Полученные «острова» централизованной системы начинают разрастаться в сети, постепенно вытесняя решения распределенной системы. На заключительном этапе все развернутые системы интегрирую сценарий развертывания централизованной системы, поскольку принципы централизованной эксплуатации реализуются сразу после развертывания первой системы управления/мониторинга, а локальные системы выполняют свои задачи в процессе перехода к OSS без перерыва. Основное отличие предлагаемого эволюционного подхода – уровень интеграции оборудования в OSS. При стандартном подходе к развертыванию OSS возникает необходимость сопряжения платформы OSS с каждым типом сенсора используемого оборудования. В случае «перетекания» систем мониторинга в OSS интеграция происходит между системами управления и мониторинга. Она требует более тщательного и глубокого сопряжения по форматам передаваемых данных, но в то же время значительно уменьшает количество элемент-менеджеров в сети, поскольку каждый из них будет представлять собой уже не отдельное устройство, а целый сегмент эксплуатации. Следствием промежуточной интеграции по эволюционному сценарию является не только его относительная безболезненность для оператора, но и существенная гибкость, поскольку уровень интеграции может определять сам оператор. Уже первые работы по оптимальному синтезу систем мониторинга и OSS дали очень интересные результаты. Например, компания PR-GROUP предложила для одного из проектов в области OSS изменение классификации решений. Обычно для систем управления принято деление по уровням управления – устройствами, сетью, ресурсами, услугами, бизнесом (шлюз из OSS в BSS). При таком подходе не учитываются традиционная структура систем электросвязи с ее делением на первичную и вторичные сети, а также специфика работы магистральных, городских и других операторов. Для того чтобы приблизить проблему эксплуатации к реальной сети, было предложено составить матрицу технических решений, где по вертикали использовалось бы классическое деление OSS/TMN, а по горизонтали – технологические подсистемы электросвязи. В клетках матрицы легко поместились и компоненты OSS, и мониторинговые решения, которые дополнили друг друга и одновременно интегрировались в общую систему эксплуатации. Открытые вопросы к обсуждению Подводя итог, хотелось бы вернуться к общей оценке проблемы внедрения OSS. В настоящее время вокруг них складывается революционная ситуация, так что возможны поспешные и непродуманные решения. Чтобы этого не случилось, необходимо начать конструктивное обсуждение проблем OSS на основе следующих принципов: • рассматривать вопросы OSS применительно к построению всей централизованной системы эксплуатации; • анализировать принципы и методы развертывания компонентов OSS на поливариантной основе (с учетом альтернативных способов – локальных систем управления и систем мониторинга); • всегда придерживаться эволюционного подхода, позволяющего создавать более гибкие и функциональные решения; • проводить всесторонний анализ OSS (технический, экспертный, кадровый аспекты); • учитывать национальную специфику и менталитет специалистов; • идтнических решений. При выполнении всех перечисленных условий обсуждение проблемы OSS может войти в нормальное русло, без каких-либо революций, потрясений и бессмысленной борьбы за наведение непонятного порядка. Только тогда новая концепция сможет действительно что-то дать отечественным операторам. Главная страница / Архитектура отрасли |