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

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

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

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

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


Rambler's Top100

  

Управление уровнем обслуживания с разных точек зрения

Дэвид Уиллис

Управление уровнем обслуживания — сегодня эти слова произносят многие, часто не вникая в их смысл.

Раньше под термином “управление уровнем обслуживания” понимали более конкретные действия, но последние два года его употребляют совершенно неадекватно. Теперь трудно понять, что именно имеют в виду люди, произнося этот термин. Частично в сложившейся ситуации виновата специализированная пресса, на страницах которой многие поставщики постоянно заявляют о своей причастности к ныне популярному движению — управлению уровнем обслуживания (Service-Level Management — SLM).

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

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

Назад к основам

Обычно под соглашением об уровне обслуживания (Service-Level Agreement — SLA) подразумевают контракт между поставщиком и потребителем, терминология которого понятна последнему. Насколько мне известно, специалисты отделов информационных технологий (IT) предпочитают описывать предоставляемые услуги управляемых ими систем, используя понятную им одним техническую терминологию: клиенту демонстрируются данные по загруженности сети и обработке транзакций отдельными хостами и, возможно, значение времени отклика для некоторых выбранных узлов. Вооружась длинным списком этих никак не связанных друг с другом цифр, можно без труда убедить пользователей в надежности работы системы, даже если они жалуются на низкое качество обслуживания.

И в этом нет ничего удивительного, поскольку пользователям просто-напросто предоставляются самые лучшие показатели работы оборудования. И хотя для клиентов эти рафинированные данные практически бесполезны, ИТ-менеджер, подобно герою вестерна, всегда готов “выхватить” свой отчет, если его попросят объяснить причину низкой производительности некоторых приложений или сбоев в их работе: “У удаленных пользователей имеются проблемы, потому что линия постоянно занята? Этого не может быть, взгляните на статистику и убедитесь сами, как часто бывают свободны порты!”

Если подобный прием не убеждает пользователя, в ход идут утверждения, что, дескать, он (ИТ-менеджер) не отвечает за возникновение этой проблемы, потому что это не его сеть (или не его хост, не его база данных, не его приложение и т. д.). Может быть, вы просто не правильно используете это приложение? Один указывает пальцем на другого. Однако привычка прикрываться данными о производительности оборудования в конечном счете ведет к поражению в борьбе за клиентов.

Мой партнер меня не понимает

Взгляните на цифры, которые помогают вам отслеживать изменения производительности вашего оборудования, и подумайте, имеют ли они какое-либо значение для вашего клиента. Если, хвастаясь перед каким-нибудь “технарем”, вы рассказываете ему о том, сколько байтов в секунду может быть обработано тем или иным хостом вашей сети, спросите себя, а нужно ли это знать вашему клиенту? Как и многие другие, он и так осмысливает слишком много информации. Способствуют ли эти цифры вашему сотрудничеству с пользователем или становятся барьером между ним и вами?

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

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

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

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

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

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

Взгляд с другой стороны

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

что пользователь “видит” со своего рабочего места.

Продукт VeriServ фирмы Response Network — это один из продуктов, действительно заслуживающих того, чтобы их называли “средствами управления уровнем обслуживания”. VeriServ помещает на клиентские машины небольшие программы-агенты, которые тестируют приложения “на лету” с точки зрения того, кого их работа волнует больше всего, т. е. конечных пользователей. Агенты VeriServ определяют степень доступности приложений и измеряют время отклика, периодически посылая информацию на центральный узел, здесь она суммируется и оформляется в виде отчета. Запуская программные тесты непосредственно на рабочих местах, можно получить характеристики уровня обслуживания приложений. Агенты VeriServ могут также генерировать запросы к СУБД или выполнять эхо-тестирование определенных адресов и портов TCP/UDP, а в будущем — проверять работу таких приложений, как Microsoft Exchange или Lotus Notes. И хотя то, что они измеряют, работая параллельно с самими приложениями, не является в чистом виде пользовательским временем отклика, полученные с их помощью результаты настолько близки к нему, насколько в принципе этого можно добиться без изменения самих приложений.

Благодаря такому подходу фирмы Response Network к управлению уровнем обслуживания VeriServ потребляет очень мало ресурсов на клиентской стороне и этим отличается от большинства других средств управления сетями и системами. Вместо сбора больших объемов данных и попытки получить какие-либо выводы в результате их обработки VeriServ просто измеряет наиболее важные параметры. При возникновении проблем вы всегда сможете воспользоваться любым из имеющихся продуктов, предназначенных для их локализации и устранения.

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

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





  
8 '1999
СОДЕРЖАНИЕ

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

• Виртуальный Госснаб для реальной экономики

локальные сети

• Устанавливаемые в стойку серверы

• СКС категории 6: за и против

• Избежать полировки наконечников оптических разъемов пока не удается

• Коаксиальный кабель: кому сухарь, а кому хлеб с маслом

• Nortel Networks: объединение на всех уровнях

• Балансировка загрузки «многозадачных» руководителей

• На заводе APC в Галвее

интернет и интрасети

• Настоящее и будущее средств разработки

• XML: эсперанто для приложений

корпоративные сети

• Как внедрить SMB в среде Unix

• Управление уровнем обслуживания с разных точек зрения

• Подключение филиала по выделенной линии. Практические советы

услуги сетей связи

• MSDSL: технология на все случаи жизни

• Маленькие и большие шлюзы IP-телефонии

• GSM on the Net: мобильность и интеграция обслуживания

• Операторы связи на рубеже столетий

системы учрежденческой связи

• Микросотовые системы стандарта Dect

защита данных

• Средства антивирусной защиты серверов

• С такими друзьями...

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

• HP для инженеров, дизайнеров и поставщиков информационных услуг; Никто не хочет класть все яйца в одну корзину; Сatalyst 2924M XL: больше портов для сетевых штормов



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