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

Управление сервисным обслуживанием: лучшая Белая книга методов

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


Содержание


Введение

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

Управленческий обзор сервисного обслуживания

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

Критические факторы успеха

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

Дополнительную информацию см. в управлении Сервисного обслуживания Осуществления.

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

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

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

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

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

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

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

Посмотрите управление Сервисного обслуживания Осуществления для получения дополнительной информации.

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

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

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

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

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

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/15117-highlevel.gif

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

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

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

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

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

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

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

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

  3. Создайте прикладные особенности сети детализации профилей важных приложений.

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

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

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

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

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

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

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

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

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

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

  • Текущий транспортный груз или прикладное поведение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • 1 - (полное время отключения электричества связи) / (полное штатное время связи)

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

  2. Отсутствие

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

  3. Наличие аппаратных средств

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

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

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

  5. Экологический и доступность власти

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

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

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

  6. Связь или неудача перевозчика

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

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

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

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

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

  7. Проектирование сети

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

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

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

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

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

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

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

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

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

  9. Определение окончательного бюджета доступности

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

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

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

    • Доступность программного обеспечения с помощью надежности программного обеспечения GD в качестве ссылки = доступность на 99.9999 процентов

    • Экологический и доступность власти с резервными системами = доступность на 99.999 процентов

    • Неудача связи в окружающей среде LAN = доступность на 99.9999 процентов

    • Системное время переключения не factored = 100-процентная доступность

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

    Окончательный бюджет доступности, за который должны бороться организации, равняется 0.9999 X 0.999999 X 0.999999 X 0.999999 = 0.999896, или доступность на 99.9896 процентов. Если мы, фактор в потенциальном недостатке из-за пользователя или ошибки процесса и предполагает, что недостаток 4X доступность из-за технических факторов, мы могли предположить, что бюджет доступности составляет 99.95 процентов.

    Этот анализ в качестве примера указывает тогда, что доступность LAN упала бы в среднем между 99.95 и 99.989 процентами. Эти числа могут теперь использоваться в качестве цели сервисного обслуживания для сетевой организации. Можно получить дополнительную стоимость путем измерения доступности в системе и определения того, чем процент недостатка происходил из-за каждой из вышеупомянутых шести областей. Это позволяет организации должным образом оценивать продавцов, перевозчики, процессы и штат. Число может также использоваться для урегулирования ожиданий в пределах бизнеса. Если число недопустимо, то бюджет дополнительные ресурсы для получения желаемых уровней.

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

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

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

Шаг 3: создайте прикладные профили

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

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

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

  • Прикладное название

  • Тип применения

  • Новое применение?

  • Деловая важность

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

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

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

  • Число и местоположение пользователей

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

  • Сетевое воздействие отключения электричества

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

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

Шаг 4: определите стандарты доступности и работы

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

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

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

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

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

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

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

Сетевая область Цель доступности Метод измерения Средняя сетевая цель времени отклика Принятое время отклика Макса Метод измерения времени отклика
LAN 99.99% Затронутые пользовательские минуты Под 5 мс 10 мс Ответ звона туда и обратно
БЛЕДНЫЙ 99.99% Затронутые пользовательские минуты Под 100 мс (звон туда и обратно) 150 мс Ответ звона туда и обратно
Критический WAN и Extranet 99.99% Затронутые пользовательские минуты Под 100 мс (звон туда и обратно) 150 мс Ответ звона туда и обратно

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

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

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

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

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

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

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

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

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

Реактивные определения сервисного обслуживания

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

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

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

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

Сетевая область Превентивное проблемное идентификационное отношение Реактивное проблемное идентификационное отношение
LAN 80% 20%
БЛЕДНЫЙ 80% 20%

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

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

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

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

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

Сетевое устройство или связь вниз Метод обнаружения 5 x 8 Уведомлений 7 x 24 Уведомления 5 x 8 Резолюций 7 x 24 Резолюции
Основной LAN Устройство SNMP и опрос связи, ловушки NOC создает заявку на устранение неисправности, пейджер ОБЯЗАННОСТИ LAN страницы Авто страница пейджер обязанности LAN, человек обязанности LAN создает заявку на устранение неисправности для основной очереди LAN Аналитик LAN назначил в течение 15 минут NOC, ремонтом согласно сервисному определению ответа Приоритеты 1 и 2 непосредственных расследования и Приоритеты резолюции 3 и 4 очереди для утренней резолюции
Внутренний WAN Устройство SNMP и опрос связи, ловушки NOC создает заявку на устранение неисправности, страница пейджер обязанности WAN Авто страница пейджер обязанности WAN, человек обязанности WAN создает заявку на устранение неисправности для очереди WAN Аналитик WAN назначил в течение 15 минут NOC, ремонтом согласно сервисному определению ответа Приоритеты 1 и 2 непосредственных расследования и Приоритеты резолюции 3 и 4 очереди для утренней резолюции
Extranet Устройство SNMP и опрос связи, ловушки NOC создает заявку на устранение неисправности, пейджер обязанности партнера по странице Авто пейджер обязанности партнера по странице, человек обязанности партнера создает заявку на устранение неисправности для очереди партнера Аналитик партнера назначил в течение 15 минут NOC, ремонтом согласно сервисному определению ответа Приоритеты 1 и 2 непосредственных расследования и резолюция; Приоритеты 3 и 4 очереди для утренней резолюции

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

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

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

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

  • Ряд 1, ряд 2 и ряд 3 обязанности по поддержке

  • Балансирование приоритета сетевой информации об управлении с суммой превентивной работы, с которой может эффективно обращаться операционная группа

  • Учебные требования для обеспечения технического персонала могут эффективно иметь дело с определенными тревогами

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

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

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

s.

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

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

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

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

  • Ясное понимание требований потребительских свойств

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

  • Бюджетный цикл и из цикла модернизирует требования

  • Ряд 1, ряд 2 и ряд 3 обязанности по поддержке

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 6: соберите метрики и монитор

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

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

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

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

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

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

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

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

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

7. Встретьте предпосылки для SLAs.

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

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

10. Поймите потребительские потребности бизнеса и цели

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

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

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

14. Проведите встречи рабочей группы и спроектируйте SLA.

15. Договоритесь о SLA.

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

Шаг 7: встретьте предпосылки для SLAs

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

  • Ваш бизнес должен иметь культуру для обслуживания широкого круга запросов.

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

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

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

  • Инициативы клиента/бизнеса должны стимулировать все действия IT.

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

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

  • Необходимо передать процесс SLA и контракт.

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

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

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

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

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

  • Достижение реактивных целей бизнеса поддержки

  • Обеспечение высшего уровня доступности путем определения превентивного SLAs

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

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

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

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

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

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

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

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

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

  • Цели сервисной службы

  • Сетевой ответ обнаружения ошибки и обслуживания

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

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

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

  • Финансирование осуществленного SLA

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

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

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

  • Эксплуатационные требования

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

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

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

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

  • Финансирование требований из бюджета или поперечная зарядка методологии

Например, можно создать категории решения для возможности соединения места WAN. Платиновое решение было бы предоставлено с двойными услугами T1 места. Различный перевозчик обеспечил бы каждую линию T1. Место имело бы два маршрутизатора формируемыми так, чтобы, если бы какой-либо T1 или маршрутизатор потерпели неудачу, место не испытывало бы отключение электричества. Золотое обслуживание имело бы два маршрутизатора, но сделало бы копию Ретрансляции кадров, будет использоваться. Это решение, возможно, ограничило полосу пропускания на время отключения электричества. Серебряное решение имело бы только один маршрутизатор и одно обслуживание перевозчика. Любое из этих решений рассмотрели бы для различных приоритетных уровней для проблемных билетов. Если приоритет 1 или 2 билета требуется для отключения электричества, некоторые организации могут потребовать платины или золотого раствора. Потребительские организации могут тогда финансировать уровень обслуживания, которого они требуют. Следующая таблица показывает пример организации, которая предлагает три уровня обслуживания, в зависимости от деловой потребности в extranet возможности соединения.

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

Шаг 10: поймите потребительские потребности бизнеса и цели

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

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

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

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

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

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

Шаг 12: выберите формат SLA

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

  1. Цель соглашения

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

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

  2. Услуги обеспечили и поддержанные продукты

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

    • Проблемные определения серьезности, основанные на деловом воздействии для определений MTTR

    • Деловые критические сервисные приоритеты для определений QoS

    • Определенные категории решения, основанные на доступности и эксплуатационных требованиях

    • Учебные требования

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

    • Требования подъема

    • Сообщение

    • Сетевые решения обеспечили

    • Новые запросы решения

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

  3. Деловая политика

    • Поддержка во время рабочего времени

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

    • Праздничное освещение

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

    • Прогнозирование рабочей нагрузки

    • Резолюция обиды

    • Сервисные дающие право критерии

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

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

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

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

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

    • Обязанности по посетителю

    • Проблемный диагноз и требования закрытия требования

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

    • Проблемные категории резолюции или определения

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

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

  5. Цели качества обслуживания

    • Качественные определения

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

    • Качественные цели

    • Среднее время для инициирования проблемной резолюции проблемным приоритетом

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

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

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

    • Руководящая способность

    • Руководящий рост

    • Качественное сообщение

  6. Укомплектование персоналом и бюджеты

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

    • Операционный бюджет

  7. Обслуживание соглашения

    • График обзора соответствия

    • Исполнительное сообщение и обзор

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

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

  8. Одобрения

  9. Приложения и выставки

    • Блок-схемы требования

    • Матрица подъема

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

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

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

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

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

Шаг 14: проведите встречи рабочей группы и спроектируйте SLA

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

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

Шаг 15: договоритесь о SLA

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

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

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

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

  • Получение заключительного одобрения

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

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

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

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

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

Управленческие показатели эффективности сервисного обслуживания

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

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

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

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

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

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

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

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

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

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

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

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

  • Реактивное сервисное время отклика приоритетом требования

  • Проблемные цели резолюции или MTTR

  • Проблемные процедуры подъема.

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

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

  • Сетевое обнаружение ошибки

  • Способность или исполнительное обнаружение задач.

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

Цель

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

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

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

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

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

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

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

  • Реактивное сервисное время отклика приоритетом требования

  • Проблемные цели резолюции или MTTR

  • Проблемные процедуры подъема

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

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

Метрики показателя эффективности

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

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

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

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

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

  • Реактивное сервисное время отклика приоритетом требования

  • Проблемные цели резолюции или MTTR

  • Проблемное время подъема

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

  • О времени требование первоначально сообщили (или вступили база данных),

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

  • Время проблема наращивалось

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

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

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

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

Управленческий обзор сервисного обслуживания

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

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

  • Обзор измеренного сервисного обслуживания в течение установленного срока

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

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

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

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

Управленческое резюме сервисного обслуживания

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

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

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


Соответствующая информация


Document ID: 15117