Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Как используются соглашения SLA

Джон Сапериа

Особенности современного делового климата обязывают руководителей отделов ИТ интересоваться исключительно теми технологиями и подходами, которые обещают увеличение прибыльности их предприятию и повышение его конкурентоспособности, а также могут продемонстрировать важность подразделений ИТ. Для достижения этих целей все чаще используются соглашения об уровне обслуживания (Service Level Agreements — SLA).

Входящая в организацию Open Group специальная комиссия по качеству обслуживания (Quality of Service) поделилась с нами результатами своего недавнего исследования, касающегося использования SLA. (Open Group — независимый международный консорциум, цель которого — согласовывать интересы покупателей и продавцов продукции ИТ, чтобы уменьшить время, расходы и риски, связанные с внедрением новых технологий в корпоративной среде.) Представленные в данном исследовании компании США относятся к самым разным вертикальным рынкам. Всего в Web-опросе и последующих телефонных переговорах принимал участие 151 респондент (см.: “Наши респонденты”).

Полную версию данной статьи смотрите во 6-ом номере журнала за 2003 год.

Не так все радужно

Основные претензии, предъявляемые компаниями к сервис-провайдерам, состоят в том, что SLA-соглашения трудно реализуются на практике и имеют запутанную документацию (рис. 1). При применении SLA и повторном обсуждении их условий постарайтесь четко разобраться во всех деталях — если вы будете знать, где могут таиться ловушки, считайте сражение уже наполовину выигранным.

Не отказывайтесь от SLA даже в том случае, если вы не смогли полностью отстоять свои условия — более половины опрошенных заявили, что SLA бывают полезны даже без пункта о санкциях или штрафах. Например, сформировав хорошую систему показателей обслуживания, вы сможете определить действительное положение вещей и воспользоваться этой информацией при заключении соглашений в будущем с тем же провайдером или, чтобы добиться лучших условий, с другим. Руководствуясь этими соображениями, в ходе переговорного процесса оговорите получение соответствующих численных данных, которые доказывали бы соблюдение условий SLA, и позаботьтесь о том, чтобы документация выбранных параметров была понятна и полезна вашей организации.

Принимая во внимание проблемы и расходы, связанные с использованием SLA, компания, чтобы ввязаться в это дело, должна иметь очень вескую причину. Что ж, как показал опрос Open Group, SLA действительно могут реально способствовать решению важных бизнес-задач (рис. 2).

SLA настолько важны, что большинство респондентов согласны подписаться на некоторые виды обслуживания только в том случае, если для них предусмотрены SLA. Они же заявили, что соглашения об уровне обслуживания помогают им более эффективно конкурировать на рынке. Если разворачивание новой сетевой службы стоит затрат, то стоит затрат и знание того, будет ли способствовать эта служба достижению тех целей, для которых она разворачивается. Собственно гово-ря, большинство участвовавших в опросе компаний заключили SLA на большой перечень служб, от низкоуровневого транспорта, например Frame Relay, до высокоуровневых систем, таких, как видеоконференц-связь.

И невзирая на простоту или сложность тех служб, которые вы намерены предлагать, SLA помогут вам максимально удовлетворить требования ваших клиентов (или конечных пользователей), а также окажут содействие повышению вашей конкурентоспособности, предоставляя точную информацию, на что пошли ваши денежки и получаете ли вы то, за что их заплатили.

Подробности, подробности...

Многие респонденты придают SLA большое значение (рис. 3). При этом ценность этих соглашений тем выше, чем точнее прописаны в них все параметры и методики их определения. Здесь в игру вступают слова “маркировка” и “измерение”. Маркировка на языке SLA означает идентификацию конкретных служб во всей сети. А измерение в этом контексте означает мониторинг этих маркированных служб.

Измерения параметров сетевой службы позволят вам подтвердить перед вашими пользователями и высоким начальством, что вы обеспечили им именно то, за что было уплачено. Чем точнее маркировка и измерение, тем с большей уверенностью можно сказать, соответствует ли включенный в соглашение сервис требованиям вашего бизнеса.

Как добиться точного учета? Один из подходов предусматривает применение технологий, идентифицирующих различные типы сетевого трафика. Из рис. 4 видно, что среди тех, кто использует этот подход, самым распространенным способом маркировки является URL-идентификация. При этом отметим, что только 23% респондентов применяют показанные на данном рисунке методы.

Проблем здесь несколько. Технологии идентификации сетевых служб обычно сложны для конфигурирования и мониторинга. И к сожалению, есть службы, которые не так просто классифицировать или даже отличить в сети. Допустим, например, что вам важен не весь трафик IP-телефонии, а только тот, что проходит между определенными точками? Конфигурирование и мониторинг, связанные с таким уровнем детализации, могут оказаться чрезвычайно сложными. Проблема еще и в том, что компании хотя и заинтересованы в информации по типам приложений, но в большинстве своем не вкладывают средства в технологии типа DiffServ (Differentiated Services), которые позволили бы им такие данные получить. Вместо этого они предпочитают предоставлять критически важным приложениям выделенные сетевые компоненты и серверы приложений.

Здесь мы подошли вплотную ко второму, испытанному и верному подходу — избыточному выделению ресурсов (over-provisioning). Суть этого подхода проста — достаточно поместить важные службы на выделенное оборудование, мощности которого с избытком хватит для их нормальной работы. В некоторых случаях трафик пускается по линиям связи, которыми не пользуются никакие другие сетевые службы, что дает вам полный контроль над ситуацией. Именно так обычно и поступают, чтобы обеспечить гарантированную работу наиболее важных для предприятия служб.

Итак, реализация первого подхода, при котором, как правило, требуются сложные технологии типа DiffServ, может оказаться дорогостоящей в части конфигурирования, мониторинга и управления. Что касается второго подхода, то он требует изрядных инвестиций в оборудование и выделенную полосу пропускания. Выбор сделать трудно, но не невозможно, ведь вашей целью является снижение издержек — значит, мы сравниваем “яблоки с яблоками”. Для подхода “избыточность” определение затрат элементарно: стоимость оборудования и дополнительной полосы пропускания плюс затраты на конфигурирование дополнительных ресурсов.

Использование технологий для управления трафиком в сети может дать экономию полосы пропускания, расходов на сетевое оборудование, а также гарантию, что ваши сетевые ресурсы действительно используются по назначению. К недостаткам этого подхода относятся более сложное конфигурирование и сбор текущих данных, которые помогут определить соблюдение SLA, а также необходимость в квалифицированном персонале для выполнения этих задач.

К решению проблемы можно подойти и с другой стороны: попробовать оценить стоимость процедур мониторинга и измерений, что необходимы для реализации SLA. В результате вы сможете провести анализ затрат для двух решений: “избыточность” против “высоких технологий”. “Избыточность”, как правило, побеждает из-за сложности новых технологий, даже если принять во внимание, что она может не обеспечить нужной масштабируемости для внедрения все новых критически важных приложений. Следует также признать, что DiffServ и его собратья хоть и обнаруживаются в некоторых новых устройствах, таких, как маршрутизаторы Cisco, но зачастую оказываются слишком сложными для большинства сотрудников ИТ-отделов.

Вот два небольших примера. При реализации необходимого качества обслуживания в кампусной сети логично пойти по пути “избыточности”, особенно учитывая появление таких скоростных технологий, как 10 Gigabit Ethernet. Но в случае, когда рассматриваемые ресурсы в дефиците и дороги, как, например, в территориально-распределенных сетях (WAN), лучше пойти на внедрение механизмов управления трафиком.

Наблюдая за наблюдателями

Из рис. 5 видно, какие именно данные ценят корпоративные пользователи. Проверьте, что из указанных на этом рисунке данных предлагает ваш сервис-провайдер. Все эти данные, включая отчеты об использовании ресурсов, мониторинг пороговых величин и работы различных приложений в реальном времени, помогают выяснить, соблюдаются или нет условия SLA.

Многие компании до сих пор не проводят такого рода измерения независимо от выбранного ими подхода: “избыточности”, гарантирующей “выделенное” обслуживание, или применения технологий для контроля расходования общих ресурсов. Отделы ИТ во многих организациях до сих пор привыкли получать большую часть информации на основании откликов пользователей, без всякого там хитроумного мониторинга. Такая качественная оценка действительно очень важна, но если дополнить ее количественными данными, получаемыми в режиме реального времени, то вы окажетесь в более выгодной позиции для защиты своего бюджета и получите реальные рычаги воздействия на сервис-провайдера.

Количественные данные имеют и дополнительную ценность: их можно использовать для более разумного планирования мощностей, распределения ресурсов, проектирования серверной и сетевой структуры. Каждая из перечисленных задач может потребовать больших расходов и не принести ощутимых выгод, если решать ее, не имея реальных данных.

Как собрать характеристики

Чтобы делать выводы о соблюдении или нарушении SLA, в большинстве случаев вам потребуется получать информацию из сети — будь то отчеты о перерывах в обслуживании или мониторинг трафика в режиме реального времени. Пока еще нет общепринятых стандартов, на основе которых мы могли бы сказать о качестве работы служб высокого уровня. По большей части эти вопросы решаются индивидуально в каждом конкретном случае.

Наиболее часто используются такие характеристики, как время задержки, потеря пакетов, средняя наработка до ремонта (MTTR), средняя наработка на отказ (MTBF), коэффициент готовности и время отклика транзакций. Комбинируя их различным образом, вы сможете прописать в своем SLA достаточно условий, чтобы сразу знать о нарушении соглашения. Но, несмотря на ценность упомянутых характеристик, многие до сих пор не могут добиться их получения от своих сервис-провайдеров (рис. 6).

Если количественные данные так полезны для решения множества важных задач, то почему же большинству из нас они недоступны? Так, только чуть более трети тех, кого мы опрашивали, получают базовые данные о потере пакетов, а 25% не могут добиться даже получения статистики о перерывах в обслуживании.

Этому есть несколько возможных объяснений. Самым убедительным выглядит следующее: у нас нет интегрированных наборов средств, которые бы обеспечили мониторинг сетевых служб. Вместо этого имеется нечто вроде лоскутного одеяла, сшитого из отдельных средств для конфигурирования, мониторинга производительности, управления отказоустойчивостью, безопасностью (например, системы обнаружения вторжений). Именно эта разнородная масса систем является главным препятствием для эффективного управления сетью и службами.

Жизнь с SLA

Но не отчаивайтесь: не все так безнадежно. Есть вещи, которые мы все-таки можем сделать, чтобы извлечь максимальную пользу из тех соглашений SLA, которые заключаем и с нашими провайдерами и с внутренними клиентами.

• Беритесь, не колеблясь, за SLA невзирая на все их недостатки. Только убедитесь, что ваше соглашение прописано достаточно аккуратно, чтобы вы могли получать достоверные данные о соблюдении условий SLA в любой момент времени (даже если эти данные и не будут столь детальными, как вам бы того хотелось).

• Постарайтесь оставить само соглашение и вашу сеть как можно более простыми, сама возможность сбора большого количества данных еще не означает, что это надо делать. Ведь сбор и анализ сетевых данных требуют серьезных затрат. Если в вашей сети имеется важная служба, которая всегда должна работать, и работать хорошо, то поступите так, как уже сделали многие до вас: вместо того чтобы внедрять новую технологию, выделите оборудование и канальные ресурсы на нужды этой службы. Затем, когда ПО управления станет более совершенным, переводите все службы в единую сетевую инфраструктуру, сохраняя необходимые им характеристики по надежности и производительности.

• Пропишите в SLA конкретные виды измерений и определите способ их проведения. Нужно быть уверенными, что вы правильно понимаете методику измерений, и имеете хорошее представление о том, что испытывают ваши пользователи.

• Требуйте от ваших сервис-провайдеров и поставщиков оборудования постоянного улучшения средств управления. Необходимость в новом поколении управляющего ПО действительно назрела, а пока суд да дело, ужесточение требований может привести хотя бы к постепенному его совершенствованию..


http://pedant.ru/moscow/remont-telefonov/remont-apple/ipad/4/




  
6 '2003
СОДЕРЖАНИЕ

колонка редактора

• Хот-спот Wi-Fi — "горячая" точка мира телекоммуникаций

бизнес

• Рынок СТК и Интернет-карт в Москве

• Тенденции развития российского рынка сотовой связи

инфраструктура

• Тестируем двухдиапазонные точки доступа для беспроводных ЛВС

• Уровень 7 работает на вас

• Решение транспортной проблемы Москвы — в руках связистов?

информационные системы

• Проблемы реализации ИТ-проектов на государственном предприятии

• Системы CRM осваивают новые профессии

• Приди и возьми!

• Ликвидируем утечки коммуникаций

сети связи

• Проверка качества каналов Интернет

• Качество VoIP: корреляция оценки MOS и R-фактора

• Как используются соглашения SLA

кабельные системы

• Еще раз об интероперабельности компонентов категории 6

• Спецификация и выбор оптического волокна, применяемого в СКС

• Стандарт на СКС для систем автоматизации зданий

новые продукты

• Четырехпроцессорный Storm; Онлайновые ИБП Vanguard; Системы удаленного присутствия In-Reach LX-4000S


• Калейдоскоп



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх