мониторинг sla что это
Мониторинг качества связи с помощью технологии IP SLA
Мониторинг наличия и качества связи является важным инструментом администратора сети, т.к. он позволяет не только обнаруживать проблему, но и предвидеть возникновение самой проблемы.
В Cisco IOS встроены несколько тестов для определения состояния сети которые объдинены понятием SLA.
Вообще SLA расшифровывается как Service Level Agreements, что можно перевести как соглашения об уровне обслуживания.
На сегодняшний день SLA поддерживает следующие тесты:
dhcp DHCP Operation
dns DNS Query Operation
ethernet Ethernet Operations
ftp FTP Operation
http HTTP Operation
icmp-echo ICMP Echo Operation
icmp-jitter ICMP Jitter Operation
path-echo Path Discovered ICMP Echo Operation
path-jitter Path Discovered ICMP Jitter Operation
tcp-connect TCP Connect Operation
udp-echo UDP Echo Operation
udp-jitter UDP Jitter Operation
voip Voice Over IP Operation
Применение одной из них (icmp-echo) описано в статье Автопереключение между двумя провайдерами.
На качество голоса влияет несколько параметров одновременно:
End-to-end (one way) delay: Это задержка пакета в одну сторону. Должно быть максимум 150ms
Jitter: Разные пакеты могут приходить с разными задержками, эту флуктуацию и определяет параметр jitter. Должно быть максимум 30ms
Packet loss: Потери пакетов должны быть максимум 1%
Эти параметры можно посмотреть на телефоне прямо во время звонка двумя способами:
— Зайти на страницу телефона: Streaming Statistics > stream 1
— Дважды нажать на кнопку «?» на телефоне
Возможны различные комбинации значений этих трех параметров. Например, как показывает практика, вполне можно говорить если End-to-end (one way) delay составляет 200ms, а остальные параметры идеальны. Но совершенно невозможно говорить если Jitter стабильно более 100, даже если остальные два параметра идеальны.
Тест IP SLA Jitter позволяет их всех привести к «общему знаменателю», типа можно говорить или нельзя. Этими едиными параметрами является MoS или ICPIF.
В тесте IP SLA Jitter используется Service Assurance Agent (Cisco SAA). Его работа заключается в симулировании голосового кодека и последующим определением End-to-end (one way) delay, Jitter, Packet loss. По этим параметрам Cisco SAA затем вычисляет MOS и ICPIF.
MOS и ICPIF используются для оценки качества связи и могут быть определены автоматически в результате теста Jitter.
Рассмотрим возможные значения.
ICPIF
5 Very Good
10 Good
20 Adequate
30 Limiting case
45 Exceptional limiting case
55 Customers likely to react strongly
MOS
5 Excelent
4 Good
3 Fair
2 Poor
1 Bad
Как показала практика, наибольшую полезность представляет ICPIF
Реализация
На одном конце
ip sla responder
ip sla 10
udp-jitter 172.16.127.33 20001 source-ip 172.16.127.4 codec g711ulaw codec-size 20
tos 184
frequency 300
ip sla schedule 10 life forever start-time now
access-list 5 permit 192.168.2.49
snmp-server community cmonitor RW 5
snmp-server ifindex persist
На другом конце
ip sla responder
access-list 5 permit 192.168.2.49
snmp-server community cmonitor RW 5
snmp-server ifindex persist
Смотрим текущее значение IP SLA:
show ip sla statistics
SLA на облако: как читать и на что обратить внимание
Сегодня хочу поговорить о том, как читать Service Level Agreement в договоре на облачные сервисы. SLA – это норма: клиенты требуют его на этапе запроса, провайдеры указывают заветные девятки во всех материалах. Отрицать не буду – без SLA плохо, но какие зоны ответственности затрагивает соглашение, не всегда понятно. Попробуем разобраться, что же это такое и когда бежать к провайдеру, размахивая договором, а когда искать проблему на месте.
Простой пример: у клиента перестает работать ВМ, клиент сразу думает, что проблема в инфраструктуре. И смотрит, что же там в SLA по поводу доступности. А может, на самом деле зависла ОС, клиентская сеть лагает, — предположить можно всё что угодно. Если проблема внутри ОС, то провайдер ресурсов тут не поможет.
Если мы не администрируем клиентские виртуальные машины, то и приложения внутри для нас – черный ящик. При этом самые частые отказы находятся как раз на стороне приложения. Может случиться что угодно: переполнятся диски, учетные записи заблокируются, DNS откажет, компоненты приложения перестанут взаимодействовать из-за неправильных настроек. А может оказаться, что системное время выставлено неверно или установилось ненужное обновление. Такие проблемы не являются нарушением SLA и решаются на стороне клиента. Так когда же он действует?
SLA – что это такое и для чего
SLA – это своего рода гарантийный талон на услугу. Но это не просто пункт с девятками в основном договоре. Это развернутое приложение, в котором фиксируются все параметры оказываемой услуги. Правильно составленное приложение страхует и клиента, и сервис-провайдера.
В SLA содержатся гарантированные значения основных параметров предоставления услуг. Важный момент: гарантированные – значит не ниже. Так, в SLA на виртуальную инфраструктуру учитываются показатели до операционной системы на клиентской ВМ. Операционная система и приложения внутри ВМ – забота администратора клиента. Если что-то сломалось, первым делом проверьте у себя. Поверьте, если поломается сама инфраструктура, то провайдер узнает об этом раньше вас через мониторинг.
В хорошем SLA на виртуальную инфраструктуру должны быть:
Доступность
Доступность – это те самые девятки, которые чаще всего выдаются за SLA. Проценты доступности переводятся в минуты и часы недоступности сервиса в месяц или год.
| Доступность | Простой в месяц | Простой в год |
|---|---|---|
| 99% | 7 час. 18 мин. 17,5 сек. | 3 дня 15 час. 39 мин. 29.5 сек. |
| 99,9% | 43 мин. 49,7 сек. | 8 час. 45 мин. 57 сек. |
| 99,95% | 21 мин. 54,9 сек. | 4 часа 22 мин. 58,5 сек. |
| 99,982% | 7 мин. 53,4 сек. | 1 час 34 мин. 40,3 сек. |
Все варианты можно посмотреть здесь.
Казалось бы, всё понятно, в чем же подвох?
Месяц или год. Не зря я наверху выбрал две колонки – месяц и год. Когда видите заветные девятки в SLA, обратите внимание, к какому периоду они относятся. Чаще всего провайдеры говорят о месяце. То есть при доступности 99% мы получаем 7 с лишним часов даунтайма в месяц, а не в год. Уточняйте этот момент, чтобы потом не было разочарований.
Девятки и инфраструктура. Если вам необходим определенный уровень отказоустойчивости сервиса, то и виртуальная инфраструктура должна быть построена таким образом, чтобы эту доступность обеспечивать. Так, для достижения уровня доступности 99,95% вам, как минимум, понадобится кластер active-passive. Если вы хотите перешагнуть за 99,982% (уровень доступности в дата-центрах Tier III), вам нужно строить систему, распределенную по нескольким ЦОД.
Выбирая конфигурацию виртуальной инфраструктуры, ответьте себе на вопрос: нужны ли вам пять девяток? Девятки не должны быть самоцелью. Во-первых, чем больше девяток, тем дороже для вас будет стоить система. Каждая следующая честная девятка будет добавлять нолик справа к стоимости! Во-вторых, не каждый сервис требует геораспределенного кластера.
Если вы выбираете облачные ресурсы, определитесь, какую задачу вы решаете сейчас: строите тестовую среду или холодный резерв или размещаете критические сервисы – интернет-магазин, платежную систему или CRM.
Совокупная доступность. Если ваше приложение имеет доступность 99,5%, облако имеет доступность 99,95%, а дата-центр, где оно развернуто, – 99,982%, то на выходе вы будете иметь доступность не выше 99,5%. Так как доступность всего сервиса не может быть выше доступности самого слабого его звена. Помните об этом при выборе сервиса и не пытайтесь лечить перелом подорожником. Защищенный геораспределенный кластер не спасет падающее через день приложение.
Не доступностью единой
Доступность для ИТ-сервисов – главный параметр. Но и при стопроцентном аптайме виртуальная машина может жестко тупить из-за сетевых задержек, недостаточного количества IOPS, высокой latency СХД и прочих проблем. Поэтому в правильном SLA должны быть все качественные метрики по инфраструктуре. На что смотреть и к чему стремиться?
секунды. Поэтому норма для этого параметра – в пределах от 0 до 1%. Как и в случае с сетевой задержкой, уточните у провайдера, где заканчивается его ответственность.
В SLA также следует прописать способы измерения и мониторинга по каждому параметру. Например, так:
Запросы, инциденты и технические работы
Сначала разведем понятия запрос и инцидент. Запрос – это заявки на штатные работы. Инцидент – когда что-то сломалось и не работает, например: машина сильно тупит или не пингуется. Если что-то сломалось у провайдера, то уведомление об инциденте приходит из системы мониторинга. Все запросы и инциденты разделяются по приоритетам. Это позволяет быстро реагировать на вопросы жизни и смерти и чинить все вовремя. Важно определить статус заявки на этапе ее регистрации. Как это устроено у нас, мы рассказывали в статье о службе поддержки.
Решение инцидентов. Все возможные поломки не предугадать. Но типовые причины недоступности сервиса должны быть прописаны в SLA. Еще раз отмечу, что соглашение затрагивает только неполадки на стороне провайдера и не распространяется на ошибки внутри ВМ. Все инциденты делятся по приоритетам, в зависимости от того, ведут они к полной недоступности сервиса или к частичной деградации. На каждый приоритет определяется максимальный срок устранения.
Если используете разные типы дисков, не забудьте прописать инциденты по каждому из них:
Пример инцидентов первого приоритета.
В нашем SLA на IaaS мы делим инциденты на три приоритета. Каждый обрабатывается в круглосуточном режиме, но время на исполнение разное.
Уточните у провайдера, как он считает время на исполнение инцидента, и проверьте, чтобы это было прописано в приложении. Как правило, временем исполнения считается время от уведомления клиента о регистрации инцидента и до момента его решения.
Кроме того, SLA может ограничивать число заявок, которое вы можете открыть у провайдера в месяц.
Обработка запросов. Все верно: в хорошем SLA прописано время на обработку запросов. Это нужно для того, чтобы правильно расставить приоритеты и не проморгать отключение сервиса за рутинными задачами. И защитить провайдера. Так как речь не идет об остановке сервиса, то в этот раздел часто не вчитываются, а зря. Именно здесь зафиксировано, что запросы принимаются в рабочие часы провайдера и на их решение отводится не меньше 12 часов.
Мы делим запросы на три типа, которые отличаются по характеру работ и времени исполнения:
Проведение регламентных работ и уведомление. Инфраструктура – это живой организм. Ее нужно обслуживать: апгрейдить, накатывать критические обновления, проводить плановые работы (например, обновлять прошивку на серверах). Не все работы можно сделать без остановки сервиса. Поэтому в SLA фиксируется порядок уведомления о таких работах, время проведения работ и возможное время перерыва в сервисе. Проверяйте, чтобы срок уведомления о плановых работах был достаточным и было зафиксировано максимальное время остановки сервиса.
У нас это выглядит так:
Наложение штрафных санкций. Штрафные санкции бывают двух типов: за превышение времени реакции на инцидент и за простой сервиса, в нашем случае виртуальной инфраструктуры. Чем подробнее описан порядок наложения санкций, тем безопаснее чувствуют себя и клиент, и провайдер. Если условия не понятны, задавайте провайдеру вопросы до подписания соглашения, чтобы не было сюрпризов и разочарований.
Если в SLA есть все описанные выше пункты, то вы получаете сервис с прозрачными гарантиями и уровнем доступности. Врать в SLA невыгодно, так как от штрафов отбрехаться не получится. Но и подогнать под SLA поломки из-за косных приложений или неправильной настройки ВМ не удастся.
Если есть вопросы, традиционно жду в комментариях. Здорового вам облака!
Для чего нужен SLA и что кроется под заветными процентами
Что такое SLA
Service Level Agreement (SLA) часто встречается в описании преимуществ облачных провайдеров. Его можно назвать гарантией качества услуги. Термин появился благодаря руководству ITIL, самому распространённому документу по управлению ИТ-услугами. С его помощью компании во всём мире упорядочивают свои бизнес-процессы. Встречается SLA и в стандарте COBIT, регламентирующем большинство процессов облачных провайдеров, контроль их выполнения и взаимодействие с клиентами.
SLA — это полноценный документ, в котором фиксируются параметры оказываемой провайдером услуги. От традиционного договора SLA отличается детально прописанным уровнем доступности сервиса и скорости реакции на проблемы, которые могут возникнуть у клиента провайдера.
SLA определяет гарантированный уровень качества предоставляемой провайдером услуги. То есть ниже, чем зафиксировано в договоре, сервис быть не может. На разные сервисы могут прописываться разные Соглашения об уровне обслуживания. Условия тоже могут отличаться. Например, SLA на виртуальную инфраструктуру распространяется строго до ОС клиентской виртуальной машины. То, что внутри ВМ — касается только клиента и его ИТ-службы. Соответственно при каком-либо сбое начинать проверку надо с собственной системы. Потому что поломку инфраструктуры провайдер увидит раньше вас с помощью систем мониторинга.
Кому выгоден SLA и в чём его особенности
Наличие SLA — это норма для любого облачного провайдера. Клиенты часто уточняют цифры на этапе знакомства с компанией, а провайдеры гордо указывают заветные девятки в своих промо-материалах. При этом не всегда понятно, чем может быть полезен документ и в каких случаях нужно срочно обращаться к провайдеру, а в каких — разбираться самостоятельно.
Как мы уже сказали, клиентские ВМ — это своеобразная закрытая зона для провайдера. Но при этом большинство сбоев происходит именно там. Переполнение дисков, блокировка учётных записей, сбои из-за глючного обновления или неправильной настройки приложений — эти проблемы не подпадают под SLA. Их решают силами клиента. Нередко — с привлечением сотрудников провайдера, но уже в рамках отдельных договорённостей.
Соглашение об уровне обслуживания фиксирует следующие требования:
Соглашение об уровне обслуживания имеет ещё одну важную особенность: измеряемость. Все критерии, прописанные в Соглашении, имеют цифровые значения. Так, допустимое время простоя сервисов и сроки устранения проблем указываются в минутах.
Получается, что SLA выгоден обеим сторонам. Облачный провайдер защищён от необоснованных требований, а клиент получает гарантии, что возникший инцидент будет решён в конкретные временные рамки.
Время реакции на инциденты и другие цифры
Раз уж мы заговорили про контроль сроков и время реакции на инциденты, давайте рассмотрим этот вопрос детальнее.
Время реакции на инциденты в SLA — это числовая метрика, которая охватывает период времени с момента поступления или регистрации тикета об инциденте до момента его закрытия. Она не равна времени простоя, так как является составляющей её длительности. Математически всё это выглядит так:
Время инцидента = Время реакции на произошедшее + Время решения инцидента
Если реакция на инцидент или общее время простоя выше зафиксированного в SLA, это может грозить провайдеру выплатой неустойки. Поэтому облачные провайдеры строго следят за соблюдением сроков и внедряют новые технологические решения, позволяющие добиться нужного уровня доступности.
Кстати, инциденты бывают разные. Условно говоря, критические, важные и типовые. Все запросы и инциденты разделяются по приоритетам, что позволяет провайдеру быстрее реагировать на действительно важные обращения и вовремя устранять неисправности. Все заявки обрабатываются в круглосуточном режиме, но время на исполнение у всех разное.
Доступность — это те самые девятки, которые показываются как SLA. И в них кроется особая магия. Посмотрите:
Время простоя за месяц
Время простоя за год
7 час. 18 мин. 17,5 сек.
3 дня 15 час. 39 мин. 29.5 сек.
8 час. 45 мин. 57 сек.
4 часа 22 мин. 58,5 сек.
1 час 34 мин. 40,3 сек.
Вы заметили, как с ростом процентной точности снижается время простоя? 99% — это почти 4 дня простоя в год, а заявленные Cloud4Y 99,982% — всего полтора часа. Разница по времени колоссальная, хотя по цифрам — меньше 1 процента.
И тут встречается хитрость со стороны провайдера, когда в договоре он указывает время простоя не за год, а за месяц. Обязательно уточняйте этот момент, чтобы потом не получить неприятный сюрприз.
От чего зависят проценты? От организации инфраструктуры провайдера. Определённый уровень отказоустойчивости сервиса напрямую зависит от того, как построена виртуальная инфраструктура. Уровень доступности в 99,95% требует от провайдера наличия как минимум одного кластера active-passive. Показатель 99,982% дают распределённые системы с использованием нескольких ЦОДов Tier III. У Cloud4Y для обеспечения такого уровня доступности используется Hi-End оборудование корпоративного уровня, каждый элемент нашей инфраструктуры многократно дублируется, а информация передаётся по защищённым каналам и хранится в современных дата-центрах, расположенных в России и за рубежом.
Подчеркнём, что 99,99% и тем более 99,999% не должны быть самоцелью. Во-первых, такой уровень доступности будет стоить сильно дороже. Во-вторых, он не всегда нужен. Да, Cloud4Y может предложить некоторые сервисы с таким уровнем доступности. Но подавляющему большинству клиентов достаточно базового 99,982%.
Ещё один интересный нюанс — совокупная доступность. Она считается по наименьшему показателю. Если, к примеру, ваше приложение имеет доступность 99,95%, а дата-центр и облако, в котором оно развёрнуто — 99,982%, то общая доступность всё равно будет 99,95%. Всё определяется самым слабым звеном, не забывайте об этом. Нестабильное, часто сбоящее приложение не спасёт даже самое надёжное геораспределённое решение.
Чтобы снять все вопросы, приведём заявленный уровень доступности дата-центров разного уровня:
Уровень надежности ЦОД
Время простоя, часов в год
Что ещё может учитываться в SLA
Несомненно, доступность является самым важным параметром облачных ИТ-сервисов. Но виртуальные машины могут здорово потрепать нервы и при 100% доступности. Сетевые задержки, недостаточное количество IOPS, медленная СХД — эти и другие проблемы тоже нужно предусмотреть. Какие метрики нужно прописать в SLA?
Вместо заключения
SLA — это важный инструмент, удобный как для поставщика облачных услуг, так и для потребителя этих самых услуг. Если разобраться в деталях и понять, например, что означают сотые доли процента в метрике доступности, то у вас не будет завышенных ожиданий, но и уровень предоставляемого сервиса вы тоже сможете быстро оценить. В целом, можно перечислить следующие преимущества использования SLA для компании-клиента:
Рекомендации от экспертов. Блог Okdesk
В условиях всё нарастающей конкуренции работа над качеством услуг — неотъемлемая часть сервисного бизнеса. Поскольку какие-то усовершенствования невозможно себе представить без метрик и соглашений относительно этих метрик, мы приходим к идее SLA. Давайте обсудим, что это такое и зачем оно на самом деле нужно.
SLA — что это такое?
SLA (Service Level Agreement — соглашение об уровне обслуживания) — внешний документ (существующий между заказчиком и исполнителем), описывающий параметры предоставляемой услуги. «Соответствие SLA» эквивалентно тому, что сервис работает так, что реальные параметры не выходят за пределы заявленных в соглашении диапазонов метрик.
Хотя сам термин SLA появился в ИТ, сегодня такие документы используются для описания самых разных услуг, как в ИТ, так и в других сегментах B2B, например в обслуживании коммерческой недвижимости, при ремонте специализированного оборудования и т.п. В SLA определяются сроки устранения определенных неисправностей, скорость реакции на обращения, доступность службы поддержки и другие параметры.
Соглашения SLA активно применяются там, где исполнитель и заказчик услуг автономны по отношению друг к другу. И хотя соглашения внутри компании, которые заключаются для обеспечения SLA, зачастую его напоминают, для них применяется другой термин — OLA.
Что такое OLA
Для исполнения SLA с внешним клиентом сервисной компании необходимо следить за процессом оказания услуги внутри — устанавливать сроки ответа на обращения и т.п. Для этого формируется OLA — Operational Level Agreement — аналогичный SLA внутренний документ компании, определяющий зоны ответственности подразделений.
В OLA расписывается, как именно оказывается услуга — кто за нее ответственен, по каким правилам передается эта ответственность, какие метрики оцениваются, какие показатели должны соблюдаться. Фактически OLA определяет, как при оказании внешней услуги будут взаимодействовать отдельные группы и сотрудники сервисной компании.
Условия OLA должны соответствовать SLA или быть более жесткими, чтобы выступать гарантией соблюдения последнего, поэтому для формирования SLA сначала лучше продумать OLA, согласовав его с исполнителями. Если инженер физически не сможет добраться на объект быстрее, чем за 2 часа, вы не должны обещать клиенту, что решите его проблему за час.
Разница между SLA и OLA
Основное различие SLA и OLA в том, что первый документ описывает взаимодействие с внешним клиентом, а второй — работу подразделений внутри компании. И если SLA говорит на языке клиента и важных для него параметров сервиса («мы обеспечиваем доступность сервиса 99,8% времени»), то OLA погружается в технические детали и подробности взаимодействия отдельных подразделений и специалистов («диспетчер регистрирует заявку в течение 10 минут, инженер реагирует на нее в течение 2 часов, механик выезжает в течение 5 часов»).
Что должно быть в договоре SLA
SLA должен содержать описание предлагаемой услуги и определять границы ответственности.
Содержание SLA должно закрывать вопрос ответственности, ограничив область взаимодействия с пользователями только лишь заранее объявленными объектами или продуктами.
Также в SLA должно быть прописано, при каких условиях услуга считается оказанной (когда ответственность исполнителя прекращается).
Параметры, от которых зависит SLA
Помимо границ, в SLA прописываются параметры услуги и их допустимые колебания. Это должны быть измеримые параметры, которые может оценить клиент и сама сервисная компания — своего рода KPI, которым услуга должна соответствовать. В этом, кстати, отличие SLA от KPI. Хотя эти понятия часто путают, KPI — метрики сами по себе, а SLA — соглашение о том, какими они должны быть.
К примеру, в соглашении можно прописать, что специалист поддержки имеет право отвечать не мгновенно, а в течение 4-х часов после регистрации заявки. Он имеет право не отвечать в выходные и праздничные дни.
Чтобы SLA не превратилось в головную боль для всех заинтересованных сторон, важно указывать там реально достижимые параметры услуг, которые обе стороны трактуют одинаково.
В сервисном бизнесе самый распространенный параметр — время. Это может быть:
При упоминании того или иного параметра в SLA указывается конкретный показатель и при необходимости допустимые отклонения.
Мы не рекомендуем указывать в SLA слишком много параметров или использовать какие-то косвенные показатели, слабо коррелирующие с действиями исполнителя. Они только усложняют работу.
Параметры SLA определяют ожидания клиента и позволяют предложить несколько уровней сервиса. Например, за стандартную абонентскую плату инженер будет реагировать на обращение в течение суток, а для VIP-клиентов с более высокой стоимостью сервиса срок реакции будет сокращен до 4 часов. Важно, чтобы клиент четко понимал, за какой уровень сервиса он платит и чем этот уровень отличается от других.
Выбор правильных показателей для контроля, как выбор правильных метрик, требует опыта и понимания ситуации. К примеру, нельзя бездумно мотивировать сотрудников решать задачи клиента быстрее — так пострадает качество решения.
Договор SLA
Раз уж SLA определяет взаимодействие двух сторон — клиента и исполнителя — разберем, как соглашение работает для каждой из них.
Глазами клиента
В рамках SLA заказчик получает метрики предоставления услуги — четкое описание того, за что именно он платит.
Клиенту полезно, что в SLA прописываются сроки исполнения заявок (инцидентных или на обслуживание). Конечно, любой заказчик хочет, чтобы его вопрос решался мгновенно, но соглашение (особенно с несколькими уровнями сервиса) отлично демонстрирует, что «мгновенность» стоит денег, и иногда можно подождать несколько часов, чтобы сделать решение дешевле. Он получает достойный ответ на вопрос: «Почему моя проблема не решена вчера?».
Параметры качества, заложенные в SLA, позволяют сверять ожидания от услуги с реальностью. А кроме того заказчику важна ответственность исполнителя за несоблюдение заявленных параметров (вплоть до штрафов). SLA, в котором ответственности не прописано, — лишь декларация о намерениях. А заявленная ответственность повышает доверие Заказчика к поставщику услуг.
Глазами сервисной компании
С точки зрения сервисного отдела или компании SLA — это набор целевых метрик, к которым стремятся исполнители. SLA на самом деле очень полезно, т.к. наводит порядок не только во взаимоотношениях с клиентом, но и (по цепочке) в бизнес-процессах самой сервисной компании.
SLA может стать основой системы мотивации сотрудников. Тот факт, что указанные там параметры соблюдаются — повод похвалить сервисный отдел, заплатить премии его сотрудникам. А несоблюдение заявленных условий — причина начать внутреннее расследование и депремировать виновных. Важно, чтобы у Вас были инструменты, которые позволят контролировать соблюдение SLA и, в случае нарушения, оперативно находить причину или виновного.
Во взаимодействии с клиентом SLA помогает ограничить зону ответственности.
Как написать хороший SLA
Грамотно составленный SLA должен давать в руки клиента контроль над услугой, которую он получает. Желательно, чтобы при этом рычаги контроля были ему понятны — пункты соглашения должны однозначно трактоваться как заказчиком, так и исполнителем.
Пройдемся по основным положениям, которые стоит добавить в SLA.
Как и любой официальный документ, SLA должен четко определять, что входит в само понятие «услуга», кто именно ее оказывает и в чем она заключается. Поэтому начать стоит с определений услуг, ролей и спецтерминов. Эта часть должна отвечать на следующие вопросы:
SLA должен содержать понятные клиенту метрики услуги, характеризующие ее качество. Конкретные примеры метрик зависят от сферы деятельности компании. В сервисном бизнесе зачастую берут за основу время решения проблемы.
Важно, чтобы исполнитель полностью определял соответствие услуги этим метрикам (имел на них влияние). Если вы обслуживаете только кассы, нельзя привязываться в SLA простой всей ИТ-инфраструктуры магазина, потому что в нее входят компоненты вне вашей зоны ответственности. Кассу-то, может, вы и запустили, но если при этом в помещении отключено электричество, сделать ничего нельзя. Поэтому лучше сосредоточиться на конкретных метриках, определяющих именно вашу услугу — скорость восстановления работы кассы после остановки.
Метрики должны быть реалистичными. Если в примере с кассой установить в SLA скорость ремонта в 10 минут, скорее всего соглашение просто не будет работать. Более реалистичное, но короткое время, заставит привлекать опытных специалистов, которые в среднем работают с задачами быстрее. А это стоит денег. В этом смысле SLA — это поиск баланса между интересами клиента, который хочет «вчера», и исполнителя, который не может быстрее (или может, но в ущерб другим клиентам).
Метрик не нужно много. Большое количество метрик запутает исполнителя, он не сможет нормально расставить приоритеты в своей собственной работе, боясь выйти за рамки по какой-то из метрик.
Если в оказании услуги участвует несколько отделов и хочется прописать метрики для каждого, это можно сделать в OLA, задав в SLA только один общий параметр, в который уложится вся последовательность действий. Или задать несколько версий этой метрики в SLA, в зависимости от подключения к решению проблемы новых участников (условно говоря, если проблема уходит на третий уровень поддержки, то допустимое время реакции увеличивается на сутки).
Пример договора SLA
Ниже представлен пример договора SLA реальной IT-компании.
I. Предоставляемые услуги
В этом разделе мы описываем все работы, которые «IT-консалт» выполняет для Заказчика, и системы, которые находятся у нас на поддержке. По каждому виду работ определяется график и ограничения объема услуг, если они есть. Отдельно оговариваются те работы, которые не входят в нашу зону ответственности.
Исполнитель обязуется оказывать Заказчику услуги по сопровождению программного обеспечения 1С 8 ERP, установленного у Заказчика, на следующих инсталляциях:
Период оказания услуг — с «___» _______ ____ г. — «___» _______ ____ г.
Перечень услуг по сопровождению, время предоставления и ограничения по объему оказываемых услуг указан в таблице:
| Услуга | Время предоставления* | Объем услуг |
| Консультации пользователей по работе с ПО, помощь в решении проблем в части бизнес-процессов: — Приемка на склад — Отгрузка готовой продукции | 24/7 | Не ограничен |
| Консультации пользователей по работе с ПО, помощь в решении проблем в части прочих бизнес-процессов | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Контроль выполнения регулярных процедур по согласованным регламентам | 24/7 | Не ограничен |
| Мониторинг интеграций с системами Меркурий, EDI, восстановление работоспособности интеграций | 24/7 | Не ограничен |
| Мониторинг и поддержание работоспособности сервера приложений | 24/7 | Не ограничен |
| Ведение пользовательской документации (обновление документации при изменениях в ПО, ведение раздела «FAQ») | Ежемесячно | Не ограничен |
| Выдача и изменение пользовательских прав, ролей (по заявкам ключевых пользователей или службы безопасности) | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Эскалация вопросов, не относящихся к области компетенции Исполнителя (администрирование инфраструктуры, администрирование БД) | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Исправление ошибок в программном коде ПО | С 9:00 по 18:00 в рабочие дни | Не ограничен |
| Доработка ПО в соответствии с бизнес-требованиями Заказчика | С 9:00 по 18:00 в рабочие дни | Не более 40 плановых часов в месяц ** |
| Обновление систем на новые версии, поставляемые производителем ПО | С 9:00 по 18:00 в рабочие дни | Не более 2 раз в год |
* Время часового пояса Москвы.
** Плановые часы — часы на выполнение модификации, включая постановку задачи, кодирование, тестирование и перенос модификации на рабочее приложение; плановые часы являются оценкой Исполнителя, в обязательном порядке согласуются с ответственным представителем ИТ-службы Заказчика. Риск превышения фактического времени над плановым находится на стороне Исполнителя. Время на модификации не переносится из периода в период.
В перечень услуг, оказываемых Исполнителем, не входят следующие задачи:
Способы взаимодействия пользователей Заказчика и Исполнителя:
Конкретные почтовые адреса, телефоны и учетные записи для Service Desk определяются в регламенте взаимодействия.
II. Ответственность Заказчика
Здесь мы описываем то, что нам нужно для эффективного выполнения работы — доступы, координатор со стороны заказчика, и так далее. Самое важное в этом разделе — монопольный доступ к коду системы с нашей стороны. Если монопольного доступа нет, после возникновения каких-то проблем можно «не найти концов». Если мы отвечаем за приложение, к нам в дальнейшем все вопросы, но мы должны его контролировать.
Заказчик имеет право:
III. Приоритеты и нормативное время решения заявок
В этом разделе мы описываем принципы очередности выполнения заявок поддержкой, включая разбивку бизнес-процессов Заказчика по степени критичности. Здесь же описывается нормативное среднее время решения заявок и предельная доля тех заявок, которые не уложились в нормативное время.
Приоритет заявок определяется дежурным специалистом Исполнителя, исходя из бизнес-процесса, по которому поступила заявка от пользователя ПО, и характера заявки. Нормативное среднее время выполнения заявок и максимально допустимая доля заявок, время выполнения которых не уложилось в нормативное время, представлена в таблице:
| № | Приоритет | Среднее время решения заявки | Доля просроч. заявок | Виды заявок |
| 1 | Критический | Не более 2 рабочих часов | Не более 20% | Нарушения в работе ПО, которые приводят к неработоспособности одной или нескольких инсталляций в целом. |
Мониторинг и поддержание работоспособности сервера приложений
— Отгрузка готовой продукции
Эскалация вопросов, не относящихся к области компетенции Исполнителя (администрирование инфраструктуры, администрирование БД)
Контроль выполнения регулярных процедур по согласованным регламентам
Мониторинг интеграций с системами Меркурий, EDI, восстановление работоспособности интеграций
Выдача и изменение пользовательских прав, ролей
Обновление систем на новые версии, поставляемые производителем ПО
Ведение пользовательской документации (обновление документации при изменениях в ПО, ведение раздела «FAQ»)
По взаимному соглашению сторон приоритет заявки может быть изменен как в большую, так и в меньшую стороны.
Время решения заявки рассчитывается как разница между датой/временем решения заявки и датой/временем регистрации заявки в ServiceDesk, за вычетом периодов нерабочего времени (в соответствии с графиком предоставления услуг в разделе I) и за вычетом времени нахождения заявки на стороне пользователя:
Доля просроченных заявок рассчитывается как отношение количества заявок данного приоритета, время решения которых больше нормативного, к общему количеству заявок данного приоритета.
IV. Отчетность по услугам
Раздел определяет формат и частоту предоставления отчетов для Заказчика
Отчеты предоставляются Исполнителем Заказчику в табличном формате, в электронном виде и используются Заказчиком для оценки качества предоставляемых услуг.
Отчеты по количественным показателям (раздел III) содержат следующую информацию, в разбивке по приоритетам:
Отчеты по количественным показателям предоставляются Исполнителем ежемесячно до 5 числа каждого месяца. Указанные отчеты оформляются как приложения к актам выполненных услуг, подписываются Исполнителем и Заказчиком.
Дополнительно к количественным показателям Исполнитель собирает информацию о качественном восприятии сервиса. Дважды в год Исполнитель проводит опрос пользователей на предмет удовлетворенности следующими факторами:
Отчеты по качественным показателям содержат информацию по удовлетворенности пользователей, в разбивке по ролям пользователей, а также описание принимаемых мер по улучшению показателей.
Отчеты по качественным показателям предоставляются Исполнителем дважды в год, до 20 июня и до 20 декабря.
Координатор самостоятельно проводит анализ полученной отчетности. В случае необходимости, Координатор может инициировать проведение совещания рабочей группы с представителями Исполнителя услуг по анализу отчетности.
V. Методика оценки качества сервиса
В этом разделе мы определяем то, как мы измеряем качество сервиса. Мы приводим перечень метрик качества, как количественных, так и качественных, и определяем вес (важность) каждой метрики, исходя из бизнеса клиента
Исполнитель обязуется ежемесячно рассчитывать итоговый показатель качества сервиса (QoS), на основании следующего расчета:
| Метрика | Вес метрики |
| Среднее время выполнения заявок 1 приоритета меньше нормативного | 0,1 |
| Доля просроченных заявок 1 приоритета меньше нормативной | 0,1 |
| Среднее время выполнения заявок 2 приоритета меньше нормативного | 0,15 |
| Доля просроченных заявок 2 приоритета меньше нормативной | 0,15 |
| Среднее время выполнения заявок 3 приоритета меньше нормативного | 0,05 |
| Доля просроченных заявок 3 приоритета меньше нормативной | 0,05 |
| Среднее время выполнения заявок 4 приоритета меньше нормативного | 0,05 |
| Доля просроченных заявок 4 приоритета меньше нормативной | 0,05 |
| Доля ответов «Быстрее, чем рассчитывал», «Как и рассчитывал» на вопрос анкеты «Насколько быстро, по Вашему мнению, решаются Ваши проблемы» больше 70% * | 0,1 |
| Доля ответов «Да», «Чаще да» на вопрос анкеты «Снимаются ли Ваши проблемы в работе с системой службой поддержки?» больше 80% * | 0,1 |
| Доля ответов «Да», «Чаще да» на вопрос анкеты «Было ли обращение сотрудников службы поддержки с Вами вежливым?» больше 90% * | 0,1 |
* По данным последнего проведенного опроса пользователей
Итоговый показатель качества (QoS) рассчитывается как сумма весов по тем метрикам, которые были выполнены в периоде.
Исполнитель самостоятельно, без согласования с Заказчиком, определяет необходимый трудовой ресурс специалистов поддержки, консультантов и разработчиков для выполнения указанных метрик.
VI. Стоимость услуг, штрафные санкции и условия оплаты
Основной пункт в этом разделе — это расчет штрафных санкций, которые «IT-консалт» применяет к месячному акту в том случае, если нарушаем метрики качества.
Стоимость услуг Исполнителя составляет ________ (___________) рублей в месяц, без учета НДС.
В случае нарушения показателей качества стоимость услуг уменьшается пропорционально штрафным санкциям, согласно следующей таблице:
| QoS от | QoS до | Штрафные санкции, в % от стоимости услуг |
| 0,8 | 1 | 0% |
| 0,6 | 0,79 | 5% |
| 0,4 | 0,59 | 10% |
| 0 | 0,39 | 20% |
Штрафные санкции могут быть начислены начиная с 3-го месяца оказания услуг. Первые два месяца являются ознакомительным периодом, в котором Исполнитель нарабатывает компетенцию в приложении Заказчика.
В случае изменения объема услуг и/или количества инсталляций, стоимость договора может быть пересмотрена как в большую, так и меньшую сторону.
Стоимость дополнительного сервиса, оказываемого по требованию Заказчика:
Стоимость дополнительного сервиса будет включаться в месячный акт отдельными строками.
Оплата услуг производится Заказчиком путем перечисления денежных средств на расчетный счет Исполнителя в течение 10 (десяти) рабочих дней, исчисляемых с первого числа месяца, следующего за месяцем, в котором Сторонами был подписан без замечаний Акт приема-передачи услуг.
Как работать по SLA?
Схема работы по готовому соглашению предельно понятна:
Отметим, что соблюдать SLA проще, если процессы в сервисной компании отлажены. Помогают этому различные инструменты автоматизации, в частности, Help Desk.