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 Assurance (Cisco Systems). На смену им приходят полноценные коммерческие продукты от компаний Brix Networks, InfoVista, HP и Micromuse (Proviso). Наиболее крупные операторы уже занялись контролем качества сети и услуг. Сначала он проводится только для внутренней сети - это тестирование работы ядра, затем - «последняя миля» и на завершающем этапе - готовая услуга - SLA для конечных пользователей в виде тестов и постоянных отчетов. Это будет уже контроль качества работы услуги «из конца в конец» и по требуемой архитектуре сети клиента, так называемый Managed SLA, а не только «на бумаге». Так что следите за предложениями операторов и запрашивайте эту услугу сами.

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

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

- низкий уровень разграничения доступа и в целом информационной безопасности разработки (одна из основных причин, почему операторы не предоставляют отчеты клиентам по SLA в режиме on-line на «домашней» разработке);

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

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

Давайте оставим решение этих задач профессионалам и не будем идти на поводу у амбициозных программистов. Гораздо эффективнее и полезнее силами внешних консультантов рассчитать возврат инвестиций на коммерческий продукт, а также недополученную прибыль, например, на быстрое развертывание и продажу услуг. Это поможет обосновать инвестиции в OSS.

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

Когда оправданна «домашняя» разработка OSS?

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

Однако резкого перехода от количества к качеству можно избежать, для этого еще на этапе количественного роста оператора необходимо развивать коммерческие OSS-решения в определенных пропорциях с бюджетом строительства сети. Рассчитать оптимальные пропорции позволят обследования и ТЭО по OSS-решениям. Кроме того, полезно развернуть лабораторию с прототипом сети и тщательно протестировать возможных претендентов-поставщиков коммерческих OSS-решений. Более качественно и эффективно это сделают привлеченные консультанты. Максимум, что необходимо со стороны оператора, - создать команду, но только для сопровождения проекта: взаимодействия с консультантами при обследовании, участия в постановке задачи, выработке решения, испытаниях и доработках.

Другой случай использования «домашней» разработки - дефицит бюджета на определенной стадии проекта. Типичный пример, когда на первом этапе создания OSS на операцию контроля сбоев сети (Fault management) бюджета хватило, а автоматизированной службы поддержки (Help Desk) или мониторинга доступности и производительности сетевых узлов (Performance management) - уже нет. Временное использование ПО «домашней» разработки для реализации данных операций действительно оправданно, так как бизнес оператора не останавливается, а решать задачи необходимо уже сейчас. Главное - не увязнуть в разработке таких «заплаток» и правильно запланировать развитие OSS, последовательно продвигать через «экономное» руководство требуемые коммерческие решения.

Выводы

Таким образом, на основании изложенного можно дать некоторые рекомендации:

не тратьте время и средства компании на «домашние» разработки;

экономьте и зарабатывайте деньги на основной производственной деятельности компании;

используйте «домашние» разработки только для временных «заплаток» бюджета IT и эксплуатации;

требуйте постоянной отчетности по представленному качеству услуг и обслуживанию как от собственного подразделения IT и эксплуатации, так и от оператора связи.

Список литературы

Журнал «Connect!», №11.2005