Как правильно составить 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), и на её поддержке работают:

1. HelpDesk (он же 1й уровень поддержки), принимающий обращения от всех пользователей компании по телефону, почте и интранету, оформляющий обращения в инциденты и переводящий инциденты в специализированные группы поддержки 2-го уровня,
2. Группа поддержки 2-го уровня из аналитиков, знающих эту систему с точки зрения функционала, которые могут разобрать инцидент, помочь пользователям и выявить ошибки системы в коде/данных,
3. Группа поддержки 3-го уровня из разработчиков, которые умеют исправить код/данные в системе и привлечь вендора базового ПО в случае необходимости,
4. Вендор базового ПО является в этой схеме 4-м уровнем поддержки. На этом же уровне могут фигурировать другие подразделения компании типа сетевиков, инфраструктуры и т.п.

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

Мы пишем в 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

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

UPDATE: то, что не поместилось в основной статье:
Философия SLA: что такое эскалация и зачем она нужна
Философия SLA: про приоритеты запросов

Что такое SLA, для чего оно нужно IT-компаниям и как его составить, чтобы наладить эффективное сотрудничество с заказчиками.

Что это такое – SLA

SLA (англ. Service Level Agreement – соглашение об уровне сервиса) – это соглашение между заказчиком и исполнителем о том, какие, когда и как будут предоставляться услуги. Также в него входят права и обязанности сторон. Используется SLA в IT и сфере телекоммуникаций.

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

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

Простыми словами, SLA – это договор, в котором подробно описаны предоставляемые услуги, их качество, время реагирования на заявку и ее исполнение.

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

Например, главбух клиента может быть недоволен, что админ со стороны провайдера поднимает какой-то там сервер (делов-то на 5 минут, а он уже 2 часа возится), вместо того чтобы заправить картриджи в бухгалтерии.

И чтобы избежать таких моментов и сохранить хорошие отношения, аутсорсинговая компания может составить SLA, в котором:

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

И теперь клиенты будут знать, что если разом перестали работать 20 тонких клиентов из 30, то сотрудник сможет заняться этим через 15–30 минут, а на устранение уйдет от 1 до 5 часов. А если проблема с принтером, то отклик будет только через час, хотя решение проблемы займет всего 10 минут.

Как составить SLA

Существует типовая структура, которой следует придерживаться, чтобы составить договор аутсорсинга на оказание услуг:

1. Определение сторон предоставляемого сервиса и сроков действия договора.
2. Дни и часы оказания услуг (включая тестирование, поддержку и модернизацию).
3. Количество пользователей и оборудования, а также их территориальное размещение.
4. Описание процедуры составления отчетов о неполадках.
5. Описание процедуры заполнения заявок на обслуживание.
6. Определение уровней качества предоставления услуги.
7. Описание платежей.
8. Ответственность заказчика.
9. Способы решения разногласий.
10. Возможные действия по улучшению договора.

Все эти пункты должны быть прописаны очень подробно. Так, например, описывая уровень качества, нужно учесть такие параметры, как:

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

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

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

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

Не отпугивает ли это клиентов

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

Исполнитель обязуется устранить неисправность после обращения заказчика.

В SLA же будет написано:

Исполнитель обязуется приступить к устранению неисправности в течение 30–60 минут в будний день с 9 до 18 часов и исправить ее в течение 5–10 часов.

Это немного не совпадает с желаниями заказчика – он хочет, чтобы провайдер был готов разобраться с локальным концом света в режиме 24/7. Поэтому некоторые потенциальные клиенты могут отказаться от сотрудничества, прочитав SLA.

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

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

В этом отношении у SLA есть явные преимущества:

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

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

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

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

Рассказываем об IT-бизнесе, технологиях и цифровой трансформации

Подпишитесь в соцсетях или по email

Соглашение об уровне обслуживания (Service Level Agreement, или SLA
) — договор между поставщиком ИТ-услуги и заказчиком. Появившись когда-то в ITIL
как одна из рекомендаций, SLA стал незаменимым практическим инструментом. Сейчас именно на основе SLA в большинстве случаев выстраивается взаимодействие поставщика и заказчика.

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

• Описание, или определение, услуги, вовлеченные стороны, сроки действия SLA;
• Даты и время, в которые услуга будет предоставляться;
• Количество пользователей (сервиса), экземпляров оборудования или ПО;
• Регламент обработки запросов, инцидентов, а также подготовки отчетов о проблемах;
• Целевые показатели: согласованное время работоспособности, согласованное время поддержки, время реакции, доступность сервиса и т. д.;
• Расценки и график платежей за услугу;
• Компенсации за несоблюдение SLA и процедура разрешения спорных ситуаций.

Основной канал, через который поставщик и клиент взаимодействуют в рамках предоставления ИТ-услуги, — служба поддержки. Отсюда и ключевая роль Help Desk, или Service Desk, в SLA. Важно составлять подробное и грамотное SLA, чтобы оно учитывало все нюансы процесса оказания услуги.

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

Периодически проверяйте и корректируйте SLA

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

Вы сервис-провайдер, который взял на поддержку виртуальную инфраструктуру клиента. Одна из ключевых метрик вашего SLA — параметр производительности системы хранения на HDD-дисках. Допустим, производительность СХД по SLA составляет 2000 IOPS.

В какой-то момент клиент переходит на новую ресурсоемкую СУБД. После чего в вашу службу поддержки начинает поступать всё больше запросов, связанных с медленной работой СХД. Выясняется, что клиента больше не удовлетворяет действующая метрика производительности, и он, не вникая в особенности технологии, просит пересмотреть SLA.

Анализируя отчеты Service Desk, вы можете действовать на опережение — пообщаться с клиентом и выяснить причины проблемы. Как вариант, можно перевести клиентскую базу данных на SSD-хранилище с производительностью 10 000 IOPS и предложить клиенту SLA с новыми метриками. Так, своевременный апгрейд инфраструктуры и пересмотр метрик поможет избежать конфликтной ситуации.

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

Добавьте ограничения и исключения

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

Время реакции. Если у вас проводится регулярное плановое техобслуживание систем мониторинга, когда вы не можете оперативно ответить на запрос, укажите это в SLA в качестве ограничения. Например: «Гарантированное время реакции на запрос — до 1,5 часов, кроме каждой второй среды месяца в период с 1.00 до 4.00». Добавьте детальное объяснение причины.

Периоды простоя. Отметьте ситуации, когда простой сервиса не зависит от вас и время неработоспособности сервиса может возрасти. Например:

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

Время поддержки. Учтите период, в который вы не сможете поддерживать сервис, — к примеру, в нерабочее время и в выходные. Тогда согласованное время поддержи можно указать так: «8×5 (10:00-18:00, Пн-Пт)».

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

Сделайте SLA измеримыми

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

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

Сделайте отдельные метрики для каждого уровня поддержки

Help Desk и Service Desk обычно многоуровневые службы. У каждого уровня определенные специфика, сложность задач и KPI. Это нужно учитывать при согласовании в SLA времени реакции и времени решения проблем.

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

Первая линия обрабатывает запросы пользователей и решает простые проблемы — ей на это требуется в среднем один-два часа.

Вторая решает более сложные проблемы — от нескольких часов до суток.

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

Рассчитывайте временные метрики в SLA индивидуально для каждой линии техподдержки. Метрики должны быть реалистичными: если проблема требует сложных работ с привлечением третьей линии поддержки, ее невозможно решить за сутки.
Объясните клиенту, почему у разного типа инцидентов и запросов на обслуживание разные сроки решения, и от чего они зависят.

Учитывайте ожидания клиента

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

Если уровень гарантированной доступности сервиса 99,9%, ему позволено «лежать» суммарно 43 минуты в месяц. Сценарии могут быть разными. Например — четыре некритичных инцидента ночью с простоем по 10 минут каждый. Либо 40 минут днем, в час пиковой нагрузки, когда простой сервиса приведет к многомиллионным убыткам. Формально поставщик не нарушит SLA, но вряд ли клиент будет удовлетворен качеством услуги.

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

Избегайте общего SLA для клиентов с географически распределенной структурой

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

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

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

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

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

Соглашение об уровне сервиса обычно обладает следующими характеристиками:

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

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

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

Что обычно указывают в SLA

Выше мы привели пример SLA от Amazon Web Services. Это не стандарт, а лишь один из вариантов, который учитывает специфику конкретного сервиса.

В SLA для IT часто расписывают следующие пункты:

• Порядок использования сервиса или услуги.
• Ответственность сторон, в том числе инструменты взаимного контроля исполнения принятых обязательств.
• Конкретные шаги для устранения неисправностей и восстановления работоспособности.

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

При описании качества сервиса также раскрываются его параметры. Обычно это:

• Доступность самого сервиса.
• Время реакции на возникшую проблему.
• Время устранения неисправностей.

В соглашение может быть также указана метрика часов работы. 

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

Ключевые параметры SLA

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

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

Допустим, компания делит всех клиентов на несколько групп. Первой группе гарантируют круглосуточную поддержку по телефону и в чате. Второй — поддержку по телефону и в чате, но только по будням. Третьей — поддержку только в чате и только по будням.

Метрики нужны для того, чтобы все участники соглашения понимали, какие услуги, когда и в каком объеме они получат. Отсюда следуют несколько характеристик:

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

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

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

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

Допустим, компания предоставляет IT-услуги на аутсорсе. У нее есть группа пользователей, которая оплачивает премиум-тариф, и группа пользователей на базовом тарифе. Время реакции на инцидент может быть разным в зависимости от группы. Например, клиенты из первой группы получают ответ в течение 15 минут. А клиенты из второй группы могут ждать до суток. Все это должно быть четко отражено в SLA.

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

Допустим, у клиента перестала работать локальная сеть в офисе и все процессы остановились. Устранением такой проблемы нужно заниматься в первую очередь. В SLA можно прописывать конкретные ситуации и время работы над ними. Допустим, проверка и настройка локальной сети — не более 5 часов.

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

Время отклика на вызов клиента и время решения проблемы в совокупности составляют время простоя. 

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

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

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

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

Например, на cloud.timeweb.com доступность по SLA — 99,99%. Соглашение гарантирует, что простой сервисов не превысит 52 минут в год. 

Провайдеры могут обещать и пять девяток — 99,999% или не более 15 минут простоя сервисов в год. Но это не всегда лучшее решение. Есть как минимум две вещи, которые стоит иметь в виду:

• Чем выше показатель SLA, тем дороже обслуживание.
• Далеко не каждому клиенту нужен такой уровень SLA. В подавляющем большинстве случаев достаточно базовых 99,982% или немного выше.

Смотреть стоит не только на количество девяток, но и на время, которое провайдер указывает для контроля. По умолчанию в договор SLA вписывают показатели за год. Например, вам обещают, что сервисы будут доступны 99,95% времени. Простой — не более 4,5 часов в год.

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

Еще один важный момент — совокупная доступность. Она равна наименьшему показателю.

Плюсы SLA

Подписание и соблюдение SLA выгодно обеим сторонам. 

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

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

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

SLA и SLO: в чем разница

SLA также можно рассматривать в качестве индикатора удовлетворенности пользователей. Высшее значение — 100%, низшее — 0%. 

Добиться абсолютной удовлетворенности (100%) невозможно — так же, как нельзя гарантировать, что по SLA server всегда будет доступен. Поэтому при выборе конкретных метрик рекомендуют смотреть на продукт реалистично и выбирать посильные значения. 

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

Чтобы отслеживать уровень сервиса внутри компании, придумали еще одну систему — SLO. Это те значения метрик, которые поставщик услуг хотел бы достичь (objectives). 

Берем тот же пример с технической поддержкой. Допустим, текущие возможности — обработка 50 обращений в течение рабочего дня, график — с 9:00 до 18:00 пять дней в неделю. Эти метрики компания фиксирует в SLA и показывает клиентам. 

Параллельно составляется еще один документ — SLO. Это основа, на которой выстраивается управление уровнем услуг. В SLO учитываются текущие метрики, закрепленные в SLA, но дополнительно есть цель: например, увеличить количество обработанных обращений в течение рабочего дня до 75 или сделать поддержку круглосуточной. От этого зависит будущий IT-service level. 

Как составить правильное соглашение

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

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

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

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

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

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

Чек-лист: на что обратить внимание при подготовке SLA

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

• Пользователи. В больших системах рекомендуется разделять пользователей на группы и работать с ними отдельно. Это помогает эффективнее распределить ресурсы и не разрываться между запросами разных групп клиентов.
• Сервисы. Здесь важна критичность сервиса для конкретной группы клиентов. Например, вы предлагаете CRM торговым компаниям. Если они не смогут ей пользоваться, то понесут убытки и придут с претензиями. Поэтому у такого сервиса самый высокий уровень критичности. Условная замена принтера или создание новой учетной записи для сотрудника на этом фоне может подождать до завтра.
• Параметры качества сервисов. Они должны соотноситься с бизнес-целями компании и потребностями клиентов. Стандартный пример — время и порядок устранения инцидентов. Например, компания может гарантировать круглосуточную поддержку или решать проблемы только по будням с 9:00 до 18:00.

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

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

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