Доступность : Высокая доступность

Управление уровнями обслуживания Рекомендации и Описание технологических решений

28 июля 2013 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (4 октября 2005) | Отзыв


Содержание


Введение

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

Общие сведения об управлении уровнем обслуживания

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

Факторы критического успеха

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

Дополнительные сведения см. в разделе "Реализация управления уровнем услуг".

Показатели эффективности

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

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

Показатели эффективности включают:

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

  • Ежемесячно передавая просмотр встречи уровня обслуживания для рассмотрения соответствия уровня обслуживания и улучшений внедрения.

  • Метрики указателя эффективности, включая доступность, производительность, время ответа сервиса в зависимости от приоритета, время до принятия решения в зависимости от приоритета, а также другие измеримые параметры SLA

Подробнее см. "Внедрение управления на уровне службы".

Поток данных процесса управления на уровне службы

Поток процессов высокого уровня для управления уровнем обслуживания включает две основные группы:

  1. Определение уровней сетевой службы

  2. Создание и поддержание SLA

Щелкните по объектам в придерживающейся схеме для просмотра подробных данных для того шага.

/image/gif/paws/15117/highlevel.gif

Внедряющее управление уровнем обслуживания

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

Определение уровней сетевой службы

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

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

Мы рекомендуем следующие шаги для здания и поддержки модели уровня обслуживания:

  1. Проанализируйте технические цели и ограничения.

  2. Определите бюджет доступности.

  3. Создайте профили приложения, детализирующие сетевые характеристики критически важных приложений.

  4. Определите доступность и стандарты производительности и определите распространенные слова.

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

  6. Соберите метрики и контролируйте определение уровня обслуживания.

Шаг 1. Проанализируйте технические цели и ограничения

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

Например, у вас мог бы быть уровень доступности 99.999 процентов, или 5 минут времени простоя ежегодно. Для достижения подобных показателей существует ряд ограничений: единственное уязвимое место в аппаратном обеспечении, среднее время восстановления работоспособности (MTTR) неисправного оборудования в удаленных пунктах, надежность несущей, функции профилактического обнаружения ошибок, высокая частота внесения изменений и текущие ограничения пропускной способности сети. В результате можно отрегулировать цель к более достижимому уровню. Модель доступности в следующем разделе поможет поставить реальные цели.

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

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

  • Сетевые технологии, упругость, и конфигурация

  • Жизненные циклы технологии, включая планирование, дизайн, реализацию, и операцию

  • Текущий трафик или поведение приложения

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

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

Жизненные циклы технологии определяют процессы и управление сетью, используемой, чтобы последовательно развернуть решения, обнаружить и восстановить проблемы, предотвратить емкость или проблемы производительности, и настроить сеть для целостности и модульный принцип. Необходимо рассматривать эту область, так как экспертиза и процесс обычно наибольшим образом отражается на отсутствии работоспособности. Жизненный цикл сети обращается к циклу планирования, дизайна, реализации, и операций. В пределах каждой области следует понять функции управления сетью, такие как управление производительностью, управление конфигурацией, управление отказами и защита. Оценка жизненного цикла сети доступна от служб служб высокой доступности (HAS) NSA Cisco, показывая ограничения доступности текущей сети, привязанные к методам жизненного цикла сети.

Текущий трафик или ограничения приложения просто обращаются к влиянию текущего трафика и приложений.

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

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

Риск или ограничение Тип ограничения Потенциальное воздействие
Доступные программные средства обнаружения DoS не могут обнаружить все типы атак DoS. Технология/упругость Высоко
Не имейте требуемого штата и обрабатывайте для реакции на предупреждения. Жизненные циклы технологии Высоко
Политика доступа текущей сети не существует. Жизненные циклы технологии Среда
Если перегрузка полосы пропускания используется для атаки, текущее Интернет-соединение более низкой пропускной способности может быть фактором. Пропускная способность сети Среда
В настоящее время конфигурация безопасности, чтобы помочь предотвращать атаки может не быть полной. Технология/упругость Среда

Шаг 2. Определите бюджет доступности

Бюджет доступности является ожидаемой теоретической возможностью сети между двумя определенными точками. Точные теоретические сведения полезны несколькими способами:

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

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

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

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

Доступность является вероятностью, что продукт или услуга будет работать при необходимости. См. следующие определения:

  1. Доступность

    • 1 - (общее время простоя соединения) / (общее время работы соединения)

    • 1 - [Sigma (цифровые соединения, на которые влияют в простое i X продолжительностей простоя i)] / (цифра ведет в обслуживании в X раз),

  2. Недоступность

    1 - Доступность, или общее время бездействия соединения вследствие (аппаратной ошибки, программной ошибки, проблем с питанием и средой, ошибки канала или несущей, структуры сети или ошибки пользователя и ошибки процесса)

  3. Коэффициент готовности оборудования

    Первой областью, которая займется расследованиями, является сбой потенциального оборудования и эффект на недоступность. Чтобы это определить, организация должна проанализировать MTBF всех сетевых компонентов и MTTR для неполадок с оборудованием для всех устройств между двумя точками. Если сеть будет модульной и иерархической, то доступность оборудования будет тем же между почти любыми двумя точками. Данные MTBF доступны для всех компонентов Cisco и предоставляются по запросу местному менеджеру по работе с клиентами. Программа Cisco NSA HAS использует также средства для определения доступности оборудования по сетевым путям, даже если в системе представлены избыточности модулей, шасси и путей. Одним из главных факторов надежности аппаратного обеспечения является MTTR. Организации должны оценить, как быстро они могут восстановить поврежденное оборудование. Если организация не имеет никакого недостаточного плана и полагается на стандартный Cisco соглашение SMARTnet™, то потенциальное среднее время замены составляет приблизительно 24 часа. В типичной среде локальной сети с резервированием основных компонентов и никакой избыточностью доступа, приблизительная доступность составляет 99.99 процентов с 4-часовым MTTR.

  4. Доступность программного обеспечения

    Следующая область для рассмотрения является сбоями программного обеспечения. В измерительных целях Cisco определяет сбои программного обеспечения как coldstart устройства вследствие программной ошибки. Cisco сделал значительные успехи к общим сведениям доступности ПО; однако более новые версии занимают время для измерения и считаются менее доступными, чем программное обеспечение для общего развертывания. Программное обеспечение для общего развертывания, такое как версия IOS 11.2 (18), было измерено в доступности на более чем 99.9999 процентов. Это рассчитывается по количеству выполненных "холодных" запусков маршрутизаторов Cisco с временем починки, равным шести минутам (столько занимает перезагрузка маршрутизатора). Организации, работающие с различными версиями, могут столкнуться с незначительным снижением доступности из-за повышенной сложности сети, проблем совместимости и увеличения времени, затрачиваемого на устранение неполадок. Предполагается, что компании, использующие последние версии программы, имеют более высокий уровень недоступности. Распространение для недоступности также достаточно велико, т.е. клиенты могут столкнуться со значительной недоступностью или доступностью, близкой к выпускам для обычного развертывания.

  5. Связанный со средой и доступность питания

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

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

    Для осторожной оценки мы можем сказать, что организация с резервными генераторами, системами uninterruptible-power-supply (UPS), и процессами внедрения качества мощности может испытать шесть 9s доступности, или 99.9999 процентов, тогда как организации без этих систем могут испытать доступность в 99.99 процентах, или приблизительно 36 минут времени простоя ежегодно. Конечно, можно отрегулировать эти значения к более реалистическим значениям на основе восприятия организации или реальных данных.

  6. Ссылка или ошибка несущей

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

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

    Создание оценки доступности для WAN - сред должно основываться на информации фактического носителя и уровне избыточности для "возможности подключения WAN. Если организация будет иметь несколька вводов телекоммуникаций в здание, избыточных поставщиков локальной петли, локальный доступ SynchronousOptical Network (SONET) (синхронная оптоволоконная сеть), и избыточных поставщиков услуг дальней связи с географическим разнесением, то готовность WAN будет значительно улучшена.

    Служба телефонии – это очень доступно для сетевых подключений без избыточности в средах WAN. Сквозное соединение для телефонов имеет бюджет приблизительной доступности 99.94 процентов используя методология бюджета доступности, подобная той, описанной в этом разделе. Эта методология была успешно использована в окружении данных, где присутствовало только незначительное отклонение, и теперь используется в качестве цели спецификации PacketCable для кабельных сетей поставщиков услуг. Если мы применяем это значение к полностью избыточная система, мы можем предположить, что готовность WAN будет близко к доступным 99.9999 процентам. Конечно, очень немного организаций имеют абсолютно избыточный, географически рассеянные системы WAN из-за расхода и доступности, таким образом используйте правильное решение относительно этой возможности.

    Отказы соединения в среде локальной сети менее вероятны. Однако планировщики могут хотеть принять малую величину времени простоя в связи с к сломанным или свободным разъёмам. Для локальных сетей оценка с запасом является доступностью на приблизительно 99.9999 процентов, или приблизительно 30 секунд ежегодно.

  7. Инфраструктура сети

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

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

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

    Вычислите доступность просто использование те же методы системных расчетов. Однако это не допустимо, если время переключения сети не удовлетворяет требования сетевого приложения. Если время переключения приемлемо, удалите его из вычисления. Если время переключения не приемлемо, то необходимо добавить его к вычислениям. Примером могла бы быть речь по IP (VoIP) в среде, где предполагаемое или фактическое время переключения составляет 30 секунд. В данном примере пользователи просто зависнут телефон и возможно попробуют еще раз. Пользователи несомненно сочтут этот промежуток времени как недоступность, однако он не оценивается в уровне доступности.

    Вычислите недостаток вследствие времени перехода системы в другой режим путем рассмотрения теоретической доступности программных и аппаратных средств вдоль путей с избыточным резервом, потому что переключатель произойдет в этой области. Следует знать количество устройств, которые могут дать сбой и вызвать переключение на резервный маршрут, MTBF этих устройств и время переключения. Простой пример был бы MTBF 35,433 часов для каждого из двух избыточных идентичных устройств и время переключения 30 секунд. Делясь 35,433 8766 (часовы в год, усредненные для включения високосных годов), мы видим, что устройство откажет один раз каждые четыре года. Если мы используем 30 секунд как время переключения, мы можем тогда предположить, что каждое устройство испытает, в среднем, 7.5 секунд ежегодно недостатка вследствие переключателя. Так как пользователи могут пересекать любой путь, результат тогда удвоен до 15 секунд ежегодно. Когда это вычислено с точки зрения секунд ежегодно, сумма доступности в связи с к переключателю может быть вычислена как доступность на 99.99999785 процентов в этой простой системе. Этот показатель может быть еще выше в других средах, в зависимости от числа избыточных устройств в сети, в которой вероятна возможность переключения.

  8. Ошибка пользователя и процесс

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

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

    Так как вы не можете теоретически вычислить сумму недостатка вследствие ошибки пользователя и процесса, мы рекомендуем удалить, это удалило из бюджета доступности и этого, организации борются за совершенство. Одно предупреждение состоит в том, что организации должны понять текущий риск для доступности в их собственных процессах и уровнях знаний и опыта. Когда вы лучше понимаете эти риски и задержки, сетевые планировщики могут изъявить желание разложить на некоторое количество недоступность из-за этих проблем. Программа Cisco NSA HAS расследует эти проблемы и может помочь организациям оценить потенциальную возможность недоступности из-за проблем процесса, пользовательской ошибки или недостаточной квалификации.

  9. Определение итогового баланса доступности

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

    В данном примере бюджет доступности сделан для иерархической модульной среды ЛВС. Среда использует резервные генераторы и системы UPS для всех сетевых компонентов и должным образом управляет питанием. Организация не использует VoIP и не хочет влиять на время переключения ПО. Оценки:

    • Доступность аппаратного пути между с двумя окончаниями указывает = доступность на 99.99 процентов

    • Доступность ПО с использованием надежности ПО GD в качестве эталона = 99,9999 процентов доступности

    • Связанный со средой и доступность питания с резервными системами = доступность на 99.999 процентов

    • Отказ соединения в среде локальной сети = доступность на 99.9999 процентов

    • Время перехода системы в другой режим, не разложенное на множители = 100-процентная доступность

    • Доступность ошибки пользователя и процесса предполагается идеальной = 100 процентов

    Окончательный уровень доступности, которого должны добиваться организации, равен 0,9999 X 0,999999 X 0,999999 X 0,999999 = 0,999896 или 99,9896 процентов доступности. Если мы разлагаем на множители в потенциальной недоступности вследствие пользователя или ошибки процесса и предполагаем, что недостаток 4X доступность в связи с к техническим факторам, мы могли предположить, что бюджет доступности составляет 99.95 процентов.

    Анализ этого примера показывает, что доступность локальной сети в среднем попадает в интервал 99,95 - 99,989 процентов. Данные значения могут использоваться в качестве цели уровня обслуживания для организации сети. Можно получить дополнительно значение, посчитав работоспособность в системе и определив процентность неготовности вследствие каждой их указанных выше шести областей. Это позволяет организации должным образом оценивать поставщиков, операторов связи, процессы и персонал. С помощью этого числа также можно получить математические ожидания для организации. Если количество недопустимо, то дополнительные ресурсы бюджета для получения нужных уровней.

    Для менеджеров сети может быть полезно понять продолжительность простоя на любом определенном уровне доступности. Время простоя в минутах за один год при любом заданном уровне готовности составляет:

    Минуты времени простоя через один год = 525600 - (Уровень X 5256 доступности)

    При использовании уровня доступности 99.95 процентов это выясняет, чтобы быть равным 525600 - (99.95 X 5256), или 222.8 минуты времени простоя. Для вышеупомянутого определения готовности это равно средней величине времени простоя для всех соединений в обслуживании в сети.

Шаг 3. Создайте профили приложения

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

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

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

  • Имя приложения

  • Тип приложения

  • Новое приложение?

  • Важность для работы

  • Требования доступности

  • Протоколы и порты используются

  • Предполагаемая пользовательская полоса пропускания (кбит/с)

  • Количество и расположение пользователей

  • Требования передачи файла (включая время, громкость, и оконечные устройства)

  • Влияние выхода сети из строя

  • Задержка, дрожание, и требования доступности

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

Шаг 4. Определите стандарты доступности и производительности

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

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

  1. Определите географическое или области применения, где будут применены сервисные стандарты.

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

  2. Определите сервисные стандартные параметры.

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

После определения областей обслуживания и параметров службы используйте информацию от предыдущих шагов до сборки матрица стандартов служб. Организация будет также требовать к областям define, которые могут сбить с толку группам IT и пользователям. Например, максимальное время отклика будет очень отличаться для кругового эха - запроса, чем для того, чтобы поразить Клавишу Enter в удаленном местоположении для определенного приложения. Следующая таблица показывает поставленные задачи в Соединенных Штатах.

Network Area Цель доступности Метод измерения Средняя цель времени отклика сети Принятое время отклика Max Метод измерения времени отклика
LAN 99.99% Impacted user minutes До 5 мс 10 мс Ответ на двусторонний эхо-тест
WAN 99.99% Impacted user minutes До 100 мс (круговой эхо-тест) 150 мс Ответ на двусторонний эхо-тест
Важная глобальная сеть и экстрасеть 99.99% Impacted user minutes До 100 мс (круговой эхо-тест) 150 мс Ответ на двусторонний эхо-тест

Шаг 5. Определите сетевую службу

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

  • Опишите реактивное, и профилактический процесс имел обыкновение достигать цели уровня обслуживания

  • Как будут управлять сервисным процессом

  • Как будут измерены цель службы и сервисный процесс.

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

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

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

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

Определения уровня обслуживания с обратной связью

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

Степени серьезности ошибки 1 Степени серьезности ошибки 2 Степени серьезности ошибки 3 Важность 4
Серьезный пользователь LAN воздействия на бизнес или сегмент сервера вниз Критический узел WAN вниз Высокое воздействие на бизнес через потерю или ухудшение, возможный обходной путь в Локальной сети уровня кампуса места вниз; 5-99 пользователей влияли на сайт Внутренней сети WAN вниз Международный сайт WAN вниз влияние Критической производительности Некоторые определенные функции сети потеряны или ухудшены, такие как производительность Локальной сети уровня кампуса потери избыточности повлиял на потерянную избыточность LAN (локальной сети передачи данных) Функциональный запрос или отказ, который не имеет никакого воздействия на бизнес для организации

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

Уровень поддержки Ответственность Цели
Разделите 1 Поддержку на уровни Полностью занятые поддержки вызова Ответа поддержки справочного стола, разместите ярлыки проблемы, работайте на проблему до 15 минут, билет документа и передайте к соответствующему уровню 2 поддержки Разрешение 40% входящих вызовов
Разделите 2 Поддержки на уровни Мониторинг очереди, управление сетями, мониторинг станции Размещает ярлыки проблемы для Внедрения идентифицированных проблем программного обеспечения, Принимают звонки от уровня 1, поставщик, и разделяют 3 роста на уровни, Принимают владение вызова до разрешения Разрешение 100% заходит в уровень 2 уровня
Уровень 3 поддержки Должен предоставить непосредственную поддержку для разделения на уровни 2 для всего приоритета, которому 1 проблема Соглашается помочь со всеми проблемами, нерешенными уровнем 2 в периоде разрешения SLA Никакое прямое проблемное владение

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

Важность проблемы Ответ справочного стола Отклик уровня 2 Местный уровень 2 Замена оборудования Решение проблемы
1 Мгновенное повышение приоритета для разделения на уровни 2, менеджер функционирований сети 5 минут 2 часа 2 часа 4 часа
2 Мгновенное повышение приоритета для разделения на уровни 2, менеджер функционирований сети 5 минут 4 часа 4 часа 8 часов
3 15 минут 2 часа 12 часов 24 часа 36 часов
4 15 минут 4 часа 3 дня 3 дня 6 дней

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

Время работы (астрономическое) Степени серьезности ошибки 1 Степени серьезности ошибки 2 Степени серьезности ошибки 3 Важность 4
5 минут Менеджер функционирований сети, разделите на уровни 3 поддержки, блок управления сетью      
1 час Обновление до диспетчера сетевых операций, поддержки уровня 3, директора работы с сетями. Обновление до диспетчера сетевых операций, поддержки уровня 3, директора работы с сетями.    
2 часа Эскалируйте к VP, обновлению управляющему узлу, диспетчеру операций      
4 часа Анализ корневой причины для VP, директор, диспетчер сетевых операций, поддержка яруса 3, неразрешенная нужная нотификация CEO Эскалируйте к VP, обновлению управляющему узлу, диспетчеру операций    
24 часа     Менеджер функционирований сети  
5 дней       Менеджер функционирований сети

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

В следующей таблице показан способ измерения организацией возможностей и общего эффекта от активной поддержки.

Network Area Коэффициент превентивной идентификации проблемы Реактивное соотношение распознавания ошибки
LAN 80% 20%
WAN 80% 20%

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

Определения уровня профилактического обслуживания

Больше комплексной методологии для того, чтобы создать определения уровня обслуживания включает больше подробности о том, как сеть проверена и как организация работы реагирует на станцию управления определенной сети (NMS) пороги на 7 x 24 основания. Это может показаться невыполнимой задачей, учитывая количество переменных MIB и количество данных для управления сетью, необходимых для работы сети. Это могло также быть чрезвычайно дорого и потребляющие ресурсы. К сожалению эти объекты не дают многим пользователям использовать упреждающее определение параметров обслуживания, которое должно быть простым, легким в использовании и применяемом только к наивысшим рискам потери производительности или готовности в сети. Если организация тогда видит значение в основных упреждающих определениях параметров обслуживания, больше переменных может быть добавлено в течение долгого времени без значительного влияния, пока вы внедряете поэтапный подход.

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

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

Сетевое устройство или Выключенная ссылка Метод обнаружения 5 x 8 Уведомлений уведомление 7 x 24 5 x 8 Разрешений разрешение 7 x 24
Основной ЛВС Опрос устройств и каналов SNMP, ловушки NOC создает ярлык проблемы, ДЕЖУРНУЮ СИСТЕМУ МГНОВЕННОГО ОБМЕНА СООБЩЕНИЯМИ В ЛОКАЛЬНОЙ СЕТИ страницы Дежурная система мгновенного обмена сообщениями в локальной сети автостраницы, дежурный по сети LAN создает ярлык проблемы для очереди основного ЛВСа Аналитик LAN назначил в течение 15 минут NOC, восстановлением согласно сервисному ответному определению Приоритеты 1 и 2 немедленных анализа и решения Приоритеты 3 и 4 очереди для разрешения на следующий день
Внутренняя сеть WAN Опрос устройств и каналов SNMP, ловушки NOC создает ярлык проблемы, сообщение дежурной системы мгновенного обмена сообщениями в глобальной сети Дежурная система мгновенного обмена сообщениями в глобальной сети автостраницы, дежурные сети WAN создают ярлык проблемы для очереди WAN Аналитик WAN назначается NOC в течение 15 минут, восстановление согласно определению ответа службы. Приоритеты 1 и 2 немедленных анализа и решения Приоритеты 3 и 4 очереди для разрешения на следующий день
Экстрасеть Опрос устройств и каналов SNMP, ловушки NOC создает ярлык проблемы, систему мгновенного обмена сообщениями Партнера страницы Система мгновенного обмена сообщениями партнера по автостранице, партнерское лицо режима работы создает ярлык проблемы для партнерской очереди Аналитик партнера назначается NOC в течение 15 минут, восстановление согласно определению ответа службы Немедленное расследование и разрешение приоритетов 1 и 2 Приоритеты 3 и 4 - в очередь для решения вопроса на следующий день

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

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

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

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

  • Ярус 1, ярус 2 и ярус 3 поддерживают ответственность

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

  • Требования к обучению, гарантирующие, что специалисты службы поддержки смогут эффективно работать с определенными оповещениями.

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

  • Документация относительно определенных сообщений или предупреждений, который помогает с идентификацией событий в уровне 1 уровню поддержки

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

s.

Категория ошибки Метод обнаружения Threshold Принятые меры
Ошибки программного обеспечения (сбои, вызванные программным обеспечением) Ежедневный анализ сообщений системного журнала использует средство просмотра системного журнала, Сделанное уровнем 2 поддержки Любое событие для приоритета 0, 1, и 2 более чем 100 вхождений уровня 3 или выше Проанализируйте проблему, составьте уведомление о неисправности и при ее повторении отправьте его в службу поддержки.
Аппаратные ошибки (сбои, вызванные аппаратными средствами) Ежедневный анализ сообщений системного журнала использует средство просмотра системного журнала, Сделанное уровнем 2 поддержки Любое событие для приоритета 0, 1, и 2 более чем 100 вхождений уровня 3 или выше Проанализируйте проблему, составьте уведомление о неисправности и при ее повторении отправьте его в службу поддержки.
Ошибки протокола (Только протоколы IP-маршрутизации) Ежедневный анализ сообщений системного журнала использует средство просмотра системного журнала, Сделанное уровнем 2 поддержки Сообщения о приоритетах (десять на каждый день) 0, 1, и 2 более чем 100 вхождений уровня 3 или выше Проанализируйте проблему, составьте уведомление о неисправности и при ее повторении отправьте его в службу поддержки.
Ошибки управления средой передачи (только FDDI, POS, и Fast Ethernet) Ежедневный анализ сообщений системного журнала использует средство просмотра системного журнала, Сделанное уровнем 2 поддержки Сообщения о приоритетах (десять на каждый день) 0, 1, и 2 более чем 100 вхождений уровня 3 или выше Проанализируйте проблему, составьте уведомление о неисправности и при ее повторении отправьте его в службу поддержки.
Сообщения об условиях работы (питание и температура) Ежедневный анализ сообщений системного журнала использует средство просмотра системного журнала, Сделанное уровнем 2 поддержки Любое сообщение Создайте ярлык проблемы и диспетчеризируйте для новых проблем
Ошибки точности (связывают ошибки ввода), Последовательный опрос SNMP в 5-минутных Пороговых событиях интервалов получен NOC Ошибки ввода или вывода Одна ошибка в любом 5-минутном интервале на любой ссылке Создайте ярлык проблемы для новых проблем и диспетчеризируйте для разделения на уровни 2 поддержки

Другие определения уровня категории активного обслуживания применены к производительности и емкости. Управление производительностью и пропускной способностью включает в себя управление исключениями, сбор данных и тенденций, а также анализ "что-если". Определение уровня обслуживания просто определяет производительность и пределы исключения емкости и средние пороги, которые будут инициировать исследование или обновление. Эти пороги могут затем некоторым образом применяться к процессам управления всеми тремя производительностями и пропускной способностью.

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

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

  • Четкое представление требований производительности приложения

  • Всестороннее техническое исследование на пороговых значениях, которые целесообразно для организации на основе потребностей бизнеса и общих затратов

  • Бюджетный цикл и требования к обновлению out-of-cycle

  • Ярус 1, ярус 2 и ярус 3 поддерживают ответственность

  • Приоритетность и важность данных, используемых для управления сетью, с учетом объема профилактических работ, с которым рабочая группа можно эффективно справляться.

  • Требования к подготовке, чтобы гарантировать, что персоналы технической поддержки понимают сообщения или предупреждения и могут эффективно иметь дело с определенным условием

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

  • Документация относительно определенных сообщений или предупреждений, который помогает с идентификацией событий в уровне 1 уровню поддержки

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

Область сети / среды Метод обнаружения Threshold Принятые меры
Магистраль локальной сети уровня кампуса и каналы распространения Последовательный опрос SNMP в 5-минутном исключении RMON интервалов поймал в ловушку на ядре и каналах распространения 50%-ое использование в 5-минутном использовании 90% интервалов через trap-сообщение исключения Уведомление по электронной почте Группе псевдонима электронной почты производительности для оценки требования QoS или плана обновляет для повторяющихся проблем
Ссылки внутренней сети WAN Опрос по протоколу SNMP с пятиминутными интервалами 75% загрузка в 5-минутных интервалах Уведомление по электронной почте Группе псевдонима электронной почты производительности для оценки требования QoS или плана обновляет для повторяющихся проблем
Каналы WAN экстрасети Опрос по протоколу SNMP с пятиминутными интервалами 60%-ое использование в 5-минутных интервалах Уведомление по электронной почте Группе псевдонима электронной почты производительности для оценки требования QoS или плана обновляет для повторяющихся проблем

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

         
Cisco 7500: ЦПУ, память, буферы Последовательный опрос SNMP в - 5-минутное Уведомление rmon интервалов для ЦПУ ЦПУ в 75% во время 5-минутных интервалов, 99% через Память Уведомления rmon в 50% во время 5-минутных Буферов интервалов при 99%-ом использовании Уведомление по электронной почте к производительности и группе псевдонима электронной почты емкости для решения вопросов или ЦПУ RMON обновления плана в 99% разместите ярлык проблемы, и страница разделяют 2 пейджера поддержки на уровни
Cisco 2600 ЦПУ, память Опрос по протоколу SNMP с пятиминутными интервалами ЦПУ в 75% во время 5-минутной Памяти интервалов в 50% во время 5-минутных интервалов Уведомление по электронной почте к производительности и группе псевдонима электронной почты емкости для решения вопросов или обновления плана
Catalyst 5000: Использование объединительной платы, память Опрос по протоколу SNMP с пятиминутными интервалами Объединительная плата в 50%-ой Памяти использования при 75%-ом использовании Уведомление по электронной почте к производительности и группе псевдонима электронной почты емкости для решения вопросов или обновления плана
Коммутатор ATM LightStream® 1010 ЦПУ, память Опрос по протоколу SNMP с пятиминутными интервалами ЦПУ в 65%-ой Памяти использования при 50%-ом использовании Уведомление по электронной почте к производительности и группе псевдонима электронной почты емкости для решения вопросов или обновления плана

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

Область сети / среды Метод измерения Threshold Принятые меры
Локальная сеть уровня кампуса Ни один Никакая проблема не ожидал Трудный измерить всю инфраструктуру LAN (локальной сети) 10-миллисекундная задержка в сети (время распространения пакета до адресата и обратно) или менее постоянно Уведомление по электронной почте к производительности и группе псевдонима электронной почты емкости для решения вопроса или обновления плана
Ссылки внутренней сети WAN Текущее измерение от SF до NY и SF в Чикаго только использует эхо - запрос ICMP Интернет-монитора производительности (IPM) За 5-минутный период усреднена задержка в сети (время распространения пакета до адресата и обратно) с 75 миллисекундами Уведомление по электронной почте группе псевдонима электронной почты производительности для оценки требования QoS или плана обновляет для повторяющихся проблем
Из Сан-Франциско в Токио Текущее измерение от Сан-Франциско до Брюсселя использует IPM и эхо - запрос ICMP За 5-минутный период усреднена задержка в сети (время распространения пакета до адресата и обратно) с 250 миллисекундами Уведомление по электронной почте группе псевдонима электронной почты производительности для оценки требования QoS или плана обновляет для повторяющихся проблем
Сан-Франциско в Брюссель Текущее измерение от Сан-Франциско до Брюсселя использует IPM и эхо - запрос ICMP За 5-минутный период усреднена задержка в сети (время распространения пакета до адресата и обратно) с 175 миллисекундами Уведомление по электронной почте группе псевдонима электронной почты производительности для оценки требования QoS или плана обновляет для повторяющихся проблем

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

  • определения и измерение уровней обслуживания позволяют избежать конфликтов между группами;

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

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

В следующей таблице приведено определение простого уровня обслуживания для производительности приложения.

Приложение Метод измерения Threshold Принятые меры
Порт TCP Приложения планирования ресурсов в масштабе предприятия (ERP) 1529 Брюссель к SF Брюссель в Сан-Франциско использует шлюз Брюсселя производительности приема-передачи порта измерения IPM 1529 года для шлюза SFO 2 За 5-минутный период усреднена задержка в сети (время распространения пакета до адресата и обратно) с 175 миллисекундами Уведомление по электронной почте группе псевдонима электронной почты производительности для оценки проблемы или плана обновляет для повторяющихся проблем
Порт TCP ERP - приложения 1529 Токио к SF Брюссель в Сан-Франциско использует шлюз Брюсселя производительности приема-передачи порта измерения IPM 1529 года для шлюза SFO 2 За 5-минутный период усреднена задержка в сети (время распространения пакета до адресата и обратно) с 200 миллисекундами Уведомление по электронной почте группе псевдонима электронной почты производительности для оценки проблемы или плана обновляет для повторяющихся проблем
Порт TCP Приложения Службы поддержки пользователей 1702 Сидней к SF Сидней в Сан-Франциско использует шлюз Сидней производительности приема-передачи порта измерения IPM 1702 года для шлюза SFO 1 За 5-минутный период усреднена задержка в сети (время распространения пакета до адресата и обратно) с 250 миллисекундами Уведомление по электронной почте группе псевдонима электронной почты производительности для оценки проблемы или плана обновляет для повторяющихся проблем

Шаг 6. Соберите метрики и монитор

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

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

Создание и поддержание SLA

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

SLA предоставляют несколько преимуществ:

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

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

  • Документированный SLA создает средство для настраивания ожидаемого уровня обслуживания.

Рекомендуются следующие шаги для построения SLA после создания определений уровней служб: Рекомендуются следующие шаги для построения SLA после создания определений уровней служб:

7. Встретьте предварительные условия для SLA.

8. Определите участвующие стороны в SLA.

9. Определите элементы обслуживания.

10. Учет бизнес-целей и требований клиента

11. Определите SLA, требуемый для каждой группы.

12. Выберите формат SLA

13. Разработайте рабочие группы SLA

14. Встречи рабочей группы Ожидания и проект SLA.

15. Выполните согласование о SLA.

16. Измерьте и контролируйте соответствие SLA.

Шаг 7. Встретьте предварительные условия для SLA

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

  • Бизнес должен иметь культуру, ориентированную на обслуживание.

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

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

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

  • Клиент/предпринимательские инициативы должен вести все действия IT.

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

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

  • Необходимо передать Процесс sla и договор.

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

Шаг 8. Определите участвующие стороны в SLA

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

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

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

  • Совещание коммерческих целей поддержки, основанной на реагировании на происшедшие события

  • Обеспечение высшего уровня доступности путем определения упреждающих SLA

  • Предложение или продажа услуг

Шаг 9 Определите элементы обслуживания

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

  • Внутрифилиальная поддержка графика работы и процедуры для поддержки нерабочего времени.

  • Определения приоритетов, включая тип проблемы, максимальное время для начала работают на проблему, максимальное время для решения проблемы, и процедур эскалации

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

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

  • Географический или проблемы уровня поддержки служебного подразделения и требования

  • Методология и процедуры устранения проблем (системы регистрации вызовов)

  • Цели справочного стола

  • Обнаружение ошибок сети и сервисный ответ

  • Измерение доступности сети и сообщение

  • Пропускная способность сети и измерение производительности и сообщение

  • Процедуры разрешения конфликтов

  • Финансирование внедренного SLA

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

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

  • Требования пропускной способности и возможности пакета

  • Требования к производительности

  • Определения и требования QoS

  • Требования доступности и избыточность к плану решения сборки

  • Отслеживая и сообщая требования, методологию, и процедуры

  • Критерии обновления для приложения/элементов обслуживания

  • Финансирование требований out-of-budget или перекрестная зарядка методологии

Например, можно создать категории решения для возможностей подключения узла WAN. "Платиновое решение" предусматривает двойные службы T1 для узла. Другой носитель предоставил бы каждую линию T1. В узле должно быть два настроенных маршрутизатора, чтобы при сбое на любом T1 или маршрутизаторе узел не выходил из строя. Золотая служба имела бы два маршрутизатора, но резервный маршрутизатор Frame Relay будет использоваться. Это решение может обеспечивать ограниченную пропускную способность во время сбоя. "Серебряное решение" включает один маршрутизатор и одну службу доставки. Любой из этих решений был бы рассмотрен для других уровней приоритета для проблемных билетов. Для некоторых организаций могут потребоваться "платиновое" или "золотое" решение, если при сбое необходимо уведомление с приоритетом 1 или 2. Пользовательские организации могут тогда финансировать уровень обслуживания, которого они требуют. В следующей таблице показан пример организации, предлагающей 3 уровня обслуживания, в зависимости от потребностей предприятия в подключении к внешней сети.

Решение: Платина Золото Серебро
Устройства Резервные маршрутизаторы для подключения к WAN Избыточный маршрутизатор для резервного копирования на центральном узле. Никакая избыточность устройства
WAN Избыточное подключение T1, несколько несущихи Подключение T1 с Резервным копированием Frame Relay Никакая избыточность WAN
Требования пропускной способности и пакет Резервный Т1 с распределенной загрузкой для пакета Нераспределение нагрузки, Резервное копирование Frame Relay для критически важных приложений только; Frame Relay 64 K CIR только Подключение к T1
Производительность Непротиворечивая задержка в сети (время распространения пакета до адресата и обратно) на 100 мс или меньше Время отклика менее 100мс ожидается с вероятностью 99.9% Время отклика 100 мс или менее ожидаемые 99%
Требования доступности 99.99% 99.95% 99.9%
Приоритет справочного стола когда Выключенный Приоритет 1 критически важная для бизнеса служба не работает Приоритет 2 влияющая на бизнес служба не функционирует Приоритет 3: деловая связь вниз

Шаг 10: Основные сведения о потребностях и целях заказчиков

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

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

Шаг 11: Определите SLA, требуемый для каждой группы

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

Другие служебные подразделения в организации будут иметь другие требования. Одной из задач сети SKA должно быть соглашение на общий формат, соответствующий различным уровням обслуживания. Эти требования являются обычно доступностью, QoS, производительностью, и MTTR. В SLA (соглашение об уровне обслуживания) сети эти переменные обрабатываются путем расположения по приоритетам бизнеса - приложений для потенциальной настройки QoS, определения приоритетов службы справки для MTTR других влияющих на сеть проблем, и разработки плана решения, который поможет обрабатывать другую доступность и требования к производительности. Пример матрицы простого решения для производственной компании предприятия может смотреть что-то как следующая таблица. Можно добавить сведения о доступности, QoS и производительности.

Служебное подразделение Приложения Стоимость простоя Приоритет проблемы в нерабочем состоянии Требования к серверу и сети
Производство ERP Высоко 1 Максимальная избыточность
Служба поддержки пользователей Пользовательская поддержка Высоко 1 Максимальная избыточность
Разработка Файловый сервер, дизайн ASIC Среда 2 Резервирование основных компонентов LAN
Маркетинг Файловый сервер Среда 2 Резервирование основных компонентов LAN

Шаг 12: Выберите Format SLA

Формат для SLA может изменяться в соответствии с желаниями группы или требованиями организации. Придерживающееся является рекомендуемой структурой в качестве примера для SLA (соглашение об уровне обслуживания) сети:

  1. В целях соглашения

    • Стороны, участвующие в соглашении

    • Цели и цели соглашения

  2. Предоставляемые услуги и поддерживаемые продукты

    • Служба службы справки и отслеживание вызовов

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

    • Приоритеты для определений QoS критически важной службы для бизнеса

    • Определенные категории решения на основе доступности и требований к производительности

    • Требования к подготовке

    • Требования планирования мощности

    • Требования эскалации

    • Сообщение

    • Сетевые решения предоставлены

    • Новое решение запрашивает

    • Неподдерживаемые продукты или приложения

  3. Политика предприятия

    • Поддержка во время рабочих часов

    • Внеурочные определения поддержки

    • Обеспечение в выходные дни

    • Номера контактного телефона

    • Прогнозирование объема работы

    • Разрешение жалобы

    • Критерии права доступа к сервису

    • Ответственности обеспечения безопасности группы и пользователя

  4. Процедуры управления проблемными ситуациями

    • Инициация вызова (пользователь и автоматизированный)

    • Ответ первого уровня и вызов восстанавливают соотношение

    • Отслеживание вызовов и рекордное хранение

    • Обязанности вызывающего абонента

    • Диагностика проблемы и требования закрытия вызова

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

    • Категории или определения решения проблемы

    • Хроническая обработка задач

    • Критическая проблема / обработка вызова исключения

  5. Задачи по обеспечению качества обслуживания

    • Определения качества

    • Определения измерения

    • Задачи по обеспечению качества

    • Среднее время для инициирования устранения проблемы приоритетом проблемы

    • Среднее время решения проблемы приоритетом проблемы

    • Среднее время для замены аппаратных средств приоритетом проблемы

    • Доступность сети и производительность

    • Управление емкостью

    • Управление ростом

    • Отчет о качестве

  6. Набор персонала и формирование бюджета

    • Модели кадрового обеспечения

    • Бюджет на разработку проекта

  7. Техническое обслуживание по соглашению

    • Список анализа соответствия

    • Сообщающая производительность и анализ

    • Согласование отчетной метрики

    • Периодические обновления SLA

  8. Утверждения

  9. Присоединения и вещественные доказательства

    • Диаграммы потока вызовов

    • Матрица расширения

    • Матрица сетевого решения

    • Примеры отчетов

Шаг 13 Разработайте рабочие группы SLA

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

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

Шаг 14 Встречи рабочей группы Ожидания и проект SLA

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

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

Шаг 15: Выполните согласование о SLA

Последний этап в создании SLA – окончательное согласование и выход из системы. Этот шаг включает:

  • Рассмотрение проекта

  • Выполнение согласование о содержании

  • Редактирование и пересмотр документа

  • Окончательное утверждение получения

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

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

Шаг 16: Измерьте и контролируйте соответствие SLA

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

Следующий раздел предоставляет дополнительные сведения на том, как управление в организации может оценить свои SLA и свой полный Service Level Management.

Индикаторы производительности управления на уровне служб

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

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

Например, рассмотрите придерживающийся реальный сценарий. Компания X получала жалобы многочисленных пользователей, что сеть часто не работала для длительных периодов времени. Путем измерения доступности компания нашла, что основная проблема была несколькими сайтами WAN. Детальное изучение тех достопримечательностей показало, что большинство проблем было на нескольких сайтах WAN. Основная причина была найдена, и организация решила проблему. Затем организация задает цели уровня обслуживания по доступности и заключает соглашения с группами пользователей. Идентифицированные проблемы будущих измерений быстро из-за несоответствия к SLA. Группа организации сети тогда просматривалась как наличие более высокого профессионализма, знаний и опыта, и общего ценного вклада к организации. Фактически группа из группы реагирования стала группой упреждения и помогла компании добиться практических результатов.

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

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

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

  • Метрики указателя эффективности, включая доступность, производительность, время ответа сервиса в зависимости от приоритета, время до принятия решения в зависимости от приоритета, а также другие измеримые параметры SLA

  • Ежемесячные заседания руководящего состава уровня сетевой службы для рассмотрения соответствия уровня обслуживания и улучшений внедрения

Задокументированное соглашение об уровне обслуживания или определение уровня обслуживания

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

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

Реактивные вторичные цели включают:

  • Время ответа службы в зависимости от приоритета вызова

  • Цели при решении проблем или среднее время восстановления

  • Процедуры эскалации проблемы

Дополнительные цели профилактики включают:

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

  • Обнаружение ошибок сети

  • Емкость или обнаружение проблемы производительности.

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

Цель

  • Как будет измерена цель

  • Стороны, ответственные за измерение доступности и производительности

  • Стороны, ответственные за обеспечение плановой доступности и производительности

  • Процессы несоответствия

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

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

  • Определения приоритета проблемы

  • Время ответа службы в зависимости от приоритета вызова

  • Цели при решении проблем или среднее время восстановления

  • Процедуры эскалации проблемы

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

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

Метрики индикатора производительности

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

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

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

Другие успешные методы калькуляции – использование уведомлений о неисправности и измерение, называемое сжатые минуты пользователя (IUM). Этот метод записывает количество пользователей, которых затронул сбой, и умножает его на количество минут длительности сбоя. Если выразить как процентное содержание общего числа минут за временной период, то это легко преобразовать в коэффициент готовности. В любом случае может также быть полезно определить и измерить основную причину времени простоя так, чтобы могло быть более легко предназначено улучшение. Категории корневых причин включают в себя проблемы оборудования, проблемы программного обеспечения, проблемы канала или носителя, проблемы питания или среды, отказы изменения, а также пользовательские ошибки.

Измеримые цели поддержки включают:

  • Время ответа службы в зависимости от приоритета вызова

  • Цели при решении проблем или среднее время восстановления

  • Время эскалации проблемы

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

  • Время исходного отчета о вызове (или регистрации в базе данных):

  • Время, когда вызов был принят лицом, работающим над проблемой.

  • Время проблема передавалось

  • Время проблема было закрыто

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

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

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

Обзор управления служебного уровня

Другой мерой успеха Service Level Management является анализ Service Level Management. Это необходимо сделать независимо от того, приняты ли соглашения об уровне обслуживания SLA. Проведите обзор управления уровнем обслуживания на ежемесячной встрече с сотрудниками, ответственными за измерение и предоставление определенных уровней обслуживания. Когда SLA включены, группы пользователей могут также присутствовать. Цель собрания – оценить производительность определений измеряемого уровня обслуживания и внести улучшения.

Каждое совещание должно иметь определенную программу, которая включает:

  • Обзор измеренных уровней обслуживания для данного периода

  • Рассмотрение инициатив по улучшению, разработанных для отдельных областей.

  • Текущие метрики уровня обслуживания

  • Обсуждение того, какие улучшения необходимы на основе текущего набора метрик.

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

Сводка управления уровнем обслуживания

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

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 15117