Меняющийся лик соглашений об уровне сервиса

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

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

«С точки зрения обслуживания разница между сетью, приложениями и бизнес-процессами постепенно стирается», — говорит Джефф Каплан, директор по стратегическому маркетингу в подразделении NetCare Professional Services компании Lucent Technologies.

Другими стимулами популяризации SLA стали появление электронной коммерции и требования, которые она налагает на сеть. «Если у кого-то имеется крупный узел электронной коммерции, то, очевидно, он хотел бы иметь серьезные гарантии, что узел будет продолжать функционировать при любых обстоятельствах», — добавляет Каплан.

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

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

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

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

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

Одно время гарантии на уровень сервиса и управление производительностью занимали только длинноволосых нечесаных инженеров в их плохо проветриваемых закутках. Они разве что не приходили в экстаз от статистики потерь пакетов и времени прохождения ping от одного конца сети до другого.

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

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

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

Еще больше усугубляет путаницу то, что SLA также претерпевают изменения. В первых SLA основное внимание уделялось характеристикам сетевой инфраструктуры, например тому, что пакет должен попасть с маршрутизатора А на маршрутизатор Б не более чем за 200 мс. Это весьма полезная информация, но сегодня SLA ориентируются на производительность приложений.

«Мы видим, что самое важное — то, как работа сети сказывается на конечных пользователях, — говорит Энди Бирн, менеджер по продуктам VitalAnalysis и VitalHelp в отделе NetCare компании Lucent Technologies. — В конечном итоге, продуктивность рядовых пользователей, работающих с сетевыми приложениями, сказывается на прибыльности компании».

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

Работу сети очень трудно выразить в виде четких критериев. Часто администратор заявляет, что все системы функционируют нормально, поэтому все должно работать адекватно, между тем как конечные пользователи утверждают, что «сегодня сеть как-то медленно работает».

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

Администратор сети может сколько ему угодно утверждать, что все прекрасно (и, с его точки зрения, это действительно так), но конечные пользователи ощущают на себе многочисленные взаимозависимости внутри компании. Сеть, кабели, устройства и приложения — все они взаимодействуют между собой, и, хотя каждый отдельный параметр может представлять некоторую ценность для слежения за тем, что работает, а что нет, истинную картину работы сети нельзя получить посредством суммирования отдельных метрик.

В целях учета точки зрения конечных пользователей такие продукты, как VitalSuite 7.0 от Lucent NetCare, осуществляют мониторинг не только работы устройств, но и работы приложений — для предоставления решения, отчеты которого мог бы понимать любой сотрудник организации (о продуктах см. врезку «Некоторые инструменты для мониторинга»).

«Среди тех, кто принимает решение относительно выбора технологий, менеджеры по маркетингу и по продажам, — говорит Бирн. — Они непосредственно заинтересованы в том, как структура продаж будет реализована в Web».

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

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

SLA состоит из нескольких компонентов, каждый из которых вносит вклад в измерение уровней сервиса (см. более подробно об условиях SLA во врезке «Элементы SLA»). По данным исследования International Network Services (INS, теперь часть Lucent), главной характеристикой является доступность сети, а далее по важности — уровень удовлетворенности пользователей, производительность сети и доступность приложений.

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

Что касается приложений, то для конечных пользователей наиболее существенны два параметра: доступность и время отклика приложения. Вместо времени отклика между двумя устройствами эта метрика, например, сообщает, что при выполнении приложения планирования корпоративных ресурсов среднее время отклика для пользователей составляет 8—10 с.

Интеграция управления приложениями и управления сетью дает возможность углубиться до уровня, на котором администратор мог бы видеть, почему время отклика приложения составляет 8 с. Если оно должно равняться 5 с, то он сможет выяснить, чем вызвана чрезмерная трехсекундная задержка.

«Успех на рынке управления уровнем сервиса будет зависеть от способности продукта обрабатывать данные из различных источников и извлекать из собранных данных необходимую информацию, — говорит Марк Бучард, аналитик-исследователь из META Group. — Как правило, это подразумевает переход от сетецентрической статистики к статистике по ОС и серверам, а также критически важным приложениям».

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

Как измеряется производительность? Какие данные записываются? Как показало исследование INS, наиболее популярной метрикой, используемой при определении доступности и производительности, является доступность всех компонентов сети, в том числе устройств и каналов; следом за ней идет доступность приложений в сети (см. ).

Метрическая система. Приведенные параметры используются для определения и измерения доступности и производительности сети.

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

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

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

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

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

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

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

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

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

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

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

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

Невыполнение. SLA также определяет невыполнение, т. е. что следует делать, когда индикаторы показывают недостижение должного уровня сервиса. Однако здесь немаловажное значение имеет степень отклонения. Например, требование, что время отклика для всех транзакций не должно превышать 2 с, менее реалистично, чем требование, что, скажем, время отклика не должно превышать 2 с для 95% транзакций, а для оставшихся 5% оно должно находиться в пределах от 2 до 5 с.

Предоставляемые услуги. Все сервисы должны быть перечислены и определены с указанием индикаторов уровня сервиса. SLA должно описывать способ измерения индикатора и указывать ответственного за измерения.

Дополнительные услуги. Это перечень дополнительных услуг, которые провайдер услуг готов предоставить по запросу в дополнение к перечисленным в данном соглашении.

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

Особые условия. Если необходимо, в SLA следует предусмотреть особые условия с учетом сферы деятельности компании.

Изменение. В SLA должны оговариваться процедуры его изменения при возникновении такой необходимости.

Уточнение. Технические новшества могут привести к необходимости уточнения SLA или переопределения обязательств. Например, при установке нового оборудования требования клиента в отношении производительности могут вырасти.

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

NetCare Vital Suite 7.0 компании Lucent Technologies. С помощью этого продукта провайдеры услуг могут предоставить заказчикам конкретные отчеты и продемонстрировать выполнение ими соглашений об уровне сервиса (Service Level Agreement, SLA). Со своей стороны заказчики могут использовать его для проверки провайдеров. VitualSuite способен осуществлять непрерывный мониторинг функционирования сетей и приложений как с точки зрения конечного пользователя, так и в отношении параметров работы внутренних механизмов.

В отличие от некоторых других инструментов мониторинга, VitalSuite обеспечивает сквозной мониторинг приложений, сети и сервисов на всех семи уровнях модели OSI. Пользователи могут получить высокоуровневую картину их работы или воспользоваться цветными «тепловыми диаграммами» для получения более подробной информации. Весь комплект стоит от 44 000 долларов.

InfoVista. Этот продукт представляет собой распределенное решение на базе Web и масштабируется на крупные организации со множеством филиалов. Архитектура InfoVista позволяет составлять плановые отчеты об уровне сервиса, по запросу или в реальном времени, для сетевого оборудования и серверов, локальных и глобальных сетей, серверов Web и приложений.

Remedy. Продукт Service Level Agreements 4.0 от Remedy в действительности является частью комплекта Remedy. Совместно с Remedy Help Desk он представляет собой инструмент для проверки внутренних SLA. Пользователи получают единый вид всего комплекта, со специальными консолями для конечных пользователей, технического персонала и руководителей.

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

Мониторинг конкретных разновидностей сетей, таких, как ATM, глобальные сети на базе IP, frame relay и другие, часто осуществляется с помощью аппаратных зондов со специальным программным обеспечением. Трудность в том, что зонды обычно нестандартные. Например, вы можете приобрести зонд для мониторинга маршрутизаторов конкретных производителей. Такое решение вполне адекватно, если сеть построена на базе оборудования одного производителя. Тем не менее оно дает информацию лишь о конкретных устройствах и ничего не сообщает о работе приложений в масштабах всего предприятия.

Cisco Systems предлагает разнообразные зонды для мониторинга сетей на базе оборудования Cisco; они обеспечивают мониторинг на физическом, сетевом и прикладном уровнях, а кроме того, совместимы с большинством платформ управления сетью.

Мониторинг frame relay, ISDN, выделенных линий или глобальных сетей на базе IP позволяет осуществлять множество продуктов. Однако чем выше скорости, тем ограниченнее выбор, и лишь немногие производители поддерживают соединения быстрее T-1/E-1. Это порождает очевидные трудности при мониторинге сети ATM, так как она вполне может работать на скорости 155 Мбит/с. Продукты для мониторинга ATM обычно представляют собой исключительно программные решения для сбора данных из генерируемых коммутаторами ATM журнальных файлов.

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