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 на «домашней» разработке);

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

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

Рекомендуем скачать другие рефераты по теме: предмет культурологии, реферат на тему организация.



1  2 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки