Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Быстрая разработка SLA

Быстрая разработка SLA

Подготовка соглашения об уровне сервиса — актуальная задача для многих ИТ-аутсорсинговых компаний. Alex Bewley редактор сайта ctoedge.com предлагает несколько советов о том, как быстро разработать SLA. Первая проблема с которой сталкиваются при подготовке SLA — люди не знают с чего следует начать. Достигнуть доступности в 99.999% слишком сложно, дорого и ненужно в большинстве случаев. Точно также для большинства приложений не требуется поддержка 24/7. Наилучшая отправная точка для формулирования SLA — исторические данные о доступности сервисов. То, что уже было оценено, как «достаточно хорошее», достаточно хорошо для SLA.

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

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

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

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

Полный текст статьи на сайте ctoedge.com

Дополнительные материалы

sla

Комментарии (5)

  • Аватар

    Рубинштейн Кирилл [krubinshteyn], 01 февраля 2011, 19:08

    1
    Фиксация параметров SLA по историческим данным (с целью "от чего-то отталкиваться") предложение правильное. Сам часто на ITSM проекта подобный вариант предлагал. Но вот в последнее время задумываюсь — не смахивает ли такой подход на игру в ITIL и прочий ITSM?

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

    А получается, что ИТ тут надумал себе поставить планку. Но нужна ли (реально, а не ради "чтоб была") эта планка бизнесу? Зачем ИТ такая зрелость, если бизнесу до неё ещё зреть и зреть?
    • Аватар

      Бычков Валерий [vbychkov], 01 февраля 2011, 19:54

      0
      Мне кажется тут наоборот, предполагается, что ИТ (внешняя или внутренняя) возьмет имеющийся сервис в том виде в каком он есть и на этом уровне поставит первую планку. А дальше да процесс непрерывного улучшения к заветным 5 девятками, или насколько у бизнеса хватит денег/потребностей.
    • Аватар

      Яковлев Андрей Михайлович [swtws], 02 февраля 2011, 10:18

      1
      В реале
      1.  Объяснить бизнесу что есть метрика и зачем она нужна. (Вообще-то KPI, состоящий из метрик, точнее будет)
      2. Если Вы предложите бизнесу выставить планку, он ее "задерет", а когда Вы проведете оценку, быстро заскучает.
      3. Текущий уровень лучше оценить  мониторингом 1-3 мес, главное обосновать оплату этого этапа в предпроектной подготовке. Договориться о первом пересмотре через  6 мес.
      4. После стабилизации перейти к отчетам по глобальным метрикам (например, "снижение числа инцидентов в год")
      4. Проходит очень туго, но могу похвастаться, есть несколько мест где механизм работает.
  • Аватар

    Катунин Михаил [RAKTAVARNA], 02 февраля 2011, 03:13

    1
    К сожалению слишком коротко о такой серьезной теме как разработка SLA.