Что такое Service Level Agreement

Что такое «Соглашение об уровне обслуживания», известное как SLA, какие метрики чаще всего содержит и почему будет полезно как компании-провайдеру услуг, так и организации-пользователю.

Как расшифровывается SLA

SLA (Service Level Agreement) дословно переводится как «Соглашение об уровне обслуживания (оказания услуги)», то есть это договор об уровне предоставляемого сервиса между компанией-провайдером и организацией-клиентом. Основное отличие SLA от обычного договора состоит в подробно прописанном уровне доступности сервиса и времени реакции на инциденты и раскрывает следующее:

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

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

Важно помнить, что использование SLA выгодно обеим сторонам:

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

Происхождение термина SLA

Термин SLA появился из методологии ITIL (англ. IT Infrastructure Library – библиотека инфраструктуры информационных технологий), которая помогает IT-компаниям упорядочивать свои бизнес-процессы.

SLA подробнее всего описывается в стандартах ITIL и COBIT (от англ. Control Objectives for Information and Related Technologies – «Задачи управления для информационных и смежных технологий»), используя которые компании-провайдеры регламентируют большинство своих процессов и выстраивают процедуры дальнейшего контроля выполнением этих процессов и взаимодействием с клиентами.

Для чего нужно SLA

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

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

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

Что включает в себя типовой SLA

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

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

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

При описании уровня качества сервиса, важно указать в SLA такие параметры, как:

  • доступность самого сервиса;
  • время реакции на инцидент;
  • время решения инцидента.

Если речь идет об оплате сервиса, то указывается следующее:

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

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

Параметры, от которых зависит SLA

Параметры, из которых состоит SLA – это измеримые метрики, отвечающие за уровень качества предоставления услуги. Условно эти метрики можно называть «KPI» для SLA.

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

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

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

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

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

Доступность услуги

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

В качестве примера доступности услуги рассмотрим уровень надежности дата-центров Tier. Для каждого из четырех уровней дата-центров задана конкретная доступность в процентном эквиваленте.

Доступность сервиса невозможна на 100%. Значение доступности в процентах стремиться к 100% и выражается в виде количества «девяток» процента доступности. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток», а доступность в 99,95% — может обозначаться как «три с половиной девятки».
Уровень надежности дата-центраУровень доступности (%)Время простоя (часов в год)
Tier I99,671%28,8
Tier II99,749%22,0
Tier III99,982%1,6
Tier IV99,995%0,4 (24 минуты)

Кстати, на примере доступности дата-центров учитывается только время простоя, в то время как значения остальных основных параметров заданы по умолчанию. При размещении сервера в Selectel, в стоимость входят:

  • мощность 300 Вт;
  • выделенный IP-адрес;
  • ширина интернет-канала 1 Гбит/с.

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

Время реакции на инциденты

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

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

Время реакции на инцидент + Время решения проблемы = Время жизни инцидента

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

Оценка результата

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

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

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

  • низкий — проблемы в функционировании одного из модулей сервиса;
  • средний — проблемы в работе и взаимодействии нескольких модулей сервиса;
  • высокий — неработоспособность большей части сервиса.

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

SLI и SLO

SLI (Service Level Indicator) – это количественная оценка работы сервиса, которая является корреляцией между ожиданиями пользователей и действительной производительностью сервиса за указанный период времени (месяц, квартал, год).

SLI можно рассматривать в качестве индикатора пользовательского опыта, измеряя его в процентном эквиваленте, где:

  • 100 % — отличный пользовательский опыт;
  • 0% — ужасный пользовательский опыт.

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

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

SLO (Service Level Objectives) – это значение SLI, которого компания-провайдер хотела бы достичь. При установке SLO рекомендуется указывать реально достижимое значение для каждого конкретного SLI. SLO показывает, с каким качеством фактически работает сервис и/или приложение, в отличие от SLA, который используется для того, чтобы задать тот уровня доступности сервиса, на который смогут ориентироваться все пользователи.

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

Плюсы использования SLA для заказчиков и исполнителей

Организация-заказчик:

  • получает услугу на необходимом и достаточном уровне и знает, за какой именно уровень качества платит;
  • может контролировать сроки выполнения заявок;
Конечно, любая организация-заказчик хотела бы мгновенной реакции на заявки, но если услуга предоставляется в нескольких комплектациях и скорость решения инцидентов может требовать большей оплаты (то есть «мгновенность» стоит дороже), иногда организация-заказчик может принять решение подождать несколько часов, чтобы сделать решение заявки дешевле.

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

Компания-провайдер:

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

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

Вместо заключения

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

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

Что еще почитать по теме

Кирилл Филипенко 14 сентября 2022

Увеличиваем FPS в аниме с помощью нейросети и GPU Tesla T4

Рассказываем про технологию интерполяции и ее практическое применение с помощью облачных серверов с GPU.
Кирилл Филипенко 14 сентября 2022
Ульяна Малышева 25 августа 2022

CDN против DDoS-атак: в каких случаях это действительно работает

Рассказываем про неочевидное преимущество CDN — услуга повышает безопасность инфраструктуры за счет защиты от DDoS-атак.
Ульяна Малышева 25 августа 2022
T-Rex 24 августа 2022

IT-инфраструктура организации: понятие, типы и функции

Рассказываем об IT-инфраструктуре предприятия и ее компонентах для малого, среднего и крупного бизнеса.
T-Rex 24 августа 2022

Новое в блоге

Михаил Фомин 24 июня 2022

Docker Swarm VS Kubernetes — как бизнес выбирает оркестраторы

Рассказываем, для каких задач бизнесу больше подойдет Docker Swarm, а когда следует выбрать Kubernetes.
Михаил Фомин 24 июня 2022
Ульяна Малышева 30 сентября 2022

«Нулевой» локальный диск. Как мы запустили облако только с сетевыми дисками и приручили Ceph

Чем хороши сетевые диски и почему именно Ceph, рассказал директор по развитию ядра облачной платформы Иван Романько.
Ульяна Малышева 30 сентября 2022
Валентин Тимофеев 30 сентября 2022

Как проходит онбординг сотрудников ИТО? Что нужно, чтобы выйти на смену в дата-центр

Рассказываем, как обучаем новых сотрудников, какие задачи и испытания проходят инженеры прежде, чем выйти на свою первую смену.
Валентин Тимофеев 30 сентября 2022
T-Rex 28 сентября 2022

Книги по SQL: что почитать новичкам и специалистам

Собрали 6 книг, которые помогут на старте изучения SQL и при углублении в тему.
T-Rex 28 сентября 2022