Радимир Петров
Данная статья стала отражением дискуссии о пользе и вреде так называемых 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 в режиме on-line на «домашней» разработке);
- потеря времени на разработку и развитие решения (как уже было сказано, вся работа превращается в бесконечную погоню за коммерческим продуктом без всякой надежды на успех);
- потеря средств. Поскольку разработка ПО не является основным профилем компании, то себестоимость решения будет значительно превышать планируемые затраты (не забывайте еще о развитии и поддержке данного ПО), при этом по производительности и качеству на порядок уступая коммерческому ПО.
Давайте оставим решение этих задач профессионалам и не будем идти на поводу у амбициозных программистов. Гораздо эффективнее и полезнее силами внешних консультантов рассчитать возврат инвестиций на коммерческий продукт, а также недополученную прибыль, например, на быстрое развертывание и продажу услуг. Это поможет обосновать инвестиции в OSS.
Обобщая типичные проблемы с «домашней» разработкой, можно сделать следующий вывод: «Не бойтесь совершенства - вам его не достичь». Вот и ответ на вопрос о маршрутизаторах на FreeBSD - экономия обойдется дороже...
Когда оправданна «домашняя» разработка OSS?
«Домашняя» разработка OSS-решения оправданна, когда оператор связи наращивает сети: точки присутствия, емкости, зону покрытия услугой и технологией и т. д. Это период становления оператора. В таких случаях, конечно, подразделения IT или эксплуатации сети в вопросах финансирования всегда проигрывают подразделениям капитального строительства, что вполне объяснимо и оправданно. О коммерческом OSS-решении, качественном и многофункциональном, вспоминают, когда созревает здоровая конкуренция и наращивание сетей уже не дает прежней прибыли. Наступает период насыщения рынка связи данного региона, и требуется переход от количества к качеству. В такой ситуации оператор или находит способы качественного роста, или сдает свои позиции на рынке, «золотой середины» нет.
Однако резкого перехода от количества к качеству можно избежать, для этого еще на этапе количественного роста оператора необходимо развивать коммерческие OSS-решения в определенных пропорциях с бюджетом строительства сети. Рассчитать оптимальные пропорции позволят обследования и ТЭО по OSS-решениям. Кроме того, полезно развернуть лабораторию с прототипом сети и тщательно протестировать возможных претендентов-поставщиков коммерческих OSS-решений. Более качественно и эффективно это сделают привлеченные консультанты. Максимум, что необходимо со стороны оператора, - создать команду, но только для сопровождения проекта: взаимодействия с консультантами при обследовании, участия в постановке задачи, выработке решения, испытаниях и доработках.
Другой случай использования «домашней» разработки - дефицит бюджета на определенной стадии проекта. Типичный пример, когда на первом этапе создания OSS на операцию контроля сбоев сети (Fault management) бюджета хватило, а автоматизированной службы поддержки (Help Desk) или мониторинга доступности и производительности сетевых узлов (Performance management) - уже нет. Временное использование ПО «домашней» разработки для реализации данных операций действительно оправданно, так как бизнес оператора не останавливается, а решать задачи необходимо уже сейчас. Главное - не увязнуть в разработке таких «заплаток» и правильно запланировать развитие OSS, последовательно продвигать через «экономное» руководство требуемые коммерческие решения.
Выводы
Таким образом, на основании изложенного можно дать некоторые рекомендации:
не тратьте время и средства компании на «домашние» разработки;
экономьте и зарабатывайте деньги на основной производственной деятельности компании;
используйте «домашние» разработки только для временных «заплаток» бюджета IT и эксплуатации;
требуйте постоянной отчетности по представленному качеству услуг и обслуживанию как от собственного подразделения IT и эксплуатации, так и от оператора связи.
Список литературы
Журнал «Connect!», №11.2005