OSS: экономия средств или недополученная прибыль?

Радимир Петров

Данная статья стала отражением дискуссии о пользе и вреде так называемых In-house разработок, которые можно называть «домашними». Речь пойдет о программном обеспечении, создаваемом силами и средствами самого ИТ-подразделения компании. В частности, мы рассмотрим ПО для управления услугами и связью - Operations Support System (OSS).

Радимир ПЕТРОВ, Project Manager Professional IPMA, руководитель направления OSS, компании «Микротест»

Вместо предисловия: .. .и настало время безраздельной власти MRTG и Cricket, и мир погрузился во тьму вечной разработки...

«Домашняя» разработка OSS и качество услуг

Кто обычно занимается «домашней» разработкой OSS-решения? В первую очередь большие операторы, со значительным штатом специалистов в IT-де-партаменте. Подобными разработками увлекаются также средние и более мелкие операторы и даже компании-интеграторы, сами строящие сети и центры обработки данных для клиентов. Но особенно это популярно среди интернет-провайдеров всех уровней, хотя у наиболее крупных из них уже наметилась тенденция снижения интереса к собственным разработкам.

Страдает от этого пользователь услуг связи, в первую очередь из-за банальной экономии средств на стоимости OSS-решения. «Домашние» разработки уступают коммерческим OSS прежде всего по качеству и функциональности, за что расплачиваются клиенты, которые получают услуги с неконтролируемыми параметрами качества. Конечно, такие параметры определены в договоре, но и только... Может даже существовать отдельное приложение к договору - Service Level Agreement (SLA), но это лишь «на бумаге». Данные параметры измеряются и предоставляются в виде отчетов клиентам только при первичной сдаче канала (услуги) или разборе «полетов», когда клиент приходит к оператору с жалобой на плохое качество связи и требованием тестирования канала (услуги).

Проверяется SLA «на бумаге» просто - позвоните и узнайте, предоставляются ли постоянные отчеты по контролируемым параметрам качества услуги, прописанным в контракте. Ответ в 99% случаев будет отрицательным, 1% составляют операторы, пытающиеся предоставлять вручную отчеты на OSS «домашней» разработки. Мучаются специалисты оператора, но делают... Это редкий случай, причем обычно для самых придирчивых и богатых корпоративных клиентов, так называемой категории VIP. Самое печальное, что выбирать не приходится, так как одного оператора с SLA «на бумаге» пока можно поменять только на другого, такого же. А VIP-обслуживание доступно очень узкому кругу клиентов.

Где же выход? Продолжайте спрашивать у операторов услуги с «настоящим», постоянно контролируемым SLA. Это заставит их задуматься над проблемой отчетности и контроля уровня качества услуг и, в конце концов, предоставить их.

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

Последствия «домашней» разработки OSS

Давайте порассуждаем, чем может обернуться такая «домашняя» разработка? Назовем наиболее типичные проблемы:

- сосредоточение знаний в одной умной, но «единственной»

голове программиста этой разработки. Данный специалист будет настолько уникален, что, случись проблемы с таким ПО (здесь и далее синоним OSS «домашней» сборки), например, во время болезни или отпуска, устранить неполадки будет очень трудно;

- низкий уровень документирования решения (качества и объема, сравнимые с документированием коммерческого OSS-решения, достижим только теоретически);

- низкий уровень поддержки решения;

- низкая функциональность и постоянная доработка решения в надежде хоть на 10-20% реализовать возможности коммерческого OSS-решения, которое, в свою очередь, тоже развивается, но совершенно иными темпами;

- низкий уровень графического интерфейса «домашней» разработки, обычно это текстовые редакторы, причем на xNIX и псевдоязыке;

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

- отсутствие поддержки контроля версионности (для продуктивного решения данной задачи тоже необходимо коммерческое ПО);

- отсутствие контроля (логиро-вания) действий программиста, который является обычно и администратором данного сервера (это всегда будет «черным ящиком» для руководителя);

Перемены в потребностях рынка

Об изменении тенденции с «домашними» разработками и «бумажными» SLA в среде операторов связи можно судить по активизации рынка коммерческих OSS-решений. Прежде всего это относится к автоматизации операций управления QoS и SLA Обычно «управление» QoS и SLA осуществлялось средствами «домашней» разработки на основе скриптов, Cricket или MRTG, путем контроля качества работы ядра сети по откликам агентов SNMP или Service Assura