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