OSS: економія коштів чи недоотриманий прибуток?

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.