Реферати українською » Информатика, программирование » 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

Схожі реферати:

Нові надходження

Замовлення реферату

Реклама

Навігація