Аббревиатура sla что означает

Что такое 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 – это измеримые метрики, отвечающие за уровень качества предоставления услуги. Условно эти метрики можно называть «KPI» для SLA.

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

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

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

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

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

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

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

Доступность сервиса невозможна на 100%. Значение доступности в процентах стремиться к 100% и выражается в виде количества «девяток» процента доступности. Например, доступность 99% и 99,999% может быть обозначена как «2 девятки» и «5 девяток», а доступность в 99,95% — может обозначаться как «три с половиной девятки».

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

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

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

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

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

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

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

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

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

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

SLI и SLO

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

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

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

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

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

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

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

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

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

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

Источник

Для чего нужен 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 для компании-клиента:

Источник

Как написать хороший SLA

Как написать хороший SLA (Service Level Agreement, оно же Соглашение об уровне сервиса). И какой SLA будет хорошим.

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

Я буду оперировать названием SLA, Service Level Agreement, оно же Соглашение об уровне сервиса. Пришло оно из ITIL/ITSM и прижилось. Этот документ является краеугольным камнем в текущих подходах к осуществлению функций IT. Также он является одним из ключевых, если мы либо хотим нанять внешнего исполнителя для каких-нибудь услуг, либо хотим внутренние подразделения сделать максимально автономными, то есть по сути относиться к ним как к внутреннему аутсорсеру. И хотя подходы ITSM несколько более универсальны и применять их можно с некоторой выдумкой даже довольно далеко за рамками IT, в дальнейшем изложении я буду приводить в примеры ситуацию, когда у нас есть некоторая IT система и сервис — это её сопровождение. Ну просто потому что такая задача типична и встречается повсеместно. Аналогично можно написать SLA для любой другой деятельности, поменяются только список услуг да критерии оценки.

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

Вводная (определительная) часть SLA

В водной части SLA, и я не зря назвал её определительной, неплохо было бы определить, о чём вообще идёт речь.

Лучше всего начать SLA с глоссария, краткого описания системы и ролей участников процесса. Указываем название системы, на основе какого продукта от какого производителя она сделана, если в основе коробочный продукт, или на каких технологиях основана, если самопал. Обычные участники — пользователи, ключевые пользователи, сотрудники HelpDesk (первой линии поддержки), сотрудники второй, третьей (и так далее) линий поддержки, можно указать названия подразделений компании, вовлечённых в процесс, и перечислить какие роли выполняют сотрудники этих подразделений.

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

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

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

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

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

Какой SLA является хорошим?

Начнём с вопроса «какой SLA мы будем считать хорошим». Очень достойный вопрос, очень мало кто может на него внятно ответить. Опустив три тонны размышлений и несколько сточенных языков, перейду сразу к самой сути.

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

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

Выбор метрик для SLA

Много великих умов человечества посвятили массу времени и внимания придумыванию метрик. Обычно не составляет особого труда выбрать такие метрики, которые подойдут в конкретном случае. Знание и понимание предметной области тут является ключевым. Интересно, что некоторые процессы не поддаются вводу метрик. Например, работу программиста нельзя описать хорошими метриками, любая из них может быть перевыполнена программистом в ущерб делу, то есть дискредитирована. И в силу особенностей профессии, любая метрика непременно будет дискредитирована. Но об этом как-нибудь в другой раз. Для поддержки IT-систем всё несколько проще. Часто берут время реакции (иногда подразумевая под ним время до начала обработки запроса) и целевое время для решения запроса. Если в вашей организации исторически сложились другие общепринятые параметры, то возьмите их. Ознакомиться с мировым опытом и подобрать себе метрики можно погуглив на ключевые слова «SLA» и «метрика».

Что тут важно. Не вдаваясь в подробности (это тема для отдельной статьи), метрики должны обладать следующим качествами:
(1) отражать качество предоставления сервиса,
(2) быть легко измеримыми,
(3) быть по возможности универсальными (чтобы использовать во всех своих SLA),
(4) их не должно быть много.

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

И, наконец, последнее по порядку (но не по важности):
(5) метрика должна зависеть только от работы исполнителя.

Если корреляция метрики с работой исполнителя будет слабая, то метрика не будет работать — контроль потерян, SLA не работает.

Приведу пример плохой метрики. Время доступности конкретной IT-системы 99,99% является плохой метрикой для работы HelpDesk. Потому что HelpDesk не влияет на время простоя систем от слова «никак». То есть, если система «упала», то HelpDesk может только максимально оперативно передать информацию тому администратору, кто может систему «поднять». А сколько это займёт времени (и будет ли там вообще кто-либо суетиться) от HelpDesk-а не зависит. Наказывать HelpDesk за чью-то неоперативную работу — это жестоко и бессмысленно. Единственное, чего этим можно будет добиться, что HelpDesk на подобный SLA положит с прибором.

Значения метрик

Теперь я хочу показать, как грамотно подойти к выбору значений метрик.

Типичная ошибка выглядит вот как. Описываю ситуацию. Пусть у нас есть довольно большая система (например, какая-нибудь ERP), и на её поддержке работают:

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

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

HelpDesk в любом случае успеет сделать всё, что от него зависит даже не за сутки, а за час максимум. То есть в процессе телефонного разговора будет оформлен инцидент, заданы уточняющие вопросы, информация зафиксирована и отправлена на 2-й уровень. Час — это так, с запасом. Поэтому HelpDesk не обращает никакого внимания на метрики в SLA. Главное, чтобы всё, прилетевшее сегодня, сегодня же и улетело, и все SLA будут выполнены. Но они так всегда работают.

Теперь 2-й уровень получил инцидент (может напрямую, может из HelpDesk), и до конца дня есть время, чтобы с инцидентом разобраться. Не каждый инцидент может быть за такое время решён, но большая часть действительно за день решается, особенно критичного приоритета. Правда, если инцидент проболтался забытым до вечера в HelpDesk-е, то времени на его решение не осталось. При этом нарушит метрику 2-й уровень, а виноват-то на самом деле был HelpDesk.

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

Теперь 3-й уровень в лице разработчиков, если ещё не разошёлся по домам, имеет дилемму — поработать ударно в ночь или гарантированно нарушить SLA и заняться проблемой утром следующего рабочего дня. В случае ручного педалирования ситуации конечно первый вариант сработает, но штатной такую работу называть не хочется. Потому что с таким подходом срочное прилетает всегда к вечеру. Это итог ударной (и, что особенно важно, хорошей) работы коллег со 2-го уровня.

Разбор полётов. Что мы видим в результах в свете нашего SLA? Для HelpDesk-а и 3-го уровня SLA не работает, работает только для 2-го.

Что будет, если мы увеличим целевое время решения до недели? Теперь можно начать требовать исполнения такого SLA с 3-го уровня. Но зато для 2-го уровня такой SLA работать перестал — чего суетиться, завтра успеем. Или послезавтра. В результате на 3-й уровень проблемы станут попадать в последний день отведённой недели, 3-й уровень этим фактом возмутится и (если здравый смысл внезапно победит) неделя из SLA будет поделена на 2 дня работы 2-го уровня и 3 дня работы 3-го или ещё как-нибудь. Ну и 2-й уровень конечно расслабится, ведь времени, которое ему можно терять попусту, явно стало больше. Зато HelpDesk теперь на SLA не смотрит совсем, они такой SLA не могут нарушить даже если захотят. Им пользователи голову раньше открутят. И общее время решения проблем станет больше. Как-то не очень получается.

А что делать, чтобы SLA начал работать для HelpDesk? Наверное уменьшать время. До одного часа. Но тогда и 2-й и 3-й уровни перестанут попадать в SLA в принципе. И они перестанут в SLA смотреть совсем, потому что там с их точки зрения глупости написаны. И ещё постепенно все уволятся, потому что не могут выполнять свою работу хорошо, а этого на самом деле никто не любит.

Что же делать? Делать выводы. Если мы хотим контроль, то надо выделить целевое время работ на каждом уровне поддержки. И дать на работу HelpDesk-у час, 2-му уровню день, а 3-му три дня. За это время каждый должен выполнить свою задачу. А пока задачу решают другие, один счётчик тикать перестаёт, другой включается. Теперь у нас каждый следит за своим временем и не теряет его попусту. Полный контроль. При привлечении дополнительного уровня поддержки общее время должно увеличиваться, отражая глубину выявленной проблемы. Если надо кого-то интенсифицировать, то можно сделать это адресно. Например, если в самом деле надо вписаться в сутки на всё про всё, то делим их на 30 минут для 1-го уровня, 4 часа для второго и 19 с половиной для третьего. Это может оказаться излишне жёсткими требованиями в каком-то случае, но о вредных последствиях излишне жёстких требований я поясню чуть позже. Зато теперь у нас в SLA есть контроль и он работает, так как метрика позволяет легко выявить, кто не выполняет свою часть работы хорошо. Если пишете многоуровневый SLA, то всегда указывайте метрики отдельно для каждого уровня.

Отдельно отвечу на вопрос «но нам же пользователи сказали, что за один день», и что с этим делать. Пользователи IT-систем очень нечасто обладают компетенцией, достаточной для того, чтобы внедрить, настроить и далее развивать и поддерживать ту самую систему, пользователями которой они являются. Для решения подобных задач как раз существуют IT-подразделения, которые должны по роду своей деятельности понять и обеспечить именно то, что пользователям на самом деле нужно. Так что если Ваши пользователи назвали Вам время в сутки на решение критической задачи, то значит Вы их плохо спрашивали. Конечно же они хотели, чтобы критичные проблемы решались быстрее, скажем за час. А ещё лучше, чтобы сразу по мере возникновения. Некоторые, особо сообразительные могут даже потребовать превентивного решения проблем, и таки да, лучшие практики говорят как раз о проактивной работе. Но тогда, в случае полного успеха, работу IT-отдела не будет никому видно, и всех IT-шников уволят. Поэтому так круто заморачиваются только в тех случаях, когда без этого действительно никак (например, в системах по жизнеобеспечению). Так что не надо прикрываться некомпетентностью пользователей, а надо делать свою работу: объяснить пользователям, что простая проблема будет решена не за день, а даже быстрее. А сложная будет решаться дольше и от этого никуда не деться. И, кстати, в большинстве случаев тот же день на решение и получится.

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

Чем опасны излишние требования

Теперь о вреде излишней жестокости установленных метрик, да и любых других параметров услуг в SLA. Всё просто до банальности: ужесточение метрик увеличивает стоимость работ. Dixi. Поясню на примерах.

Пример №1. Предположим, что какой-то вид запросов на обслуживание в среднем решается часа за 4. Также нам известно, что исполнитель с высоким уровнем экспертизы может решать такие запросы за 2 часа. Что будет, если мы в SLA напишем 2 часа вместо 4? Это приведёт к тому, что исполнитель должен быть экспертом, значит станет более дорогим. Плюс проблемы с его мотивацией в будущем. Потому что с одной стороны эксперту будет скучно заниматься одним и тем же, а с другой стороны есть куча мест, куда его будут усиленно звать. По моим многочисленным наблюдениям цена услуги увеличивается в полтора-два раза.

Пример №2. Что будет, если в SLA в той же ситуации написать 1 час (или 1 минуту, что в данном контексте одно и то же), то есть сделать время нереалистичным? К предыдущему увеличению стоимости смело добавляйте величину предполагаемых штрафов за просрочку и умножайте результат на коэфициент риска, равный, скажем, 1,5-2. И, что самое плохое в данной ситуации, SLA перестаёт работать. Не надо так делать в здравом рассудке.

Пример №3. Хотим вместо режима 8х5 (8 часов по рабочим дням) получить режим 24х7. Ценник тут же увеличивается в два-три раза. И это только в том случае, если можно обойтись дежурной сменой, которая будет перекрывать ночь/выходные и вызванивать реальных исполнителей в случае чего. Если же нужна реальная постоянная работа в режиме 24х7, то ценник будет выше в пять раз, если не больше. Почему? Потому что три смены и выходные/праздники, да подмена на отпуска/больничные. А ещё квалифицированные кадры могут отказаться работать по нестандартному графику, и этот разрыв ожиданий придётся тоже лечить деньгами. Точно ли нужен 24х7?

Пример №4. Хотим постоянного присутствия исполнителя в офисе, чтобы было видно, как он работает и не работает ли — ах! — на сторону? Да, теперь он действительно не может больше помогать коллегам, участвовать параллельно в других проектах, а также не может быть сотрудником из регионального офиса. В конце концов исполнитель будет обязан соблюдать наш дресс-код и терять время на дорогу к нам. Итого раза в два будет дороже. Попутно мы перекрыли себе возможность использовать дополнительные ресурсы во время пиковых нагрузок и привлечение экспертов нужной квалификации по мере надобности, что происходило бы само собой в случае удалённой работы исполнителя. А может и не происходило бы, но теперь этого точно не будет.

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

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

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

Как же тогда правильно выбрать параметры? Лучше всего представить себя на месте исполнителя, прикинуть типичные задачи и достаточное разумное время для решения таких задач. Вот такие параметры и взять для SLA. А дальше уже смотреть за работой SLA в реальной жизни и вносить корректировки.

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

Заключительные пожелания

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

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

Что делать, если систем много. Писать свой SLA на каждую — получится совершенно запутанный зоопарк, нужно унифицировать. Полезно было бы сразу метрики из SLA и их значения сделать универсальными, чтобы не изобретать велосипед для каждой IT-системы в компании, да и в целом так проще отслеживать, что происходит вокруг, сравнивать ситуацию по разным системам. В больших компаниях различных IT-систем существуют десятки, если не сотни. Лучший мировой опыт говорит, что все системы нужно разбить на классы (Mission Critical, Business Critical и т.п.), и выписать метрики для классов. В отдельных случаях могут быть индивидуальные исключения, но большая часть систем может быть покрыта универсальным SLA именно так.

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

Приложение. Прототип SLA

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

Служебная информация
Владелец документа, лист согласования, история версий.

I. Вводная часть.

Система ХХХ на базе продукта УУУ версии 1.2.3.

Список компонент системы

Границы оказания услуг

Услуги оказываются с 09:00 по 18:00 МСК по рабочим дням с пн по пт, кроме выходных и праздников РФ.

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

II. Уровень сервиса

Приоритеты

Использование приоритетов, процедура эскалации (привлечений внимания)…

Ключевые показатели эффективности (КПЭ)

Пример для услуги №2 «Решение инцидентов»:

Целевые значения КПЭ

Алгоритм расчёта метрики

Целевое значение метрики (пример):
80% инцидентов должны решаться в целевое время.

Источник